RFC 8940

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)

📅 published October 2020, from ietf

Abstract ✨

okay bestie, RFC 8940 is the update that cleans up EAP Session-Id 💖

Quick facts first 🎀: this is an IETF document (the Internet Engineering Task Force, the crew that writes the Internet's rulebook 🌸), written by A. DeKok at FreeRADIUS, dated October 2020. It's a Standards Track document with ISSN 2070-1721, and it updates RFC 5247. That's the only thing it updates. It's titled 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) 🦋

So the abstract basically says: RFC 5247 gets an update to define and clarify how the EAP Session-Id is derived for several EAP methods 🔥. Right now the Session-Id derivation is missing for EAP-SIM and EAP-AKA when they use fast reconnect instead of full authentication 😭. The full authentication derivation is also clarified for both of them. And the PEAP derivation finally gets written down, following the same pattern as the other TLS-based EAP methods ✨

Status of This Memo 📜

This is an Internet Standards Track document, no cap 💅

It's a product of the IETF and represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ If you want more on Internet Standards, check Section 2 of RFC 7841 🌈

Info about its current status, any errata, and how to send feedback lives 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) as they're in effect on the date this document was published 🌸 Please read these carefully, because they spell out your rights and restrictions for 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 they come without warranty, as described in the Simplified BSD License 💖

Table of Contents 📚

   1.  Introduction
   2.  Updates to RFC 5247, Appendix A
     2.1.  EAP-AKA
     2.2.  EAP-SIM
     2.3.  Rationale for EAP-AKA and EAP-SIM Updates
   3.  Session-Id for PEAP
   4.  Security Considerations
   5.  IANA Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Acknowledgments
   Author's Address

1. Introduction ✨

Okay so the big picture 🧚 The EAP [RFC3748] Session-Id derivation was never defined for EAP-SIM and EAP-AKA when they use fast reconnect instead of full authentication 😭 [RFC5247] does define Session-Id for these methods, but that definition only works for the full authentication case.

The Session-Id derivation wasn't defined for EAP-AKA' either, but [AKAP] now defines it, along with some other updates 🦋 So the EAP-AKA' definition isn't included here.

The full authentication derivation also gets clarified, because the text in [RFC5247] is ambiguous 🙈

Here's why this matters. The IEEE's Fast Initial Link Setup (FILS) authentication [FILS] needs the EAP Session-Id so that the EAP Re-authentication Protocol (ERP) [RFC6696] can work 🔥 That makes fixing these deficiencies in the EAP Session-Id definition super important 👑

Last but not least, [RFC5247] never defined a Session-Id for PEAP [MS-PEAP] [PEAP] 💀 So this document fixes all of it. It updates [RFC5247] with the Session-Id derivation during fast reconnect for EAP-SIM and EAP-AKA, clarifies the Session-Id derivation during full authentication for both, and defines the Session-Id derivation for PEAP. The PEAP one is the same for full authentication and fast reconnect 🎀

2. Updates to RFC 5247, Appendix A 💅

In this section, we update [RFC5247], Appendix A so that it defines Session-Id for the fast reconnect exchange for EAP-AKA and EAP-SIM 🌈

2.1. EAP-AKA 🌸

So for EAP-AKA, [RFC5247], Appendix A currently says this:

   |  EAP-AKA
   |     EAP-AKA is defined in [RFC4187].  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

And it should say this instead 🦋

   |  EAP-AKA
   |     EAP-AKA is defined in [RFC4187].  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:
   |
   |        Session-Id = 0x17 || RAND || AUTN
   |
   |     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:
   |
   |        Session-Id = 0x17 || NONCE_S || MAC

So the new version splits things into two cases 🫶 Full authentication keeps the RAND and AUTN version, and fast reconnect uses NONCE_S and MAC 💖

2.2. EAP-SIM 🌷

EAP-SIM is pretty much the same story 💅 [RFC5247], Appendix A currently says:

   |  EAP-SIM
   |     EAP-SIM is defined in [RFC4186].  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:
   |
   |        Session-Id = 0x12 || RAND || NONCE_MT

And it should say this 🎀

   |  EAP-SIM
   |     EAP-SIM is defined in [RFC4186].  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
   |
   |        Session-Id = 0x12 || RAND1 || RAND2 || NONCE_MT
   |
   |     which is 49 octets in length.
   |
   |     For "n=3", the Session-Id is therefore defined as
   |
   |        Session-Id = 0x12 || RAND1 || RAND2 || RAND3 || NONCE_MT
   |
   |     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:
   |
   |        Session-Id = 0x12 || NONCE_S || MAC
   |
   |     which is 33 octets in length.

So for full auth, the spec now walks through both "n=2" (49 octets) and "n=3" (65 octets) cases 🔥 And fast reconnect gets its own 33-octet version using NONCE_S and MAC 🌈

2.3. Rationale for EAP-AKA and EAP-SIM Updates 🧠

Okay, the why 🍓 Appendix A of [RFC5247] was supposed to define exported parameters for existing EAP methods. But the way Session-Id was defined for EAP-AKA and EAP-SIM only works for full authentication. It can't be used when the optional fast reconnect case is in play, because the parameters it relies on (RAND, AUTN, NONCE_MT) aren't used in fast reconnect at all 😭

Looking at [RFC4187], Section 5.2 and the similar text in [RFC4186], Section 5.2, NONCE_S lines up with RAND and MAC in EAP-Request/AKA-Reauthentication, and EAP-Request/SIM/Reauthentication lines up with AUTN. So it seems like the Session-Id could be defined using NONCE_S and MAC instead of RAND and AUTN/NONCE_MT 👀

This derivation runs off a random value created by the server, plus a secret key and the peer's identity 🔐 We believe it's secure, though no formal analysis has been done yet 🙈

(continued in part 2 🦋 — Section 3, Session-Id for PEAP, is up next 💜)

6.2. Informative References 🎀

okay bestie, these are the extra reading picks 📚💅 they're informative, so they add context rather than set rules 🧚

Acknowledgments ✨

the bug squashed in this spec was first spotted by Jouni Malinen, who reported it as a technical erratum for RFC 5247 [Err5011] 🙌

the wording in this document follows Jouni's suggestions 💜

Author's Address 🌸

Alan DeKok

The FreeRADIUS Server Project

Email: aland@freeradius.org

📦 where this page comes from