idnits 2.17.1 draft-badra-eap-double-tls-05.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1172. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1156. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1162. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1178), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 15, 2006) is 6525 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) == Missing Reference: 'OutputLength' is mentioned on line 492, but not defined ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Possible downref: Normative reference to a draft: ref. 'SKTLS' ** Obsolete normative reference: RFC 2716 (ref. 'EAPTLS') (Obsoleted by RFC 5216) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') -- Possible downref: Normative reference to a draft: ref. 'EAPTTLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'PEAP' == Outdated reference: A later version (-38) exists of draft-urien-eap-smartcard-08 ** Downref: Normative reference to an Informational draft: draft-urien-eap-smartcard (ref. 'EAPSC') -- Possible downref: Non-RFC (?) normative reference: ref. 'GSM' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISOAPDU' Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Badra 3 INTERNET DRAFT P. Urien 4 ENST Paris 5 Expires: December 2006 June 15, 2006 7 EAP-Double-TLS Authentication Protocol 8 10 Status 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on December 15, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). All Rights Reserved. 39 1 Abstract 41 EAP-Double-TLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, 42 a full TLS handshake is used to mutually authenticate a peer and 43 server and to share a secret key. EAP-Double-TLS extends this 44 authentication negotiation by establishing a secure connection based 45 on the use of Pre Shared Keys (PSK). The secure connection may then 46 be used to allow the server and the peer to securely exchange their 47 identity and to update security attributes for next sessions. 49 EAP-Double-TLS allows the peer and the server to establish keying 50 material for use in the data connection between the peer and the 51 authenticator. The keying material is established implicitly between 52 peer and server based on the TLS Pre-Shared-Key handshake. 54 It provides additional security services such as anonymous exchanges 55 and identity protection against eavesdropping and the PFS (Perfect 56 Forward Secrecy). 58 Table of Contents 60 1 Abstract.........................................................1 61 2 Introduction.....................................................3 62 2.1 Requirements language.......................................4 63 3 Protocol design considerations and overview......................4 64 3.1 EAP identity protection.....................................4 65 3.2 Structure of the session identifier.........................4 66 3.3 Overview of the EAP-Double-TLS conversation.................5 67 3.3.1 Phase 1: Handshake....................................7 68 3.3.2 Phase 2...............................................8 69 3.3.2.1 Case 1: TLS Handshake...............................9 70 3.3.2.2 Case 2: AVP Exchanges...............................9 71 3.4. Retry behavior............................................10 72 3.5. Fragmentation.............................................10 73 3.6. Key derivation............................................10 74 3.7. CCP and CCP negotiation...................................11 75 3.8. Inner method encapsulation................................11 76 3.7. Examples.....................................................12 77 4 Detailed description of the EAP-Double-TLS protocol.............15 78 4.1 EAP-Double-TLS Packet Format...............................15 79 4.2 EAP-Double-TLS Request Packet..............................16 80 4.3 EAP-Double-TLS Response Packet.............................17 81 5 Security Considerations.........................................18 82 5.1 Security claims............................................18 83 5.1.1 Authentication, confidentiality, and Integrity. 84 Replay, man in-the-middle and dictionary attack protection.18 85 5.1.2 Session independence or perfect forward secrecy....19 86 5.1.4 Key strength.......................................20 87 5.1.5 Channel binding....................................20 88 5.1.6 Fast reconnect.....................................20 89 7 IANA Considerations.............................................20 90 Acknowledgements..................................................20 91 References........................................................20 92 Author's Addresses................................................21 93 Appendix A. EAP-Double-TLS protocol within EAP Smartcards.........21 94 A.1 Fragmentation issues.......................................22 95 2 Introduction 97 The Extensible Authentication Protocol (EAP) [EAP] defines a 98 mechanism that may be extended with additional authentication 99 protocols within PPP [PPP] such as MD5 [MD5], TLS [TLS] and PEAP 100 [PEAP]. 102 The EAP-TLS authentication method, described in [EAPTLS], provides a 103 standard method for mutual authentication and key generation. 104 However, this method requires the use of certificates and Public Key 105 Infrastructures (PKI) that MUST be well maintained. On the other 106 hand, this protocol can not provide some security services, such as 107 the supplicant's identity protection. 109 TLS itself allows the peer and the server to resume secure sessions 110 [TLS]. A secure connection may be terminated and resumed later. 111 Secure sessions can be resumed if the peer and the server agree. 112 During a resume Handshake, both the peer and the serve will use the 113 old master_secret and the new random numbers to calculate new 114 cryptographic keys. This will generate fewer cryptographic 115 computations and less processing time than a full TLS handshake. In 116 addition, it will save the bandwidth which is the bottleneck in the 117 wireless networks. 119 Shared-key handshake runs as a resume session using pre-installed 120 secret key. A detailed description may be found in [SKTLS]. However, 121 it may be an advantageous to use shared-key authentication handshake 122 instead of PKI based certificates. Further, shared-key TLS does not 123 require any asymmetric cryptographic operation (e.g. asymmetric 124 encrypt/decrypt or certificates verification). 126 EAP-Double-TLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, 127 a TLS handshake is used to mutually authenticate a peer and a 128 server. EAP-Double-TLS extends this authentication negotiation; 129 using the PSK authentication. 131 EAP-Double-TLS is composed of two phases. The first phase is based 132 on the use of PSKs to mutually authenticate the peer and the server 133 and to generate cryptographic keys, as it is defined in [SKTLS]. 135 The second phase is used to allow additional security services, such 136 as identity protection. It allows also the peer and the server to 137 update their security attributes for next sessions and then to 138 ensure the PFS (Perfect Forward Secrecy). 140 EAP-Double-TLS provides a mechanism for session key establishment 141 for encryption protocols within PPP such as PPP-DES [PPPDES] and 142 PPP-3DES [PPP3DES] protocols. 144 2.1 Requirements language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC-2119. 150 3 Protocol design considerations and overview 152 3.1 EAP identity protection 154 At the beginning of an EAP session, EAP identity (EAP-ID) is 155 transmitted in clear text, in the identity response message. This 156 parameter is used by the authenticator to forward EAP packets to the 157 authentication server which in turn uses it as an index for users' 158 database management. 160 In EAP-Double-TLS, EAP-ID SHOULD be replaced either by the TLS 161 session_id value (see 3.2) or by the session_id concatenated to the 162 authentication server address (session_id@server.com). 164 This process will protect the user's privacy against surveillance 165 and make the subscriber's EAP exchanges untraceable to 166 eavesdroppers. In fact, the current session_id will be replaced by a 167 new one computing or generating during phase 2 (see 3.2). 169 3.2 Structure of the session identifier 171 According to TLS, the peer hello message includes a variable length 172 session identifier. If not empty, the identifier identifies a TLS 173 session already established between the peer and the authentication 174 server. 176 EAP-Double-TLS defines a new structure of the session identifier, 177 used during the first phase. The structure is defined as follows: 179 struct { 180 opaque random_bytes<0..24>; 181 SecondPhaseExchange second_phase_exchange<1..8>; 182 } SessionID; 184 SecondPhaseExchange None = { 0x00 }; 185 SecondPhaseExchange TLS = { 0x01 }; 186 SecondPhaseExchange TLS_RSA_anon = { 0x02 }; 187 SecondPhaseExchange TLS_DH_anon = { 0x03 }; 188 SecondPhaseExchange AVP = { 0x04 }; 190 This new structure allows to the peer and to the server to negotiate 191 the key exchange method during the second phase. These methods are 192 sent by the peer, ordered according to its preference. There MUST be 193 at least one method acceptable to the server. This document defines 194 five methods: None, TLS, TLS_RSA_anon, TLS_DH_anon and AVP. 196 None refers to the option that means that the peer is satisfied by 197 running TLS resumed handshake (phase 2 will then not be executed). 198 TLS refers to the RFC2246 authentication based-certificate, 199 TLS_RSA_anon and TLS_DH_anon refers respectively to unauthenticated 200 (or ephemeral) RSA key exchange and Diffie_Hellman anonymous key 201 exchange. These last three types allow both the peer and the server 202 to generate new session_id and new master_secret. Concerning the 203 attribute-value pairs (AVPs), it is used to allow the server to send 204 back to the peer, a new master_secret and a new session_id. More 205 details are given through the document. 207 Note that TLS generates a variable length session identifier, which 208 MAY be at maximum 32 bytes. EAP-Double-TLS implementation MUST then 209 generate a variable length session identifier smaller than 24 bytes. 211 3.3 Overview of the EAP-Double-TLS conversation 213 In order to apply the use of shared key TLS, this document suggests 214 sharing a TLS session between the peer and the server. The session 215 is identified by a 24-byte session_id. It corresponds to, among 216 others, the value of the master_secret and the cipher_suite. The 217 cipher_suite represents the cryptographic option supported by both 218 the server and the peer and it is initialized by them to a 219 particular option. 221 In general, EAP-Double-TLS negotiation consists in two phases: 223 During the first phase, Shared-key handshake is used for mutual 224 authentication and key generation. This phase uses a cipher suite 225 allowing phase 2 to securely exchange TLS records or AVP. 227 peer Server 228 ---- ------ 230 ClientHello --------> 231 (session_id) ServerHello 232 ChangeCipherSpec 233 <-------- Finished 234 ChangeCipherSpec 235 Finished --------> 237 Figure 1: Phase 1, the Shared-key handshake 239 The second phase MAY be a full TLS handshake with mutual 240 authentication, only server-side authentication, or with anonymous 241 key exchange. Nevertheless, it MAY be an exchange of AVPs. In this 242 latter case, the server MUST generate a new (session_id, 243 master_secret) and send them to the peer, over a link encrypted with 244 the cryptographic keys generated during the first phase (examples of 245 exchanges are given in the section 3.7). 247 peer server 248 ---- ------ 250 Tunnel TLS 251 ................................... 252 . +----------+ +----------+ . 253 . | Handshake| | Handshake| . 254 . | phase 2 | | phase 2 | . 255 . +-----^----+ +----^-----+ . 256 . | | . 257 +---------+ . | | . +---------+ 258 |Handshake| . | | . |Handshake| 259 | phase 1 | . | | . | phase 1 | 260 +----^----+ . | | . +----^----+ 261 | . | | . | 262 | . | | . | 263 | . +----v----+ +----v----+ . | 264 | . | Record | | Record | . | 265 | . | phase 2 |<----->| phase 2 | . | 266 | . +--^------+ +------^--+ . | 267 | ......|.....................|...... | 268 | | | | 269 | +----+ +----+ | 270 | | | | 271 +-v-------v-+ +-v-------v-+ 272 | Record | | Record | 273 | phase 1 |<------------------------->| phase 1 | 274 +-----^-----+ +-----^-----+ 275 | | 276 <=======================================> 277 Carrier Protocol (PPP, EAPOL, RADIUS, etc) 279 Figure 2- Relationship between the EAP-Double-TLS peer and the EAP- 280 Double-TLS server, in the case of the use of TLS during 281 the second phase. 283 peer server 284 ---- ------ 286 AVP exchange 287 ................................ 288 . +--------+ +--- ----+ . 289 . | AVP | | AVP | . 290 . |Phase 2 | |Phase 2 | . 291 . +---^----+ +---^----+ . 292 ......|................|........ 293 +---------+ | | +---------+ 294 |Handshake| | | |Handshake| 295 | phase 1 | | | | phase 1 | 296 +----^----+ | | +----^----+ 297 | | | | 298 | | | | 299 | | | | 300 +-v------------v---+ +-v-----------v---+ 301 | Record (Phase 1)|<-------->| Record(Phase 1)| 302 +-----^------------+ +-----^-----------+ 303 | | 304 <=============================> 305 Carrier Protocol (PPP, EAPOL, RADIUS, etc) 307 Figure 3- Relationship between the EAP-Double-TLS peer and the EAP- 308 Double-TLS server, in the case of AVP exchange during the 309 second phase. 311 3.3.1 Phase 1: Handshake 313 In the first phase, the EAP-Double-TLS begins with the authenticator 314 sending an EAP-Request/Identity packet to the peer. The peer will 315 respond with an EAP-Response/Identity packet to the authenticator, 316 containing the peer's UserId (User Identifier). Once this is 317 established, the authenticator MAY act as a pass-through device, 318 with the EAP packets received from the peer being encapsulated for 319 transmission to a RADIUS server or back-end security server. 321 When the server receives the peer's Identity, it MUST respond with 322 an EAP-Double-TLS/Start packet. This is an EAP-Request packet with 323 EAP-Type= EAP-Double-TLS, the Start (S) bit set and no data. 325 When receiving this message, the peer will answer by EAP-Response 326 packet with EAP-Type= EAP-Double-TLS. The data field encapsulates 327 the TLS client_hello resumed handshake message. This message 328 contains, among others parameters, a random number and the 329 session_id corresponds to the TLS shared session the peer wishes to 330 use. The session_id contains both the SessionID.random_bytes and 331 SessionID.SecondPhaseExchange. 333 The server then checks its sessions' database for a match. If a 334 match is found and that the server is able to negotiate one of the 335 second_phase_exchange methods supported by the peer, the server 336 replays with EAP-Request with an EAP-Type= EAP-Double-TLS. This 337 packet will encapsulate the TLS server_hello handshake message. This 338 message transports, among others, the same value of 339 SessionID.random_bytes and another random number. The session_id 340 includes the second_phase_exchange method selected by the server 341 (SessionID.SecondPhaseExchange). 343 After the hello messages, the server will send its TLS change cipher 344 spec message and proceed directly to finished message. The finished 345 message will serve to authenticate the server to the peer since it 346 is encrypted and MACed using keys derived from the shared key. 348 If the EAP server authenticates unsuccessfully, the peer MAY send an 349 EAP-Response packet of EAP-Type= EAP-Double-TLS containing a TLS 350 Alert message identifying the reason for the failed authentication. 351 A fatal error message results in the immediate termination of the 352 connection. 354 In order to make sure that the server receives the TLS alert 355 message, the peer MUST wait for the server to reply before 356 terminating the conversation. Like in [EAPTLS], the server MUST 357 reply with an EAP-Failure packet since server authentication failure 358 is a terminal condition. 360 If the EAP server authenticates successfully (the peer decrypts the 361 finished message and verify the MAC), the peer MUST send an EAP- 362 Response packet of EAP-Type= EAP-Double-TLS, that transports the 363 change cipher spec and the finished messages. Once this 364 establishment is complete, the peer and the server MAY start the 365 second phase. Otherwise, the server will send data connection keying 366 information and other authorization information to the 367 authenticator. 369 If the peer authenticates unsuccessfully, the server MAY send an 370 EAP-Response packet of EAP-Type= EAP-Double-TLS containing a TLS 371 Alert message identifying the reason for the failed authentication. 372 Alert messages with a level of fatal result in the immediate 373 termination of the connection. 375 In order to make sure that the peer receives the TLS alert message, 376 the server MUST wait for the peer to reply before terminating the 377 conversation. 379 3.3.2 Phase 2 381 EAP-Double-TLS Phase 2 will occur if the establishment of its first 382 phase is successfully terminated. Phase 2 is used to ensure 383 additional services such as peer identity protection and PFS. This 384 phase MAY be established by executing a TLS session or by exchanging 385 AVPs between the peer and the server. 387 3.3.2.1 Case 1: TLS Handshake 389 During the second phase, the TLS Record layer is used to securely 390 tunnel data related to the second phase. TLS session data will be 391 encapsulated in sequences of TLS attributes, whose use and format 392 are described in [TLS]. 394 The peer starts the second phase by sending its hello. The 395 ClientHello follows the Finished message sent by the peer during the 396 first phase 398 Next, the peer and the server continue to exchange EAP packets until 399 either the TLS session is successfully established or an error 400 occurs. If the session is successfully established, the peer MUST 401 send an EAP-Response packet of EAP-Type= EAP-Double-TLS, and no 402 data. The EAP-Server must then respond with an EAP-Success message. 404 At this point, the server distributes data connection keying 405 information and other authorization data to the authenticator, which 406 are derived from the shared key that was used during the first 407 phase. Next, the server and the peer replace the security parameters 408 (e.g. the shared key and its identity) with the security parameters 409 that are generated by TLS during the second phase. These new TLS 410 security parameters will be then used during the next EAP-Double-TLS 411 sessions. 413 3.3.2.2 Case 2: AVP Exchanges 415 The second phase MAY be established using AVP exchanges, if the peer 416 and the server agree. The AVP is securely tunneled between the 417 client and server by TLS Record. 419 This document defines the AVP Session-Id-Master-Secret (AVP Code 420 TBS). The Data field is 48 or more octets and contains a new 421 (session_id, master_secret) generated by the server. 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | AVP Code (TBS) | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | AVP Length | | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Data = master_secret#session_id (# means concatenation) 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 In this case of AVPs exchange, the server encodes a new 24-byte 433 session_id (e.g. SessionID.random_bytes) and a new 48-byte 434 master_secret, encapsulates them in the AVP Session-Id-Master- 435 Secret, passes the result to the TLS record layer, and sends the 436 resulting data to the peer. The peer recovers the AVP in clear text 437 from the TLS record layer. If this is successfully established, the 438 peer MUST send an EAP-Response packet of EAP-Type= EAP-Double-TLS, 439 and no data. The EAP-Server must then respond with an EAP-Success 440 message. 442 At this point, the peer and the server update their shared 443 master_secret and session_id with the new ones generated by the 444 server and delivered to the peer. Next, the server distributes data 445 connection keying information and other authorization data to the 446 authenticator. 448 3.4. Retry behavior 450 See section 3.2 of RFC 2716. 452 3.5. Fragmentation 454 See section 3.3 of RFC 2716. 456 3.6. Key derivation 458 EAP-Double-TLS derives keying material after each successful 459 negotiation in each phase. The first phase allows the peer and the 460 server to generate a 48-byte master_secret (MS1) by applying the 461 TLS-PRF (Pseudo Random Function) [TLS] on the shared key (SK), 462 ClientHello.random and ServerHello.random: 464 MS1 = PRF(SK, "master_secret", 465 ClientHello.random + ServerHello.random)[0..48] 467 This key is used to derive keying material used to encrypt and to 468 calculate the MAC of each message. Keys derived from MS1 are then 469 delivered to the authenticator for additional keys computation. 471 When TLS is selected as second_key_exchange, the peer and the server 472 will exchange new random values. The peer is also able to randomly 473 generate a secret key (the pre_master_secret in TLS terminology). 474 This key is sent securely to the server using the server public key 475 and it is used to generate a new and fresh master_secret key (FMS) 476 by applying the PRF on, among others, the pre_master_secret (PMS). 477 The generated key will be then used during the future EAP-Double-TLS 478 session. 480 FMS = PRF(PMS, "master_secret", 481 ClientHello.random + ServerHello.random) [0..48] 482 When AVP is selected as second_key_exchange, both the peer and the 483 server will replace the old master_secret and the old session_id 484 with the new ones that are generated by the server and delivered to 485 the peer. 487 Note: the client and the server can derive and compute the required 488 keys (e.g. MSK, EMSK, etc.) by applying the TLS-PRF on the MS1 and 489 the random values of the first phase. PRF's P_hash can be iterated 490 as many times as is necessary to produce the required key length 491 (e.g., OutputKey = PRF(MS1, "output_key", 492 ClientHello.random + ServerHello.random) [OutputLength]) 494 3.7. CCP and CCP negotiation 496 See section 3.6 and 3.7 of RFC 2716. 498 3.8. Inner method encapsulation 500 As stated before, EAP-Double-TLS uses the TLS record layer to tunnel 501 information between the peer and the server to, among others 502 operations perform additional authentication. In this optic, EAP- 503 Double-TLS reuses the attribute-value pairs (AVPs) defined in 504 [EAPTTLS]. 506 3.7. Examples 508 The following exchanges show where TLS is selected as 509 second_key_exchange: 511 Authenticating Peer Authenticator 512 ------------------- ------------- 513 <- EAP-Request/Identity 514 EAP-Response/Identity -> 515 <- EAP-Request/ 516 EAP-Type= EAP-Double-TLS 517 (EAP-Double-TLS Start) 518 EAP-Response/ 519 EAP-Type= EAP-Double-TLS 520 (TLS client_hello)-> 521 <- EAP-Request/ 522 EAP-Type= EAP-Double-TLS 523 (TLS server_hello, 524 TLS change_cipher_spec, 525 TLS finished) 526 EAP-Response/ 527 EAP-Type= EAP-Double-TLS 528 (TLS change_cipher_spec, 529 TLS finished 530 TLS client_hello) -> 531 <- EAP-Request/ 532 EAP-Type= EAP-Double-TLS 533 (TLS server_hello, 534 [TLS certificate], 535 [TLS server_key_exchange], 536 [TLS certificate_request], 537 TLS server_hello_done) 538 EAP-Response/ 539 EAP-Type= EAP-Double-TLS 540 ([TLS certificate], 541 TLS client_key_exchange, 542 [TLS certificate_verify], 543 TLS change_cipher_spec, 544 TLS finished) -> 545 <- EAP-Request/ 546 EAP-Type= EAP-Double-TLS 547 (TLS change_cipher_spec, 548 TLS finished) 549 EAP-Response/ 550 EAP-Type= EAP-Double-TLS -> 551 <- EAP-Success 552 The following exchanges show where AVP is selected as 553 second_key_exchange: 555 Authenticating Peer Authenticator 556 ------------------- ------------- 557 <- EAP-Request/Identity 558 EAP-Response/Identity -> 559 <- EAP-Request/ 560 EAP-Type= EAP-Double-TLS 561 (EAP-Double-TLS Start) 562 EAP-Response/ 563 EAP-Type= EAP-Double-TLS 564 (TLS client_hello)-> 565 <- EAP-Request/ 566 EAP-Type= EAP-Double-TLS 567 (TLS server_hello, 568 TLS change_cipher_spec, 569 TLS finished) 570 EAP-Response/ 571 EAP-Type= EAP-Double-TLS 572 (TLS change_cipher_spec, 573 TLS finished) -> 575 <- EAP-Request/ 576 EAP-Type= EAP-Double-TLS 577 (AVP 578 [session_id, master_secret]) 579 EAP-Response/ 580 EAP-Type= EAP-Double-TLS -> 581 <- EAP-Success 583 The following exchanges show where TLS is selected as 584 second_key_exchange and fragmentation is required (during the phase 585 1, no fragmentation is required), the conversation (during the phase 586 2) will be as follows: 588 Authenticating Peer Authenticator 589 ------------------- ------------- 590 <- EAP-Request/ 591 EAP-Type= EAP-Double-TLS 592 (TLS Hello Request, S bit set) 593 EAP-Response/ 594 EAP-Type= EAP-Double-TLS 595 (TLS client_hello)-> 596 <- EAP-Request/ 597 EAP-Type= EAP-Double-TLS 598 (TLS server_hello, 599 TLS change_cipher_spec, 600 TLS finished) 601 (Fragment 1: L, M bits set) 602 EAP-Response/ 603 EAP-Type= EAP-Double-TLS -> 604 <- EAP-Request/ 605 EAP-Type= EAP-Double-TLS 606 (Fragment 2: M bits set) 607 EAP-Response/ 608 EAP-Type= EAP-Double-TLS -> 609 <- EAP-Request/ 610 EAP-Type= EAP-Double-TLS 611 (Fragment 3) 612 EAP-Response/ 613 EAP-Type= EAP-Double-TLS 614 (TLS change_cipher_spec, 615 TLS finished)(Fragment 1: 616 L, M bits set)-> 617 <- EAP-Success 619 During the phase 1 and in the case where the server authenticates to 620 the peer successfully, but the peer fails to authenticate to the 621 server, the conversation will be as follows: 623 Authenticating Peer Authenticator 624 ------------------- ------------- 625 <- EAP-Request/Identity 626 EAP-Response/Identity -> 627 <- EAP-Request/ 628 EAP-Type= EAP-Double-TLS 629 (TLS Start) 630 EAP-Response/ 631 EAP-Type= EAP-Double-TLS 632 (TLS client_hello)-> 633 <- EAP-Request/ 634 EAP-Type= EAP-Double-TLS 635 (TLS server_hello, 636 TLS change_cipher_spec 637 TLS finished) 638 EAP-Response/ 639 EAP-Type= EAP-Double-TLS 640 (TLS change_cipher_spec, 641 TLS finished) -> 642 <- EAP-Request 643 EAP-Type= EAP-Double-TLS 644 (TLS Alert message) 645 EAP-Response/ 646 EAP-Type= EAP-Double-TLS -> 647 <- EAP-Failure 648 (User Disconnected) 649 During the phase 1 and in the case where server authentication is 650 unsuccessful, the conversation will be as follows: 652 Authenticating Peer Authenticator 653 ------------------- ------------- 654 <- EAP-Request/Identity 655 EAP-Response/Identity -> 656 <- EAP-Request/ 657 EAP-Type= EAP-Double-TLS 658 (TLS Start) 659 EAP-Response/ 660 EAP-Type= EAP-Double-TLS 661 (TLS client_hello) -> 662 <- EAP-Request/ 663 EAP-Type= EAP-Double-TLS 664 (TLS server_hello, 665 TLS change_cipher_spec, 666 TLS finished) 668 EAP-Response/ 669 EAP-Type= EAP-Double-TLS 670 (TLS Alert message) -> 671 <- EAP-Failure 672 (User Disconnected) 674 4 Detailed description of the EAP-Double-TLS protocol 676 This section shows the conversation between the peer and the 677 authenticator using EAP-Double-TLS protocol. It takes the same 678 notifications introduced in the section 4 of RFC2716 [EAPTLS]. 680 4.1 EAP-Double-TLS Packet Format 682 A summary of the EAP-Double-TLS Request/Response packet format is 683 shown below. The fields are transmitted from left to right. 685 0 1 2 3 686 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 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Request | Identifier | Length | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Type | Data... 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 The description of the EAP/Response/identity is detailed according 694 to the IETF RFC 2284. 696 4.2 EAP-Double-TLS Request Packet 698 A summary of the EAP-Double-TLS Request packet format is shown 699 below. The fields are transmitted from left to right. 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Code=01 | Identifier | Length | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Type | Flag | EAP-Double-TLS Message Length 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | EAP-Double-TLS Message Length | EAP-Double-TLS Data... 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 Code 713 1 715 Identifier 717 The Identifier field is one octet and aids in matching responses 718 with requests. The Identifier field MUST be changed on each Request 719 packet. 721 Length 723 The Length field is two octets and indicates the length of the EAP 724 packet including the Code, Identifier, Length, Type, and Double-TLS 725 Response fields. 727 Type 729 TBD - EAP Double TLS 731 Flags 733 0 1 2 3 4 5 6 7 734 +-+-+-+-+-+-+-+-+ 735 |L M S R R R R R| 736 +-+-+-+-+-+-+-+-+ 738 L = Length included 739 M = More fragments 740 S = EAP-Double-TLS start 741 R = Reserved 743 The L bit (length included) is set to indicate the presence of the 744 four octet Double-TLS Message Length field, and MUST be set for the 745 first fragment of a fragmented EAP-Double-TLS message or set of 746 messages. The M bit (more fragments) is set on all but the last 747 fragment. The S Bit (EAP-Double-TLS start) is set in an EAP-Double- 748 TLS Start message. This differentiates the EAP-Double-TLS Start 749 message from a fragment acknowledgement. 751 Double-TLS Message Length 753 The Double-TLS Message Length field is four octets, and is present 754 only if the L bit is set. This field provides the total length of 755 the Double-TLS message or set of messages that is being fragmented. 757 Double-TLS data 759 The Double-TLS data consists of the encapsulated Double-TLS packet 760 in TLS record format. 762 4.3 EAP-Double-TLS Response Packet 764 A summary of the EAP-Double-TLS Request packet format is shown 765 below. The fields are transmitted from left to right. 767 0 1 2 3 768 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 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Code=01 | Identifier | Length | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Type | Flag | EAP-Double-TLS Message Length 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | EAP-Double-TLS Message Length | EAP-Double-TLS Data... 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 Code 779 2 781 Identifier 783 The Identifier field is one octet and MUST match the Identifier 784 field from the corresponding request. 786 Length 788 The Length field is two octets and indicates the length of the EAP 789 packet including the Code, Identifier, Length, Type, and Double-TLS 790 Response fields. 792 Type 794 TBD - EAP Double TLS 795 Flags 797 0 1 2 3 4 5 6 7 798 +-+-+-+-+-+-+-+-+ 799 |L M S R R R R R| 800 +-+-+-+-+-+-+-+-+ 802 L = Length included 803 M = More fragments 804 S = EAP-Double-TLS start 805 R = Reserved 807 The L bit (length included) is set to indicate the presence of the 808 four octet Double-TLS Message Length field, and MUST be set for the 809 first fragment of a fragmented EAP-Double-TLS message or set of 810 messages. The M bit (more fragments) is set on all but the last 811 fragment. The S Bit (EAP-Double-TLS start) is set in an EAP-Double- 812 TLS Start message. This differentiates the EAP-Double-TLS Start 813 message from a fragment acknowledgement. 815 Double-TLS Message Length 817 The Double-TLS Message Length field is four octets, and is present 818 only if the L bit is set. This field provides the total length of 819 the Double-TLS message or set of messages that is being fragmented. 821 Double-TLS data 823 The Double-TLS data consists of the encapsulated Double-TLS packet 824 in TLS record format. 826 5 Security Considerations 828 The EAP-Double-TLS server MUST stock the TLS session in a secure and 829 protected manner in order to prevent attackers from retrieving the 830 master_secret values and session' parameters. 832 5.1 Security claims 834 This section describes EAP-Double-TLS in terms of specific security 835 terminology as required by [EAP]. 837 5.1.1 Authentication, confidentiality, and Integrity. Replay, man 838 in-the-middle and dictionary attack protection 840 EAP-Double-TLS provides mutual authentication using the shared key 841 during the first phase. EAP-Double-TLS mitigates man-in-the-middle 842 vulnerabilities because of the mutual authentication established 843 during the first phase. The confidentiality and integrity are 844 provided using the negotiated cryptographic algorithms as well as 845 encryption and authentication keys derived from the shared key. 846 Furthermore and during the second phase, messages notification 847 (failure or success) are also protected against man-in-the-middle 848 and eavesdropping attacks. This is because they are encrypted with 849 the tunnel established during the first phase. On the other hand and 850 like TLS, EAP-Double-TLS natively protects against replay protection 851 attacks using sequence numbers. The use of sequence numbers and of 852 strong cryptographic algorithms (e.g., AES) defends the protocol 853 against dictionary attacks. 855 5.1.2 Session independence or perfect forward secrecy 857 EAP-Double-TLS protocol independently generates keys per session and 858 it MAY uses ephemeral public/private keys during its second phase. 859 As a result, it provides Perfect Forward Secrecy (i.e. ephemeral 860 Deffie-Hellman and RSA public keys are both supported by EAP-Double- 861 TLS as key exchange methods in the case where TLS is selected as 862 second_phase_exchange). Added to that, passive attacks (such as 863 capture of the EAP conversation) or active attacks (including the 864 recovery of the shared key) do not entail the compromising of prior 865 shared keys and are thus incapable of decrypting previous sessions. 867 In the case of AVP, the PFS is provided, by generating new secret 868 key which is independent to any old secret. 870 5.1.3 Protected cipher suite negotiation and user identity 871 protection 873 EAP-Double-TLS ensures cipher suite negotiation in a protected 874 manner. In fact, it uses the same TLS principle that offers an 875 integrated mechanism to protect cipher suite negotiation. This is 876 because at the end of the first phase, the peer and server exchange 877 the finished messages. These messages are always sent immediately 878 after a change cipher spec message to verify that the key exchange 879 and authentication processes were successful. They are the first 880 messages protected with the just-negotiated algorithms and the 881 secret key, and it is computed in function of, among others, all 882 handshake messages data, including the negotiated cipher suite. 884 Concerning the identity protection and as we cited above, the shared 885 key and its identity are replaced with new values if the second 886 phase of EAP-Double-TLS is successfully terminated. This process 887 will protect the user's privacy and identity against surveillance 888 and make the subscriber's EAP exchanges untraceable to 889 eavesdroppers. In fact, the EAP-ID value used at the beginning and 890 the session_id used during the first phase will be replaced by a new 891 session_id securely computing and generating during the EAP-Double- 892 TLS second phase. 894 5.1.4 Key strength 896 EAP-Double-TLS reuses the TLS-PRF for keys generation (See [TLS]). 898 5.1.5 Channel binding 900 EAP-Double-TLS does not explicitly include any channel binding. 902 5.1.6 Fast reconnect 904 Due to the nature of wireless connections, the peer MAY be 905 disconnected at any time. Fortunately, the EAP-Double-TLS peer and 906 the server don't have to go through the entire process every time 907 they want to communicate. While EAP-Double-TLS is based on TLS, fast 908 reconnection option is implicitly included; executing TLS resumed 909 Handshake (as described in phase 1). 911 7 IANA Considerations 913 This document requires IANA to allocate a new EAP Type for EAP- 914 Double-TLS, new AVP Code for Session-Id-Master-Secret AVP and for 915 values related to the SecondPhaseExchange. 917 Acknowledgements 919 This EAP method has been inspired by [EAPTLS] and [TLS]. Thus, it 920 reused extracts of these documents. 922 References 924 [TLS] Dierks, T., et. al, "The TLS Protocol Version 1.0", RFC 925 2246, November 1998. 927 [SKTLS] Gutmann, P., "Use of Shared Keys in the TLS Protocol", 928 draft-ietf-tls-sharedkeys-02 (expired), October 2003. 930 [PPP] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 931 STD 51, RFC 1661, July 1994. 933 [EAPTLS] Aboba, B., and D., Simon, "PPP EAP TLS Authentication 934 Protocol", RFC 2716, October 1999. 936 [MD5] Rivest, R., and S., Dusse, "The MD5 Message-Digest 937 Algorithm", RFC 1321, April 1992. 939 [EAP] Aboba, B., et. al., "PPP Extensible Authentication 940 Protocol EAP)", RFC 3748, June 2004. 942 [PPPDES] Sklower, K., and G., Meyer, "The PPP DES Encryption 943 Protocol, Version 2 (DESE-bis)", RFC 2419, September 944 1998. 946 [PPP3DES] Hummert, K., "The PPP Triple-DES Encryption Protocol 947 (3DESE)", RFC 2420, September 1998. 949 [EAPTTLS] Funk, P., et. al., "EAP Tunneled TLS Authentication 950 Protocol (EAP-TTLS)" draft-ietf-pppext-eap-ttls-05.txt, 951 Internet draft (work in progress), August 2004. 953 [PEAP] TBC 955 [EAPSC] Urien, P., et. al., "EAP support in smartcards", 956 draft-urien-eap-smartcard-08.txt, Internet draft (work in 957 progress), July 2005. 959 [GSM] GSM Technical Specification GSM 11.11. Digital cellular 960 telecommunications system (Phase 2+); Specification of 961 the Subscriber Identity Module - Mobile Equipment (SIM � 962 ME) interface, Version 5.0.0, December 1995. 964 [802.11] IEEE Std. 802.11, IEEE Standard for Wireless LAN Medium 965 Access Control (MAC) and Physical Layer (PHY) 966 Specifications, 1997. 968 [ISOAPDU] ISO 7816-4 SmartCard Standard: Part 4: Inter industry 969 Commands for Interchange, 1995. 971 Author's Addresses 973 Mohamad Badra 974 ENST 975 46 rue Barrault 976 75634 Paris Phone: NA 977 France Email: Mohamad.Badra@enst.fr 979 Pascal Urien 980 ENST 981 46 rue Barrault 982 75634 Paris Phone: NA 983 France Email: Pascal.Urien@enst.fr 985 Appendix A. EAP-Double-TLS protocol within EAP Smartcards 987 EAP-support in smartcards is described and detailed by an Internet 988 draft [EAPSC]. It is an opened, ISO 7816 microcontroller supporting 989 most authentication protocols. An EAP smartcard implements an EAP 990 method (EAP-TLS, etc) and works in cooperation with a smartcard 991 interface entity, which transparently sends and receives EAP 992 messages to and from this component. 994 Smartcard is one of the news technologies added to the world of 995 information technology. In fact, they can make significant impact on 996 current computer systems and network environments because of their 997 inherent security and mobility. Further, they are an effective means 998 of adding enhanced protection to wireless networks; namely 802.11 999 wireless LAN. Added to that, they are widely used in the Global 1000 System for Mobile Communication (GSM) [GSM] in the form of a SIM 1001 (Subscriber Identity Module) card for secure access to the mobile 1002 network, for storing basic network information and for 1003 accounting/billing procedures. 1005 Smartcards have a bear particular attraction, as they generally 1006 considered as the most secure computing platform. In fact, they 1007 offer good tamper resistance. This means that certain physical 1008 hardware and software protections are used, which makes it difficult 1009 to extract or modify private and secret information in the module. 1010 So it seems a good idea to store the (strong) master_secret keys on 1011 a smartcard. Further, smartcard deployment in a typical network such 1012 as WLAN 802.11 [802.11] offers the enhanced functionality of tighter 1013 authentication. 1015 A.1 Fragmentation issues 1017 Data is exchanged between the terminal and the smartcard through a 1018 card acceptance device (CAD) in the form of messages exchanged from 1019 the terminal to the card and vice versa. Data transport is 1020 established by using Data Pocket called Application Protocol Data 1021 Unit (APDU). Each APDU consists of two fields: 5 bytes header and 0- 1022 255 bytes of data. The ISO [ISOAPDU] standard defines these 1023 command/response packets that are used for reading, writing and 1024 exchanging data between the host and the smartcard. These packets 1025 transferred from the CAD to the module (command APDU) are followed 1026 by a response APDU from the module back to the CAD. 1028 The TLS Record Layer fragments information blocks into TLS records 1029 carrying data in chunks of 16384 bytes or less [TLS]. Furthermore, 1030 TLS message may carry multiple TLS records. Since the IEEE 802.3 MAC 1031 may not send frames greater than 1518 bytes in length and because 1032 fragmentation support is not provided by EAP, it is the 1033 responsibility of EAP methods to provide the fragmentation required. 1034 For that, EAP-Double-TLS extends the EAP-TLS segmentation method, 1035 which defines a segmentation process that splits TLS messages in 1036 smaller blocks, acknowledged by the recipient. In this context, the 1037 RADIUS server generates acknowledged requests and the supplicant 1038 answers by acknowledged responses. 1040 EAP-TLS defines the fragmentation mechanism for data exchanged 1041 between the server and the terminal. It will not define the data 1042 segmentation between the terminal and the smartcard because the 1043 latter is not readable to the EAP-TLS server. For that and in order 1044 to allow smartcards use, a double segmentation mechanism was 1045 introduces by EAP-Double-TLS to forward TLS packets to the 1046 smartcard. We defined this mechanism as following. First, TLS server 1047 messages are divided in smaller segments (E1, E2), whose size is 1048 typically 1400 bytes or less (figure 3). Next, the segments are 1049 encapsulated in EAP-Double-TLS packets that are split in a 1050 collection of APDUs (A11 .. A1p .. An1 .. Anq) in the form of 1051 ISO7816 commands. Afterwards, the APDUs (each APDUs size is around 1052 240 bytes) are forwarded to the EAP-Double-TLS smartcard. Note that 1053 for each APDU received by the smartcard, an APDU response, with 2 1054 bytes of data, is generated to inform the supplicant of the APDUs 1055 status (if the APDU was arrived and correctly processed or no). 1057 EAP-Double-TLS Supplicant Authentication 1058 Smartcard Smartcard interface server 1059 +---------------------+ +-------------+ +--------------+ 1060 | | | | | | 1061 TLS EAP-Double-TLS EAP-Double-TLS TLS 1062 ----- --------- --------- ----- 1063 Send: TLS 1064 message M1 = E1 .. En 1065 EAP-Double-TLS: 1066 E1 <= 1400 octets 1067 <-- Frag E1 = A11 .. A1p 1068 <-- APDU : Frag A11 1069 (<= 240 octets) 1070 APDU --> 1071 Ack A11 . 1072 . . 1073 . 1074 <-- APDU : Frag A1p 1075 (<= 240 octets) 1076 APDU --> 1077 Ack A1p 1078 Ack E1 --> 1079 . 1080 . . 1081 . EAP-Double-TLS: 1082 En <= 1400 octets 1083 <-- Frag En = An1 .. Alq 1085 <-- APDU : Frag An1 1086 (<= 240 octets) 1087 APDU --> 1088 Ack Ap1 . 1089 . . 1091 . 1092 <-- APDU : Frag Anq 1093 (<= 240 octets) 1094 <---- 1095 Receive: TLS 1096 message M1 1098 Send: TLS 1099 message M2= F1 .. Fk 1100 = A1 .. Ak 1101 EAP-Double-TLS: F1 1102 (<= 240 octets) --> 1103 <-- EAP-TLS 1104 . Ack F1 1105 . . 1106 . . 1107 reassembly M2 fragments 1108 and send the result using 1109 packets of 1400 octets or less 1110 --> 1112 . <-- EAP-TLS 1113 . Ack 1114 EAP-Double-TLS: Fi 1115 (<= 240 octets) --> 1116 <-- EAP-TLS 1117 . Ack Fi 1118 . 1119 EAP-Double-TLS: Fk . 1120 (<= 240 octets) --> . . 1121 <-- EAP-TLS . 1122 Ack Fk 1123 --> 1124 Receive: TLS 1125 message M2 1127 Figure 3 - Smartcard double segmentation using EAP-Double-TLS 1128 Authentication Protocol 1130 However, for the smartcard part and in order to prevent multiple 1131 segmentation and re-assembly operations, the maximum EAP message 1132 length of a no fragmented packet SHALL be set to 240 bytes. For a 1133 fragmented EAP message, the maximum length value shall be 240 bytes. 1135 As defined in EAP-TLS, when the EAP-Double-TLS smartcard receives an 1136 EAP-Request packet with the M bit set, it MUST respond with an EAP- 1137 Response with EAP-Type=EAP-TLS and no data. This serves as a 1138 fragment ACK. 1140 Intellectual Property Statement 1142 The IETF takes no position regarding the validity or scope of any 1143 Intellectual Property Rights or other rights that might be claimed 1144 to pertain to the implementation or use of the technology described 1145 in this document or the extent to which any license under such 1146 rights might or might not be available; nor does it represent that 1147 it has made any independent effort to identify any such rights. 1148 Information on the IETF's procedures with respect to rights in IETF 1149 Documents can be found in BCP 78 and BCP 79. 1151 Copies of IPR disclosures made to the IETF Secretariat and any 1152 assurances of licenses to be made available, or the result of an 1153 attempt made to obtain a general license or permission for the use 1154 of such proprietary rights by implementers or users of this 1155 specification can be obtained from the IETF on-line IPR repository 1156 at http://www.ietf.org/ipr. 1158 The IETF invites any interested party to bring to its attention any 1159 copyrights, patents or patent applications, or other proprietary 1160 rights that may cover technology that may be required to implement 1161 this standard. Please address the information to the IETF at ietf- 1162 ipr@ietf.org. 1164 Disclaimer of Validity 1166 This document and the information contained herein are provided on 1167 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1168 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1169 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1170 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1171 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1172 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1174 Copyright Statement 1176 Copyright (C) The Internet Society (2006). This document is subject 1177 to the rights, licenses and restrictions contained in BCP 78, and 1178 except as set forth therein, the authors retain all their rights. 1180 Acknowledgment 1182 Funding for the RFC Editor function is currently provided by the 1183 Internet Society.