INTERNET-DRAFT J. Arkko Document: draft-torvinen-http-eap-01.txt V. Torvinen Expires: May 2002 Ericsson A. Niemi Nokia November 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 RFC2026. 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 a 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). EAP 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 protocols, which apply HTTP authentication, such as Session Initiation Protocol (SIP). Table of Contents 1 Introduction.....................................................2 Torvinen et al 1 INTERNET-DRAFT HTTP Authentication with EAP November 2001 2 HTTP EAP Authentication Scheme...................................2 2.1 The WWW-Authenticate Response Header...........................4 2.2 The Authorization Request Header...............................6 2.3 Authentication-Info Response Header............................6 3 Security Considerations..........................................7 4 References.......................................................9 5 Acknowledgements.................................................9 6 Author's Addresses...............................................9 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] 1 Introduction The 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. The Basic scheme is perceived as insecure since the user credentials are transmitted across the public network in a cleartext format. The Digest scheme is based on cryptographic hashes and is consequently perceived as a 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 also be applied at the application layer. 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 The HTTP EAP Authentication Scheme delivers base64 encoded EAP packets within HTTP Authentication headers (e.g. WWW-Authenticate Response headers and Authorization Request 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. Torvinen et al Expires May 2002 2 INTERNET-DRAFT HTTP Authentication with EAP November 2001 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. 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 Torvinen et al Expires May 2002 3 INTERNET-DRAFT HTTP Authentication with EAP November 2001 in the GET message. This would enable the server to start the actual authentication exchange immediately. - 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 the 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 an 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. A Proxy acts in the same way but it uses a "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 directive (case-insensitive) is required for all authentication schemes that issue a challenge. 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: challenge = "Eap" eap-challenge eap-challenge = 1#(realm | eap-param) Torvinen et al Expires May 2002 4 INTERNET-DRAFT HTTP Authentication with EAP November 2001 realm = "realm" "=" <"> realm-value <"> realm-value = token [ "@" token ] eap-param = "eap-p" "=" <"> eap-packet <"> eap-packet = <base64 encoded eap-packet, except not limited to 76 char/line> The realm value SHOULD be globally unique. Proxy servers are RECOMMENDED to use globally unique realm values in order to be able to recognize their set of user credentials in a multi-proxy authentication scenario. Implementations MAY use the form "local- realm@host". The realm value 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. The Code field is one octet and it identifies the type of the EAP packet. Packet type is either a request, response, success, or failure. The Identifier field is also one octet and it is used for matching responses with corresponding requests. The Length field is two octets and it indicates in octects the length of the whole EAP packet including code, identifier, length and data fields. The Data field is zero or more octets and its format depends on the content of Code field. The 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 a WWW-Authenticate Response Header using EAP authentication would look like: WWW-Authenticate: eap realm="BollyWorld@example.com", eap-p="QWxh4ZGRpb2jpvcGVuNlctZQ==" where "BollyWorld" is the string assigned by the server to identify the protection space of the Request-URI at server "example.com". A proxy may respond with the same challenge using the Proxy- Authenticate header field. Then it is especially important to Torvinen et al Expires May 2002 5 INTERNET-DRAFT HTTP Authentication with EAP November 2001 maintain global uniqueness for the realm values, since a request may have credentials for multiple Proxy-Authenticate challenges. 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 to 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 the corresponding challenge. credentials = auth-scheme #auth-param For HTTP EAP Authentication, the framework above is utilized as follows: credentials = "Eap" eap-response eap-response = 1#( realm | eap-param ) eap-param = "eap-p" "=" eap-packet eap-packet = <base64 encoded eap-packet, except not limited to 76 char/line> The value of the realm field must be that supplied in the WWW- Authenticate or Proxy-Authenticate response header for the resource being requested. Example below demonstrates how the Authorization Request Header using EAP authentication would look like: Authorization: Eap realm="BollyWorld@example.com", eap-p="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. auth-info = #auth-param For HTTP EAP authentication the framework above is utilized as follows: Auth-info = eap-packet Torvinen et al Expires May 2002 6 INTERNET-DRAFT HTTP Authentication with EAP November 2001 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 also perform mutual authentication. 3) Using the strongest authentication mechanism available: Servers and clients accepting multiple authentication mechanisms should be aware of the possibility of 'bidding-down' attacks where a man-in-the-middle modifies the 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, 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 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 Torvinen et al Expires May 2002 7 INTERNET-DRAFT HTTP Authentication with EAP November 2001 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 schemes 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 are no such authentication schemes in HTTP authentication, which would fully protect the integrity of HTTP messages. The 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 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. 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 Expires May 2002 8 INTERNET-DRAFT HTTP Authentication with EAP November 2001 4 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. 5 Acknowledgements The authors wish to thank Henry Haverinen and Bernard Aboba for interesting discussions in this problem space. 6 Author's Addresses Jari Arkko Ericsson 02420 Jorvas Phone: +358 40 5079256 Finland Email: jari.arkko@ericsson.com Vesa Torvinen Ericsson 02420 Jorvas Phone: +358 40 7230822 Finland Email: vesa.torvinen@ericsson.com Aki Niemi Nokia Networks P.O. Box 301 00045 Nokia Group Phone: +358 50 3891644 Finland E-mail: aki.niemi@nokia.com Torvinen et al Expires May 2002 9