Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations
draft-ietf-httpbis-authscheme-registrations-10

[Ballot comment]

nitty nit nit: suggest s/defined in standards-track
RFCs/defined in RFCs/ might be better - reading this
I got a scare for a second that that registry might
require standards-track but it doesn't, its IETF
review.

[Ballot comment]
No sure yet at this point if this a COMMENT or DISCUSS. I'm waiting for the discussion.

Cut and paste from Sue Hares, OPS-DIR reviewer:
I am reviewing the following document: Susan Hares T 2013-12-17 draft-ietf-httpbis-authscheme-registrations-09

But the IESG write-up states the following should 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 (Peter Schoenmaker Ops-Dir reviewer)

* draft-ietf-httpbis-method-registrations (Michael Sneed, Ops-dir

* draft-ietf-httpbis-authscheme-registrations (Sue Hares Reviewer)


I am concerned about the breaking of the review of httpbis-authscheme-registrations away From the draft-ietf-httpbis-p7-auth and the draft-ietf-httpbis-method-registrations.  I have read all three drafts. 


So this is addressed to the reviewers of the httpbis documents for this week

Niclas Comstedt        T 2013-12-17 draft-ietf-httpbis-p1-messaging-25

Menachem Dodge        T 2013-12-17 draft-ietf-httpbis-p5-range-25

Lionel Morand          T 2013-12-17 draft-ietf-httpbis-p6-cache-25

Sarah Banks            T 2013-12-17 draft-ietf-httpbis-p2-semantics-25

Peter Schoenmaker      T 2013-12-17 draft-ietf-httpbis-p7-auth-25

Michael Sneed          T 2013-12-17 draft-ietf-httpbis-method-registrations-14

Susan Hares            T 2013-12-17 draft-ietf-httpbis-authscheme-registrations-09




Review of the draft-ietf-httpbis-authscheme-registrations

This document: Not ready.

Why not ready:  It is just really unclear exactly what IANA is putting in

Here’s my guess:  I think that  IANA is simply giving the following as potential WWW-Authenticate RFC values

WWW-Authenticate: [Basic]|[Bearer] |

                  [Digest] |[Negotiate]| [OAuth]


What’s the problem with reviewing just this document: Reviewing just this document is like tracing the validity of a string path that enters a wad of strings and exits it.  Without looking at the whole scheme, you cannot tell if this is reason.


I have reviewed the specification reference in draft-ietf-httpbis-authscheme-registrations.


1)      Basic: RFC 2617: section 2 (nothing) 

2)      Bearer: RFC 6750: bearers

Bearer authentication have 3 different bearer authentication schemes but no logging of which is used.  The errors (due to HTTP errors reporting) seem to merge several errors into the same error codes). Since this is an approved RFC,  why does IANA have error codes for the different Bearer schemes?

What level of this work is “just encode” and what level is updated to the latest in security handshaking schemes?  Should this be compared against the OASIS work to secure portions of the information? That is – authenticate who can have this piece of data using my HTTTP.

3)      Digest: RFC 2617:  Digest – Even for routing protocols (sometimes called security light) the digests have been considered weak.  What exactly the author is trying to suggest needs to be included in the registry is not clear.

4)      Negotiate: RFC 54559: Section 3: The author indicates that this breaks syntax by mixing Kerberos (connection-oriented) and expanding the syntax (Authenticate/Authorization) by not including the Kerberos gssapi-data in the initial WWW-Authenticate header.

It is entirely unclearly why this kludge in limited use is any more a kludge than the rest of the system.  The comment on non-context specific ignores the password/user digest issues of deployment

It is not clear why this needs to be noted in the IANA registration.

5)      OAuth: RFC5849: Section 3.5.1             

Authorization: OAuth realm="Example",

        oauth_consumer_key="0685bd9184jfhq22",

        oauth_token="ad180jjd733klru7",

        oauth_signature_method="HMAC-SHA1",

        oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",

        oauth_timestamp="137131200",

        oauth_nonce="4572616e48616d6d65724c61686176",

        oauth_version="1.0"

I have confirmed that referenced documents in  do reference these documents and have comments. However, unless I look at the wider context of these documents, I do not know if the IANA work is complete.


What bothers me in the macro-view:

However, I would like to comment on the protected space concept (Realm) and proxy-authenticate in the draft-ietf-httpbis-p4-auth. The practical implementation is impacted by the new world of VMs and shared information.

Respectfully, but

Sue Hares

IESG/Authors/WG Chairs:

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

We received the following comments/questions from the IANA's reviewer:


IANA notes that one of the actions in the IANA Considerations section is dependent upon the approval of another draft being considered by the IESG: draft-ietf-httpbis-p1-messaging.

IANA understands that, upon approval of this document, there is one action which IANA must complete.

First, a new registry, called the HTTP Authentication Scheme Registry, will be created via the approval of the document draft-ietf-httpbis-p7-auth.  This new registry has no initial registrations as a result of the potential approval of draft-ietf-httpbis-p7-auth.  The new registry is proposed to be located at:

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

The registration rule for this name space is defined by draft-ietf-httpbis-p7-auth as IETF Review as defined in RFC 5226.  Each registration is made up of a Authentication Scheme Name, a Reference and Notes for the registration.

This document appears to add new registrations to the empty registry created by draft-ietf-httpbis-p7-auth.

The current document requests that the following Authentication Scheme Names be added to the HTTP Authentication Scheme Registry, created via the approval of the document draft-ietf-httpbis-p7-auth:

+----------------+------------+-------------------------------------+
| Authentication | Reference  | Notes                              |
| Scheme Name    |            |                                    |
+----------------+------------+-------------------------------------+
| Basic          | [RFC2617], |                                    |
|                | Section 2  |                                    |
| Bearer        | [RFC6750]  |                                    |
| Digest        | [RFC2617], |                                    |
|                | Section 3  |                                    |
| Negotiate      | [RFC4559], | This authentication scheme violates |
|                | Section 3  | both HTTP semantics (being          |
|                |            | connection-oriented) and syntax    |
|                |            | (use of syntax incompatible with    |
|                |            | the WWW-Authenticate and            |
|                |            | Authorization header field syntax). |
| OAuth          | [RFC5849], |                                    |
|                | Section    |                                    |
|                | 3.5.1      |                                    |
+----------------+------------+-------------------------------------+

IANA understands that this is the only action 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:  (Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations) to Informational RFC


The IESG has received a request from the Hypertext Transfer Protocol Bis
WG (httpbis) to consider the following document:
- 'Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme
  Registrations'
  as Informational
RFC

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


  This document registers Hypertext Transfer Protocol (HTTP)
  authentication schemes which have been defined in standards-track
  RFCs before the IANA HTTP Authentication Scheme Registry was
  established.


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-authscheme-registrations/

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

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

1. Summary

Document: draft-ietf-httpbis-authscheme-registrations-08
Document Shepherd: Mark Nottingham
Responsible Area Director: Barry Leiba
Publication Type: Proposed Standard

This document registers Hypertext Transfer Protocol (HTTP) authentication
schemes which have been defined in standards-track RFCs before the IANA HTTP
Authentication Scheme Registry was established.

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 Working Group Last Call, with multiple reviewers. 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. The author has confirmed
that he has no direct, personal knowledge of IPR related to this document that
has not been disclosed.

4. Other Points

Downward references: None.

New registries created: None.

Updated registries: None.