Compound authentication "issue"
Stephen Farrell <[email protected]> Thu, 21 Nov 2002 14:35:46 +0000
| Newsgroups | gmane.ietf.sacred |
|---|---|
| Organization | Baltimore Technologies Ltd. |
| Message-ID | <[email protected]> |
All, At the meeting (see the minutes) we discussed the potential problem where a sacred DIGEST-MD5 password is also used in an insecure fashion and the possibility that this allows an attacker to carry out something that's a bit like a MITM attack. (This arose from a draft [1] discussing the problem in an EAP context.) Even though (IMO) this problem doesn't represent an attack on sacred, it does describe a situation that can, and will, happen, and also something we can help to make much less likely to happen (though we can't avoid the damage entirely). So, as well as describing the issue in the security considerations section, we can try to make sure that even if the same DIGEST-MD5 password is used elsewhere insecurely, the DIGESGT-MD5 authenticator used in sacred differs so that the attacker doesn't get to be a MITM and has to dictionary attack the authenticator as used outside sacred. There're a bunch of ways to do this, all of which amount to doing some additional processing on the username &/or password before passing it to the DIGEST-MD5 code:- 1. We can modify the username 2. We can modofy the password 3. We can modify both 4. We can do nothing and claim this isn't a real problem. And "modify" can mean: a. Prepend a value, i.e. password (resp. uname) --> "sacred:pwd" b. Do an additional hash, i.e. password (resp. uname) --> "H(pwd)" c. Do both, i.e. password (resp. uname) --> "H(sacred:pwd)" Our current favorite is choice 1a, to prepend the string "sacred:" to all usernames. I should probably point out that this makes it hard (impossible?) to use an existing DIGEST-MD5 database within a sacred credential server (which is possibly desirable anyway). We also looked at, but discarded, some options which would involve modifications to either the TLS support in BEEP or to the DIGEST-MD5 internals, since we don't think those layering violations are a good idea. If you don't agree with this can you send mail to the list in the next few days, and please specify which option you do prefer, or specify another one. If you do agree with 2a, feel free to say that too. Cheers, Stephen. [1] http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-00.txt -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:[email protected] Ireland http://www.baltimore.com