idnits 2.17.1 draft-torvinen-http-eap-01.txt: -(421): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(427): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 8 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 210: '... The realm value SHOULD be globally un...' RFC 2119 keyword, line 211: '... RECOMMENDED to use globally unique ...' RFC 2119 keyword, line 213: '... Implementations MAY use the form "loc...' RFC 2119 keyword, line 263: '...f with an origin server or a proxy MAY...' RFC 2119 keyword, line 268: '... agent MUST apply the strongest auth...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8196 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 64 looks like a reference -- Missing reference section? '2' on line 74 looks like a reference -- Missing reference section? '3' on line 294 looks like a reference -- Missing reference section? '7' on line 349 looks like a reference -- Missing reference section? '4' on line 345 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Arkko 3 Document: draft-torvinen-http-eap-01.txt V. Torvinen 4 Expires: May 2002 Ericsson 5 A. Niemi 6 Nokia 7 November 2001 9 HTTP Authentication with EAP 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes a HTTP authentication scheme using PPP 34 Extensible Authentication Protocol (EAP). 36 HTTP EAP authentication enables HTTP connections to be authenticated 37 using any of the authentication schemes supported through EAP. EAP 38 performs the authentication without sending the password in the 39 clear text format (which is the biggest weakness of the Basic HTTP 40 authentication scheme, for example). 42 EAP is useful for HTTP protocol because it opens up several new 43 authentication schemes without additional specification work. The 44 same benefits can be reached by any other protocols, which apply 45 HTTP authentication, such as Session Initiation Protocol (SIP). 47 Table of Contents 49 1 Introduction.....................................................2 50 2 HTTP EAP Authentication Scheme...................................2 51 2.1 The WWW-Authenticate Response Header...........................4 52 2.2 The Authorization Request Header...............................6 53 2.3 Authentication-Info Response Header............................6 54 3 Security Considerations..........................................7 55 4 References.......................................................9 56 5 Acknowledgements.................................................9 57 6 Author's Addresses...............................................9 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 63 this document are to be interpreted as described in RFC-2119 [1] 65 1 Introduction 67 The HTTP Authentication framework includes two authentication 68 schemes: Basic and Digest [2]. In the Basic scheme, the client 69 authenticates itself with a user-ID and a password for each realm. 70 The Basic scheme is perceived as insecure since the user credentials 71 are transmitted across the public network in a cleartext format. The 72 Digest scheme is based on cryptographic hashes and is consequently 73 perceived as a more secure authentication scheme than Basic, but is 74 limited to the use of passwords. See [2] for detailed information 75 about the general HTTP authentication protocol. 77 The PPP Extensible Authentication Protocol (EAP) is a general 78 protocol for PPP authentication [3]. Even though EAP was originally 79 developed as a link layer protocol, it can also be applied at the 80 application layer. EAP supports multiple authentication mechanism 81 (e.g. smart cards, Kerberos, Public Key, One Time Passwords, and 82 others) and it can, by definition, be easily extended to support new 83 authentication mechanisms [see e.g. 4, 5, 6, 7]. EAP packets are 84 defined in a binary format, and their contents depend highly on the 85 used authentication scheme. 87 HTTP EAP Authentication Scheme supplements HTTP Authentication with 88 EAP functionality. This opens up several new authentication schemes 89 for HTTP Authentication without additional specification work. 91 2 HTTP EAP Authentication Scheme 93 The HTTP EAP Authentication Scheme delivers base64 encoded EAP 94 packets within HTTP Authentication headers (e.g. WWW-Authenticate 95 Response headers and Authorization Request headers). EAP packets 96 include all relevant information about the required authentication 97 scheme, e.g. authentication scheme, packet type (request, response, 98 success or failure) and/or challenge. The content of these packets 99 is up to the chosen EAP authentication scheme. 101 The progression of an authentication procedure depends also on the 102 chosen authentication mechanism. Typically, the authenticator sends 103 an initial Identity Request followed by one or more Requests for 104 authentication information. The peer sends a Response packet in 105 reply to each Request. As with the Request packet, the Response 106 packet contains a type field, which corresponds to the type field of 107 the Request. The authenticator ends the authentication phase with a 108 Success or Failure packet. See Figure 1. 110 User agent Server 112 GET 113 --------------------------------------------------------> 115 401 Unauthorized, WWW-Authenticate: EAP 116 <-------------------------------------------------------- 118 Authorization: EAP 119 --------------------------------------------------------> 121 401 Unauthorized, WWW-Authenticate: EAP 122 <-------------------------------------------------------- 124 Authorization: EAP 125 --------------------------------------------------------> 127 200 OK, Authentication-Info: EAP 128 <-------------------------------------------------------- 130 Figure 1. HTTP EAP Authentication message flow 132 This message flow above represents only the typical situation. 133 Variations of the flow are also possible in the following 134 situations: 136 - The chosen authentication mechanism requires more than the single 137 challenge-response message pair shown. Any number of message 138 exchanges are allowed here. 139 - Error situations result in terminating the flow from the server's 140 side with an error response. This response could be one of 401 141 Unauthorized, 403 Forbidden, or 407 Proxy Authentication Required. 142 For 401 and 407, the client distinguishes the error situation from 143 the continuation of the EAP exchange by the existence of EAP 144 FAILURE payload, or the lack of any EAP payload. 145 - Error situations from the client's side result in terminating the 146 communications with the server. 147 - Certain EAP authentication mechanisms such as [7] allow an 148 optimized flow where identity request does not need to be sent. In 149 these cases, if the client knows it will be demanded EAP 150 authentication, it can include an unsolicited EAP ID RESP already 151 in the GET message. This would enable the server to start the 152 actual authentication exchange immediately. 153 - EAP authentication was shown to be run towards the server which 154 responds with 401 Unauthorized responses. It is also possible to 155 run towards a proxy, which responds with 407 Proxy Authentication 156 Required responses. 158 In this document, we define three new header types for the HTTP 159 authentication framework. These headers, WWW-Authenticate Response 160 Header, Authorization Request Header and Authentication-Info 161 Response Header, are needed for making EAP as an independent HTTP 162 authentication scheme. 164 2.1 The WWW-Authenticate Response Header 166 The general HTTP authentication framework uses an extensible, case- 167 insensitive token to identify the authentication scheme. 168 Authentication scheme identifier is followed by a comma-separated 169 list of attribute-value pairs, which carry the parameters necessary 170 for achieving authentication via that scheme. 172 auth-scheme = token 173 auth-param = token "=" ( token | quoted-string ) 175 If a server receives a request for an access-protected object 176 without an acceptable Authorization header, the server responds with 177 a "401 Unauthorized" status code, a WWW-Authenticate header and at 178 least one challenge applicable to the requested resource. A Proxy 179 acts in the same way but it uses a "407 Proxy Authentication 180 Required" status code instead. 182 challenge = auth-scheme 1*SP 1#auth-param 184 The authentication parameter realm is defined for all authentication 185 schemes: 187 realm = "realm" "=" realm-value 188 realm-value = quoted-string 190 The realm value and the canonical root URL of the server being 191 accessed define the protection space. 193 The realm directive (case-insensitive) is required for all 194 authentication schemes that issue a challenge. The realm value 195 (case-sensitive) is a string, which may have additional semantics 196 specific to the authentication scheme. 198 For HTTP EAP Authentication, the framework above is utilized as 199 follows: 201 challenge = "Eap" eap-challenge 203 eap-challenge = 1#(realm | eap-param) 204 realm = "realm" "=" <"> realm-value <"> 205 realm-value = token [ "@" token ] 206 eap-param = "eap-p" "=" <"> eap-packet <"> 207 eap-packet = 210 The realm value SHOULD be globally unique. Proxy servers are 211 RECOMMENDED to use globally unique realm values in order to be able 212 to recognize their set of user credentials in a multi-proxy 213 authentication scenario. Implementations MAY use the form "local- 214 realm@host". 216 The realm value should be considered as an opaque string, which can 217 only be compared for equality with other realms on that server. The 218 server will service the request only if it can validate the user 219 credentials for the protection space of the Request-URI. 221 EAP packets have a general structure consisting of four basic 222 fields: code, identifier, length and data. The Code field is one 223 octet and it identifies the type of the EAP packet. Packet type is 224 either a request, response, success, or failure. The Identifier 225 field is also one octet and it is used for matching responses with 226 corresponding requests. The Length field is two octets and it 227 indicates in octects the length of the whole EAP packet including 228 code, identifier, length and data fields. The Data field is zero or 229 more octets and its format depends on the content of Code field. The 230 example below demonstrates the general structure of EAP packets. 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Code | Identifier | Length | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Data ... 238 +-+-+-+-+ 240 All these fields (Code, Identifier, Length, and Data) are included 241 in the eap-packet in base64 form. Note that since the packets are 242 self-identifying and self-delimiting it is allowed to include 243 multiple EAP packets within one eap-packet, should some EAP 244 mechanism be able to benefit from this. 246 Example below demonstrates how a WWW-Authenticate Response Header 247 using EAP authentication would look like: 249 WWW-Authenticate: eap realm="BollyWorld@example.com", 250 eap-p="QWxh4ZGRpb2jpvcGVuNlctZQ==" 252 where "BollyWorld" is the string assigned by the server to identify 253 the protection space of the Request-URI at server "example.com". 255 A proxy may respond with the same challenge using the Proxy- 256 Authenticate header field. Then it is especially important to 257 maintain global uniqueness for the realm values, since a request may 258 have credentials for multiple Proxy-Authenticate challenges. 260 2.2 The Authorization Request Header 262 In the general HTTP authentication framework, a user agent that 263 wishes to authenticate itself with an origin server or a proxy MAY 264 do so by including an Authorization header or a Proxy-Authorization 265 header field to the request. The authorization field value(s) 266 consists of credentials containing the authentication information of 267 the client for the realm of the resource being requested. The user 268 agent MUST apply the strongest authentication scheme it understands 269 and request credentials from the user based upon the corresponding 270 challenge. 272 credentials = auth-scheme #auth-param 274 For HTTP EAP Authentication, the framework above is utilized as 275 follows: 277 credentials = "Eap" eap-response 278 eap-response = 1#( realm | eap-param ) 279 eap-param = "eap-p" "=" eap-packet 280 eap-packet = 283 The value of the realm field must be that supplied in the WWW- 284 Authenticate or Proxy-Authenticate response header for the resource 285 being requested. 287 Example below demonstrates how the Authorization Request Header 288 using EAP authentication would look like: 290 Authorization: Eap realm="BollyWorld@example.com", 291 eap-p="QWxhZGRpbjpvcGVuIHNlc2FtZQ==" 293 Rules for handling potential user identifiers, passwords, challenges 294 and so on, are defined in EAP protocol [3]. 296 2.3 Authentication-Info Response Header 298 The Authentication-Info header is used by the server to communicate 299 information back to the client. This can be either the successful 300 authentication in the response, or the continuation of the EAP 301 mechanism. 303 auth-info = #auth-param 305 For HTTP EAP authentication the framework above is utilized as 306 follows: 308 Auth-info = eap-packet 309 eap-packet = 312 Example below demonstrates how the Authentication-Info Response 313 Header using EAP authentication would look like: 315 Authentication-Info: QWxhZGRpbjpvcGVuIHNlc2FtZQ== 317 The semantics of Proxy-Authentication-Info follow those of 318 Authentication-Info. Proxy-Authentication-Info is used by proxy 319 servers in conjunction with the "407 Proxy Authentication Required" 320 response, and the consequent client authorization request. 322 3 Security Considerations 324 Very little about the security of HTTP EAP Authentication can be 325 stated without knowing the chosen EAP authentication scheme. 326 Generally speaking, depending on the chosen EAP authentication 327 scheme, HTTP EAP is subject to the same security threats as HTTP 328 Authentication. However, there are some general aspects, which 329 SHOULD be considered when analyzing the security of HTTP EAP 330 Authentication: 332 1) Authentication of clients: All EAP mechanisms authenticate the 333 client, using a method dependent on the mechanism. 334 2) Authentication of servers: Some EAP mechanisms also perform 335 mutual authentication. 336 3) Using the strongest authentication mechanism available: Servers 337 and clients accepting multiple authentication mechanisms should 338 be aware of the possibility of 'bidding-down' attacks where a 339 man-in-the-middle modifies the authentication offers until the 340 peers agree on an easily breakable mechanism. In general, we 341 expect HTTP EAP based servers to require a predefined 342 authentication mechanism from a particular client in any case, 343 which avoids this problem. For instance, the user data base at 344 a server indicates that user A has a particular public key. The 345 server should then insist on using the EAP TLS [4] mechanism to 346 authenticate the user. 347 4) Confidentiality: Each EAP mechanism offers its specific 348 protection schemes for the exchanged credentials. For instance, 349 the EAP AKA [7] mechanism sends secure cryptographic hashes 350 rather than cleartext passwords like HTTP Basic Authentication 351 does, even if both are based on the concept of a shared secret. 352 As in EAP in general, HTTP EAP does not protect against 353 revealing the identity of the client since the EAP ID RESP 354 packets are not encrypted. Confidentiality and integrity of the 355 HTTP requests themselves beyond the authentication parameters 356 is not within the scope of HTTP EAP, but is discussed below 357 under item 7. 358 5) Replay protection: Each EAP mechanism offers its specific 359 protection schemes for preventing the replay of the 360 credentials. For instance, the EAP AKA mechanism uses a 361 cryptographically strong sequence number scheme. This is in 362 contrast to the replay possibilities that exist for the HTTP 363 Basic Authentication, and is similar to the use of nonces in 364 the HTTP Digest Authentication. 365 6) Integrity protection: Again, each EAP mechanism offers its 366 specific protection schemes against a man-in-the-middle 367 modifying the authentication credentials. Mechanisms based on 368 secure hashes prevent any modifications to the authentication 369 parameters themselves. Again, integrity of the HTTP requests 370 themselves beyond the authentication parameters is a separate 371 issue and is discussed below. 372 7) Integrity and confidentiality protection of the HTTP request 373 itself is also an important issue. Without such protection, it 374 is possible for a man-in-the-middle to read and modify the 375 actual contents of the request, regardless of any 376 authentication that was performed 378 Currently, there are no such authentication schemes in HTTP 379 authentication, which would fully protect the integrity of HTTP 380 messages. The HTTP Basic Authentication scheme provides no integrity 381 protection. HTTP Digest Authentication provides only limited (and 382 optional) protection. Most header fields and their values could be 383 modified as part of a man-in-the-middle attack. It should also be 384 noted that HTTP EAP does not inherently provide the integrity 385 protection qualities present in Digest, namely the protection of 386 Request-URI and request-method (and possibly the payload). 388 Even though HTTP EAP Authentication scheme does not include a 389 protection mechanism, it can be used for setting up one. Chosen EAP 390 authentication scheme may be used to generate session keys, which 391 together with some additional security protocol can provide e.g. 392 integrity protection. 394 However, such protection should include the protection of original 395 HTTP requests as well. This is not trivial because session 396 protection keys are generated during the authentication, which takes 397 place after submitting the request. In practice, full protection is 398 only possible if the request is repeated at the end of the 399 authentication procedure. This is, however, already the behavior in 400 many typical usage situations. For instance, when authenticating a 401 SIP REGISTER message, the authentication procedure takes a few 402 message rounds, and on each round the REGISTER message is repeated 403 until the session keys are available and the procedure is completed. 404 The last such message can then use integrity protection. Servers 405 that want to avoid man-in-the-middle attacks MUST NOT act on 406 requests until both the authentication procedure has completed and 407 the messages have been received under integrity protection. 409 4 References 411 1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, March 1997 414 2 Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, 415 P., Luotonen, A. and Stewart, L. �HTTP Authentication: Basic and 416 Digest Access Authentication�, RFC 2617, June 1999. 418 3 Blunk, L. and Vollbrecht, J. �PPP Extensible Authentication 419 Protocol (EAP)� RFC 2284, March 1998. 421 4 Aboba, B. and Simon, D. �PPP EAP TLS Authentication Protocol� RFC 422 2716, October 1999. 424 5 Aboba, B. �EAP GSS Authentication Protocol� Internet Draft, 425 draft-aboba-pppext-eapgss-03.txt, February 2001. 427 6 Carlson, J. �PPP EAP SRP-SHA1 Authentication Protocol� Internet 428 Draft, draft-ietf-pppext-eap-srp-01.txt, May 2001. 430 7 Arkko, J. and Haverinen, H. �EAP AKA Authentication� Internet 431 Draft, draft-arkko-pppext-eap-aka-00.txt, May 2001. 433 5 Acknowledgements 435 The authors wish to thank Henry Haverinen and Bernard Aboba for 436 interesting discussions in this problem space. 438 6 Author's Addresses 440 Jari Arkko 441 Ericsson 442 02420 Jorvas Phone: +358 40 5079256 443 Finland Email: jari.arkko@ericsson.com 445 Vesa Torvinen 446 Ericsson 447 02420 Jorvas Phone: +358 40 7230822 448 Finland Email: vesa.torvinen@ericsson.com 450 Aki Niemi 451 Nokia Networks 452 P.O. Box 301 453 00045 Nokia Group Phone: +358 50 3891644 454 Finland E-mail: aki.niemi@nokia.com