Network Working Group S. Hartman Internet-Draft MIT Expires: December 16, 2006 June 14, 2006 Distributed Identity for the Web draft-hartman-webauth-00.txt 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- Drafts. 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 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 16, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract 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 [PHISHING]. 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 privacy. 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 password. 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 supports. 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 needed: 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 assertions. 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 detail. 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 identities. 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. [MSNEGOTIATE] Jaganathan, K., Zhu, L., and J. Brezak, "Kerberos Based HTTP Authentication in Windows", draft-jaganathan-kerberos-http-01.txt (work in progress), July 2005. [PHISHING] 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 Email: hartmans-ietf@mit.edu 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 http://www.ietf.org/ipr. 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 ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hartman Expires December 16, 2006 [Page 17]