Hypertext Transfer Protocol (HTTP/1.1): Authentication
draft-ietf-httpbis-p7-auth-26

[Ballot comment]
*) I'll not repeats the OWS discuss point from p1.  If it gets changed there I assume it will get changed here.  If not then this can be ignored.

0) Abstract: Maybe would add stateless in front of protocol in the description.

1) So I guess the reason we're not saying TLS is an MTI with basic/digest is that that's getting done in an httpauth draft?  It really wouldn't hurt to duplicate that while we're getting the other one done (I know you *don't* want a reference to that draft).

[Ballot comment]
Kathleen Moriarty made a Gen-ART review which raised comments which I believe would be useful to consider (but we've not seen a reply yet).

Minor issues:

In section 2.1, in third to last paragraph, why is ought used here instead of a keyword?  This is a point that could help with interoperability, so I think a keyword is important.  Unless there is another error message, one should be provided when the role access requirements are not met.  Users would expect this functionality.

Nits/editorial comments:

Section 3.2.1 - please fix the run-on sentence, the first one as it is difficult to read.  Suggestion:
From:
If a server receives a request for an access-protected object, and an
  acceptable Authorization header is not sent, the server responds with
  a "401 Unauthorized" status code, and a WWW-Authenticate header as
  per the framework defined above, which for the digest scheme is
  utilized as follows:
To:
If a server receives a request for an access-protected object and an
  acceptable Authorization header is not sent.  The server responds with
  a "401 Unauthorized" status code and a WWW-Authenticate header as
  per the framework defined above.  For the digest scheme, this is
  utilized as follows:

Section 4.1, second to last paragraph.  Please consider rewording the content in parenthesis, it is difficult to read and probably found just be a separate sentence rather than included with the prior sentence in parenthesis.
"If a request is authenticated and a realm specified, the same
  credentials are presumed to be valid for all other requests within
  this realm (assuming that the authentication scheme itself does not
  require otherwise, such as credentials that vary according to a
  challenge value or using synchronized clocks)."

Section 4.2, second paragraph, consider breaking the following sentence into two:
From:
However, if a recipient proxy needs to obtain its
  own credentials by requesting them from a further outbound client, it
  will generate its own 407 response, which might have the appearance
  of forwarding the Proxy-Authenticate header field if both proxies use
  the same challenge set.
To:
However, if a recipient proxy needs to obtain its
  own credentials by requesting them from a further outbound client, it
  will generate its own 407 response.  This might have the appearance
  of forwarding the Proxy-Authenticate header field if both proxies use
  the same challenge set.

Section 4.4, the last paragraph could be read more clearly with the following change:
From:
This header field contains two challenges; one for the "Newauth"
  scheme with a realm value of "apps", and two additional parameters
  "type" and "title", and another one for the "Basic" scheme with a
  realm value of "simple".
To:
This header field contains two challenges; one for the "Newauth"scheme
with a realm value of "apps" and two additional parameters
  "type" and "title", and the second for the "Basic" scheme with a
  realm value of "simple".

Section 6: Security Considerations
Could you add in text to inform developers that content should not be accessed before authentication occurs when required?  I know this sounds obvious, but I recently ran into this issue.  On a Mac, I am able to see that the application server/database information is actually loaded before I authenticate (sure there is a SQL injection happening here too) and the screen is slightly greyed out.  On a PC, it appears to block access, but this is a display thing rather than requiring the authentication to actually work prior to serving content.
Perhaps something like the following:

When a web service is configured to use authentication, content from the application server requiring authentication MUST not be accessed until the authentication has completed successfully.

[Ballot comment]
COMMENT 1:
In Section 3.1, suggest clarifying:

OLD: "The origin server MUST send a WWW-Authenticate ... target resource."

NEW: "The origin server MUST send a WWW-Authenticate ... target resource. (If the server is unwilling to grant access for any credentials, it should instead use the 403 (Forbidden) status code.)"

[Ballot comment]


- 2.2: shouldn't there be some mention of how realms map to
web-origins here? I don't necessarily mean in a normative
manner, but to explain.

- 4.2: I didn't find the description of chains of proxies
very clear. An example would help I think.  Although it looks
like chains of proxies all doing 407 are not very well
defined - is that fair?

- Please check the secdir review. [1] I agree with the
comment that this really should have some mention of using
TLS to protect basic/digest, even if that ought also be
elsewhere.

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

acker.
IANA Actions - YES

NOTE:
The authors have confirmed that the new requested registry is
a new top-level registry. The new URL will be:

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

Thank you,

Pearl Liang
ICANN/IANA


On Tue Nov 05 08:59:31 2013, iesg-secretary@ietf.org wrote:
> Evaluation for  can be found at
> http://datatracker.ietf.org/doc/draft-ietf-httpbis-p7-auth/
>
> Last call to expire on: 2013-11-04 00:00
>
>
>        Please return the full line with your position.
>
>                      Yes  No-Objection  Discuss  Abstain
> Barry Leiba          [ X ]    [  ]      [  ]    [  ]
>
>
> "Yes" or "No-Objection" positions from 2/3 of non-recused ADs,
> with no "Discuss" positions, are needed for approval.
>
> DISCUSSES AND COMMENTS
> ===========
> ?
> ---- following is a DRAFT of message to be sent AFTER approval ---
> From: The IESG
> To: IETF-Announce
> Cc: RFC Editor ,
>    httpbis mailing list ,
>    httpbis chair
> Subject: Protocol Action: 'Hypertext Transfer Protocol (HTTP/1.1):
> Authentication' to Proposed Standard (draft-ietf-httpbis-p7-auth-
> 24.txt)
>
> The IESG has approved the following document:
> - 'Hypertext Transfer Protocol (HTTP/1.1): Authentication'
>  (draft-ietf-httpbis-p7-auth-24.txt) as Proposed Standard
>
> This document is the product of the Hypertext Transfer Protocol Bis
> Working Group.
>
> The IESG contact persons are Barry Leiba and Pete Resnick.
>
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-httpbis-p7-auth/
>
>
>
>
> Technical Summary
>
> The Hypertext Transfer Protocol (HTTP) is an application-level
> protocol for
> distributed, collaborative, hypermedia information systems. This
> document
> defines the HTTP Authentication framework.
>
> Note that this document is part of a set, which should be reviewed
> together:
>
> * draft-ietf-httpbis-p1-messaging
> * draft-ietf-httpbis-p2-semantics
> * draft-ietf-httpbis-p4-conditional
> * draft-ietf-httpbis-p5-range
> * draft-ietf-httpbis-p6-cache
> * draft-ietf-httpbis-p7-auth
> * draft-ietf-httpbis-method-registrations
> * draft-ietf-httpbis-authscheme-registrations
>
>
> Review and Consensus
>
> As chartered, this work was very constrained; the WG sought only to
> clarify
> RFC2616, making significant technical changes only where there were
> considerably interoperability or security issues.
>
> While the bulk of the work was done by a core team of editors, it has
> been
> reviewed by a substantial number of implementers, and design issues
> enjoyed
> input from many of them.
>
> It has been through two Working Group Last Calls, with multiple
> reviewers each
> time. We have also discussed this work with external groups (e.g., the
> W3C TAG).
>
>
> Personnel
>
> Document Shepherd: Mark Nottingham
> Responsible Area Director: Barry Leiba
>
>

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-httpbis-p7-auth-24.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there are three actions which IANA must complete. The designated expert for Permanent Message Header Field Names must approve the new action.

First, a new registry called the HTTP Authentication Scheme Registry will be created at

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

The registration rule for this name space is IETF Review as defined in RFC 5226.  Each registration is made up of an authentication scheme name, notes and a reference.

There are no initial registrations in this new registry.

Second, in the HTTP Status Code Registry, located at:

http://www.iana.org/assignments/http-status-codes/

these values will be updated as follows:

+-------+-------------------------------+-------------+
| Value | Description                  | Reference  |
+-------+-------------------------------+-------------+
| 401  | Unauthorized                  |[ RFC-to-be ]|
| 407  | Proxy Authentication Required |[ RFC-to-be ]|
+-------+-------------------------------+-------------+

Third, in the Permanent Message Header Field Names registry in the Message Headers page at

http://www.iana.org/assignments/message-headers/

the following message headers will be updated to reflect the new information provided below:

+---------------------+----------+----------+-------------+
| Header Field Name  | Protocol | Status  | Reference  |
+---------------------+----------+----------+-------------+
| Authorization      | http    | standard |[ RFC-to-be ]|
| Proxy-Authenticate  | http    | standard |[ RFC-to-be ]|
| Proxy-Authorization | http    | standard |[ RFC-to-be ]|
| WWW-Authenticate    | http    | standard |[ RFC-to-be ]|
+---------------------+----------+----------+-------------+

IANA understands that these actions are the only ones required to be completed upon approval of this document.

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:  (Hypertext Transfer Protocol (HTTP/1.1): Authentication) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol Bis
WG (httpbis) to consider the following document:
- 'Hypertext Transfer Protocol (HTTP/1.1): 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 2013-11-04. 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


  The Hypertext Transfer Protocol (HTTP) is an application-level
  protocol for distributed, collaborative, hypermedia information
  systems.  This document defines the HTTP Authentication framework.


Note that this document is part of a set, which should be reviewed together:

* draft-ietf-httpbis-p1-messaging
* draft-ietf-httpbis-p2-semantics
* draft-ietf-httpbis-p4-conditional
* draft-ietf-httpbis-p5-range
* draft-ietf-httpbis-p6-cache
* draft-ietf-httpbis-p7-auth
* draft-ietf-httpbis-method-registrations
* draft-ietf-httpbis-authscheme-registrations

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p7-auth/

Once IESG evaluation begins, IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p7-auth/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1398/

1. Summary

Document: draft-ietf-httpbis-p7-auth-24
Document Shepherd: Mark Nottingham
Responsible Area Director: Barry Leiba
Publication Type: Proposed Standard

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
distributed, collaborative, hypermedia information systems. This document
defines the HTTP Authentication framework.

Note that this document is part of a set, which should be reviewed together:

* draft-ietf-httpbis-p1-messaging
* draft-ietf-httpbis-p2-semantics
* draft-ietf-httpbis-p4-conditional
* draft-ietf-httpbis-p5-range
* draft-ietf-httpbis-p6-cache
* draft-ietf-httpbis-p7-auth
* draft-ietf-httpbis-method-registrations
* draft-ietf-httpbis-authscheme-registrations

2. Review and Consensus

As chartered, this work was very constrained; the WG sought only to clarify
RFC2616, making significant technical changes only where there were
considerably interoperability or security issues.

While the bulk of the work was done by a core team of editors, it has been
reviewed by a substantial number of implementers, and design issues enjoyed
input from many of them.

It has been through two Working Group Last Calls, with multiple reviewers each
time. We have also discussed this work with external groups (e.g., the W3C TAG).

3. Intellectual Property

There are no IPR disclosures against this document (one was previously made,
but "removed at the submitter's request"). The authors have confirmed that they
have no direct, personal knowledge of IPR related to this document that has not
been disclosed.

4. Other Points

Downward references: None.

New registries created:

* The Authentication Scheme Registry policy is IETF Review. This policy was
  chosen to ensure adequate security review.

Updated registries: None.