idnits 2.17.1 draft-ietf-emu-eap-session-id-07.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 : ---------------------------------------------------------------------------- -- 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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. (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 (3 September 2020) is 1324 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FILS' == Outdated reference: A later version (-10) exists of draft-ietf-emu-rfc5448bis-07 == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 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 (if approved) 3 September 2020 5 Intended status: Standards Track 6 Expires: March 03, 2021 8 EAP Session-Id Derivation for EAP-SIM, EAP-AKA, and PEAP 9 draft-ietf-emu-eap-session-id-07.txt 11 Abstract 13 RFC 5247 is updated to define and clarity EAP Session-Id derivation 14 for multiple EAP methods. The derivation of Session-Id was not given 15 for EAP-SIM or EAP-AKA when using the fast reconnect exchange instead 16 of full authentication. The derivation of Session-Id for full 17 authentication is clarified for both EAP-SIM and EAP-AKA. The 18 deriviation of Session-Id for PEAP is also given. The definition for 19 PEAP follows the definition for other TLS-based EAP methods. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on March 03, 2021. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction ............................................. 4 62 1.1. Requirements Language ............................... 4 63 2. Updates to RFC 5247 Appendix A ........................... 5 64 2.1. EAP-AKA ............................................. 5 65 2.2. EAP-SIM ............................................. 5 66 2.3. Rationale for EAP-AKA and EAP-SIM updates ........... 6 67 3. Session-Id for PEAP ...................................... 7 68 4. Security Considerations .................................. 7 69 5. IANA Considerations ...................................... 8 70 6. References ............................................... 8 71 6.1. Normative References ................................ 8 72 6.2. Informative References .............................. 8 74 1. Introduction 76 EAP [RFC3748] Session-Id derivation has not been defined for EAP-SIM 77 and EAP-AKA when using the fast reconnect exchange instead of full 78 authentication. [RFC5247] defines the Session-Id for these EAP 79 methods, but that derivation is only applicable for the full 80 authentication case. The Session-Id derivation was not defined for 81 EAP-AKA', but [AKAP] now defines it, along with other updates. As 82 such, the definition for EAP-AKA' is not included here. 84 Further, the deriviation of Session-Id for full authentication is 85 clarified, as the text in [RFC5247] is ambiguousl 87 The IEEE has defined Fast Initial Link Setup (FILS) authentication 88 [FILS], which needs the EAP Session-Id in order for the EAP Re- 89 authentication Protocol (ERP) [RFC6696] to work. It is therefore 90 important to address the existing deficiencies in the definition of 91 EAP Session-Id. 93 Finally, [RFC5247] did not define Session-Id for PEAP [MS-PEAP], 94 [PEAP]. We correct these deficiencies here by updating [RFC5247] with 95 the Session-Id derivation during fast-reconnect exchange for EAP-SIM 96 and EAP-AKA; clarfying the Session-Id derivation during full 97 authentication for EAP-SIM and EAP-AKA; and defining the Session-Id 98 derivation for PEAP which is the same for both full authentication 99 and fast reconnect. 101 1.1. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 2. Updates to RFC 5247 Appendix A 111 This section updates [RFC5247] Appendix A to define Session-Id for 112 fast reconnect exchange for EAP-AKA and EAP-SIM. 114 2.1. EAP-AKA 116 For EAP-AKA, [RFC5247] Appendix A says: 118 EAP-AKA 120 EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the 121 concatenation of the EAP Type Code (0x17) with the contents of the 122 RAND field from the AT_RAND attribute, followed by the contents of 123 the AUTN field in the AT_AUTN attribute: 125 Session-Id = 0x17 || RAND || AUTN 127 It should say: 129 EAP-AKA 131 EAP-AKA is defined in [RFC4187]. When using full authentication, 132 the EAP-AKA Session-Id is the concatenation of the EAP Type Code 133 (0x17) with the contents of the RAND field from the AT_RAND 134 attribute, followed by the contents of the AUTN field in the 135 AT_AUTN attribute: 137 Session-Id = 0x17 || RAND || AUTN 139 When using fast reconnect, the EAP-AKA Session-Id is the 140 concatenation of the EAP Type Code (0x17) with the contents of the 141 NONCE_S field from the AT_NONCE_S attribute, followed by the 142 contents of the MAC field from the AT_MAC attribute from EAP- 143 Request/AKA-Reauthentication: 145 Session-Id = 0x17 || NONCE_S || MAC 147 2.2. EAP-SIM 149 Similarly for EAP-SIM, [RFC5247] Appendix A says: 151 EAP-SIM 153 EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the 154 concatenation of the EAP Type Code (0x12) with the contents of the 155 RAND field from the AT_RAND attribute, followed by the contents of 156 the NONCE_MT field in the AT_NONCE_MT attribute: 158 Session-Id = 0x12 || RAND || NONCE_MT 160 It should say: 162 EAP-SIM 164 EAP-SIM is defined in [RFC4186]. When using full authentication, 165 the EAP-SIM Session-Id is the concatenation of the EAP Type Code 166 (0x12) with the contents of the RAND field from the AT_RAND 167 attribute, followed by the contents of the NONCE_MT field in the 168 AT_NONCE_MT attribute. RFC 4186 says that EAP server should 169 obtain "n" GSM triplets where "n=2" or "n=3". 171 For "n=2", the Session-Id is therefore defined as 173 Session-Id = 0x12 || RAND1 || RAND2 || NONCE_MT 175 which is 49 octets in length. 177 For "n=3", the Session-Id is therefore defined as 179 Session-Id = 0x12 || RAND1 || RAND2 || RAND3 || NONCE_MT 181 which is 65 octets in length. 183 Where RAND1, RAND2 and RAND3 correspond to the RAND value from the 184 first, second and third GSM triplet respectively. 186 When using fast reconnect, the EAP-SIM Session-Id is the 187 concatenation of the EAP Type Code (0x12) with the contents of the 188 NONCE_S field from the AT_NONCE_S attribute, followed by the 189 contents of the MAC field from the AT_MAC attribute from EAP- 190 Request/SIM/Reauthentication: 192 Session-Id = 0x12 || NONCE_S || MAC 194 which is 33 octets in length. 196 2.3. Rationale for EAP-AKA and EAP-SIM updates 198 [RFC5247] was supposed to define exported parameters for existing EAP 199 methods in Appendix A. The way Session-Id was defined for EAP-AKA and 200 EAP-SIM works only for the full authentication case, i.e., it cannot 201 be used when the optional fast reconnect case is used since the used 202 parameters (RAND, AUTN, NONCE_MT) are not used in the fast reconnect 203 case. Based on [RFC4187] Section 5.2, and similar text in [RFC4186] 204 Section 5.2, NONCE_S corresponds to RAND and MAC in EAP-Request/AKA- 205 Reauthentication and EAP-Request/SIM/Reauthentication corresponds to 206 AUTN. That would seem to imply that the Session-Id could be defined 207 using NONCE_S and MAC instead of RAND and AUTN/NONCE_MT. 209 This deriviation is done via a random value created by the server, 210 along with a secret key and the peer's identity. We believe that 211 this deriviation is secure, though no formal analysis has been done. 213 3. Session-Id for PEAP 215 [RFC5247] did not define Session-Id for Microsoft's Protected EAP 216 (PEAP). For consistency with the EAP-TLS definition given in 217 [RFC5216] Section 2.3, we define it as: 219 Session-Id = 0x19 || client.random || server.random 221 This definition is that same for both full authentication, and for 222 fast reconnect. 224 This definition is already in wide-spread use in all known PEAP 225 implementations. 227 Note that this definition for Session-Id only applies when TLS 1.2 or 228 earlier is used. A different derivation is defined for TLS 1.3 in 229 [TLS-EAP-TYPES]. 231 4. Security Considerations 233 This specification defines EAP Session-Ids for ERP with EAP-SIM and 234 EAP-AKA. It therefore enables ERP key hierarchy establishment using 235 fast reconnect with EAP-SIM and EAP-AKA. 237 The Session-Id definitions given here are unique per session and 238 unforgeable and unguessable by an outside party, as per the 239 requirements of [RFC5247] Section 10. 241 The definitions used here have been widely deployed for years, in 242 all major EAP implementations. However, we acknowledge that very 243 little security analysis has been done for these definitions. As a 244 result, any security issues would result in serious issues for the 245 Internet as a whole. 247 These updates do not modify the Security Considerations outlined in 248 RFC5247. 250 5. IANA Considerations 252 There are no actions for IANA. RFC EDITOR: This section may be 253 removed before publication. 255 6. References 257 6.1. Normative References 259 [RFC2119] 260 Bradner, S., "Key words for use in RFCs to Indicate Requirement 261 Levels", RFC 2119, March, 1997, . 264 [RFC3748] 265 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 266 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 267 June 2004. 269 [RFC5216] 270 Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication 271 Protocol", RFC 5216, March 2008 273 [RFC5247] 274 Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication 275 Protocol (EAP) Key Management Framework", RFC 5247, August 2008, 277 [RFC8174] 278 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key 279 Words", RFC 8174, May 2017, . 282 [FILS] 283 "IEEE Standard for Information technology--Telecommunications and 284 information exchange between systems Local and metropolitan area 285 networks--Specific requirements - Part 11: Wireless LAN Medium 286 Access Control (MAC) and Physical Layer (PHY) Specifications - 287 Amendment 1: Fast Initial Link Setup", IEEE Std 802.11ai-2016, 288 2016. 290 6.2. Informative References 292 [RFC4186] 293 Haverinen, H. (Ed), Salowey, J., "Extensible Authentication 294 Protocol Method for Global System for Mobile Communications (GSM) 295 Subscriber Identity Modules (EAP-SIM)", RFC 4186, January 2006. 297 [RFC4187] 298 Arkko, J., Haverinen, H., "Extensible Authentication Protocol 299 Method for 3rd Generation Authentication and Key Agreement (EAP- 300 AKA)", RFC 4187, January 2006. 302 [RFC6696] 303 Cao, Z. et al, "EAP Extensions for EAP Re-authentication Protocol 304 (ERP)", RFC 6696, July 2012. 306 [AKAP] 307 Arkko, J., et al, "Improved Extensible Authentication Protocol 308 Method for 3rd Generation Authentication and Key Agreement (EAP- 309 AKA')", draft-ietf-emu-rfc5448bis-07.txt, March 2020. 311 [TLS-EAP-TYPES] 312 DeKok, A., "TLS-based EAP types and TLS 1.3" draft-dekok-emu-tls- 313 eap-types-02, April 2020. 315 [MS-PEAP] 316 Microsoft, "[MS-PEAP]: Protected Extensible Authentication Protocol 317 (PEAP)", https://docs.microsoft.com/en- 318 us/openspecs/windows_protocols/ms-peap/5308642b-90c9-4cc4-beec- 319 fb367325c0f9 321 [PEAP] 322 Andersson, H., et al, "Protected EAP Protocol (PEAP)", draft- 323 josefsson-pppext-eap-tls-eap-05.txt, September 2002. 325 Acknowledgments 327 The issue corrected in this specification was first reported by Jouni 328 Malinen in a technical errata at https://www.rfc- 329 editor.org/errata_search.php?rfc=5247 331 The text in this document follows Jouni's suggestions. 333 Authors' Addresses 335 Alan DeKok 336 The FreeRADIUS Server Project 338 Email: aland@freeradius.org