Sterman Issue#8 and Some Other Issues

[Jun Wang <jwang@qualcomm.com>]

Hi folks,

The following comments and questions are related to issue #8 and some other 
new issues.

1) The title of Issue #8 indicates that "Rspauth generation not possible if 
RADIUS server chooses nonces and qop=auth-int"

This issue exists regardless of whether the RADIUS Server or Client chooses 
the nonces. We think the current approach proposed by Wolfgang can apply 
for both cases.

2) Section 2.19 (Digest-HA1 attribute) first paragraph states:

"If this attribute is present, the RADIUS server did not accept the nonce 
value."

This statement seems incorrect. It should be replaced with: "This attribute 
holds H(A1) as described in RFC2617 to be used for constructing the 
Authentication-Info header by the RADIUS client."

3) There several places (like sections 2.19, 3.1, and 3.2) which state 
something like: ".... MUST NOT...., unless....".   We think it will be 
better to reword the sentences along the lines provided in the examples below.

a) Section 2.19 under string definition, states the following:

"If the 'algorithm' directive's value is 'MD5' or 'AKAv1-MD5', the 
Digest-HA1 attribute MUST NOT be sent by the RADIUS server or processed by 
the RADIUS client, unless the authenticity and integrity of the 
Access-Accept message was secured by cryptographic or equivalently secure 
means."

We can replace the above text to:

If the 'algorithm' directive's value is 'MD5' or 'AKAv1-MD5', and the 
authenticity and integrity of the Access-Accept message was not secured by 
cryptographic or equivalent secure means, the Digest-HA1 attribute MUST NOT 
be sent by the RADIUS server or processed by the RADIUS client.

b) Text in Sections 3.1 and 3.2 states:

"If the Digest-Qop attribute's value is 'auth-int' and the Digest-Algorithm 
attribute's value is 'MD5' or 'AKAv1-MD5', the RADIUS client MUST NOT use 
the Digest-HA1 attribute, unless it knows for sure that the Access-Accept 
message was encrypted or otherwise protected against eavesdropping".

We can replace the above text to:

The RADIUS client MUST NOT use the Digest-HA1 attribute if all of the 
following conditions are true:
- The Digest-Qop attribute's value is 'auth-int';
- The Digest-Algorithm attribute's value is 'MD5' or 'AKAv1-MD5'; and
- The authenticity and integrity of the Access-Accept message was not 
secured by cryptographic or other equivalent secure means.


4) Section  2.4 (Digest-Response-Auth attribute) states:

"This attribute is only used in Access-Accept messages if the RADIUS server 
is configured to choose nonces."

Why is this attribute not applicable when RADIUS client chooses nonces? It 
seems that this attribute is needed as long as the mutual authentication is 
performed (see section 3.2.3 of RFC 2617.)

5) This comment is applicable to all attributes in Section 2. All attribute 
definitions should clearly specify in which RADIUS messages (Access 
Request, Access Accept, Access-Challenge, Access-Reject) these are valid.

For example, section 2.9 only mentions Access Accept message. However, the 
Digest-Algorithm attribute can also be present in Access-Challenge message.

6) The definition of Digest-Stale attribute in Section 2.18 is not clear. 
It should be clarified as follows:

2.18  Digest-Stale attribute

This attribute indicates whether the RADIUS server accepted the nonce value 
received from the RADIUS client.

Type
         DIG-STALE

Length
         3

String
         The string consists of a single character.  If the nonce 
presented by the RADIUS client was stale, the character is '1' and is '0' 
otherwise.  If the RADIUS sever does not accept the nonce received in 
Access Request message but authentication was successful, the RADIUS server 
MUST include this attribute in Access Accept message and set it to '1'; the 
RADIUS server MUST also set the 'next-nonce' attribute in the Access-Accept 
message to the valid nonce-value.


7) In Section 3.1, the text on Digest-Stale attribute is not clear. It 
should be clarified as follows:

If the RADIUS client receives an Access-Accept message from the RADIUS 
Server with the Digest-Stale attribute set to '1', the RADIUS client sends 
an error (401 or 407) response to the HTTP-style client containing 
WWW-/Proxy-Authenticate header with the stale flag set to "TRUE and the 
nonce value set to the 'next-nonce' value received in the Access-Accept 
message.

8) The following RADIUS Server procedure should be added to section 3.2:

If the RADIUS sever does not accept the nonce received in Access Request 
message but authentication was successful, the RADIUS server MUST include 
this attribute in Access Accept message and set it to '1'; the RADIUS 
server MUST also set the 'next-nonce' attribute in the Access-Accept 
message to the valid nonce-value.

9) More general question related to comments 6), 7) & 8) above. 
The  current text assumes that if the nonce is stale and authentication is 
successful, the RADIUS server will indicate it to the RADIUS client using 
Access-Accept message. Shouldn't this be indicated in Access-Challenge 
message? So, Access-Accept messages should be sent only when nonce is valid 
and authentication is successful. For any other purpose, Access-Challenge 
or Access-Reject should be used.

Thanks,
Jun


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