idnits 2.17.1 draft-ietf-pppext-eaptls-06.txt: ** The Abstract section seems to be numbered 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 is more than 15 pages and seems to lack a Table of Contents. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 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 90: '...the peer, the authenticator MAY act as...' RFC 2119 keyword, line 96: '... Identity, the EAP server MUST respond...' RFC 2119 keyword, line 110: '...ed by the client MUST correspond to TL...' RFC 2119 keyword, line 120: '...The version offered by the server MUST...' RFC 2119 keyword, line 124: '...server MUST choose the sessionId to es...' (40 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 125 has weird spacing: '...ssionId will ...' == Line 127 has weird spacing: '...ered by the...' == Line 1068 has weird spacing: '...>, and expir...' -- 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 (12 August 1999) is 9018 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '5' on line 927 looks like a reference -- Missing reference section? '6' on line 930 looks like a reference -- Missing reference section? '9' on line 939 looks like a reference -- Missing reference section? '10' on line 942 looks like a reference -- Missing reference section? '12' on line 948 looks like a reference -- Missing reference section? '11' on line 945 looks like a reference -- Missing reference section? '2' on line 919 looks like a reference -- Missing reference section? '13' on line 951 looks like a reference -- Missing reference section? '1' on line 916 looks like a reference -- Missing reference section? '3' on line 922 looks like a reference -- Missing reference section? '4' on line 924 looks like a reference -- Missing reference section? '7' on line 933 looks like a reference -- Missing reference section? '8' on line 936 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPPEXT Working Group Bernard Aboba 2 INTERNET-DRAFT Microsoft 3 Category: Informational Dan Simon 4 Microsoft 5 12 August 1999 7 PPP EAP TLS Authentication Protocol 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. Internet- 17 Drafts are draft documents valid for a maximum of six months and may be 18 updated, replaced, or obsoleted by other documents at any time. It is 19 inappropriate to use Internet-Drafts as reference material or to cite 20 them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 The distribution of this memo is unlimited. It is filed as , and expires March 1, 2000. Please send comments 30 to the authors. 32 2. Copyright Notice 34 Copyright (C) The Internet Society (1999). All Rights Reserved. 36 3. Abstract 38 The Point-to-Point Protocol (PPP) provides a standard method for 39 transporting multi-protocol datagrams over point-to-point links. PPP 40 also defines an extensible Link Control Protocol (LCP), which can be 41 used to negotiate authentication methods, as well as an Encryption 42 Control Protocol (ECP), used to negotiate data encryption over PPP 43 links, and a Compression Control Protocol (CCP), used to negotiate 44 compression methods. The Extensible Authentication Protocol (EAP) is a 45 PPP extension that provides support for additional authentication 46 methods within PPP. 48 Transport Level Security (TLS) provides for mutual authentication, 49 integrity-protected ciphersuite negotiation and key exchange between two 50 endpoints. This document describes how EAP-TLS, which includes support 51 for fragmentation and reassembly, provides for these TLS mechanisms 52 within EAP. 54 4. Introduction 56 The Extensible Authentication Protocol (EAP), described in [5], provides 57 a standard mechanism for support of additional authentication methods 58 within PPP. Through the use of EAP, support for a number of 59 authentication schemes may be added, including smart cards, Kerberos, 60 Public Key, One Time Passwords, and others. To date however, EAP methods 61 such as [6] have focussed on authenticating a client to a server. 63 However, it may be desirable to support mutual authentication, and since 64 PPP encryption protocols such as [9] and [10] assume existence of a 65 session key, it is useful to have a mechanism for session key 66 establishment. Since design of secure key management protocols is non- 67 trivial, it is desirable to avoid creating new mechanisms for this. The 68 EAP protocol described in this document allows a PPP peer to take 69 advantage of the protected ciphersuite negotiation, mutual 70 authentication and key management capabilities of the TLS protocol, 71 described in [12]. 73 4.1. Requirements language 75 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 76 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 77 described in [11]. 79 5. Protocol overview 81 5.1. Overview of the EAP-TLS conversation 83 As described in [5], the EAP-TLS conversation will typically begin with 84 the authenticator and the peer negotiating EAP. The authenticator will 85 then typically send an EAP-Request/Identity packet to the peer, and the 86 peer will respond with an EAP-Response/Identity packet to the 87 authenticator, containing the peer's userId. 89 >From this point forward, while nominally the EAP conversation occurs 90 between the PPP authenticator and the peer, the authenticator MAY act as 91 a passthrough device, with the EAP packets received from the peer being 92 encapsulated for transmission to a RADIUS server or backend security 93 server. In the discussion that follows, we will use the term "EAP 94 server" to denote the ultimate endpoint conversing with the peer. 96 Once having received the peer's Identity, the EAP server MUST respond 97 with an EAP-TLS/Start packet, which is an EAP-Request packet with EAP- 98 Type=EAP-TLS, the Start (S) bit set, and no data. The EAP-TLS 99 conversation will then begin, with the peer sending an EAP-Response 100 packet with EAP-Type=EAP-TLS. The data field of that packet will 101 encapsulate one or more TLS records in TLS record layer format, 102 containing a TLS client_hello handshake message. The current cipher 103 spec for the TLS records will be TLS_NULL_WITH_NULL_NULL and null 104 compression. This current cipher spec remains the same until the 105 change_cipher_spec message signals that subsequent records will have the 106 negotiated attributes for the remainder of the handshake. 108 The client_hello message contains the client's TLS version number, a 109 sessionId, a random number, and a set of ciphersuites supported by the 110 client. The version offered by the client MUST correspond to TLS v1.0 or 111 later. 113 The EAP server will then respond with an EAP-Request packet with EAP- 114 Type=EAP-TLS. The data field of this packet will encapsulate one or more 115 TLS records. These will contain a TLS server_hello handshake message, 116 possibly followed by TLS certificate, server_key_exchange, 117 certificate_request, server_hello_done and/or finished handshake 118 messages, and/or a TLS change_cipher_spec message. The server_hello 119 handshake message contains a TLS version number, another random number, 120 a sessionId, and a ciphersuite. The version offered by the server MUST 121 correspond to TLS v1.0 or later. 123 If the client's sessionId is null or unrecognized by the server, the 124 server MUST choose the sessionId to establish a new session; otherwise, 125 the sessionId will match that offered by the client, indicating a 126 resumption of the previously established session with that sessionID. 127 The server will also choose a ciphersuite from those offered by the 128 client; if the session matches the client's, then the ciphersuite MUST 129 match the one negotiated during the handshake protocol execution that 130 established the session. 132 The purpose of the sessionId within the TLS protocol is to allow for 133 improved efficiency in the case where a client repeatedly attempts to 134 authenticate to an EAP server within a short period of time. While this 135 model was developed for use with HTTP authentication, it may also have 136 application to PPP authentication (e.g. multilink). 138 As a result, it is left up to the peer whether to attempt to continue a 139 previous session, thus shortening the TLS conversation. Typically the 140 peer's decision will be made based on the time elapsed since the 141 previous authentication attempt to that EAP server. Based on the 142 sessionId chosen by the peer, and the time elapsed since the previous 143 authentication, the EAP server will decide whether to allow the 144 continuation, or whether to choose a new session. 146 In the case where the EAP server and authenticator reside on the same 147 device, then client will only be able to continue sessions when 148 connecting to the same NAS or tunnel server. Should these devices be set 149 up in a rotary or round-robin then it may not be possible for the peer 150 to know in advance the authenticator it will be connecting to, and 151 therefore which sessionId to attempt to reuse. As a result, it is likely 152 that the continuation attempt will fail. In the case where the EAP 153 authentication is remoted then continuation is much more likely to be 154 successful, since multiple NAS devices and tunnel servers will remote 155 their EAP authentications to the same RADIUS server. 157 If the EAP server is resuming a previously established session, then it 158 MUST include only a TLS change_cipher_spec message and a TLS finished 159 handshake message after the server_hello message. The finished message 160 contains the EAP server's authentication response to the peer. If the 161 EAP server is not resuming a previously established session, then it 162 MUST include a TLS server_certificate handshake message, and a 163 server_hello_done handshake message MUST be the last handshake message 164 encapsulated in this EAP-Request packet. 166 The certificate message contains a public key certificate chain for 167 either a key exchange public key (such as an RSA or Diffie-Hellman key 168 exchange public key) or a signature public key (such as an RSA or DSS 169 signature public key). In the latter case, a TLS server_key_exchange 170 handshake message MUST also be included to allow the key exchange to 171 take place. 173 The certificate_request message is included when the server desires the 174 client to authenticate itself via public key. While the EAP server 175 SHOULD require client authentication, this is not a requirement, since 176 it may be possible that the server will require that the peer 177 authenticate via some other means. 179 The peer MUST respond to the EAP-Request with an EAP-Response packet of 180 EAP-Type=EAP-TLS. The data field of this packet will encapsulate one or 181 more TLS records containing a TLS change_cipher_spec message and 182 finished handshake message, and possibly certificate, certificate_verify 183 and/or client_key_exchange handshake messages. If the preceding 184 server_hello message sent by the EAP server in the preceding EAP-Request 185 packet indicated the resumption of a previous session, then the peer 186 MUST send only the change_cipher_spec and finished handshake messages. 187 The finished message contains the peer's authentication response to the 188 EAP server. 190 If the preceding server_hello message sent by the EAP server in the 191 preceeding EAP-Request packet did not indicate the resumption of a 192 previous session, then the peer MUST send, in addition to the 193 change_cipher_spec and finished messages, a client_key_exchange message, 194 which completes the exchange of a shared master secret between the peer 195 and the EAP server. If the EAP server sent a certificate_request 196 message in the preceding EAP-Request packet, then the peer MUST send, in 197 addition, certificate and certificate_verify handshake messages. The 198 former contains a certificate for the peer's signature public key, while 199 the latter contains the peer's signed authentication response to the EAP 200 server. After receiving this packet, the EAP server will verify the 201 peer's certificate and digital signature, if requested. 203 If the peer's authentication is unsuccessful, the EAP server SHOULD send 204 an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS record 205 containing the appropriate TLS alert message. The EAP server SHOULD 206 send a TLS alert message rather immediately terminating the conversation 207 so as to allow the peer to inform the user of the cause of the failure 208 and possibly allow for a restart of the conversation. 210 To ensure that the peer receives the TLS alert message, the EAP server 211 MUST wait for the peer to reply with an EAP-Response packet. The EAP- 212 Response packet sent by the peer MAY encapsulate a TLS client_hello 213 handshake message, in which case the EAP server MAY allow the EAP-TLS 214 conversation to be restarted, or it MAY contain an EAP-Response packet 215 with EAP-Type=EAP-TLS and no data, in which case the EAP-Server MUST 216 send an EAP-Failure packet, and terminate the conversation. It is up to 217 the EAP server whether to allow restarts, and if so, how many times the 218 conversation can be restarted. An EAP Server implementing restart 219 capability SHOULD impose a limit on the number of restarts, so as to 220 protect against denial of service attacks. 222 If the peers authenticates successfully, the EAP server MUST respond 223 with an EAP-Request packet with EAP-Type=EAP-TLS, which includes, in the 224 case of a new TLS session, one or more TLS records containing TLS 225 change_cipher_spec and finished handshke messages. The latter contains 226 the EAP server's authentication response to the peer. The peer will 227 then verify the hash in order to authenticate the EAP server. 229 If the EAP server authenticates unsuccessfully, the peer MAY send an 230 EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert message 231 identifying the reason for the failed authentication. The peer MAY send 232 a TLS alert message rather than immediately terminating the conversation 233 so as to allow the EAP server to log the cause of the error for 234 examination by the system administrator. 236 To ensure that the EAP Server receives the TLS alert message, the peer 237 MUST wait for the EAP-Server to reply before terminating the 238 conversation. The EAP Server MUST reply with an EAP-Failure packet 239 since server authentication failure is a terminal condition. 241 If the EAP server authenticates successfully, the peer MUST send an EAP- 242 Response packet of EAP-Type=EAP-TLS, and no data. The EAP-Server then 243 MUST respond with an EAP-Success message. 245 5.2. Retry behavior 247 As with other EAP protocols, the EAP server is responsible for retry 248 behavior. This means that if the EAP server does not receive a reply 249 from the peer, it MUST resend the EAP-Request for which it has not yet 250 received an EAP-Response. However, the peer MUST NOT resend EAP-Response 251 packets without first being prompted by the EAP server. 253 For example, if the initial EAP-TLS start packet sent by the EAP server 254 were to be lost, then the peer would not receive this packet, and would 255 not respond to it. As a result, the EAP-TLS start packet would be resent 256 by the EAP server. Once the peer received the EAP-TLS start packet, it 257 would send an EAP-Response encapsulating the client_hello message. If 258 the EAP-Response were to be lost, then the EAP server would resend the 259 initial EAP-TLS start, and the peer would resend the EAP-Response. 261 As a result, it is possible that a peer will receive duplicate EAP- 262 Request messages, and may send duplicate EAP-Responses. Both the peer 263 and the EAP-Server should be engineered to handle this possibility. 265 5.3. Fragmentation 267 A single TLS record may be up to 16384 octets in length, but a TLS 268 message may span multiple TLS records, and a TLS certificate message may 269 in principle be as long as 16MB. The group of EAP-TLS messages sent in a 270 single round may thus be larger than the PPP MTU size, the maximum 271 RADIUS packet size of 4096 octets, or even the Multilink Maximum 272 Received Reconstructed Unit (MRRU). As described in [2], the multilink 273 MRRU is negotiated via the Multilink MRRU LCP option, which includes an 274 MRRU length field of two octets, and thus can support MRRUs as large as 275 64 KB. 277 However, note that in order to protect against reassembly lockup and 278 denial of service attacks, it may be desirable for an implementation to 279 set a maximum size for one such group of TLS messages. Since a typical 280 certificate chain is rarely longer than a few thousand octets, and no 281 other field is likely to be anwhere near as long, a reasonable choice of 282 maximum acceptable message length might be 64 KB. 284 If this value is chosen, then fragmentation can be handled via the 285 multilink PPP fragmentation mechanisms described in [2]. While this is 286 desirable, there may be cases in which multilink or the MRRU LCP option 287 cannot be negotiated. As a result, an EAP-TLS implementation MUST 288 provide its own support for fragmentation and reassembly. 290 Since EAP is a simple ACK-NAK protocol, fragmentation support can be 291 added in a simple manner. In EAP, fragments that are lost or damaged in 292 transit will be retransmitted, and since sequencing information is 293 provided by the Identifier field in EAP, there is no need for a fragment 294 offset field as is provided in IPv4. 296 EAP-TLS fragmentation support is provided through addition of a flags 297 octet within the EAP-Response and EAP-Request packets, as well as a TLS 298 Message Length field of four octets. Flags include the Length included 299 (L), More fragments (M), and EAP-TLS Start (S) bits. The L flag is set 300 to indicate the presence of the four octet TLS Message Length field, and 301 MUST be set for the first fragment of a fragmented TLS message or set of 302 messages. The M flag is set on all but the last fragment. The S flag is 303 set only within the EAP-TLS start message sent from the EAP server to 304 the peer. The TLS Message Length field is four octets, and provides the 305 total length of the TLS message or set of messages that is being 306 fragmented; this simplifies buffer allocation. 308 When an EAP-TLS peer receives an EAP-Request packet with the M bit set, 309 it MUST respond with an EAP-Response with EAP-Type=EAP-TLS and no data. 310 This serves as a fragment ACK. The EAP server MUST wait until it 311 receives the EAP-Response before sending another fragment. In order to 312 prevent errors in processing of fragments, the EAP server MUST increment 313 the Identifier field for each fragment contained within an EAP-Request, 314 and the peer MUST include this Identifier value in the fragment ACK 315 contained within the EAP-Reponse. Retransmitted fragments will contain 316 the same Identifier value. 318 Similarly, when the EAP server receives an EAP-Response with the M bit 319 set, it MUST respond with an EAP-Request with EAP-Type=EAP-TLS and no 320 data. This serves as a fragment ACK. The EAP peer MUST wait until it 321 receives the EAP-Request before sending another fragment. In order to 322 prevent errors in the processing of fragments, the EAP server MUST use 323 increment the Identifier value for each fragment ACK contained within an 324 EAP-Request, and the peer MUST include this Identifier value in the 325 subsequent fragment contained within an EAP-Reponse. 327 5.4. Identity verification 329 As part of the TLS negotiation, the server presents a certificate to the 330 peer, and if mutual authentication is requested, the peer presents a 331 certificate to the server. 333 Note that since the peer has made a claim of identity in the EAP- 334 Response/Identity (MyID) packet, the EAP server SHOULD verify that the 335 claimed identity corresponds to the certificate presented by the peer. 336 Typically this will be accomplished either by placing the userId within 337 the peer certificate, or by providing a mapping between the peer 338 certificate and the userId using a directory service. 340 Similarly, the peer MUST verify the validity of the EAP server 341 certificate, and SHOULD also examine the EAP server name presented in 342 the certificate, in order to determine whether the EAP server can be 343 trusted. Please note that in the case where the EAP authentication is 344 remoted that the EAP server will not reside on the same machine as the 345 authenticator, and therefore the name in the EAP server's certificate 346 cannot be expected to match that of the intended destination. In this 347 case, a more appropriate test might be whether the EAP server's 348 certificate is signed by a CA controlling the intended destination and 349 whether the EAP server exists within a target sub-domain. 351 5.5. Key derivation 353 Since the normal TLS keys are used in the handshake, and therefore 354 should not be used in a different context, new encryption keys must be 355 derived from the TLS master secret for use with PPP encryption. For 356 both peer and EAP server, the derivation proceeds as follows: given the 357 master secret negotiated by the TLS handshake, the pseudorandom function 358 (PRF) defined in the specification for the version of TLS in use, and 359 the value random defined as the concatenation of the handshake message 360 fields client_hello.random and server_hello.random (in that order), the 361 value PRF(master secret, "client EAP encryption", random) is computed up 362 to 128 bytes, and the value PRF("", "client EAP encryption", random) is 363 computed up to 64 bytes (where "" is an empty string). The peer 364 encryption key (the one used for encrypting data from peer to EAP 365 server) is obtained by truncating to the correct length the first 32 366 bytes of the first PRF of these two output strings. TheEAP server 367 encryption key (the one used for encrypting data from EAP server to 368 peer), if different from the client encryption key, is obtained by 369 truncating to the correct length the second 32 bytes of this same PRF 370 output string. The client authentication key (the one used for 371 computing MACs for messages from peer to EAP server), if used, is 372 obtained by truncating to the correct length the third 32 bytes of this 373 same PRF output string. The EAP server authentication key (the one used 374 for computing MACs for messages from EAP server to peer), if used, and 375 if different from the peer authentication key, is obtained by truncating 376 to the correct length the fourth 32 bytes of this same PRF output 377 string. The peer initialization vector (IV), used for messages from 378 peer to EAP server if a block cipher has been specified, is obtained by 379 truncating to the cipher's block size the first 32 bytes of the second 380 PRF output string mentioned above. Finally, the server initialization 381 vector (IV), used for messages from peer to EAP server if a block cipher 382 has been specified, is obtained by truncating to the cipher's block size 383 the second 32 bytes of this second PRF output. 385 The use of these encryption and authentication keys is specific to the 386 PPP encryption mechanism used, such as those defined in [9] and [10]. 387 Additional keys or other non-secret values (such as IVs) can be obtained 388 as needed for future PPP encryption methods by extending the outputs of 389 the PRF beyond 128 bytes and 64 bytes, respectively. 391 5.6. ECP negotiation 393 Since TLS supports ciphersuite negotiation, peers completing the TLS 394 negotiation will also have selected a ciphersuite, which includes key 395 strength, encryption and hashing methods. As a result, a subsequent 396 Encryption Control Protocol (ECP) conversation, if it occurs, has a 397 predetermined result. 399 In order to ensure agreement between the EAP-TLS ciphersuite negotiation 400 and the subsequent ECP negotiation (described in [6]), during ECP 401 negotiation the PPP peer MUST offer only the ciphersuite negotiated in 402 EAP-TLS. This ensures that the PPP authenticator MUST accept the EAP- 403 TLS negotiated ciphersuite in order for the onversation to proceed. 404 Should the authenticator not accept the EAP-TLS negotiated ciphersuite, 405 then the peer MUST send an LCP terminate and disconnect. 407 Please note that it cannot be assumed that the PPP authenticator and EAP 408 server are located on the same machine or that the authenticator 409 understands the EAP-TLS conversation that has passed through it. Thus if 410 the peer offers a ciphersuite other than the one negotiated in EAP-TLS 411 there is no way for the authenticator to know how to respond correctly. 413 5.7. CCP negotiation 415 TLS as described in [12] supports compression as well as ciphersuite 416 negotiation. However, TLS only provides support for a limited number of 417 compression types which do not overlap with the compression types used 418 in PPP. As a result, during the EAP-TLS conversation the EAP endpoints 419 MUST NOT request or negotiate compression. Instead, the PPP Compression 420 Control Protocol (CCP), described in [13] should be used to negotiate 421 the desired compression scheme. 423 5.8. Examples 425 In the case where the EAP-TLS mutual authentication is successful, the 426 conversation will appear as follows: 428 Authenticating Peer Authenticator 429 ------------------- ------------- 430 <- PPP LCP Request-EAP 431 auth 432 PPP LCP ACK-EAP 433 auth -> 434 <- PPP EAP-Request/ 435 Identity 436 PPP EAP-Response/ 437 Identity (MyID) -> 438 <- PPP EAP-Request/ 439 EAP-Type=EAP-TLS 440 (TLS Start) 441 PPP EAP-Response/ 442 EAP-Type=EAP-TLS 443 (TLS client_hello)-> 444 <- PPP EAP-Request/ 445 EAP-Type=EAP-TLS 446 (TLS server_hello, 447 TLS certificate, 448 [TLS server_key_exchange,] 449 [TLS certificate_request,] 450 TLS server_hello_done) 451 PPP EAP-Response/ 452 EAP-Type=EAP-TLS 453 (TLS certificate, 454 TLS client_key_exchange, 455 [TLS certificate_verify,] 456 TLS change_cipher_spec, 457 TLS finished) -> 458 <- PPP EAP-Request/ 459 EAP-Type=EAP-TLS 460 (TLS change_cipher_spec, 461 TLS finished) 462 PPP EAP-Response/ 463 EAP-Type=EAP-TLS -> 464 <- PPP EAP-Success 465 PPP Authentication 466 Phase complete, 467 NCP Phase starts 469 ECP negotiation 470 CCP negotiation 471 In the case where the EAP-TLS mutual authentication is successful, and 472 fragmentation is required, the conversation will appear as follows: 474 Authenticating Peer Authenticator 475 ------------------- ------------- 476 <- PPP LCP Request-EAP 477 auth 478 PPP LCP ACK-EAP 479 auth -> 480 <- PPP EAP-Request/ 481 Identity 482 PPP EAP-Response/ 483 Identity (MyID) -> 484 <- PPP EAP-Request/ 485 EAP-Type=EAP-TLS 486 (TLS Start, S bit set) 487 PPP EAP-Response/ 488 EAP-Type=EAP-TLS 489 (TLS client_hello)-> 490 <- PPP EAP-Request/ 491 EAP-Type=EAP-TLS 492 (TLS server_hello, 493 TLS certificate, 494 [TLS server_key_exchange,] 495 [TLS certificate_request,] 496 TLS server_hello_done) 497 (Fragment 1: L, M bits set) 498 PPP EAP-Response/ 499 EAP-Type=EAP-TLS -> 500 <- PPP EAP-Request/ 501 EAP-Type=EAP-TLS 502 (Fragment 2: M bit set) 503 PPP EAP-Response/ 504 EAP-Type=EAP-TLS -> 505 <- PPP EAP-Request/ 506 EAP-Type=EAP-TLS 507 (Fragment 3) 508 PPP EAP-Response/ 509 EAP-Type=EAP-TLS 510 (TLS certificate, 511 TLS client_key_exchange, 512 [TLS certificate_verify,] 513 TLS change_cipher_spec, 514 TLS inished)(Fragment 1: 515 L, M bits set)-> 516 <- PPP EAP-Request/ 517 EAP-Type=EAP-TLS 518 PPP EAP-Response/ 519 EAP-Type=EAP-TLS 520 (Fragment 2)-> 521 <- PPP EAP-Request/ 522 EAP-Type=EAP-TLS 523 (TLS change_cipher_spec, 524 TLS finished) 525 PPP EAP-Response/ 526 EAP-Type=EAP-TLS -> 527 <- PPP EAP-Success 528 PPP Authentication 529 Phase complete, 530 NCP Phase starts 532 ECP negotiation 533 CCP negotiation 534 In the case where the server authenticates to the client successfully, 535 but the client fails to authenticate to the server, the conversation 536 will appear as follows: 538 Authenticating Peer Authenticator 539 ------------------- ------------- 540 <- PPP LCP Request-EAP 541 auth 542 PPP LCP ACK-EAP 543 auth -> 544 <- PPP EAP-Request/ 545 Identity 546 PPP EAP-Response/ 547 Identity (MyID) -> 548 <- PPP EAP-Request/ 549 EAP-Type=EAP-TLS 550 (TLS Start) 551 PPP EAP-Response/ 552 EAP-Type=EAP-TLS 553 (TLS client_hello)-> 554 <- PPP EAP-Request/ 555 EAP-Type=EAP-TLS 556 (TLS server_hello, 557 TLS certificate, 558 [TLS server_key_exchange,] 559 TLS certificate_request, 560 TLS server_hello_done) 561 PPP EAP-Response/ 562 EAP-Type=EAP-TLS 563 (TLS certificate, 564 TLS client_key_exchange, 565 TLS certificate_verify, 566 TLS change_cipher_spec, 567 TLS finished) -> 568 <- PPP EAP-Request/ 569 EAP-Type=EAP-TLS 570 (TLS change_cipher_spec, 571 TLS finished) 572 PPP EAP-Response/ 573 EAP-Type=EAP-TLS -> 574 <- PPP EAP-Request 575 EAP-Type=EAP-TLS 576 (TLS Alert message) 577 PPP EAP-Response/ 578 EAP-Type=EAP-TLS -> 579 <- PPP EAP-Failure 580 (User Disconnected) 582 In the case where server authentication is unsuccessful, the 583 conversation will appear as follows: 585 Authenticating Peer Authenticator 586 ------------------- ------------- 587 <- PPP LCP Request-EAP 588 auth 589 PPP LCP ACK-EAP 590 auth -> 591 <- PPP EAP-Request/ 592 Identity 593 PPP EAP-Response/ 594 Identity (MyID) -> 595 <- PPP EAP-Request/ 596 EAP-Type=EAP-TLS 597 (TLS Start) 598 PPP EAP-Response/ 599 EAP-Type=EAP-TLS 600 (TLS client_hello)-> 601 <- PPP EAP-Request/ 602 EAP-Type=EAP-TLS 603 (TLS server_hello, 604 TLS certificate, 605 [TLS server_key_exchange,] 606 [TLS certificate_request,] 607 TLS server_hello_done) 608 PPP EAP-Response/ 609 EAP-Type=EAP-TLS 610 (TLS certificate, 611 TLS client_key_exchange, 612 [TLS certificate_verify,] 613 TLS change_cipher_spec, 614 TLS finished) -> 615 <- PPP EAP-Request/ 616 EAP-Type=EAP-TLS 617 (TLS change_cipher_spec, 618 TLS finished) 619 PPP EAP-Response/ 620 EAP-Type=EAP-TLS 621 (TLS change_cipher_spec, 622 TLS finished) 623 <- PPP EAP-Request/ 624 EAP-Type=EAP-TLS 625 PPP EAP-Response/ 626 EAP-Type=EAP-TLS 627 (TLS Alert message) -> 628 <- PPP EAP-Failure 629 (User Disconnected) 631 In the case where a previously established session is being resumed, and 632 both sides authenticate successfully, the conversation will appear as 633 follows: 635 Authenticating Peer Authenticator 636 ------------------- ------------- 637 <- PPP LCP Request-EAP 638 auth 639 PPP LCP ACK-EAP 640 auth -> 641 <- PPP EAP-Request/ 642 Identity 643 PPP EAP-Response/ 644 Identity (MyID) -> 645 <- PPP EAP-Request/ 646 EAP-Request/ 647 EAP-Type=EAP-TLS 648 (TLS Start) 649 PPP EAP-Response/ 650 EAP-Type=EAP-TLS 651 (TLS client_hello)-> 652 <- PPP EAP-Request/ 653 EAP-Type=EAP-TLS 654 (TLS server_hello, 655 TLS change_cipher_spec 656 TLS finished) 657 PPP EAP-Response/ 658 EAP-Type=EAP-TLS 659 (TLS change_cipher_spec, 660 TLS finished) -> 661 <- PPP EAP-Success 662 PPP Authentication 663 Phase complete, 664 NCP Phase starts 666 ECP negotiation 668 CCP negotiation 669 In the case where a previously established session is being resumed, and 670 the server authenticates to the client successfully but the client fails 671 to authenticate to the server, the conversation will appear as follows: 673 Authenticating Peer Authenticator 674 ------------------- ------------- 675 <- PPP LCP Request-EAP 676 auth 677 PPP LCP ACK-EAP 678 auth -> 679 <- PPP EAP-Request/ 680 Identity 681 PPP EAP-Response/ 682 Identity (MyID) -> 683 <- PPP EAP-Request/ 684 EAP-Request/ 685 EAP-Type=EAP-TLS 686 (TLS Start) 687 PPP EAP-Response/ 688 EAP-Type=EAP-TLS 689 (TLS client_hello) -> 690 <- PPP EAP-Request/ 691 EAP-Type=EAP-TLS 692 (TLS server_hello, 693 TLS change_cipher_spec, 694 TLS finished) 695 PPP EA-Response/ 696 EAP-Type=EAP-TLS 697 (TLS change_cipher_spec, 698 TLS finished) -> 699 <- PPP EAP-Request 700 EAP-Type=EAP-TLS 701 (TLS Alert message) 702 PPP EAP-Response 703 EAP-Type=EAP-TLS -> 704 <- PPP EAP-Failure 705 (User Disconnected) 707 In the case where a previously established session is being resumed, and 708 the server authentication is unsuccessful, the conversation will appear 709 as follows: 711 Authenticating Peer Authenticator 712 ------------------- ------------- 713 <- PPP LCP Request-EAP 714 auth 715 PPP LCP ACK-EAP 716 auth -> 717 <- PPP EAP-Request/ 718 Identity 719 PPP EAP-Response/ 720 Identity (MyID) -> 721 <- PPP EAP-Request/ 722 EAP-Request/ 723 EAP-Type=EAP-TLS 724 (TLS Start) 725 PPP EAP-Response/ 726 EAP-Type=EAP-TLS 727 (TLS client_hello)-> 728 <- PPP EAP-Request/ 729 EAP-Type=EAP-TLS 730 (TLS server_hello, 731 TLS change_cipher_spec, 732 TLS finished) 733 PPP EAP-Response/ 734 EAP-Type=EAP-TLS 735 (TLS change_cipher_spec, 736 TLS finished) 737 <- PPP EAP-Request/ 738 EAP-Type=EAP-TLS 739 PPP EAP-Response/ 740 EAP-Type=EAP-TLS 741 (TLS Alert message) -> 742 <- PPP EAP-Failure 743 (User Disconnected) 745 6. Detailed description of the EAP-TLS protocol 747 6.1. PPP EAP TLS Packet Format 749 A summary of the PPP EAP TLS Request/Response packet format is shown 750 below. The fields are transmitted from left to right. 752 0 1 2 3 753 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 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Code | Identifier | Length | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Type | Data... 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 Code 762 1 - Request 763 2 - Response 765 Identifier 767 The identifier field is one octet and aids in matching responses with 768 requests. 770 Length 772 The Length field is two octets and indicates the length of the EAP 773 packet including the Code, Identifier, Length, Type, and Data fields. 774 Octets outside the range of the Length field should be treated as 775 Data Link Layer padding and should be ignored on reception. 777 Type 779 13 - EAP TLS 781 Data 783 The format of the Data field is determined by the Code field. 785 6.2. PPP EAP TLS Request Packet 787 A summary of the PPP EAP TLS Request packet format is shown below. The 788 fields are transmitted from left to right. 790 0 1 2 3 791 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 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Code | Identifier | Length | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Type | Flags | TLS Message Length 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | TLS Message Length | TLS Data... 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 Code 802 1 804 Identifier 806 The Identifier field is one octet and aids in matching responses with 807 requests. The Identifier field MUST be changed on each Request 808 packet. 810 Length 812 The Length field is two octets and indicates the length of the EAP 813 packet including the Code, Identifier, Length, Type, and TLS Response 814 fields. 816 Type 818 13 - EAP TLS 820 Flags 822 0 1 2 3 4 5 6 7 8 823 +-+-+-+-+-+-+-+-+ 824 |L M S R R R R R| 825 +-+-+-+-+-+-+-+-+ 827 L = Length included 828 M = More fragments 829 S = EAP-TLS start 830 R = Reserved 832 The L bit (length included) is set to indicate the presence of the 833 four octet TLS Message Length field, and MUST be set for the first 834 fragment of a fragmented TLS message or set of messages. The M bit 835 (more fragments) is set on all but the last fragment. The S bit (EAP- 836 TLS start) is set in an EAP-TLS Start message. This differentiates 837 the EAP-TLS Start message from a fragment acknowledgement. 839 TLS Message Length 841 The TLS Message Length field is four octets, and is present only if 842 the L bit is set. This field provides the total length of the TLS 843 message or set of messages that is being fragmented. 845 TLS data 847 The TLS data consists of the encapsulated TLS packet in TLS record 848 format. 850 6.3. PPP EAP TLS Response Packet 852 A summary of the PPP EAP TLS Response packet format is shown below. The 853 fields are transmitted from left to right. 855 0 1 2 3 856 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 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Code | Identifier | Length | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Type | Flags | TLS Message Length 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | TLS Message Length | TLS Data... 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 Code 867 2 869 Identifier 871 The Identifier field is one octet and MUST match the Identifier field 872 from the corresponding request. 874 Length 876 The Length field is two octets and indicates the length of the EAP 877 packet including the Code, Identifir, Length, Type, and TLS data 878 fields. 880 Type 882 13 - EAP TLS 884 Flags 886 0 1 2 3 4 5 6 7 8 887 +-+-+-+-+-+-+-+-+ 888 |L M S R R R R R| 889 +-+-+-+-+-+-+-+-+ 891 L = Length included 892 M = More fragments 893 S = EAP-TLS start 894 R = Reserved 896 The L bit (length included) is set to indicate the presence of the 897 four octet TLS Message Length field, and MUST be set for the first 898 fragment of a fragmented TLS message or set of messages. The M bit 899 (more fragments) is set on all but the last fragment. The S bit (EAP- 900 TLS start) is set in an EAP-TLS Start message. This differentiates 901 the EAP-TLS Start message from a fragment acknowledgement. 903 TLS Message Length 905 The TLS Message Length field is four octets, and is present only if 906 the L bit is set. This field provides the total length of the TLS 907 message or set of messages that is being fragmented. 909 TLS data 911 The TLS data consists of the encapsulated TLS packet in TLS record 912 format. 914 7. References 916 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, 917 RFC 1661, July 1994. 919 [2] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, 920 "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. 922 [3] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994. 924 [4] Rivest, R., Dusse, S., "The MD5 Message-Digest Algorithm", RFC 925 1321, April 1992. 927 [5] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol 928 (EAP)", RFC 2284, March 1998. 930 [6] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 931 1996. 933 [7] National Bureau of Standards, "Data Encryption Standard", FIPS PUB 934 46 (January 1977). 936 [8] National Bureau of Standards, "DES Modes of Operation", FIPS PUB 81 937 (December 1980). 939 [9] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, Version 2 940 (DESE-bis)", RFC 2419, September 1998. 942 [10] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 943 2420, September 1998. 945 [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement 946 Levels", BCP 14, RFC 2119, March 1997. 948 [12] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 2246, 949 November 1998. 951 [13] D. Rand. "The PPP Compression Control Protocol", RFC 1962, Novell, 952 June 1996. 954 8. Security Considerations 956 8.1. Certificate revocation 958 Since the EAP server is on the Internet during the EAP conversation, the 959 server is capable of following a certificate chain or verifying whether 960 the peer's certificate has been revoked. In contrast, the peer may or 961 may not have Internet connectivity, and thus while it can validate the 962 EAP server's certificate based on a pre-configured set of CAs, it may 963 not be able to follow a certificate chain or verify whether the EAP 964 server's certificate has been revoked. 966 In the case where the peer is initiating a voluntary Layer 2 tunnel 967 using PPTP or L2TP, the peer will typically already have a PPP interface 968 and Internet connectivity established at the time of tunnel initiation. 969 As a result, during the EAP conversation it is capable of checking for 970 certificate revocation. 972 However, in the case where the peer is initiating an intial PPP 973 conversation, it will not have Internet connectivity and is therefore 974 not capable of checking for certificate revocation until after NCP 975 negotiation completes and the peer has access to the Internet. In this 976 case, the peer SHOULD check for certificate revocation after connecting 977 to the Internet. 979 8.2. Separation of the EAP server and PPP authenticator 981 As a result of the EAP-TLS conversation, the EAP endpoints will mutually 982 authenticate, negotiate a ciphersuite, and derive a session key for 983 subsequent use in PPP encryption. Since the peer and EAP client reside 984 on the same machine, it is necessary for the EAP client module to pass 985 the session key to the PPP encryption module. 987 The situation may be more complex on the PPP authenticator, which may or 988 may not reside on the same machine as the EAP server. In the case where 989 the EAP server and PPP authenticator reside on different machines, there 990 are several implications for security. Firstly, the mutual 991 authentication defined in EAP-TLS will occur between the peer and the 992 EAP server, not between the peer and the authenticator. This means that 993 as a result of the EAP-TLS conversation, it is not possible for the peer 994 to validate the identity of the NAS or tunnel server that it is speaking 995 to. 997 The second issue is that the session key negotiated between the peer and 998 EAP server will need to be transmitted to the authenticator. Therefore 999 a mechanism needs to be provided to transmit the session key from the 1000 EAP server to the authenticator or tunnel server that needs to use the 1001 key. The specification of this transit mechanism is outside the scope of 1002 this document. 1004 8.3. Relationship of PPP encryption to other security mechanisms 1006 It is envisaged that EAP-TLS will be used primarily with dialup PPP 1007 connections. However, there are also circumstances in which PPP 1008 encryption may be used along with Layer 2 tunneling protocols such as 1009 PPTP and L2TP. 1011 In compulsory layer 2 tunneling, a PPP peer makes a connection to a NAS 1012 or router which tunnels the PPP packets to a tunnel server. Since with 1013 compulsory tunneling a PPP peer cannot tell whether its packets are 1014 being tunneled, let alone whether the network device is securing the 1015 tunnel, if security is required then the client must make its own 1016 arrangements. In the case where all endpoints cannot be relied upon to 1017 implement IPSEC, TLS, or another suitable security protocol, PPP 1018 encryption provides a convenient means to ensure the privacy of packets 1019 transiting between the client and the tunnel server. 1021 9. Acknowledgments 1023 Thanks to Terence Spies, Glen Zorn and Narendra Gidwani of Microsoft for 1024 useful discussions of this problem space. 1026 10. Author Addresses 1028 Bernard Aboba 1029 Microsoft Corporation 1030 One Microsoft Way 1031 Redmond, WA 98052 1033 Phone: 425-936-6605 1034 EMail: bernarda@microsoft.com 1036 Dan Simon 1037 Microsoft Corporation 1038 One Microsoft Way 1039 Redmond, WA 98052 1040 Phone: 425-936-6711 1041 EMail: dansimon@microsoft.com 1043 11. Full Copyright Statement 1045 Copyright (C) The Internet Society (1999). All Rights Reserved. 1046 This document and translations of it may be copied and furnished to 1047 others, and derivative works that comment on or otherwise explain it or 1048 assist in its implmentation may be prepared, copied, published and 1049 distributed, in whole or in part, without restriction of any kind, 1050 provided that the above copyright notice and this paragraph are included 1051 on all such copies and derivative works. However, this document itself 1052 may not be modified in any way, such as by removing the copyright notice 1053 or references to the Internet Society or other Internet organizations, 1054 except as needed for the purpose of developing Internet standards in 1055 which case the procedures for copyrights defined inthe Internet 1056 Standards process must be followed, or as required to translate it into 1057 languages other than English. The limited permissions granted above are 1058 perpetual and will not be revoked by the Internet Society or its 1059 successors or assigns. This document and the information contained 1060 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1061 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1062 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1063 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1064 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1066 12. Expiration Date 1068 This memo is filed as , and expires 1069 March 1, 2000.