<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="UTF-8"?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd" [ <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC3748 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3748.xml"> <!ENTITY RFC5216 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5216.xml"> <!ENTITY RFC5247 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5247.xml"> <!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY RFC4186 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4186.xml"> <!ENTITY RFC4187 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4187.xml"> <!ENTITY RFC6696 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6696.xml"> <!ENTITY I-D.ietf-emu-rfc5448bis SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-emu-rfc5448bis-07.xml"> <!ENTITY I-D.ietf-emu-rfc5448bis SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-emu-rfc5448bis.xml"> <!ENTITY I-D.dekok-emu-tls-eap-types SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.dekok-emu-tls-eap-types.xml"> <!ENTITY I-D.josefsson-pppext-eap-tls-eap SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.josefsson-pppext-eap-tls-eap.xml"> ]>"rfc2629-xhtml.ent"> <rfcsubmissionType="IETF"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-emu-eap-session-id-07.txt" number="8940" submissionType="IETF" category="std" consensus="true" updates="5247"ipr="trust200902"> <!-- Generated by id2xml 1.5.0 on 2020-09-08T23:13:04Z --> <?rfc strict="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc text-list-symbols="o*+-"?> <?rfc toc="yes"?>ipr="trust200902" obsoletes="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3"> <front> <title abbrev="EAP Session-IdDerivation">EAPDerivation">Extensible Authentication Protocol (EAP) Session-Id Derivation forEAP-SIM, EAP-AKA,EAP Subscriber Identity Module (EAP-SIM), EAP Authentication andPEAP</title>Key Agreement (EAP-AKA), and Protected EAP (PEAP)</title> <seriesInfo name="RFC" value="8940"/> <author initials="A." surname="DeKok" fullname="Alan DeKok"> <organization abbrev="FreeRADIUS">The FreeRADIUS Server Project</organization><address><email>aland@freeradius.org</email><address> <email>aland@freeradius.org</email> </address> </author> <date year="2020"month="September"/> <abstract><t>month="October"/> <keyword>EAP</keyword> <keyword>PEAP</keyword> <keyword>EAP-AKA</keyword> <keyword>EAP-SIM</keyword> <keyword>ERP</keyword> <keyword>FILS</keyword> <keyword>Session-ID</keyword> <keyword>fast reconnect</keyword> <keyword>TLS</keyword> <abstract> <t> RFC 5247 is updated to define andclarityclarify EAP Session-Id derivation for multipleEAPExtensible Authentication Protocol (EAP) methods. The derivation of Session-Id was not given forEAP-SIMEAP Subscriber Identity Module (EAP-SIM) orEAP-AKAEAP 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. Thederiviationderivation of Session-Id forPEAPProtected EAP (PEAP) is also given. The definition for PEAP follows the definition for other TLS-based EAP methods.</t> </abstract> </front> <middle> <sectiontitle="Introduction" anchor="sect-1"><t>anchor="sect-1" numbered="true" toc="default"> <name>Introduction</name> <t> EAP <xreftarget="RFC3748"/>target="RFC3748" format="default"/> Session-Id derivation has not been defined for EAP-SIM and EAP-AKA when using the fast reconnect exchange instead of full authentication. <xreftarget="RFC5247"/>target="RFC5247" format="default"/> 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 <xreftarget="I-D.ietf-emu-rfc5448bis"/>target="I-D.ietf-emu-rfc5448bis" format="default"/> now defines it, along with other updates. As such, the definition for EAP-AKA' is not included here.</t> <t> Further, thederiviationderivation of Session-Id for full authentication is clarified, as the text in <xreftarget="RFC5247"/>target="RFC5247" format="default"/> isambiguousl</t>ambiguous.</t> <t> The IEEE has defined Fast Initial Link Setup (FILS) authentication <xreftarget="FILS"/>,target="FILS" format="default"/>, which needs the EAP Session-Id in order for the EAP Re-authentication Protocol (ERP) <xreftarget="RFC6696"/>target="RFC6696" format="default"/> to work. It is therefore important to address the existing deficiencies in the definition of EAP Session-Id.</t> <t> Finally, <xreftarget="RFC5247"/>target="RFC5247" format="default"/> did not define Session-Id for PEAP <xreftarget="MS-PEAP"/>,target="MS-PEAP" format="default"/> <xreftarget="I-D.josefsson-pppext-eap-tls-eap"/>.target="I-D.josefsson-pppext-eap-tls-eap" format="default"/>. We correct these deficiencies here by updating <xreftarget="RFC5247"/>target="RFC5247" format="default"/> with the Session-Id derivation during fast-reconnect exchange for EAP-SIM and EAP-AKA;clarfyingclarifying the Session-Id derivation during full authentication for EAP-SIM and EAP-AKA; and defining the Session-Id derivation forPEAPPEAP, which is the same for both full authentication and fast reconnect.</t><section title="Requirements Language" anchor="sect-1.1"><t> 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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> </section></section> <sectiontitle="Updatesanchor="sect-2" numbered="true" toc="default"> <name>Updates to RFC52475247, AppendixA" anchor="sect-2"><t>A</name> <t> This section updates <xreftarget="RFC5247"/> Appendix Atarget="RFC5247" sectionFormat="comma" section="A"/> to define Session-Id for fast reconnect exchange for EAP-AKA and EAP-SIM.</t> <sectiontitle="EAP-AKA" anchor="sect-2.1"><t>anchor="sect-2.1" numbered="true" toc="default"> <name>EAP-AKA</name> <t> For EAP-AKA, <xreftarget="RFC5247"/> Appendix Atarget="RFC5247" sectionFormat="comma" section="A"/> says:</t> <blockquote> <dl newline="true"> <dt>EAP-AKA</dt> <dd> <t>EAP-AKA<list> <t> EAP-AKAis defined in <xreftarget="RFC4187"/>.target="RFC4187" format="default"/>. 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_AUTNattribute:</t> </list>attribute: </t><figure><artwork><![CDATA[<artwork> Session-Id = 0x17 || RAND || AUTN]]></artwork> </figure></artwork> </dd> </dl> </blockquote> <t>It should say:</t><t>EAP-AKA <list><blockquote> <dl newline="true"> <dt>EAP-AKA</dt> <dd> <t>EAP-AKA is defined in <xreftarget="RFC4187"/>.target="RFC4187" format="default"/>. 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:</t></list> <figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ Session-Id = 0x17 || RAND || AUTN ]]></artwork></figure> <list><t>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:</t></list> </t> <figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ Session-Id = 0x17 || NONCE_S || MAC ]]></artwork></figure></dd> </dl> </blockquote> </section> <sectiontitle="EAP-SIM" anchor="sect-2.2"><t>anchor="sect-2.2" numbered="true" toc="default"> <name>EAP-SIM</name> <t> Similarly for EAP-SIM, <xreftarget="RFC5247"/> Appendix Atarget="RFC5247" sectionFormat="comma" section="A"/> says:</t><t>EAP-SIM <list><blockquote> <dl newline="true"> <dt>EAP-SIM </dt> <dd> <t>EAP-SIM is defined in <xreftarget="RFC4186"/>.target="RFC4186" format="default"/>. 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:</t></list> </t> <figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ Session-Id = 0x12 || RAND || NONCE_MT ]]></artwork></figure></dd> </dl> </blockquote> <t>It should say:</t><t>EAP-SIM <list><blockquote> <dl newline="true"> <dt>EAP-SIM </dt> <dd> <t>EAP-SIM is defined in <xreftarget="RFC4186"/>.target="RFC4186" format="default"/>. 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".</t> <t>For "n=2", the Session-Id is therefore defined as</t></list> <figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ Session-Id = 0x12 || RAND1 || RAND2 || NONCE_MT ]]></artwork></figure> <list><t>which is 49 octets in length.</t> <t>For "n=3", the Session-Id is therefore defined as</t></list> <figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ Session-Id = 0x12 || RAND1 || RAND2 || RAND3 || NONCE_MT ]]></artwork></figure> <list><t>which is 65 octets in length.</t><t>Where RAND1, RAND2<t>RAND1, RAND2, and RAND3 correspond to the RAND value from the first,secondsecond, and third GSMtriplettriplet, respectively.</t> <t>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:</t></list> <figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ Session-Id = 0x12 || NONCE_S || MAC ]]></artwork></figure> <list><t>which is 33 octets in length.</t></list> </t></dd> </dl> </blockquote> </section> <sectiontitle="Rationaleanchor="sect-2.3" numbered="true" toc="default"> <name>Rationale for EAP-AKA and EAP-SIMupdates" anchor="sect-2.3"><t>Updates</name> <t> <xreftarget="RFC5247"/>target="RFC5247" sectionFormat="of" section="A"/> was supposed to define exported parameters for existing EAPmethods in Appendix A.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 <xreftarget="RFC4187"/> Section 5.2,target="RFC4187" sectionFormat="comma" section="5.2"/> and similar text in <xreftarget="RFC4186"/> Section 5.2,target="RFC4186" sectionFormat="comma" section="5.2"/>, NONCE_S corresponds to RAND and MAC inEAP-Request/AKA-ReauthenticationEAP-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.</t> <t> Thisderiviationderivation is done via a random value created by the server, along with a secret key and the peer's identity. We believe that thisderiviationderivation is secure, though no formal analysis has been done.</t> </section> </section> <sectiontitle="Session-Idanchor="sect-3" numbered="true" toc="default"> <name>Session-Id forPEAP" anchor="sect-3"><t>PEAP</name> <t> <xreftarget="RFC5247"/>target="RFC5247" format="default"/> did not define Session-Id for Microsoft's Protected EAP (PEAP). For consistency with the EAP-TLS definition given in <xreftarget="RFC5216"/> <xref target="sect-2.3"/>,target="RFC5216" sectionFormat="comma" section="2.3"/>, we define it as:</t><figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ Session-Id = 0x19 || client.random || server.random ]]></artwork></figure><t> This definition is that same for both fullauthentication,authentication and for fast reconnect.</t> <t> This definition is already inwide-spreadwidespread use in all known PEAP implementations.</t> <t> 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 <xreftarget="I-D.dekok-emu-tls-eap-types"/>.</t>target="I-D.ietf-emu-tls-eap-types" format="default"/>.</t> </section> <sectiontitle="Security Considerations" anchor="sect-4"><t>anchor="sect-4" numbered="true" toc="default"> <name>Security Considerations</name> <t> 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.</t> <t> The Session-Id definitions given here are unique persession and unforgeablesession, unforgeable, and unguessable by an outside party, as per the requirements of <xreftarget="RFC5247"/> Section 10.</t>target="RFC5247" sectionFormat="comma" section="10"/>.</t> <t> The definitions used here have been widely deployed foryears,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. </t> <t> These updates do not modify theSecurity Considerationssecurity considerations outlined inRFC5247.</t><xref target="RFC5247"/>.</t> </section> <sectiontitle="IANA Considerations" anchor="sect-5"><t> There are no actions for IANA. RFC EDITOR:anchor="sect-5" numbered="true" toc="default"> <name>IANA Considerations</name> <t> Thissection may be removed before publication.</t>document has no IANA actions.</t> </section> </middle> <back><references title="Normative References"> &RFC2119; &RFC3748; &RFC5216; &RFC5247; &RFC8174;<displayreference target="I-D.ietf-emu-rfc5448bis" to="AKAP"/> <displayreference target="I-D.ietf-emu-tls-eap-types" to="TLS-EAP-TYPES"/> <displayreference target="I-D.josefsson-pppext-eap-tls-eap" to="PEAP"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3748.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5216.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5247.xml"/> <referenceanchor="FILS"><front>anchor="FILS"> <front> <title>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</title><author><author><organization>IEEE </organization> </author> <date month="December" year="2016"/> </front> <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7792308"/> <seriesInfo name="IEEE" value="Std 802.11ai-2016"/> </reference> </references><references title="Informative References"> &RFC4186; &RFC4187; &RFC6696; &I-D.ietf-emu-rfc5448bis; &I-D.dekok-emu-tls-eap-types;<references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4186.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4187.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6696.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-emu-rfc5448bis.xml"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-emu-tls-eap-types.xml"/> <reference anchor="MS-PEAP"target="https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-peap/5308642b-90c9-4cc4-beec-fb367325c0f9"><front>target="https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-peap/5308642b-90c9-4cc4-beec-fb367325c0f9"> <front> <title>[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)</title> <author> <organization>Microsoft</organization> </author> <date/> </front> </reference>&I-D.josefsson-pppext-eap-tls-eap;<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.josefsson-pppext-eap-tls-eap.xml"/> <reference anchor="Err5011" quote-title="false" target="https://www.rfc-editor.org/errata/eid5011"> <front> <title>Erratum ID 5011</title> <author><organization>RFC Errata</organization></author> </front> <refcontent>RFC 5247</refcontent> </reference> </references> </references> <sectiontitle="Acknowledgments" numbered="no" anchor="acknowledgments"><figure><artwork><![CDATA[numbered="false" anchor="acknowledgments" toc="default"> <name>Acknowledgments</name> <t> The issue corrected in this specification was first reported byJouni Malinen<contact fullname="Jouni Malinen"/> in a technicalerrata at https://www.rfc-editor.org/errata_search.php?rfc=5247erratum for RFC 5247 <xref target="Err5011"/>.</t> <t> The text in this document follows Jouni's suggestions.]]></artwork> </figure></t> </section> </back> </rfc>