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