1 / 8

Draft-ietf-sacred-protocol-bss-0 4 .txt

Draft-ietf-sacred-protocol-bss-0 4 .txt. editor: Stephen Farrell, stephen.farrell@baltimore.ie 55 th IETF, November 2002. Changes from –03. Replaced SASL-MD5 with DIGEST-MD5 everywhere Updated appendix B and other BEEP issues according to Marshall Rose's Oct 6th recommendations

denton-santos
Download Presentation

Draft-ietf-sacred-protocol-bss-0 4 .txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Draft-ietf-sacred-protocol-bss-04.txt editor: Stephen Farrell, stephen.farrell@baltimore.ie 55th IETF, November 2002

  2. Changes from –03 • Replaced SASL-MD5 with DIGEST-MD5 everywhere • Updated appendix B and other BEEP issues according to Marshall Rose's Oct 6th recommendations • Applied all but three "editorial corrections" raised on list • Added a recommendation to download prior to modify • Fixed AuthXXXType extensibility as suggested by Gareth Richards

  3. Issues still open • “Rejected” issues from list: • Adding upload response message • Use of CDATA needed? (BEEP question) • “More editorial” stuff from Magnus: “ok,ok,ok” • Some clarifications (Manning) • “tuning” & clarity wrt BEEP & auth • New security issue: binding of separate authentications

  4. Compound Authentication Issue • draft-puthenkulam-eap-binding-00.txt describes how the lack of a strong binding between compound authentications (esp. server then tunnelled client) leaves open the possibility of “MITM” attacks, which, if the same client authenticator (e.g. password) is badly used in one context, can be real attacks. • Raised wrt EAP, but applies here too unfortunately.

  5. Problem • DIGEST-MD5 password used for sacred and (non TLS) web access with web server (WS) • Attacker masquerades as WS to client. • Client connects to WS. • Attacker WS connects to credential server (CS) • CS issues challenge to Attacker • Attacker passes back challenge to Client • Client sends response to attacker • Game over

  6. Danger!!! Client Web Server Credential Server Digest-MD5 (clear) Server-auth TLS, then Digest-MD5 (same pwd) Too late. Client Attacker Credential Server Server-auth TLS, DIGEST-MD5 challenge Digest-MD5 (clear) Finish Digest-MD5 Run away with private key

  7. Fix? • As a generic attack it arguably ought to be fixed generically (e.g. show a way to securely use SASL within TLS) • Specific fix: Modify use of DIGEST-MD5, e.g. make password include “sacred:” or hash(uname) or something? (bar-BoF anyone?) • Guidance: If the client authenticator is only used for sacred then the attack doesn’t arise => recommend that the DIGEST-MD5 password only be used for sacred and point at (or describe: “dependency--”) the attack scenario in the security considerations section? • EKE, SRP etc. Been there, done that. :-(

  8. Plan • -05 to be done this week • Only real work is new security considerations text (if that’s how we fix the compound authentication issue) • Proposed text to list this week

More Related