rfc8940xml2.original.xml   rfc8940.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
C.2119.xml">
<!ENTITY RFC3748 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
C.3748.xml"> docName="draft-ietf-emu-eap-session-id-07.txt" number="8940"
<!ENTITY RFC5216 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF submissionType="IETF" category="std" consensus="true" updates="5247"
C.5216.xml"> ipr="trust200902" obsoletes="" xml:lang="en" symRefs="true"
<!ENTITY RFC5247 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF sortRefs="true" tocInclude="true" version="3">
C.5247.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC4186 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4186.xml">
<!ENTITY RFC4187 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4187.xml">
<!ENTITY RFC6696 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6696.xml">
<!ENTITY I-D.ietf-emu-rfc5448bis SYSTEM "https://xml2rfc.ietf.org/public/rfc/bib
xml3/reference.I-D.draft-ietf-emu-rfc5448bis-07.xml">
<!ENTITY I-D.ietf-emu-rfc5448bis SYSTEM "https://xml2rfc.ietf.org/public/rfc/bib
xml3/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/publi
c/rfc/bibxml3/reference.I-D.josefsson-pppext-eap-tls-eap.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-emu-eap-session-id-07.txt" catego
ry="std" 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"?>
<front> <front>
<title abbrev="EAP Session-Id Derivation">EAP Session-Id Derivation for E <title abbrev="EAP Session-Id Derivation">Extensible Authentication
AP-SIM, EAP-AKA, and PEAP</title> Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module
<author initials="A." surname="DeKok" fullname="Alan DeKok"> (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected
<organization abbrev="FreeRADIUS">The FreeRADIUS Server Project</organiza EAP (PEAP)</title>
tion> <seriesInfo name="RFC" value="8940"/>
<address><email>aland@freeradius.org</email> <author initials="A." surname="DeKok" fullname="Alan DeKok">
</address> <organization abbrev="FreeRADIUS">The FreeRADIUS Server Project</organizat
</author> ion>
<address>
<email>aland@freeradius.org</email>
</address>
</author>
<date year="2020" 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>
<date year="2020" month="September"/> <abstract>
<abstract><t> <t>
RFC 5247 is updated to define and clarity EAP Session-Id derivation RFC 5247 is updated to define and clarify EAP Session-Id derivation
for multiple EAP methods. The derivation of Session-Id was not given for multiple Extensible Authentication
for EAP-SIM or EAP-AKA when using the fast reconnect exchange instead Protocol (EAP) methods. The derivation of Session-Id was not given
for EAP Subscriber Identity Module (EAP-SIM) or EAP Authentication and Key Ag
reement (EAP-AKA) when using the fast reconnect exchange instead
of full authentication. The derivation of Session-Id for full of full authentication. The derivation of Session-Id for full
authentication is clarified for both EAP-SIM and EAP-AKA. The authentication is clarified for both EAP-SIM and EAP-AKA. The
deriviation of Session-Id for PEAP is also given. The definition for derivation of Session-Id for Protected EAP (PEAP) is also given. The definit ion for
PEAP follows the definition for other TLS-based EAP methods.</t> PEAP follows the definition for other TLS-based EAP methods.</t>
</abstract>
</front>
<middle>
<section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name>
<t>
EAP <xref 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. <xref 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 <xref 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>
</abstract> <t>
</front> Further, the derivation of Session-Id for full authentication is
clarified, as the text in <xref target="RFC5247" format="default"/> is
<middle> ambiguous.</t>
<section title="Introduction" anchor="sect-1"><t> <t>
EAP <xref target="RFC3748"/> Session-Id derivation has not been defined for
EAP-SIM and EAP-AKA when using the fast reconnect exchange instead of full
authentication. <xref target="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 <xref target="I-D.ietf-emu-rfc5448bis"/> now defines it,
along with other updates. As such, the definition for EAP-AKA' is not
included here.</t>
<t>
Further, the deriviation of Session-Id for full authentication is
clarified, as the text in <xref target="RFC5247"/> is ambiguousl</t>
<t>
The IEEE has defined Fast Initial Link Setup (FILS) authentication <xref The IEEE has defined Fast Initial Link Setup (FILS) authentication <xref
target="FILS"/>, which needs the EAP Session-Id in order for the EAP target="FILS" format="default"/>, which needs the EAP Session-Id in order
Re-authentication Protocol (ERP) <xref target="RFC6696"/> to work. It is for the EAP Re-authentication Protocol (ERP) <xref target="RFC6696"
therefore important to address the existing deficiencies in the definition format="default"/> to work. It is therefore important to address the
of EAP Session-Id.</t> existing deficiencies in the definition of EAP Session-Id.</t>
<t>
<t> Finally, <xref target="RFC5247" format="default"/> did not define
Finally, <xref target="RFC5247"/> did not define Session-Id for PEAP <xref Session-Id for PEAP <xref target="MS-PEAP" format="default"/> <xref
target="MS-PEAP"/>, <xref target="I-D.josefsson-pppext-eap-tls-eap"/>. We target="I-D.josefsson-pppext-eap-tls-eap" format="default"/>. We correct
correct these deficiencies here by updating <xref target="RFC5247"/> with these deficiencies here by updating <xref target="RFC5247"
the Session-Id derivation during fast-reconnect exchange for EAP-SIM and format="default"/> with the Session-Id derivation during fast-reconnect
EAP-AKA; clarfying the Session-Id derivation during full authentication for exchange for EAP-SIM and EAP-AKA; clarifying the Session-Id derivation
EAP-SIM and EAP-AKA; and defining the Session-Id derivation for PEAP which during full authentication for EAP-SIM and EAP-AKA; and defining the
is the same for both full authentication and fast reconnect.</t> Session-Id derivation for PEAP, which is the same for both full
authentication and fast reconnect.</t>
<section title="Requirements Language" anchor="sect-1.1"><t> </section>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <section anchor="sect-2" numbered="true" toc="default">
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <name>Updates to RFC 5247, Appendix A</name>
"OPTIONAL" in this document are to be interpreted as described in BCP 14 <t>
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they This section updates <xref target="RFC5247" sectionFormat="comma"
appear in all capitals, as shown here.</t> section="A"/> to define Session-Id for fast reconnect exchange for EAP-AKA an
d
</section> EAP-SIM.</t>
<section anchor="sect-2.1" numbered="true" toc="default">
</section> <name>EAP-AKA</name>
<t>
<section title="Updates to RFC 5247 Appendix A" anchor="sect-2"><t> For EAP-AKA, <xref target="RFC5247" sectionFormat="comma"
This section updates <xref target="RFC5247"/> Appendix A to define Session-Id section="A"/> says:</t>
for <blockquote>
fast reconnect exchange for EAP-AKA and EAP-SIM.</t> <dl newline="true">
<dt>EAP-AKA</dt>
<section title="EAP-AKA" anchor="sect-2.1"><t> <dd>
For EAP-AKA, <xref target="RFC5247"/> Appendix A says:</t> <t>EAP-AKA is defined in <xref target="RFC4187"
format="default"/>. The EAP-AKA Session-Id is the concatenation of
<t>EAP-AKA 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
<list> the AT_AUTN attribute:
</t>
<t> EAP-AKA is defined in <xref target="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:</t>
</list>
</t>
<figure><artwork><![CDATA[ <artwork>
Session-Id = 0x17 || RAND || AUTN Session-Id = 0x17 || RAND || AUTN
]]></artwork> </artwork>
</figure>
<t>It should say:</t>
<t>EAP-AKA
<list>
<t>EAP-AKA is defined in <xref target="RFC4187"/>. When using full </dd>
</dl>
</blockquote>
<t>It should say:</t>
<blockquote>
<dl newline="true">
<dt>EAP-AKA</dt>
<dd>
<t>EAP-AKA is defined in <xref target="RFC4187" format="default"/>. W
hen using full
authentication, the EAP-AKA Session-Id is the concatenation of the EAP 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 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, followed by the contents of the AUTN field in the AT_AUTN
attribute:</t> attribute:</t>
</list> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
Session-Id = 0x17 || RAND || AUTN Session-Id = 0x17 || RAND || AUTN
]]></artwork> ]]></artwork>
</figure>
<list> <t>When using fast reconnect, the EAP-AKA Session-Id is the
<t>When using fast reconnect, the EAP-AKA Session-Id is the
concatenation of the EAP Type Code (0x17) with the contents of 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 NONCE_S field from the AT_NONCE_S attribute, followed by the contents
of the MAC field from the AT_MAC attribute from of the MAC field from the AT_MAC attribute from
EAP-Request/AKA-Reauthentication:</t> EAP-Request/AKA-Reauthentication:</t>
</list> <artwork name="" type="" align="left" alt=""><![CDATA[
</t>
<figure><artwork><![CDATA[
Session-Id = 0x17 || NONCE_S || MAC Session-Id = 0x17 || NONCE_S || MAC
]]></artwork> ]]></artwork>
</figure> </dd>
</section> </dl>
</blockquote>
<section title="EAP-SIM" anchor="sect-2.2"><t> </section>
Similarly for EAP-SIM, <xref target="RFC5247"/> Appendix A says:</t> <section anchor="sect-2.2" numbered="true" toc="default">
<name>EAP-SIM</name>
<t>EAP-SIM <t>
Similarly for EAP-SIM, <xref target="RFC5247" sectionFormat="comma"
<list> section="A"/> says:</t>
<blockquote>
<t>EAP-SIM is defined in <xref target="RFC4186"/>. The EAP-SIM <dl newline="true">
<dt>EAP-SIM
</dt>
<dd>
<t>EAP-SIM is defined in <xref target="RFC4186" format="default"/>. T
he EAP-SIM
Session-Id is the concatenation of the EAP Type Code (0x12) with the 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 RAND field from the AT_RAND attribute, followed by the
contents of the NONCE_MT field in the AT_NONCE_MT attribute:</t> contents of the NONCE_MT field in the AT_NONCE_MT attribute:</t>
</list> <artwork name="" type="" align="left" alt=""><![CDATA[
</t>
<figure><artwork><![CDATA[
Session-Id = 0x12 || RAND || NONCE_MT Session-Id = 0x12 || RAND || NONCE_MT
]]></artwork> ]]></artwork>
</figure> </dd>
</dl>
<t>It should say:</t> </blockquote>
<t>It should say:</t>
<t>EAP-SIM
<list>
<t>EAP-SIM is defined in <xref target="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".</t>
<t>For "n=2", the Session-Id is therefore defined as</t> <blockquote>
<dl newline="true">
<dt>EAP-SIM
</dt>
<dd>
<t>EAP-SIM is defined in <xref 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>
</list> <t>For "n=2", the Session-Id is therefore defined as</t>
<figure><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Session-Id = 0x12 || RAND1 || RAND2 || NONCE_MT Session-Id = 0x12 || RAND1 || RAND2 || NONCE_MT
]]></artwork> ]]></artwork>
</figure>
<list> <t>which is 49 octets in length.</t>
<t>For "n=3", the Session-Id is therefore defined as</t>
<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 Session-Id = 0x12 || RAND1 || RAND2 || RAND3 || NONCE_MT
]]></artwork> ]]></artwork>
</figure>
<list>
<t>which is 65 octets in length.</t>
<t>Where RAND1, RAND2 and RAND3 correspond to the RAND value from the <t>which is 65 octets in length.</t>
first, second and third GSM triplet respectively.</t>
<t>When using fast reconnect, the EAP-SIM Session-Id is the <t>RAND1, RAND2, and RAND3 correspond to the RAND value from the
first, second, and third GSM triplet, 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 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 NONCE_S field from the AT_NONCE_S attribute, followed by the contents
of the MAC field from the AT_MAC attribute from of the MAC field from the AT_MAC attribute from
EAP-Request/SIM/Reauthentication:</t> EAP-Request/SIM/Reauthentication:</t>
</list> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
Session-Id = 0x12 || NONCE_S || MAC Session-Id = 0x12 || NONCE_S || MAC
]]></artwork> ]]></artwork>
</figure>
<list>
<t>which is 33 octets in length.</t> <t>which is 33 octets in length.</t>
</dd>
</list> </dl>
</t> </blockquote>
</section>
</section> <section anchor="sect-2.3" numbered="true" toc="default">
<name>Rationale for EAP-AKA and EAP-SIM Updates</name>
<section title="Rationale for EAP-AKA and EAP-SIM updates" anchor="sect-2 <t>
.3"><t> <xref target="RFC5247" sectionFormat="of"
<xref target="RFC5247"/> was supposed to define exported parameters for section="A"/> was supposed to define exported parameters for
existing EAP methods in Appendix A. The way Session-Id was defined 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 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 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 parameters (RAND, AUTN, NONCE_MT) are not used in the fast reconnect
case. Based on <xref target="RFC4187"/> Section 5.2, and similar text in case. Based on <xref target="RFC4187" sectionFormat="comma" section="5.2"/>
<xref target="RFC4186"/> Section 5.2, NONCE_S corresponds to RAND and MAC and similar text in
in EAP-Request/AKA-Reauthentication and EAP-Request/SIM/Reauthentication <xref target="RFC4186" sectionFormat="comma" section="5.2"/>, NONCE_S corresp
onds 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 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> defined using NONCE_S and MAC instead of RAND and AUTN/NONCE_MT.</t>
<t>
<t> This derivation is done via a random value created by the server,
This deriviation is done via a random value created by the server,
along with a secret key and the peer's identity. We believe that along with a secret key and the peer's identity. We believe that
this deriviation is secure, though no formal analysis has been done.</t> this derivation is secure, though no formal analysis has been done.</t>
</section>
</section> </section>
<section anchor="sect-3" numbered="true" toc="default">
</section> <name>Session-Id for PEAP</name>
<t>
<section title="Session-Id for PEAP" anchor="sect-3"><t> <xref target="RFC5247" format="default"/> did not define Session-Id for Micro
<xref target="RFC5247"/> did not define Session-Id for Microsoft's soft's
Protected EAP (PEAP). For consistency with the EAP-TLS definition given in Protected EAP (PEAP). For consistency with the EAP-TLS definition given in
<xref target="RFC5216"/> <xref target="sect-2.3"/>, we define it as:</t> <xref 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 Session-Id = 0x19 || client.random || server.random
]]></artwork> ]]></artwork>
</figure> <t>
<t> This definition is that same for both full authentication and for fast reconn
This definition is that same for both full authentication, and for ect.</t>
fast reconnect.</t> <t>
This definition is already in widespread use in all known PEAP
<t>
This definition is already in wide-spread use in all known PEAP
implementations.</t> implementations.</t>
<t>
<t>
Note that this definition for Session-Id only applies when TLS 1.2 or 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 earlier is used. A different derivation is defined for TLS 1.3 in
<xref target="I-D.dekok-emu-tls-eap-types"/>.</t> <xref target="I-D.ietf-emu-tls-eap-types" format="default"/>.</t>
</section>
</section> <section anchor="sect-4" numbered="true" toc="default">
<name>Security Considerations</name>
<section title="Security Considerations" anchor="sect-4"><t> <t>
This specification defines EAP Session-Ids for ERP with EAP-SIM and This specification defines EAP Session-Ids for ERP with EAP-SIM and
EAP-AKA. It therefore enables ERP key hierarchy establishment using EAP-AKA. It therefore enables ERP key hierarchy establishment using
fast reconnect with EAP-SIM and EAP-AKA.</t> fast reconnect with EAP-SIM and EAP-AKA.</t>
<t>
<t> The Session-Id definitions given here are unique per session, unforgeable, an
The Session-Id definitions given here are unique per session and d unguessable by an outside party, as per the
unforgeable and unguessable by an outside party, as per the requirements of <xref target="RFC5247" sectionFormat="comma" section="10"/>.<
requirements of <xref target="RFC5247"/> Section 10.</t> /t>
<t>
<t> The definitions used here have been widely deployed for years in
The definitions used here have been widely deployed for years, in
all major EAP implementations. However, we acknowledge that very all major EAP implementations. However, we acknowledge that very
little security analysis has been done for these definitions. As a little security analysis has been done for these definitions. As a
result, any security issues would result in serious issues for the result, any security issues would result in serious issues for the
Internet as a whole. </t> Internet as a whole. </t>
<t>
These updates do not modify the security considerations outlined in
<xref target="RFC5247"/>.</t>
</section>
<section anchor="sect-5" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
This document has no IANA actions.</t>
</section>
</middle>
<back>
<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.R
FC.3748.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5216.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5247.xml"/>
<t> <reference anchor="FILS">
These updates do not modify the Security Considerations outlined in <front>
RFC5247.</t> <title>IEEE Standard for Information
technology--Telecommunications and information exchange between
</section> systems - Local and metropolitan area networks--Specific
requirements - Part 11: Wireless LAN Medium Access Control (MAC)
<section title="IANA Considerations" anchor="sect-5"><t> and Physical Layer (PHY) Specifications - Amendment 1: Fast
There are no actions for IANA. RFC EDITOR: This section may be Initial Link Setup</title>
removed before publication.</t> <author><organization>IEEE
</organization>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3748;
&RFC5216;
&RFC5247;
&RFC8174;
<reference anchor="FILS"><front>
<title>IEEE Standard for Information technology--Telecommunications and i
nformation exchange between systems Local and metropolitan area networks--Specif
ic requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications - Amendment 1: Fast Initial Link Setup</title>
<author>
</author> </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>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4186.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4187.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6696.xml"/>
<date year="2016"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-em
</front> u-rfc5448bis.xml"/>
<seriesInfo name="IEEE" value="Std 802.11ai-2016"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-em
</reference> u-tls-eap-types.xml"/>
</references>
<references title="Informative References">
&RFC4186;
&RFC4187;
&RFC6696;
&I-D.ietf-emu-rfc5448bis;
&I-D.dekok-emu-tls-eap-types;
<reference anchor="MS-PEAP" target="https://docs.microsoft.com/en-us/open
specs/windows_protocols/ms-peap/5308642b-90c9-4cc4-beec-fb367325c0f9"><front>
<title>[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)</ti
tle>
<author>
<organization>Microsoft</organization>
</author>
<date/> <reference anchor="MS-PEAP" target="https://docs.microsoft.com/en-us/ope
</front> nspecs/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>
</reference> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.josefss
&I-D.josefsson-pppext-eap-tls-eap; on-pppext-eap-tls-eap.xml"/>
</references>
<section title="Acknowledgments" numbered="no" anchor="acknowledgments"><
figure><artwork><![CDATA[
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. <reference anchor="Err5011" quote-title="false"
]]></artwork> target="https://www.rfc-editor.org/errata/eid5011">
</figure> <front>
</section> <title>Erratum ID 5011</title>
<author><organization>RFC Errata</organization></author>
</front>
<refcontent>RFC 5247</refcontent>
</reference>
</back> </references>
</references>
<section numbered="false" anchor="acknowledgments" toc="default">
<name>Acknowledgments</name>
<t>
The issue corrected in this specification was first reported by <contact
fullname="Jouni Malinen"/> in a technical erratum for RFC 5247 <xref target="Err
5011"/>.</t>
</rfc> <t>
The text in this document follows Jouni's suggestions.
</t>
</section>
</back>
</rfc>
 End of changes. 47 change blocks. 
300 lines changed or deleted 283 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/