Network Working Group S. Farrell Internet-Draft Trinity College Dublin Intended status: Standards Track P. Hoffman Expires: January 17, 2013 VPN Consortium July 16, 2012 HTTP Origin-Bound Authentication (HOBA) draft-farrell-httpbis-hoba-01 Abstract HTTP Origin-Bound Authentication (HOBA) is an HTTP authentication method with credentials that are not vulnerable to simple phishing attacks, and that does not require a server-side password database. It is an alternative to HTTP authentication that requires passwords and all the negative attributes that come with password-based systems. HOBA can be integrated with account management and other applications running over HTTP and supports portability, so a user can associate more than one device or origin-bound certificate with the same service. HOBA has many other useful features such as a mechanism to handle state-loss if one of a user's credentials is lost and a logout mechanism. Status of this Memo 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 January 17, 2013. Copyright Notice 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 Farrell & Hoffman Expires January 17, 2013 [Page 1] Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012 (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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. HOBA HTTP Authentication . . . . . . . . . . . . . . . . . . . 5 3. Additional Services . . . . . . . . . . . . . . . . . . . . . 6 3.1. Signing Up . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Binding Additional Keys . . . . . . . . . . . . . . . . . 7 3.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . . 9 5.2. .well-known URLs . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. HOBA Using TLS Inside of HTTP . . . . . . . . . . . . 10 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 11 B.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Farrell & Hoffman Expires January 17, 2013 [Page 2] Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012 1. Introduction [[Text in double square brackets (like this) is commentary.]] [[This is a proposal for a new HTTP authentication scheme that might be adopted by the httpbis WG as part of their work on HTTP/2.0. It is also usable with HTTP 1.0 and HTTP 1.1. The main goal of HOBA is to offer an easy-to-implement HTTP authentication scheme that is not based on passwords. If deployment of HOBA reduces the number of password entries in databases by any appreciable amount then it would be worthwhile. While application layer (above HTTP) authentication is also very common today - and better schemes are needed there too - that does not mean that we ought not have one for HTTP as well. If we want to reduce password use, then both will be needed.]] [[The authors admit that the current organization of the document leaves much to be desired. This can easily be fixed if the WG adopts the document.]] Databases of passwords cause huge security problems. Large password datasets seem to leak out onto the Internet with increasing frequency. Once leaked those reveal passwords that are used across multiple systems. This is a threat to the Internet that would be mitigated by the development and deployment of non-password based HTTP authentication schemes. The HTTP Origin Bound Authentication (HOBA) described here is one such scheme. RFC 2617 [RFC2617] defines basic and digest authentication methods for HTTP that have been in use for many years, but which, being based on passwords, are susceptible to theft of server-side databases. The HTTP authentication framework [I-D.ietf-httpbis-p7-auth] describes how more modern HTTP authentication methods should be defined. HOBA takes the best features of digest authentication (that is, the ones that are easy to implement and are interoperable) and gets rid of the passwords. It also adds features that people have wanted in HTTP authentication for over a decade, such as credential management and session logout. [I-D.balfanz-tls-obc] describes per-origin, self-signed "Origin-Bound Certificates" (OBCs) that are used for authenticating clients. [[We should consider whether the self-signed format described in that draft is really needed here. One can imagine that cert signed by a trusted CA that had the rest of the the properties needed.]] These certificates are used in HOBA for HTTP clients to authenticate themselves to servers in the HTTP protocol. The HOBA spec also defines many services that are required for modern HTTP authentication: Farrell & Hoffman Expires January 17, 2013 [Page 3] Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012 o For HOBA to be usable, the server needs some way to bind the OBC with some identifier for, usually, an account of some sort. HOBA allows servers to define their own policies for binding OBC certificates with user accounts during account sign-up. o Users are likely to use more than one device or user agent (UA) for the same HTTP based service, so there needs to be a way to bind more than one OBC to the same account, but without having to sign up for each separately. Sign-up may involve the user entering values, or closing a mail loop or other time consuming operations. To handle this the server can supply the client with the information required to bind together two OBCs, so that either can be used for the same account. o Users are also likely to lose a private key, if they lose a mobile device or for many other reasons. Another way in which state can be lost is if the OBC expires, at which point the sign-up needs to happen again. The approach taken here to handle loss of state is the same as for handling portability - allow the user to bind more than one OBC to the same account, this time so that even if state is lost from one user agent, that user agent can be easily bound to another OBC for the user. o Logout features can be useful for user agents, so we define a way to close a current "session" over and above just closing the [[TLS]] session, and also a way to close all current sessions, even if more than one session is currently active from different user agents for the same account. 1.1. Terminology 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 RFC 2119 [RFC2119]. This specification uses [[or will use:-)]] the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. A HOBA client credential consists of an asymmetric private key and an associated origin-bound certificate (OBC). On the server-side, the term credential means just the OBC. [[That's a different use of the term from [I-D.ietf-httpbis-p7-auth]. Maybe a better term is needed.]] The term "account" is (loosely) used to refer to whatever data structure(s) the server maintains that are associated with the user and a given HTTP authentication realm. [I-D.ietf-httpbis-p7-auth] That will normally contain of at least one OBC and the realm, but Farrell & Hoffman Expires January 17, 2013 [Page 4] Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012 might involve many other non-standard pieces of data that the server accumulates as part of an account creation processes. An account may have many OBCs that are considered equivalent in terms of being usable for authentication to that realm, however, the meaning of the word equivalent here is really up to the server and not defined here. 2. HOBA HTTP Authentication An HTTP server that supports HOBA authentication MAY include the "hoba" auth-scheme value in a WWW-Authenticate header field as required. This scheme MUST be followed by one or more auth-param values. The auth-param attributes defined by this specification are below. Other auth-param attributes MAY be used as well. Unknown auth-param attributes MUST be ignored by clients, if present. [[If that's ok, need to think about it a bit.]] The "challenge" attribute MUST be included. The challenge is a string of characters that the server wants the client to sign in its response. The challenge MUST be unique for every HTTP request and sufficiently difficult to guess in advance in order to prevent replay attacks from passive observers. A "realm" attribute MAY be included to indicate the scope of protection in the manner described in HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]. The "realm" attribute MUST NOT appear more than once. A UA using HOBA MUST maintain a list of web origins [RFC6454] and realms for each of those. The UA MUST maintain one or more client credentials for each origin/realm combination. [[Note: [I-D.balfanz-tls-obc] says *at most* one OBC per web-origin, but here we're saying one OBC per (web-origin,realm) pair. Something needs to change there.]] On receipt of a WWW-Authenticate for a given realm, the client marshals a to-be-signed blob that consists of the origin name, the realm name, and the challenge string, and signs that blob. It concatenates the signed blob with the OBC identifier that the client and host agreed on for the client, and encodes the result as a b64token. The client then returns that b64token in the Authorization header. [[Note: this is just an illustrative first cut at a challenge-response protocol, real design and analysis is needed for this, e.g. for security, algorithm agility, etc. Ideally we can just adopt something that already has some security proofs. Expect changes here.]] Farrell & Hoffman Expires January 17, 2013 [Page 5] Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012 If the UA has no client credential for the realm in question, the UA MAY (possibly involving user input) choose to sign up for that realm by using the HOBA sign up procedure described below. 3. Additional Services HOBA uses well-known URLs [RFC5785] for performing many tasks: "http://hostname/.well-known/hoba/". These URLs are based on the name of the origin host that the HTTP client is accessing. There are many use cases for these URLs to redirect to other URLs: a site that does sign-up through a federated site, a site that only does sign-up under HTTPS, and so on. Like any HTTP client, HOBA clients MUST be able to handle redirection of these .well-known URLs which is quite likely to happen. [[There are a bunch of security issues to consider related to cases where a re-direct brings you off-site.]] 3.1. Signing Up Normally, a sign-up is expected to happen after a UA receives a WWW- Authenticate for an origin/realm for which it has no client- credential. The process of signing up for a HOBA account on a server is simple - a new client credential is generated for the web-origin/ realm in question and is submitted to the signup URL, ".well-known/ hoba/sign-up", using a POST message. It is up to the server to decide what kind of user interaction is required before the account is considered "live," so that HOBA authentication for that origin/ realm combination works for the client. These interactions MUST take place via a TLS server authenticated session. That is, signup URLs MUST be https URLs. [[The logic being there's no reason at all to not use TLS here, if there were then a SHOULD would be appropriate.]] The POST message sent to the signup URL has one parameter [[name TBD]] which contains the OBC that the UA will use for the origin/ realm combination. The OBC MUST be sent base64 encoded. The value that is base64 encoded is the DER encoding of the self-signed X.509 certificate structure that is the OBC. See [RFC5280] for generic details of that data structure and the OBC specification [I-D.balfanz-tls-obc] for the profile of X.509 that is used for OBC. [[It might be better to use a template for this so that we don't have to standardise the format of the post data. OTOH, it seems simpler to just POST the OBC to the server using a standard attribute. Whatever fancy UI the server wants can be handled via normal web interactions following on from the POST message in either case.]] Farrell & Hoffman Expires January 17, 2013 [Page 6] Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012 3.2. Binding Additional Keys Key binding will normally be required where a user has more than one UA she wants to use for that service. This can be triggered when the UA is in one of two states - either authenticated or unauthenticated. The former case might happen if the user has two previously separate accounts on the server and wishes these to be "merged" for whatever definition or merge the server chooses. The latter case can happen if a user has gone through the sign up process with one UA and now wishes to add another OBC, used by another UA, to that account. This can be useful if the sign up process is cumbersome for the user, who doesn't want to have to fill in many form fields for a second time but who can access both UAs within a reasonable time frame. Essentially, we provide enough protocol machinery that a server can decide to add, or not accept, the new OBC for that account using whatever UI the sever chooses, but with the restriction that the user has to transfer a string, chosen by the server, from the previously authenticated UA to the "new" UA. In either the authenticated or unauthenticated cases the key binding operation is triggered by the user, via the UA, and MUST NOT be triggered solely as a result of network interactions. When key binding is triggered, the UA will go to ".well-known/hoba/ key-binding". The server can then interact with the user however it (the server) chooses but that MUST involve two things. The first is display of a string that the user can enter into a different UA to bind the two accounts, and the second is a form that allows for entry of such strings. If the UA triggered key binding but was not yet authenticated, then the UA generates a new set of client credentials and also sends the OBC to the server using another form field. [[More detail TBD.]] If an acceptable string is entered with a new OBC in this manner, then the server can choose to associate the two OBCs with one account. Whether to do so is entirely at the server's discretion however, but the server SHOULD make the outcome clear to the user. Note that the security level associated with key binding is entirely up to the server. The server can use any mechanism it chooses to make it less likely that a user manages to associate their OBC with someone else's account. That will typically involve trade-offs between security and usability based on the length of the string, the duration for which the string will be accepted etc. The strings used here are only intended be used once. However, error Farrell & Hoffman Expires January 17, 2013 [Page 7] Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012 handling might cause a sensible server to allow a string to be used more than once. If the same string is used more than once then the same OBC MUST be associated with that string. The UA MUST NOT generate a new OBC unless a new string is to be entered during key binding. Since the string can be entered more than once, key binding URLs MUST make use of TLS with server authentication, that is the key binding URL MUST be an https URL. [[Need a better term than "string" here that gets over what its for but also allows e.g. the server to display a long value and ask the user to enter the "3rd, 6th and 9th numbers" from a displayed selection etc.]] 3.3. Logging Out When the user wishes to logout, the UA simply goes to ".well-known/ hoba/log-out". The UA MAY also delete session cookies associated with the session. [[Is that right?, maybe a SHOULD- or MUST-delete would be better]] The server-side MUST NOT allow TLS session resumption for any logged out session and SHOULD also revoke or delete any cookies associated with the session. Logging out all sessions is pretty obvious really:-) Note that if a user follows the ".well-known/hoba/log-out-all" URL, then it is quite likely that another of the user's devices might experience an unexpected session termination, and the user SHOULD be notified of this, if possible. [[How? How do we know that's the reason for the failure? Might need a 4xx rule maybe.]] 4. Security Considerations If key binding was server-selected then a bad actor could bind different accounts belonging to the user from the network with possible bad consequences, especially if one of the private keys was compromised somehow. Binding my OBC with someone else's account would be fun and profitable so SHOULD be hard. In particular the string generated by the server MUST be hard to guess, for whatever level of difficulty is chosen by the server. The server SHOULD NOT allow a random guess to reveal whether or not an account exists. [[lots more TBD, be nice to your private keys etc. etc.]] Farrell & Hoffman Expires January 17, 2013 [Page 8] Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012 5. IANA Considerations 5.1. HOBA Authentication Scheme Authentication Scheme Name: hoba Pointer to specification text: [[ this document ]] Notes (optional): The HOBA scheme can be used with either HTTP servers or proxies. [[But we need to figure out the proxy angle;-)]] 5.2. .well-known URLs TBD We probably want a new registry for the labels beneath .well-known/ hoba so that other folks can add additional features in a controlled way, e.g. for OBC/account revocation or whatever. 6. Acknowledgements [[TBD]] 7. References 7.1. Normative References [I-D.ietf-httpbis-p7-auth] Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part 7: Authentication", draft-ietf-httpbis-p7-auth-20 (work in progress), July 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010. [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, Farrell & Hoffman Expires January 17, 2013 [Page 9] Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012 December 2011. 7.2. Informative References [I-D.balfanz-tls-obc] Balfanz, D., Smetters, D., and A. Barth, "TLS Origin-Bound Certificates", draft-balfanz-tls-obc-01 (work in progress), November 2011. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. Appendix A. HOBA Using TLS Inside of HTTP The -00 version of this proposal used a completely different method of using HOBA, namely to follow [I-D.balfanz-tls-obc] literally and use TLS 1.2 ([RFC5246]) inside of HTTP to do the authentication. This appendix copies the earlier proposal in case the WG wants to go with that instead of the method described in the main sections of this document. [[Note that re-using [I-D.balfanz-tls-obc] has pros and cons. The benefit if OBC was widely deployed would be that HOBA would be quite a simple layer on top. The downsides however are that HOBA would then need a modified TLS implementation on both client and server and HOBA would also be less proxy-friendly in particular for HTTP/1.1. The alternative, that the authors are happy to explore should the WG wish, is to basically do the OBC trick in the HTTP layer itself, where the server issues a challenge that is to be signed by the client. A downside of that is that we need to define that challenge response security protocol, but that can be done relatively easily. This is an issue that would need discussion in the wg - from a security and authentication point of view, it could work fine either way, so the decision should probably be driven by what's easier to develop/deploy.]] In this context, we assume that server authentication uses the normal TLS server authentication methods. On receipt of a WWW-Authenticate for a given realm, in order to Farrell & Hoffman Expires January 17, 2013 [Page 10] Internet-Draft HTTP Origin-Bound Auth (HOBA) July 2012 authenticate, the UA establishes an OBC TLS connection with the server using the appropriate client credential, if an appropriate client credential is available. Appendix B. Changes B.1. Changes from -00 to -01 o Added Paul Hoffman as co-author o Changed the mechanism to do signing in HTTP itself; moved the old mechanism to Appendix A. o Started using .well-known/hoba/foo etc. rather than auth params Authors' Addresses Stephen Farrell Trinity College Dublin Dublin, 2 Ireland Phone: +353-1-896-2354 Email: stephen.farrell@cs.tcd.ie Paul Hoffman VPN Consortium Email: paul.hoffman@vpnc.org Farrell & Hoffman Expires January 17, 2013 [Page 11]