Internet Engineering Task Force Y. Oiwa Internet-Draft RCIS, AIST Intended status: Informational T. Hayashi Expires: January 6, 2012 B. Kihara Lepidum July 5, 2011 HTTP authentication: problem statement draft-oiwa-http-auth-problem-statement-00 Abstract This document discusses about existing problems in the current authentication technologies around HTTP and some analysis of the requirements for future authentication technologies in HTTP area. 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 6, 2012. Copyright Notice Copyright (c) 2011 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Oiwa, et al. Expires January 6, 2012 [Page 1] Internet-Draft HTTP auth problem statement July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Existing authentication mechanisms . . . . . . . . . . . . . . 4 3. Background: existing threats and contributing factors . . . . 4 3.1. Impersonation of server identity (Phishing) . . . . . . . 4 3.2. Impacts of server-side password database leakage . . . . . 4 3.3. Impacts of complex authentication/authorization technologies . . . . . . . . . . . . . . . . . . . . . . . 5 4. Applicable fields for HTTP authentication . . . . . . . . . . 5 4.1. Web user authentication . . . . . . . . . . . . . . . . . 5 4.2. Web client application data accesses . . . . . . . . . . . 6 4.3. Non-Web user authentication . . . . . . . . . . . . . . . 7 5. Problem statements . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Lack of mutual authentication . . . . . . . . . . . . . . 7 5.2. Avoiding use of plain-text passwords on authentication . . 8 5.3. Functional weakness of HTTP authentication framework . . . 9 5.4. Lack of bindings between multi-layer authentications/authorizations . . . . . . . . . . . . . . 9 6. More topics . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Oiwa, et al. Expires January 6, 2012 [Page 2] Internet-Draft HTTP auth problem statement July 2011 1. Introduction User authentication is, needless to say, one of the most important building block for the Web applications and other Internet-based systems. As social activities and commerce systems are more and more widely spreading, the importance for the security of the authentication also increase. Furthermore, the recent movement of providing government services on the Web requires user authentication as a key feature. Impersonation of client users in such systems may cause unrecoverable damages such as loss of credits, trusts, or social statuses. At the same time, the authentication is currently one of the weakest blocks in terms of security. Intrinsically, the Web system as a whole is a multi-party system where the malicious servers cannot be rejected from the world. Unlike other systems such as email (POP [RFC1939] or IMAP [RFC3501]) or VPN (IPsec [RFC4301], L2TP [RFC2661] etc.) where the communication peer is typically pre-configured in the client software, Web clients (Web browsers) communicate with any party which the user insists to. This property leaves malicious servers to forge users to communicate with himself and performs a fiddle with the victim. Once such an attack succeeds, its result is severe: not only user's passwords to be stolen, users are often fooled to provide more critical information such as credit card numbers to the attackers. On contrary to the current design, the authentication on the Web systems should be bidirectional and mutual: not only the authenticity of the users, but the authenticity and integrity of the servers is really important for protecting user resource stored on the server side. Most users assume that the successful user authentication also implies that they are talking with the genuine server entity: unfortunately, for almost all currently-deployed technologies on Web authentication this is not true, even for the TLS [RFC5246] client certificate authentication. The motivation of this document is to promote ideas of replacing current systems and mechanisms for authentications on the HTTP/Web systems by more secure building blocks which are carefully designed for both security and usability/deployability. In the following sections, currently available methods of authentication on the Web systems are reviewed, and existing problems are discussed. At last, we conclude with possible action plan proposals for the community. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and Oiwa, et al. Expires January 6, 2012 [Page 3] Internet-Draft HTTP auth problem statement July 2011 "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Existing authentication mechanisms (To be described) 3. Background: existing threats and contributing factors 3.1. Impersonation of server identity (Phishing) The term "Phishing" here is used as a generic term of attacks involving some kind of spoofing or impersonation used to socially/ technically fool the victim users. From the beginning of the Web system, such "false web sites" are considered as a problem. TLS and its predecessor, SSL, have introduced a PKI-based server identity checking [RFC3647] using trusted certificate authorities (CAs) to address this issue. However, more and more sensitive and valuable information Web systems become to handle, more and more the Phishing attacks become "useful" attack vector. Such Phishing sites typically steal user identity and plain-text passwords from the victim user, and use it to either access sensitive data (such as Web mail services for critical officers), to fool users to provide more sensitive informations to the attackers (such as credit card numbers), or to impersonate victims with a malicious social activities (such as selling stolen items in a net auction). 3.2. Impacts of server-side password database leakage Technically speaking, security of the server-side data is an out-of- scope issue for the HTTP authentication. However, we should be aware that many real-world security bleaches actually caused (partially) by the leakage of server-side stored information. Impact of such server-side leakage depends on how the authentication mechanism are designed. For Basic authentication [RFC2617], server-side credential used for password verification is usually one-way hashed with a random salt, which mitigates risk of server-side leakage a bit. Public key cryptography-based authentication, if correctly managed and deployed, can also avoid storing of sensitive client-credentials to the server-side. On the contrary, Digest authentication and other hash-based authentication schemes (e.g. CRAM-MD5 in SASL [RFC4422], APOP, etc.) requires raw client-side credentials to be stored in the server side by its nature. Of course, if all other properties are similar, the algorithms which do not require raw client credentials in server side is preferable as far as possible. Oiwa, et al. Expires January 6, 2012 [Page 4] Internet-Draft HTTP auth problem statement July 2011 3.3. Impacts of complex authentication/authorization technologies Recently, many complex framework for authentication and authorizations are deployed to realize multi-party authentication. For example, OpenID and SAML [OASIS.saml-core-2.0-os] gives servers an opportunity to authenticate users using identities provided by third parties. OAuth [RFC5849] allows a user to delegate some access rights to servers or other systems without giving client authentication credential itself. Introduction of such services can have both positive and negative impacts on the Web security. For example, federated multi-party authentication can reduce number of client credentials which are required to access many services, which can reduce risk of server- side information leakage. At the same time, it requires user to authenticate himself in dynamically-generated web pages in the middle of complex page redirection flows, which makes users difficult to discriminate whether the page is a correct one to input her user name and password, increasing risk of Phishing attacks. Detailed analysis of its security, including user experiences in its consideration, might be needed. Also, in such systems single security bleach among multiple parties involved to federated authentication may or may not impact security of other systems and their users. There are many pitfalls in implementation of such multi-party protocols, such as session fixation, session hijacking and cross-site request forgeries. Especially because most of those technologies are implemented often in application layer, careful observation and analysis of such bleaches caused by mis-implementation of a single party should be performed. 4. Applicable fields for HTTP authentication Nowadays HTTP is used as a common foundation for various systems including Web systems and other non-Web applications. Depending on the nature of each systems using HTTP, the required properties for the underlying authentication/authorization mechanism may vary. Although the comprehensive analysis of all existing applications are impossible, this document hereby proposes categorizing use cases to three typical groups as a starting point, for further analysis in the sections below. 4.1. Web user authentication The first group is to authenticate users of common Web applications, typically using Web browsers as clients. This group is very common Oiwa, et al. Expires January 6, 2012 [Page 5] Internet-Draft HTTP auth problem statement July 2011 use cases which exists from very early stage of HTTP, and the ones for which currently existing HTTP authentication mechanisms are designed. One of the most important security consideration in these scenarios is complex interactions between human users, browser clients and Websites including those of uncontrollable third-party entities. Phishing is a very common attack vector for this scenario, and without having some weapons against protecting authentication credentials and integrity, it is impossible to stop malicious phishers from deploying such attacks. Authentication credentials used for these scenarios varies for required authentication strength and several social factors, for example passwords, cryptographic secret keys, smart cards, one-time passwords, etc., but in most cases such credentials are belonging to human entities. There is several proposals for unified and federated authentications, but this principle does not change. 4.2. Web client application data accesses Recently, capability of client-side data processing in Web browser clients are greatly improved, and it introduced a new pattern of client-server relationship in Web applications: Web-application initiated data accesses. In ancient Web systems, clients are only communicating with the corresponding server providing the current Web page, and if some external data accesses are needed, the server will perform it, process the received data and serve the result to client as a static data embedded in Web contents. In this scheme, the user authentication mentioned above is only necessary, and all other authorization managements are performed in the server-side. However, evolution of client-side data processing changed the whole story. Now the client-side application can request authentication of itself as an agent of the human user, obtain authorization rights and access several data resources in various servers. Such authorization rights are not needed to be directly corresponding to the active human user's rights: it can be of another user's rights delegated to a user (like what the OAuth protocol [I-D.ietf-oauth-v2] provides), or it can be subset of what the user has access to. In this story, the authentication/authorization of client application are related but not directly connected to the human user's authentication. Some important points in this group might be flexibility: application-level authentication can be either related or unrelated to human entity, and same application may need to provide more than Oiwa, et al. Expires January 6, 2012 [Page 6] Internet-Draft HTTP auth problem statement July 2011 one methods of authentications in the same framework, possibly with different levels of authorizations. In this use cases, phishing is not always a key factor for threat analysis. If Web applications are itself faked and thus provided from phishing sites, the user cannot trust provided data regardless of whether the data resource servers accessed are trustful or not. On the contrary, provided Web applications are trustful, these programs typically (but not always) "know" what server is the correct server to interact. Some mutual and eavesdropping-safe authentication technologies are still useful, as many applications nowadays still need some communication in an unencrypted channels because of overhead of secure-channel provisions. 4.3. Non-Web user authentication The final group is use-cases for non-browser client applications. Nowadays HTTP is becoming a common vehicle for various applications including non-browser clients. Because of its simplicity, many existing services are providing both Web-client and non-Web API accesses using the same HTTP platform. We should not ignore such use cases when considering solutions for the above two groups. In some aspects, required features for this group of applications are subsets of the above two use cases. Simple user authentication may be mapped to an HTTP authentication scheme provided for the "Web user authentication", and some detailed authorization cases may be mapped to an access grant management used for "Web application authentication" stories. However, because we cannot rely on any aid from Web pages and scripts, some technologies for these groups may be not useful for non-Web applications, or careful design consideration may be needed for applying those to this group of use cases. For an instance, OAuth usually relies on Web-based authentication and page redirections, but to support non-Web application use cases it required some additional features as well. Also, integration with existing authentication framework such as SASL [RFC4422] or GSSAPI [RFC2743] might be important especially in this use cases. 5. Problem statements 5.1. Lack of mutual authentication Most authentication technologies which are currently used on Web systems are essentially one-directional. A server always checks authenticity of users using client authentication credential, but a user has little control of the process and a user can not know whether the talking peer is the intended entity, or they can not know Oiwa, et al. Expires January 6, 2012 [Page 7] Internet-Draft HTTP auth problem statement July 2011 whether the server is actually performing an authentication and has knowledge of the user. This has been a cause of many Phishing attack instances. All of HTTP Basic authentication, Digest authentication, HTML Form authentication and even TLS client certificate authentication fall into this category of technologies. TLS server authentication are thought to mitigate this factor, but it was too weak to prevent many Phishing attacks. The TLS server authentication only certifies that the server has (in some sense) a right to legitimately use the domain name that the client accessed, and optionally binds the server with some real-world entity. In fact, some phishing sites use their own domains with a valid server certificates, or others use a cracked servers with legitimate certificates to perform an attack. In this situation, the server authentication does not prevent Phishing technically, instead it relies on the careful manual investigation of domain names by an end user. For secure use of Web systems mutual authentication between users and servers has critical needs. By performing mutual authentication, a user can assure that the peer server has certainly performed an authentication, and that the peer has a prior knowledge of the user, eliminating possibility of man-in-the-middle attacks or false authentications. We should investigate possibilities of performing mutual authentication using various kinds of authentication credentials: passwords (weak secret), strong shared key, multi-factor credentials and even cryptographic public/private key pairs if possible. This requirement is mainly applicable for both Web and non-Web user authentication. For simple access patterns (where user authentication coincide with data access authorization), it may be also applicable for application data accesses (both Web and non-Web). 5.2. Avoiding use of plain-text passwords on authentication Two most widely used authentication technologies, Basic and Form- based authentication, uses plain-text passwords as credentials and send these directly on wire. Obviously, using those technologies without encryption will reveal any secret credentials to all eavesdroppers. Even if TLS encryption is used, on-wire plaintext passwords are vulnerable for Phishing and (Web application layer) man-in-the-middle attacks. This weakness is amplified when users are using a single password for several independent systems. Especially, using plaintext passwords in Form-based authentication required handling of passwords in a Web application layer, which has caused many password leakage accidents in many commercial websites. To avoid these problems, we need technologies which prevents leakage of reusable weak secret. Oiwa, et al. Expires January 6, 2012 [Page 8] Internet-Draft HTTP auth problem statement July 2011 This item applies to all of the previously-mentioned use cases. Especially when applications needs use of unencrypted channels for performance reasons, it is crucial to protect authentication credentials and tokens. 5.3. Functional weakness of HTTP authentication framework Current basic design of HTTP authentication framework [RFC2617] does not sufficiently provide the features which are required by current Web application logics. This is currently one of the biggest reason why many Web developers prefer HTML Form-based authentication more than HTTP Basic authentication. For example, current HTTP authentication framework lacks support for non-mandatory authentication (aka guest user support), and enforcement of login session termination (log-out control). It also removes application developers detailed control of user experiences, because most of interactive HTTP clients (Web browsers) uses a modal, interruptive dialog user interface for authentication. Some authentication schemes, notably TLS client certificate authentication are further worse, as a single server must serve a single set of authentication, and users can not use several identities simultaneously within one server. However, due to the nature of HTML form and UI designs, it is almost impossible to fundamentally improve security of Form authentication, mainly due to the fact UI of such authentication can be always faked and imitated. For example, if we had a secure input field for passwords in some HTML extensions, Phishers would simply forge it with usual password field instead to steal any passwords inputs. To avoid this problem, the user agent (browsers) and the HTTP protocol must serve a role of securely handling authentication and user credentials. To make use of such agent-driven authentication in real applications, the authentication framework should be flexible enough so that the application developers can realize any application logics they require for the user and session managements. This requirement is mainly applicable for browser-based Web user authentication. The provision of such features should be compatible with other use cases, however. 5.4. Lack of bindings between multi-layer authentications/ authorizations Many recent Web applications are implemented in multi-layer technologies and each layer often has own control of authentication and authorization. For example, OAuth [I-D.ietf-oauth-v2] enables application-level delegated access authorization using credentials issued on another authentication/authorization framework. W3C Oiwa, et al. Expires January 6, 2012 [Page 9] Internet-Draft HTTP auth problem statement July 2011 proposed WebID uses result of TLS client authentication for control of upper-layer identification and authorization. The channel binding is a key technology to implement such multi-layer applications. Simply speaking, the channel binding is a technique which relates an upper-layer authentication with a result of lower-layer authentications/key-exchanges. By doing that, any result of upper- layer authentication can not be separately used on any other lower- layer channels which are not authenticated by the same way. For example, by using TLS channel binding [RFC5929] with a signed OAuth request, such request tokens can not be used by any other people to access the protected resources, even if the token has been leaked in some way. Unfortunately, current HTTP-layer authentication schemes does not provide functionality for such channel bindings. Future schemes should consider providing such binding functionality as its building blocks. (to be mentioned: OAuth HTTP MAC authentication [I-D.ietf-oauth-v2-http-mac]) 6. More topics (TBD) 7. IANA Considerations None. 8. Security Considerations This document obviously deals with security technologies. However, the purpose of this document is not to provide specific protocols or technologies to be directly implemented, but to discuss about current status of existing technologies and requirements for future technologies. Therefore, there is no specific security precautions to be mentioned here. When designing some specific technologies mentioned in this document, we MUST have careful consideration of security properties, because the technology area handled in this document has very complex and legacy characteristics and limitations. 9. References Oiwa, et al. Expires January 6, 2012 [Page 10] Internet-Draft HTTP auth problem statement July 2011 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [I-D.ietf-oauth-v2] Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 2.0 Authorization Protocol", draft-ietf-oauth-v2-16 (work in progress), May 2011. [I-D.ietf-oauth-v2-http-mac] Hammer-Lahav, E., Barth, A., and B. Adida, "HTTP Authentication: MAC Access Authentication", draft-ietf-oauth-v2-http-mac-00 (work in progress), May 2011. [OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core- 2.0-os, March 2005. [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [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. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Oiwa, et al. Expires January 6, 2012 [Page 11] Internet-Draft HTTP auth problem statement July 2011 Internet Protocol", RFC 4301, December 2005. [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, April 2010. [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010. Authors' Addresses Yutaka Oiwa National Institute of Advanced Industrial Science and Technology Research Center for Information Security AIST Tsukuba Headquarters' building Tsukuba Central 2 1-1-1 Umezono Tsukuba-shi, Ibaraki JP Phone: +81 29-861-5284 Email: mutual-auth-contact@m.aist.go.jp Tatsuya Hayashi Lepidum Co. Ltd. #602, Village Sasazuka 3 1-30-3 Sasazuka Shibuya-ku, Tokyo JP Boku Kihara Lepidum Co. Ltd. Oiwa, et al. Expires January 6, 2012 [Page 12]