Subject: Compound authentication "issue"

From: Stephen Farrell <[email-masked]>
Date: Thu, 21 Nov 2002 14:35:46 +0000

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-masked]
Ireland                             http://www.baltimore.com

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 21 Nov 2002 15:19:01 +0000

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.

---

From: Lawrence Greenfield <[email-masked]>
Date: Wed, 27 Nov 2002 15:35:53 -0500

Upon further consideration, isn't the man-in-the-middle attack
thwarted by the inclusion of "digest-uri-value" in the hash?

The DIGEST-MD5 client hash includes a client-selected
"digest-uri-value" which in sacred's case will be "sacred/<host>". In
a MITM attack, those values will be something else.

A MITM attack as described in the WG meeting is thwarted because
digest-uri-value wouldn't match what the sacred server is expecting.

If it would make people feel better, we can mention this safeguard in
the security considerations section.

Larry

---

From: "Nystrom, Magnus" <[email-masked]>
Date: Thu, 28 Nov 2002 22:35:46 +0100 (W. Europe Standard Time)

I believe you are right Lawrence. In essence, the client's response is a
keyed hash of a string of which the digest-uri-value is a part. Since the
MITM cannot influence that part, the "sacred" serv-type won't be present
when a MITM is active and the true SACRED server won't therefore accept
the response (it must not mechanically take the client-provided cleartext
digest-uri-value and use that when calculating its version of the response
though, but also check that the serv-type IS "sacred" and the name is its
own).

Assuming this holds I agree, some text in the Security Considerations
section seems to be sufficient.

Thanks,
-- Magnus

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Nov 2002 11:21:09 +0000

Great. Since you guys clearly understand this better, can you provide me
with the said text?

Thanks,
Stephen.