Internet Draft V. Torvinen Document: draft-torvinen-http-eap-00.txt J. Arkko Expires: January, 2002 Ericsson A. Niemi Nokia June 2001 HTTP Authentication with EAP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Abstract This document describes HTTP authentication scheme using PPP Extensible Authentication Protocol (EAP). HTTP EAP authentication enables HTTP connections to be authenticated using any of the authentication schemes supported through EAP. EAP performs the authentication without sending the password in the clear text format (which is the biggest weakness of the Basic HTTP authentication scheme, for example). It is useful for HTTP protocol because it opens up several new authentication schemes without additional specification work. The same benefits can be reached by any other protocol, which apply the HTTP authentication scheme, such as Session Initiation Protocol (SIP). Torvinen et al Informational HTTP Authentication with EAP June 2001 Table of Contents Status of this Memo 1 Abstract 1 Table of Contents 2 Conventions used in this document 2 1 Introduction 3 2 HTTP EAP Authentication Scheme 3 2.1 The WWW-Authenticate Response Header 5 2.2 The Authorization Request Header 7 2.3 Authentication-Info Response Header 7 3 Security Considerations 8 References 11 Author's Addresses 11 Conventions used in this document 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 [1]. Torvinen et al Informational HTTP Authentication with EAP June 2001 1 Introduction HTTP Authentication framework includes two authentication schemes: Basic and Digest [2]. In the Basic scheme, the client authenticates itself with a user-ID and a password for each realm. Basic scheme is perceived as insecure since the user credentials are transformed across the public network in a cleartext format. The Digest scheme is based on cryptographic hashes and it is perceived consequently as more secure authentication scheme than Basic, but is limited to the use of passwords. See [2] for detailed information about the general HTTP authentication protocol. The PPP Extensible Authentication Protocol (EAP) is a general protocol for PPP authentication [3]. Even though EAP was originally developed as a link layer protocol, it can be applied at application layer, too. EAP supports multiple authentication mechanism (e.g. smart cards, Kerberos, Public Key, One Time Passwords, and others) and it can, by definition, be easily extended to support new authentication mechanisms [see e.g. 4, 5, 6, 7]. EAP packets are defined in a binary format, and their contents depend highly on the used authentication scheme. HTTP EAP Authentication Scheme supplements HTTP Authentication with EAP functionality. This opens up several new authentication schemes for HTTP Authentication without additional specification work. 2 HTTP EAP Authentication Scheme HTTP EAP Authentication Scheme delivers base64 encoded EAP packets within HTTP Authentication headers (e.g. Authorization Request headers and WWW-Authenticate Response headers). EAP packets include all relevant information about the required authentication scheme, e.g. authentication scheme, packet type (request, response, success or failure) and/or challenge. The content of these packets is up to the chosen EAP authentication scheme. The progression of an authentication procedure depends also on the chosen authentication mechanism. Typically, the authenticator sends an initial Identity Request followed by one or more Requests for authentication information. The peer sends a Response packet in reply to each Request. As with the Request packet, the Response packet contains a type field, which corresponds to the type field of the Request. The authenticator ends the authentication phase with a Success or Failure packet. See Figure 1. Torvinen et al Informational HTTP Authentication with EAP June 2001 User agent Server GET --------------------------------------------------------> 401 Unauthorized, WWW-Authenticate: EAP <EAP ID REQ> <-------------------------------------------------------- Authorization: EAP <EAP ID RESP> --------------------------------------------------------> 401 Unauthorized, WWW-Authenticate: EAP <EAP CHALLENGE> <-------------------------------------------------------- Authorization: EAP <EAP RESP> --------------------------------------------------------> 200 OK, Authentication-Info: EAP <EAP SUCCESS> <-------------------------------------------------------- Figure 1. HTTP EAP Authentication message flow This message flow above represents only the typical situation. Variations of the flow are also possible in the following situations: - The chosen authentication mechanism requires more than the single challenge-response message pair shown. Any number of message exchanges are allowed here. - Error situations result in terminating the flow from the server's side with an error response. This response could be one of 401 Unauthorized, 403 Forbidden, or 407 Proxy Authentication Required. For 401 and 407, the client distinguishes the error situation from the continuation of the EAP exchange by the existence of EAP FAILURE payload, or the lack of any EAP payload. - Error situations from the client's side result in terminating the communications with the server. - Certain EAP authentication mechanisms such as [7] allow an optimized flow where identity request does not need to be sent. In these cases, if the client knows it will be demanded EAP authentication, it can include an unsolicited EAP ID RESP already in the GET message. This would enable the server to start the actual authentication exchange immediately. Torvinen et al Informational HTTP Authentication with EAP June 2001 - EAP authentication was shown to be run towards the server which responds with 401 Unauthorized responses. It is also possible to run towards a proxy, which responds with 407 Proxy Authentication Required responses. In this document, we define three new header types for HTTP authentication framework. These headers, WWW-Authenticate Response Header, Authorization Request Header and Authentication-Info Response Header, are needed for making EAP as an independent HTTP authentication scheme. 2.1 The WWW-Authenticate Response Header The general HTTP authentication framework uses an extensible, case- insensitive token to identify the authentication scheme. Authentication scheme identifier is followed by a comma-separated list of attribute-value pairs, which carry the parameters necessary for achieving authentication via that scheme. auth-scheme = token auth-param = token "=" ( token | quoted-string ) If a server receives a request for an access-protected object without acceptable Authorization header, the server responds with a "401 Unauthorized" status code, a WWW-Authenticate header and at least one challenge applicable to the requested resource. Proxy acts in the same way but it uses "407 Proxy Authentication Required" status code instead. challenge = auth-scheme 1*SP 1#auth-param The authentication parameter realm is defined for all authentication schemes: realm = "realm" "=" realm-value realm-value = quoted-string The realm value and the canonical root URL of the server being accessed define the protection space. The realm value (case- sensitive) is a string, which may have additional semantics specific to the authentication scheme. For HTTP EAP Authentication, the framework above is utilized as follows: Torvinen et al Informational HTTP Authentication with EAP June 2001 challenge = "eap" eap-challenge eap-challenge = 1#([realm] | eap-param) realm = "realm" "=" realm-value realm-value = quoted-string eap-param = "eap-p" "=" eap-packet eap-packet = <base64 encoded eap-packet, except not limited to 76 char/line> Realm is made optional because EAP notification mechanism can be used as well [3]. If realm value is present, it should be considered as an opaque string, which can only be compared for equality with other realms on that server. The server will service the request only if it can validate the user credentials for the protection space of the Request-URI. EAP packets have a general structure consisting of four basic fields: code, identifier, length and data. Code field is one octet and it identifies the type of EAP packet. Packet type is a request, response, success, or failure. Identifier field is also one octet and it is used for matching responses with corresponding requests. Length field is two octets and it indicates the whole EAP packet including code, identifier, length and data fields. Data field is zero or more octets and its format depends on the content of code field. Example below demonstrates the general structure of EAP packets. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ All these fields (Code, Identifier, Length, and Data) are included in the eap-packet in base64 form. Note that since the packets are self-identifying and self-delimiting it is allowed to include multiple EAP packets within one eap-packet, should some EAP mechanism be able to benefit from this. Example below demonstrates how WWW-Authenticate Response Header using EAP authentication would look like: WWW-Authenticate: eap realm="BollyWorld", eap-p=QWxh4ZGRpb2jpvcGVuNlctZQ== Torvinen et al Informational HTTP Authentication with EAP June 2001 where "BollyWorld" is the string assigned by the server to identify the protection space of the Request-URI. A proxy may respond with the same challenge using the Proxy- Authenticate header field. 2.2 The Authorization Request Header In the general HTTP authentication framework, a user agent that wishes to authenticate itself with an origin server or a proxy MAY do so by including an Authorization header or a Proxy- Authorization header field with the request. The authorization field value(s) consists of credentials containing the authentication information of the client for the realm of the resource being requested. The user agent must apply the strongest authentication scheme it understands and request credentials from the user based upon corresponding challenge. credentials = auth-scheme #auth-param For HTTP EAP Authentication, the framework above is utilized as follows: credentials = "eap" eap-packet eap-packet = <base64 encoded eap-packet, except not limited to 76 char/line> Example below demonstrates how the Authorization Request Header using EAP authentication would look like: Authorization: eap QWxhZGRpbjpvcGVuIHNlc2FtZQ== Rules for handling potential user identifiers, passwords, challenges and so on, are defined in EAP protocol [3]. 2.3 Authentication-Info Response Header The Authentication-Info header is used by the server to communicate information back to the client. This can be either the successful authentication in the response, or the continuation of the EAP mechanism. Torvinen et al Informational HTTP Authentication with EAP June 2001 auth-info = #auth-param For HTTP EAP authentication the framework above is utilized as follows: auth-info = eap-packet eap-packet = <base64 encoded eap-packet, except not limited to 76 char/line> Example below demonstrates how the Authentication-Info Response Header using EAP authentication would look like: Authentication-Info: QWxhZGRpbjpvcGVuIHNlc2FtZQ== The semantics of Proxy-Authentication-Info follow those of Authentication-Info. Proxy-Authentication-Info is used by proxy servers in conjunction with the "407 Proxy Authentication Required" response, and the consequent client authorization request. 3 Security Considerations Very little about the security of HTTP EAP Authentication can be stated without knowing the chosen EAP authentication scheme. Generally speaking, depending on the chosen EAP authentication scheme, HTTP EAP is subject to the same security threats as HTTP Authentication. However, there are some general aspects, which SHOULD be considered when analyzing the security of HTTP EAP Authentication: 1) Authentication of clients: All EAP mechanisms authenticate the client, using a method dependent on the mechanism. 2) Authentication of servers: Some EAP mechanisms perform also mutual authentication. 3) Using the strongest authentication mechanism: Servers and clients accepting multiple authentication mechanisms should be aware of the possibility of `bidding-down' attacks where a man- in-the-middle modifies authentication offers until the peers agree on an easily breakable mechanism. In general, we expect HTTP EAP _based servers to require a predefined authentication mechanism from a particular client in any case, which avoids this problem. For instance, the user data base at a server indicates that user A has a particular public key. The server should then insist on using the EAP TLS [4] mechanism to authenticate the user. 4) Confidentiality: Each EAP mechanism offers its specific protection schemes for the exchanged credentials. For instance, Torvinen et al Informational HTTP Authentication with EAP June 2001 the EAP AKA [7] mechanism sends secure cryptographic hashes rather than cleartext passwords like HTTP Basic Authentication does, even if both are based on the concept of a shared secret. As in EAP in general, HTTP EAP does not protect against revealing the identity of the client since the EAP ID RESP packets are not encrypted. Confidentiality and integrity of the HTTP requests themselves beyond on the authentication parameters is not within the scope of HTTP EAP, but is discussed below under item 7. 5) Replay protection: Each EAP mechanism offers its specific protection schemes for preventing the replay of the credentials. For instance, the EAP AKA mechanism uses a cryptographically strong sequence number scheme. This is in contrast to the replay possibilities that exist for the HTTP Basic Authentication, and is similar to the use of nonces in the HTTP Digest Authentication. 6) Integrity protection: Again, each EAP mechanism offers its specific protection against a man-in-the-middle modifying the authentication credentials. Mechanisms based on secure hashes prevent any modifications to the authentication parameters themselves. Again, integrity of the HTTP requests themselves beyond the authentication parameters is a separate issue and is discussed below. 7) Integrity and confidentiality protection of the HTTP request itself is also an important issue. Without such protection, it is possible for a man-in-the-middle to read and modify the actual contents of the request, regardless of any authentication that was performed Currently, there is no such authentication scheme in HTTP authentication, which would fully protect the integrity of HTTP messages. HTTP Basic Authentication scheme provides no integrity protection. HTTP Digest Authentication provides only limited (and optional) protection. Most header fields and their values could be modified as a part of a man-in-the-middle attack. It should also be noted that HTTP EAP does not inherently provide the integrity protection qualities present in Digest, namely the protection of Request-URI and request- method (and possibly the payload). Even though HTTP EAP Authentication scheme does not include a protection mechanism, it can be used for setting up one. Chosen EAP authentication scheme may be used to generate session keys, which together with some additional security protocol can provide e.g. integrity protection. Torvinen et al Informational HTTP Authentication with EAP June 2001 However, such protection should include the protection of original HTTP requests as well. This is not trivial because session protection keys are generated during the authentication, which takes place after submitting the request. In practice, full protection is only possible if the request is repeated at the end of the authentication procedure. This is, however, already the behavior in many typical usage situations. For instance, when authenticating a SIP REGISTER message, the authentication procedure takes a few message rounds, and on each round the REGISTER message is repeated until the session keys are available and the procedure is completed. The last such message can then use integrity protection. Servers that want to avoid man-in-the-middle attacks MUST NOT act on requests until both the authentication procedure has completed and the messages have been received under integrity protection. Torvinen et al Informational 1 HTTP Authentication with EAP June 2001 References 1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2 Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and Stewart, L. "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. 3 Blunk, L. and Vollbrecht, J. "PPP Extensible Authentication Protocol (EAP)" RFC 2284, March 1998. 4 Aboba, B. and Simon, D. "PPP EAP TLS Authentication Protocol" RFC 2716, October 1999. 5 Aboba, B. "EAP GSS Authentication Protocol" Internet Draft, draft-aboba-pppext-eapgss-03.txt, February 2001. 6 Carlson, J. "PPP EAP SRP-SHA1 Authentication Protocol" Internet Draft, draft-ietf-pppext-eap-srp-01.txt, May 2001. 7 Arkko, J. and Haverinen, H. "EAP AKA Authentication" Internet Draft, draft-arkko-pppext-eap-aka-00.txt, May 2001. Acknowledgements The authors wish to thank Henry Haverinen and Bernard Aboba for interesting discussions in this problem space. Author's Addresses Jari Arkko Ericsson 02420 Jorvas Phone: +358 40 5079256 Finland Email: jari.arkko@ericsson.fi Vesa Torvinen Ericsson 02420 Jorvas Phone: +358 40 7230822 Finland Email: vesa.torvinen@ericsson.fi Aki Niemi Nokia Networks P.O. Box 301 00045 Nokia Group Phone: +358 50 3891644 Finland E-mail: aki.niemi@nokia.com