Network Working Group J. Arkko Internet-Draft Ericsson Updates: 3748,5247 (if approved) February 22, 2021 Intended status: Standards Track Expires: August 26, 2021 Extensible Authentication Protocol (EAP) Main Session Key draft-arkko-emu-main-session-key-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 and RFC 5247. 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 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. Arkko Expires August 26, 2021 [Page 1] Internet-Draft Main Session Key February 2021 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. EAP Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 6.2. Informative References . . . . . . . . . . . . . . . . . 5 Appendix A. Changes from RFC 3748 and RFC 5247 . . . . . . . . . 7 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 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 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 and RFC 5247. Note that other documents referring to these base documents are not updated, their updates can be provided when there is some other reason for the update. That is, the following documents are not updated at this time: RFC 6677, and RFC 7029 for the EAP framework [RFC3748] [RFC5247] [RFC6677] [RFC7029], RFC 5216 for EAP-TLS [RFC5216], RFC 5433 for EAP-GPSK [RFC5433], and RFC 4186, Arkko Expires August 26, 2021 [Page 2] Internet-Draft Main Session Key February 2021 RFC4187, RFC 5448, draft-ietf-emu-rfc5448bis for EAP-SIM, EAP-AKA and EAP-AKA' methods [RFC4186], [RFC4187] [RFC5448] [I-D.ietf-emu-rfc5448bis], RFC 6630 and RFC 6696 for ERP and ERP/ AAK [RFC6630] [RFC6696], or RFC 7170 for TEAP [RFC7170]. 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. 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". Arkko Expires August 26, 2021 [Page 3] Internet-Draft Main Session Key February 2021 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. 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. 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. Security Considerations There are no security issues in this specification, beyond those already discussed in the relevant original RFCs. Arkko Expires August 26, 2021 [Page 4] Internet-Draft Main Session Key February 2021 5. IANA Considerations There are no IANA considerations or requests for changes. 6. References 6.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, . [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, DOI 10.17487/RFC5247, August 2008, . 6.2. Informative References [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, . [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, . [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, . Arkko Expires August 26, 2021 [Page 5] Internet-Draft Main Session Key February 2021 [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, . [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. [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. Arkko Expires August 26, 2021 [Page 6] Internet-Draft Main Session Key February 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. Appendix A. 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. 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 7]