idnits 2.17.1 draft-ietf-emu-eap-session-id-02.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 (7 January 2020) is 1542 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' -- Unexpected draft version: The latest known version of draft-arkko-eap-rfc5448bis is -01, but you're referring to -06. == Outdated reference: A later version (-02) exists of draft-dekok-emu-tls-eap-types-00 Summary: 0 errors (**), 0 flaws (~~), 3 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 7 January 2020 9 EAP Session-Id Derivation for EAP-SIM, EAP-AKA, and PEAP 10 draft-ietf-emu-eap-session-id-02.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. RFC 5247 also does not define 18 Session-Id derivation for PEAP. A definition is given here which 19 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 July 7, 2020. 44 Copyright Notice 46 Copyright (c) 2019 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 ........................................... 7 67 2.4. Session-Id for PEAP ................................. 7 68 3. Security Considerations .................................. 7 69 4. IANA Considerations ...................................... 8 70 5. References ............................................... 8 71 5.1. Normative References ................................ 8 72 5.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 re-authentication exchange instead of 78 full 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 The IEEE is defining FILS authentication [FILS], which needs the EAP 85 Session-Id for in order for the EAP Re-authentication Protocol (ERP) 86 [RFC6696] to work, it would be important to get this resolved with a 87 clearly defined and agreed derivation rules to allow fast re- 88 authentication cases to be used to derive ERP key hierarchy. 90 Further, [RFC5247] did not define Session-Id for PEAP. We correct 91 that deficiency here. 93 1.1. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in BCP 98 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 2. Updates to RFC 5247 Appendix A 103 This section updates [RFC5247] Appendix A to define Session-Id for 104 fast re-authentication exchange for EAP-AKA and EAP-SIM. It further 105 defines Session-ID derivation for PEAP. 107 2.1. EAP-AKA 109 For EAP-AKA, [RFC5247] Appendix A says: 111 EAP-AKA 113 EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the 114 concatenation of the EAP Type Code (0x17) with the contents of the 115 RAND field from the AT_RAND attribute, followed by the contents of 116 the AUTN field in the AT_AUTN attribute: 118 Session-Id = 0x17 || RAND || AUTN 120 It should say: 122 EAP-AKA 124 EAP-AKA is defined in [RFC4187]. When using full authentication, 125 the EAP-AKA Session-Id is the concatenation of the EAP Type Code 126 (0x17) with the contents of the RAND field from the AT_RAND 127 attribute, followed by the contents of the AUTN field in the 128 AT_AUTN attribute: 130 Session-Id = 0x17 || RAND || AUTN 132 When using fast re-authentication, the EAP-AKA Session-Id is the 133 concatenation of the EAP Type Code (0x17) with the contents of the 134 NONCE_S field from the AT_NONCE_S attribute, followed by the 135 contents of the MAC field from the AT_MAC attribute from EAP- 136 Request/AKA-Reauthentication: 138 Session-Id = 0x17 || NONCE_S || MAC 140 2.2. EAP-SIM 142 Similarly for EAP-SIM, it says: 144 EAP-SIM 146 EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the 147 concatenation of the EAP Type Code (0x12) with the contents of the 148 RAND field from the AT_RAND attribute, followed by the contents of 149 the NONCE_MT field in the AT_NONCE_MT attribute: 151 Session-Id = 0x12 || RAND || NONCE_MT 153 The Peer-Id is the contents of the Identity field from the 154 AT_IDENTITY attribute, using only the Actual Identity Length 155 octets from the beginning, however. Note that the contents are 156 used as they are transmitted, regardless of whether the 157 transmitted identity was a permanent, pseudonym, or fast EAP re- 158 authentication identity. The Server-Id is the null string (zero 159 length). 161 It should say: 163 EAP-SIM 165 EAP-SIM is defined in [RFC4186]. The EAP-SIM Session-Id is the 166 concatenation of the EAP Type Code (0x12) with the contents of the 167 RAND field from the AT_RAND attribute, followed by the contents of 168 the NONCE_MT field in the AT_NONCE_MT attribute. RFC 4186 says 169 that EAP server should obtain "n" GSM triplets where "n=2" or 170 "n=3". 172 For "n=2", the Session-Id is therefore defined as 174 Session-Id = 0x12 || RAND1 || RAND2 || NONCE_MT 176 which is 49 octets in length. 178 For "n=3", the Session-Id is therefore defined as 180 Session-Id = 0x12 || RAND1 || RAND2 || RAND3 || NONCE_MT 182 which is 65 octets in length. 184 The Peer-Id is the contents of the Identity field from the 185 AT_IDENTITY attribute, using only the Actual Identity Length 186 octets from the beginning, however. Note that the contents are 187 used as they are transmitted, regardless of whether the 188 transmitted identity was a permanent, pseudonym, or fast EAP re- 189 authentication identity. The Server-Id is the null string (zero 190 length). 192 When using fast re-authentication, the EAP-SIM Session-Id is the 193 concatenation of the EAP Type Code (0x12) with the contents of the 194 NONCE_S field from the AT_NONCE_S attribute, followed by the 195 contents of the MAC field from the AT_MAC attribute from EAP- 196 Request/AKA-Reauthentication: 198 Session-Id = 0x12 || NONCE_S || MAC 200 which is 33 octets in length. 202 2.3. Rationale 204 [RFC5247] was supposed to define exported parameters for existing EAP 205 methods in Appendix A. The way Session-Id was defined for EAP-AKA and 206 EAP-SIM works only for the full authentication case, i.e., it cannot 207 be used when the optional fast re-authentication case is used since 208 the used parameters (RAND, AUTN, NONCE_MT) are not used in the fast 209 re-authentication case. Based on [RFC4187] Section 5.2, and similar 210 text in [RFC4186], NONCE_S corresponds to RAND and MAC in EAP- 211 Request/AKA-Reauthentication corresponds to AUTN. That would seem to 212 imply that the Session-Id could be defined using NONCE_S and MAC 213 instead of RAND and AUTN/NONCE_MT. 215 2.4. Session-Id for PEAP 217 [RFC5247] did not define Session-Id definition for Microsoft's 218 Protected EAP (PEAP). Similar to the definition in [RFC5216] Section 219 2.3, we define it as: 221 Session-Id = 0x19 || client.random || server.random 223 This definition is already in wide-spread use in multiple PEAP 224 implementations. 226 Note that this definition for Session-Id only applies when TLS 1.2 is 227 used. A different derivation is defined for TLS 1.3 in [TLS-EAP- 228 TYPES]. 230 3. Security Considerations 232 This specification defines EAP Session-Ids for ERP with EAP-SIM and 233 EAP-AKA. It therefore enables ERP key hierarchy establishment using 234 fast re-authentication with EAP-SIM and EAP-AKA. 236 There are no known security issues from using the NONCE_S and MAC as 237 defined above. 239 This specification also defines the EAP Session-Id for PEAP. That 240 derivation has no known security issues. 242 4. IANA Considerations 244 There are no actions for IANA. RFC EDITOR: This section may be 245 removed before publication. 247 5. References 249 5.1. Normative References 251 [RFC2119] 252 Bradner, S., "Key words for use in RFCs to Indicate Requirement 253 Levels", RFC 2119, March, 1997, . 256 [RFC3748] 257 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 258 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 259 June 2004. 261 [RFC5216] 262 Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication 263 Protocol", RFC 5216, March 2008 265 [RFC5247] 266 Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication 267 Protocol (EAP) Key Management Framework", RFC 5247, August 2008, 269 [RFC6696] 270 Cao, Z. et al, "EAP Extensions for EAP Re-authentication Protocol 271 (ERP)", RFC 6696, July 2012. 273 [RFC8174] 274 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key 275 Words", RFC 8174, May 2017, . 278 [FILS] 279 "IEEE Standard for Information technology--Telecommunications and 280 information exchange between systems Local and metropolitan area 281 networks--Specific requirements - Part 11: Wireless LAN Medium 282 Access Control (MAC) and Physical Layer (PHY) Specifications - 283 Amendment 1: Fast Initial Link Setup", IEEE Std 802.11ai-2016, 284 2016. 286 5.2. Informative References 288 [RFC4186] 289 Haverinen, H. (Ed), Salowey, J., "Extensible Authentication 290 Protocol Method for Global System for Mobile Communications (GSM) 291 Subscriber Identity Modules (EAP-SIM)", RFC 4186, January 2006. 293 [RFC4187] 294 Arkko, J., Haverinen, H., "Extensible Authentication Protocol 295 Method for 3rd Generation Authentication and Key Agreement (EAP- 296 AKA)", RFC 4187, January 2006. 298 [AKAP] 299 Arkko, J., et al, "Improved Extensible Authentication Protocol 300 Method for 3rd Generation Authentication and Key Agreement (EAP- 301 AKA')", draft-arkko-eap-rfc5448bis-06.txt, November 2019. 303 [TLS-EAP-TYPES] 304 DeKok, A., "TLS-based EAP types and TLS 1.3" draft-dekok-emu-tls- 305 eap-types-00, February 2019. 307 Acknowledgments 309 The issue corrected in this specification was first reported by Jouni 310 Malinen in a technical errata at https://www.rfc- 311 editor.org/errata_search.php?rfc=5247 313 The text in this document follows Jouni's suggestions. 315 Authors' Addresses 317 Alan DeKok 318 The FreeRADIUS Server Project 320 Email: aland@freeradius.org