Re: RFC 2617 Authentication and character sets revisited

  In keeping with Jims' admonition to get text this week, I propose
  the following edit for 2616++ to clarify the Digest password
  encoding issue; immediately following the ABNF for passwd in
  3.2.2.2, add:

   The passwd value SHOULD be encoded using UTF-8 [ref] for input to
   the hash.  The encoding of the passwd value was not specified by
   [RFC 2616], so for backward compatibility, servers MAY also
   calculate the A1 value using any convention used prior to this
   specification.

  So that section would read:

3.2.2.2 A1

   If the "algorithm" directive's value is "MD5" or is unspecified, then
   A1 is:

      A1       = unq(username-value) ":" unq(realm-value) ":" passwd

   where

      passwd   = < user's password >

   The passwd value SHOULD be encoded using UTF-8 [ref] for input to
   the hash.  The encoding of the passwd value was not specified by
   [RFC 2616], so for backward compatibility, servers MAY also
   calculate the A1 value using any convention used prior to this
   specification.

   If the "algorithm" directive's value is "MD5-sess", then A1 is
   calculated only once - on the first request by the client following
   receipt of a WWW-Authenticate challenge from the server.  It uses the
   server nonce from that challenge, and the first client nonce value to
   construct A1 as follows:

      A1       = H( unq(username-value) ":" unq(realm-value)
                     ":" passwd )
                     ":" unq(nonce-value) ":" unq(cnonce-value)

   This creates a 'session key' for the authentication of subsequent
   requests and responses which is different for each "authentication
   session", thus limiting the amount of material hashed with any one
   key.  (Note: see further discussion of the authentication session in
   section 3.3.) Because the server need only use the hash of the user
   credentials in order to create the A1 value, this construction could
   be used in conjunction with a third party authentication service so
   that the web server would not need the actual password value.  The
   specification of such a protocol is beyond the scope of this
   specification.

-- 
Scott Lawrence        
  http://skrb.org/scott/

Received on Wednesday, 26 November 2003 12:09:18 UTC