| Network Working Group | N. Williams |
| Internet-Draft | Cryptonector |
| Intended status: Informational | June 2012 |
| Expires: December 01, 2012 |
A Proposals for Classification and Analysis of HTTPbis Authentication Proposals
draft-williams-httpbis-auth-classification-01
This document proposes a classification scheme for HTTPbis authentication proposals, to help with analysis and selection.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 01, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The HTTPbis WG is accepting proposals for new authentication systems for HTTPbis, the successor to Hypertext Transport Protocol (HTTP) version 1.1[RFC2616]. This document proposes a classification system for these proposals. Several axes of classification are proposed, and several simplified imagined or likely authentication systems are used to illustrate the classification system.
The author assumes that the WG is interested primarily in new user authentication proposals, with ones that provide mutual authentication (of users and servers to each other) being in scope. The author also assumes that Transport Layer Security (TLS) [RFC5246] will continue to be used by HTTPbis for cryptographic session protection.
Some familiarity with authentication systems is assumed. A glossary is provided.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This document considers user authentication only in the context of HTTP applications, whether they be web applications or otherwise. Authentication of the service is also in scope, but authentication methods that authenticate only the user to the service (with the service authenticated by Transport Layer Security (TLS)) are in scope.
There are at least two entities involved in authentication in this context: the user (on the client side), one or more of the web server host or the web server application/service, and any trusted third parties that an authentication mechanism might involve.
This section defines terms as they are used in this document. Readers are strongly encouraged to read this section before reading any subsequent section.
Web applications today use a variety of user authentication methods, many of which are somewhat or deeply unsatisfying. Almost all of these methods involve the user-agent being mostly dumb – not participating in any cryptographic protocols other than TLS.
The most common user authentication methods used in web applications today include:
Not much use is made of TLS user certificates, though that is available as well.
These methods are somewhat-to-highly unsatisfactory for a variety of reasons:
Additionally, there is no strong concept of “sessions” in web applications. Sessions, such as they are, consist of HTTP requests and responses united into a session by the web cookies they bear. Not all web cookies are used for identifying sessions, and there is no simple “logout” functionality. The biggest problem with web cookies is that they are too easy to misuse or steal (e.g., given the occasional TLS vulnerability, such as BEAST [XXX Add references!]).
Furthermore, there are uncomfortable user interface (UI) problems. In particular it is difficult to convey to the user information about the server's/service's identity and how it is authenticated (if at all).
HTTP applications that are not web application have similar issues, though some of them can also use SASL[RFC4422]. Non-web HTTP applications also may not need cookies, instead using a single HTTP/1.1 persistent connection over which to issue all requests that make up a session – such applications have a stronger sense of session than web applications do.
The TLS server PKI, and, truly, any hierarchical or flat PKI intended for authenticating servers or services to users has a fundamental problem: the number of Names for which to issue certificates is too large to expect the PKI administrators to do a good job of keeping out the bad guys. Bad guys use any number of phishing techniques such that the names of their services need not even match those of the services that they wish to steal credentials for. The goal should be to keep the bad guys out altogether, but this is also quite difficult, if not impossible for many reasons including political ones.
The TLS server PKI suffers from a number of other non-fundamental problems, mostly due to legacy deployment:
The TLS server PKI also suffers from all the problems that trusted third party systems suffer from, namely: the need to trust the third parties. Fortunately there are a number of efforts under way to improve the trustworthiness of TLS server PKI CAs by, for example, making them auditable by the public [XXX Add references to CT, Convergence, HSTS/TACK/other pinning schemes, and others!]
And yet the TLS server PKI is here to stay. It will not go away. We can only minimize the dependence of the web's security on the TLS server PKI. To do so requires authentication mechanisms that can provide authentication of the server to the user in some manner such that none of the above problems apply. The hardest PKI problem to address is the fundamental problem described above: this requires accepting a smaller scale of server/service authentication to the user – a balkanization of sorts of the web, but see the discussion of trust islands in Section 3.6.
All authentication mechanism require some number of messages in order to authenticate an entity. For example, TLS generally requires two round-trips, while OAuth requires a single message from the client to the server. Here we count only messages from the HTTP client to the HTTP server; additional message exchanges may be required involving trusted third parties.
The number of authentication messages that must be exchanged for a given authentication mechanism is important. The API of at least one important credential management facility is premised on authentication mechanisms having exchanges of just one message – adding new API is possible, but it would take a long time for applications to begin using it. Thus mechanisms that require just one message are at a premium (but see the next section).
The number of authentication messages is also important for latency reasons: since authentication message exchanges are synchronous, each round trip time is added to the latency observed by the user.
The number of messages that an authentication mechanism needs to exchange with infrastructure (e.g., trusted third parties) also affects latency, but at least applications need never be aware of messages exchanged with infrastructure – these can be abstracted away by the APIs. Some authentication mechanisms have fast re-authentication facilities such that the latency cost of infrastructure messaging need not be incurred as frequently as the entity authenticates to others.
Half round trip mechanisms depend utterly on some other system for authentication of the server – in webauth this means the TLS server PKI. To understand why imagine that an application sends the one authentication message to a service, but it turns out that it is speaking to an impersonator for that service. The impersonator can at the very least obtain any sensitive data that the application is willing to send immediately. Additionally, if there's no channel bindings between the authentication mechanism and the service impersonator then the one message can be sent by the impersonator to the real service, letting the service impersonator impersonate the user to the real service as well (thus being a proper MITM).
There exist a number of one-message webauth authentication mechanisms that are widely deployed; we cannot forbid their use, we can only document their security considerations, namely: that they depend entirely on the TLS server PKI for their security.
[Discuss phishing issues, in particular the difficulty of creating user interfaces in web apps that cannot be spoofed by either server impersonators or MITMs. Reference Sam Hartman's anti-phishing I-D [I-D.hartman-webauth-phishing].]
Several orthogonal classification axes are proposed:
These nine classification axes are largely orthogonal to each other. Other classification criteria are also possible and may be added in future versions of this Internet-Draft. Some such possible additional criteria are subjective, such as, for example: ease of deployment, ease of implementation, etcetera. Perhaps the WG can come to consensus regarding desirable properties based on objective classification to narrow the set of proposals to consider. Or perhaps the WG can consider a large number of proposals and use objective classification to guide any applicability statements for the proposals accepted. Ideally the WG can apply objective classification first, then for each “bucket” of similar proposals the WG could consider more subjective classification criteria.
The web today depends utterly on the “TLS server PKI” for security. This would be just fine were it not for the systemic weaknesses in the TLS server PKI: the lack of name constraints, the large number of trust anchors, the large number of certificate authority (CA) compromises, and so on. Building on the TLS server PKI and thus assuming its being sufficiently secure, is quite tempting, as it may simplify various aspects of user authentication (not least by providing server authentication a priori, thus saving the designers the need to provide server authentication themselves).
This classification axis is very simple: either a proposed solution depends on the TLS server PKI or it doesn't. Some shades of black are imaginable in this case (if not likely).
A bearer token is a message the presentation of which is sufficient to authenticate the presenter. Stolen bearer tokens may be used to trivially impersonate the subject, thus bearer tokens generally require confidentiality protection in any protocols over which they might be exchanged, and generally depend on authenticating the relying party first.
Proof of possession systems consist of some secret/private key(s), an authenticator message the “proves” possession of the secret or private key(s) used in the construction of the authenticator, and a token not unlike a bearer token but which securely indicates to the relying party(ies) what keys the user must have used in the construction of the authenticator. The relying party then validates the authenticator to establish that the user did indeed possess the necessary secret/private key(s) to the best of the cryptographic capabilities of the authentication system used.
It is possible to design user (and mutual) authentication mechanisms that can work at any end-to-end layer between the HTTPbis client and server. The relevant layers are:
We dismiss out of hand the possibility of that layer being TCP or IPsec, though admittedly they are also end-to-end layers where user authentication could theoretically be done.
We distinguish between network layers and API layers (see glossary). A solution at the application network layer might nonetheless be implemented at the HTTP API layer (and vice-versa).
User authentication is generally something that a transport layer cannot know to initiate on its own: the application must be in control of when (server- and client-side) to authenticate, how (server- and/or client-side), with what credentials / as whom (client-side). This means that authentication in the transport layer requires APIs that give the application a measure of control. HTTP API capabilities will vary, but HTTPbis is a good opportunity to standardize an abstract API outlining capabilities and semantics to be exposed to applications by an HTTP stack.
Note that on the user-agent side the platform may provide user interaction facilities for authentication, thus simplifying user authentication APIs. The application, on the server side, remains in control over when to initiate authentication.
End-to-end session cryptographic protection is best done in the lowest possible transport layer. For HTTP applications, historically this means TLS; though it'd be technically feasible to provide protection at lower layers it does not appear to be a realistic option at this time.
User authentication is best “bound” into transport security layers, in this case TLS. When user authentication is moved to higher layers a “channel binding” problem arises: we would like to ensure that no man-in-the-middle exists in the transport layer, with the MITM terminating two TLS connections. For more information about channel binding see [RFC5056].
UI and API issues are quite different for web applications versus non-web applications. The former have rich UI elements (all of HTML's) and programming models (scripting, particularly through JavaScript). One problem that is particularly severe for web applications, is the ability of server impersonators to emulate all imaginable graphical user interfaces that the native user-agent might wish to use to distinguish itself from the applications it runs. Regardless of what layer implements authentication this problem will arise in web applications.
It's important to note that there need not be much difference between HTTP-layer and application-layer user authentication, at least if we assume a standard application-layer user authentication convention. For argument's sake let's assume an application-layer user authentication convention like the one in [I-D.williams-rest-gss], and let's assume two possible HTTPbis HTTP-layer authentication solutions: one that is most similar to HTTP/1.1's and one that uses a new verb for authentication. Then let's look at what each of these three solutions look like on the wire using the SCRAM mechanism for cases where the client already knows it has to authenticate. For brevity we elide any HTTP request and response where the server indicates that the client must authenticate, as well as any requests/responses involving negotiation of mechanism to use.
C->S: HTTP/1.1 POST /rest-gss-login
Host: A.example
Content-Type: application/rest-gss-login
Content-Length: nnn
SCRAM-SHA-1,,MIC
n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
S->C: HTTP/1.1 201
Location http://A.example/rest-gss-session-9d0af5f680d4ff46
Content-Type: application/rest-gss-login
Content-Length: nnn
C
r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
s=QSXCR+Q6sek8bf92,i=4096
C->S: HTTP/1.1 POST /rest-gss-session-9d0af5f680d4ff46
Host: A.example
Content-Type: application/rest-gss-login
Content-Length: nnn
c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
S->C: HTTP/1.1 200
Content-Type: application/rest-gss-login
Content-Length: nnn
A
v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
Figure 1: REST-GSS Login w/ SCRAM Example
C->S: HTTP/1.1 LOGIN
Host: A.example
Content-Type: application/SASL
Content-Length: nnn
SCRAM-SHA-1,,MIC
n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
S->C: HTTP/1.1 201
Location http://A.example/login-session-9d0af5f680d4ff46
Content-Type: application/SASL
Content-Length: nnn
C
r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
s=QSXCR+Q6sek8bf92,i=4096
C->S: HTTP/1.1 LOGINCONTINUE /login-session-9d0af5f680d4ff46
Host: A.example
Content-Type: application/SASL
Content-Length: nnn
c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
S->C: HTTP/1.1 200
Content-Type: application/SASL
Content-Length: nnn
A
v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
Figure 2: HTTPbis w/ New Verb Login w/ SCRAM Example
C->S: HTTP/1.1 GET /location/of/interest/to/app
Host: A.example
S->C: HTTP/1.1/401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:26:47 GMT
WWW-Authenticate: <list of mechanisms>
Content-Type: text/html
Content-Length: nnn
<error document>
C->S: HTTP/1.1 GET /location/of/interest/to/app
Host: A.example
Authorization: SCRAM-SHA-1,,MIC
n,,n=user,r=fyko+d2lbbFgONRv9qkxdaw
S->C: HTTP/1.1 4xx
WWW-Authenticate: C
r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
s=QSXCR+Q6sek8bf92,i=4096
WWW-Authenticate-Session: 9d0af5f680d4ff46
C->S: HTTP/1.1 GET /location/of/interest/to/app
Host: A.example
Authorization-Session: 9d0af5f680d4ff46
Authorization: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
S->C: HTTP/1.1 200
WWW-Authenticate: A
v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
Content-Type: ...
Content-Length: nnn
<content>
Figure 3: Extended HTTP/1.1 Style Login w/ SCRAM Example
There's not much difference between the first two examples. The third example has several important differences relative to the first two examples:
The main difference on the wire between a generic HTTP-layer user authentication framework (like the one in the second example) and an application-layer equivalent (as in the first example) can be so minimal as to make the choice of layer seem like splitting hairs.
There are HTTP stacks that make it possible to implement HTTP authentication methods in the application (e.g., FCGI in web servers), and nothing would prevent HTTP stacks from implementing a standard application-layer user authentication protocol either. The APIs offered by an HTTP stack should look remarkably similar regardless of which layer the user authentication protocol is technically at. Once again, the difference between HTTP-layer and standard application-layer user authentication is minimal.
Note however that if the HTTP stack does not implement authentication, leaving it to the application to do so, then the application developer runs the risk of making mistakes in the implementation, such as failing to implement channel binding where possible. Thus it is generally best if the HTTP stack implements authentication – even if TLS is used for user authentication, the HTTP stack should provide a singular API for authentication.
The choice of layer is clearly more important for APIs than on the wire. On the wire the choice of layer is minimal, trivial even, when the choice is between HTTP and the application layer.
If the WG agrees that the distinction between HTTP-layer and application-layer user authentication is or should be minimal then how should the WG pick one of those two layers, if it decides not to pursue TLS-layer user authentication?
A standard application-layer authentication scheme implies no changes to HTTP itself, and may not rely on any particular features of HTTP/1.1 or HTTPbis, thus it may be usable even with HTTP/1.0. This is true of the REST-GSS proposal[I-D.williams-rest-gss], which is also RESTful. This must be of some value.
An HTTP-layer authentication solution must either: a) not support multi-round trip mechanisms, b) add verbs, or c) not be RESTful. (a) works with HTTP/1.0, (b) would not work with HTTP/1.0. [The author believes that RESTfulness is desirable.]
Issues:
Benefits:
“Infrastructure” consists, for the purposes of this document, of services such as Identity Providers (IdPs), Certificate Revocation Lists (CRLs) and their servers, Online Certificate Status Protocol (OCSP) responders, Kerberos Key Distribution Centers (KDCs), RADIUS/DIAMETER servers, etcetera. These are services that run on parties other than a client (e.g., a web browser / user agent) and an application server. In some cases infrastructure services may be physically co-located with the client or server, but by and large they are physically separated; infrastructure services are always logically separate from the client and server. [XXX Move this to glossary.]
Some protocols require that the client do all or most of the message exchanges with infrastructure, some require that the server do this messaging, some require both to do some messaging. In some cases a server might proxy a client's messages to infrastructure. There are advantages to the client doing this messaging: namely a simpler server, less subject to denial of service / resource consumption attacks. [Are there advantages to the server doing this messaging?]
Consider a protocol like Kerberos. Kerberos relies on Key Distribution Center (KDC) infrastructure, and it relies on the client doing all the messaging needed to ultimately authenticate it to a server. Kerberos can be used in a way such that the relying party proxies this messaging for the client (see IAKERB), but even so the client had to communicate with the KDCs in order to ultimately authenticate to the relying party – IAKERB is simply a proxy mechanism.
Now consider an authentication mechanism based on PKI. The only online infrastructure in a PKI are the CRLs and OCSP responders. Of course, a Certificate Authority (CA) can also be online, as in kca [add reference], a CA that authenticates clients via Kerberos and which issues fresh, short-lived certificates. Private keys for certificates can also be served by online services such as SACRED and browserid. The method of validating certificates currently considered ideal is for the possessor of certificate's private key to send both, the certificate and a current/fresh OCSP response for it (or, rather, responses, for the entire certificate chain), thus the PKI relying party should ideally not have to contact infrastructure; in practice CRL checking is still the more commonly used method, requiring infrastructure messaging on the relying party side.
The responsibility for infrastructure messaging varies widely.
The number of messages that must be exchanged in order to authenticate a peer varies a lot by authentication mechanism. Some require just one message from the client to the server. Others require a reply message from the server. Others require some larger number of messages (typically three or four). Yet others require a variable number of messages.
Typically key exchange is also required in order to provide confidentiality and integrity protection to the transport. Key exchange protocols also vary in number of messages required. Key exchange and authentication may be combined, either directly in a single network layer, or across layers via channel binding.
One-message authentication protocols:
Two-message authentication protocols:
Authentication protocols with three or more messages, or with arbitrary numbers of messages:
It's worth pointing out that TLS is a three- to four-message protocol, but when providing confidentiality protection for the client identity it becomes a six- to eight-message protocol (though there is a proposal to improve this, getting back to three to four messages [add reference to Marsh's I-D]).
Some authentication protocols can provide key exchange, others cannot. Similarly, not all mechanisms can provide channel binding.
The total number of messages required is important. These message exchanges are always ordered and synchronous; no progress can be made by the application until they are completed. Over long distances the time to complete each round trip add up to noticeable latency, and there is much pressure to get this latency down to an absolute minimum.
Integrating user authentication into TLS has the clear allure of potentially cutting down the number of round trips necessary, but it's not clear that this can be achieved in every case. In particular it may not be clear that a client has to authenticate until after a TLS connection is established over which the client may request access to some resource that requires authenticated clients.
Pair-wise pre-shared keying systems require careful initial key exchange, but otherwise have no transitive trust issues: every pair of entities that has shared keying can communicate without the aid of any other entity. However, pair-wise pre-shared keying does not scale to the Internet as it is O(n^2), and it requires either “leap of faith” (a.k.a., trust on first use, or TOFU) or physical proximity for the key pre-sharing. Physical proximity
Authentication mechanisms that scale to the Internet of necessity require some degree of trust transitivity. That is, there must be many cases where Alice and Bob can communicate with each other only because they can authenticate each other by way of one or more third parties (e.g., Trent) that each of them trust a priori.
There are a number of issues with trust transitivity:
There are several ways to use transitive trust. In hierarchical transitive trust we organize the trusted third parties in such a way that there should be a trust path for every pair of entities of interest (e.g., every user to every server, every user to every user, ...) – think of PKI. In mesh systems trust transits through every entity's “friends” – think of PGP.
There may be other models of transitive trust, such as one with islands of trust. An islands of trust model would consist of federations of transitive trust (using hierarchical or mesh models) that are much smaller than the entire Internet, but large enough to be of use to large numbers of users. For example, an online merchant might provide for authentication of all users to a set of participating vendors [XXX expand on this].
Given the need for transitive trust and the serious drawbacks of transitive trust, some workarounds may be necessary, such as:
For an example of pinning, consider a TLS extension where self-signed, persistent user certificates are used, possibly one per-origin for pseudonymity purposes. The user agent can enroll the user certificates at their corresponding origin servers such that thereafter no MITMs are possible that can impersonate the user to the server. Of course, such a scheme suffers from needing a fall-back authentication method when the user's device(s) that store the relevant private keys are lost. Users would need to be able to fall-back on an alternative authentication method for re-enrollment, likely one that is susceptible to attack or else is inconvenient. In this cases the pinning is on the server side; keep in mind that pinning need not only be used on clients, but may be used even in the distributed trust infrastructure (e.g., to shorten trust paths).
Ideally an authentication facility for HTTP/2.0 should support a variety of trust establishment models, as it is not clear that one mode is superior to the others. (Though certainly the hierarchical model is likely the scheme that can have the most universal reach, and therefore most minimize user credentials needed. However, users may not mind having a small number of logon credentials for a trust island model.)
[Cover:
]
It seems likely that no single user authentication method will satisfy the needs of all web applications. Nor can we predict the future. Moreover, some weak authentication approaches are perfectly safe for accessing low-value resources, or in contexts where the Internet threat model is overkill. This argues for a multitude of solutions, and possibly a pluggable system.
The author proposes the following: