idnits 2.17.1 draft-ietf-pppext-eaptls-00.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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 260 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 424 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '...), its areas...' == Line 14 has weird spacing: '... its worki...' == Line 18 has weird spacing: '... and may ...' == Line 19 has weird spacing: '...afts as refer...' == Line 22 has weird spacing: '... To learn...' == (255 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (13 October 1997) is 9686 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 903, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 906, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 909, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 912, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 927, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 930, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '4') == Outdated reference: A later version (-07) exists of draft-ietf-pppext-eaprsa-04 -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' == Outdated reference: A later version (-02) exists of draft-ietf-pppext-des-encrypt-v2-00 == Outdated reference: A later version (-10) exists of draft-ietf-pppext-pptp-02 ** Downref: Normative reference to an Informational draft: draft-ietf-pppext-pptp (ref. '13') == Outdated reference: A later version (-16) exists of draft-ietf-pppext-l2tp-06 == Outdated reference: A later version (-06) exists of draft-ietf-tls-protocol-03 ** Downref: Normative reference to an Historic draft: draft-ietf-tls-protocol (ref. '15') == Outdated reference: A later version (-05) exists of draft-ietf-radius-eap-02 -- Possible downref: Normative reference to a draft: ref. '17' Summary: 16 errors (**), 0 flaws (~~), 21 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Extensions Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft 4 Category: Standards Track Dan Simon 5 Microsoft 6 13 October 1997 8 PPP EAP TLS Authentication Protocol 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute work- 15 ing documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference mate- 20 rial or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 The distribution of this memo is unlimited. It is filed as , and expires March 1, 1998. Please send 29 comments to the authors. 31 2. Abstract 33 The Point-to-Point Protocol (PPP) provides a standard method for 34 transporting multi-protocol datagrams over point-to-point links. PPP 35 also defines an extensible Link Control Protocol (LCP), which can be 36 used to negotiate authentication methods, as well as an Encryption 37 Control Protocol (ECP), used to negotiate data encryption over PPP 38 links, and a Compression Control Protocol (CCP), used to negotiate 39 compression methods. The Extensible Authentication Protocol (EAP) is 40 a PPP extension that provides support for additional authentication 41 methods within PPP. 43 Transport Level Security (TLS) provides for mutual authentication, 44 ciphersuite negotiation and key exchange between two endpoints. This 45 document describes how these TLS mechanisms may be used within EAP. 47 3. Introduction 49 The Extensible Authentication Protocol (EAP), described in [5], pro- 50 vides a standard mechanism for support of additional authentication 51 methods within PPP. Through the use of EAP, support for a number of 52 authentication schemes may be added, including smart cards, Kerberos, 53 Public Key, One Time Passwords, and others. To date however, EAP meth- 54 ods such as [6] have focussed on authenticating a client to a server. 56 However, in order to guard against rogue servers, it may be desirable 57 to support mutual authentication. In addition, since PPP encryption 58 protocols such as [10] and [11] assume existence of a session key, it 59 is useful to have a mechanism for session key establishment. Since 60 design of authentication and key management protocols is a non-trivial 61 exercise, it is desirable to avoid creating new mechanisms for this. 62 The EAP protocol described in this document allows a PPP peer to take 63 advantage of the mutual authentication and key management capabilities 64 of the TLS protocol, described in [15]. 66 3.1. Requirements language 68 This specification uses the same words as [12] for defining the sig- 69 nificance of each particular requirement. These words are: 71 MUST This word, or the adjectives "REQUIRED" or "SHALL", means 72 that the definition is an absolute requirement of the speci- 73 fication. 75 MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi- 76 nition is an absolute prohibition of the specification. 78 SHOULD This word, or the adjective "RECOMMENDED", means that there 79 may exist valid reasons in particular circumstances to 80 ignore a particular item, but the full implications must be 81 understood and carefully weighed before choosing a different 82 course. 84 SHOULD NOT 85 This phrase means that there may exist valid reasons in par- 86 ticular circumstances when the particular behavior is 87 acceptable or even useful, but the full implications should 88 be understood and the case carefully weighed before imple- 89 menting any behavior described with this label. 91 MAY This word, or the adjective "", means that an item is truly 92 optional. One vendor may choose to include the item because 93 a particular marketplace requires it or because the vendor 94 feels that it enhances the product while another vendor may 95 omit the same item. An implementation which does not 96 include a particular option MUST be prepared to interoperate 97 with another implementation which does include the option, 98 though perhaps with reduced functionality. In the same vein 99 an implementation which does include a particular option 100 MUST be prepared to interoperate with another implementation 101 which does not include the option.(except, of course, for 102 the feature the option provides) 104 An implementation is not compliant if it fails to satisfy one or more 105 of the must or must not requirements for the protocols it implements. 106 An implementation that satisfies all the must, must not, should and 107 should not requirements for its protocols is said to be "uncondition- 108 ally compliant"; one that satisfies all the must and must not require- 109 ments but not all the should or should not requirements for its proto- 110 cols is said to be "conditionally compliant." 112 4. Protocol overview 114 4.1. Overview of the EAP-TLS conversation 116 As described in [5] and [17], the EAP-TLS conversation will typically 117 begin with the authenticator and the peer negotiating EAP. The 118 authenticator will then typically send an EAP-Request/Identity packet 119 to the peer, and the peer will respond with an EAP-Response/Identity 120 packet to the authenticator, containing the peer's userId. 122 From this point forward, while nominally the EAP conversation occurs 123 between the authenticator and the peer, as described in [17] the 124 authenticator MAY act as a passthrough device, with the EAP packets 125 received from the peer being encapsulated for transmission to a RADIUS 126 server or backend security server. In the discussion that follows, we 127 will use the term "EAP server" to denote the ultimate endpoint con- 128 versing with the peer. 130 Once having received the peer's userId, the EAP server will respond 131 with an EAP-TLS/Start packet, which is an EAP-Request packet with EAP- 132 Type=EAP-TLS, and no data. The EAP-TLS conversation will then begin, 133 with the peer sending an EAP-Response packet with EAP-Type=EAP-TLS. 134 The data field of that packet will encapsulate one or more TLS records 135 in TLS record layer format, containing a TLS client_hello handshake 136 message. The current cipher spec for the TLS records will be 137 TLS_NULL_WITH_NULL_NULL and null compression. This current cipher 138 spec remains the same until the change_cipher_spec message signals 139 that subsequent records will have the negotiated attributes for the 140 remainder of the handshake. 142 The client_hello message contains the client's TLS version number, a 143 sessionId, a random number, and a set of ciphersuites supported by the 144 client. The version offered by the client MUST correspond to TLS v1.0 145 or later. 147 The EAP server will then respond with an EAP-Request packet with EAP- 148 Type=EAP-TLS. The data field of this packet will encapsulate one or 149 more TLS records. These will contain a TLS server_hello handshake mes- 150 sage, possibly followed by TLS certificate, server_key_exchange, cer- 151 tificate_request, server_hello_done and/or finished handshake mes- 152 sages, and/or a TLS change_cipher_spec message. The server_hello 153 handshake message contains a TLS version number, another random num- 154 ber, a sessionId, and a ciphersuite. The version offered by the 155 server MUST correspond to TLS v1.0 or later. 157 If the client's sessionId is null or unrecognized by the server, the 158 server will choose the sessionId to establish a new session; other- 159 wise, the sessionId will match that offered by the client, indi- 160 cating a resumption of the previously established session with that 161 sessionID. The server will also choose a ciphersuite from those 162 offered by the client; if the session matches the client's, then the 163 ciphersuite MUST match the one negotiated during the handshake proto- 164 col execution that established the session. 166 The purpose of the sessionId within the TLS protocol is to allow for 167 improved efficiency in the case where a client repeatedly attempts to 168 authenticate to an EAP server within a short period of time. While 169 this model was developed for use with HTTP authentication, it may also 170 have application to PPP authentication (e.g. multilink). 172 As a result, it is left up to the peer whether to attempt to continue 173 a previous session, thus shortening the TLS conversation. Typically 174 the peer's decision will be made based on the time elapsed since the 175 previous authentication attempt to that EAP server. Based on the ses- 176 sionId chosen by the peer, and the time elapsed since the previous 177 authentication, the EAP server will decide whether to allow the con- 178 tinuation, or whether to choose a new session. 180 In the case where the EAP server and authenticator reside on the same 181 device, then client will only be able to continue sessions when con- 182 necting to the same NAS or tunnel server. Should these devices be set 183 up in a rotary or round-robin then it may not be possible for the peer 184 to know in advance the authenticator it will be connecting to, and 185 therefore which sessionId to attempt to reuse. As a result, it is 186 likely that the continuation attempt will fail. In the case where the 187 EAP authentication is remoted then continuation is much more likely to 188 be successful, since multiple NAS devices and tunnel servers will 189 remote their EAP authentications to the same RADIUS server. 191 If the EAP server is resuming a previously established session, then 192 it MUST include only a TLS change_cipher_spec message and a TLS fin- 193 ished handshake message after the server_hello message. The finished 194 message contains the EAP server's authentication response to the peer. 195 If the EAP server is not resuming a previously established session, 196 then it MUST include a TLS server_certificate handshake message, and a 197 server_hello_done handshake message MUST be the last handshake message 198 encapsulated in this EAP-Request packet. 200 The certificate message contains a public key certificate chain for 201 either a key exchange public key (such as an RSA or Diffie-Hellman key 202 exchange public key) or a signature public key (such as an RSA or DSS 203 signature public key). In the latter case, a TLS server_key_exchange 204 handshake message MUST also be included to allow the key exchange to 205 take place. 207 The certificate_request message is included when the server desires 208 the client to authenticate itself via public key. While the EAP server 209 SHOULD require client authentication, this is not a requirement, since 210 it may be possible that the server will require that the peer authen- 211 ticate via some other means. 213 The peer will then respond with an EAP-Response packet with EAP- 214 Type=EAP-TLS. The data field of this packet will encapsulate one or 215 more TLS records containing a TLS change_cipher_spec message and fin- 216 ished handshake message, and possibly certificate, certificate_verify 217 and/or client_key_exchange handshake messages. If the preceding 218 server_hello message sent by the EAP server in the preceding EAP- 219 Request packet indicated the resumption of a previous session, then 220 the peer MUST send only the change_cipher_spec and finished handshake 221 messages. The finished message contains the peer's authentication 222 response to the EAP server. 224 If the preceding server_hello message sent by the EAP server in the 225 preceding EAP-Request packet did not indicate the resumption of a pre- 226 vious session, then the peer MUST send, in addition to the 227 change_cipher_spec and finished messages, a client_key_exchange mes- 228 sage, which completes the exchange of a shared master secret between 229 the peer and the EAP server. If the EAP server sent a certifi- 230 cate_request message in the preceding EAP-Request packet, then the 231 peer MUST send, in addition, certificate and certificate_verify hand- 232 shake messages. The former contains a certificate for the peer's sig- 233 nature public key, while the latter contains the peer's signed authen- 234 tication response to the EAP server. 236 After receiving this packet, the EAP server will verify the peer's 237 certificate and digital signature, if requested. If the authentication 238 is unsuccessful, the EAP server will send an EAP-Request packet with 239 EAP-Type=EAP-TLS, encapsulating a TLS record containing the appropri- 240 ate TLS alert message. It is useful for the EAP server to send a TLS 241 alert message rather than immediately terminating the conversation so 242 as to allow the peer to inform the user of the cause of the failure 243 and allow them to correct the condition. 245 To ensure that the peer receives the TLS alert message, the EAP server 246 will wait for the peer to reply with an EAP-Response packet. The EAP- 247 Response packet sent by the peer may encapsulate a TLS client_hello 248 handshake message, in which case the EAP server may allow the EAP-TLS 249 conversation to be restarted, or it may contain an EAP-Response packet 250 with EAP-Type=EAP-TLS and no data, in which case the EAP-Server will 251 send an EAP-Failure packet, and terminate the conversation. It is up 252 to the EAP server whether to allow restarts, and if so, how many times 253 the conversation can be restarted. An EAP Server implementing restart 254 capability SHOULD impose a limit on the number of restarts, so as to 255 protect against denial of service attacks. 257 In the case that the authentication is successful, the EAP server will 258 respond with an EAP-Request packet with EAP-Type=EAP-TLS, which 259 includes, in the case of a new TLS session, one or more TLS records 260 containing TLS change_cipher_spec and finished handshake messages. 261 The latter contains the EAP server's authentication response to the 262 peer. The peer will then verify the hash in order to authenticate the 263 EAP server. 265 If EAP server authentication is unsuccessful, the peer sends an EAP- 266 Response packet of EAP-Type=EAP-TLS containing a TLS Alert message 267 identifying the reason for the failed authentication. It is useful for 268 the peer to send a TLS alert message rather than immediately terminat- 269 ing the conversation so as to allow the EAP server to log the cause of 270 the error for examination by the system administrator. 272 To ensure that the EAP Server receives the TLS alert message, the peer 273 will wait for the EAP-Server to reply with an EAP-Request packet. The 274 EAP-Request packet sent by the EAP server will be of EAP-Type=EAP-TLS 275 and will contain no data, and the peers will respond with an EAP-Fail- 276 ure packet and terminate the conversation. 278 4.2. Retry behavior 280 As with other EAP protocols, the EAP server is responsible for retry 281 behavior. This means that if the EAP server does not receive a reply 282 from the peer, it will resend the EAP-Request for which it has not yet 283 received an EAP-Response. However, the peer will not resend EAP- 284 Response packets without first being prompted by the EAP server. 286 For example, if the initial EAP-TLS start packet sent by the EAP 287 server were to be lost, then the peer would not receive this packet, 288 and would not respond to it. As a result, the EAP-TLS start packet 289 would be resent by the EAP server. Once the peer received the EAP-TLS 290 start packet, it would respond with an EAP-Response encapsulating the 291 client_hello message. If the EAP-Response were to be lost, then the 292 EAP server would resend the initial EAP-TLS start, and the peer would 293 resend the EAP-Response. 295 As a result, it is possible that a peer will receive duplicate EAP- 296 Request messages, and may send duplicate EAP-Responses. Both the peer 297 and the EAP-Server should be engineered to handle this possibility. 299 4.3. Identity verification 301 As part of the TLS negotiation, the server presents a certificate to 302 the peer, and if mutual authentication is requested, the peer presents 303 a certificate to the server. 305 Note that since the peer has made a claim of identity in the EAP- 306 Response/Identity (MyID) packet, the EAP server SHOULD verify that the 307 claimed identity corresponds to the certificate presented by the peer. 308 Typically this will be accomplished either by placing the userId 309 within the peer certificate, or by providing a mapping between the 310 peer certificate and the userId using a directory service. 312 Similarly, the peer MUST verify the validity of the EAP server cer- 313 tificate, and SHOULD also examine the EAP server name presented in the 314 certificate, in order to determine whether the EAP server can be 315 trusted. Please note that in the case where the EAP authentication is 316 remoted that the EAP server will not reside on the same machine as the 317 authenticator, and therefore the name in the EAP server's certificate 318 cannot be expected to match that of the intended destination. In this 319 case, a more appropriate test might be whether the EAP server's cer- 320 tificate is signed by a CA controlling the intended destination and 321 whether the EAP server exists within a target sub-domain. 323 4.4. Key derivation 325 Since the normal TLS keys are used in the handshake, and therefore 326 should not be used in a different context, new encryption keys must be 327 derived from the TLS master secret for use with PPP encryption. For 328 both peer and EAP server, the derivation proceeds as follows: given 329 the master secret negotiated by the TLS handshake, the pseudorandom 330 function (PRF) defined in the specification for the version of TLS in 331 use, and the value random defined as the concatenation of the hand- 332 shake message fields client_hello.random and server_hello.random (in 333 that order), the value PRF(master secret, "client EAP encryption", 334 random) is computed up to 128 bytes, and the value PRF("", "client EAP 335 encryption", random) is computed up to 64 bytes (where "" is an empty 336 string). The peer encryption key (the one used for encrypting data 337 from peer to EAP server) is obtained by truncating to the correct 338 length the first 32 bytes of the first PRF of these two output 339 strings. The EAP server encryption key (the one used for encrypting 340 data from EAP server to peer), if different from the client encryption 341 key, is obtained by truncating to the correct length the second 32 342 bytes of this same PRF output string. The client authentication key 343 (the one used for computing MACs for messages from peer to EAP 344 server), if used, is obtained by truncating to the correct length the 345 third 32 bytes of this same PRF output string. The EAP server authen- 346 tication key (the one used for computing MACs for messages from EAP 347 server to peer), if used, and if different from the peer authentica- 348 tion key, is obtained by truncating to the correct length the fourth 349 32 bytes of this same PRF output string. The peer initialization vec- 350 tor (IV), used for messages from peer to EAP server if a block cipher 351 has been specified, is obtained by truncating to the cipher's block 352 size the first 32 bytes of the second PRF output string mentioned 353 above. Finally, the server initialization vector (IV), used for mes- 354 sages from peer to EAP server if a block cipher has been specified, is 355 obtained by truncating to the cipher's block size the second 32 bytes 356 of this second PRF output. 358 The use of these encryption and authentication keys is specific to the 359 PPP encryption mechanism used, such as those defined in [10] and [11]. 360 Additional keys or other non-secret values (such as IVs) can be 361 obtained as needed for future PPP encryption methods by extending the 362 outputs of the PRF beyond 128 bytes and 64 bytes, respectively. 364 4.5. ECP negotiation 366 Since TLS supports ciphersuite negotiation, peers completing the TLS 367 negotiation will also have selected a ciphersuite, which includes key 368 strength, encryption and hashing methods. As a result, a subsequent 369 Encryption Control Protocol (ECP) conversation, if it occurs, has a 370 predetermined result. 372 In order to ensure agreement between the EAP-TLS ciphersuite negotia- 373 tion and the subsequent ECP negotiation (described in [7]), during ECP 374 negotiation the PPP peer MUST offer only the ciphersuite negotiated in 375 EAP-TLS. This ensures that the PPP authenticator MUST accept the EAP- 376 TLS negotiated ciphersuite in order for the conversation to proceed. 377 Should the authenticator not accept the EAP-TLS negotiated cipher- 378 suite, then the peer MUST send an LCP terminate and disconnect. 380 Please note that as described in [17], it cannot be assumed that the 381 PPP authenticator and EAP server are located on the same machine or 382 that the authenticator understands the EAP-TLS conversation that has 383 passed through it. Thus if the peer offers a ciphersuite other than 384 the one negotiated in EAP-TLS there is no way for the authenticator to 385 know how to respond correctly. 387 4.6. CCP negotiation 389 TLS as described in [15] supports compression as well as ciphersuite 390 negotiation. However, TLS only provides support for a limited number 391 of compression types which do not overlap with the compression types 392 used in PPP. As a result, during the EAP-TLS conversation the EAP end- 393 points MUST NOT request or negotiate compression. Instead, the PPP 394 Compression Control Protocol (CCP), described in [16] should be used 395 to negotiate the desired compression scheme. 397 4.7. Examples 399 In the case where the EAP-TLS mutual authentication is successful, the 400 conversation will appear as follows: 402 Authenticating Peer Authenticator 403 ------------------- ------------- 405 <- PPP LCP Request-EAP 406 auth 407 PPP LCP ACK-EAP 408 auth -> 409 <- PPP EAP-Request/ 410 Identity 411 PPP EAP-Response/ 412 Identity (MyID) -> 413 <- PPP EAP-Request/ 414 EAP-Type=EAP-TLS 415 (TLS Start) 417 PPP EAP-Response/ 418 EAP-Type=EAP-TLS 419 (TLS client_hello)-> 420 <- PPP EAP-Request/ 421 EAP-Type=EAP-TLS 422 (TLS server_hello, 423 TLS certificate, 424 [TLS server_key_exchange,] 425 [TLS certificate_request,] 426 TLS server_hello_done) 427 PPP EAP-Response/ 428 EAP-Type=EAP-TLS 429 (TLS certificate, 430 TLS client_key_exchange, 431 [TLS certificate_verify,] 432 TLS change_cipher_spec, 433 TLS finished) -> 434 <- PPP EAP-Request/ 435 EAP-Type=EAP-TLS 436 (TLS change_cipher_spec, 437 TLS finished) 438 PPP EAP-Success-> 439 <- PPP EAP-Success 441 PPP Authentication 442 Phase complete, 443 NCP Phase starts 445 ECP negotiation 447 CCP negotiation 449 In the case where the server authenticates to the client successfully, 450 but the client fails to authenticate to the server, the conversation 451 will appear as follows: 453 Authenticating Peer Authenticator 454 ------------------- ------------- 455 <- PPP LCP Request-EAP 456 auth 457 PPP LCP ACK-EAP 458 auth -> 459 <- PPP EAP-Request/ 460 Identity 461 PPP EAP-Response/ 462 Identity (MyID) -> 463 <- PPP EAP-Request/ 464 EAP-Type=EAP-TLS 465 (TLS Start) 466 PPP EAP-Response/ 467 EAP-Type=EAP-TLS 468 (TLS client_hello)-> 469 <- PPP EAP-Request/ 470 EAP-Type=EAP-TLS 471 (TLS server_hello, 472 TLS certificate, 473 [TLS server_key_exchange,] 474 TLS certificate_request, 475 TLS server_hello_done) 476 PPP EAP-Response/ 477 EAP-Type=EAP-TLS 478 (TLS certificate, 479 TLS client_key_exchange, 480 TLS certificate_verify, 481 TLS change_cipher_spec, 482 TLS finished) -> 483 <- PPP EAP-Request 484 EAP-Type=EAP-TLS 485 (TLS Alert message) 486 PPP EAP-Response/ 487 EAP-Type=EAP-TLS -> 488 <- PPP EAP-Failure 489 (User Disconnected) 491 In the case where server authentication is unsuccessful, the conversa- 492 tion will appear as follows: 494 Authenticating Peer Authenticator 495 ------------------- ------------- 496 <- PPP LCP Request-EAP 497 auth 498 PPP LCP ACK-EAP 499 auth -> 500 <- PPP EAP-Request/ 501 Identity 502 PPP EAP-Response/ 503 Identity (MyID) -> 504 <- PPP EAP-Request/ 505 EAP-Type=EAP-TLS 506 (TLS Start) 507 PPP EAP-Response/ 508 EAP-Type=EAP-TLS 509 (TLS client_hello)-> 510 <- PPP EAP-Request/ 511 EAP-Type=EAP-TLS 512 (TLS server_hello, 513 TLS certificate, 514 [TLS server_key_exchange,] 515 [TLS certificate_request,] 516 TLS server_hello_done) 517 PPP EAP-Response/ 518 EAP-Type=EAP-TLS 519 (TLS certificate, 520 TLS client_key_exchange, 521 [TLS certificate_verify,] 522 TLS change_cipher_spec, 523 TLS finished) -> 524 <- PPP EAP-Request/ 525 EAP-Type=EAP-TLS 526 (TLS change_cipher_spec, 527 TLS finished) 528 PPP EAP-Response/ 529 EAP-Type=EAP-TLS 530 (TLS Alert message) -> 532 <- PPP EAP-Request 533 EAP-Type=EAP-TLS 534 PPP EAP-Failure -> 536 PPP LCP Terminate -> 537 (User Disconnected) 539 In the case where a previously established session is being resumed, 540 and both sides authenticate successfully, the conversation will appear 541 as follows: 543 Authenticating Peer Authenticator 544 ------------------- ------------- 545 <- PPP LCP Request-EAP 546 auth 547 PPP LCP ACK-EAP 548 auth -> 549 <- PPP EAP-Request/ 550 Identity 551 PPP EAP-Response/ 552 Identity (MyID) -> 553 <- PPP EAP-Request/ 554 EAP-Request/ 555 EAP-Type=EAP-TLS 556 (TLS Start) 557 PPP EAP-Response/ 558 EAP-Type=EAP-TLS 559 (TLS client_hello)-> 560 <- PPP EAP-Request/ 561 EAP-Type=EAP-TLS 562 (TLS server_hello, 563 TLS change_cipher_spec, 564 TLS finished) 565 PPP EAP-Response/ 566 EAP-Type=EAP-TLS 567 (TLS change_cipher_spec, 568 TLS finished) -> 569 <- PPP EAP-Success 571 PPP Authentication 572 Phase complete, 573 NCP Phase starts 575 ECP negotiation 577 CCP negotiation 578 In the case where a previously established session is being resumed, 579 and the server authenticates to the client successfully but the client 580 fails to authenticate to the server, the conversation will appear as 581 follows: 583 Authenticating Peer Authenticator 584 ------------------- ------------- 585 <- PPP LCP Request-EAP 586 auth 587 PPP LCP ACK-EAP 588 auth -> 589 <- PPP EAP-Request/ 590 Identity 591 PPP EAP-Response/ 592 Identity (MyID) -> 593 <- PPP EAP-Request/ 594 EAP-Request/ 595 EAP-Type=EAP-TLS 596 (TLS Start) 597 PPP EAP-Response/ 598 EAP-Type=EAP-TLS 599 (TLS client_hello) -> 600 <- PPP EAP-Request/ 601 EAP-Type=EAP-TLS 602 (TLS server_hello, 603 TLS change_cipher_spec, 604 TLS finished) 605 PPP EAP-Response/ 606 EAP-Type=EAP-TLS 607 (TLS change_cipher_spec, 608 TLS finished) -> 609 <- PPP EAP-Request 610 EAP-Type=EAP-TLS 611 (TLS Alert message) 612 PPP EAP-Response 613 EAP-Type=EAP-TLS -> 614 <- PPP EAP-Failure 615 (User Disconnected) 617 In the case where a previously established session is being resumed, 618 and the server authentication is unsuccessful, the conversation will 619 appear as follows: 621 Authenticating Peer Authenticator 622 ------------------- ------------- 623 <- PPP LCP Request-EAP 624 auth 625 PPP LCP ACK-EAP 626 auth -> 627 <- PPP EAP-Request/ 628 Identity 629 PPP EAP-Response/ 630 Identity (MyID) -> 631 <- PPP EAP-Request/ 632 EAP-Request/ 633 EAP-Type=EAP-TLS 634 (TLS Start) 635 PPP EAP-Response/ 636 EAP-Type=EAP-TLS 637 (TLS client_hello)-> 638 <- PPP EAP-Request/ 639 EAP-Type=EAP-TLS 640 (TLS server_hello, 641 TLS change_cipher_spec, 642 TLS finished) 643 PPP EAP-Response/ 644 EAP-Type=EAP-TLS 645 (TLS Alert message) -> 647 <- PPP EAP-Request 648 EAP-Type=EAP-TLS 649 PPP EAP-Failure -> 651 PPP LCP Terminate -> 652 (User Disconnected) 654 5. Detailed description of the EAP-TLS protocol 656 5.1. PPP EAP TLS Packet Format 658 A summary of the PPP EAP TLS Request/Response packet format is shown 659 below. The fields are transmitted from left to right. 661 0 1 2 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Code | Identifier | Length | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Type | Data ... 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 669 Code 671 1 - Request 672 2 - Response 674 Identifier 676 The identifier field is one octet and aids in matching responses 677 with requests. 679 Length 681 The Length field is two octets and indicates the length of the EAP 682 packet including the Code, Identifier, Length, Type, and Data 683 fields. Octets outside the range of the Length field should be 684 treated as Data Link Layer padding and should be ignored on recep- 685 tion. 687 Type 689 ? - EAP TLS 691 Data 693 The format of the Data field is determined by the Code field. 695 5.2. PPP EAP TLS Request Packet 697 A summary of the PPP EAP TLS Request packet format is shown below. 698 The fields are transmitted from left to right. 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Code | Identifier | Length | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Type | TLS data... 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 Code 710 1 712 Identifier 714 The identifier field is one octet and aids in matching responses 715 with requests. The identifier field MUST be changed on each 716 Request packet. 718 Length 720 The Length field is two octets and indicates the length of the EAP 721 packet including the Code, Identifier, Length, Type, and TLS 722 Response fields. 724 Type 726 ? - EAP TLS 728 TLS data 730 The TLS data consists of the encapsulated TLS packet in TLS record 731 format. 733 5.3. PPP EAP TLS Response Packet 735 A summary of the PPP EAP TLS Response packet format is shown below. 736 The fields are transmitted from left to right. 738 0 1 2 3 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Code | Identifier | Length | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Type | TLS Data... 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 Code 748 2 750 Identifier 752 The identifier field is one octet and MUST match the Identifier 753 field from the corresponding request. 755 Length 757 The Length field is two octets and indicates the length of the EAP 758 packet including the Code, Identifier, Length, Type, and TLS data 759 fields. 761 Type 763 ? - EAP TLS 765 TLS data 767 The TLS data consists of the encapsulated TLS packet in TLS record 768 format. 770 6. Security issues 772 6.1. Certificate revocation 774 Since the EAP server is on the Internet during the EAP conversation, 775 the EAP server is capable of following a certificate chain or verify- 776 ing whether the peer's certificate has been revoked. In contrast, the 777 peer may or may not have Internet connectivity, and thus while it can 778 validate the EAP server's certificate based on a pre-configured set of 779 CAs, it may not be able to follow a certificate chain or verify 780 whether the EAP server's certificate has been revoked. 782 In the case where the peer is initiating a voluntary Layer 2 tunnel 783 using PPTP or L2TP, the peer will typically already have a PPP inter- 784 face and Internet connectivity established at the time of tunnel 785 initiation. As a result, during the EAP conversation it is capable of 786 checking for certificate revocation. 788 However, in the case where the peer is initiating an intial PPP con- 789 versation, it will not have Internet connectivity and is therefore not 790 capable of checking for certificate revocation until after NCP negoti- 791 ation completes and the peer has access to the Internet. In this case, 792 the peer SHOULD check for certificate revocation after connecting to 793 the Internet. 795 6.2. Separation of the EAP server and PPP authenticator 797 As a result of the EAP-TLS conversation, the EAP endpoints will mutu- 798 ally authenticate, negotiate a ciphersuite, and derive a session key 799 for subsequent use in PPP encryption. Since the peer and EAP client 800 reside on the same machine, it is necessary for the EAP client module 801 to pass the session key to the PPP encryption module. 803 The situation may be more complex on the PPP authenticator. As noted 804 in [17], the PPP authenticator may or may not reside on the same 805 machine as the EAP server. For example, when RADIUS/EAP is used, the 806 EAP server may be a backend security server, or a module residing on 807 the RADIUS server. 809 In the case where the EAP server and PPP authenticator reside on dif- 810 ferent machines, there are several implications for security. Firstly, 811 the mutual authentication defined in EAP-TLS will occur between the 812 peer and the EAP server, not between the peer and the authenticator. 813 This means that as a result of the EAP-TLS conversation, it is not 814 possible for the peer to validate the identity of the NAS or tunnel 815 server that it is speaking to. 817 As described in [17], when EAP/RADIUS is used to encapsulate EAP pack- 818 ets, the Signature attribute is required in EAP/RADIUS Access-Requests 819 sent from the NAS or tunnel server to the RADIUS server. Since the 820 Signature attribute involves a keyed-MD5 hash, it is possible for the 821 RADIUS server to verify the integrity of the Access-Request as well as 822 the NAS or tunnel server's identity. Similarly, Access-Challenge pack- 823 ets sent from the RADIUS server to the NAS are also authenticated and 824 integrity protected using a keyed-MD5 hash, enabling the NAS or tunnel 825 server to determine the integrity of the packet and verify the iden- 826 tity of the RADIUS server. Moreover, EAP-TLS packets in transit are 827 integrity protected and authenticated end-to-end via TLS mechanisms, 828 so that they cannot be successfully modified by a rogue NAS or tunnel 829 server. 831 The second issue that arises in the case of an EAP server and PPP 832 authenticator residing on different machines is that the session key 833 negotiated between the peer and EAP server will need to be transmitted 834 to the authenticator. Therefore a mechanism needs to be provided to 835 transmit the session key from the EAP server to the authenticator or 836 tunnel server that needs to use the key. The specification of this 837 transit mechanism is outside the scope of this document. 839 6.3. Relationship of PPP encryption to other security mechanisms 841 PPP encryption currently plays an important role in the securing of 842 Layer 2 tunneling protocols such as PPTP, described in [13], and L2TP, 843 described in [14]. While it may be envisaged that security mechanisms 844 such as IPSEC will eventually become ubiquitous, it will take some 845 time for vendors to add IPSEC capabilities to their devices, and in 846 any case legacy authenticator devices or routers may not be able to 847 support IPSEC without being upgraded. As a result, it is likely that 848 non-IPSEC capable devices will persist in operational networks for 849 quite some time. 851 In an environment where IPSEC is not ubiquitous, in Layer 2 tunneling 852 protocols a role remains for PPP encryption. Since with mandatory tun- 853 neling a PPP peer cannot tell whether its packets are being tunneled, 854 let alone whether the authenticator is securing the tunnel, if secu- 855 rity is required then the client must make its own arrangements. In 856 the case where all endpoints cannot be relied upon to implement IPSEC, 857 TLS, or another suitable security protocol, then PPP encryption pro- 858 vides a very convenient means to ensure the privacy of packets tran- 859 siting between the client and the tunnel server. 861 There also may be circumstances in which PPP encryption may be desir- 862 able even if IPSEC is available. Routers implementing Network Address 863 Translation (NAT) are now growing rapidly in popularity. Where NAT is 864 turned on, IPSEC cannot be used to secure the outer layer of a client- 865 initiated layer 2 tunnel, since the address translated packet will 866 then fail the authentication check. By contrast, Layer 2 tunnels uti- 867 lizing PPP encryption may pass unimpeded through a NAT. 869 7. Copyright notice 871 Copyright (C) The Internet Society, 1997. All Rights Reserved. 873 This document and translations of it may be copied and furnished to 874 others, and derivative works that comment on or otherwise explain it 875 or assist in its implmentation may be prepared, copied, published and 876 distributed, in whole or in part, without restriction of any kind, 877 provided that the above copyright notice and this paragraph are 878 included on all such copies and derivative works. However, this docu- 879 ment itself may not be modified in any way, such as by removing the 880 copyright notice or references to the Internet Society or other Inter- 881 net organizations, except as needed for the purpose of developing 882 Internet standards in which case the procedures for copyrights defined 883 in the Internet Standards process must be followed, or as required to 884 translate it into languages other than English. 886 The limited permissions granted above are perpetual and will not be 887 revoked by the Internet Society or its successors or assigns. 889 This document and the information contained herein is provided on an 890 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 891 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 892 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 893 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 894 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 896 8. Acknowledgments 898 Thanks to Terence Spies, Glen Zorn and Narendra Gidwani of Microsoft 899 for useful discussions of this problem space. 901 9. References 903 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)." STD 51, 904 RFC 1661, Daydreamer, July 1994. 906 [2] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, 907 "The PPP Multilink Protocol (MP)." RFC 1990, UC Berkeley, August 1996. 909 [3] Simpson, W., Editor, "PPP LCP Extensions." RFC 1570, Daydreamer, 910 January 1994. 912 [4] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm." RFC 913 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., 914 April 1992. 916 [5] L. J. Blunk, J. R. Vollbrecht. "PPP Extensible Authentication 917 Protocol (EAP)." Work in progress, draft-ietf-pppext-eap-auth-02.txt, 918 Merit Network, Inc., June 1996. 920 [6] W. T. Whelan, "PPP EAP RSA Public Key Authentication Protocol." 921 Work in progress, draft-ietf-pppext-eaprsa-04.txt, Cabletron Systems, 922 February 1997. 924 [7] Meyer, G., "The PPP Encryption Protocol (ECP)." RFC 1968, Spider 925 Systems. June 1996 927 [8] National Bureau of Standards, "Data Encryption Standard." FIPS PUB 928 46 (January 1977). 930 [9] National Bureau of Standards, "DES Modes of Operation." FIPS PUB 931 81 (December 1980). 933 [10] K. Sklower, G. Meyer. "The PPP DES Encryption Protocol, Version 934 2 (DESE-bis)" Work in progress, draft-ietf-pppext-des-encrypt- 935 v2-00.txt, University of California, Berkeley, Shiva, July 1997. 937 [11] K. Hummert. "The PPP Triple-DES Encryption Protocol (3DESE)" 938 Work in progress, draft-ietf-pppext-3des-encrypt-00.txt, Nentec GmbH, 939 July 1997. 941 [12] S. Bradner. "Key words for use in RFCs to Indicate Requirement 942 Levels." RFC 2119, Harvard University, March 1997. 944 [13] K. Hamzeh, G. S. Pall, J. Taarud, W. Verthein, W. A. Little. 945 "Point-to-Point Tunneling Protocol -- PPTP." Internet draft (work in 946 progress), draft-ietf-pppext-pptp-02.txt, Ascend Communications, 947 Microsoft, Copper Mountain Networks, U.S. Robotics, July 1997. 949 [14] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, B. Palter, J. 950 Taarud, W. M. Townsley, A. Valencia, W. Verthein. "Layer Two Tunnel- 951 ing Protocol L2TP." Internet draft (work in progress) draft-ietf- 952 pppext-l2tp-06.txt, Ascend Communications, Cisco Systems, Microsoft, 953 Copper Mountain Networks, IBM, U.S. Robotics, August 1997. 955 [15] T. Dierks, C. Allen. "The TLS Protocol Version 1.0." Internet 956 draft (work in progress) draft-ietf-tls-protocol-03.txt, Consensus 957 Development, May 1997. 959 [16] D. Rand. "The PPP Compression Control Protocol." RFC 1962, Nov- 960 ell, June 1996. 962 [17] P. Calhoun, A.C. Rubens, B. Aboba. "Extensible Authentication 963 Protocol Support in RADIUS." Internet draft (work in progress), draft- 964 ietf-radius-eap-02.txt, US Robotics Access Corp., Merit Network, 965 Microsoft, May, 1997. 967 10. Authors' Addresses 969 Bernard Aboba 970 Microsoft Corporation 971 One Microsoft Way 972 Redmond, WA 98052 974 Phone: 425-936-6605 975 EMail: bernarda@microsoft.com 977 Dan Simon 978 Microsoft Corporation 979 One Microsoft Way 980 Redmond, WA 98052 982 Phone: 425-936-6711 983 EMail: dansimon@microsoft.com