idnits 2.17.1 draft-josefsson-pppext-eap-tls-eap-01.txt: 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 18 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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. RFC 2119 keyword, line 355: '... channel MUST be the same party that...' 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 (October 2001) is 8230 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) ** Obsolete normative reference: RFC 2716 (ref. '1') (Obsoleted by RFC 5216) ** Obsolete normative reference: RFC 2284 (ref. '2') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 13 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft H. Andersson 3 S. Josefsson 4 RSA Security 5 G. Zorn 6 Cisco 7 B. Aboba 8 Microsoft 9 October 2001 11 Protected Extensible Authentication Protocol (PEAP) 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or made obsolete by other documents at 24 any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as work in progress. 27 The list of current Internet-Drafts may be found at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories may be found at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document specifies an Extensible Authentication Protocol (EAP) 36 mechanism for mutual authentication and session key generation in a 37 roaming environment. The server authentication and the negotiation of 38 the session key is done using the PPP EAP Transport Layer Security 39 (TLS) Authentication Protocol. The user authenticates using a PPP EAP 40 mechanism, integrity and privacy protected by TLS. In essence, a 41 wrapping of EAP inside TLS inside EAP is specified. An important 42 application discussed in this document is to provide authentication 43 of access points and stations within an IEEE 802.11 Wireless Local 44 Area Network (WLAN), but other applications such as LAN access over 45 Bluetooth might also be considered in the future. 47 1. Introduction 49 The PPP Extensible Authentication Protocol [2] defines a general 50 authentication framework. This document specifies an EAP mechanism 51 for mutual authentication and session key generation, with support 52 for a roaming environment. The connection is made, using EAP 53 terminology, between a peer and an authenticator. The (public-key) 54 authentication of the authenticator and the negotiation of the 55 session key is done using the PPP EAP Transport Layer Security (TLS) 56 Authentication Protocol [1]. The user performs authentication using 57 any defined PPP EAP mechanism, see [2]. 59 Section 2 defines the model and some terminology. A overview of this 60 EAP mechanism is given in Section 3, and Section 4 gives a detailed 61 description of packet formats. In Section 5, the protocol is applied 62 to an IEEE 802.11 Wireless Local Area Network (WLAN). Finally, 63 Section 6 discusses security issues. 65 2. Model and Terminology 67 The term peer refers to a client, acting on behalf of a user, that 68 requests access to a network. The entity contacted by the peer is 69 denoted authenticator. The authenticator is in turn connected to an 70 entity called back-end server. In our model, the authenticator is 71 acting merely as a passthrough device during the authentication 72 phase, forwarding each packet received from the peer to the back-end 73 server, and vice versa. It should be noted that the back-end server 74 may be a logical entity located in the same physical device as the 75 authenticator. The realisation of the back-end server and the 76 communication between the authenticator and backend server are 77 outside the scope of this document. 79 +---+ 80 | B | 81 | a | 82 | c | 83 | k | +---------------+ +--------+ 84 | | <-----------> | Authenticator | <-----> | Peer | 85 | e | +---------------+ EAP +--------+ 86 | n | . 87 | d | . 88 | | . 89 | S | +---------------+ . EAP 90 | e | <-----------> | Authenticator | . 91 | r | +---------------+ 92 | v | 93 | e | 94 | r | 95 +---+ 97 An overview of the assumed environment is found in the figure above. 99 The peer initially contacts the first authenticator (at the top of 100 the figure). The dotted line between the peer and the second 101 authenticator symbolizes roaming, i.e. the situation where the peer 102 transits from one authenticator to another while still maintaining 103 server and user authentication. It is assumed that the same logical 104 back-end server sits behind all of the authenticators contacted by 105 the peer. In practice, the back-end server may be distributed over 106 several machines, for e.g. fail-over or load-balancing purposes, but 107 in this document we regard them as one logical unit. 109 This document frequently uses the following terms and abbreviations: 111 authenticator 113 The end of the link requiring the authentication. 115 EAP 117 Extensible Authentication Protocol. After a connection link has 118 been established between two entities, an authentication phase may 119 take place. The PPP EAP protocol [2] is a general authentication 120 protocol. The authenticator sends one or more requests to the 121 peer, and the peer sends a response in reply to each request. The 122 authenticator ends the authentication phase with a success or 123 failure message. 125 peer 127 The other end of the point-to-point link; the end which is 128 being authenticated by the authenticator. 130 TLS 132 Transport Layer Security. Internet security protocol for 133 point-to-point connections (enhancement of Secure Sockets Layer, 134 SSL). Defined in [3]. Under this protocol, two entities are able 135 to authenticate each other and to establish a secure link. TLS 136 operates at the transport layer. The protocol PPP EAP TLS [1] 137 describes how to provide for TLS mechanisms within EAP. 139 3. Overview of the conversation 141 A peer wishes to set up a connection with an authenticator, for the 142 purpose of authenticating itself to e.g. a wireless infrastructure. 143 In our model, the authenticators are in connection with an back-end 144 server. The following describes each EAP packet that is sent between 145 the authenticator and peer during the EAP connection. 147 3.1. Initial registration 149 The first two steps are described in detail in Section 3.1 of [2], we 150 include them here for illustration. Note that as per the EAP 151 specification, this Identity exchange is not required. 153 1. The first EAP Request packet sent by the authenticator to the 154 peer is of type Identity. The data field may optionally contain a 155 displayable message. 157 2. The peer responds with an EAP-Response packet of type Identity. 159 Note that the data field of the Identity packet, which contains the 160 peer identity, cannot be assumed to be integrity or privacy 161 protected. Accordingly, it should not be used instead of the peer 162 identity sent inside the TLS channel later on. 164 The entities now initiate an EAP-TLS conversation. The following is 165 an example of a successful TLS handshake within EAP -- the packets 166 are described in detail in Section 4 of [1]. The EAP method defined 167 in this document does not terminate the TLS connection once the TLS 168 handshake phase is concluded (and thus differs subtly from how TLS is 169 used in [1]). The retry behavior and fragmentation concerns of 170 section 3.2 and 3.3 of [1] are still applicable (but not illustrated 171 in this example). 173 3. The authenticator sends an EAP-TLS packet of type Start with empty 174 data field. The data field of following packets will encapsulate 175 TLS Handshake Protocol messages. 177 4. Client hello: The peer sends a preferred TLS protocol version 178 number, an empty Session ID field, a list of preferred 179 cryptographic algorithms, and a random number to initialize the 180 TLS handshake. 182 5. Server hello: The authenticator responds with a selected TLS 183 protocol version number, a new Session ID, a list of selected 184 cryptographic algorithms, and another random number. Server 185 certificate: The authenticator then sends a chain of X.509v3 186 certificates, starting with its own certificate. The packet may 187 optionally include a server key exchange. Server hello 188 done: Finally, the authenticator indicates the end of this message 189 stream. (Note that the authenticator must NOT send any certificate 190 request.) 192 6. Client key exchange: The peer generates a premaster secret, 193 encrypts it using the public key obtained from the server 194 certificate, and sends the result. Change cipher spec: The 195 peer selects the cipher(s) to use. Client finished: The peer also 196 calculates a master secret from the premaster secret, and sends a 197 hash of a message consisting of the master secret; all of the data 198 from all previous handshake messages; the string "client 199 finished". 201 7. Change cipher spec: The authenticator selects the cipher(s) to 202 use. Server finished: Finally, the authenticator itself 203 generates the master secret from the premaster secret and 204 responds with a hash of a message consisting of the master 205 secret; all of the data from all previous handshake messages; 206 the string "server finished". 208 8. The peer acknowledges the end of the TLS negotiation by sending 209 an empty EAP Response packet. 211 This concludes the TLS handshake phase and the authentication of the 212 authenticator. It remains to perform user authentication. Note that 213 it is not until now that we deviate from the TLS EAP specification. 214 The authenticator will now intiate a second EAP handshake, within 215 TLS, to provide peer authentication in a protected channel. In this 216 EAP handshake, any EAP mechanism may be used to provide the peer 217 authentication. 219 This concludes the mutual authentication, and upon success both 220 authenticator and peer may generate any amount of new key material to 221 be forwarded to the underlying transport. This is accomplished within 222 the TLS Record Protocol by using the so-called PRF (Pseudo-Random 223 Function), see Section 3.5 "Key Derivation" of [3]. 225 It remains to be described what happens upon failures. In case the 226 TLS negotiation has failed fatally (after the proper TLS Alert 227 messages have been sent), an EAP-Failure messages is transmitted. 228 Within the TLS channel, in the second EAP handshake, after any EAP- 229 Success and EAP-Failure messages has successfully been sent, the same 230 type of packet should be send in the outer EAP channel as well. 232 3.2. Roaming 234 We now describe the case where the peer is transiting between two 235 authenticators during a session. In order to obtain a seamless 236 transition to a connection between the peer and the new 237 authenticator, we use the connection re-establishment mechanism 238 provided by the TLS Handshake Protocol. Note that the new 239 authenticator is assumed to use the same back-end server as the old 240 one, hence the old security parameters are still available. In the 241 case where the back-end server is just a logical entity residing at 242 the authenticator, the second authenticator will be required to 243 (securely) transfer the security parameters from the first 244 authenticator. 246 The steps 1-3 above are repeated without change. The following 247 describes a successful TLS handshake: 249 4. Client hello: The peer sends the TLS protocol version number, the 250 Session ID of the old connection, the previously negotiated 251 cryptographic algorithms, and a random number. 253 5. Server hello: The authenticator responds with the TLS protocol 254 version number, the Session ID, the negotiated cryptographic 255 algorithms, and another random number. If the old Session ID has 256 expired, then a new Session ID is presented to the peer and full 257 authentication takes place, as described in Subsection 3.1. 258 Change cipher spec: the server selects the cipher(s) to 259 use. Server finished: The authenticator responds with a hash of 260 a message consisting of the master secret; data from all 261 previous handshake messages; the string "server finished". 263 6. Change cipher spec: The peer select cipher(s) to use. Client 264 finished: The peer sends a hash of a message consisting of 265 the previously calculated master secret; data from all previous 266 handshake messages; the string "client finished". 268 Note that mutual authentication is achieved, since both peer and 269 authenticator have to know the old master secret in order to 270 successfully complete the protocol. An alternative to TLS resumption 271 has been discussed, whereby a "Roaming ID" is used to identify the 272 user moving between authenticators. At a new connection, server 273 authentication and generation of new security parameters is 274 mandatory. The advantage of this approach is that the authentication 275 server does not have to store so much key material, since all data 276 except the Roaming ID may be deleted when entities are disconnected. 277 This can be an important issue if there are many peers to be served. 278 On the other hand, having to generate much new key material could be 279 very time consuming for the back-end server, and this potential 280 danger has led us to choose TLS resumption as described above. 282 Finally, the length of time that a Session ID is valid should be 283 limited. The time of validity is application dependent. In some 284 environments it may be desirable that the authenticator notify the 285 peer that the Session ID is about to expire. No mechanism is defined 286 in this document to handle such a scenario, but note that the Session 287 ID validity is checked during connection re-establishment (see 5 288 above). 290 4. Packet formats 291 It is assumed that underlying transport protocols has set up the 292 connection so that it is ready to transfer EAP packets. 294 4.1. TLS in EAP 296 The syntax of EAP packets containing TLS messages are per [1], and 297 the TLS protocol description is per [3]. Note that [1] does not use 298 the negotiated TLS tunnel to transfer any data, while this 299 specification does, however this does not affect the EAP protocol 300 syntax. We include the EAP syntax in the following figure, referring 301 to Sections 4.2 and 4.3 of [1] for the definition of the Request and 302 Response packets. 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Code | Identifier | Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type | Data ... / 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 Code 314 1 - Request 315 2 - Response 317 Identifier 319 The identifier field is one octet and aids in matching responses 320 with requests. 322 Length 324 The Length field is two octets and indicates the length of the EAP 325 packet including the Code, Identifier, Length, Type, and Data 326 fields. Octets outside the range of the Length field should be 327 treated as Data Link Layer padding and should be ignored on 328 reception. 330 Type 332 TBA - EAP TLS EAP 334 Data 336 The format of the Data field is determined by the Code field. 338 4.2. EAP negotiation inside TLS 339 We now assume that the TLS handshake has been successfully completed 340 and that a secure TLS connection is available within the TLS Record 341 Protocol. The following packets (protected by TLS Record Protocol and 342 sent inside EAP packets) are used to negotiate the peer EAP 343 authentication. 345 The following figure describes the template packet structure that is 346 used during this communication. 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | EAP Data as per RFC 2284 ... / 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 The party acting as authenticator in this second, wrapped, EAP 355 channel MUST be the same party that acted as authenticator in the 356 original EAP channel. 358 5. Example: IEEE 802.11 WLAN 360 IEEE 802.11 Wireless Local Area Network (WLAN) is a standard for 361 wireless computer networks, see [5]. Any device that contains an IEEE 362 802.11 conformant medium access control and physical layer interface 363 to the wireless medium is called a Station (STA). An entity that has 364 station functionality and also provides access to the distribution 365 services (e.g. a wired LAN) via the wireless medium for associated 366 stations is called an Access Point (AP). The authentication services 367 defined within IEEE 802.11 are discussed below, and the need for 368 higher level authentication is addressed. 370 IEEE 802.11 defines two types of authentication methods -- Open 371 system authentication and Shared key authentication. Open system 372 authentication is essentially a null authentication. The conversation 373 is done in clear, no challenge procedure is performed. The purpose of 374 Shared key authentication is to check that both parties share a pre- 375 negotiated encryption key. The AP sends a challenge and the STA 376 responds by encrypting this challenge. If the AP successfully 377 decrypts that message, the authentication is finished. In other 378 words, the AP is never required to authenticate itself. This opens up 379 for a number of attacks, such as denial of service attacks via rogue 380 APs. It is thus crucial to achieve mutual authentication. 382 The IEEE 802.1X draft [4] specifies a general method for the 383 provision of port based network access control. A port in this 384 context is an attachment point to the LAN infrastructure, e.g. an 385 association between a STA and an AP. The specification describes the 386 architectural framework within which the authentication takes place, 387 and establishes the requirements for a higher level authentication 388 protocol between the station and the access point. 390 The IEEE 802.1X draft provides a framework, Extensible Authentication 391 Protocol Over Local area networks (EAPOL), that makes it possible to 392 send EAP packets between IEEE 802.11 entities. In a WLAN environment, 393 the "Authenticator" is the AP, and the "Peer" is a STA. An 394 Authentication Server is an entity connected with the AP. The server 395 is communicating with the STA during the authentication -- the AP is 396 sitting in between, acting merely as a passthrough device. In a 397 roaming environment, the STA may connect to several APs during a 398 session. All the APs are assumed to be connected to the same 399 authentication server. The protocol described in this paper may 400 therefore be applied to a WLAN environment, providing authentication 401 of the AP, strong authentication of the user of the STA, and session 402 key negotiation. 404 Note that the present protocol is partly based on [1], which in turn 405 assumes PPP EAP and not EAPOL as the underlying protocol. However, 406 this minor difference will cause no problems whatsoever, since the 407 TLS conversation carries over word by word to the new environment. 409 Let us finally comment on the Wired Equivalent Privacy (WEP) 410 encryption scheme defined in the IEEE 802.11 standard. WEP uses the 411 stream cipher RC4 with key obtained as the concatenation of a 24 bit 412 IV and a 40 bit WEP key. Four WEP keys can be prestored, but it is 413 also possible to use a session key negotiated during the 414 authentication phase, i.e. follow the approach outlined in this work. 415 WEP suffers from some serious security weaknesses, e.g. the WEP key 416 is too short to withstand a brute force attack. Also, the IV is too 417 short -- even if a new random IV is used for each packet, collisions 418 will start appearing within a few seconds (according to the birthday 419 paradox). XORing messages with the same IV results in plaintext 420 difference that can be further analyzed. Finally, there is no real 421 data integrity since the integrity check value used is just a linear 422 checksum. An active attacker wishing to alter the plaintext can 423 easily modify the checksum to be valid for the new plaintext. The 424 IEEE 802.11 working group recognizes the need to improve security, 425 and is currently working on a revision of the standard. 427 6. Security considerations 429 The Transport Layer Security protocol is presumed to be a strong 430 security protocol and it is widely accepted. Here we discuss some 431 security issues. The Session ID is sent in clear, so an attacker may 432 contact an authenticator, pretending to be the legitimate user. 433 However, by sending correct Finished messages, the parties prove to 434 each other that they know the correct premaster secret. The attacker 435 will not be able to finish the handshake properly (unless the 436 protocol has been completely broken). 438 An attacker, acting as an active man-in-the-middle, might try to 439 influence the choice of encryption algorithm by altering the 440 corresponding handshake message. However, this will also be detected 441 in the verification of the Finished messages, since each of these 442 consists of a hash of all previous messages. The hash functions MD5 443 and SHA-1 are used in tandem wherever possible. The TLS designers 444 claim that this approach ensures that a serious flaw in one of the 445 functions will not lead to failure of the entire TLS protocol. 447 Finally, the strength of the user authentication is dependent on the 448 EAP mechanism chosen. With the approach described here, the EAP 449 packets sent by the peer are not transmitted in clear, which improve 450 the security of some EAP mechanisms. This is particularly important 451 in a wireless environment where passive eavesdropping is a serious 452 threat. 454 7. Acknowledgements 456 We wish to thank Jan-Ove Larsson and Magnus Nystrom for helpful 457 discussions and comments during the development of this draft. We 458 would also like to thank Glen Zorn and Simon Blake-Wilson for 459 comments on the first version of this draft. 461 References 463 [1] Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol", 464 RFC 2716, October 1999. 466 [2] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication 467 Protocol (EAP)", RFC 2284, March 1998. 469 [3] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246, January 470 1999. 472 [4] IEEE Standards for Local and Metropolitan Area Networks: Port 473 based Network Access Control, IEEE Draft 802.1X/D10, January 474 2001. 476 [5] Information technology -- Telecommunications and information 477 exchange between systems -- Local and metropolitan area 478 networks -- Specific requirements -- Part 11: Wireless LAN 479 Medium Access Control (MAC) and Physical Layer (PHY) 480 Specifications, IEEE Std. 802.11, 1999. 482 Address of the authors 484 Hakan Andersson 485 RSA Security 486 Box 107 04 487 SE-121 29 Stockholm 488 Sweden 489 E-mail: handersson@rsasecurity.com 490 Phone: +46 8 725 9758 491 Fax: +46 8 649 4970 493 Simon Josefsson 494 RSA Security 495 Box 107 04 496 SE-121 29 Stockholm 497 Sweden 498 E-mail: sjosefsson@rsasecurity.com 499 Phone: +46 8 725 0914 500 Fax: +46 8 649 4970 502 Glen Zorn 503 Cisco 504 E-mail: gwz@cisco.com 506 Bernard Aboba 507 Microsoft 508 E-mail: aboba@internaut.com