draft-ietf-httpauth-rest-auth-00.txt   draft-ietf-httpauth-rest-auth-01.txt 
Network Working Group N. Williams Network Working Group N. Williams
Internet-Draft Cryptonector Internet-Draft Cryptonector
Intended status: Informational August 14, 2013 Intended status: Informational August 14, 2013
Expires: February 15, 2014 Expires: February 15, 2014
RESTful Authentication Pattern for the Hypertext Transport Protocol RESTful Authentication Pattern for the Hypertext Transport Protocol
(HTTP) (HTTP)
draft-ietf-httpauth-rest-auth-00 draft-ietf-httpauth-rest-auth-01
Abstract Abstract
This document proposes a "RESTful" pattern of authentication for This document proposes a "RESTful" pattern of authentication for
HTTP/1.0, 1.1, and 2.0. The goal is to make it easy to add HTTP/1.0, 1.1, and 2.0. The goal is to make it easy to add
authentication mechanisms to HTTP and to make it easy to implement authentication mechanisms to HTTP applications and to make it easy to
them even without much help from the HTTP stack (though it is best to implement them even without much help from the HTTP stack (though it
integrate authentication into the stack, of course). is best to integrate authentication into the stack, of course).
Another goal is to make it easy to reuse existing authentication
mechanisms by allowing the user (that is, the server's operators) to
choose what concrete authentication mechanism(s) to use.
Among other benefits of RESTauth: it is orthogonal to "HTTP routers" Among other benefits of RESTauth: it is orthogonal to "HTTP routers"
and proxies, it results in session Uniform Resource Identifiers and proxies, it results in session Uniform Resource Identifiers
(URIs) that can be DELETEd to logout, naturally supports multi-legged (URIs) that can be DELETEd to logout, naturally supports multi-legged
authentication schemes, and it can be universally implemented on the authentication schemes, naturally supports clustering, and can be
server side with the Common Gateway Interface (CGI) and FastCGI. universally implemented on the server side with such
server<->application interfaces as the Common Gateway Interface (CGI)
and FastCGI, among others.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 3, line 8 skipping to change at page 2, line 20
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Protocol Outline . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. API-Imposed Constraints . . . . . . . . . . . . . . . . . 5 1.1.1. Authentication Infrastructure and Credentials Reuse . . . 5
2. Conventions used in this document . . . . . . . . . . . . 7 1.2. Protocol Outline . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3. API-Imposed Constraints . . . . . . . . . . . . . . . . . 7
3.1. Negotiable Parameters . . . . . . . . . . . . . . . . . . 8 1.4. Conventions used in this document . . . . . . . . . . . . 7
3.1.1. Strong Binding to TLS . . . . . . . . . . . . . . . . . . 9 2. Alternatives . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. WWW-Authenticate Header Value Prefix Syntax . . . . . . . 9 2.1. In-band HTTP Authentication . . . . . . . . . . . . . . . 8
3.1.3. WWW-ChannelBinding-Types Header . . . . . . . . . . . . . 10 2.2. Out-of-Band Bearer Token Mechanisms . . . . . . . . . . . 9
3.1.4. WWW-ChannelBinding-Type Header . . . . . . . . . . . . . . 10 2.3. Authentication in TLS . . . . . . . . . . . . . . . . . . 9
3.1.5. WWW-SessionBinding-Type Header . . . . . . . . . . . . . . 10 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.6. WWW-ReplayProtection Header . . . . . . . . . . . . . . . 10 3.1. Negotiable Parameters . . . . . . . . . . . . . . . . . . 10
3.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 10 3.1.1. Strong Binding to TLS . . . . . . . . . . . . . . . . . . 11
3.2.1. One Round Trip Optimization: Challenges Borne in 3.1.2. WWW-Authenticate Header Value Prefix Syntax . . . . . . . 11
WWW-Authenticate Headers . . . . . . . . . . . . . . . . . 11 3.1.3. WWW-ChannelBinding-Types Header . . . . . . . . . . . . . 12
3.3. Session Binding Types: Cookie, Session URI, and MAC . . . 12 3.1.4. WWW-ChannelBinding-Type Header . . . . . . . . . . . . . . 12
3.3.1. The New WWW-Session-URI Header . . . . . . . . . . . . . . 12 3.1.5. WWW-SessionBinding-Type Header . . . . . . . . . . . . . . 12
3.3.2. The New WWW-Session-MAC Header . . . . . . . . . . . . . . 12 3.1.6. WWW-ReplayProtection Header . . . . . . . . . . . . . . . 12
3.3.3. A MAC Trailer?? . . . . . . . . . . . . . . . . . . . . . 13 3.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 12
4. Representation of Authenticated Session Resources . . . . 14 3.2.1. One Round Trip Optimization: Challenges Born in
5. HTTP "Routing" and Authentication . . . . . . . . . . . . 15 WWW-Authenticate Headers . . . . . . . . . . . . . . . . . 13
6. In-band HTTP Authentication Alternatives . . . . . . . . . 16 3.3. Session Binding Types: Cookie, Channel Bound Session
7. Sample/Potential RESTauth Authentication Mechanisms . . . 17 URI, and MAC . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. OAuth via RESTauth . . . . . . . . . . . . . . . . . . . . 17 3.3.1. The New WWW-Session-URI Header . . . . . . . . . . . . . . 14
7.1.1. OAuth 1.0 . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3.2. The New WWW-Session-MAC Header . . . . . . . . . . . . . . 14
7.1.2. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3.3. To MAC or not to MAC; A MAC Trailer?? . . . . . . . . . . 15
7.2. Adapting SSHv2 Authentication Mechanisms to RESTauth . . . 17 4. Representation of Authenticated Session Resources . . . . 16
7.2.1. RESTauth Mechanism Names for SSHv2 Userauth Methods . . . 17 5. Session URI Origin and Scope . . . . . . . . . . . . . . . 17
7.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. HTTP "Routing" and Authentication . . . . . . . . . . . . 18
7.2.3. "Session ID" . . . . . . . . . . . . . . . . . . . . . . . 18 7. Actual Authentication Mechanisms . . . . . . . . . . . . . 19
7.3. Adapting IKEv2 Authentication Mechanisms to RESTauth . . . 18 7.1. OAuth via RESTauth . . . . . . . . . . . . . . . . . . . . 19
7.1.1. OAuth 1.0 . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.2. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. Adapting SSHv2 Authentication Mechanisms to RESTauth . . . 19
7.2.1. RESTauth Mechanism Names for SSHv2 Userauth Methods . . . 20
7.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2.3. "Session ID" . . . . . . . . . . . . . . . . . . . . . . . 20
7.3. Adapting IKEv2 Authentication Mechanisms to RESTauth . . . 20
7.3.1. Adapting IKEv2 Password Authenticated Connection 7.3.1. Adapting IKEv2 Password Authenticated Connection
Establishment (PACE) to RESTauth . . . . . . . . . . . . . 18 Establishment (PACE) to RESTauth . . . . . . . . . . . . . 20
7.4. Using SASL Authentication Mechanisms with RESTauth . . . . 18 7.4. Using SASL Authentication Mechanisms with RESTauth . . . . 21
7.4.1. Using SCRAM in RESTauth . . . . . . . . . . . . . . . . . 19 7.4.1. Using SCRAM in RESTauth . . . . . . . . . . . . . . . . . 21
7.4.2. Using SCRAM with Round Trip Optimization in RESTauth . . . 20 7.4.2. Using SCRAM with Round Trip Optimization in RESTauth . . . 22
7.5. Using GSS-API Authentication Mechanisms with RESTauth . . 21 7.5. Using GSS-API Authentication Mechanisms with RESTauth . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 23 8. Implementation Advice . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . 24 8.1. Server-Side Implementation Advice . . . . . . . . . . . . 25
10. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1.1. Channel Binding on the Server Side . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . 26 8.1.2. Server Cluster / Routing Support . . . . . . . . . . . . . 25
11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 8.2. Client-Side Implementation Advice . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . . 26 8.2.1. Channel Binding on the Client Side . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . 29
11. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . 31
12.1. Normative References . . . . . . . . . . . . . . . . . . . 31
12.2. Informative References . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
We propose a pattern for HTTP [RFC2616] [XXX add reference to There is a great need for improved authentication options in HTTP
applications, both web browser and non-browser applications. At this
time there are a number of proposals being made in the HTTPauth
Working Group (WG). This proposal is just one of many.
Some of the goals of RESTauth are:
o an authentication protocol that reuses existing authentication
mechanisms -- in principle any and all mechanisms that we have in
the Internet protocols, including: SASL [RFC4422], GSS-API
[RFC2743], SSHv2 [RFC4251], IKEv2 [RFC5996], and other frameworks,
as well as ad-hoc mechanisms and/or standard mechanisms used
outside such frameworks;
o an authentication protocol that layers above HTTP so that
applications may implement it with little or no help from (read:
modifications to) the existing HTTP stacks that they use, all the
while not precluding native support for RESTauth by any HTTP
stack;
o an authentication protocol that supports a notion of sessions
without depending on having a single HTTP/TLS/TCP connection, and
which can be logged out explicitly, with explicit scoping of
sessions;
o an authentication protocol that naturally supports HTTP server-
side routing and clustering.
We propose a pattern for HTTP [RFC2616] [TODO: add reference to
HTTP/2.0 as well?] authentication mechanisms that, by being HTTP/2.0 as well?] authentication mechanisms that, by being
"RESTful", obtains a number of benefits: "RESTful", obtains these goals naturally.
o authentication that works with all versions of HTTP, even when the 1.1. Motivation
authentication mechanism requires multiple round trips;
o compatibility with "HTTP routing" by making no assumptions that Existing HTTP authentication mechanisms leave much to be desired.
related requests are sent over the same TCP/TLS connection;
o channel binding, or an HTTP session protocol such as Existing "in-band" mechanisms:
[I-D.williams-websec-session-continue-proto] (or any other meeting
requirements of HTTP session protocols, described in
[I-D.williams-websec-session-continue-prob]), can be used instead
of web cookies;
* a "session URI" results that can be used to multiplex multiple o Basic [RFC2617];
sessions onto the same TCP/TLS connections;
* a "session URI" results that can be DELETEd to effect logout; o Digest [RFC2617];
* a "session URI" results that has better security semantics than o Negotiate [RFC4559].
HTTP cookies;
o the ability to refer to multiple sessions in one request wherever Other existing mechanisms:
such a concept might be useful;
o can be implemented by any application without changes being o ad-hoc username-and-password authentication using HTML forms
required to any HTTP stack; POSTed over HTTP, plus web cookies;
* but it can also be implemented by the HTTP stack; o various bearer token mechanisms [TODO: add examples, such as
OAuth];
o on the server side this can be implemented entirely via CGI, o various non-bearer token mechanisms which are not generalized or
FastCGI, WSGI, servlets, and so on; generalizable to a larger universe of authentication mechanisms
[TODO: add examples, such as BrowserID].
o by its RESTful nature, multi-round trip authentication message In enterprise and educational settings it is common to need support
exchanges are naturally handled without making any changes to for Kerberos [RFC4120]. Of the above only Negotiate supports
HTTP. Kerberos meaningfully or at all, and does so badly, requiring re-
authentication for every request in many implementations (among other
problems; see Section 2.1 for more).
There are probably other benefits not listed above. Enterprises and educational settings also often have RADIUS
[RFC2865], often used via EAP [RFC3748]. These could be supported by
the generic security mechanism based on EAP, RADIUS, and SAML being
developed by the ABFAB WG [TODO: add references!]. These mechanisms
in particular will be difficult to use via Negotiate because they
involve multiple round trips, which Negotiate supports half-
heartedly; see Section 2.1.
1.1. Protocol Outline 1.1.1. Authentication Infrastructure and Credentials Reuse
All too commonly the community invents new authentication mechanisms
that require their own authentication infrastructures or bridges to
other mechanisms' existing infrastructures. This is a costly habit:
costly for those who must deploy these. A pattern of authentication
mechanism reuse would greatly improve this situation.
Most, if not all [classical, not quantum mechanical] authentication
mechanisms involve an exchange of one or more authentication
messages, accept as input the names of the peers being authenticated,
and on success output some information such as the names of the
authenticated peers, trust transit paths, session keys, and so on.
Actual mechanisms differ in minor details, such as which party sends
the first authentication mechanism (but there is always an initiator,
even if initiation is implied by connecting to a network, for example
as in EAP, which can be thought of as sending an empty initial
authentication message). These differences can be abstracted.
Indeed, we have at least _five_ authentication mechanism frameworks
in Internet protocols:
o Generic Security Services (GSS-API) [RFC2743];
o Simple Authentication and Security Layers (SASL) [RFC4422];
o Secure Shell version 2 (SSHv2) [RFC4251];
o Internet Key Exchange Protocol versions 1 and 2 (IKEv2) [RFC5996];
o Extensible Authentication protocol (EAP) [RFC3748].
Five authentication frameworks is an embarrassment of riches. And
yet we continually implement new ad-hoc authentication mechanisms --
this is not just embarrassing (it isn't really embarrassing, as it is
a part of the human condition that we continually re-invent things),
but wasteful, both because it means we fail to reuse existing code
and specifications, and because it means users are faced with costly
deployment headaches.
There are also many authentication mechanisms that support (or could
easily be extended to) federation.
The desire to re-invent authentication mechanisms (and frameworks) to
avoid technologies of the past (e.g., ASN.1 and its encoding rules)
or specific instantiations of them (e.g., GSS-API) is understandable,
but at the very least it should be made easy for developers to add
application support for arbitrary authentication mechanisms of any
given users choice. The only way to enable use of the user's choice
of authentication mechanism is through a common protocol that embeds
that authentication mechanism's messages, and that is _exactly_ what
RESTauth aims to be for HTTP.
1.2. Protocol Outline
1. initial authentication messages are POSTed to an agreed-upon or 1. initial authentication messages are POSTed to an agreed-upon or
indicated "login" resource... indicated "login" resource...
2. ....which then results in a new resource being created with the 2. ....which then results in a new resource being created with the
authentication reply message as the new resource's authentication reply message as the new resource's
representation. representation.
3. Thereafter any additional authentication message exchanges needed 3. Thereafter any additional authentication message exchanges needed
(for multi-legged mechanisms) are POSTed to the new resource (for multi-legged mechanisms) are POSTed to the new resource
skipping to change at page 5, line 27 skipping to change at page 7, line 15
5. Session URIs can be used to multiplex multiple sessions over the 5. Session URIs can be used to multiplex multiple sessions over the
same TCP/TLS connections, implement logout, and share sessions same TCP/TLS connections, implement logout, and share sessions
across multiple related servers. across multiple related servers.
Authentication using mechanisms that require that the server send the Authentication using mechanisms that require that the server send the
first authentication message is also possible, in either of two ways: first authentication message is also possible, in either of two ways:
the initial authentication message is sent in headers in a 401 the initial authentication message is sent in headers in a 401
response, or the client POSTs an empty first message to the login response, or the client POSTs an empty first message to the login
resource. resource.
1.2. API-Imposed Constraints 1.3. API-Imposed Constraints
To the extent that existing Application Programming Interfaces (APIs) To the extent that existing Application Programming Interfaces (APIs)
assume specific styles of HTTP authentication message flows, if we assume specific styles of HTTP authentication message flows, if we
want those APIs to support RESTauth backwards-compatibly, then those want those APIs to support RESTauth backwards-compatibly, then those
APIs may impose constraints on RESTauth. APIs may impose constraints on RESTauth.
For example, the Android Account Manager API assumes a single round For example, the Android Account Manager API assumes a single round
trip for authentication [XXX add reference!]. But the Android trip for authentication [TODO: add reference!]. But the Android
Account Manager could perform all but the last round trip on behalf Account Manager could perform all but the last round trip on behalf
of the application, then let the application perform the last round of the application, then let the application perform the last round
trip. In order for that to work we need the authentication message trip. In order for that to work we need the authentication message
exchange to be orthogonal to TCP/TLS connections -- that is, we need exchange to be orthogonal to TCP/TLS connections -- that is, we need
it to be possible to use multiple TCP/TLS connections for completing it to be possible to use multiple TCP/TLS connections for completing
a single authentication exchange. This is because the application a single authentication exchange. This is because the application
and the account manager will likely be using different TCP/TLS and the account manager will likely be using different TCP/TLS
connections. connections.
A typical constraining characteristic might be that an API assumes A typical constraining characteristic might be that an API assumes
the use of GET with tokens encoded into the URI or into a header, or the use of GET with tokens encoded into the URI or into a header, or
that the API makes no room for the use of headers in authentication that the API makes no room for the use of headers in authentication
message exchanges. message exchanges.
One way to work around such constraints may be to provide various One way to work around such constraints may be to provide various
options in RESTauth. Another might be to use OAuth 1.0 [RFC5849] or options in RESTauth. Another might be to use OAuth 1.0 [RFC5849] or
2.0 [I-D.ietf-oauth-v2] as a bridge: the API would use this framework 2.0 [RFC6749] as a bridge: the API would use this framework under the
under the covers then obtain OAuth credentials from the server that covers then obtain OAuth credentials from the server that the
the application can then use in any way that the API's form allows application can then use in any way that the API's form allows for.
for.
[[anchor1: TODO: Add a table/list of various known APIs and their [[anchor1: TODO: Add a table/list of various known APIs and their
characteristics that might constrain this and/or other frameworks.]] characteristics that might constrain this and/or other frameworks.]]
2. Conventions used in this document 1.4. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Alternatives
2.1. In-band HTTP Authentication
RESTauth is "out-of-band" in the sense that the authentication
messages are exchanged independently of the application's requests
for normal resources, with authentication tokens sent as message
bodies rather than as header values. Of course, RESTauth exchanges
may well (and often will) happen in the same TCP/TLS connection as
normal application requests, so RESTauth is not out-of-band in the
sense of using distinct transport connections. We use "out-of-band"
and "in-band" very loosely in this section.
There exist several "in-band" HTTP authentication alternatives where
the authentication message exchanges happen in the context of
application resources. Here the HTTP verb and resource are
application-specific and have nothing to do with authentication, and
the authentication messages are exchanged via HTTP request and
response headers with the server responding with a 401 status code
until authentication is complete.
The extant "Basic" and "DIGEST-MD5" [RFC2617] HTTP authentication
methods, as well as HTTP/Negotiate [RFC4559] are "in-band" HTTP
authentication methods.
In so far as an in-band authentication method results in a cookie or
session URI/ID the distinction between in-band and out-of-band is
almost trivial, as described above: authentication messages in
headers vs. bodies, and HTTP verb and URL. However, if in-line
authentication methods are strongly tied to the TCP/TLS connections
over which they were utilized then that is a big disadvantage over
RESTauth: each connection requires re-authenticating, and support for
HTTP routing schemes is not clear. Indeed, in common implementations
of HTTP Basic, Digest, and Negotiate, cases every request requires
authentication, which can be particularly costly for the Negotiate
case.
Additionally, Negotiate can require multiple round trips but provides
no mechanism for explicitly associating a given GSS-API security
context token with a given GSS-API security context: it has to be
assumed that all messages are serialized and only one multi-round
trip security context establishment can be ongoing in any given HTTP
connection.
Even if the only difference between in-band and out-of-band is a
trivial one, using the REST pattern means that authentication can be
implemented using with no help from the HTTP stack (even though it's
desirable to have it implemented within/by the HTTP stack), whereas
there may not be a way to implement in-band authentication without
help from the HTTP stack for some stacks.
2.2. Out-of-Band Bearer Token Mechanisms
Some HTTP/web authentication mechanisms used on the web involve out-
of-band (that is, outside the application's HTTP connections to a
server) communications to get bearer tokens, which the application
then includes in its HTTP requests (or perhaps it POSTs them to the
target server).
The main problem with bearer token systems is that they depend
utterly on the ability of TLS to authenticate services. Other
mechanisms, ones that depend on proof-of-secret/
private-key-possession, can often provide better security in the face
of weak TLS server authentication.
2.3. Authentication in TLS
A number of proposals use TLS [RFC5246] for authentication, some
adding extensions for sending user credentials encrypted to avoid the
overhead of renegotiation for privacy protection of user credentials.
There are several problems with user authentication in TLS:
o authentication mechanisms requiring multiple round trips are not
supported, and though there may not be any reason to not permit
them, in practice any extension of TLS handshakes to multiple
round trips is likely to cause much trouble in adapting existing
TLS implementations;
o new interfaces are required, affecting HTTP stacks and
applications both in addition to TLS itself (compare to RESTauth,
which requires only changes to applications, and which welcomes,
but does not require, support by HTTP stacks), and we know from
experience that it takes a long time to deploy solutions that
require modifying implementations of multiple network layers.
3. Protocol 3. Protocol
The are few normative protocol elements here besides the outline The are few normative protocol elements here besides the outline
given in Section 1. The normative protocol elements are: given in Section 1. The normative protocol elements are:
o the form of the WWW-Authenticate header values -in 401 responses- o the form of the WWW-Authenticate header values -in 401 responses-
for RESTauth mechanisms; for RESTauth mechanisms;
o several new headers for advertising negotiable parameters that are o several new headers for advertising negotiable parameters that are
orthogonal to WWW-Authenticate; orthogonal to WWW-Authenticate;
skipping to change at page 11, line 24 skipping to change at page 13, line 24
headers to inform the client of the need to authenticate in order to headers to inform the client of the need to authenticate in order to
access a given resource. For RESTauth mechanisms the WWW- access a given resource. For RESTauth mechanisms the WWW-
Authenticate header values MUST conform to the ABNF given in Authenticate header values MUST conform to the ABNF given in
Section 3.1.2. Section 3.1.2.
To proceed the client chooses a suitable authentication mechanism To proceed the client chooses a suitable authentication mechanism
(for which, presumably, it has credentials for a desired client (for which, presumably, it has credentials for a desired client
identity), possibly a channel binding type, possibly a session type, identity), possibly a channel binding type, possibly a session type,
and whether to use replay protection. and whether to use replay protection.
3.2.1. One Round Trip Optimization: Challenges Borne in WWW- 3.2.1. One Round Trip Optimization: Challenges Born in WWW-Authenticate
Authenticate Headers Headers
Some mechanisms may optimize the protocol flow by allowing the server Some mechanisms may optimize the protocol flow by allowing the server
to include challenges in the 401 response's WWW-Authenticate header to include challenges in the 401 response's WWW-Authenticate header
values. DIGEST-MD5 works this way, for example, sending a challenge values. DIGEST-MD5 works this way, for example, sending a challenge
nonce to be fed into the digest function (along with other client- nonce to be fed into the digest function (along with other client-
side inputs). side inputs).
RESTauth allows this, but this feature is OPTIONAL: it must always be RESTauth allows this, but this feature is OPTIONAL: it must always be
possible for a client to initiate RESTauth without first obtaining a possible for a client to initiate RESTauth without first obtaining a
challenge in a WWW-Authenticate header value, in which case the challenge in a WWW-Authenticate header value, in which case the
skipping to change at page 12, line 6 skipping to change at page 14, line 6
2. to support authentication mechanisms that require that the client 2. to support authentication mechanisms that require that the client
initiate authentication message exchanges. initiate authentication message exchanges.
A challenge may consist of a nonce, some encrypted or MACed nonce, a A challenge may consist of a nonce, some encrypted or MACed nonce, a
time-stamp, certificates and digital signatures, etcetera. The time-stamp, certificates and digital signatures, etcetera. The
server may include a login URI in challenge-laden WWW-Authenticate server may include a login URI in challenge-laden WWW-Authenticate
headers where the login URI encodes secure state regarding the headers where the login URI encodes secure state regarding the
challenge (e.g., the challenge encrypted in a symmetric key known challenge (e.g., the challenge encrypted in a symmetric key known
only to the server). only to the server).
3.3. Session Binding Types: Cookie, Session URI, and MAC 3.3. Session Binding Types: Cookie, Channel Bound Session URI, and MAC
A notion of session binding type is added for binding HTTP requests A notion of session binding type is added for binding HTTP requests
to specific RESTauth login sessions. Three types are provided: to specific RESTauth login sessions. Three types are provided:
Cookies The traditional HTTP cookie approach to session binding; Cookies The traditional HTTP cookie approach to session binding;
Session URI HTTP requests carry a WWW-Session-URI header identifying Session URI HTTP requests carry a WWW-Session-URI header identifying
the session(s) (similar to cookies, but without all the associated the session(s) (similar to cookies, but without all the associated
baggage); baggage);
skipping to change at page 13, line 9 skipping to change at page 15, line 9
[[anchor3: Describe the header, its values, algorithm agility, and [[anchor3: Describe the header, its values, algorithm agility, and
what the MAC is to be taken over. Note too that this cannot apply to what the MAC is to be taken over. Note too that this cannot apply to
request contents as we have to consider chunking, and besides, a MAC request contents as we have to consider chunking, and besides, a MAC
of contents really has to go as a trailer, not a header.]] of contents really has to go as a trailer, not a header.]]
[[anchor4: We may want to remove this anyways and leave it for a [[anchor4: We may want to remove this anyways and leave it for a
session continuation spec. Or we may want to require the use of session continuation spec. Or we may want to require the use of
HTTPS.]] HTTPS.]]
3.3.3. A MAC Trailer?? 3.3.3. To MAC or not to MAC; A MAC Trailer??
[[anchor5: ... This is only needed for RESTauth *without* TLS, which [[anchor5: ... This is only needed for RESTauth *without* TLS, which
will probably not be the common mode of use for RESTauth... unless we will probably not be the common mode of use for RESTauth... unless we
can produce a MAC trailer extension for HTTP/2.0, in which case this can produce a MAC trailer extension for HTTP/2.0, in which case this
may well become a common mode of RESTauth usage.]] may well become a common mode of RESTauth usage.]]
[[anchor6: We may want to remove this anyways and leave it for a [[anchor6: We may want to remove this anyways and leave it for a
session continuation spec. Or we may want to require the use of session continuation spec. Or we may want to require the use of
HTTPS.]] HTTPS.]]
skipping to change at page 15, line 5 skipping to change at page 17, line 5
user_id The authenticated user identity. user_id The authenticated user identity.
The server MAY exclude any part of this when the entity requesting a The server MAY exclude any part of this when the entity requesting a
session resource is the session's user. The server MUST exclude (or session resource is the session's user. The server MUST exclude (or
respond with 401) all of the session resource's representation when respond with 401) all of the session resource's representation when
the entity requesting it is not authenticated or authorized to see the entity requesting it is not authenticated or authorized to see
it. The server SHOULD exclude locally-determined authorization_data it. The server SHOULD exclude locally-determined authorization_data
and/or user_id information when the entity requesting the resource is and/or user_id information when the entity requesting the resource is
the session's user. the session's user.
5. HTTP "Routing" and Authentication 5. Session URI Origin and Scope
[[anchor9: TODO: Add a notion of session origin and scope. The
origin can probably be determined naturally from the session URI.
The scope should be set by the server. Perhaps we can also have the
scope reflected in the session URI's representation, which would
allow the scope of a session to change over time.]]
[[anchor10: Clearly, using a session from one origin at another will
require a channel binding verification operation. This will have to
be added.]]
6. HTTP "Routing" and Authentication
It is common to deploy HTTP services with load-balanced servers It is common to deploy HTTP services with load-balanced servers
behind a load balancer and TLS concentrator. Other techniques may behind a load balancer and TLS concentrator. Other techniques may
also result in a multiplicity of servers acting on behalf of a single also result in a multiplicity of servers acting on behalf of a single
service. The load balancers may even behave like routers and route service. The load balancers may even behave like routers and route
HTTP requests to the same server for all requests in a single HTTP requests to the same server for all requests in a single
connection, or even route HTTP requests according to the verb and connection, or even route HTTP requests according to the verb and
resource. It helps to be able to have a notion of authenticated resource. It helps to be able to have a notion of authenticated
sessions that can be referenced by all servers responding to a given sessions that can be referenced by all servers responding to a given
service name. service name.
skipping to change at page 16, line 5 skipping to change at page 19, line 5
methods for such signaling). methods for such signaling).
By using REST for the authentication message exchange we allow this By using REST for the authentication message exchange we allow this
disconnection between "session" and "connection", which therefore disconnection between "session" and "connection", which therefore
facilitates "routing" of HTTP requests and even off-loading of facilitates "routing" of HTTP requests and even off-loading of
authentication and/or session binding to HTTP "routers". authentication and/or session binding to HTTP "routers".
This approach should be flexible enough for all existing This approach should be flexible enough for all existing
architectures for deploying HTTP services. architectures for deploying HTTP services.
6. In-band HTTP Authentication Alternatives 7. Actual Authentication Mechanisms
RESTauth is "out-of-band" in the sense that the authentication
messages are exchanged independently of the application's requests
for normal resources. Of course, RESTauth exchanges may well (and
often will) happen in the same TCP/TLS connection as normal
application requests, so RESTauth is not really out-of-band. We use
"out-of-band" and "in-band" very loosely in this section.
There exist several "in-band" HTTP authentication alternatives where
the authentication message exchanges happen in the context of
application resources. Here the HTTP verb and resource are
application-specific and have nothing to do with authentication, and
the authentication messages are exchanged via HTTP request and
response headers with the server responding with a 401 status code
until authentication is complete.
The extant "Basic" and "DIGEST-MD5" [RFC2617] HTTP authentication
methods, as well as HTTP/Negotiate [RFC4559] are "in-band" HTTP
authentication methods.
In so far as an in-band authentication method results in a cookie or
session URI/ID the distinction between in-band and out-of-band is
almost trivial, as described above: authentication messages in
headers vs. bodies, and HTTP verb and URL. However, if in-line
authentication methods are strongly tied to the TCP/TLS connections
over which they were utilized then that is a big disadvantage over
RESTauth: each connection requires re-authenticating, and support for
HTTP routing schemes is not clear.
HTTP/Negotiate is more troublesome because historically it has
required re-authentication per-HTTP request(!).
Even if the only difference between in-band and out-of-band is a
trivial one, using the REST pattern means that authentication can be
implemented using with no help from the HTTP stack (even though it's
desirable to have it implemented within/by the HTTP stack), whereas
there may not be a way to implement in-band authentication without
help from the HTTP stack for some stacks.
7. Sample/Potential RESTauth Authentication Mechanisms
Here we describe (informatively, for the time being) how to use or Here we describe (INFORMATIVELY for the time being) how to use or
adapt a variety of authentication mechanisms, from SSHv2, IKEv2, adapt a variety of authentication mechanisms, from SSHv2, IKEv2,
SASL, GSS-API, and other frameworks, so as to quickly gain a set of SASL, GSS-API, and other frameworks, so as to quickly gain a set of
usable mechanisms, both, specification- and implementation-wise. usable mechanisms, both, specification- and implementation-wise.
This section is also intended to show that adding RESTauth mechanisms This section is also intended to show that adding RESTauth mechanisms
is easy. is easy.
Reuse of existing authentication mechanisms is a key goal of
RESTauth: let us stop inventing wheels that require costly deployment
of new authentication infrastructures (and credentials) and/or
bridges to other authentication infrastructures.
7.1. OAuth via RESTauth 7.1. OAuth via RESTauth
OAuth 1.0 RFC5849 and OAuth 2.0 [I-D.ietf-oauth-v2] are commonly OAuth 1.0 RFC5849 and OAuth 2.0 [RFC6749] are commonly deployed.
deployed. Being able to use OAuth via RESTauth would be useful. We Being able to use OAuth via RESTauth would be useful. We attempt to
attempt to make RESTauth such that at least for OAuth 1.0 there is a make RESTauth such that at least for OAuth 1.0 there is a standard
standard way to use OAuth such that it conforms to RESTauth. way to use OAuth such that it conforms to RESTauth.
7.1.1. OAuth 1.0 7.1.1. OAuth 1.0
For OAuth 1.0 [RFC5849] the "form-encoded body" form (see section For OAuth 1.0 [RFC5849] the "form-encoded body" form (see section
3.5.2 of [RFC5849]) of OAuth 1.0 conforms to RESTauth without further 3.5.2 of [RFC5849]) of OAuth 1.0 conforms to RESTauth without further
changes. changes.
7.1.2. OAuth 2.0 7.1.2. OAuth 2.0
[It looks like OAuth 2.0 [I-D.ietf-oauth-v2] also uses POST to send [It looks like OAuth 2.0 [RFC6749] also uses POST to send tokens to
tokens to the server, and it looks like it too effectively conforms the server, and it looks like it too effectively conforms to
to RESTauth.] RESTauth.]
7.2. Adapting SSHv2 Authentication Mechanisms to RESTauth 7.2. Adapting SSHv2 Authentication Mechanisms to RESTauth
SSHv2 "userauth" mechanisms [RFC4252] typically involve a digital SSHv2 "userauth" mechanisms [RFC4252] typically involve a digital
signature (or similar) of an SSHv2 session ID. There is no such signature (or similar) of an SSHv2 session ID. There is no such
thing as an SSHv2 session ID in HTTP. A session URI cannot serve as thing as an SSHv2 session ID in HTTP. A session URI cannot serve as
a stand-in for an SSHv2 session ID because a) the session URI is an a stand-in for an SSHv2 session ID because a) the session URI is an
outcome of authentication in RESTauth, b) to prevent cut-n-paste and outcome of authentication in RESTauth, b) to prevent cut-n-paste and
replay attacks the client and the server both must contribute to the replay attacks the client and the server both must contribute to the
entropy of the session ID that is signed by the client. entropy of the session ID that is signed by the client.
skipping to change at page 18, line 38 skipping to change at page 20, line 43
type name, followed by the channel binding data (e.g., 'tls-server- type name, followed by the channel binding data (e.g., 'tls-server-
end-point' followed by the server EE certificate as sent in the end-point' followed by the server EE certificate as sent in the
server's TLS Certificate message). server's TLS Certificate message).
Note that use of channel binding when using SSHv2 mechanisms is Note that use of channel binding when using SSHv2 mechanisms is
REQUIRED so as to defeat cut-n-paste attacks by weakly-authenticated REQUIRED so as to defeat cut-n-paste attacks by weakly-authenticated
servers. servers.
7.3. Adapting IKEv2 Authentication Mechanisms to RESTauth 7.3. Adapting IKEv2 Authentication Mechanisms to RESTauth
[[anchor9: TBD.]] [[anchor11: TBD.]]
7.3.1. Adapting IKEv2 Password Authenticated Connection Establishment 7.3.1. Adapting IKEv2 Password Authenticated Connection Establishment
(PACE) to RESTauth (PACE) to RESTauth
[[anchor10: TBD.]] [[anchor12: TBD.]]
7.4. Using SASL Authentication Mechanisms with RESTauth 7.4. Using SASL Authentication Mechanisms with RESTauth
Simple Authentication and Security Layers (SASL) [RFC4422] is a Simple Authentication and Security Layers (SASL) [RFC4422] is a
simple, pluggable framework for authentication mechanisms. simple, pluggable framework for authentication mechanisms.
To use a SASL mechanism in RESTauth just prefix "SA-" to the SASL To use a SASL mechanism in RESTauth just prefix "SA-" to the SASL
mechanism name and use that as the RESTauth mechanism name. If the mechanism name and use that as the RESTauth mechanism name. If the
SASL mechanism is server-initiated then the server's challenge is SASL mechanism is server-initiated then the server's challenge is
sent in the server's WWW-Authenticate header value as described sent in the server's WWW-Authenticate header value as described
skipping to change at page 20, line 49 skipping to change at page 22, line 49
S->C: HTTP/1.1 200 S->C: HTTP/1.1 200
Content-Type: application/octet-stream Content-Type: application/octet-stream
Content-Length: nnn Content-Length: nnn
v=rmF9pqV8S7suAoZWja4dJRkFsKQ= v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
Figure 3: RESTauth w/ SCRAM Figure 3: RESTauth w/ SCRAM
7.4.2. Using SCRAM with Round Trip Optimization in RESTauth 7.4.2. Using SCRAM with Round Trip Optimization in RESTauth
[[anchor11: This might work by having the authentication ID function [[anchor13: This might work by having the authentication ID function
as the salt and the server offering a challenge nonce and iteration as the salt and the server offering a challenge nonce and iteration
count in its optimistic challenge. However, it's not clear that a count in its optimistic challenge. However, it's not clear that a
round trip optimized form of SCRAM is desirable.]] round trip optimized form of SCRAM is desirable.]]
The following figure shows what a round trip optimized RESTauth w/ The following figure shows what a round trip optimized RESTauth w/
SCRAM exchange might look like. SCRAM exchange might look like.
[[anchor12: NOTE: SCRAM was not intended to be used this way. In [[anchor14: NOTE: SCRAM was not intended to be used this way. In
particular this approach forces the use of an algorithmic salt, to be particular this approach forces the use of an algorithmic salt, to be
derived only from either the username or the username and the derived only from either the username or the username and the
server's name (or else to be remembered by the user, but that's not server's name (or else to be remembered by the user, but that's not
likely).]] likely).]]
C->S: GET /some-resources HTTP/1.1 C->S: GET /some-resources HTTP/1.1
Host: A.example Host: A.example
S->C: HTTP/1.1 401 Unauthorized S->C: HTTP/1.1 401 Unauthorized
WWW-Authenticate: RA-SA-SCRAM-SHA-1 \ WWW-Authenticate: RA-SA-SCRAM-SHA-1 \
skipping to change at page 23, line 5 skipping to change at page 25, line 5
mechanisms via the "SASL/GS2" bridge [RFC5801]. This includes the mechanisms via the "SASL/GS2" bridge [RFC5801]. This includes the
Kerberos V5 GSS-API mechanism [RFC4121]. Kerberos V5 GSS-API mechanism [RFC4121].
GSS-API security mechanisms could also be used without SASL/GS2, but GSS-API security mechanisms could also be used without SASL/GS2, but
SASL/GS2 barely adds any overhead or complexity (a SASL SASL/GS2 barely adds any overhead or complexity (a SASL
implementation is not required in order to use SASL/GS2, just a GSS implementation is not required in order to use SASL/GS2, just a GSS
implementation): a simple header is to be prefixed to the initial implementation): a simple header is to be prefixed to the initial
security context token and to the channel binding data, with both security context token and to the channel binding data, with both
peers always providing channel binding data. peers always providing channel binding data.
8. IANA Considerations 8. Implementation Advice
RESTauth can be implemented without having to modify the HTTP nor TLS
stacks.
The simplest thing to do is to implement a small API to produce and
consume HTTP messages.
8.1. Server-Side Implementation Advice
On the server side the simplest thing to do is to implement POST
handlers for the login and session resource URI namespace. The
aspects of implementation that will be stack-specific are:
o WWW-Authenticate header value generation;
o Routing of GET and POST requests on the login and session
resources to the RESTauth handlers;
o The interface between the web server and the handlers.
The FCGI interface is widely supported, allowing RESTauth to be
implemented in a nearly universal way on the server side.
8.1.1. Channel Binding on the Server Side
The simplest way to implement channel binding on the server side is
to use 'tls-server-end-point' channel bindings, using a table of
server certificates indexed by fully-qualified server hostname
values, with the Host: header value used to index this table. The
server's end entity (EE) certificate is the channel binding data.
8.1.2. Server Cluster / Routing Support
Because each RESTauth session is a first-class resource named by a
URI (natch), multiple servers behind a given origin may recognize and
handle all the sessions that they should be able to: all the sessions
created at that origin, and all the sessions scoped to include that
origin. This is handled by the simple expedient of doing an HTTP GET
of the session resource claimed by a client. Note that the
representation of a session resource can be cached easily, and
updates can be checked with HEAD or conditional GETs, as one would
expect of any RESTful HTTP API.
It is important that server MUST NOT attempt to GET (or HEAD) session
resources for origins that the server does not respond to or which
the server does not expect to share sessions with the server's
origin(s).
8.2. Client-Side Implementation Advice
There are many HTTPS client stacks, too many, each with its own APIs,
to make it possible to implement RESTauth universally. The
application will have to bridge any generic RESTauth APIs with the
HTTP stack.
A reasonable implementation strategy is to build a generic RESTauth
interface that
o consumes 401 responses (or just their WWW-Authenticate header
values)
o consumes channel binding data (see below)
o generates HTTP requests to send to login or session URIs
o consumes HTTP responses to requests sent to login or session URIs
The application would have to extract relevant responses and channel
binding data from the HTTP stack to feed to the RESTauth interface,
and it would have to extract requests from the RESTauth interface and
feed them to the HTTP stack.
The interfaces, abstractly, should be:
restauth_new() Create a RESTauth context handle;
restauth_401() Consume a 401 and update or create a RESTauth context
handle;
restauth_login() Produce a POST to a login resource URI (either
provided explicitly or obtained from a 401);
restauth_login_continue() Consume a response to a POST to a login
resource and output a) status (complete or continue), b) possibly
a POST to a session URI;
restauth_logout() Produce a DELETE of the given session URI or the
given RESTauth context's session URI.
Channel binding type and data would be given to restauth_login().
Specific programming language bindings of this API are easy enough to
produce. Whether the API outputs or consumes complete messages or
decomposed messages (start-line, headers, body, trailers) will depend
on the APIs of the HTTP stack being targeted. A utility API that
composes/decomposes HTTP messages will help make a RESTauth
implementation widely reusable.
8.2.1. Channel Binding on the Client Side
Most HTTPS stacks provide a way for the client application to obtain
the server's EE certificate; this is sufficient to implement 'tls-
server-end-point' channel binding.
9. IANA Considerations
TBD (header registrations, ...) TBD (header registrations, ...)
9. Security Considerations 10. Security Considerations
This entire document deals with security considerations. [Add more, This entire document deals with security considerations. [Add more,
like about channel binding, same-origin-like constraints on the login like about channel binding, same-origin-like constraints on the login
and session absolute URIs', ...] and session absolute URIs', ...]
10. TODO Note that though servers can GET/HEAD session resources, they MUST
only do it for session resources for recognized origins. See
Section 8.1.2.
[[anchor13: Add references (to HTTP/2.0, CGI/fCGI, ...).]] [[anchor15: ...]]
[[anchor14: Describe MAC session binding option and replay protection 11. TODO
in detail -- or remove it altogether. Describe how to extract keys
for MAC keying from SASL/GSS/PACE.]]
[[anchor15: Figure out how to adapt IKEv2 password-based methods to [[anchor16: Add references (to HTTP/2.0, CGI/fCGI, ...).]]
[[anchor17: Decide whether to support a MAC type of session
continuation, or only channel bound sessions.]]
[[anchor18: Describe or remove the MAC session binding option and
replay protection in detail -- or remove it altogether. Describe how
to extract keys for MAC keying from SASL/GSS/PACE.]]
[[anchor19: Figure out how to adapt IKEv2 password-based methods to
RESTauth. This may not be worthwhile (since each method tends to RESTauth. This may not be worthwhile (since each method tends to
depend heavily on the entire IKEv2 framework in ways that add depend heavily on the entire IKEv2 framework in ways that add
messaging that we'd not need in RESTauth).]] messaging that we'd not need in RESTauth).]]
[[anchor16: Do we need to distinguish exchanges for authentication [[anchor20: Normatively specify bindings to SASL and/or GSS-API
from exchanges for authorization? Probably.]] security mechanisms. Include support for BrowserID.]]
11. References 12. References
11.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
skipping to change at page 26, line 42 skipping to change at page 31, line 42
Continuation: Problem Statement", Continuation: Problem Statement",
draft-williams-websec-session-continue-prob-00 (work in draft-williams-websec-session-continue-prob-00 (work in
progress), January 2013. progress), January 2013.
[I-D.williams-websec-session-continue-proto] [I-D.williams-websec-session-continue-proto]
Williams, N., "Hypertext Transport Protocol (HTTP) Session Williams, N., "Hypertext Transport Protocol (HTTP) Session
Continuation Protocol", Continuation Protocol",
draft-williams-websec-session-continue-proto-00 (work in draft-williams-websec-session-continue-proto-00 (work in
progress), January 2013. progress), January 2013.
11.2. Informative References 12.2. Informative References
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, [RFC2743] Linn, J., "Generic Security Service Application Program
April 2010. Interface Version 2, Update 1", RFC 2743, January 2000.
[I-D.ietf-oauth-v2] [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
Hardt, D., "The OAuth 2.0 Authorization Framework", "Remote Authentication Dial In User Service (RADIUS)",
draft-ietf-oauth-v2-31 (work in progress), August 2012. RFC 2865, June 2000.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Security Layer (SASL)", RFC 4422, June 2006. Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
"Salted Challenge Response Authentication Mechanism Kerberos Network Authentication Service (V5)", RFC 4120,
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. July 2005.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006. Authentication Protocol", RFC 4252, January 2006.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft Kerberos and NTLM HTTP Authentication in Microsoft
Windows", RFC 4559, June 2006. Windows", RFC 4559, June 2006.
[RFC6631] Kuegler, D. and Y. Sheffer, "Password Authenticated
Connection Establishment with the Internet Key Exchange
Protocol version 2 (IKEv2)", RFC 6631, June 2012.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
Service Application Program Interface (GSS-API) Mechanisms Service Application Program Interface (GSS-API) Mechanisms
in Simple Authentication and Security Layer (SASL): The in Simple Authentication and Security Layer (SASL): The
GS2 Mechanism Family", RFC 5801, July 2010. GS2 Mechanism Family", RFC 5801, July 2010.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
Version 5 Generic Security Service Application Program "Salted Challenge Response Authentication Mechanism
Interface (GSS-API) Mechanism: Version 2", RFC 4121, (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
July 2005.
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
April 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[RFC6631] Kuegler, D. and Y. Sheffer, "Password Authenticated
Connection Establishment with the Internet Key Exchange
Protocol version 2 (IKEv2)", RFC 6631, June 2012.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, October 2012.
Author's Address Author's Address
Nicolas Williams Nicolas Williams
Cryptonector, LLC Cryptonector, LLC
Email: nico@cryptonector.com Email: nico@cryptonector.com
 End of changes. 55 change blocks. 
175 lines changed or deleted 469 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/