Network Working Group J. Arkko Internet-Draft Ericsson Updates: 3748,4186,4187,5216,5247,5433,5 February 22, 2021 448,6630,6677,6696,7029,7170 (if approved) Intended status: Standards Track Expires: August 26, 2021 Extensible Authentication Protocol (EAP) Main Session Key draft-arkko-emu-main-session-key-all-00 Abstract This document updates the terms that are used for referring to some keys in the Extensible Authentication Protocol (EAP). This document updates RFC 3748, RFC 5247, RFC 6677, and RFC 7029 for the EAP framework, RFC 5216 for EAP-TLS, RFC 5433 for EAP-GPSK, RFC 4186, RFC 4187 and RFC 5448 for EAP-SIM, EAP-AKA and EAP-AKA' methods, RFC 6630 and RFC 6696 for ERP and ERP/AAK, and RFC 7170 for TEAP. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 26, 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Arkko Expires August 26, 2021 [Page 1] Internet-Draft Main Session Key February 2021 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. EAP Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 4. EAP-TLS Terminology . . . . . . . . . . . . . . . . . . . . . 5 5. EAP-SIM, EAP-AKA and EAP-AKA' Terminology . . . . . . . . . . 5 6. EAP-GPSK Terminology . . . . . . . . . . . . . . . . . . . . 5 7. ERP Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 8. TEAP Terminology . . . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 11.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Changes from previous RFCs . . . . . . . . . . . . . 9 A.1. Changes from RFC 3748 and RFC 5247 . . . . . . . . . . . 9 A.2. Changes from RFC 6677 and RFC 7029 . . . . . . . . . . . 9 A.3. Changes from RFC 4186, RFC 4187 and RFC 5448 . . . . . . 9 A.4. Changes from RFC 5216 . . . . . . . . . . . . . . . . . . 9 A.5. Changes from RFC 5433 . . . . . . . . . . . . . . . . . . 9 A.6. Changes from RFC 6630 . . . . . . . . . . . . . . . . . . 9 A.7. Changes from RFC 6696 . . . . . . . . . . . . . . . . . . 9 A.8. Changes from RFC 7170 . . . . . . . . . . . . . . . . . . 10 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction [RFC3748] defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. This document is a modest proposal for a minor update of the terminology associated withe EAP. Specifically, the document updates the terms that are used for referring to certain keys in the protocol. While the author believes that the update is useful, it is by no means something that has to be done, but has been provided for the community's consideration as part of an overall interest in Arkko Expires August 26, 2021 [Page 2] Internet-Draft Main Session Key February 2021 maintaining the technology and its documentation. If we care about a technology we should keep it up to date. The author believes that it is preferable to have ongoing maintenance that addresses issues when they are identified, rather than waiting for a larger but more infrequent update. A rationale for this particular change is discussed in more detail in Section 2. This proposal is brought forward for discussion. Discussion may find that the proposal is considered useful or unnecessary, or perhaps even a distracton or flawed in some of its definitions. All feedback is welcome! Technically, this document updates RFC 3748, RFC 5247, RFC 6677, and RFC 7029 for the EAP framework [RFC3748] [RFC5247] [RFC6677] [RFC7029] (see Section 3), RFC 5216 for EAP-TLS [RFC5216] (see Section 4), RFC 5433 for EAP-GPSK [RFC5433] (see Section 6), and RFC 4186, RFC 4187, RFC 5448 for EAP-SIM, EAP-AKA and EAP-AKA' methods [RFC4186] [RFC4187] [RFC5448] [I-D.ietf-emu-rfc5448bis] (see Section 5), RFC 6630 and RFC 6696 for ERP and ERP/AAK [RFC6630] [RFC6696] (see Section 7), and RFC 7170 for TEAP [RFC7170] (see Section 8). 2. Rationale In 2020, the Internet Engineering Steering Group (IESG) noted that terminology used in IETF documents is important [IESG]. When the objective of an organization is to be inclusive and respectful, terminology can also have an effect. There are obvious challenges for creating good terminology for the parts of Internet technology currently under development, both in a technical sense and in our ability to agree what terms are inclusive. There are also difficult tradeoffs related to changing terminology for existing technology, or for spending valuable effort on terminology vs. other things. The author has worked for a long time with EAP technology, and continues to make contributions in this space. In the author's view, while there is no need for a change, some of the terms that are used when referring to various parts of the overall EAP technology could be improved. As a result, the author wanted to make a modest proposal for a change that would improve the terms without changing the associated acronyms, and enable better use of the terms in future documents. It should be noted that the issues with EAP terms are minor, compared many other terminology or other problems with Internet technology. The author does not wish to start a big debate; if the WG finds this useful, we can perhaps make an update and move on. If not, we can simply move on without making a change. Arkko Expires August 26, 2021 [Page 3] Internet-Draft Main Session Key February 2021 The specific change that is suggested in this document relates to the use of the word "master" in various EAP terms. This word is rather benign when compared to the use of master/slave or black/whitelists, and other similar terms. Indeed, "master" is commonly used in a large number of everyday terms. Given this, some authors and organizations have chosen to make updates only with the most egregious terms, such as master/slave. Nevertheless, at least the author of this document feels that he would use another word if a different word or term was available. It should be noted that: o The slavery-related meaning comes up in any dictionary search for the word "master". o The word "master" and some suggested alternatives (such as "main") are listed in [Terminology]. o Several organisations have recommended changing the word "master" in various aspects of their documentation or software. Others are considering changes. See, for instance, [W3C] [RedHat] [GitLab] [Mozilla]. In any case, as noted, this proposal is for the working group to discuss. Discussion may find that the proposal is considered useful, unnecessary, or flawed in some fashion. 3. EAP Terminology The definitions for MSK and EMSK from RFC 3748 and RFC 5247 are replaced as follows: Main Session Key (MSK) Keying material that is derived between the EAP peer and server and exported by the EAP method. The MSK is at least 64 octets in length. In existing implementations, a AAA server acting as an EAP server transports the MSK to the authenticator. Extended Main Session Key (EMSK) Additional keying material derived between the EAP client and server that is exported by the EAP method. The EMSK is at least 64 octets in length. The EMSK is not shared with the authenticator or any other third party. The EMSK is reserved for future uses that are not defined yet. Arkko Expires August 26, 2021 [Page 4] Internet-Draft Main Session Key February 2021 These terms were previously called Master Session Key and Extended Master Session Key. These terms are generally used throughout various EAP documents, such as the method specifications, so changes in these terms affect those documents as well. In addition, the use of these terms in RFC 6677 and RFC 7029 is changed to use the new names. Note that RFC 5247 discusses one additional key, the Pairwise Master Key (PMK), but as that is defined by IEEE, this document will not redefine it. 4. EAP-TLS Terminology The quantity main_secret is defined as follows: main_secret This value is derived as previously defined for master_secret, [RFC5216] Section 2.3. Note that the definition is still literally the same, including the use of the string "master secret" in the formula. Note that RFC 5216 discusses also the TLS terms master secret and premaster secret (called pre_master_secret in RFC 5216). but as those are defined by TLS documents [RFC5246], this document will not redefine them. 5. EAP-SIM, EAP-AKA and EAP-AKA' Terminology The definition for MK is replaced as follows: Main Key (MK) A Main Key is derived as specified for MK in the relevant RFC, either [RFC4186] Section 7, [RFC4187] Section 7 or [RFC5448] Section 3.3. This term was previously called Master Key. 6. EAP-GPSK Terminology The definition for MK in RFC 5433 is replaced as follows: Main Key (MK) A session-specific Main Key between the peer and EAP server from which all other EAP method session keys are derived (KS octets). Arkko Expires August 26, 2021 [Page 5] Internet-Draft Main Session Key February 2021 A Main Key is derived as specified for MK in the [RFC5433] Section 4, and KS is an integer representing the input key size as defined in [RFC5433] Section 2. This term was previously called Master Key. 7. ERP Terminology There are no ERP-specific terms that need to be redefined in RFC 6696. However, ERP uses general EAP terminology such as MSK and EMSK. In addition, ERP uses the string "Re-authentication Master Session Key@ietf.org" for calculating the re-authentication MSK or rMSK Label. This string cannot be changed, as changes would break interoperability. ERP/AAK... 8. TEAP Terminology There are no TEAP-specific terms that need to be redefined. However, TEAP uses general EAP terminology such as MSK and EMSK, as well as TLS terminology [RFC5246] such as master secret and premaster secret (called pre-master secret in RFC 7170). 9. Security Considerations There are no security issues in this specification, beyond those already discussed in the relevant original RFCs. 10. IANA Considerations There are no IANA considerations or requests for changes. 11. References 11.1. Normative References [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, . [RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006, . Arkko Expires August 26, 2021 [Page 6] Internet-Draft Main Session Key February 2021 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187, January 2006, . [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008, . [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, DOI 10.17487/RFC5247, August 2008, . [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", RFC 5433, DOI 10.17487/RFC5433, February 2009, . [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')", RFC 5448, DOI 10.17487/RFC5448, May 2009, . [RFC6630] Cao, Z., Deng, H., Wu, Q., and G. Zorn, Ed., "EAP Re- authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)", RFC 6630, DOI 10.17487/RFC6630, June 2012, . [RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel- Binding Support for Extensible Authentication Protocol (EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012, . [RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed., "EAP Extensions for the EAP Re-authentication Protocol (ERP)", RFC 6696, DOI 10.17487/RFC6696, July 2012, . [RFC7029] Hartman, S., Wasserman, M., and D. Zhang, "Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding", RFC 7029, DOI 10.17487/RFC7029, October 2013, . Arkko Expires August 26, 2021 [Page 7] Internet-Draft Main Session Key February 2021 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, . [I-D.ietf-emu-rfc5448bis] Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen, "Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP- AKA')", draft-ietf-emu-rfc5448bis-09 (work in progress), January 2021. 11.2. Informative References [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [IESG] IESG, , "IESG Statement On Oppressive or Exclusionary Language", IESG Statement https://www.ietf.org/about/groups/iesg/statements/ statement-on-oppressive-exclusionary-language/, July 2020. [Terminology] Alissa Cooper et al., , "Inclusive terminology in IETF Documents", Contribution under the IETF GitHub https://github.com/ietf/terminology, October 2020. [W3C] Le Hegaret, P. and C. Mercier, "W3C Manual of Style", W3C Document https://w3c.github.io/manual-of-style/, January 2021. [RedHat] Wright, C., "Making open source more inclusive by eradicating problematic language", RedHat Blog https://www.redhat.com/en/blog/making-open-source-more- inclusive-eradicating-problematic-language, January 2021. [GitLab] Ramsay, J., "Change the default initial branch name for new projects on GitLab", GitLab issue 221164 https://gitlab.com/gitlab-org/gitlab/-/issues/221164, June 2020. [Mozilla] Davidson, J., "Replace all user-facing instances that refer to "master" password", Mozilla Bug 1644807 https://bugzilla.mozilla.org/show_bug.cgi?id=1644807, November 2016. Arkko Expires August 26, 2021 [Page 8] Internet-Draft Main Session Key February 2021 Appendix A. Changes from previous RFCs A.1. Changes from RFC 3748 and RFC 5247 There are no changes with related to interoperability, or the protocol definitions. The only change is the names of the MSK and EMSK terms used to discuss and specify the protocol. A.2. Changes from RFC 6677 and RFC 7029 There are no changes with related to interoperability, protocol definitions, or terms. The only change is the use of the names of the MSK and EMSK terms used in these RFCs. A.3. Changes from RFC 4186, RFC 4187 and RFC 5448 There are no changes with related to interoperability, or the protocol definitions. The only change is the name of the MK term used to discuss and specify the protocols. In addition, the changes discussed in Appendix A.1 apply as well. A.4. Changes from RFC 5216 There are no changes with related to interoperability, or the protocol definitions. The only change is the name of the master_secret term used to discuss and specify the protocols. In addition, the changes discussed in Appendix A.1 apply as well. A.5. Changes from RFC 5433 There are no changes with related to interoperability, or the protocol definitions. The only change is the name of the master_secret term used to discuss and specify the protocols. In addition, the changes discussed in Appendix A.1 apply as well. A.6. Changes from RFC 6630 ... A.7. Changes from RFC 6696 There are no changes with related to interoperability, the protocol definitions, or even terms introduced specifically in RFC 7170. The only change is the changes discussed in Appendix A.1 that apply to RFC 7170 as well. Arkko Expires August 26, 2021 [Page 9] Internet-Draft Main Session Key February 2021 A.8. Changes from RFC 7170 There are no changes with related to interoperability, the protocol definitions, or even terms introduced specifically in RFC 7170. The only change is the changes discussed in Appendix A.1 that apply to RFC 7170 as well. Appendix B. Acknowledgements The authors would like to thank Stephen Hayes, Mohit Sethi, Alissa Cooper, and John Mattsson for englightening discussions and general contributions in this area. Author's Address Jari Arkko Ericsson Jorvas 02420 Finland Email: jari.arkko@piuha.net Arkko Expires August 26, 2021 [Page 10]