open issue: rspauth generation not possible if RADIUS server choo ses nonces and qop=auth-int

["Beck01, Wolfgang" <[e-mail]>]

rspauth generation not possible if RADIUS server chooses nonces
and qop=auth-int
Submitter name: Wolfgang Beck
Submitter email address: [e-mail]
Date first submitted: 25.8.2004
Reference: 
Document: RADIUS Extension for Digest Authentication
Comment type: T
Priority: 1
Section: 3.1, 3.2
Rationale/Explanation of issue:
Jun Wang wrote:
> As the RADIUS server does not know about the response body the
> RADIUS client is going to send, it can't generate A2.
> 
> In 3GPP2, we do need to perform auth-int because we need to protect the 
> response that is sent from the network to the MS. I hope in this draft you 
> could allow solution 3 or at least you will not preclude solution 3 so that 
> we can have 3GPP2 VSA to do it.
> 
> Thanks,
> Jun
> 
> Beck01, Wolfgang wrote:
>> Hello Jun,
>> 
>> thank you for your review. Rahul Joshi told me about this problem
>> some weeks ago and I think there are three possible solutions: 1)
>> don't use authentication-info with auth-int 2) send all possible
>> response body-digests to the RADIUS server 3) your suggestion.
>> 
>> I am not sure about the security implications of 3). Replay
>> attacks might be possible. Solution 2) is a bit bloated as it
>> would double the work on client and server.
>> 
>> In the San Diego meeting, I proposed using solution 1) and
>> did not hear any objections.
>> 
>>
>> Jun Wang wrote
>>>
>>> By reviewing sterman draft (RADIUS Extension for Digest Authentication, 
>>> draft-sterman-aaa-sip-03.txt), I have questions on how the RADIUS sever can 
>>> calculate the Digest-Response that can be used by RADIUS client to 
>>> construct Auth-info header (mentioned in section 3.2 in sterman draft). 
>>> According to 3.2.3 of RFC 2617, if I understand correctly, the response 
>>> digest is calculated as for the request-digest except that A2 is slightly 
>>> different. But regardless, to calculate Digest-Response, the RADIUS server 
>>> needs to know H(entity-body), here entity-body, I think, is the body 
>>> contained in 200OK response. But RADIUS server doesn't know it. It seems to 
>>> me that the right thing is to pass some derived key to RADIUS client so 
>>> that the RADIUS client can calculate Auth-info.
>>> 
>>> 
Requested change:

[Jun Wang]
>>> [..] It seems to me that the right thing is to pass some
>>> derived key to RADIUS client so that the RADIUS client can
>>> calculate Auth-info.

[Wolfgang Beck]
When using qop=auth-int, the response-auth value is 

response-auth  = <"> < KD ( H(A1),     unq(nonce-value)
                                          ":" nc-value
                                          ":" unq(cnonce-value)
                                          ":" unq(qop-value)
                                          ":" H(A2)
                                  ) <">

with algorithm = MD5, A1 and A2 are:

A1       = unq(username-value) ":" unq(realm-value) ":" passwd
A2       = ":" digest-uri-value ":" H(entity-body)

Sending H(A1) in an Access-Accept message would be risky as A1
has no random components. Replay attacks are possible.

with algorithm = MD5-sess, A1 and A2 are:

A1       = H( unq(username-value) ":" unq(realm-value)
                     ":" passwd )
                     ":" unq(nonce-value) ":" unq(cnonce-value)
A2       = ":" digest-uri-value ":" H(entity-body)

here, A1 has some randomness. A possible solution might be:
1. Add a new attribute to carry H(A1), Digest-HA1
2. Use Digest-HA1 if server chooses nonces, qop=auth-int and
algorithm=MD5-sess
3. Use a Digest-Response-Auth attribute (new, see issue 4, 5) 
if server chooses nonces and qop != auth-int.
4. On reception of Digest-HA1, the RADIUS client constructs
rspauth, using the nonce received in a previous Access-Challenge

I don't know if this is really secure.



--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>