RE: Compound authentication "issue"

Just so I understand this a little better, it appears that there are two
styles of attack to consider:
i) an attacker obtains a user's DIGEST-MD5 password from some previous
unprotected session or server impersonation, or
ii) an attacker performs a MITM to immediately use a surreptitiously
obtained DIGEST-MD5 password. 

I believe that (i) is already dealt with through the inclusion of client and
server nonces as prescribed in [1]. It is for (ii) in particular that the
additional measures (described below) are required. Personally, I'm a little
skeptical as to the likelihood of such MITM attacks.  However, the
protection costs don't appear too onerous. I think 1a (below) is reasonable.


Cheers,
Mike

[1] http://www.ietf.org/rfc/rfc2831


 -----Original Message-----
From: 	Stephen Farrell [mailto:[email protected]] 
Sent:	November 21, 2002 9:36 AM
To:	ietf-sacred
Subject:	Compound authentication "issue"



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