Issue: Radius Digest requirement to clients

[Miguel Garcia <[e-mail]>]

Submitter name: Miguel Garcia
Submitter email address: [e-mail]
Date first submitted: August 18, 2005
Reference: -
Document: draft-ietf-radext-digest-auth-03.txt
Comment type: T
Priority: '1' Should fix
Section: 1.2
Rationale/Explanation of issue:

The text imposes a requirement for RADIUS client that is both 
unimplementable and untestable.

The text reads:
    "If the RADIUS server generates nonces, its RADIUS clients MUST NOT
    try to generate nonces.  If the RADIUS server does not generate
    nonces, its RADIUS clients MUST generate nonces locally. "

The text seems to suggest that if a RADIUS server is generating a nonce 
then the RADIUS client must make sure that it does not generate a nonce. 
  These seems to imply a sequence where first the RADIUS server does an 
action (generate or not a nonce), and then the RADIUS client does a 
consequent action (not generate or generate a nonce).

However, the sequence of events (see the scenarios in Sections 1.3.1 and 
1.3.2) is that it is the RADIUS client the first entity that has to 
decide whether to generate a nonce or not (I assume that based on 
configuration), and then the RADIUS server can operate consequently.

Requested change:

I see two possibilities here, please choose one.

Possibility 1:
==============
To describe that the RADIUS servers and clients do not verify whether a 
nonce has been previously generated by the correspondent node. However, 
this must be pre-agreed and pre-configured before operation. In this 
case, I suggest to delete the text above mentioned and add the following:

"This specification assumes that both the RADIUS client and server are 
appropriately configured to generate the nonces in either the RADIUS 
client or the RADIUS server, but not in both at the same time. 
Implementations, though, do not have the means to verify this behaviour."

Possibility 2:
==============
To enforce that nonces are generated appropriately. I have my doubts 
whether this is achievable or not, espcially considering the case of 
HTTP Digest authentication using AKA (RFC 3310), because it requires to 
generate nonces always in the RADIUS server. In addition to this, we 
would need to consider the error cases and the recovery from them. If 
someone wants to pursue this track, please provide text for discussion.

-- 
Miguel A. Garcia           tel:[phone]
sip:[e-mail]
Nokia Research Center      Helsinki, Finland


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