idnits 2.17.1 draft-ietf-pppext-eaptls-01.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 252 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 425 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...' == (247 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 (14 October 1997) is 9663 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 895, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 898, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 901, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 904, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 919, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 922, 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 14 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 May 1, 1998. Please send com- 29 ments 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 preceeding EAP-Request packet did not indicate the resumption of a 226 previous 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. After receiving this packet, the 235 EAP server will verify the peer's certificate and digital signature, 236 if requested. 238 If the peer's authentication is unsuccessful, the EAP server will send 239 an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS 240 record containing the appropriate TLS alert message. It is useful for 241 the EAP server to send a TLS alert message rather than to immediately 242 terminate the conversation so as to allow the peer to inform the user 243 of the cause of the failure and possibly allow for a restart of the 244 conversation. 246 To ensure that the peer receives the TLS alert message, the EAP server 247 will wait for the peer to reply with an EAP-Response packet. The EAP- 248 Response packet sent by the peer may encapsulate a TLS client_hello 249 handshake message, in which case the EAP server may allow the EAP-TLS 250 conversation to be restarted, or it may contain an EAP-Response packet 251 with EAP-Type=EAP-TLS and no data, in which case the EAP-Server will 252 send an EAP-Failure packet, and terminate the conversation. It is up 253 to the EAP server whether to allow restarts, and if so, how many times 254 the conversation can be restarted. An EAP Server implementing restart 255 capability SHOULD impose a limit on the number of restarts, so as to 256 protect against denial of service attacks. 258 If the peers authenticates successfully, the EAP server will respond 259 with an EAP-Request packet with EAP-Type=EAP-TLS, which includes, in 260 the case of a new TLS session, one or more TLS records containing TLS 261 change_cipher_spec and finished handshake messages. The latter con- 262 tains the EAP server's authentication response to the peer. The peer 263 will then verify the hash in order to authenticate the EAP server. 265 If the EAP server authenticates unsuccessfully, 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 before terminating the conversa- 274 tion. The EAP Server MUST reply with an EAP-Failure packet since 275 server authentication failure is a terminal condition. 277 If the EAP server authenticates successfully, the peer sends an EAP- 278 Response packet of EAP-Type=EAP-TLS, and no data. The EAP-Server then 279 responds with an EAP-Success message. 281 4.2. Retry behavior 283 As with other EAP protocols, the EAP server is responsible for retry 284 behavior. This means that if the EAP server does not receive a reply 285 from the peer, it will resend the EAP-Request for which it has not yet 286 received an EAP-Response. However, the peer will not resend EAP- 287 Response packets without first being prompted by the EAP server. 289 For example, if the initial EAP-TLS start packet sent by the EAP 290 server were to be lost, then the peer would not receive this packet, 291 and would not respond to it. As a result, the EAP-TLS start packet 292 would be resent by the EAP server. Once the peer received the EAP-TLS 293 start packet, it would respond with an EAP-Response encapsulating the 294 client_hello message. If the EAP-Response were to be lost, then the 295 EAP server would resend the initial EAP-TLS start, and the peer would 296 resend the EAP-Response. 298 As a result, it is possible that a peer will receive duplicate EAP- 299 Request messages, and may send duplicate EAP-Responses. Both the peer 300 and the EAP-Server should be engineered to handle this possibility. 302 4.3. Identity verification 304 As part of the TLS negotiation, the server presents a certificate to 305 the peer, and if mutual authentication is requested, the peer presents 306 a certificate to the server. 308 Note that since the peer has made a claim of identity in the EAP- 309 Response/Identity (MyID) packet, the EAP server SHOULD verify that the 310 claimed identity corresponds to the certificate presented by the peer. 311 Typically this will be accomplished either by placing the userId 312 within the peer certificate, or by providing a mapping between the 313 peer certificate and the userId using a directory service. 315 Similarly, the peer MUST verify the validity of the EAP server cer- 316 tificate, and SHOULD also examine the EAP server name presented in the 317 certificate, in order to determine whether the EAP server can be 318 trusted. Please note that in the case where the EAP authentication is 319 remoted that the EAP server will not reside on the same machine as the 320 authenticator, and therefore the name in the EAP server's certificate 321 cannot be expected to match that of the intended destination. In this 322 case, a more appropriate test might be whether the EAP server's cer- 323 tificate is signed by a CA controlling the intended destination and 324 whether the EAP server exists within a target sub-domain. 326 4.4. Key derivation 328 Since the normal TLS keys are used in the handshake, and therefore 329 should not be used in a different context, new encryption keys must be 330 derived from the TLS master secret for use with PPP encryption. For 331 both peer and EAP server, the derivation proceeds as follows: given 332 the master secret negotiated by the TLS handshake, the pseudorandom 333 function (PRF) defined in the specification for the version of TLS in 334 use, and the value random defined as the concatenation of the hand- 335 shake message fields client_hello.random and server_hello.random (in 336 that order), the value PRF(master secret, "client EAP encryption", 337 random) is computed up to 128 bytes, and the value PRF("", "client EAP 338 encryption", random) is computed up to 64 bytes (where "" is an empty 339 string). The peer encryption key (the one used for encrypting data 340 from peer to EAP server) is obtained by truncating to the correct 341 length the first 32 bytes of the first PRF of these two output 342 strings. The EAP server encryption key (the one used for encrypting 343 data from EAP server to peer), if different from the client encryption 344 key, is obtained by truncating to the correct length the second 32 345 bytes of this same PRF output string. The client authentication key 346 (the one used for computing MACs for messages from peer to EAP 347 server), if used, is obtained by truncating to the correct length the 348 third 32 bytes of this same PRF output string. The EAP server authen- 349 tication key (the one used for computing MACs for messages from EAP 350 server to peer), if used, and if different from the peer authentica- 351 tion key, is obtained by truncating to the correct length the fourth 352 32 bytes of this same PRF output string. The peer initialization vec- 353 tor (IV), used for messages from peer to EAP server if a block cipher 354 has been specified, is obtained by truncating to the cipher's block 355 size the first 32 bytes of the second PRF output string mentioned 356 above. Finally, the server initialization vector (IV), used for mes- 357 sages from peer to EAP server if a block cipher has been specified, is 358 obtained by truncating to the cipher's block size the second 32 bytes 359 of this second PRF output. 361 The use of these encryption and authentication keys is specific to the 362 PPP encryption mechanism used, such as those defined in [10] and [11]. 363 Additional keys or other non-secret values (such as IVs) can be 364 obtained as needed for future PPP encryption methods by extending the 365 outputs of the PRF beyond 128 bytes and 64 bytes, respectively. 367 4.5. ECP negotiation 369 Since TLS supports ciphersuite negotiation, peers completing the TLS 370 negotiation will also have selected a ciphersuite, which includes key 371 strength, encryption and hashing methods. As a result, a subsequent 372 Encryption Control Protocol (ECP) conversation, if it occurs, has a 373 predetermined result. 375 In order to ensure agreement between the EAP-TLS ciphersuite negotia- 376 tion and the subsequent ECP negotiation (described in [7]), during ECP 377 negotiation the PPP peer MUST offer only the ciphersuite negotiated in 378 EAP-TLS. This ensures that the PPP authenticator MUST accept the EAP- 379 TLS negotiated ciphersuite in order for the conversation to proceed. 380 Should the authenticator not accept the EAP-TLS negotiated cipher- 381 suite, then the peer MUST send an LCP terminate and disconnect. 383 Please note that as described in [17], it cannot be assumed that the 384 PPP authenticator and EAP server are located on the same machine or 385 that the authenticator understands the EAP-TLS conversation that has 386 passed through it. Thus if the peer offers a ciphersuite other than 387 the one negotiated in EAP-TLS there is no way for the authenticator to 388 know how to respond correctly. 390 4.6. CCP negotiation 392 TLS as described in [15] supports compression as well as ciphersuite 393 negotiation. However, TLS only provides support for a limited number 394 of compression types which do not overlap with the compression types 395 used in PPP. As a result, during the EAP-TLS conversation the EAP end- 396 points MUST NOT request or negotiate compression. Instead, the PPP 397 Compression Control Protocol (CCP), described in [16] should be used 398 to negotiate the desired compression scheme. 400 4.7. Examples 402 In the case where the EAP-TLS mutual authentication is successful, the 403 conversation will appear as follows: 405 Authenticating Peer Authenticator 406 ------------------- ------------- 408 <- PPP LCP Request-EAP 409 auth 410 PPP LCP ACK-EAP 411 auth -> 412 <- PPP EAP-Request/ 413 Identity 414 PPP EAP-Response/ 415 Identity (MyID) -> 416 <- PPP EAP-Request/ 417 EAP-Type=EAP-TLS 418 (TLS Start) 420 PPP EAP-Response/ 421 EAP-Type=EAP-TLS 422 (TLS client_hello)-> 423 <- PPP EAP-Request/ 424 EAP-Type=EAP-TLS 425 (TLS server_hello, 426 TLS certificate, 427 [TLS server_key_exchange,] 428 [TLS certificate_request,] 429 TLS server_hello_done) 430 PPP EAP-Response/ 431 EAP-Type=EAP-TLS 432 (TLS certificate, 433 TLS client_key_exchange, 434 [TLS certificate_verify,] 435 TLS change_cipher_spec, 436 TLS finished) -> 437 <- PPP EAP-Request/ 438 EAP-Type=EAP-TLS 439 (TLS change_cipher_spec, 440 TLS finished) 441 PPP EAP-Response/ 442 EAP-Type=EAP-TLS -> 443 <- PPP EAP-Success 444 PPP Authentication 445 Phase complete, 446 NCP Phase starts 448 ECP negotiation 450 CCP negotiation 452 In the case where the server authenticates to the client successfully, 453 but the client fails to authenticate to the server, the conversation 454 will appear as follows: 456 Authenticating Peer Authenticator 457 ------------------- ------------- 458 <- PPP LCP Request-EAP 459 auth 460 PPP LCP ACK-EAP 461 auth -> 462 <- PPP EAP-Request/ 463 Identity 464 PPP EAP-Response/ 465 Identity (MyID) -> 466 <- PPP EAP-Request/ 467 EAP-Type=EAP-TLS 468 (TLS Start) 469 PPP EAP-Response/ 470 EAP-Type=EAP-TLS 471 (TLS client_hello)-> 472 <- PPP EAP-Request/ 473 EAP-Type=EAP-TLS 474 (TLS server_hello, 475 TLS certificate, 476 [TLS server_key_exchange,] 477 TLS certificate_request, 478 TLS server_hello_done) 479 PPP EAP-Response/ 480 EAP-Type=EAP-TLS 481 (TLS certificate, 482 TLS client_key_exchange, 483 TLS certificate_verify, 484 TLS change_cipher_spec, 485 TLS finished) -> 486 <- PPP EAP-Request 487 EAP-Type=EAP-TLS 488 (TLS Alert message) 489 PPP EAP-Response/ 490 EAP-Type=EAP-TLS -> 491 <- PPP EAP-Failure 492 (User Disconnected) 494 In the case where server authentication is unsuccessful, the conversa- 495 tion will appear as follows: 497 Authenticating Peer Authenticator 498 ------------------- ------------- 499 <- PPP LCP Request-EAP 500 auth 501 PPP LCP ACK-EAP 502 auth -> 503 <- PPP EAP-Request/ 504 Identity 505 PPP EAP-Response/ 506 Identity (MyID) -> 507 <- PPP EAP-Request/ 508 EAP-Type=EAP-TLS 509 (TLS Start) 510 PPP EAP-Response/ 511 EAP-Type=EAP-TLS 512 (TLS client_hello)-> 513 <- PPP EAP-Request/ 514 EAP-Type=EAP-TLS 515 (TLS server_hello, 516 TLS certificate, 517 [TLS server_key_exchange,] 518 [TLS certificate_request,] 519 TLS server_hello_done) 520 PPP EAP-Response/ 521 EAP-Type=EAP-TLS 522 (TLS certificate, 523 TLS client_key_exchange, 524 [TLS certificate_verify,] 525 TLS change_cipher_spec, 526 TLS finished) -> 527 <- PPP EAP-Request/ 528 EAP-Type=EAP-TLS 529 (TLS change_cipher_spec, 530 TLS finished) 531 PPP EAP-Response/ 532 EAP-Type=EAP-TLS 533 (TLS Alert message) -> 534 <- PPP EAP-Failure 535 (User Disconnected) 537 In the case where a previously established session is being resumed, 538 and both sides authenticate successfully, the conversation will appear 539 as follows: 541 Authenticating Peer Authenticator 542 ------------------- ------------- 543 <- PPP LCP Request-EAP 544 auth 545 PPP LCP ACK-EAP 546 auth -> 547 <- PPP EAP-Request/ 548 Identity 549 PPP EAP-Response/ 550 Identity (MyID) -> 551 <- PPP EAP-Request/ 552 EAP-Request/ 553 EAP-Type=EAP-TLS 554 (TLS Start) 555 PPP EAP-Response/ 556 EAP-Type=EAP-TLS 557 (TLS client_hello)-> 558 <- PPP EAP-Request/ 559 EAP-Type=EAP-TLS 560 (TLS server_hello, 561 TLS change_cipher_spec, 562 TLS finished) 563 PPP EAP-Response/ 564 EAP-Type=EAP-TLS 565 (TLS change_cipher_spec, 566 TLS finished) -> 567 <- PPP EAP-Success 568 PPP Authentication 569 Phase complete, 570 NCP Phase starts 572 ECP negotiation 574 CCP negotiation 576 In the case where a previously established session is being resumed, 577 and the server authenticates to the client successfully but the client 578 fails to authenticate to the server, the conversation will appear as 579 follows: 581 Authenticating Peer Authenticator 582 ------------------- ------------- 583 <- PPP LCP Request-EAP 584 auth 585 PPP LCP ACK-EAP 586 auth -> 587 <- PPP EAP-Request/ 588 Identity 589 PPP EAP-Response/ 590 Identity (MyID) -> 591 <- PPP EAP-Request/ 592 EAP-Request/ 593 EAP-Type=EAP-TLS 594 (TLS Start) 595 PPP EAP-Response/ 596 EAP-Type=EAP-TLS 597 (TLS client_hello) -> 598 <- PPP EAP-Request/ 599 EAP-Type=EAP-TLS 600 (TLS server_hello, 601 TLS change_cipher_spec, 602 TLS finished) 603 PPP EAP-Response/ 604 EAP-Type=EAP-TLS 605 (TLS change_cipher_spec, 606 TLS finished) -> 607 <- PPP EAP-Request 608 EAP-Type=EAP-TLS 609 (TLS Alert message) 610 PPP EAP-Response 611 EAP-Type=EAP-TLS -> 612 <- PPP EAP-Failure 613 (User Disconnected) 615 In the case where a previously established session is being resumed, 616 and the server authentication is unsuccessful, the conversation will 617 appear as follows: 619 Authenticating Peer Authenticator 620 ------------------- ------------- 621 <- PPP LCP Request-EAP 622 auth 623 PPP LCP ACK-EAP 624 auth -> 625 <- PPP EAP-Request/ 626 Identity 627 PPP EAP-Response/ 628 Identity (MyID) -> 629 <- PPP EAP-Request/ 630 EAP-Request/ 631 EAP-Type=EAP-TLS 632 (TLS Start) 633 PPP EAP-Response/ 634 EAP-Type=EAP-TLS 635 (TLS client_hello)-> 636 <- PPP EAP-Request/ 637 EAP-Type=EAP-TLS 638 (TLS server_hello, 639 TLS change_cipher_spec, 640 TLS finished) 641 PPP EAP-Response/ 642 EAP-Type=EAP-TLS 643 (TLS Alert message) -> 644 <- PPP EAP-Failure 645 (User Disconnected) 647 5. Detailed description of the EAP-TLS protocol 649 5.1. PPP EAP TLS Packet Format 651 A summary of the PPP EAP TLS Request/Response packet format is shown 652 below. The fields are transmitted from left to right. 654 0 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Code | Identifier | Length | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Type | Data ... 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 662 Code 664 1 - Request 665 2 - Response 667 Identifier 669 The identifier field is one octet and aids in matching responses 670 with requests. 672 Length 674 The Length field is two octets and indicates the length of the EAP 675 packet including the Code, Identifier, Length, Type, and Data 676 fields. Octets outside the range of the Length field should be 677 treated as Data Link Layer padding and should be ignored on recep- 678 tion. 680 Type 682 ? - EAP TLS 684 Data 686 The format of the Data field is determined by the Code field. 688 5.2. PPP EAP TLS Request Packet 690 A summary of the PPP EAP TLS Request packet format is shown below. 691 The fields are transmitted from left to right. 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Code | Identifier | Length | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Type | TLS data... 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 Code 703 1 705 Identifier 707 The identifier field is one octet and aids in matching responses 708 with requests. The identifier field MUST be changed on each 709 Request packet. 711 Length 713 The Length field is two octets and indicates the length of the EAP 714 packet including the Code, Identifier, Length, Type, and TLS 715 Response fields. 717 Type 719 ? - EAP TLS 721 TLS data 723 The TLS data consists of the encapsulated TLS packet in TLS record 724 format. 726 5.3. PPP EAP TLS Response Packet 728 A summary of the PPP EAP TLS Response packet format is shown below. 729 The fields are transmitted from left to right. 731 0 1 2 3 732 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 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Code | Identifier | Length | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Type | TLS Data... 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 Code 740 2 742 Identifier 744 The identifier field is one octet and MUST match the Identifier 745 field from the corresponding request. 747 Length 749 The Length field is two octets and indicates the length of the EAP 750 packet including the Code, Identifier, Length, Type, and TLS data 751 fields. 753 Type 755 ? - EAP TLS 757 TLS data 759 The TLS data consists of the encapsulated TLS packet in TLS record 760 format. 762 6. Security issues 764 6.1. Certificate revocation 766 Since the EAP server is on the Internet during the EAP conversation, 767 the EAP server is capable of following a certificate chain or verify- 768 ing whether the peer's certificate has been revoked. In contrast, the 769 peer may or may not have Internet connectivity, and thus while it can 770 validate the EAP server's certificate based on a pre-configured set of 771 CAs, it may not be able to follow a certificate chain or verify 772 whether the EAP server's certificate has been revoked. 774 In the case where the peer is initiating a voluntary Layer 2 tunnel 775 using PPTP or L2TP, the peer will typically already have a PPP inter- 776 face and Internet connectivity established at the time of tunnel ini- 777 tiation. As a result, during the EAP conversation it is capable of 778 checking for certificate revocation. 780 However, in the case where the peer is initiating an intial PPP con- 781 versation, it will not have Internet connectivity and is therefore not 782 capable of checking for certificate revocation until after NCP negoti- 783 ation completes and the peer has access to the Internet. In this case, 784 the peer SHOULD check for certificate revocation after connecting to 785 the Internet. 787 6.2. Separation of the EAP server and PPP authenticator 789 As a result of the EAP-TLS conversation, the EAP endpoints will mutu- 790 ally authenticate, negotiate a ciphersuite, and derive a session key 791 for subsequent use in PPP encryption. Since the peer and EAP client 792 reside on the same machine, it is necessary for the EAP client module 793 to pass the session key to the PPP encryption module. 795 The situation may be more complex on the PPP authenticator. As noted 796 in [17], the PPP authenticator may or may not reside on the same 797 machine as the EAP server. For example, when RADIUS/EAP is used, the 798 EAP server may be a backend security server, or a module residing on 799 the RADIUS server. 801 In the case where the EAP server and PPP authenticator reside on dif- 802 ferent machines, there are several implications for security. Firstly, 803 the mutual authentication defined in EAP-TLS will occur between the 804 peer and the EAP server, not between the peer and the authenticator. 805 This means that as a result of the EAP-TLS conversation, it is not 806 possible for the peer to validate the identity of the NAS or tunnel 807 server that it is speaking to. 809 As described in [17], when EAP/RADIUS is used to encapsulate EAP pack- 810 ets, the Signature attribute is required in EAP/RADIUS Access-Requests 811 sent from the NAS or tunnel server to the RADIUS server. Since the 812 Signature attribute involves a keyed-MD5 hash, it is possible for the 813 RADIUS server to verify the integrity of the Access-Request as well as 814 the NAS or tunnel server's identity. Similarly, Access-Challenge pack- 815 ets sent from the RADIUS server to the NAS are also authenticated and 816 integrity protected using a keyed-MD5 hash, enabling the NAS or tunnel 817 server to determine the integrity of the packet and verify the iden- 818 tity of the RADIUS server. Moreover, EAP-TLS packets in transit are 819 integrity protected and authenticated end-to-end via TLS mechanisms, 820 so that they cannot be successfully modified by a rogue NAS or tunnel 821 server. 823 The second issue that arises in the case of an EAP server and PPP 824 authenticator residing on different machines is that the session key 825 negotiated between the peer and EAP server will need to be transmitted 826 to the authenticator. Therefore a mechanism needs to be provided to 827 transmit the session key from the EAP server to the authenticator or 828 tunnel server that needs to use the key. The specification of this 829 transit mechanism is outside the scope of this document. 831 6.3. Relationship of PPP encryption to other security mechanisms 833 PPP encryption currently plays an important role in the securing of 834 Layer 2 tunneling protocols such as PPTP, described in [13], and L2TP, 835 described in [14]. While it may be envisaged that security mechanisms 836 such as IPSEC will eventually become ubiquitous, it will take some 837 time for vendors to add IPSEC capabilities to their devices, and in 838 any case legacy authenticator devices or routers may not be able to 839 support IPSEC without being upgraded. As a result, it is likely that 840 non-IPSEC capable devices will persist in operational networks for 841 quite some time. 843 In an environment where IPSEC is not ubiquitous, in Layer 2 tunneling 844 protocols a role remains for PPP encryption. Since with mandatory tun- 845 neling a PPP peer cannot tell whether its packets are being tunneled, 846 let alone whether the authenticator is securing the tunnel, if secu- 847 rity is required then the client must make its own arrangements. In 848 the case where all endpoints cannot be relied upon to implement IPSEC, 849 TLS, or another suitable security protocol, then PPP encryption pro- 850 vides a very convenient means to ensure the privacy of packets tran- 851 siting between the client and the tunnel server. 853 There also may be circumstances in which PPP encryption may be desir- 854 able even if IPSEC is available. Routers implementing Network Address 855 Translation (NAT) are now growing rapidly in popularity. Where NAT is 856 turned on, IPSEC cannot be used to secure the outer layer of a client- 857 initiated layer 2 tunnel, since the address translated packet will 858 then fail the authentication check. By contrast, Layer 2 tunnels uti- 859 lizing PPP encryption may pass unimpeded through a NAT. 861 7. Copyright notice 863 Copyright (C) The Internet Society, 1997. All Rights Reserved. 865 This document and translations of it may be copied and furnished to 866 others, and derivative works that comment on or otherwise explain it 867 or assist in its implmentation may be prepared, copied, published and 868 distributed, in whole or in part, without restriction of any kind, 869 provided that the above copyright notice and this paragraph are 870 included on all such copies and derivative works. However, this docu- 871 ment itself may not be modified in any way, such as by removing the 872 copyright notice or references to the Internet Society or other Inter- 873 net organizations, except as needed for the purpose of developing 874 Internet standards in which case the procedures for copyrights defined 875 in the Internet Standards process must be followed, or as required to 876 translate it into languages other than English. 878 The limited permissions granted above are perpetual and will not be 879 revoked by the Internet Society or its successors or assigns. 881 This document and the information contained herein is provided on an 882 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 883 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 884 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 885 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 886 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 888 8. Acknowledgments 890 Thanks to Terence Spies, Glen Zorn and Narendra Gidwani of Microsoft 891 for useful discussions of this problem space. 893 9. References 895 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)." STD 51, 896 RFC 1661, Daydreamer, July 1994. 898 [2] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, 899 "The PPP Multilink Protocol (MP)." RFC 1990, UC Berkeley, August 1996. 901 [3] Simpson, W., Editor, "PPP LCP Extensions." RFC 1570, Daydreamer, 902 January 1994. 904 [4] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm." RFC 905 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., 906 April 1992. 908 [5] L. J. Blunk, J. R. Vollbrecht. "PPP Extensible Authentication 909 Protocol (EAP)." Work in progress, draft-ietf-pppext-eap-auth-02.txt, 910 Merit Network, Inc., June 1996. 912 [6] W. T. Whelan, "PPP EAP RSA Public Key Authentication Protocol." 913 Work in progress, draft-ietf-pppext-eaprsa-04.txt, Cabletron Systems, 914 February 1997. 916 [7] Meyer, G., "The PPP Encryption Protocol (ECP)." RFC 1968, Spider 917 Systems. June 1996 919 [8] National Bureau of Standards, "Data Encryption Standard." FIPS PUB 920 46 (January 1977). 922 [9] National Bureau of Standards, "DES Modes of Operation." FIPS PUB 923 81 (December 1980). 925 [10] K. Sklower, G. Meyer. "The PPP DES Encryption Protocol, Version 926 2 (DESE-bis)" Work in progress, draft-ietf-pppext-des-encrypt- 927 v2-00.txt, University of California, Berkeley, Shiva, July 1997. 929 [11] K. Hummert. "The PPP Triple-DES Encryption Protocol (3DESE)" 930 Work in progress, draft-ietf-pppext-3des-encrypt-00.txt, Nentec GmbH, 931 July 1997. 933 [12] S. Bradner. "Key words for use in RFCs to Indicate Requirement 934 Levels." RFC 2119, Harvard University, March 1997. 936 [13] K. Hamzeh, G. S. Pall, J. Taarud, W. Verthein, W. A. Little. 937 "Point-to-Point Tunneling Protocol -- PPTP." Internet draft (work in 938 progress), draft-ietf-pppext-pptp-02.txt, Ascend Communications, 939 Microsoft, Copper Mountain Networks, U.S. Robotics, July 1997. 941 [14] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, B. Palter, J. 942 Taarud, W. M. Townsley, A. Valencia, W. Verthein. "Layer Two Tunnel- 943 ing Protocol L2TP." Internet draft (work in progress) draft-ietf- 944 pppext-l2tp-06.txt, Ascend Communications, Cisco Systems, Microsoft, 945 Copper Mountain Networks, IBM, U.S. Robotics, August 1997. 947 [15] T. Dierks, C. Allen. "The TLS Protocol Version 1.0." Internet 948 draft (work in progress) draft-ietf-tls-protocol-03.txt, Consensus 949 Development, May 1997. 951 [16] D. Rand. "The PPP Compression Control Protocol." RFC 1962, Nov- 952 ell, June 1996. 954 [17] P. Calhoun, A.C. Rubens, B. Aboba. "Extensible Authentication 955 Protocol Support in RADIUS." Internet draft (work in progress), draft- 956 ietf-radius-eap-02.txt, US Robotics Access Corp., Merit Network, 957 Microsoft, May, 1997. 959 10. Authors' Addresses 961 Bernard Aboba 962 Microsoft Corporation 963 One Microsoft Way 964 Redmond, WA 98052 966 Phone: 425-936-6605 967 EMail: bernarda@microsoft.com 969 Dan Simon 970 Microsoft Corporation 971 One Microsoft Way 972 Redmond, WA 98052 974 Phone: 425-936-6711 975 EMail: dansimon@microsoft.com