idnits 2.17.1 draft-ietf-emu-eap-session-id-01.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 abstract seems to indicate that this document updates RFC5247, but the header doesn't have an 'Updates:' line to match this. 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. -- The document date (4 November 2019) is 1606 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) ** Obsolete normative reference: RFC 5296 (Obsoleted by RFC 6696) -- Possible downref: Non-RFC (?) normative reference: ref. 'FILS' -- Unexpected draft version: The latest known version of draft-arkko-eap-rfc5448bis is -01, but you're referring to -04. Summary: 1 error (**), 0 flaws (~~), 2 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 5 Category: Standards Track 6 7 4 November 2019 9 EAP Session-Id Derivation for EAP-SIM, EAP-AKA, and PEAP 10 draft-ietf-emu-eap-session-id-01.txt 12 Abstract 14 EAP Session-Id derivation has not been defined for EAP-SIM or EAP-AKA 15 when using the fast re-authentication exchange instead of full 16 authentication. This document updates RFC 5247 to define those 17 derivations for EAP-SIM and EAP-AKA. Since RFC5448bis defines the 18 Session-ID for EAP-AKA', the definition for EAP-AKA' is not included 19 here. RFC 5247 also does not define Session-Id derivation for PEAP. 20 A definition is given here which follows the definition for other 21 TLS-based EAP methods. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on April 4, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction ............................................. 4 64 1.1. Requirements Language ............................... 4 65 2. Updates to RFC 5247 Appendix A ........................... 5 66 2.1. EAP-AKA ............................................. 5 67 2.2. EAP-SIM ............................................. 5 68 2.3. Rationale ........................................... 7 69 2.4. Session-Id for PEAP ................................. 7 70 3. Security Considerations .................................. 7 71 4. IANA Considerations ...................................... 8 72 5. References ............................................... 8 73 5.1. Normative References ................................ 8 74 5.2. Informative References .............................. 8 76 1. Introduction 78 EAP [RFC3748] Session-Id derivation has not been defined for EAP-SIM 79 and EAP-AKA when using the fast re-authentication exchange instead of 80 full authentication. [RFC5247] defines the Session-Id for these EAP 81 methods, but that derivation is only applicable for the full 82 authentication case. The Session-Id derivation was not defined for 83 EAP-AKA', but [AKAP] now defines it, along with other updates. As 84 such, the definition for EAP-AKA' is not included here. 86 The IEEE is defining FILS authentication [FILS], which needs the EAP 87 Session-Id for in order for the EAP Re-authentication Protocol (ERP) 88 [RFC5296] to work, it would be important to get this resolved with a 89 clearly defined and agreed derivation rules to allow fast re- 90 authentication cases to be used to derive ERP key hierarchy. 92 Further, [RFC5247] did not define Session-Id for PEAP. We correct 93 that deficiency here. 95 1.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 2. Updates to RFC 5247 Appendix A 105 This section updates [RFC5247] Appendix A to define Session-Id for 106 fast re-authentication exchange for EAP-AKA and EAP-SIM. It further 107 defines Session-ID derivation for PEAP. 109 2.1. EAP-AKA 111 For EAP-AKA, [RFC5247] Appendix A says: 113 EAP-AKA 115 EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the 116 concatenation of the EAP Type Code (0x17) with the contents of the 117 RAND field from the AT_RAND attribute, followed by the contents of 118 the AUTN field in the AT_AUTN attribute: 120 Session-Id = 0x17 || RAND || AUTN 122 It should say: 124 EAP-AKA 126 EAP-AKA is defined in [RFC4187]. When using full authentication, 127 the EAP-AKA Session-Id is the concatenation of the EAP Type Code 128 (0x17) with the contents of the RAND field from the AT_RAND 129 attribute, followed by the contents of the AUTN field in the 130 AT_AUTN attribute: 132 Session-Id = 0x17 || RAND || AUTN 134 When using fast re-authentication, the EAP-AKA Session-Id is the 135 concatenation of the EAP Type Code (0x17) with the contents of the 136 NONCE_S field from the AT_NONCE_S attribute, followed by the 137 contents of the MAC field from the AT_MAC attribute from EAP- 138 Request/AKA-Reauthentication: 140 Session-Id = 0x17 || NONCE_S || MAC 142 2.2. EAP-SIM 144 Similarly for EAP-SIM, it says: 146 EAP-SIM 148 EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the 149 concatenation of the EAP Type Code (0x12) with the contents of the 150 RAND field from the AT_RAND attribute, followed by the contents of 151 the NONCE_MT field in the AT_NONCE_MT attribute: 153 Session-Id = 0x12 || RAND || NONCE_MT 155 The Peer-Id is the contents of the Identity field from the 156 AT_IDENTITY attribute, using only the Actual Identity Length 157 octets from the beginning, however. Note that the contents are 158 used as they are transmitted, regardless of whether the 159 transmitted identity was a permanent, pseudonym, or fast EAP re- 160 authentication identity. The Server-Id is the null string (zero 161 length). 163 It should say: 165 EAP-SIM 167 EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the 168 concatenation of the EAP Type Code (0x12) with the contents of the 169 RAND field from the AT_RAND attribute, followed by the contents of 170 the NONCE_MT field in the AT_NONCE_MT attribute. RFC 4186 says 171 that EAP server should obtain "n" GSM triplets where "n=2" or 172 "n=3". 174 For "n=2", the Session-Id is therefore defined as 176 Session-Id = 0x12 || RAND1 || RAND2 || NONCE_MT 178 which is 49 octets in length. 180 For "n=3", the Session-Id is therefore defined as 182 Session-Id = 0x12 || RAND1 || RAND2 || RAND3 || NONCE_MT 184 which is 65 octets in length. 186 The Peer-Id is the contents of the Identity field from the 187 AT_IDENTITY attribute, using only the Actual Identity Length 188 octets from the beginning, however. Note that the contents are 189 used as they are transmitted, regardless of whether the 190 transmitted identity was a permanent, pseudonym, or fast EAP re- 191 authentication identity. The Server-Id is the null string (zero 192 length). 194 When using fast re-authentication, the EAP-SIM Session-Id is the 195 concatenation of the EAP Type Code (0x12) with the contents of the 196 NONCE_S field from the AT_NONCE_S attribute, followed by the 197 contents of the MAC field from the AT_MAC attribute from EAP- 198 Request/AKA-Reauthentication: 200 Session-Id = 0x12 || NONCE_S || MAC 202 which is 33 octets in length. 204 2.3. Rationale 206 [RFC5247] was supposed to define exported parameters for existing EAP 207 methods in Appendix A. The way Session-Id was defined for EAP-AKA and 208 EAP-SIM works only for the full authentication case, i.e., it cannot 209 be used when the optional fast re-authentication case is used since 210 the used parameters (RAND, AUTN, NONCE_MT) are not used in the fast 211 re-authentication case. Based on [RFC4187] Section 5.2, and similar 212 text in [RFC4186], NONCE_S corresponds to RAND and MAC in EAP- 213 Request/AKA-Reauthentication corresponds to AUTN. That would seem to 214 imply that the Session-Id could be defined using NONCE_S and MAC 215 instead of RAND and AUTN/NONCE_MT. 217 2.4. Session-Id for PEAP 219 [RFC5247] did not define Session-Id definition for Microsoft's 220 Protected EAP (PEAP). Similar to the definition in [RFC5216] Section 221 2.3, we define it as: 223 Session-Id = 0x19 || client.random || server.random 225 This definition is already in wide-spread use in multiple PEAP 226 implementations. 228 Note that this definition for Session-Id only applies when TLS 1.2 is 229 used. A different derivation is defined for TLS 1.3. 231 3. 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 re-authentication with EAP-SIM and EAP-AKA. 237 There are no known security issues from using the NONCE_S and MAC as 238 defined above. 240 This specification also defines the EAP Session-Id for PEAP. That 241 derivation has no known security issues. 243 4. IANA Considerations 245 There are no actions for IANA. RFC EDITOR: This section may be 246 removed before publication. 248 5. References 250 5.1. Normative References 252 [RFC2119] 253 Bradner, S., "Key words for use in RFCs to Indicate Requirement 254 Levels", RFC 2119, March, 1997, . 257 [RFC3748] 258 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 259 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 260 June 2004. 262 [RFC5216] 263 Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication 264 Protocol", RFC 5216, March 2008 266 [RFC5247] 267 Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication 268 Protocol (EAP) Key Management Framework", RFC 5247, August 2008, 270 [RFC5296] 271 Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 272 authentication Protocol (ERP)", RFC 5296, August 2008. 274 [RFC8174] 275 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key 276 Words", RFC 8174, May 2017, . 279 [FILS] 280 "IEEE Standard for Information technology--Telecommunications and 281 information exchange between systems Local and metropolitan area 282 networks--Specific requirements - Part 11: Wireless LAN Medium 283 Access Control (MAC) and Physical Layer (PHY) Specifications - 284 Amendment 1: Fast Initial Link Setup", IEEE Std 802.11ai-2016, 285 2016. 287 5.2. Informative References 289 [RFC4186] 290 Haverinen, H. (Ed), Salowey, J., "Extensible Authentication 291 Protocol Method for Global System for Mobile Communications (GSM) 292 Subscriber Identity Modules (EAP-SIM)", RFC 4186, January 2006. 294 [RFC4187] 295 Arkko, J., Haverinen, H., "Extensible Authentication Protocol 296 Method for 3rd Generation Authentication and Key Agreement (EAP- 297 AKA)", RFC 4187, January 2006. 299 [AKAP] 300 Arkko, J., et al, "Improved Extensible Authentication Protocol 301 Method for 3rd Generation Authentication and Key Agreement (EAP- 302 AKA')", draft-arkko-eap-rfc5448bis-04.txt, January 2019. 304 Acknowledgments 306 The issue corrected in this specification was first reported by Jouni 307 Malinen in a technical errata at https://www.rfc- 308 editor.org/errata_search.php?rfc=5247 310 The text in this document follows Jouni's suggestions. 312 Authors' Addresses 314 Alan DeKok 315 The FreeRADIUS Server Project 317 Email: aland@freeradius.org