IETF Proceedings

IETF-87 Proceedings

Introduction | Area, Working Goup & BoF Reports | Plenaries | Training | Internet Research Task Force

Hypertext Transfer Protocol Authentication (httpauth) (WG)

Minutes | Audio Archives | Jabber Logs | Mailing List Archives

Additional information is available at tools.ietf.org/wg/httpauth

Chair(s):

Security Area Area Director(s):

Security Area Advisor

Sean Turner

Meeting Slides:

Blue Sheets:

bluesheets-87-httpauth-01.pdf

Internet-Drafts:

An Encoding Parameter for HTTP Basic Authentication (20290 bytes)
Mutual Authentication Protocol for HTTP (118282 bytes)
HTTP Authentication Extensions for Interactive Clients (49730 bytes)
Salted Challenge Response (SCRAM) HTTP Authentication Mechanism (39866 bytes)
An Encoding Mechanism for HTTP Digest Authentication (9691 bytes)
HTTP Origin-Bound Authentication (HOBA) (59110 bytes)
RESTful Authentication Pattern for the Hypertext Transport Protocol (HTTP) (59168 bytes)
HTTP Digest Update (19715 bytes)
The 'Basic' HTTP Authentication Scheme (17217 bytes)

No Request for Comments

Charter (as of 2013-03-27):

Authentication of users to servers over HTTP has always been a weak
point in web services. The current HTTP authentication mechanisms,
basic and digest, pass the credentials in the clear or employ weak
algorithms and are considered to be insecure today. Authentication
through non-standard web forms is much more commonly used, but also
pass the credentials in the clear. There is a need for improved
mechanisms that can replace or augment HTTP authentication without the
need to rely on transport layer security. Only HTTP authentication is
in scope for this WG; form-based or "web" authentication is out of
scope.

The httpauth WG will be a short-lived working group that will document
a small number of HTTP user authentication schemes that might offer
security benefits, and that could, following experimentation, be
widely adopted as standards-track schemes for HTTP user
authentication. Each of these RFCs will be Informational or
Experimental, and should include a description of when use of its
mechanism is appropriate, via a use-case or other distinguishing
characteristics. Standards track solutions for HTTP Authentication
schemes are out of scope, as none of the proposals are expected to be
sufficiently widely deployed to warrant that status before the WG
closes.

All schemes to be developed in the httpauth WG must be usable with the
existing HTTP authentication framework, or with evolutions of that
framework as developed in the httpbis WG. That is, the evolution of
the HTTP authentication framework is to be done in the httpbis WG and
not in the httpauth WG.

The httpauth WG will work closely with the httpbis WG to ensure that
the outcomes from the httpauth WG do not conflict with work done
elsewhere.

The drafts currently under consideration as WG items include:

- draft-williams-http-rest-auth
- draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension
- draft-farrell-httpbis-hoba
- draft-montenegro-httpbis-multilegged-auth
- draft-melnikov-httpbis-scram-auth

The WG will produce two standards track documents that will obsolete
the basic and digest schemes defined in RFC 2617 taking into account
errata on that specification.

For the digest scheme, the new specification will incorporate "more
modern" algorithm agility and internationalization support, which
requires input from internationalization experts.
draft-ahrens-httpbis-digest-auth-update documents one possible
approach that the WG could adopt and modify as it sees fit.

For the basic scheme, no technical changes are envisaged other than to
handle internationalization of usernames and passwords. The goal is
to improve the scheme's documentation and to obsolete RFC 2617, which
has some significant flaws that have emerged through 13 years of
experience.

The WG is not required to merge all proposals into one. The goal is
not to produce "perfect" mechanisms, but to review and improve
proposals and to quickly produce stable specifications for the purpose
of obtaining implementation and deployment experience. The working
group will then close, and any further culling or refinement of the
experimental mechanisms will be done in another context.

It is expected that the market/community will select which if any of
the RFCs developed might be worth progressing on the standards-track
at a later date, in a different WG.

Adoption of additional work items is not expected and will require a
re-charter.

The following are explicitly out of scope:

- changes to TLS
- changes to HTTP, except for those made in the httpbis WG
- definition of authentication mechanisms that do not work with
the HTTP authentication framework
- authentication schemes that distinguish between devices and humans
- authentication schemes that cannot be sensibly used for and
by humans
- "web" authentication that is not HTTP authentication