Re: Compound authentication "issue"

[Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>]

Sorry, I said "2a" at the end of this, but meant "1a" as stated
earlier on.

Wishing I could think & type at the same time,
Stephen.

Stephen Farrell wrote:
> 
> 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:stephen.farrell@xxxxxxxxxxxx
> Ireland                             http://www.baltimore.com

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@xxxxxxxxxxxx
Ireland                             http://www.baltimore.com