Extensible Authentication
Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module
(EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected
EAP (PEAP)
The FreeRADIUS Server Project
aland@freeradius.org
EAP
PEAP
EAP-AKA
EAP-SIM
ERP
FILS
Session-ID
fast reconnect
TLS
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.
Introduction
EAP Session-Id derivation has not
been defined for EAP-SIM and EAP-AKA when using the fast reconnect exchange
instead of full authentication.
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 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 is
ambiguous.
The IEEE has defined Fast Initial Link Setup (FILS) authentication , which needs the EAP Session-Id in order
for the EAP Re-authentication Protocol (ERP) to work. It is therefore important to address the
existing deficiencies in the definition of EAP Session-Id.
Finally, did not define
Session-Id for PEAP . We correct
these deficiencies here by updating 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.
Updates to RFC 5247, Appendix A
This section updates to define Session-Id for fast reconnect exchange for EAP-AKA and
EAP-SIM.
EAP-AKA
For EAP-AKA, says:
- EAP-AKA
-
EAP-AKA is defined in . The EAP-AKA Session-Id is the concatenation of
the EAP Type Code (0x17) with the contents of the RAND field from
the AT_RAND attribute, followed by the contents of the AUTN field in
the AT_AUTN attribute:
Session-Id = 0x17 || RAND || AUTN
It should say:
- EAP-AKA
-
EAP-AKA is defined in . When using full
authentication, the EAP-AKA Session-Id is the concatenation of the EAP
Type Code (0x17) with the contents of the RAND field from the AT_RAND
attribute, followed by the contents of the AUTN field in the AT_AUTN
attribute:
When using fast reconnect, the EAP-AKA Session-Id is the
concatenation of the EAP Type Code (0x17) with the contents of the
NONCE_S field from the AT_NONCE_S attribute, followed by the contents
of the MAC field from the AT_MAC attribute from
EAP-Request/AKA-Reauthentication:
EAP-SIM
Similarly for EAP-SIM, says:
- EAP-SIM
-
EAP-SIM is defined in . The EAP-SIM
Session-Id is the concatenation of the EAP Type Code (0x12) with the
contents of the RAND field from the AT_RAND attribute, followed by the
contents of the NONCE_MT field in the AT_NONCE_MT attribute:
It should say:
- EAP-SIM
-
EAP-SIM is defined in .
When using full authentication, the EAP-SIM Session-Id is the
concatenation of the EAP Type Code (0x12) with the contents of the
RAND field from the AT_RAND attribute, followed by the contents of
the NONCE_MT field in the AT_NONCE_MT attribute.
RFC 4186 says that the EAP server should obtain "n" GSM
triplets where "n=2" or "n=3".
For "n=2", the Session-Id is therefore defined as
which is 49 octets in length.
For "n=3", the Session-Id is therefore defined as
which is 65 octets in length.
RAND1, RAND2, and RAND3 correspond to the RAND value from the
first, second, and third GSM triplet, respectively.
When using fast reconnect, the EAP-SIM Session-Id is the
concatenation of the EAP Type Code (0x12) with the contents of the
NONCE_S field from the AT_NONCE_S attribute, followed by the contents
of the MAC field from the AT_MAC attribute from
EAP-Request/SIM/Reauthentication:
which is 33 octets in length.
Rationale for EAP-AKA and EAP-SIM Updates
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
and similar text in
, 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.
Session-Id for PEAP
did not define Session-Id for Microsoft's
Protected EAP (PEAP). For consistency with the EAP-TLS definition given in
, 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
.
Security Considerations
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 .
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
.
IANA Considerations
This document has no IANA actions.
References
Normative References
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
IEEE
Informative References
[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)
Microsoft
Erratum ID 5011
RFC Errata
RFC 5247
Acknowledgments
The issue corrected in this specification was first reported by in a technical erratum for RFC 5247 .
The text in this document follows Jouni's suggestions.