RE: issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess
"Avi Lior" <avi@bridgewatersystems.com> Fri, 06 January 2006 16:41 UTC
Envelope-to: radiusext-data@psg.com
Delivery-date: Fri, 06 Jan 2006 16:39:55 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess
Date: Fri, 06 Jan 2006 11:41:33 -0500
Message-ID: <E7CCE8A83907104ABEE91AC3AE3709A0022A380F@exchange.bridgewatersys.com>
Thread-Topic: issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess
Thread-Index: AcYSYeL8LMhRj3FzTx+ByLYrb0KQZwAekd8A
From: Avi Lior <avi@bridgewatersystems.com>
To: Henrik Nordstrom <henrik@henriknordstrom.net>, radiusext@ops.ietf.org
Hi Henrik, Personally I have no issue with doing what you want. I actually think that it makes sense. However, the problem I have is that we need this work to finish ASAP. In fact, it is my working in 3GPP2 that is waiting for this work to complete. I don't mind if we add this facilities providing it will not further delay this document. > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Henrik Nordstrom > Sent: Thursday, January 05, 2006 7:12 PM > To: radiusext@ops.ietf.org > Subject: RE: issue: draft-ietf-radext-digest-auth-06.txt > Digest MD5-sess > > On Thu, 5 Jan 2006, Avi Lior wrote: > > > So one example is in Mobile IP. Once the HA has validated the > > Registration Request or Binding Update with RADIUS. It can > continue > > to authentication subsequent bind request or Registration Request > > received from that user. This is only limited by a lifetime > received > > from the AAA server. > > Which is very similar to what is provided by Digest MD5-sess. > The credentials given to the RADIUS client is only good for > validating within a good credibility that next messages is in > the same user session. It can not be reused in authentication > to any other service, or even to start a new session or renew > the existing session to the same service. > > Giving avay the non-session Digest MD5 HA1 is a completely > different think. It's in the Digest world almost equivalent > to giving away the users plaintext password. > > The only security issue with the MD5-sess HA1 in session mode > that I can see is it SHOULD be transmitted securely IF > MD5-sess is used in session mode or if message integrity > protection is used as knowledge of the MD5-sess HA1 hash > allows for limited session theft, limited by session nonce > count and time limits enforced by the service. But as soon as > the server-side nonce expires the hash is completely useless > for any meaningful purposes. > > > > My notes on security issues of the Digest-HA1 attribute in > general and it's use in Digest session authentication in particular: > > > MD5, any mode of operation: > > Equivalent to plaintext for any service using Digest authentication. > Knowledge of the MD5 HA1 allow for full theft of the account on the > service/realm until the password or realm is changed, and > consequently > also full control of integrity protection of both requests > and responses. > > MD5-sess, one request per nonce: > > No session theft is possible as the sessions only last for a single > message. > > But knowing the HA1 allows breaking any response integrity > protection. > Request integrity is protected however as the HA1 is only > known after the > request has been received and processed by the service. > > MD5-sess, session based: > > In addition to the above it allows for session theft for as > long as that > session is considered valid by the service, including > request/response > integrity protection (except for the first message). Session > length is > usually limited by both nonce count (number of requests) and > time. The > RADIUS server may hint both session limits to the client, but can not > enforce it. > > > Senario 1 mode of operation: > > If Senario 1 mode of operation is allowed then it mau be considerably > easier for an attacker to gain access to the HA1. If Scenario > 1 mode of > operation is allowed then he only needs to be able to see the > application > protocol traffic and have access to any RADIUS client allowed > to query the > RADIUS server in this mode to gain access to the Digest-HA1 > by replaying > the seen Digest message details to the RADIUS server. > Transport protection > of the Digest-HA1 attribute does not help against this. > > > > Regards > Henrik > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://psg.com/lists/radiusext/> > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/>
- RE: issue: draft-ietf-radext-digest-auth-06.txt D… Avi Lior
- RE: issue: draft-ietf-radext-digest-auth-06.txt D… Henrik Nordstrom