idnits 2.17.1 draft-ietf-emu-tls-eap-types-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC5247], [RFC5281], [RFC3748], [EAPTLS], [RFC7170], [RFC4851], [RFC5216]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC7170, but the abstract doesn't seem to directly say this. It does mention RFC7170 though, so this could be OK. -- The draft header indicates that this document updates RFC5281, but the abstract doesn't seem to directly say this. It does mention RFC5281 though, so this could be OK. -- The draft header indicates that this document updates RFC22, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5247, but the abstract doesn't seem to directly say this. It does mention RFC5247 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- No information found for rfc22 - is the name correct? (Using the creation date from RFC5247, updated by this document, for RFC5378 checks: 2003-10-13) -- 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 (22 June 2021) is 1032 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) -- Looks like a reference, but probably isn't: '0' on line 197 == Outdated reference: A later version (-21) exists of draft-ietf-emu-eap-tls13-14 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-06 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group DeKok, Alan 3 INTERNET-DRAFT FreeRADIUS 4 Updates: 5247, 5281, 7170 22 June 2021 5 Category: Standards Track 6 Expires: December 22, 2021 8 TLS-based EAP types and TLS 1.3 9 draft-ietf-emu-tls-eap-types-03.txt 11 Abstract 13 EAP-TLS [RFC5216] is being updated for TLS 1.3 in [EAPTLS]. Many 14 other EAP [RFC3748] and [RFC5247] types also depend on TLS, such as 15 FAST [RFC4851], TTLS [RFC5281], TEAP [RFC7170], and possibly many 16 vendor specific EAP methods. This document updates those methods in 17 order to use the new key derivation methods available in TLS 1.3. 18 Additional changes necessitated by TLS 1.3 are also discussed. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 29, 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info/) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction ............................................. 4 61 1.1. Requirements Language ............................... 4 62 2. Using TLS-based EAP methods with TLS 1.3 ................. 5 63 2.1. Key Derivation ...................................... 5 64 2.2. TEAP ................................................ 6 65 2.3. FAST ................................................ 7 66 2.4. TTLS ................................................ 8 67 2.5. PEAP ................................................ 8 68 3. Application Data ......................................... 9 69 4. Resumption ............................................... 10 70 5. Security Considerations .................................. 10 71 5.1. Protected Success and Failure indicators ............ 11 72 6. IANA Considerations ...................................... 12 73 7. References ............................................... 13 74 7.1. Normative References ................................ 13 75 7.2. Informative References .............................. 14 77 1. Introduction 79 EAP-TLS is being updated for TLS 1.3 in [EAPTLS]. Many other EAP 80 types also depend on TLS, such as FAST [RFC4851], TTLS [RFC5281], 81 TEAP [RFC7170], and possibly many vendor specific EAP methods such as 82 PEAP [PEAP]. All of these methods use key derivation functions which 83 are no longer applicable to TLS 1.3. As such, all of those methods 84 are incompatible with TLS 1.3. 86 We wish to enable the use of TLS 1.3 in the wider Internet community. 87 As such, it is necessary to update the above EAP Types. These 88 changes involve defining new key derivation functions. We also 89 discuss implementation issues in order to highlight differences 90 between TLS 1.3 and earlier versions of TLS. 92 1.1. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 2. Using TLS-based EAP methods with TLS 1.3 102 In general, all of the requirements of [EAPTLS] apply to other EAP 103 methods that wish to use TLS 1.3. Unless otherwise required herein, 104 implementations of EAP methods that wish to use TLS 1.3 MUST follow 105 the guidelines in [EAPTLS]. 107 There remain some differences between EAP-TLS and other TLS-based EAP 108 methods which necessitates this document. The main difference is 109 that [EAPTLS] uses the EAP-TLS Type (value 0x0D) in a number of 110 calculations, whereas other method types will use their own Type 111 value instead of the EAP-TLS Type value. This topic is discussed 112 further below in Section 2. 114 An additional difference is that the [EAPTLS] Section 2.5 requires 115 that once the EAP-TLS handshake has completed, the EAP server sends a 116 protected success result indication. This indication is composed of 117 one octet (0x00) of application data. Other TLS-based EAP methods 118 also use this indicator, but only during resumption. When the other 119 TLS-based EAP methods use full authentication, the indicator is not 120 needed, and is not used. This topic is explained in more detail 121 below, in Section 3. 123 Finally, the document includes clarifications on how various TLS- 124 based parameters are calculated when using TLS 1.3. These parameters 125 are different for each EAP method, so they are discussed separately. 127 2.1. Key Derivation 129 The key derivation for TLS-based EAP methods depends on the value of 130 the EAP Type as defined by [IANA] in the Extensible Authentication 131 Protocol (EAP) Registry. The most important definition is of the 132 Type field, as first defined in [RFC3748] Section 2: 134 Type = value of the EAP Method type 136 For the purposes of this specification, when we refer to logical 137 Type, we mean that the logical Type is defined to be 1 octet for 138 values smaller than 254 (the value for the Expanded Type), and when 139 Expanded EAP Types are used, the logical Type is defined to be the 140 concatetation of the fields required to define the Expanded Type, 141 including the Type with value 0xfe, Vendor-Id (in network byte order) 142 and Vendor-Type fields (in network byte order) defined in [RFC3748] 143 Section 5.7. 145 Type = 0xFE || Vendor-Id || Vendor-Type 147 This definition does not alter the meaning of Type in [RFC3748], or 148 change the structure of EAP packets. Instead, this definition allows 149 us to simplify references to EAP Types, by just using a logical 150 "Type" instead of referring to "the Type field or the Type field with 151 value 0xfe, plus the Vendor-ID and Vendor-Type". 153 Unless otherwise discussed below, the key derivation functions for 154 all TLS-based EAP Types are defined as follows: 156 Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", 157 Type, 128) 158 Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", 159 Type, 64) 160 Session-Id = Type || Method-Id 161 MSK = Key_Material(0, 63) 162 EMSK = Key_Material(64, 127) 164 We note that these definitions re-use the EAP-TLS exporter labels, 165 and change the derivation only by adding a dependency on the logical 166 Type. The reason for this change is simplicity. There does not 167 appear to be compelling reasons to make the labels method-specific, 168 when they can just include the logical Type in the key derivation. 170 These definitions apply in their entirety to TTLS [RFC5281] and PEAP 171 as defined in [PEAP] and [MSPEAP]. Some definitions apply to FAST 172 and TEAP, with exceptions as noted below. 174 It is RECOMMENDED that vendor-defined TLS-based EAP methods use the 175 above definitions for TLS 1.3. There is no compelling reason to use 176 different definitions. 178 2.2. TEAP 180 [RFC7170] Section 5.2 gives a definition for the Inner Method Session 181 Key (IMSK), which depends on the TLS-PRF. We update that definition 182 for TLS 1.3 as: 184 IMSK = TLS-Exporter("TEAPbindkey@ietf.org", EMSK, 32) 186 For MSK and EMSK, TEAP [RFC7170] uses an inner tunnel EMSK to 187 calculate the outer EMSK. As such, those key derivations cannot use 188 the above derivation. 190 The other key derivations for TEAP are given here. All derivations 191 not given here are the same as given above in the previous section. 192 These derivations are also used for FAST, but using the FAST Type. 194 session_key_seed = TLS-Exporter("EXPORTER: session key seed", 195 Type, 40) 197 S-IMCK[0] = session_key_seed 198 For j = 1 to n-1 do 199 IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys", 200 S-IMCK[j-1] | IMSK[j], 60) 201 S-IMCK[j] = first 40 octets of IMCK[j] 202 CMK[j] = last 20 octets of IMCK[j] 204 Where | denotes concatenation. MSK and EMSK are then derived from 205 the above definitions, as: 207 MSK = TLS-Exporter("EXPORTER: Session Key Generating Function", 208 S-IMCK[j], 64) 210 EMSK = TLS-Exporter("EXPORTER: Extended Session Key Generating Function", 211 S-IMCK[j], 64) 213 The TEAP Compound MAC defined in [RFC7170] Section 5.3 is updated to 214 use the definition of CMK[j] given above, which then leads to the 215 following definition 217 CMK = CMK[j] 219 Compound-MAC = MAC( CMK, BUFFER ) 221 where j is the number of the last successfully executed inner EAP 222 method. For TLS 1.3, the hash function used is the same as the 223 ciphersuite hash function negotiated for HKDF in the key schedule, as 224 per section 7.1 of RFC 8446. The definition of BUFFER is unchanged 225 from [RFC7170] Section 5.3 227 2.3. FAST 229 For FAST, the session_key_seed is also used as the key_block, as 230 defined in [RFC4851] Section 5.1. 232 The definition of S-IMCK[n], MSK, and EMSK are the same as given 233 above for TEAP. We reiterate that the EAP-FAST Type must be used 234 when deriving the session_key_seed, and not the TEAP Type. 236 Unlike [RFC4851] Section 5.2, the definition of IMCK[j] places the 237 reference to S-IMCK after the textual label, and the concatenates the 238 IMSK instead of MSK. 240 EAP-FAST previously used a PAC, which is a type of pre-shared key 241 (PSK). Such uses are deprecated in TLS 1.3. As such, PAC 242 provisioning is no longer part of EAP-FAST when TLS 1.3 is used. 244 The T-PRF given in [RFC4851] Section 5.5 is not used for TLS 1.3. 246 2.4. TTLS 248 [RFC5281] Section 11.1 defines an implicit challenge when the inner 249 methods of CHAP [RFC1994], MS-CHAP [RFC2433], or MS-CHAPv2 [RFC2759] 250 are used. The derivation for TLS 1.3 is instead given as 252 EAP-TTLS_challenge = TLS-Exporter("ttls challenge",, n) 254 There no "context_value" ([RFC8446] Section 7.5) passed to the TLS- 255 Exporter function. The value "n" given here is the length of the 256 challenge required, which [RFC5281] requires to be either 8 or 16 257 octets, depending on the challenge being used. 259 Note that unlike TLS 1.2 and earlier, the calculation of TLS-Exporter 260 depends on the length passed to it. Implementations therefore MUST 261 pass the correct length, instead of passing a large length and 262 truncating the output. Any output calculated using a longer length 263 which is then truncated, will be different from the output calculated 264 using the correct length. 266 2.5. PEAP 268 When PEAP uses crypto binding, it uses a different key calculation 269 defined in [PEAP-MPPE] which consumes inner method keying material. 270 The pseudo-random function (PRF) used here is not taken from the TLS 271 exporter, but is instead calculated via a different method which is 272 given in [PEAP-PRF]. That derivation remains unchanged in this 273 specification. 275 However, the key calculation uses a PEAP Tunnel Key [PEAP-TK] which 276 is defined as: 278 ... the TK is the first 60 octets of the Key_Material, as 279 specified in [RFC5216]: TLS-PRF-128 (master secret, "client EAP 280 encryption", client.random || server.random). 282 We note that this text does not define Key_Material. Instead, it 283 defines TK as the first octets of Key_Material, and gives a 284 definition of Key_Material which is appropriate for TLS versions 285 before TLS 1.3. 287 For TLS 1.3, the TK should be derived from the Key_Material defined 288 above in Section 2.1, instead of using the TLS-PRF-128 derivation 289 given above. 291 3. Application Data 293 Unlike previous TLS versions, TLS 1.3 can continue negotiation after 294 the initial TLS handshake has been completed, which TLS 1.3 calls the 295 "CONNECTED" state. Some implementations use a "TLS finished" 296 determination as an indication that TLS negotiation has completed, 297 and that an "inner tunnel" session can now be negotiated. This 298 assumption is no longer correct for TLS 1.3. 300 TLS 1.3 permits NewSessionTicket messages to be sent before the TLS 301 "Finished", and after application data is sent. This change can 302 cause many implementations to fail in a number of different ways. 304 In order to correct this failure, we require that if the underlying 305 TLS connection is still performing negotiation, then implementations 306 MUST NOT send, or expect to receive application data in the TLS 307 session. Implementations MUST delay processing of application data 308 until such time as the TLS negotiation has finished. If the TLS 309 negotiation is successful, then the application data can be examined. 310 If the TLS negotiation is unsuccessful, then the application data is 311 untrusted, and therefore MUST be discarded without being examined. 313 The default for many TLS library implementations is to send a 314 NewSessionTicket message immediately after, or along with, the TLS 315 Finished message. This ticket is could be used for resumption, even 316 if the "inner tunnel" authentication has not been completed. If the 317 ticket could be used, then it could allow a malicious EAP peer to 318 completely bypass the "inner tunnel" authentication 320 Therefore, the EAP server MUST NOT permit any session ticket to 321 successfully resume authentication, unless the inner tunnel 322 authentication has completed successfully. 324 To protect against that attack, implementations SHOULD NOT send 325 NewSessionTicket messages until the "inner tunnel" authentication has 326 completed. There is no reason to send session tickets which will 327 later be invalidated or ignored. However, we recognize that this 328 suggestion may not always be possible to implement with some 329 available TLS libraries. As such, EAP server MUST take care to 330 either invalidate or discard session tickets which are associated 331 with sessions that terminate in EAP Failure. 333 The NewSessionTicketMessage SHOULD also be sent along with other 334 application data, if possible. Sending that message alone bloats the 335 packet exchange to no benefit. 337 [EAPTLS] Section 2.5 requires a protected result indicator which 338 indicates that TLS negotiation has finished. Methods which use 339 "inner tunnel" methods MUST instead begin their "inner tunnel" 340 negotiation by sending Type-specific application data. 342 4. Resumption 344 [EAPTLS] Section 2.1.3 defines the process for resumption. This 345 process is the same for all TLS-based EAP types. The only practical 346 difference is that the value of the Type field is different. 348 All TLS-based EAP methods support resumption, as it is a property of 349 the underlying TLS protocol. All EAP servers and peers MUST support 350 resumption for all TLS-based EAP methods. We note that EAP servers 351 and peers can still choose to not resume any particular session. For 352 example, EAP servers may forbid resumption for administrative, or 353 other policy reasons. 355 It is RECOMMENDED that EAP servers and peers enable resumption, and 356 use it where possible. The use of resumption decreases the number of 357 round trips used for authentication. This decrease leads to lower 358 latency for authentications, and less load on the EAP server. 359 Resumption can also lower load on external systems, such as databases 360 which contain user credentials. 362 As the packet flows for resumption are essentially identical across 363 all TLS-based EAP types, it is technically possible to authenticate 364 using EAP-TLS (Type 13), and then perform resumption using another 365 EAP type, just as EAP-TTLS (Type 21). However, there is no practical 366 benefit to doing so. It is also not clear what this behavior would 367 mean, or what (if any) security issues there may be with it. As a 368 result, this behavior is forbidden. 370 EAP servers therefore MUST NOT resume sessions across different EAP 371 Types, and EAP servers MUST reject resumptions in which the EAP Type 372 value is different from the original authentication. 374 5. Security Considerations 376 [EAPTLS] Section 5 is included here by reference. 378 Updating the above EAP methods to use TLS 1.3 is of high importance 379 for the Internet Community. Using the most recent security protocols 380 can significantly improve security and privace of a network. 382 In some cases, client certificates are not used for TLS-based EAP 383 methods. In those cases, the user is authenticated only after 384 successful completion of the inner tunnel authentication. However, 385 the TLS protocol may send one or more NewSessionTicket after 386 receiving the TLS Finished message from the client, and therefore 387 before the user is authenticated. 389 This separation of data allows for a "time of use, time of check" 390 security issue. Malicious clients can begin a session and receive a 391 NewSessionTicket. The malicious client can then abort the 392 authentication session, and the obtained NewSessionTicket to "resume" 393 the previous session. 395 As a result, EAP servers MUST NOT permit sessions to be resumed until 396 after authentication has successfully completed. This requirement 397 may be met in a number of ways. For example, by not caching the 398 session ticket until after authentication has completed, or by 399 marking up the cached session ticket with a flag stating whether or 400 not authentication has completed. 402 For PEAP, some derivation use HMAC-SHA1 [PEAP-MPPE]. There are no 403 known security issues with HMAC-SHA1. In the interests of 404 interoperability and minimal changes, we do not change that 405 deriviation. 407 5.1. Protected Success and Failure indicators 409 [EAPTLS] provides for protected success and failure indicators as 410 discussed in Section 4.1.1 of [RFC4137]. These indicators are 411 provided for both full authentication, and for resumption. 413 Other TLS-based EAP methods provide these indicators only for 414 resumption. 416 For full authenticaton, the other TLS-based EAP methods do not 417 provide for protected success and failure indicators as part of the 418 outer TLS exchange. That is, the protected result indicator is not 419 used, and there is no TLS-layer alert sent when the inner 420 authentication fails. Instead, there is simply either an EAP-Success 421 or EAP-Failure sent. This behavior is the same as for previous TLS 422 versions, and therefore introduces no new security issues. 424 We note that most TLS-based EAP methods provide for success and 425 failure indicators as part of the authentication exchange performed 426 inside of the TLS tunnel. These indicators are therefore protected, 427 as they cannot be modified or forged. 429 However, some inner methods do not provide for success or failure 430 indicators. For example, the use of TTLS with inner PAP or CHAP. 431 Those methods send authentication credentials to the server via the 432 inner tunnel, with no possibility to similarly signal success or 433 failure inside of the tunnel. 435 There are functionally equivalent authentication methods which can be 436 used to replace the methods which are missing protected indicators. 437 PAP can often be replaced with EAP-GTC, and CHAP with EAP-MD5. Both 438 replacement methods provide for similar functionality, and have 439 protected success and failure indicator. The main cost to this 440 change is additional round trips. 442 It is RECOMMENDED that implementations deprecate inner tunnel methods 443 which do not provided protected success and failure indicators. 444 Implementations SHOULD use EAP-GTC instead of PAP, and EAP-MD5 445 instead of CHAP. New TLS-based EAP methods MUST provide protected 446 success and failure indicators inside of the TLS tunnel. 448 When the inner authentication protocol indicates that authentication 449 has failed, then implementations MUST fail authentication for the 450 entire session. There MAY be additional protocol exchanges in order 451 to exchange more detailed failure indicators, but the final result 452 MUST be a failed authentication. As noted earlier, any session 453 tickets for this failed authentication MUST be either invalidated or 454 discarded. 456 Similarly, when the inner authentication protocol indicates that 457 authentication has succeeed, then implementations SHOULD cause 458 authentication to succeed for the entire session. There MAY be 459 additional protocol exchanges in order which could cause other 460 failures, so success is not required here. 462 In both of these cases, the EAP server MUST send an EAP-Failure or 463 EAP-Success message, as indicated by Section 2, item 4 of [RFC3748]. 464 Even though both parties have already determined the final 465 authentication status, the full EAP state machine must still be 466 followed. 468 6. IANA Considerations 470 This section provides guidance to the Internet Assigned Numbers 471 Authority (IANA) regarding registration of values related to the TLS- 472 based EAP methods for TLS 1.3 protocol in accordance with [RFC8126]. 474 This memo requires IANA to add the following labels to the TLS 475 Exporter Label Registry defined by [RFC5705]. These labels are used 476 in the derivation of Key_Material and Method-Id as defined above in 477 Section 2. 479 The labels below need to be added to the "TLS Exporter Labels" 480 registry. These labels are used only for TEAP. 482 * EXPORTER: session key seed 483 * EXPORTER: Inner Methods Compound Keys 484 * EXPORTER: Session Key Generating Function 485 * EXPORTER: Extended Session Key Generating Function 486 * TEAPbindkey@ietf.org 488 7. References 490 7.1. Normative References 492 [RFC2119] 493 Bradner, S., "Key words for use in RFCs to Indicate Requirement 494 Levels", RFC 2119, March, 1997, . 497 [RFC3748] 498 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 499 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 500 June 2004. 502 [RFC5216] 503 Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication 504 Protocol", RFC 5216, March 2008 506 [RFC5247] 507 Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication 508 Protocol (EAP) Key Management Framework", RFC 5247, August 2008, 510 [RFC5705] 511 Rescorla, E., "Keying Material Exporters for Transport Layer 512 Security (TLS)", RFC 5705, March 2010 514 [RFC7170] 515 Zhou, H., et al., "Tunnel Extensible Authentication Protocol (TEAP) 516 Version 1", RFC 7170, May 2014. 518 [RFC8126] 519 Cotton, M., et al, "Guidelines for Writing an IANA Considerations 520 Section in RFCs", RC 8126, June 2017. 522 [RFC8174] 523 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key 524 Words", RFC 8174, May 2017, . 527 [RFC8446] 528 Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 529 1.3", RFC 8446, August 2018. 531 [EAPTLS] 532 Mattsson, J., and Sethi, M., "Using EAP-TLS with TLS 1.3", draft- 533 ietf-emu-eap-tls13-14, February, 2021. 535 [IANA] 536 https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap- 537 numbers-4 539 7.2. Informative References 541 [MSPEAP] 542 https://msdn.microsoft.com/en-us/library/cc238354.aspx 544 [PEAP] 545 Palekar, A. et al, "Protected EAP Protocol (PEAP)", draft- 546 josefsson-pppext-eap-tls-eap-06.txt, March 2003. 548 [PEAP-MPPE] 549 https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS- 550 PEAP/e75b0385-915a-4fc3-a549-fd3d06b995b0 552 [PEAP-PRF] 553 https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS- 554 PEAP/0de54161-0bd3-424a-9b1a-854b4040a6df 556 [PEAP-TK] 557 https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS- 558 PEAP/41288c09-3d7d-482f-a57f-e83691d4d246 560 [RFC1994] 561 Simpson, W., "PPP Challenge Handshake Authentication Protocol 562 (CHAP)", RFC 1994, August 1996. 564 [RFC2433] 565 Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", RFC 2433, 566 October 1998. 568 [RFC2759] 569 Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, 570 January 2000. 572 [RFC4137] 573 Vollbrecht, J., et al, "State Machines for Extensible 574 Authentication Protocol (EAP) Peer and Authenticator ", RFC 4137, 575 August 2005. 577 [RFC4851] 578 Cam-Winget, N., et al, "The Flexible Authentication via Secure 579 Tunneling Extensible Authentication Protocol Method (EAP-FAST)", 580 RFC 4851, May 2007. 582 [RFC5281] 583 Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol 584 Tunneled Transport Layer Security Authenticated Protocol Version 0 585 (EAP-TTLSv0)", RFC 5281, August 2008. 587 Acknowledgments 589 Thanks to Jorge Vergara for a detailed review of the requirements for 590 various EAP types, and for assistance with interoperability testing. 592 Authors' Addresses 594 Alan DeKok 595 The FreeRADIUS Server Project 597 Email: aland@freeradius.org