RE: issue: draft-ietf-radext-digest-auth-06.txt Digest MD5-sess

["Avi Lior" <avi@bridgewatersystems.com>]

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/>