[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 draft-ietf-httpauth-hoba

Network Working Group                                         S. Farrell
Internet-Draft                                    Trinity College Dublin
Intended status: Standards Track                           June 13, 2012
Expires: December 15, 2012


                HTTP Origin-Bound Authentication (HOBA)
                     draft-farrell-httpbis-hoba-00

Abstract

   This memo proposes a way of using origin-bound certificates for HTTP
   authentication, called HOBA.  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, both major
   potential positives, if deployed.  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.  This also provides a
   mechanism to handle state-loss, if one of a user's credentials is
   lost.  HOBA also provides 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 December 15, 2012.

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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Farrell                 Expires December 15, 2012               [Page 1]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)            June 2012


   carefully, as they describe your rights and restrictions with respect
   to this document.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  A teeny bit of Terminology . . . . . . . . . . . . . . . . . .  5
   3.  HOBA HTTP Authentication . . . . . . . . . . . . . . . . . . .  5
   4.  Authenticating . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Signing Up . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Binding Additional Keys  . . . . . . . . . . . . . . . . . . .  7
   7.  Logging Out  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     11.1.  Normative References  . . . . . . . . . . . . . . . . . . 10
     11.2.  Informative References  . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11































Farrell                 Expires December 15, 2012               [Page 2]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)            June 2012


1.  Introduction

   [[Text in double square brackets (like this) is commentary.]]

   [[This is an initial 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 aimed to be usable with earlier versions of
   HTTP.  At present, there is no code for this, so a) its early days,
   but b) it can easily be changed if the basic idea is attractive, but
   details are wrong.  If someone wants to help out with this, that help
   would be welcome.  The main overall goal is to end up with an HTTP
   authentication scheme that is not based on using passwords.  There is
   no claim here that this will solve world hunger, but 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 probably.]]

   Passwords are the enemy.  In particular databases of passwords.  And
   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) scheme is one such.

   Some may disagree that passwords are the enemy.  One recent password
   database leak involved a database of 6,458,020 apparently valid
   hashed passwords.  Within days, there was a claim that 2,000,000 (or
   30%) of those had been cracked with no special equipment.  (See
   http://www.net-security.org/article.php?id=1727) Digital signature
   based authentication schemes have existed for many years, but have
   not seen sufficient deployment for client authentication outside of
   enterprise use cases.  TLS server authentication has however been
   widely deployed.  And that gives a useful comparison - in February
   2012, Lenstra et. al. (see http://eprint.iacr.org/2012/064) found
   approximately 270,000 of 6,400,000 RSA public keys (4%) might be
   problematic.  The main reason was probably re-use of public keys,
   which can be valid, but this is the "worst" figure reported so should
   be an overestimate.  For unique keys, they found real problems with
   only 0.2% resulting in a claim that RSA is "99.8% secure."

   That means that we now have (some) evidence that databases of public
   keys are an order or magnitude safer than databases of passwords.
   That is compelling and certainly sufficient to say that an
   authentication scheme that is not based on passwords is needed.



Farrell                 Expires December 15, 2012               [Page 3]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)            June 2012


   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.

   "Origin-Bound Certificates" (OBC) [I-D.balfanz-tls-obc] provides a
   way to use per-origin, self-signed client certificates for TLS
   [RFC5246] that allows for strong TLS mutual authentication if the
   "leap-of-faith" problem for the server can be solved.  The leap-of-
   faith problem for the server here is that the server needs some way
   to bind the OBC with some identifier for, usually, an account of some
   sort.  The HTTP authentication method defined here provides a URL at
   which a user can do whatever account creation steps are required.

   In this context, we assume that server authentication uses the normal
   TLS server authentication methods.

   In addition to providing a way to handle the leap-of-faith for one
   OBC, 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 solve
   the leap-of-faith problem for each separately.  (The leap of faith
   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.

   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 leap-of-faith needs to
   be handled again.

   The approach taken here to handle loss of state this 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 the other OBC for
   the user.

   While portability or state-loss could be handled using the same
   mechanism, that might not be desirable if onerous user interaction is
   needed.  In many cases it is possible to do better once an initial
   OBC exists for an account.  Here we provide a mechanism that results
   in display of a short code, in an authhenticated session, so that
   that short code can be entered into a second device or UA resulting
   in the second OBC also being associated with the same account.  The



Farrell                 Expires December 15, 2012               [Page 4]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)            June 2012


   second device or UA uses the same mechanism but this time supplies
   the short-code as an input.

   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.


2.  A teeny bit of 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
   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.


3.  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 two 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.]]



Farrell                 Expires December 15, 2012               [Page 5]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)            June 2012


   The "signup" attribute MUST be included, and MUST have a relative URL
   as its value.  This URL is where a client can sign up for a HOBA
   account for this service.

   [[Question: Ought absolute URLs be ok for HOBA auth-params?  What'd
   it mean to sign up at some other DNS name?  Sounds nice business-wise
   but dodgy security wise.  Or should we require the same web-origin or
   what?  Needs thought.]]

   The "keybind" attribute MUST be included, and MUST have a relative
   URL as its value.  That URL is where a client can associate an
   additional key with a HOBA account for this service for portability
   reasons or to recover from state-loss (assuming that at least one OBC
   remains usable).

   The "logout" attribute MAY be included, and if included MUST have a
   relative URL as its value.  That URL is where a client can cause a
   logout of the current session.

   The "logoutall" attribute MAY be included, and if included MUST have
   a relative URL as its value.  That relative URL is where a client can
   cause a logout of all current sessions associated with that account.

   The above attributes MUST NOT appear more than once.

   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.


4.  Authenticating

   In this section we describe how to authenticate using HOBA.

   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, in order to
   authenticate, the UA establishes an OBC TLS connection with the
   server using the appropriate client credential, if an appropriate
   client credential is available.

   [[Question: Is there value in having a challenge/response as part of



Farrell                 Expires December 15, 2012               [Page 6]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)            June 2012


   HOBA at the HTTP layer?  Something based on TLS channel bindings
   might be worthwhile, but need to think about that.]]

   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.


5.  Signing Up

   In this section we describe how to sign up to a service with HOBA.
   Normally, this 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 (using a POST message)
   that was part of the WWW-Authenticate header.  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.]]


6.  Binding Additional Keys

   In this section we describe how to bind additional keys to a HOBA
   "account."  This will normally be required where a user has more than
   one UA she wants to use for that service.




Farrell                 Expires December 15, 2012               [Page 7]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)            June 2012


   Key binding 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 de-reference the
   keybinding URL for that realm [[stored where?]].  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
   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



Farrell                 Expires December 15, 2012               [Page 8]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)            June 2012


   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.]]


7.  Logging Out

   When a "logout" attribute was supplied and the user wishes to logout,
   the UA simply de-references the appropriate URL.  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 "logoutall" 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 I guess.]]


8.  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                 Expires December 15, 2012               [Page 9]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)            June 2012


9.  IANA Considerations

   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 I need to figure out the proxy angle;-)]]


10.  Acknowledgements

   [[TBD]]


11.  References

11.1.  Normative 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.

   [I-D.ietf-httpbis-p7-auth]
              Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part
              7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in
              progress), March 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.

   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
              December 2011.

11.2.  Informative References

   [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.




Farrell                 Expires December 15, 2012              [Page 10]

Internet-Draft        HTTP Origin-Bound Auth (HOBA)            June 2012


   [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.


Author's Address

   Stephen Farrell
   Trinity College Dublin
   Dublin,   2
   Ireland

   Phone: +353-1-896-2354
   Email: stephen.farrell@cs.tcd.ie




































Farrell                 Expires December 15, 2012              [Page 11]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/