Internet DRAFT - draft-hartman-webauth


Network Working Group                                         S. Hartman
Internet-Draft                                                       MIT
Expires: December 16, 2006                                 June 14, 2006

                    Distributed Identity for the Web

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 16, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   It is often useful to be able to use distributed identity--an
   identity from one organization for accessing resources from another.
   for example it would be useful to use an identifier corresponding to
   your work identity when accessing business partners' websites.
   Similarly collaborative projects can benefit from distributed
   identity.  This memo proposes a scheme for distributed identity that
   meets requirements to minimize the risk of phishing attacks for HTTP-
   based applications including websites.

Hartman                 Expires December 16, 2006               [Page 1]
Internet-Draft      Distributed Identity for the Web           June 2006

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  User Experience  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Roaming and Local State  . . . . . . . . . . . . . . . . .  5
     3.2.  Webdav and other HTTP Applications . . . . . . . . . . . .  6
   4.  Website Author Experience  . . . . . . . . . . . . . . . . . .  7
   5.  A Proposed Solution  . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Negotiate Authentication . . . . . . . . . . . . . . . . .  8
     5.2.  Kerberos . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.3.  Security Assertion Markup Language . . . . . . . . . . . . 11
     5.4.  Local Browser UI . . . . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17

Hartman                 Expires December 16, 2006               [Page 2]
Internet-Draft      Distributed Identity for the Web           June 2006

1.  Introduction

   It is often useful to be able to use distributed identity--an
   identity from one organization for accessing resources from another.
   for example it would be useful to use an identifier corresponding to
   your work identity when accessing business partners' websites.
   Similarly collaborative projects can benefit from distributed
   identity.  This memo proposes a scheme for distributed identity that
   meets requirements to minimize the risk of phishing attacks

   Distributed identity solutions will never achieve the goal of having
   a single identity used for all websites.  Some websites will only
   accept a limited number of identity providers.  For example financial
   sites typically want high degrees of assurance that identity
   providers will not allow the wrong user to use an identity that has
   access to a financial account.  Similarly users will not always wish
   to link their identities together.  However distributed identity can
   minimize the number of identities that are in use.

   This proposal uses existing technology with incremental improvements
   to achieve the goal of distributed identity.  This document is
   organized into two parts.  The first part (sections 3 and 4)
   describes the intended user experience for the distributed identity
   system.  The second part describes a specific proposal for realizing
   distributed identity.

Hartman                 Expires December 16, 2006               [Page 3]
Internet-Draft      Distributed Identity for the Web           June 2006

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

   The terms identity, subject, relying party, and claim are used as
   defined in [LAWS].

Hartman                 Expires December 16, 2006               [Page 4]
Internet-Draft      Distributed Identity for the Web           June 2006

3.  User Experience

   This section describes what Alice, a HTTP user is hoping to get from
   distributed identity.

   Alice wants to go to a website.  She's remembered the name of the
   website from an ad, received a link in email, or is following a link
   from another site.

   The website wishes Alice to log in.  It presents an HTML page which
   includes a login button.  Alice pushes this button and her local
   identity management UI appears.  This UI includes some branding from
   the website, but it also includes branding Alice chose when she
   installed her computer.

   Alice selects an identity she wants to present to the website.  Since
   she has not recently used this identity either on the web or anywhere
   else, she must enter the password associated with the identity.

   Alice is logged into the website.  If the website uses TLS, she knows
   that the page she sees was created by the same party to whom she
   authenticated.  If her identity is designed to be accepted only by a
   small number of relying parties, then she knows that she is talking
   to one of these parties even if she was not careful to check to make
   sure the URL was not spoofed.

   If Alice didn't have an existing identity she wanted to use and if
   the website she's going to is not somehow restricted to existing
   users, then her identity management UI will provide the option to
   create a new identity.

   The primary benefit from distributed identity is that if the website
   allows, Alice can choose whatever identity she wishes to use.  For
   example if a business partner has granted her access to some
   collaboration site, she can use her work identity even if the site is
   in a completely different organization.  Alice can choose to use the
   same personal identity for many of the sites she shops at, or she can
   choose to use different identities in order to minimize sites'
   ability to correlate what she is doing.  She can even choose to use
   multiple identities within a single site if she wants that level of

3.1.  Roaming and Local State

   Alice's computer may store information on which identity is typically
   used with which website.  However it is important that Alice be able
   to use her identities from any computer she finds herself at, without
   needing to bring special hardware or to configure the computer with

Hartman                 Expires December 16, 2006               [Page 5]
Internet-Draft      Distributed Identity for the Web           June 2006

   her identities.  Alice should be able to use an identity by knowing
   the name of the identity, the identity provider and of course the

   Special consideration needs to be given to how Alice knows that the
   local identity management UI is displayed on a computer that she is
   visiting.  On her local computer she has branded the identity
   management UI.

3.2.  Webdav and other HTTP Applications

   Alice needs to get the same experience when she uses HTTP
   applications besides websites.  Generally the identity management UI
   will be invoked when the server requires authentication instead of
   when she selects a login button, but besides that the experience will
   be the same.

Hartman                 Expires December 16, 2006               [Page 6]
Internet-Draft      Distributed Identity for the Web           June 2006

4.  Website Author Experience

   This section describes how distributed identity works for Bob, an
   author of a website.

   Bob wants to add support for distributed identity to his website.
   His server software does already support distributed identity.

   Bob adds a new form control to his login page.  He can choose one of
   three ways to select which identities users may use:

   1.  Any identity

   2.  Any identity from a set of identity providers specified by Bob

   3.  Any identity from a single identity provider that Bob specifies

   Bob can also specify branding for his site to be included in the
   local identity management UI.  In the interests of extensibility Bob
   can specify which distributed identity management mechanisms he

   In the interests of incremental deployment, Bob needs to be able to
   use Javascript or some other mechanism to provide a page that works
   both with traditional authentication and with distributed identity.

   If Bob runs a webdav server or some other HTTP application, he sends
   the same information but it is carried in the HTTP response
   requesting authentication instead of in an HTML page.  It is
   important that future extensions to distributed identity keep the
   parameters that can be specified in HTTP and HTML in sync.

Hartman                 Expires December 16, 2006               [Page 7]
Internet-Draft      Distributed Identity for the Web           June 2006

5.  A Proposed Solution

   This section proposes a concrete way to achieve distributed identity.
   The goals of this proposal are as follows:

   1.  Demonstrate that distributed identity can be achieved with
       incremental improvements to existing protocols and technology.

   2.  Establish a minimum level of detail that needs to be specified to
       propose a solution and show that it is workable.

   3.  Propose a solution the author believes is the best compromise
       between deployability and meeting the requirements.

   The solution is comprised of four related components.  HTTP negotiate
   [MSNEGOTIATE] (GSS-API [RFC2743]) authentication is used to carry
   security data from the browser or client application to the server
   and to carry security response information back.  Kerberos [RFC4120]
   [RFC4121] is used as a way to separate the interactions with the
   identity provider from the interactions with the HTTP server.  In
   effect, Kerberos provides the distributed identity.  Security
   Assertion Markup Language (SAML) is used to carry assertions (claims)
   about the identity.  The browser or client UI is used to let the user
   know in a trusted manner that their password is being given to an
   identity manager on their local system rather than sent in the clear
   to the remote server.

5.1.  Negotiate Authentication

   HTTP negotiate [MSNEGOTIATE] authentication has been very successful
   at providing enterprise websites with a limited form of distributed
   identity.  Enterprise users can log into their operating system and
   then are authenticated to websites with no additional work.  While
   this protocol was originally introduced for Microsoft it has been
   adopted by several major browsers, Webdav libraries, web servers and
   operating systems.  Negotiate authentication has enjoyed wide
   deployment in enterprises--possibly greater than digest
   authentication [RFC2617].  The negotiate authentication method
   typically provides a better user experience than the digest method
   because except in error cases, no dialogue or user interaction is
   required.  One significant problem with basic and digest HTTP
   authentication is that at least today, they provide a interface very
   different from the rest of the website by popping up a local
   dialogue; options for forgotten passwords, new accounts or help are
   not typically available.

   In the optimal case, the negotiate method will not add any round
   trips to the HTTP exchange.  If the client knows that negotiate

Hartman                 Expires December 16, 2006               [Page 8]
Internet-Draft      Distributed Identity for the Web           June 2006

   authentication is needed (for example via an HTML extension like the
   one contemplated in Section 4), then the client can include the first
   negotiate message in the with its HTTP request.  For the case of
   Kerberos [RFC4121], only one round trip is required so no round trips
   are added.  Additional round trips may be required if other
   mechanisms are used.

   While negotiate exists today, incremental improvements are required
   to get an ideal user experience.  The following improvements would be

   1.  Create a standards track version of the negotiate protocol.  It
       is likely necessary to change the name used in the HTTP
       authentication request in order to gain change control and to add
       extensibility.  Work is already under way to do this as an
       individual submission.

   2.  Currently negotiate assumes that servers maintain context if more
       than one round trip is required.  This is unacceptable for some
       HTTP deployments.  Add support for the client to return an opaque
       context to the server for multi-round-trip negotiation.

   3.  Currently there is not a well defined way in HTTP to authenticate
       before sending a request.  In the case of PUT requests or other
       requests with confidential data it would be desirable to
       authenticate first.  Add support for this.

   4.  Provide some mechanism for carrying hints about the identity that
       is used.  As discussed in Section 5.2, servers may have many
       identities.  Some GSS-API implementations will be much easier to
       use if the server's identity is made available to the server as
       part of the HTTP request.

5.2.  Kerberos

   Kerberos provides separation between the identity provider and the
   relying party.  In effect, Kerberos allows the identity to be
   distributed.  Kerberos deployments have scaled to sizes comparable to
   those anticipated for Internet identity providers.

   Kerberos has two exchanges that are relevant to distributed identity.
   The first exchange is the authentication server (AS) exchange
   [RFC4120] which is an exchange between the identity provider and
   client.  This exchange has a mode described in RFC 4120 that is a
   traditional challenge/response authentication system [IABAUTH].
   Authentication based on public key certificates [RFC4556] can also be
   performed using the AS exchange.  Modes of the AS exchange for token
   cards and for zero-knowledge password protocols have been implemented

Hartman                 Expires December 16, 2006               [Page 9]
Internet-Draft      Distributed Identity for the Web           June 2006

   but not standardized.

   The second exchange is the ap-req exchange used to authenticate to
   the relying party.  This exchange is carried in HTTP authentication
   using the negotiate mechanism.

   A feature of Kerberos called authorization data can be used to carry
   Security Assertion Markup Language (SAML) assertions.  Since the
   assertions are carried in the ticket, Kerberos' existing mechanisms
   can be used to protect and authenticate the assertions when the
   Kerberos server (KDC) is the SAML Authority.  This will be much
   easier to deploy than XML signatures.  Of course XML signature can
   still be used for assertions made by parties other than the KDC.

   Kerberos authenticates a client to a given server.  Kerberos has
   mechanisms for cross-realm authentication where a client in one realm
   (Kerberos namespace) can authenticate to a server in another realm.
   While this mechanism can be used with distributed identity when the
   necessary cross-realm relationships exist, distributed identity
   cannot depend on being able to establish cross-realm relationships.
   A cross-realm relationship implies that the client realm believes
   that the KDC of the server realm is responsible for authentication to
   any server in that realm's namespace.  Unfortunately, there is no
   easy way to know which servers belong to a given realm's namespace.
   So, it will generally be easier to deploy systems where servers have
   multiple Kerberos principals--one for each identity provider they
   accept.  Since servers only accept identity providers when they have
   a relationship with someone using that identity provider, then this
   will not typically involve more than constant increase in state
   servers already maintain for each user.  In several important
   situations including servers that accept a specified set of identity
   providers, significantly less state is required.

   Kerberos is a good match for many of distributed identity's needs.
   However incremental improvement is required in the following ways:

   1.  Provide a standardized mechanism for enrolling an identity in a
       Kerberos realm.  This is needed so Alice's local identity
       management UI can create identities.

   2.  Develop a mechanism for enrolling a Kerberos server into a realm
       based on a public-key credential or other non-Kerberos
       credential.  This is needed so that servers can start accepting
       identities from a particular identity provider.  In cases where
       the identity provider is willing to register any server and the
       server is willing to accept any identity provider, this operation
       needs to be something Alice's browser can do automatically.

Hartman                 Expires December 16, 2006              [Page 10]
Internet-Draft      Distributed Identity for the Web           June 2006

   3.  Kerberos in the enterprise is focused on single sign-on.  Users
       should type their password or present a smart card at login and
       then should have network credentials cached.  This is desirable
       from a usability standpoint.  However security policies of some
       sites--particularly financial sites--require that the user has
       recently authenticated.  Such sites will often time out a session
       after a few minutes to avoid problems where a user has left a
       computer unattended.  Kerberos has an integrity-protected
       mechanism to report when the user actually authenticated to the
       KDC but no standardized mechanism to allow a server to request a
       new authentication be performed without using cached tickets.

   4.  An authorization data element needs to be defined to carry SAML

   5.  An HTTP transport for Kerberos should be defined.  Currently,
       Kerberos runs over TCP and UDP.  If Kerberos is going to be used
       for web authentication and HTTP transport is required so that
       Kerberos has the same firewall traversal properties as HTTP.

5.3.  Security Assertion Markup Language

   People often desire to use distributed identity systems to convey
   information such as name and age about a subject to the relying
   party.  SAML is proposed as a mechanism to do this.  In order to use
   SAML, a profile of SAML for this application needs to be created.
   Such a profile would need to specify:

   1.  What claims need to be supported

   2.  How third-party and KDC-issued claims are mixed

   3.  How clients request particular claims

   An alternative that has been proposed is a SAML GSS-API mechanism
   that wraps the Kerberos mechanism.  The problem with this approach is
   that only the KDC and server share the service key ticket.  So,
   unless the SAML is inside the Kerberos ticket, then the client is
   responsible for binding the SAML assertions to the Kerberos exchange
   and proving that the assertions apply to the client.  This would
   typically require XML digital signatures be used for all assertions--
   not just third-party claims.  That would increase code complexity and
   deployment complexity.

5.4.  Local Browser UI

   The local browser UI is critical to the security of any web
   authentication system.  The primary purpose of browser UI extensions

Hartman                 Expires December 16, 2006              [Page 11]
Internet-Draft      Distributed Identity for the Web           June 2006

   is to let a user know whether they are typing a password into a local
   system or sending the password over the network.  The phishing
   requirements document [PHISHING] discusses UI requirements in more

   Specification of the UI is outside the scope of the IETF.  However
   the IETF should be involved in discussing security requirements for
   the UI, such as the need to distinguish between passwords entered
   locally and passwords sent over the net.  The IETF also needs to be
   involved in discussing abstract requirements for the inputs and
   output of the UI such as those discussed in Section 4.

Hartman                 Expires December 16, 2006              [Page 12]
Internet-Draft      Distributed Identity for the Web           June 2006

6.  Security Considerations

   All the security considerations discussed in [PHISHING] apply to the
   specific proposal in this document.

   The security of HTML extensions proposed in Section 4 needs to be
   carefully considered.  IN particular, any concrete set of extensions
   needs to be analyzed for possible vulnerabilities when an attacker
   can modify the HTML elements used to signal distributed identity.

   As discussed in Section 5.2, Kerberos needs to be extended to support
   enrollment of new identities.  The security of these extensions will
   be critical to the security of the entire system.  Often, identity
   providers will allow new identities to be enrolled without
   authentication.  This allows the identity provider to confirm that
   subsequent uses of the identity correspond to the same subject but
   not to confirm that the identity corresponds to some particular real-
   world subject.  This is reasonable provided that relying parties do
   not place inappropriate trust in information claimed about the
   subject.  IN particular, relying parties need to make sure that they
   have sufficient confidence the identity corresponds to the intended
   subject before granting access to that identity.  Similarly the
   relying party needs to confirm that it has sufficient confidence in
   policies and procedures used to run an identity provider.

   Similar concerns exist for enrollment of servers into a Kerberos
   realm.  A denial of service condition exists if servers are weakly
   authenticated before being allowed to join a realm and an attacker is
   able to prevent the real server from joining by joining a spoofed
   server.  In addition, if users connect to a spoofed server expecting
   to be connecting to the real server, they may disclose confidential
   information to that server.  However the server authentication
   provided by TLS will tend to mitigate this attack when distributed
   identity is used in conjunction with HTTP over TLS.  Also, identity
   providers wishing to provide a high degree of trust should not weakly
   authenticate servers before allowing those servers to accept

Hartman                 Expires December 16, 2006              [Page 13]
Internet-Draft      Distributed Identity for the Web           June 2006

7.  References

7.1.  Normative References

   [LAWS]     "Laws of Identity", 2006.

              Jaganathan, K., Zhu, L., and J. Brezak, "Kerberos Based
              HTTP Authentication in Windows",
              draft-jaganathan-kerberos-http-01.txt (work in progress),
              July 2005.

              Hartman, S., "Requirements for Web Authentication
              Resistant to Phishing", May 2006.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface Version 2, Update 1", RFC 2743, January 2000.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              July 2005.

   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
              Version 5 Generic Security Service Application Program
              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
              July 2005.

7.2.  Informative References

   [IABAUTH]  Rescorla, E., "A Survey of Authentication Mechanisms",
              draft-iab-auth-mech-05.txt (work in progress),
              February 2006.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial

Hartman                 Expires December 16, 2006              [Page 14]
Internet-Draft      Distributed Identity for the Web           June 2006

              Authentication in Kerberos", rfc 4556, June 2006.

Hartman                 Expires December 16, 2006              [Page 15]
Internet-Draft      Distributed Identity for the Web           June 2006

Author's Address

   Sam Hartman
   Massachusetts Institute of Technology


Hartman                 Expires December 16, 2006              [Page 16]
Internet-Draft      Distributed Identity for the Web           June 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Hartman                 Expires December 16, 2006              [Page 17]