Proposed Resolution to Issue 230: RFC 4590bis Last Call Comments

[Bernard Aboba <bernard_aboba@hotmail.com>]

Issue 230 (RFC 4590bis Last Call Comments) is enclosed below. 
 
The length of the Digest-Nonce-Count attribute has to include the Type and Length fields, so that it is indeed 10, not 8. 
 
Here is what RFC 2617 Section 3.2.2 says about nonce-count:
 
   nonce-count
     This MUST be specified if a qop directive is sent (see above), and
     MUST NOT be specified if the server did not send a qop directive in
     the WWW-Authenticate header field.  The nc-value is the hexadecimal
     count of the number of requests (including the current request)
     that the client has sent with the nonce value in this request.  For
     example, in the first request sent in response to a given nonce
     value, the client sends "nc=00000001".  The purpose of this
     directive is to allow the server to detect request replays by
     maintaining its own copy of this count - if the same nc-value is
     seen twice, then the request is a replay.   See the description
     below of the construction of the request-digest value.

So all the examples (not just the first) in Section 6 do indeed appear to be illegal. 
 
Also, the examples should supply the password so as to allow for verification of the calculations.  
 
Handling of internationalization within RADIUS is covered in RFC 4282, so that I don't believe that this draft needs to reinvent that wheel. 
 
 
Issue 230: RFC 4590bis Last Call Comments
Submitter name: Frank Ellermann 
Submitter email address:  
Date first submitted: May 18, 2007
Reference: http://ops.ietf.org/lists/radiusext/2007/msg00287.html
Document: RFC 4590bis-01
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:
 
Hi, this draft might be also interesting for the 2831bis (SASL) and
2617bis (HTTP-AUTH) folks.  From a quick read I found that the I-D
picked the "keep backslash as is" approach between client and proxy,
trimming \\ and \" only at the RADIUS server.

The other DIGEST-MD5 parameters are as always confusing, I don't see
anything related to SASLprep in the draft (it's based on 2617).  It
mentions 2069 backwards compatibility based on the absence of "QoP",
I'm not sure if that's correct for "md5-sess" without "QoP".

The draft says that the length of NC is 10, shouldn't that be 8 ?

The first example has no CNONCE and no NC, my script claims that this
is a fatal error for qop=auth, isn't it ?  RFC 2617 says that it MUST
be sent for a non-empty qop.

The password for the 4590 examples isn't shown, therefore I'm unable
to check them, even after adjusting the code to treat qop=auth without
CNONCE as 2069 fallback.  Should I treat CNONCE as empty and make up
an NC 00000001 ?

Without SASLprep the draft IMO needs some "I18N considerations" about
non-ASCII user names and passwords as mandated by BCP 18 (RFC 2277).
Proposed Resolution: Discuss