Subject: RE: RFC 2617 Authentication and character sets revisited

From: Adam Roach <[email-masked]>
Date: Tue, 25 Nov 2003 22:40:19 -0600

Scott Lawrence [mailto:[email-masked]] wrote:

> "Yngve N. Pettersen (Developer Opera Software ASA)" 
> <[email-masked]> writes:
...
> > Personally, of course, I'd prefer that UTF-8 is endorsed as 
> > the character set.
> 
> Actually, I think this choice would be backward-compatible for those
> cases that have been working, and incompatible only with those that
> previously would have had interoperability problems anyway (passwords
> that had values outside the ASCII range).

I concur with this analysis. I also would strongly prefer the
specification of UTF-8 encoding for the purposes of calculating H(A1).

/a

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 26 Nov 2003 12:09:08 -0500

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/

---

From: Yngve Nysaeter Pettersen <[email-masked]>
Date: Wed, 26 Nov 2003 19:46:44 +0100

>    [RFC 2616], so for backward compatibility, servers MAY also

RFC 2616 or FRC 2617?

>    calculate the A1 value using any convention used prior to this

I think this will resolve the situation about passwords in digest 
authentication.

Should similar language be added about the digest username as well? Or 
should the RFC 2047 encoding be required for the username?

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer		             Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************