[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

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

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]


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