Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-01.txt

From: [email-masked]
Date: Wed, 01 Jan 2014 09:40:57 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF.

        Title           : HTTP Digest Access Authentication
        Authors         : Rifaat Shekh-Yusef
                          David Ahrens
                          Sophie Bremer
	Filename        : draft-ietf-httpauth-digest-01.txt
	Pages           : 30
	Date            : 2014-01-01

Abstract:
   HTTP provides a simple challenge-response authentication mechanism
   that may be used by a server to challenge a client request and by a
   client to provide authentication information. This document defines
   the HTTP Digest Authentication scheme that may be used with the
   authentication mechanism.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-digest-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Wed, 1 Jan 2014 12:45:36 -0500

This new version includes two changes:
1. Incorporates the Hashed Username proposal.
2. Adds a new registry in the IANA section to register the hash algorithms.

Please, take a look and let us know if you have any comments.

Regards,
 Rifaat

On Wed, Jan 1, 2014 at 12:40 PM, <[email-masked]> wrote:

>  This draft is a work item of the Hypertext Transfer Protocol
> Authentication Working Group of the IETF.
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Michael Sweet <[email-masked]>
Date: Mon, 06 Jan 2014 10:27:06 -0500

Some quick comments...

In section 3.3 you use "that could be used by the server..." for the definitions of charset and userhash - that seems a bit too wishy-washy for a standards-track RFC.  Instead I would use "that is used by the server ...", along with making OPTIONAL all-caps, per RFC 2119:

   charset
      This is an OPTIONAL parameter that is used by the server to
      indicate the character encoding it supports for the username and
      password.

   userhash
      This is an OPTIONAL parameter that is used by the server to
      indicate that it supports username hashing.

Also, qop-options still has the RFC 2617 mix of optional and SHOULD.  Since RFC 2069 is long dead, it is probably better to simply say it is now RECOMMENDED and that the absence of values is for backwards compatibility with RFC 2069, e.g.:

   qop-options
     This RECOMMENDED directive is a quoted string of one or more
     tokens indicating the "quality of protection" values supported
     by the server.  The value "auth" indicates authentication; the
     value "auth-int" indicates authentication with integrity
     protection; see the descriptions below for calculating the
     response directive value for the application of this choice.
     If not present, the client MUST assume the server only supports
     the obsolete form of Digest authentication [RFC2069]. Unrecognized
     options MUST be ignored.

In section 3.4, there is still the same legacy wording for qop, and there is an extra space between "WWW-" and "Authenticate"; how about:

 qop
      Indicates what "quality of protection" the client has applied to
      the message. If present, its value MUST be one of the alternatives
      the server indicated it supports in the WWW-Authenticate header.
      These values affect the computation of the request-digest. Note
      that this is a single token, not a quoted list of alternatives as
      in WWW-Authenticate.  This directive SHOULD be used if the server
      provided a qop directive in the WWW-Authenticate header field. If not
      present, the server MUST assume that the client only supports the
      obsolete form of Digest authentication [RFC2069].

Also, charset and userhash use "optional" and "that could be used by ... that it supports". Since the client and server are not negotiating these things and the client is telling the server what it used, I would change them to:

   charset
      This OPTIONAL parameter is used by the client to indicate the
      character encoding used for the username and password.

   userhash
      This OPTIONAL parameter is used by the client to indicate that
      the username has been hashed.

In section 3.4.4, I'd prefer to make this conditionally required for the client (if it supports username hashing) rather than leaving it a recommendation - after all, if you actually go to the trouble of implementing userhash support, why wouldn't you use it?

In section 4, did we ever decide what to say about the Unicode normalization form? RFC 5198 (network unicode) is often referenced and uses NFC.

In section 5.1, the word "recommended" is used when talking about HTTPS, but there is no reference. How about:

    Digest authentication SHOULD be used over a secure channel like HTTPS [RFC2818].

(the reference will need to be updated soon, see my comment about HTTP/1.1 references)

In section 5.2, you don't mention username protection. Simple change:

   Digest Authentication offers no confidentiality protection beyond
   protecting the actual username and password. All of the rest of the
   request and response are available to an eavesdropper.

Also, there is a "should" in the last sentence that either needs capitalization, rewording, or removal:

               Any service in present use that uses Basic SHOULD be
   switched to Digest as soon as practical.

or:

               Digest can be used as a more secure alternative to Basic in
   existing services.

General: there are a bunch of RFC 2616 references that will need to be updated for the soon-to-be-published HTTP/1.1 RFCs.

> ftp://ftp.ietf.org/internet-drafts/

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 7 Jan 2014 08:31:30 -0500

Hi Michael,

Thanks for your thorough review and for these useful comments.
Please, take a look at my responses inline...

Regards,
 Rifaat

On Mon, Jan 6, 2014 at 10:27 AM, Michael Sweet <[email-masked]> wrote:

> Some quick comments...
>
> In section 3.3 you use "that could be used by the server..." for the
> definitions of charset and userhash - that seems a bit too wishy-washy for
> a standards-track RFC.  Instead I would use "that is used by the server
> ...", along with making OPTIONAL all-caps, per RFC 2119:
>
>    charset
> Ok.

> Also, qop-options still has the RFC 2617 mix of optional and SHOULD.
>  Since RFC 2069 is long dead, it is probably better to simply say it is now
> RECOMMENDED and that the absence of values is for backwards compatibility
> with RFC 2069, e.g.:
>

I meant to send a separate email to discuss the issue of RFC2069, but since
you raised it, I will discuss it here.
Should we just not worry about RFC2069 and remove any consideration for
backward compatibility with it?

> In section 3.4, there is still the same legacy wording for qop, and there
> is an extra space between "WWW-" and "Authenticate"; how about:
>
>  qop
> Also, charset and userhash use "optional" and "that could be used by ...
> that it supports". Since the client and server are not negotiating these
> things and the client is telling the server what it used, I would change
> them to:
>
>    charset
> Ok

>
> In section 3.4.4, I'd prefer to make this conditionally required for the
> client (if it supports username hashing) rather than leaving it a
> recommendation - after all, if you actually go to the trouble of
> implementing userhash support, why wouldn't you use it?
>
> Good point. I will change it to MUST.

>
> In section 4, did we ever decide what to say about the Unicode
> normalization form? RFC 5198 (network unicode) is often referenced and uses
> NFC.
>
> I remember some discussion on the mailing list, but if I remember
correctly I do not think that there was any conclusion to that discussion.

> Ok

> Good catch.

> I would probably remove that sentence.

> General: there are a bunch of RFC 2616 references that will need to be
> updated for the soon-to-be-published HTTP/1.1 RFCs.
>
> Ok.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 07 Jan 2014 10:35:59 -0500

Rifaat,

My responses are inline...

On Jan 7, 2014, at 8:31 AM, Rifaat Shekh-Yusef <[email-masked]> wrote:
> ... 
> I meant to send a separate email to discuss the issue of RFC2069, but since you raised it, I will discuss it here.
> Should we just not worry about RFC2069 and remove any consideration for backward compatibility with it?

RFC 2069 was/is standards-track, obsoleted by 2617. I'm not sure what the IETF rules are for deprecation/breaking backwards compatibility with prior standards track work.

The "safe" path is to REQUIRE qop-options on the server and make qop conditionally required based on the presence of the qop-options parameter in WWW-Authenticate.  That preserves backwards compatibility with RFC 2069-based servers while requiring the new form in current servers.

> I remember some discussion on the mailing list, but if I remember correctly I do not think that there was any conclusion to that discussion.

It is very important that we say something here, otherwise Unicode names and passwords will not be reliable.  If we don't want to standardize on a single normalization form for the protocol, we need to say something about requiring the server to do normalization and why.