Compound authentication "issue"

[Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>]

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