idnits 2.17.1 draft-ietf-pppext-eaptls-04.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 20 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 244 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 404 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...), its areas...' == Line 13 has weird spacing: '... its worki...' == Line 17 has weird spacing: '... and may ...' == Line 18 has weird spacing: '...afts as refer...' == Line 21 has weird spacing: '... To learn...' == (239 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 (9 October 1998) is 9330 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 922, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 928, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 930, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 939, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 942, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2284 (ref. '5') (Obsoleted by RFC 3748) == Outdated reference: A later version (-06) exists of draft-ietf-tls-protocol-05 Summary: 13 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPPEXT Working Group Bernard Aboba 2 INTERNET-DRAFT Microsoft 3 Category: Informational Dan Simon 4 Microsoft 5 9 October 1998 7 PPP EAP TLS Authentication Protocol 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.ietf.org (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 The distribution of this memo is unlimited. It is filed as , and expires May 1, 1999. Please send com- 28 ments to the authors. 30 2. Abstract 32 The Point-to-Point Protocol (PPP) provides a standard method for 33 transporting multi-protocol datagrams over point-to-point links. PPP 34 also defines an extensible Link Control Protocol (LCP), which can be 35 used to negotiate authentication methods, as well as an Encryption 36 Control Protocol (ECP), used to negotiate data encryption over PPP 37 links, and a Compression Control Protocol (CCP), used to negotiate 38 compression methods. The Extensible Authentication Protocol (EAP) is 39 a PPP extension that provides support for additional authentication 40 methods within PPP. 42 Transport Level Security (TLS) provides for mutual authentication, 43 integrity-protected ciphersuite negotiation and key exchange between 44 two endpoints. This document describes how EAP-TLS, which includes 45 support for fragmentation and reassembly, provides for these TLS mech- 46 anisms within EAP. 48 3. Introduction 50 The Extensible Authentication Protocol (EAP), described in [5], pro- 51 vides a standard mechanism for support of additional authentication 52 methods within PPP. Through the use of EAP, support for a number of 53 authentication schemes may be added, including smart cards, Kerberos, 54 Public Key, One Time Passwords, and others. To date however, EAP meth- 55 ods such as [6] have focussed on authenticating a client to a server. 57 However, it may be desirable to support mutual authentication, and 58 since PPP encryption protocols such as [9] and [10] assume existence 59 of a session key, it is useful to have a mechanism for session key 60 establishment. Since design of secure key management protocols is non- 61 trivial, 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 protected ciphersuite negotiation, mutual authentica- 64 tion and key management capabilities of the TLS protocol, described in 65 [12]. 67 3.1. Requirements language 69 In this document, the key words "MAY", "MUST, "MUST NOT", 70 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 71 interpreted as described in [11]. 73 4. Protocol overview 75 4.1. Overview of the EAP-TLS conversation 77 As described in [5], the EAP-TLS conversation will typically begin 78 with the authenticator and the peer negotiating EAP. The authentica- 79 tor will then typically send an EAP-Request/Identity packet to the 80 peer, and the peer will respond with an EAP-Response/Identity packet 81 to the authenticator, containing the peer's userId. 83 From this point forward, while nominally the EAP conversation occurs 84 between the PPP authenticator and the peer, the authenticator MAY act 85 as a passthrough device, with the EAP packets received from the peer 86 being encapsulated for transmission to a RADIUS server or backend 87 security server. In the discussion that follows, we will use the term 88 "EAP server" to denote the ultimate endpoint conversing with the peer. 90 Once having received the peer's Identity, the EAP server MUST respond 91 with an EAP-TLS/Start packet, which is an EAP-Request packet with EAP- 92 Type=EAP-TLS, the Start (S) bit set, and no data. The EAP-TLS conver- 93 sation will then begin, with the peer sending an EAP-Response packet 94 with EAP-Type=EAP-TLS. The data field of that packet will encapsulate 95 one or more TLS records in TLS record layer format, containing a TLS 96 client_hello handshake message. The current cipher spec for the TLS 97 records will be TLS_NULL_WITH_NULL_NULL and null compression. This 98 current cipher spec remains the same until the change_cipher_spec mes- 99 sage signals that subsequent records will have the negotiated 100 attributes for the remainder of the handshake. 102 The client_hello message contains the client's TLS version number, a 103 sessionId, a random number, and a set of ciphersuites supported by the 104 client. The version offered by the client MUST correspond to TLS v1.0 105 or later. 107 The EAP server will then respond with an EAP-Request packet with EAP- 108 Type=EAP-TLS. The data field of this packet will encapsulate one or 109 more TLS records. These will contain a TLS server_hello handshake mes- 110 sage, possibly followed by TLS certificate, server_key_exchange, cer- 111 tificate_request, server_hello_done and/or finished handshake mes- 112 sages, and/or a TLS change_cipher_spec message. The server_hello 113 handshake message contains a TLS version number, another random num- 114 ber, a sessionId, and a ciphersuite. The version offered by the 115 server MUST correspond to TLS v1.0 or later. 117 If the client's sessionId is null or unrecognized by the server, the 118 server MUST choose the sessionId to establish a new session; other- 119 wise, the sessionId will match that offered by the client, indi- 120 cating a resumption of the previously established session with that 121 sessionID. The server will also choose a ciphersuite from those 122 offered by the client; if the session matches the client's, then the 123 ciphersuite MUST match the one negotiated during the handshake proto- 124 col execution that established the session. 126 The purpose of the sessionId within the TLS protocol is to allow for 127 improved efficiency in the case where a client repeatedly attempts to 128 authenticate to an EAP server within a short period of time. While 129 this model was developed for use with HTTP authentication, it may also 130 have application to PPP authentication (e.g. multilink). 132 As a result, it is left up to the peer whether to attempt to continue 133 a previous session, thus shortening the TLS conversation. Typically 134 the peer's decision will be made based on the time elapsed since the 135 previous authentication attempt to that EAP server. Based on the ses- 136 sionId chosen by the peer, and the time elapsed since the previous 137 authentication, the EAP server will decide whether to allow the con- 138 tinuation, or whether to choose a new session. 140 In the case where the EAP server and authenticator reside on the same 141 device, then client will only be able to continue sessions when con- 142 necting to the same NAS or tunnel server. Should these devices be set 143 up in a rotary or round-robin then it may not be possible for the peer 144 to know in advance the authenticator it will be connecting to, and 145 therefore which sessionId to attempt to reuse. As a result, it is 146 likely that the continuation attempt will fail. In the case where the 147 EAP authentication is remoted then continuation is much more likely to 148 be successful, since multiple NAS devices and tunnel servers will 149 remote their EAP authentications to the same RADIUS server. 151 If the EAP server is resuming a previously established session, then 152 it MUST include only a TLS change_cipher_spec message and a TLS fin- 153 ished handshake message after the server_hello message. The finished 154 message contains the EAP server's authentication response to the peer. 155 If the EAP server is not resuming a previously established session, 156 then it MUST include a TLS server_certificate handshake message, and a 157 server_hello_done handshake message MUST be the last handshake message 158 encapsulated in this EAP-Request packet. 160 The certificate message contains a public key certificate chain for 161 either a key exchange public key (such as an RSA or Diffie-Hellman key 162 exchange public key) or a signature public key (such as an RSA or DSS 163 signature public key). In the latter case, a TLS server_key_exchange 164 handshake message MUST also be included to allow the key exchange to 165 take place. 167 The certificate_request message is included when the server desires 168 the client to authenticate itself via public key. While the EAP server 169 SHOULD require client authentication, this is not a requirement, since 170 it may be possible that the server will require that the peer authen- 171 ticate via some other means. 173 The peer MUST respond to the EAP-Request with an EAP-Response packet 174 of EAP-Type=EAP-TLS. The data field of this packet will encapsulate 175 one or more TLS records containing a TLS change_cipher_spec message 176 and finished handshake message, and possibly certificate, certifi- 177 cate_verify and/or client_key_exchange handshake messages. If the 178 preceding server_hello message sent by the EAP server in the preceding 179 EAP-Request packet indicated the resumption of a previous session, 180 then the peer MUST send only the change_cipher_spec and finished hand- 181 shake messages. The finished message contains the peer's authentica- 182 tion response to the EAP server. 184 If the preceding server_hello message sent by the EAP server in the 185 preceeding EAP-Request packet did not indicate the resumption of a 186 previous session, then the peer MUST send, in addition to the 187 change_cipher_spec and finished messages, a client_key_exchange mes- 188 sage, which completes the exchange of a shared master secret between 189 the peer and the EAP server. If the EAP server sent a certifi- 190 cate_request message in the preceding EAP-Request packet, then the 191 peer MUST send, in addition, certificate and certificate_verify hand- 192 shake messages. The former contains a certificate for the peer's sig- 193 nature public key, while the latter contains the peer's signed authen- 194 tication response to the EAP server. After receiving this packet, the 195 EAP server will verify the peer's certificate and digital signature, 196 if requested. 198 If the peer's authentication is unsuccessful, the EAP server SHOULD 199 send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS 200 record containing the appropriate TLS alert message. The EAP server 201 SHOULD send a TLS alert message rather immediately terminating the 202 conversation so as to allow the peer to inform the user of the cause 203 of the failure and possibly allow for a restart of the conversation. 205 To ensure that the peer receives the TLS alert message, the EAP server 206 MUST wait for the peer to reply with an EAP-Response packet. The EAP- 207 Response packet sent by the peer MAY encapsulate a TLS client_hello 208 handshake message, in which case the EAP server MAY allow the EAP-TLS 209 conversation to be restarted, or it MAY contain an EAP-Response packet 210 with EAP-Type=EAP-TLS and no data, in which case the EAP-Server MUST 211 send an EAP-Failure packet, and terminate the conversation. It is up 212 to the EAP server whether to allow restarts, and if so, how many times 213 the conversation can be restarted. An EAP Server implementing restart 214 capability SHOULD impose a limit on the number of restarts, so as to 215 protect against denial of service attacks. 217 If the peers authenticates successfully, the EAP server MUST respond 218 with an EAP-Request packet with EAP-Type=EAP-TLS, which includes, in 219 the case of a new TLS session, one or more TLS records containing TLS 220 change_cipher_spec and finished handshke messages. The latter con- 221 tains the EAP server's authentication response to the peer. The peer 222 will then verify the hash in order to authenticate the EAP server. 224 If the EAP server authenticates unsuccessfully, the peer MAY send an 225 EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert message 226 identifying the reason for the failed authentication. The peer MAY 227 send a TLS alert message rather than immediately terminating the con- 228 versation so as to allow the EAP server to log the cause of the error 229 for examination by the system administrator. 231 To ensure that the EAP Server receives the TLS alert message, the peer 232 MUST wait for the EAP-Server to reply before terminating the conversa- 233 tion. The EAP Server MUST reply with an EAP-Failure packet since 234 server authentication failure is a terminal condition. 236 If the EAP server authenticates successfully, the peer MUST send an 237 EAP-Response packet of EAP-Type=EAP-TLS, and no data. The EAP-Server 238 then MUST respond with an EAP-Success message. 240 4.2. Retry behavior 242 As with other EAP protocols, the EAP server is responsible for retry 243 behavior. This means that if the EAP server does not receive a reply 244 from the peer, it MUST resend the EAP-Request for which it has not yet 245 received an EAP-Response. However, the peer MUST NOT resend EAP- 246 Response packets without first being prompted by the EAP server. 248 For example, if the initial EAP-TLS start packet sent by the EAP 249 server were to be lost, then the peer would not receive this packet, 250 and would not respond to it. As a result, the EAP-TLS start packet 251 would be resent by the EAP server. Once the peer received the EAP-TLS 252 start packet, it would send an EAP-Response encapsulating the 253 client_hello message. If the EAP-Response were to be lost, then the 254 EAP server would resend the initial EAP-TLS start, and the peer would 255 resend the EAP-Response. 257 As a result, it is possible that a peer will receive duplicate EAP- 258 Request messages, and may send duplicate EAP-Responses. Both the peer 259 and the EAP-Server should be engineered to handle this possibility. 261 4.3. Fragmentation 263 A single TLS record may be up to 16384 octets in length, but a TLS 264 message may span multiple TLS records, and a TLS certificate message 265 may in principle be as long as 16MB. The group of EAP-TLS messages 266 sent in a single round may thus be larger than the PPP MTU size, the 267 maximum RADIUS packet size of 4096 octets, or even the Multilink Maxi- 268 mum Received Reconstructed Unit (MRRU). As described in [2], the mul- 269 tilink MRRU is negotiated via the Multilink MRRU LCP option, which 270 includes an MRRU length field of two octets, and thus can support 271 MRRUs as large as 64 KB. 273 However, note that in order to protect against reassembly lockup and 274 denial of service attacks, it may be desirable for an implementation 275 to set a maximum size for one such group of TLS messages. Since a typ- 276 ical certificate chain is rarely longer than a few thousand octets, 277 and no other field is likely to be anwhere near as long, a reasonable 278 choice of maximum acceptable message length might be 64 KB. 280 If this value is chosen, then fragmentation can be handled via the 281 multilink PPP fragmentation mechanisms described in [2]. While this is 282 desirable, there may be cases in which multilink or the MRRU LCP 283 option cannot be negotiated. As a result, an EAP-TLS implementation 284 MUST provide its own support for fragmentation and reassembly. 286 Since EAP is a simple ACK-NAK protocol, fragmentation support can be 287 added in a simple manner. In EAP, fragments that are lost or damaged 288 in transit will be retransmitted, and since sequencing information is 289 provided by the Identifier field in EAP, there is no need for a frag- 290 ment offset field as is provided in IPv4. 292 EAP-TLS fragmentation support is provided through addition of a flags 293 octet within the EAP-Response and EAP-Request packets, as well as a 294 TLS Message Length field of four octets. Flags include the Length 295 included (L), More fragments (M), and EAP-TLS Start (S) bits. The L 296 flag is set to indicate the presence of the four octet TLS Message 297 Length field, and MUST be set for the first fragment of a fragmented 298 TLS message or set of messages. The M flag is set on all but the last 299 fragment. The S flag is set only within the EAP-TLS start message sent 300 from the EAP server to the peer. The TLS Message Length field is four 301 octets, and provides the total length of the TLS message or set of 302 messages that is being fragmented; this simplifies buffer allocation. 304 When an EAP-TLS peer receives an EAP-Request packet with the M bit 305 set, it MUST respond with an EAP-Response with EAP-Type=EAP-TLS and no 306 data. This serves as a fragment ACK. The EAP server MUST wait until 307 it receives the EAP-Response before sending another fragment. In order 308 to prevent errors in processing of fragments, the EAP server MUST 309 increment the Identifier field for each fragment contained within an 310 EAP-Request, and the peer MUST include this Identifier value in the 311 fragment ACK contained within the EAP-Reponse. Retransmitted fragments 312 will contain the same Identifier value. 314 Similarly, when the EAP server receives an EAP-Response with the M bit 315 set, it MUST respond with an EAP-Request with EAP-Type=EAP-TLS and no 316 data. This serves as a fragment ACK. The EAP peer MUST wait until it 317 receives the EAP-Request before sending another fragment. In order to 318 prevent errors in the processing of fragments, the EAP server MUST use 319 increment the Identifier value for each fragment ACK contained within 320 an EAP-Request, and the peer MUST include this Identifier value in the 321 subsequent fragment contained within an EAP-Reponse. 323 4.4. Identity verification 325 As part of the TLS negotiation, the server presents a certificate to 326 the peer, and if mutual authentication is requested, the peer presents 327 a certificate to the server. 329 Note that since the peer has made a claim of identity in the EAP- 330 Response/Identity (MyID) packet, the EAP server SHOULD verify that the 331 claimed identity corresponds to the certificate presented by the peer. 332 Typically this will be accomplished either by placing the userId 333 within the peer certificate, or by providing a mapping between the 334 peer certificate and the userId using a directory service. 336 Similarly, the peer MUST verify the validity of the EAP server cer- 337 tificate, and SHOULD also examine the EAP server name presented in the 338 certificate, in order to determine whether the EAP server can be 339 trusted. Please note that in the case where the EAP authentication is 340 remoted that the EAP server will not reside on the same machine as the 341 authenticator, and therefore the name in the EAP server's certificate 342 cannot be expected to match that of the intended destination. In this 343 case, a more appropriate test might be whether the EAP server's cer- 344 tificate is signed by a CA controlling the intended destination and 345 whether the EAP server exists within a target sub-domain. 347 4.5. Key derivation 349 Since the normal TLS keys are used in the handshake, and therefore 350 should not be used in a different context, new encryption keys must be 351 derived from the TLS master secret for use with PPP encryption. For 352 both peer and EAP server, the derivation proceeds as follows: given 353 the master secret negotiated by the TLS handshake, the pseudorandom 354 function (PRF) defined in the specification for the version of TLS in 355 use, and the value random defined as the concatenation of the hand- 356 shake message fields client_hello.random and server_hello.random (in 357 that order), the value PRF(master secret, "client EAP encryption", 358 random) is computed up to 128 bytes, and the value PRF("", "client EAP 359 encryption", random) is computed up to 64 bytes (where "" is an empty 360 string). The peer encryption key (the one used for encrypting data 361 from peer to EAP server) is obtained by truncating to the correct 362 length the first 32 bytes of the first PRF of these two output 363 strings. TheEAP server encryption key (the one used for encrypting 364 data from EAP server to peer), if different from the client encryption 365 key, is obtained by truncating to the correct length the second 32 366 bytes of this same PRF output string. The client authentication key 367 (the one used for computing MACs for messages from peer to EAP 368 server), if used, is obtained by truncating to the correct length the 369 third 32 bytes of this same PRF output string. The EAP server authen- 370 tication key (the one used for computing MACs for messages from EAP 371 server to peer), if used, and if different from the peer authentica- 372 tion key, is obtained by truncating to the correct length the fourth 373 32 bytes of this same PRF output string. The peer initialization vec- 374 tor (IV), used for messages from peer to EAP server if a block cipher 375 has been specified, is obtained by truncating to the cipher's block 376 size the first 32 bytes of the second PRF output string mentioned 377 above. Finally, the server initialization vector (IV), used for mes- 378 sages from peer to EAP server if a block cipher has been specified, is 379 obtained by truncating to the cipher's block size the second 32 bytes 380 of this second PRF output. 382 The use of these encryption and authentication keys is specific to the 383 PPP encryption mechanism used, such as those defined in [9] and [10]. 384 Additional keys or other non-secret values (such as IVs) can be 385 obtained as needed for future PPP encryption methods by extending the 386 outputs of the PRF beyond 128 bytes and 64 bytes, respectively. 388 4.6. ECP negotiation 390 Since TLS supports ciphersuite negotiation, peers completing the TLS 391 negotiation will also have selected a ciphersuite, which includes key 392 strength, encryption and hashing methods. As a result, a subsequent 393 Encryption Control Protocol (ECP) conversation, if it occurs, has a 394 predetermined result. 396 In order to ensure agreement between the EAP-TLS ciphersuite negotia- 397 tion and the subsequent ECP negotiation (described in [6]), during ECP 398 negotiation the PPP peer MUST offer only the ciphersuite negotiated in 399 EAP-TLS. This ensures that the PPP authenticator MUST accept the EAP- 400 TLS negotiated ciphersuite in order for the onversation to proceed. 401 Should the authenticator not accept the EAP-TLS negotiated cipher- 402 suite, then the peer MUST send an LCP terminate and disconnect. 404 Please note that it cannot be assumed that the PPP authenticator and 405 EAP server are located on the same machine or that the authenticator 406 understands the EAP-TLS conversation that has passed through it. Thus 407 if the peer offers a ciphersuite other than the one negotiated in EAP- 408 TLS there is no way for the authenticator to know how to respond cor- 409 rectly. 411 4.7. CCP negotiation 413 TLS as described in [12] supports compression as well as ciphersuite 414 negotiation. However, TLS only provides support for a limited number 415 of compression types which do not overlap with the compression types 416 used in PPP. As a result, during the EAP-TLS conversation the EAP end- 417 points MUST NOT request or negotiate compression. Instead, the PPP 418 Compression Control Protocol (CCP), described in [13] should be used 419 to negotiate the desired compression scheme. 421 4.8. Examples 423 In the case where the EAP-TLS mutual authentication is successful, the 424 conversation will appear as follows: 426 Authenticating Peer Authenticator 427 ------------------- ------------- 428 <- PPP LCP Request-EAP 429 auth 430 PPP LCP ACK-EAP 431 auth -> 432 <- PPP EAP-Request/ 433 Identity 434 PPP EAP-Response/ 435 Identity (MyID) -> 436 <- PPP EAP-Request/ 437 EAP-Type=EAP-TLS 438 (TLS Start) 439 PPP EAP-Response/ 440 EAP-Type=EAP-TLS 441 (TLS client_hello)-> 442 <- PPP EAP-Request/ 443 EAP-Type=EAP-TLS 444 (TLS server_hello, 445 TLS certificate, 446 [TLS server_key_exchange,] 447 [TLS certificate_request,] 448 TLS server_hello_done) 449 PPP EAP-Response/ 450 EAP-Type=EAP-TLS 451 (TLS certificate, 452 TLS client_key_exchange, 453 [TLS certificate_verify,] 454 TLS change_cipher_spec, 455 TLS finished) -> 456 <- PPP EAP-Request/ 457 EAP-Type=EAP-TLS 458 (TLS change_cipher_spec, 459 TLS finished) 460 PPP EAP-Response/ 461 EAP-Type=EAP-TLS -> 462 <- PPP EAP-Success 463 PPP Authentication 464 Phase complete, 465 NCP Phase starts 467 ECP negotiation 469 CCP negotiation 471 In the case where the EAP-TLS mutual authentication is successful, and 472 fragmentation is required, the conversation will appear as follows: 474 Authenticating Peer Authenticator 475 ------------------- ------------- 476 <- PPP LCP Request-EAP 477 auth 478 PPP LCP ACK-EAP 479 auth -> 480 <- PPP EAP-Request/ 481 Identity 482 PPP EAP-Response/ 483 Identity (MyID) -> 484 <- PPP EAP-Request/ 485 EAP-Type=EAP-TLS 486 (TLS Start, S bit set) 487 PPP EAP-Response/ 488 EAP-Type=EAP-TLS 489 (TLS client_hello)-> 490 <- PPP EAP-Request/ 491 EAP-Type=EAP-TLS 492 (TLS server_hello, 493 TLS certificate, 494 [TLS server_key_exchange,] 495 [TLS certificate_request,] 496 TLS server_hello_done) 497 (Fragment 1: L, M bits set) 498 PPP EAP-Response/ 499 EAP-Type=EAP-TLS -> 500 <- PPP EAP-Request/ 501 EAP-Type=EAP-TLS 502 (Fragment 2: M bit set) 503 PPP EAP-Response/ 504 EAP-Type=EAP-TLS -> 505 <- PPP EAP-Request/ 506 EAP-Type=EAP-TLS 507 (Fragment 3) 508 PPP EAP-Response/ 509 EAP-Type=EAP-TLS 510 (TLS certificate, 511 TLS client_key_exchange, 512 [TLS certificate_verify,] 513 TLS change_cipher_spec, 514 TLS inished)(Fragment 1: 515 L, M bits set)-> 516 <- PPP EAP-Request/ 517 EAP-Type=EAP-TLS 519 PPP EAP-Response/ 520 EAP-Type=EAP-TLS 521 (Fragment 2)-> 522 <- PPP EAP-Request/ 523 EAP-Type=EAP-TLS 524 (TLS change_cipher_spec, 525 TLS finished) 526 PPP EAP-Response/ 527 EAP-Type=EAP-TLS -> 528 <- PPP EAP-Success 529 PPP Authentication 530 Phase complete, 531 NCP Phase starts 533 ECP negotiation 535 CCP negotiation 537 In the case where the server authenticates to the client successfully, 538 but the client fails to authenticate to the server, the conversation 539 will appear 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-Type=EAP-TLS 553 (TLS Start) 554 PPP EAP-Response/ 555 EAP-Type=EAP-TLS 556 (TLS client_hello)-> 557 <- PPP EAP-Request/ 558 EAP-Type=EAP-TLS 559 (TLS server_hello, 560 TLS certificate, 561 [TLS server_key_exchange,] 562 TLS certificate_request, 563 TLS server_hello_done) 564 PPP EAP-Response/ 565 EAP-Type=EAP-TLS 566 (TLS certificate, 567 TLS client_key_exchange, 568 TLS certificate_verify, 569 TLS change_cipher_spec, 570 TLS finished) -> 571 <- PPP EAP-Request/ 572 EAP-Type=EAP-TLS 573 (TLS change_cipher_spec, 574 TLS finished) 575 PPP EAP-Response/ 576 EAP-Type=EAP-TLS -> 577 <- PPP EAP-Request 578 EAP-Type=EAP-TLS 579 (TLS Alert message) 580 PPP EAP-Response/ 581 EAP-Type=EAP-TLS -> 582 <- PPP EAP-Failure 583 (User Disconnected) 585 In the case where server authentication is unsuccessful, the conversa- 586 tion will appear as follows: 588 Authenticating Peer Authenticator 589 ------------------- ------------- 590 <- PPP LCP Request-EAP 591 auth 592 PPP LCP ACK-EAP 593 auth -> 594 <- PPP EAP-Request/ 595 Identity 596 PPP EAP-Response/ 597 Identity (MyID) -> 598 <- PPP EAP-Request/ 599 EAP-Type=EAP-TLS 600 (TLS Start) 601 PPP EAP-Response/ 602 EAP-Type=EAP-TLS 603 (TLS client_hello)-> 604 <- PPP EAP-Request/ 605 EAP-Type=EAP-TLS 606 (TLS server_hello, 607 TLS certificate, 608 [TLS server_key_exchange,] 609 [TLS certificate_request,] 610 TLS server_hello_done) 611 PPP EAP-Response/ 612 EAP-Type=EAP-TLS 613 (TLS certificate, 614 TLS client_key_exchange, 615 [TLS certificate_verify,] 616 TLS change_cipher_spec, 617 TLS finished) -> 618 <- PPP EAP-Request/ 619 EAP-Type=EAP-TLS 620 (TLS change_cipher_spec, 621 TLS finished) 622 PPP EAP-Response/ 623 EAP-Type=EAP-TLS 624 (TLS change_cipher_spec, 625 TLS finished) 626 <- PPP EAP-Request/ 627 EAP-Type=EAP-TLS 628 PPP EAP-Response/ 629 EAP-Type=EAP-TLS 630 (TLS Alert message) -> 631 <- PPP EAP-Failure 632 (User Disconnected) 634 In the case where a previously established session is being resumed, 635 and both sides authenticate successfully, the conversation will appear 636 as follows: 638 Authenticating Peer Authenticator 639 ------------------- ------------- 640 <- PPP LCP Request-EAP 641 auth 642 PPP LCP ACK-EAP 643 auth -> 644 <- PPP EAP-Request/ 645 Identity 646 PPP EAP-Response/ 647 Identity (MyID) -> 648 <- PPP EAP-Request/ 649 EAP-Request/ 650 EAP-Type=EAP-TLS 651 (TLS Start) 652 PPP EAP-Response/ 653 EAP-Type=EAP-TLS 654 (TLS client_hello)-> 655 <- PPP EAP-Request/ 656 EAP-Type=EAP-TLS 657 (TLS server_hello, 658 TLS change_cipher_spec 659 TLS finished) 660 PPP EAP-Response/ 661 EAP-Type=EAP-TLS 662 (TLS change_cipher_spec, 663 TLS finished) -> 664 <- PPP EAP-Success 665 PPP Authentication 666 Phase complete, 667 NCP Phase starts 669 ECP negotiation 671 CCP negotiation 673 In the case where a previously established session is being resumed, 674 and the server authenticates to the client successfully but the client 675 fails to authenticate to the server, the conversation will appear as 676 follows: 678 Authenticating Peer Authenticator 679 ------------------- ------------- 680 <- PPP LCP Request-EAP 681 auth 682 PPP LCP ACK-EAP 683 auth -> 684 <- PPP EAP-Request/ 685 Identity 686 PPP EAP-Response/ 687 Identity (MyID) -> 688 <- PPP EAP-Request/ 689 EAP-Request/ 690 EAP-Type=EAP-TLS 691 (TLS Start) 692 PPP EAP-Response/ 693 EAP-Type=EAP-TLS 694 (TLS client_hello) -> 695 <- PPP EAP-Request/ 696 EAP-Type=EAP-TLS 697 (TLS server_hello, 698 TLS change_cipher_spec, 699 TLS finished) 700 PPP EA-Response/ 701 EAP-Type=EAP-TLS 702 (TLS change_cipher_spec, 703 TLS finished) -> 704 <- PPP EAP-Request 705 EAP-Type=EAP-TLS 706 (TLS Alert message) 707 PPP EAP-Response 708 EAP-Type=EAP-TLS -> 709 <- PPP EAP-Failure 710 (User Disconnected) 712 In the case where a previously established session is being resumed, 713 and the server authentication is unsuccessful, the conversation will 714 appear as follows: 716 Authenticating Peer Authenticator 717 ------------------- ------------- 718 <- PPP LCP Request-EAP 719 auth 720 PPP LCP ACK-EAP 721 auth -> 722 <- PPP EAP-Request/ 723 Identity 724 PPP EAP-Response/ 725 Identity (MyID) -> 726 <- PPP EAP-Request/ 727 EAP-Request/ 728 EAP-Type=EAP-TLS 729 (TLS Start) 730 PPP EAP-Response/ 731 EAP-Type=EAP-TLS 732 (TLS client_hello)-> 733 <- PPP EAP-Request/ 734 EAP-Type=EAP-TLS 735 (TLS server_hello, 736 TLS change_cipher_spec, 737 TLS finished) 738 PPP EAP-Response/ 739 EAP-Type=EAP-TLS 740 (TLS change_cipher_spec, 741 TLS finished) 742 <- PPP EAP-Request/ 743 EAP-Type=EAP-TLS 744 PPP EAP-Response/ 745 EAP-Type=EAP-TLS 746 (TLS Alert message) -> 747 <- PPP EAP-Failure 748 (User Disconnected) 750 5. Detailed description of the EAP-TLS protocol 752 5.1. PPP EAP TLS Packet Format 754 A summary of the PPP EAP TLS Request/Response packet format is shown 755 below. The fields are transmitted from left to right. 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Code | Identifier | Length | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Type | Data... 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 Code 767 1 - Request 768 2 - Response 770 Identifier 772 The identifier field is one octet and aids in matching responses 773 with requests. 775 Length 777 The Length field is two octets and indicates the length of the EAP 778 packet including the Code, Identifier, Length, Type, and Data 779 fields. Octets outside the range of the Length field should be 780 treated as Data Link Layer padding and should be ignored on recep- 781 tion. 783 Type 785 13 - EAP TLS 787 Data 789 The format of the Data field is determined by the Code field. 791 5.2. PPP EAP TLS Request Packet 793 A summary of the PPP EAP TLS Request packet format is shown below. 794 The fields are transmitted from left to right. 796 0 1 2 3 797 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 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Code | Identifier | Length | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Type | Flags | TLS Message Length 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | TLS Message Length | TLS Data... 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 Code 808 1 810 Identifier 812 The Identifier field is one octet and aids in matching responses 813 with requests. The Identifier field MUST be changed on each 814 Request packet. 816 Length 818 The Length field is two octets and indicates the length of the EAP 819 packet including the Code, Identifier, Length, Type, and TLS 820 Response fields. 822 Type 824 13 - EAP TLS 826 Flags 828 0 1 2 3 4 5 6 7 8 829 +-+-+-+-+-+-+-+-+ 830 |L M S R R R R R| 831 +-+-+-+-+-+-+-+-+ 833 L = Length included 834 M = More fragments 835 S = EAP-TLS start 836 R = Reserved 838 The L bit (length included) is set to indicate the presence of the 839 four octet TLS Message Length field, and MUST be set for the first 840 fragment of a fragmented TLS message or set of messages. The M bit 841 (more fragments) is set on all but the last fragment. The S bit 842 (EAP-TLS start) is set in an EAP-TLS Start message. This differen- 843 tiates the EAP-TLS Start message from a fragment acknowledgement. 845 TLS Message Length 847 The TLS Message Length field is four octets, and is present only if 848 the L bit is set. This field provides the total length of the TLS 849 message or set of messages that is being fragmented. 851 TLS data 853 The TLS data consists of the encapsulated TLS packet in TLS record 854 format. 856 5.3. PPP EAP TLS Response Packet 858 A summary of the PPP EAP TLS Response packet format is shown below. 859 The fields are transmitted from left to right. 861 0 1 2 3 862 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 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Code | Identifier | Length | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Type | Flags | TLS Message Length 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | TLS Message Length | TLS Data... 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 Code 873 2 875 Identifier 877 The Identifier field is one octet and MUST match the Identifier 878 field from the corresponding request. 880 Length 882 The Length field is two octets and indicates the length of the EAP 883 packet including the Code, Identifir, Length, Type, and TLS data 884 fields. 886 Type 888 13 - EAP TLS 890 Flags 892 0 1 2 3 4 5 6 7 8 893 +-+-+-+-+-+-+-+-+ 894 |L M S R R R R R| 895 +-+-+-+-+-+-+-+-+ 897 L = Length included 898 M = More fragments 899 S = EAP-TLS start 900 R = Reserved 902 The L bit (length included) is set to indicate the presence of the 903 four octet TLS Message Length field, and MUST be set for the first 904 fragment of a fragmented TLS message or set of messages. The M bit 905 (more fragments) is set on all but the last fragment. The S bit 906 (EAP-TLS start) is set in an EAP-TLS Start message. This differen- 907 tiates the EAP-TLS Start message from a fragment acknowledgement. 909 TLS Message Length 911 The TLS Message Length field is four octets, and is present only if 912 the L bit is set. This field provides the total length of the TLS 913 message or set of messages that is being fragmented. 915 TLS data 917 The TLS data consists of the encapsulated TLS packet in TLS record 918 format. 920 6. References 922 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)." STD 51, 923 RFC 1661, July 1994. 925 [2] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, 926 "The PPP Multilink Protocol (MP)." RFC 1990, August 1996. 928 [3] Simpson, W., Editor, "PPP LCP Extensions." RFC 1570, January 1994. 930 [4] Rivest, R., Dusse, S., "The MD5 Message-Digest Algorithm", RFC 931 1321, April 1992. 933 [5] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol 934 (EAP)", RFC 2284, March 1998. 936 [6] Meyer, G., "The PPP Encryption Protocol (ECP)." RFC 1968, June 937 1996 939 [7] National Bureau of Standards, "Data Encryption Standard", FIPS PUB 940 46 (January 1977). 942 [8] National Bureau of Standards, "DES Modes of Operation", FIPS PUB 943 81 (December 1980). 945 [9] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, Version 946 2 (DESE-bis)", RFC 2419, September 1998. 948 [10] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", 949 RFC 2420, September 1998. 951 [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement 952 Levels", BCP 14, RFC 2119, March 1997. 954 [12] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", Internet 955 draft (work in progress) draft-ietf-tls-protocol-05.txt, November 956 1997. 958 [13] D. Rand. "The PPP Compression Control Protocol." RFC 1962, Nov- 959 ell, June 1996. 961 7. Security Considerations 963 7.1. Certificate revocation 965 Since the EAP server is on the Internet during the EAP conversation, 966 the server is capable of following a certificate chain or verifying 967 whether the peer's certificate has been revoked. In contrast, the peer 968 may or may not have Internet connectivity, and thus while it can vali- 969 date the EAP server's certificate based on a pre-configured set of 970 CAs, it may not be able to follow a certificate chain or verify 971 whether the EAP server's certificate has been revoked. 973 In the case where the peer is initiating a voluntary Layer 2 tunnel 974 using PPTP or L2TP, the peer will typically already have a PPP inter- 975 face and Internet connectivity established at the time of tunnel ini- 976 tiation. As a result, during the EAP conversation it is capable of 977 checking for certificate revocation. 979 However, in the case where the peer is initiating an intial PPP con- 980 versation, it will not have Internet connectivity and is therefore not 981 capable of checking for certificate revocation until after NCP negoti- 982 ation completes and the peer has access to the Internet. In this case, 983 the peer SHOULD check for certificate revocation after connecting to 984 the Internet. 986 7.2. Separation of the EAP server and PPP authenticator 988 As a result of the EAP-TLS conversation, the EAP endpoints will mutu- 989 ally authenticate, negotiate a ciphersuite, and derive a session key 990 for subsequent use in PPP encryption. Since the peer and EAP client 991 reside on the same machine, it is necessary for the EAP client module 992 to pass the session key to the PPP encryption module. 994 The situation may be more complex on the PPP authenticator, which may 995 or may not reside on the same machine as the EAP server. In the case 996 where the EAP server and PPP authenticator reside on different 997 machines, there are several implications for security. Firstly, the 998 mutual authentication defined in EAP-TLS will occur between the peer 999 and the EAP server, not between the peer and the authenticator. This 1000 means that as a result of the EAP-TLS conversation, it is not possible 1001 for the peer to validate the identity of the NAS or tunnel server that 1002 it is speaking to. 1004 The second issue is that the session key negotiated between the peer 1005 and EAP server will need to be transmitted to the authenticator. 1006 Therefore a mechanism needs to be provided to transmit the session key 1007 from the EAP server to the authenticator or tunnel server that needs 1008 to use the key. The specification of this transit mechanism is outside 1009 the scope of this document. 1011 7.3. Relationship of PPP encryption to other security mechanisms 1013 It is envisaged that EAP-TLS will be used primarily with dialup PPP 1014 connections. However, there are also circumstances in which PPP 1015 encryption may be used along with Layer 2 tunneling protocols such as 1016 PPTP and L2TP. 1018 In compulsory layer 2 tunneling, a PPP peer makes a connection to a 1019 NAS or router which tunnels the PPP packets to a tunnel server. Since 1020 with compulsory tunneling a PPP peer cannot tell whether its packets 1021 are being tunneled, let alone whether the network device is securing 1022 the tunnel, if security is required then the client must make its own 1023 arrangements. In the case where all endpoints cannot be relied upon to 1024 implement IPSEC, TLS, or another suitable security protocol, PPP 1025 encryption provides a convenient means to ensure the privacy of pack- 1026 ets transiting between the client and the tunnel server. 1028 8. Acknowledgments 1030 Thanks to Terence Spies, Glen Zorn and Narendra Gidwani of Microsoft 1031 for useful discussions of this problem space. 1033 9. Authors' Addresses 1035 Bernard Aboba 1036 Microsoft Corporation 1037 One Microsoft Way 1038 Redmond, WA 98052 1040 Phone: 425-936-6605 1041 EMail: bernarda@microsoft.com 1043 Dan Simon 1044 Microsoft Corporation 1045 One Microsoft Way 1046 Redmond, WA 98052 1047 Phone: 425-936-6711 1048 EMail: dansimon@microsoft.com 1050 10. Expiration Date 1052 This memo is filed as , and expires 1053 May 1, 1999.