Skip to main content

EAP Session-Id Derivation for EAP-SIM, EAP-AKA, and PEAP
draft-ietf-emu-eap-session-id-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8940.
Author Alan DeKok
Last updated 2020-05-27 (Latest revision 2020-05-14)
Replaces draft-dekok-emu-eap-session-id
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Associated WG milestone
Nov 2019
WG last call on definition of session identifiers for fast re- authentication in EAP-SIM and EAP-AKA
Document shepherd Mohit Sethi
Shepherd write-up Show Last changed 2020-01-08
IESG IESG state Became RFC 8940 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Roman Danyliw
Send notices to Mohit Sethi <mohit.m.sethi@ericsson.com>
IANA IANA review state IANA OK - No Actions Needed
draft-ietf-emu-eap-session-id-03
Network Working Group                                        DeKok, Alan
INTERNET-DRAFT                                                FreeRADIUS
Updates: 5247
Category: Standards Track
<draft-ietf-emu-eap-session-id-03.txt>
14 May 2020

        EAP Session-Id Derivation for EAP-SIM, EAP-AKA, and PEAP
                  draft-ietf-emu-eap-session-id-03.txt

Abstract

   EAP Session-Id derivation has not been defined for EAP-SIM or EAP-AKA
   when using the fast re-authentication exchange instead of full
   authentication.  This document updates RFC 5247 to define those
   derivations for EAP-SIM and EAP-AKA.  RFC 5247 also does not define
   Session-Id derivation for PEAP.  A definition is given here which
   follows the definition for other TLS-based EAP methods.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 14, 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

DeKok, Alan                 Proposed Standard                   [Page 1]
INTERNET-DRAFT          EAP Session-ID Derivation            14 May 2020

   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.

DeKok, Alan                 Proposed Standard                   [Page 2]
INTERNET-DRAFT          EAP Session-ID Derivation            14 May 2020

Table of Contents

1.  Introduction .............................................    4
   1.1.  Requirements Language ...............................    4
2.  Updates to RFC 5247 Appendix A ...........................    5
   2.1.  EAP-AKA .............................................    5
   2.2.  EAP-SIM .............................................    5
   2.3.  Rationale ...........................................    7
   2.4.  Session-Id for PEAP .................................    7
3.  Security Considerations ..................................    7
4.  IANA Considerations ......................................    8
5.  References ...............................................    8
   5.1.  Normative References ................................    8
   5.2.  Informative References ..............................    9

DeKok, Alan                 Proposed Standard                   [Page 3]
INTERNET-DRAFT          EAP Session-ID Derivation            14 May 2020

1.  Introduction

   EAP [RFC3748] Session-Id derivation has not been defined for EAP-SIM
   and EAP-AKA when using the fast re-authentication exchange instead of
   full authentication.  [RFC5247] 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.

   The IEEE is defining FILS authentication [FILS], which needs the EAP
   Session-Id in order for the EAP Re-authentication Protocol (ERP)
   [RFC6696] to work.  It is therefore important to address the existing
   deficiencies in the definition of EAP Session-Id.

   Further, [RFC5247] did not define Session-Id for PEAP. We correct
   these deficiencies here by updating [RFC5247] with the Session-Id
   derivation during fast-authentication exchange for EAP-SIM and EAP-
   AKA; and defining Session-Id derivation for PEAP.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

DeKok, Alan                 Proposed Standard                   [Page 4]
INTERNET-DRAFT          EAP Session-ID Derivation            14 May 2020

2.  Updates to RFC 5247 Appendix A

   This section updates [RFC5247] Appendix A to define Session-Id for
   fast re-authentication exchange for EAP-AKA and EAP-SIM.  It further
   defines Session-ID derivation for PEAP.

2.1.  EAP-AKA

   For EAP-AKA, [RFC5247] Appendix A says:

   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

   It should say:

   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 re-authentication, 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

2.2.  EAP-SIM

   Similarly for EAP-SIM, [RFC5247] Appendix A 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

DeKok, Alan                 Proposed Standard                   [Page 5]
INTERNET-DRAFT          EAP Session-ID Derivation            14 May 2020

      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

      The Peer-Id is the contents of the Identity field from the
      AT_IDENTITY attribute, using only the Actual Identity Length
      octets from the beginning, however.  Note that the contents are
      used as they are transmitted, regardless of whether the
      transmitted identity was a permanent, pseudonym, or fast EAP re-
      authentication identity.  The Server-Id is the null string (zero
      length).

   It should say:

   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 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.

      Where RAND1, RAND2 and RAND3 correspond to the RAND value from the
      first, second and third GSM triplet respectively.

      The Peer-Id is the contents of the Identity field from the
      AT_IDENTITY attribute, using only the Actual Identity Length
      octets from the beginning, however.  Note that the contents are
      used as they are transmitted, regardless of whether the
      transmitted identity was a permanent, pseudonym, or fast EAP re-
      authentication identity.  The Server-Id is the null string (zero
      length).

DeKok, Alan                 Proposed Standard                   [Page 6]
INTERNET-DRAFT          EAP Session-ID Derivation            14 May 2020

      When using fast re-authentication, 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/AKA-Reauthentication:

      Session-Id = 0x12 || NONCE_S || MAC

      which is 33 octets in length.

2.3.  Rationale

   [RFC5247] was supposed to define exported parameters for existing EAP
   methods in Appendix A. 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 re-authentication case is used since
   the used parameters (RAND, AUTN, NONCE_MT) are not used in the fast
   re-authentication case. Based on [RFC4187] Section 5.2, and similar
   text in [RFC4186], NONCE_S corresponds to RAND and MAC in EAP-
   Request/AKA-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.

2.4.  Session-Id for PEAP

   [RFC5247] did not define Session-Id definition for Microsoft's
   Protected EAP (PEAP).  Similar to the definition in [RFC5216] Section
   2.3, we define it as:

      Session-Id = 0x19 || client.random || server.random

   This definition is already in wide-spread use in multiple PEAP
   implementations.

   Note that this definition for Session-Id only applies when TLS 1.2 is
   used.  A different derivation is defined for TLS 1.3 in [TLS-EAP-
   TYPES].

3.  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 re-authentication with EAP-SIM and EAP-AKA.

   There are no known security issues from using the NONCE_S and MAC as
   defined above.

   This specification also defines the EAP Session-Id for PEAP.  That

DeKok, Alan                 Proposed Standard                   [Page 7]
INTERNET-DRAFT          EAP Session-ID Derivation            14 May 2020

   derivation has no known security issues.

   These updates to not modify the Security Considerations outlined in
   RFC5247.

4.  IANA Considerations

   There are no actions for IANA.  RFC EDITOR: This section may be
   removed before publication.

5.  References

5.1.  Normative References

[RFC2119]
     Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", RFC 2119, March, 1997,  <http://www.rfc-
     editor.org/info/rfc2119>.

[RFC3748]
     Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
     Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
     June 2004.

[RFC5216]
     Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication
     Protocol", RFC 5216, March 2008

[RFC5247]
     Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication
     Protocol (EAP) Key Management Framework", RFC 5247, August 2008,

[RFC6696]
     Cao, Z. et al, "EAP Extensions for EAP Re-authentication Protocol
     (ERP)", RFC 6696, July 2012.

[RFC8174]
     Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
     Words", RFC 8174, May 2017, <http://www.rfc-
     editor.org/info/rfc8174>.

[FILS]
     "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 Std 802.11ai-2016,
     2016.

DeKok, Alan                 Proposed Standard                   [Page 8]
INTERNET-DRAFT          EAP Session-ID Derivation            14 May 2020

5.2.  Informative References

[RFC4186]
     Haverinen, H. (Ed), Salowey, J., "Extensible Authentication
     Protocol Method for Global System for Mobile Communications (GSM)
     Subscriber Identity Modules (EAP-SIM)", RFC 4186, January 2006.

[RFC4187]
     Arkko, J., Haverinen, H., "Extensible Authentication Protocol
     Method for 3rd Generation Authentication and Key Agreement (EAP-
     AKA)", RFC 4187, January 2006.

[AKAP]
     Arkko, J., et al, "Improved Extensible Authentication Protocol
     Method for 3rd Generation Authentication and Key Agreement (EAP-
     AKA')", draft-arkko-eap-rfc5448bis-06.txt, November 2019.

[TLS-EAP-TYPES]
     DeKok, A., "TLS-based EAP types and TLS 1.3" draft-dekok-emu-tls-
     eap-types-00, February 2019.

Acknowledgments

   The issue corrected in this specification was first reported by Jouni
   Malinen in a technical errata at https://www.rfc-
   editor.org/errata_search.php?rfc=5247

   The text in this document follows Jouni's suggestions.

Authors' Addresses

   Alan DeKok
   The FreeRADIUS Server Project

   Email: aland@freeradius.org

DeKok, Alan                 Proposed Standard                   [Page 9]