RFC 5247 is updated to define and clarify EAP Session-Id derivation for multiple Extensible Authentication Protocol (EAP) methods. The derivation of Session-Id was not given for EAP Subscriber Identity Module (EAP-SIM) or EAP Authentication and Key Agreement (EAP-AKA) when using the fast reconnect exchange instead of full authentication. The derivation of Session-Id for full authentication is clarified for both EAP-SIM and EAP-AKA. The derivation of Session-Id for Protected EAP (PEAP) is also given. The definition for PEAP follows the definition for other TLS-based EAP methods.

This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8940.

Copyright (c) 2020 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 (https://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.

EAP [RFC 3748] Session-Id derivation has not been defined for EAP-SIM and EAP-AKA when using the fast reconnect exchange instead of full authentication. [RFC 5247] defines the Session-Id for these EAP methods, but that derivation is only applicable for the full authentication case. The Session-Id derivation was not defined for EAP-AKA', but [AKAP] now defines it, along with other updates. As such, the definition for EAP-AKA' is not included here. Further, the derivation of Session-Id for full authentication is clarified, as the text in [RFC 5247] is ambiguous. The IEEE has defined Fast Initial Link Setup (FILS) authentication [FILS], which needs the EAP Session-Id in order for the EAP Re-authentication Protocol (ERP) [RFC 6696] to work. It is therefore important to address the existing deficiencies in the definition of EAP Session-Id. Finally, [RFC 5247] did not define Session-Id for PEAP [MS-PEAP] [PEAP]. We correct these deficiencies here by updating [RFC 5247] with the Session-Id derivation during fast-reconnect exchange for EAP-SIM and EAP-AKA; clarifying the Session-Id derivation during full authentication for EAP-SIM and EAP-AKA; and defining the Session-Id derivation for PEAP, which is the same for both full authentication and fast reconnect.

This section updates RFC 5247, Appendix A to define Session-Id for fast reconnect exchange for EAP-AKA and EAP-SIM.

For EAP-AKA, RFC 5247, Appendix A says:

---

---

It should say:

---

---

Similarly for EAP-SIM, RFC 5247, Appendix A says:

---

---

It should say:

---

---

Appendix A of RFC 5247 was supposed to define exported parameters for existing EAP methods. The way Session-Id was defined for EAP-AKA and EAP-SIM works only for the full authentication case, i.e., it cannot be used when the optional fast reconnect case is used since the used parameters (RAND, AUTN, NONCE_MT) are not used in the fast reconnect case. Based on RFC 4187, Section 5.2 and similar text in RFC 4186, Section 5.2, NONCE_S corresponds to RAND and MAC in EAP-Request/AKA-Reauthentication, and EAP-Request/SIM/Reauthentication corresponds to AUTN. That would seem to imply that the Session-Id could be defined using NONCE_S and MAC instead of RAND and AUTN/NONCE_MT. This derivation is done via a random value created by the server, along with a secret key and the peer's identity. We believe that this derivation is secure, though no formal analysis has been done.

[RFC 5247] did not define Session-Id for Microsoft's Protected EAP (PEAP). For consistency with the EAP-TLS definition given in RFC 5216, Section 2.3, we define it as: This definition is that same for both full authentication and for fast reconnect. This definition is already in widespread use in all known PEAP implementations. Note that this definition for Session-Id only applies when TLS 1.2 or earlier is used. A different derivation is defined for TLS 1.3 in [TLS-EAP-TYPES].

This specification defines EAP Session-Ids for ERP with EAP-SIM and EAP-AKA. It therefore enables ERP key hierarchy establishment using fast reconnect with EAP-SIM and EAP-AKA. The Session-Id definitions given here are unique per session, unforgeable, and unguessable by an outside party, as per the requirements of RFC 5247, Section 1. The definitions used here have been widely deployed for years in all major EAP implementations. However, we acknowledge that very little security analysis has been done for these definitions. As a result, any security issues would result in serious issues for the Internet as a whole. These updates do not modify the security considerations outlined in [RFC 5247].

This document has no IANA actions.

[FILS]

IEEE, "IEEE Standard for Information technology--Telecommunications and information exchange between systems - Local and metropolitan area networks--Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 1: Fast Initial Link Setup", DOI 10.1109/IEEESTD.2016.7792308, IEEE Std 802.11ai-2016, December 2016,
<https://doi.org/10.1109/IEEESTD.2016.7792308>.

[RFC3748]

B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>.

[RFC5216]

D. Simon, B. Aboba, and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008,
<https://www.rfc-editor.org/info/rfc5216>.

[RFC5247]

B. Aboba, D. Simon, and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, DOI 10.17487/RFC5247, August 2008,
<https://www.rfc-editor.org/info/rfc5247>.

[AKAP]

Independent, , , , and , "Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')", Internet-Draft draft-ietf-emu-rfc5448bis-07, March 2020,
<https://tools.ietf.org/html/draft-ietf-emu-rfc5448bis-07>.

[Err5011]

RFC Errata, "Erratum ID 5011",
<https://www.rfc-editor.org/errata/eid5011>.

[MS-PEAP]

Microsoft, "[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)",
<https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-peap/5308642b-90c9-4cc4-beec-fb367325c0f9>.

[PEAP]

Cisco Systems, A. Palekar, S. Josefsson, D. Simon, and G. Zorn, "Protected EAP Protocol (PEAP) Version 2", Internet-Draft draft-josefsson-pppext-eap-tls-eap-10, October 2004,
<https://tools.ietf.org/html/draft-josefsson-pppext-eap-tls-eap-10>.

[RFC4186]

H. Haverinen, and J. Salowey, "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006,
<https://www.rfc-editor.org/info/rfc4186>.

[RFC4187]

J. Arkko, and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187, January 2006,
<https://www.rfc-editor.org/info/rfc4187>.

[RFC6696]

Z. Cao, B. He, Y. Shi, Q. Wu, and G. Zorn, "EAP Extensions for the EAP Re-authentication Protocol (ERP)", RFC 6696, DOI 10.17487/RFC6696, July 2012,
<https://www.rfc-editor.org/info/rfc6696>.

[TLS-EAP-TYPES]

FreeRADIUS, , "TLS-based EAP types and TLS 1.3", Internet-Draft draft-ietf-emu-tls-eap-types-01, July 2020,
<https://tools.ietf.org/html/draft-ietf-emu-tls-eap-types-01>.

The issue corrected in this specification was first reported by Jouni Malinen in a technical erratum for RFC 5247 [Err5011]. The text in this document follows Jouni's suggestions.

Alan DeKok