HTTP Digest Access Authentication
draft-ietf-httpauth-digest-19

[Ballot comment]
Just a few minor comments:

3.3, domain: "If the URI is an abs_path..."

Should that be "path-absolute", in keeping with the reference to 3986?

3.6, paragraph 4: "Because the client is REQUIRED to return..."

The use of a 2119 keyword in a dependent clause seems odd.

5.1:  "Digest authentication SHOULD be used over a secure channel like HTTPS"

Does this mean that, if you have a secure channel you should use digest, or if you use digest you should use a a secure channel? I assume the second, but the sentence can be parsed either way.

[Ballot comment]
I'm a yes on this, not because it's great
technology (it just isn't;-), but because it is a
valiant effort to do responsible updates to a
scheme that is used somewhat. Thanks for doing
the work.

- The intro could usefully say that this extends
but is generally backwards compatible with 2617
if you don't use any new stuff and include a
pointer to appendix A as well.

- p5, "nonce": "data string" is an odd
combination

- p6, "stale": Is "TRUE" the literal value? What
if it's "1" or "y" - just wondering in case
current code does something there. Section 3.3
(and elsewhere) uses "true" and "false" which
aren't the same as TRUE and FALSE (or are they?)
It'd be good to be consistent or to say that
we're not being consistent, presumably for
historical reasons.

- end of 3.4: is there a specific section of 7234
that's most relevant? If so, good to say so.

- 5.3, you could maybe add a reference to RFC7486
at the end of the 1st para (that is blatent
self-advertisement, but I couldn't resist:-)

- 5.6, is the "note" about Basic still true? I
thought Julian or someone tested it and found it
not quite so bad?

- I think something went wrong with the secdir
review [1] but I'd also encourage us to try to
bottom out on Hilarie's comments. There may be
something there that could be used, without any
damage to backwards compatibility, which would be
interesting.

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05621.html

[Ballot comment]
A simple comment to resolve, I would think - avoid using actual DNS domains. Please use example.com, or at least provide rational as to why example.com/net can't be used.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-httpauth-digest-15.  Please see the review below and report any inaccuracies as soon as possible.

IANA's reviewer has a question about the action requested in the IANA Considerations section of this document.

QUESTION: Where should the new registry be located? Should it be created at a new URL? If so, should it be listed under an existing category at http://www.iana.org/protocols, or a new one?  If the latter, what should be the name of the category? Should the webpage have the same title? (This is typically, but not always, the case.)

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, IANA will create the HTTP Digest Hash Algorithms registry at a location to be determined (see above). The registry will be maintained via the Specification Required policy defined in RFC 5226.

Initial registrations:

+----------------+-------------+----------------+
| Hash Algorithm | Digest Size | Reference |
+----------------+-------------+----------------+
| MD5 | 128 | [ RFC-to-be ] |
| SHA-512-256 | 256 | [ RFC-to-be ] |
| SHA-256 | 256 | [ RFC-to-be ] |
+----------------+-------------+----------------+

Second, in the HTTP Authentication Schemes registry at

https://www.iana.org/assignments/http-authschemes/

a new scheme will be registered as follows:

Authentication Scheme Name: Digest
Reference: [ RFC-to-be ]
Notes:

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (HTTP Digest Access Authentication) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol
Authentication WG (httpauth) to consider the following document:
- 'HTTP Digest Access Authentication'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-04-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 can be used with the HTTP
  authentication mechanism.

Editorial Note (To be removed by RFC Editor before publication)

  Discussion of this draft takes place on the HTTPAuth working group
  mailing list (http-auth@ietf.org), which is archived at [1].




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ballot/


No IPR declarations have been submitted directly on this I-D.

Authors are Rifaat Shekh-Yusef, David Ahrens, and Sophie Bremer. Kathleen
Moriarty is the responsible Area Director. Yoav Nir is the document
shepherd.

Summary
  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 can be used with the HTTP
  authentication mechanism.
     
Review and Consensus
  This document is (along with the already-approved basicauth-update)
  part of a set of documents that will collectively replace RFC 2617. 
  As such, for the most part it describes existing practice, with the
  addition of a few things:
    o New algorithms: SHA2-256 and SHA2-512/256.
    o Internationalized character set support.
    o username hashing for enhanced privacy,
 
  While the working group was chartered to add the new algorithms and
  internationalization support, the addition of user name hashing is
  not in the charter. The group was specifically polled about whether
  we wanted to add features to a legacy protocol that is anyway
  vulnerable to dictionary attacks. The group consensus was that this
  should be done.
 
  With version -15 it is the consensus of the HTTP-Auth working group
  that this document is fit to be published as a standards-track RFC.
       
Intellectual Property
  All authors have confirmed that they are not aware of any undisclosed
  IPR associated with this document. There have been no IPR disclosures.
 
Other Issues
  None