rfc9930.original.xml   rfc9930.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 2.6. -ietf-emu-rfc7170bis-22" number="9930" category="std" consensus="true" submissio
10) --> nType="IETF" obsoletes="7170" updates="9427" tocInclude="true" sortRefs="true" s
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ymRefs="true" version="3" xml:lang="en">
-ietf-emu-rfc7170bis-22" category="std" consensus="true" submissionType="IETF" o
bsoletes="7170" updates="9427" tocInclude="true" sortRefs="true" symRefs="true" <!-- [rfced] FYI: We have updated the short title of this document,
version="3"> which appears in the running header in the PDF output, as follows.
<!-- xml2rfc v2v3 conversion 3.24.0 --> Please let us know any objections.
Original:
TEAP
Current:
TEAP Version 1
-->
<front> <front>
-&gt; <title abbrev="TEAP Version 1">Tunnel Extensible Authentication Protocol (TE
<title abbrev="TEAP">Tunnel Extensible Authentication Protocol (TEAP) Versio AP) Version 1</title>
n 1</title> <seriesInfo name="RFC" value="9930"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-emu-rfc7170bis-22"/> <author initials="A." surname="DeKok" fullname="Alan DeKok" role="editor">
<author initials="A." surname="DeKok (Ed)" fullname="Alan DeKok">
<organization/> <organization/>
<address> <address>
<email>aland@freeradius.org</email> <email>aland@freeradius.org</email>
</address> </address>
</author> </author>
<date year="2025" month="May" day="28"/> <date year="2026" month="February"/>
<area>Internet</area> <area>SEC</area>
<workgroup>EMU working group</workgroup> <workgroup>emu</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <!-- [rfced] Please insert any keywords (beyond those that appear in
<?line 120?> the title) for use on https://www.rfc-editor.org/search. -->
<!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside)
.
-->
<keyword>example</keyword>
<abstract>
<t>This document defines the Tunnel Extensible Authentication Protocol <t>This document defines the Tunnel Extensible Authentication Protocol
(TEAP) version 1. TEAP is a tunnel-based EAP method that enables (TEAP) version 1. TEAP is a tunnel-based EAP method that enables
secure communication between a peer and a server by using the secure communication between a peer and a server by using the
Transport Layer Security (TLS) protocol to establish a mutually Transport Layer Security (TLS) protocol to establish a mutually
authenticated tunnel. Within the tunnel, TLV objects are used to authenticated tunnel. Within the tunnel, TLV objects are used to
convey authentication-related data between the EAP peer and the EAP convey authentication-related data between the EAP peer and the EAP
server. This document obsoletes RFC 7170 and updates RFC 9427 by server. This document obsoletes RFC 7170 and updates RFC 9427 by
moving all TEAP specifications from those documents to this one.</t> moving all TEAP specifications from those documents to this one.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis/"/>.
</t>
<t>
Discussion of this document takes place on the
EMU Working Group mailing list (<eref target="mailto:emu@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/emu/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/emu/"/>
.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/emu-wg/rfc7170bis.git"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 131?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>A tunnel-based Extensible Authentication Protocol (EAP) method is an <t>A tunnel-based Extensible Authentication Protocol (EAP) method is an
EAP method that establishes a secure tunnel and executes other EAP EAP method that establishes a secure tunnel and executes other EAP
methods under the protection of that secure tunnel. A tunnel-based methods under the protection of that secure tunnel. A tunnel-based
EAP method can be used in any lower-layer protocol that supports EAP EAP method can be used in any lower-layer protocol that supports EAP
authentication. There are several existing tunnel-based EAP methods authentication. There are several existing tunnel-based EAP methods
that use Transport Layer Security (TLS) <xref target="RFC8446"/> to establish th e that use Transport Layer Security (TLS) <xref target="RFC8446"/> to establish th e
secure tunnel. EAP methods supporting this include Protected EAP secure tunnel. EAP methods supporting this include Protected EAP
(PEAP) <xref target="PEAP"/>, EAP Tunneled Transport Layer Security (EAP-TTLS) (PEAP) <xref target="PEAP"/>, EAP Tunneled Transport Layer Security (EAP-TTLS) <
<xref target="RFC5281"/>, and EAP Flexible Authentication via Secure Tunneling xref target="RFC5281"/>, and EAP Flexible Authentication via Secure Tunneling
(EAP-FAST) <xref target="RFC4851"/>. However, they all are either vendor-specif ic or (EAP-FAST) <xref target="RFC4851"/>. However, they all are either vendor-specif ic or
informational, and the industry calls for a Standards Track informational, and the industry calls for a Standards Track
tunnel-based EAP method. <xref target="RFC6678"/> outlines the list of requirem ents for a tunnel-based EAP method. <xref target="RFC6678"/> outlines the list of requirem ents for a
standard tunnel-based EAP method.</t> standard tunnel-based EAP method.</t>
<t>This document describes the Tunnel Extensible Authentication Protocol <t>This document describes the Tunnel Extensible Authentication Protocol
(TEAP) version 1, which is based on EAP-FAST <xref target="RFC4851"/>. The chan ges from EAP-FAST to TEAP are largely minor, in order (TEAP) version 1, which is based on EAP-FAST <xref target="RFC4851"/>. The chan ges from EAP-FAST to TEAP are largely minor in order
to meet the requirements outlined in <xref target="RFC6678"/> for a standard to meet the requirements outlined in <xref target="RFC6678"/> for a standard
tunnel-based EAP method.</t> tunnel-based EAP method.</t>
<t>This specification describes TEAPv1, and defines cryptographic <t>This document also defines cryptographic derivations for use with TLS 1
derivations for use with TLS 1.2. When TLS 1.3 is used, the .2. When TLS 1.3 is used, the
definitions of cryptographic derivations in <xref target="RFC9427"/> MUST be use definitions of cryptographic derivations in <xref target="RFC9427"/> <bcp14>MUST
d </bcp14> be used
instead of the ones given here.</t> instead of the ones given here.</t>
<t>Note that while it is technically possible to use TEAPv1 with TLS 1.0 <t>Note that while it is technically possible to use TEAPv1 with TLS 1.0
and TLS 1.1, those protocols have been deprecated in <xref target="RFC8996"/>. As and TLS 1.1, those protocols have been deprecated in <xref target="RFC8996"/>. As
such, the definitions given here are only applicable for TLS 1.2, and such, the definitions given here are only applicable for TLS 1.2 and TLS 1.3.</t
for TLS 1.3.</t> >
<section anchor="interoperability"> <section anchor="interoperability">
<name>Interoperability Issues</name> <name>Interoperability Issues</name>
<t>This document contains substantial changes from <xref target="RFC7170 "/>. These <t>This document contains substantial changes from <xref target="RFC7170 "/>. These
changes are largely clarifications and corrections to that changes are largely clarifications and corrections to that
specification.</t> specification.</t>
<t>However, there is one major change from <xref target="RFC7170"/>, in <!-- [rfced] Should "functionality" be plural in this sentence?
the
specification of the cryptographic binding information. While there Original:
The implementations are interoperable, but only for a subset of the
functionality described in [RFC7170].
Perhaps:
The implementations are interoperable but only for a subset of the
functionalities described in [RFC7170].
-->
<t>However, there is one major change from <xref target="RFC7170"/> in the
specification of the cryptographic-binding information. While there
were multiple implementations of <xref target="RFC7170"/>, the text in that were multiple implementations of <xref target="RFC7170"/>, the text in that
document was interpreted differently by each implementation. The document was interpreted differently by each implementation. The
implementations are interoperable, but only for a subset of the implementations are interoperable but only for a subset of the
functionality described in <xref target="RFC7170"/>.</t> functionality described in <xref target="RFC7170"/>.</t>
<t>This specification describes how TEAPv1 works in theory, but also <t>This specification describes how TEAPv1 works in theory but also
explains what subset of TEAPv1 is currently interoperable. In order explains what subset of TEAPv1 is currently interoperable. In order
to simplify the description of an already complex specification, all to simplify the description of an already complex specification, all
interoperabiliy issues are documented separately from the normal interoperability issues are documented separately from the normal
protocol operation.</t> protocol operation.</t>
<t>Please see <xref target="limitations"/>, below, for further discussio n of <t>Please see <xref target="limitations"/> for further discussion of
interoperability issues.</t> interoperability issues.</t>
</section> </section>
<section anchor="specification-requirements"> <section anchor="specification-requirements">
<name>Specification Requirements</name> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
described in BCP 14 [RFC2119] [RFC8174] when, and only when, they NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
appear in all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>Much of the terminology in this document comes from <xref target="RFC 3748"/>. <t>Much of the terminology in this document comes from <xref target="RFC 3748"/>.
Additional terms are defined below:</t> Additional terms are defined below:</t>
<t>Type-Length-Value (TLV)</t> <dl spacing="normal" newline="true">
<ul empty="true"> <dt>Type-Length-Value (TLV)</dt>
<li> <dd>The TEAP protocol utilizes objects in TLV format. The TLV format is
<t>The TEAP protocol utilizes objects in TLV format. The TLV format defined in <xref target="teap-tlv-format"/>.</dd>
is defined in <xref target="teap-tlv-format"/>.</t> <dt>Inner Method</dt>
</li> <dd>An authentication method that is sent as application data inside of a
</ul> TLS exchange that is carried over TEAP. The inner method can be an EAP
<t>Inner Method</t> authentication method, a username/password authentication, or a
<ul empty="true"> vendor-specific authentication method. Where the TLS connection is
<li> authenticated, the inner method could also be a Public Key Cryptography
<t>An authentication method which is sent as application data inside Standard (PKCS) exchange.</dd>
of a TLS exchange which is carried over TEAP. The inner method </dl>
can be an EAP authentication method, a username / password
authentication, or a vendor-specific authentication method. Where the
TLS connection is authenticated, the inner method could also be
a Public Key Cryptography Standard (PKCS) exchange.</t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="protocol-overview"> <section anchor="protocol-overview">
<name>Protocol Overview</name> <name>Protocol Overview</name>
<t>TEAP authentication occurs in two phases after the initial EAP <t>TEAP authentication occurs in two phases after the initial EAP
Identity request/response exchange. In the first phase, TEAP employs Identity request/response exchange. In the first phase, TEAP employs
the TLS <xref target="RFC8446"/> handshake to provide an authenticated key excha nge the TLS <xref target="RFC8446"/> handshake to provide an authenticated key excha nge
and to establish a protected tunnel. Once the tunnel is established, and to establish a protected tunnel. Once the tunnel is established,
the second phase begins with the peer and server engaging in further the second phase begins with the peer and server engaging in further
conversations to establish the required authentication and conversations to establish the required authentication and
authorization policies. TEAP makes use of TLV objects to carry out authorization policies. TEAP makes use of TLV objects to carry out
the inner authentication, results, and other information, such as the inner authentication, results, and other information, such as
channel-binding information.</t> channel-binding information.</t>
<t>As discussed in <xref section="2.1.7" sectionFormat="comma" target="RFC <t>As discussed in <xref section="2.1.7" sectionFormat="of" target="RFC919
9190"/> and <xref section="3.1" sectionFormat="comma" target="RFC9427"/>, 0"/> and <xref section="3.1" sectionFormat="of" target="RFC9427"/>,
the outer EAP Identity SHOULD be an anonymous Network Access the outer EAP Identity <bcp14>SHOULD</bcp14> be an anonymous Network Access
Identifier (NAI) as described in <xref section="2.4" sectionFormat="comma" targe Identifier (NAI) as described in <xref section="2.4" sectionFormat="of" target="
t="RFC7542"/>. While <xref section="5.1" sectionFormat="comma" target="RFC3748" RFC7542"/>. While <xref section="5.1" sectionFormat="of" target="RFC3748"/> pla
/> places no ces no
limits on the contents of the Identity field, <xref section="2.6" sectionFormat= limits on the contents of the Identity field, <xref section="2.6" sectionFormat=
"comma" target="RFC7542"/> "of" target="RFC7542"/>
states that Identities which do not follow the NAI format cannot be states that Identities that do not follow the NAI format cannot be
transported in an Authentication, Authorization, and Accounting (AAA) transported in an Authentication, Authorization, and Accounting (AAA)
proxy network. As such, Identities in non-NAI form are likely to not proxy network. As such, Identities in non-NAI form are likely to not
work outside of limited and local networks.</t> work outside of limited and local networks.</t>
<t>Any inner identities (EAP or otherwise) SHOULD also <t>Any inner identities (EAP or otherwise) <bcp14>SHOULD</bcp14> also
follow the recommendations of <xref section="3.1" sectionFormat="comma" target=" RFC9427"/> about inner identities.</t> follow the recommendations of <xref section="3.1" sectionFormat="comma" target=" RFC9427"/> about inner identities.</t>
<t><xref target="RFC7170"/> defined a Protected Access Credential (PAC) to mirror <t><xref target="RFC7170"/> defined a Protected Access Credential (PAC) to mirror
EAP-FAST <xref target="RFC4851"/>. However, implementation experience and analy sis EAP-FAST <xref target="RFC4851"/>. However, implementation experience and analy sis
determined that the PAC was not necessary. Instead, TEAP performs determined that the PAC was not necessary. Instead, TEAP performs
session resumption using the NewSessionTicket message as defined in session resumption using the NewSessionTicket message as defined in
<xref section="2.1.2" sectionFormat="comma" target="RFC9190"/> and <xref section ="2.1.3" sectionFormat="comma" target="RFC9190"/>. As such, the PAC has Sections <xref section="2.1.2" sectionFormat="bare" target="RFC9190"/> and <xref section="2.1.3" sectionFormat="bare" target="RFC9190"/> of <xref target="RFC919 0"/>. As such, the PAC has
been deprecated.</t> been deprecated.</t>
<t>The TEAP conversation is used to establish or resume an existing <t>The TEAP conversation is used to establish or resume an existing
session to typically establish network connectivity between a peer session to typically establish network connectivity between a peer
and the network. Upon successful execution of TEAP, the EAP peer and and the network. Upon successful execution of TEAP, the EAP peer and
EAP server both derive strong session key material (Master Session Key <xref tar get="RFC3748"/>) that can then be EAP server both derive strong session key material (Master Session Key <xref tar get="RFC3748"/>) that can then be
communicated to the network access server (NAS) for use in communicated to the network access server (NAS) for use in
establishing a link-layer security association.</t> establishing a link-layer security association.</t>
<section anchor="architectural-model"> <section anchor="architectural-model">
<name>Architectural Model</name> <name>Architectural Model</name>
<t>The network architectural model for TEAP usage is shown below:</t> <t>The network architectural model for TEAP usage is shown below:</t>
<figure> <figure>
<name>TEAP Architectural Model</name> <name>TEAP Architectural Model</name>
<artwork><![CDATA[ <artwork><![CDATA[
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| | | | | | | Inner | | | | | | | | Inner |
| Peer |<---->| Authen- |<---->| TEAP |<---->| Method | | Peer |<---->| Authen- |<---->| TEAP |<---->| Method |
| | | ticator | | server | | server | | | | ticator | | server | | server |
| | | | | | | | | | | | | | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+]]></artwork>
]]></artwork>
</figure> </figure>
<t>The Peer and Authenticator are defined in <xref section="1.2" section Format="comma" target="RFC3748"/>, <t>The Peer and Authenticator are defined in <xref section="1.2" section Format="comma" target="RFC3748"/>.
The TEAP server is the "backend authentication server" defined in The TEAP server is the "backend authentication server" defined in
<xref section="1.2" sectionFormat="comma" target="RFC3748"/>. The "Inner Method server" is usually part of the <xref section="1.2" sectionFormat="comma" target="RFC3748"/>. The "Inner Method server" is usually part of the
TEAP server, and handles the application data (inner methods, EAP, passwords, et c.) TEAP server and handles the application data (inner methods, EAP, passwords, etc .)
inside of the TLS tunnel.</t> inside of the TLS tunnel.</t>
<t>The entities depicted above are logical entities and may or may not <t>The entities depicted above are logical entities and may or may not
correspond to separate network components. For example, the TEAP correspond to separate network components. For example, the TEAP
server and Inner Method server might be a single entity; the server and Inner Method server might be a single entity; the
authenticator and TEAP server might be a single entity; or the authenticator and TEAP server might be a single entity; or the
functions of the authenticator, TEAP server, and Inner Method server functions of the authenticator, TEAP server, and Inner Method server
might be combined into a single physical device. For example, might be combined into a single physical device. For example,
typical IEEE 802.11 deployments place the authenticator in an access typical IEEE 802.11 deployments place the authenticator in an access
point (AP) while a RADIUS server may provide the TEAP and inner point (AP) while a RADIUS server may provide the TEAP and inner
method server components. The above diagram illustrates the division method server components. The above diagram illustrates the division
of labor among entities in a general manner and shows how a of labor among entities in a general manner and shows how a
distributed system might be constructed; however, actual systems distributed system might be constructed; however, actual systems
might be realized more simply. The security considerations in might be realized more simply. The security considerations in
<xref target="separation-p1-p2"/> provide an additional discussion of the implic ations of <xref target="separation-p1-p2"/> provide an additional discussion of the implic ations of
separating the TEAP server from the Inner Method server.</t> separating the TEAP server from the Inner Method server.</t>
</section> </section>
<section anchor="protocol-layering-model"> <section anchor="protocol-layering-model">
<name>Protocol-Layering Model</name> <name>Protocol-Layering Model</name> <t>TEAP packets are encapsulated
<t>TEAP packets are encapsulated within EAP; EAP in turn requires a within EAP; EAP in turn requires a transport protocol. TEAP packets
transport protocol. TEAP packets encapsulate TLS, which is then used encapsulate TLS, which is then used to encapsulate user authentication
to encapsulate user authentication information. Thus, TEAP messaging information. Thus, TEAP messaging can be described using a layered
can be described using a layered model, where each layer encapsulates model, where each layer encapsulates the layer above it. The
the layer above it. The following diagram clarifies the relationship following diagram clarifies the relationship between protocols:</t>
between protocols:</t>
<figure> <figure>
<name>Protocol-Layering Model</name> <name>Protocol-Layering Model</name>
<artwork><![CDATA[ <artwork><![CDATA[
+------------------------------------------+ +------------------------------------------+
| Inner EAP Method | Other TLV information | | Inner EAP Method | Other TLV information |
|------------------------------------------| |------------------------------------------|
| TLV Encapsulation (TLVs) | | TLV Encapsulation (TLVs) |
|------------------------------------------+---------------------+ |------------------------------------------+---------------------+
| TLS | Optional Outer TLVs | | TLS | Optional Outer TLVs |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| TEAP | | TEAP |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| EAP | | EAP |
|----------------------------------------------------------------| |----------------------------------------------------------------|
| Carrier Protocol (EAP over LAN, RADIUS, Diameter, etc.) | | Carrier Protocol (EAP over LAN, RADIUS, Diameter, etc.) |
+----------------------------------------------------------------+ +----------------------------------------------------------------+]]></artwork>
]]></artwork>
</figure> </figure>
<t>The TLV layer is a payload with TLV objects as defined in <t>The TLV layer is a payload with TLV objects as defined in
<xref target="teap-tlv-format"/>. The TLV objects are used to carry arbitrary p arameters <xref target="teap-tlv-format"/>. The TLV objects are used to carry arbitrary p arameters
between an EAP peer and an EAP server. All data exchanges in the TEAP between an EAP peer and an EAP server. All data exchanges in the TEAP-protected
protected tunnel are encapsulated in a TLV layer.</t> tunnel are encapsulated in a TLV layer.</t>
<t>Methods for encapsulating EAP within carrier protocols are already <t>Methods for encapsulating EAP within carrier protocols are already
defined. For example, IEEE 802.1X <xref target="IEEE.802-1X.2020"/> may be used to defined. For example, IEEE 802.1X <xref target="IEEE.802-1X.2020"/> may be used to
transport EAP between the peer and the authenticator; RADIUS transport EAP between the peer and the authenticator; RADIUS
<xref target="RFC3579"/> or Diameter <xref target="RFC4072"/> may be used to tra nsport EAP between <xref target="RFC3579"/> or Diameter <xref target="RFC4072"/> may be used to tra nsport EAP between
the authenticator and the EAP server.</t> the authenticator and the EAP server.</t>
</section> </section>
<section anchor="outer-tlvs-versus-inner-tlvs"> <section anchor="outer-tlvs-versus-inner-tlvs">
<name>Outer TLVs versus Inner TLVs</name> <name>Outer TLVs Versus Inner TLVs</name>
<t>TEAP packets may include TLVs both inside and outside the TLS tunnel <t>TEAP packets may include TLVs both inside and outside the TLS tunnel
defined as follows:</t> defined as follows:</t>
<t>Outer TLVs</t> <dl spacing="normal" newline="true">
<ul empty="true"> <dt>Outer TLVs</dt>
<li> <dd>This term is used to refer to optional TLVs outside the TLS tunnel,
<t>This term is used to refer to optional TLVs outside the which are only allowed in the first two messages in the TEAP protocol. That
TLS tunnel, which are only allowed in the first two messages in the is the first EAP-server-to-peer message and first peer-to-EAP-server
TEAP protocol. That is the first EAP-server-to-peer message and message. If the message is fragmented, the whole set of fragments is
first peer-to-EAP-server message. If the message is fragmented, the counted as one message.</dd>
whole set of fragments is counted as one message.</t> <dt>Inner TLVs</dt>
</li> <dd>This term is used to refer to TLVs sent within the TLS tunnel. In TEAP
</ul> Phase 1, Outer TLVs are used to help establish the TLS tunnel, but no Inner
<t>Inner TLVs</t> TLVs are used. In Phase 2 of TEAP, TLS records may encapsulate zero or more
<ul empty="true"> Inner TLVs, but no Outer TLVs are used.</dd>
<li> </dl>
<t>This term is used to refer to TLVs sent within the TLS tunnel. I
n TEAP
Phase 1, Outer TLVs are used to help establish the TLS tunnel, but no
Inner TLVs are used. In Phase 2 of TEAP, TLS
records may encapsulate zero or more Inner TLVs, but no Outer TLVs are used.</t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="teap-protocol"> <section anchor="teap-protocol">
<name>TEAP Protocol</name> <name>TEAP Protocol</name>
<t>The operation of the protocol, including Phase 1 and Phase 2, is the <t>The operation of the protocol, including Phase 1 and Phase 2, is the
topic of this section. The format of TEAP messages is given in topic of this section. The format of TEAP messages is given in
<xref target="message-formats"/>, and the cryptographic calculations are given i n <xref target="cryptographic-calculations"/>.</t> <xref target="message-formats"/>, and the cryptographic calculations are given i n <xref target="cryptographic-calculations"/>.</t>
<section anchor="version-negotiation"> <section anchor="version-negotiation">
<name>Version Negotiation</name> <name>Version Negotiation</name>
<t>TEAP packets contain a 3-bit Version field, following the TLS Flags <t>TEAP packets contain a 3-bit Version field, following the TLS Flags
field, which enables future TEAP implementations to be backward field, which enables future TEAP implementations to be backward
compatible with previous versions of the protocol. This compatible with previous versions of the protocol. This
specification documents the TEAP version 1 protocol; implementations specification documents the TEAP version 1 protocol; implementations
of this specification MUST use a Version field set to 1.</t> of this specification <bcp14>MUST</bcp14> use a Version field set to 1.</t>
<t>Version negotiation proceeds as follows:</t> <t>Version negotiation proceeds as follows:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1">
<li>
<t>In the first EAP-Request sent with EAP type=TEAP, the EAP server <t>In the first EAP-Request sent with EAP type=TEAP, the EAP server
MUST set the Version field to the highest version it supports.</t> <bcp14>MUST</bcp14> set the Version field to the highest version it supports.</t >
</li> </li>
<li> <li>
<t>If the EAP peer supports this version of the protocol, it respond s <t>If the EAP peer supports this version of the protocol, it respond s
with an EAP-Response of EAP type=TEAP, including the version number with an EAP-Response of EAP type=TEAP, including the version number
proposed by the TEAP server.</t> proposed by the TEAP server.</t>
</li> </li>
<li> <li>
<t>If the TEAP peer does not support the proposed version but suppor ts <t>If the TEAP peer does not support the proposed version but suppor ts
a lower version, it responds with an EAP-Response of EAP type=TEAP and a lower version, it responds with an EAP-Response of EAP type=TEAP and
sets the Version field to its highest supported version.</t> sets the Version field to its highest supported version.</t>
</li> </li>
<li> <li>
<t>If the TEAP peer only supports versions higher than the version <t>If the TEAP peer only supports versions higher than the version
proposed by the TEAP server, then use of TEAP will not be possible. proposed by the TEAP server, then use of TEAP will not be possible.
In this case, the TEAP peer sends back an EAP-Nak either to negotiate In this case, the TEAP peer sends back an EAP-Nak either to negotiate
a different EAP type or to indicate no other EAP types are available.</t> a different EAP type or to indicate no other EAP types are available.</t>
</li> </li>
<li> <li>
<t>If the TEAP server does not support the version number proposed b y <t>If the TEAP server does not support the version number proposed b y
the TEAP peer, it MUST either terminate the conversation with an EAP the TEAP peer, it <bcp14>MUST</bcp14> either terminate the conversation with an EAP
Failure or negotiate a new EAP type.</t> Failure or negotiate a new EAP type.</t>
</li> </li>
<li> <li>
<t>If the TEAP server does support the version proposed by the TEAP <t>If the TEAP server does support the version proposed by the TEAP
peer, then the conversation continues using the version proposed by peer, then the conversation continues using the version proposed by
the TEAP peer.</t> the TEAP peer.</t>
</li> </li>
</ol> </ol>
<t>The version negotiation procedure guarantees that the TEAP peer and <t>The version negotiation procedure guarantees that the TEAP peer and
server will agree to the latest version supported by both parties. server will agree to the latest version supported by both parties.
If version negotiation fails, then use of TEAP will not be possible, If version negotiation fails, then use of TEAP will not be possible,
and another mutually acceptable EAP method will need to be negotiated and another mutually acceptable EAP method will need to be negotiated
if authentication is to proceed.</t> if authentication is to proceed.</t>
<t>The TEAP version is not protected by TLS and hence can be modified in <t>The TEAP version is not protected by TLS and hence can be modified in
transit. In order to detect a bid-down attack on the TEAP version, the transit. In order to detect a bid-down attack on the TEAP version, the
peers MUST exchange the TEAP version number received during version peers <bcp14>MUST</bcp14> exchange the TEAP version number received during versi on
negotiation using the Crypto-Binding TLV described in <xref target="crypto-bindi ng-tlv"/>. negotiation using the Crypto-Binding TLV described in <xref target="crypto-bindi ng-tlv"/>.
The receiver of the Crypto-Binding TLV MUST verify that the version The receiver of the Crypto-Binding TLV <bcp14>MUST</bcp14> verify that the versi on
received in the Crypto-Binding TLV matches the version sent by the received in the Crypto-Binding TLV matches the version sent by the
receiver in the TEAP version negotiation.</t> receiver in the TEAP version negotiation.</t>
<t>Intermediate results are signaled via the Intermediate-Result TLV (<x ref target="intermediate-result-tlv"/>). <t>Intermediate results are signaled via the Intermediate-Result TLV (<x ref target="intermediate-result-tlv"/>).
However, the Crypto-Binding TLV MUST be validated before any However, the Crypto-Binding TLV <bcp14>MUST</bcp14> be validated before any
Intermediate-Result TLV or Result TLV is examined. If the Intermediate-Result TLV or Result TLV is examined. If the
Crypto-Binding TLV fails to be validated for any reason, then it is a Crypto-Binding TLV fails to be validated for any reason, then it is a
fatal error and is handled as described in <xref target="phase-2-errors"/>.</t> fatal error and is handled as described in <xref target="phase-2-errors"/>.</t>
<t>The true success or failure of TEAP is conveyed by the Result TLV, <t>The true success or failure of TEAP is conveyed by the Result TLV
with value Success or Failure. However, as EAP terminates with either with value Success or Failure. However, as EAP terminates with either
a cleartext EAP Success or Failure, a peer will also receive a a cleartext EAP Success or Failure, a peer will also receive a
cleartext EAP Success or Failure. The received cleartext EAP Success cleartext EAP Success or Failure. The received cleartext EAP Success
or Failure MUST match that received in the Result TLV; the peer SHOULD or Failure <bcp14>MUST</bcp14> match that received in the Result TLV; the peer <
silently discard those cleartext EAP Success or Failure messages which bcp14>SHOULD</bcp14>
silently discard those cleartext EAP Success or Failure messages that
do not coincide with the status sent in the protected Result TLV.</t> do not coincide with the status sent in the protected Result TLV.</t>
</section> </section>
<section anchor="phase1"> <section anchor="phase1">
<name>TEAP Authentication Phase 1: Tunnel Establishment</name> <name>TEAP Authentication Phase 1: Tunnel Establishment</name>
<t>TEAP relies on the TLS handshake <xref target="RFC8446"/> to establis h an <t>TEAP relies on the TLS handshake <xref target="RFC8446"/> to establis h an
authenticated and protected tunnel. The TLS version offered by the authenticated and protected tunnel. The TLS version offered by the
peer and server MUST be TLS version 1.2 <xref target="RFC5246"/> or later. This peer and server <bcp14>MUST</bcp14> be TLS version 1.2 <xref target="RFC5246"/>
version of the TEAP implementation MUST support the following TLS or later. This
version of the TEAP implementation <bcp14>MUST</bcp14> support the following TLS
cipher suites:</t> cipher suites:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</t> <t>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</t>
</li> </li>
<li> <li>
<t>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</t> <t>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</t>
</li> </li>
</ul> </ul>
<t>Other cipher suites MAY be supported. Implementations MUST implement <!-- [rfced] Section 4.3 of [RFC9325] states the following:
the recommended cipher suites in <xref section="4.2" sectionFormat="comma" targe
t="RFC9325"/> for TLS 1.2, "This document does not specify any cipher suites for TLS 1.3. Readers are
referred to Section 9.1 of [RFC8446] for cipher suite recommendations."
It may be more helpful to the reader to clarify that Section 4.3 of [RFC9325]
points to Section 9.1 of [RFC8446]. Or perhaps this sentence should simply
point to Section 9.1 of [RFC8446]?
Current:
Implementations MUST implement the recommended cipher suites in
[RFC9325], Section 4.2 for TLS 1.2, and in [RFC9325], Section 4.3 for TLS 1.3.
Perhaps:
Implementations MUST implement the recommended cipher suites in
[RFC9325], Section 4.2 for TLS 1.2 and in [RFC8446], Section 9.1 for TLS 1.3.
-->
<t>Other cipher suites <bcp14>MAY</bcp14> be supported. Implementations
<bcp14>MUST</bcp14> implement
the recommended cipher suites in <xref section="4.2" sectionFormat="comma" targe
t="RFC9325"/> for TLS 1.2
and in <xref section="4.3" sectionFormat="comma" target="RFC9325"/> for TLS 1.3. </t> and in <xref section="4.3" sectionFormat="comma" target="RFC9325"/> for TLS 1.3. </t>
<t>It is REQUIRED that anonymous <t>It is <bcp14>REQUIRED</bcp14> that anonymous
cipher suites such as TLS_DH_anon_WITH_AES_128_CBC_SHA <xref target="RFC5246"/> only cipher suites such as TLS_DH_anon_WITH_AES_128_CBC_SHA <xref target="RFC5246"/> only
be used in the case when the inner method provides be used in the case when the inner method provides
mutual authentication, key generation, and resistance to on-path mutual authentication, key generation, and resistance to on-path
and dictionary attacks. TLS cipher suites that do not provide and dictionary attacks. TLS cipher suites that do not provide
confidentiality MUST NOT be used. During the TEAP Phase 1, the TEAP endpoints M confidentiality <bcp14>MUST NOT</bcp14> be used. During the TEAP Phase 1, the T
AY negotiate TLS compression. EAP endpoints <bcp14>MAY</bcp14> negotiate TLS compression.
During TLS tunnel establishment, TLS extensions MAY be used. For During TLS tunnel establishment, TLS extensions <bcp14>MAY</bcp14> be used. For
instance, the Certificate Status Request extension <xref target="RFC6066"/> and the instance, the Certificate Status Request extension <xref target="RFC6066"/> and the
Multiple Certificate Status Request extension <xref target="RFC6961"/> can be us ed Multiple Certificate Status Request extension <xref target="RFC6961"/> can be us ed
to leverage a certificate-status protocol such as Online Certificate to leverage a certificate-status protocol such as the Online Certificate
Status Protocol (OCSP) <xref target="RFC6960"/> to check the validity of server Status Protocol (OCSP) <xref target="RFC6960"/> to check the validity of server
certificates. TLS renegotiation indications defined in RFC 5746 certificates. TLS renegotiation indications defined in
<xref target="RFC5746"/> MUST be supported.</t> <xref target="RFC5746"/> <bcp14>MUST</bcp14> be supported.</t>
<t>Use of TLS-PSK is NOT RECOMMENDED. TEAP has not been designed to wor <t>Use of TLS-PSK is <bcp14>NOT RECOMMENDED</bcp14>. TEAP has not been
k designed to work
with TLS-PSK, and no use-cases, security analyses, or implementations with TLS-PSK, and no use cases, security analyses, or implementations
have been done. TLS-PSK may work (or not) with TEAP, depending on the have been done. TLS-PSK may work (or not) with TEAP, depending on the
status of a particular implementation, and it is therefore not useful to status of a particular implementation, and it is therefore not useful to
deploy it.</t> deploy it.</t>
<t>The EAP server initiates the TEAP conversation with an EAP request <t>The EAP server initiates the TEAP conversation with an EAP request
containing a TEAP/Start packet. This packet includes a set Start (S) containing a TEAP/Start packet. This packet includes a set Start (S)
bit, the TEAP version as specified in <xref target="version-negotiation"/>, and an authority bit, the TEAP version as specified in <xref target="version-negotiation"/>, and an authority
identity TLV. The TLS payload in the initial packet is empty. The identity TLV. The TLS payload in the initial packet is empty. The
authority identity TLV (Authority-ID TLV) is used to provide the peer authority identity TLV (Authority-ID TLV) is used to provide the peer
a hint of the server's identity that may be useful in helping the a hint of the server's identity that may be useful in helping the
peer select the appropriate credential to use. Assuming that the peer select the appropriate credential to use. Assuming that the
peer supports TEAP, the conversation continues with the peer sending peer supports TEAP, the conversation continues with the peer sending
an EAP-Response packet with EAP type of TEAP with the Start (S) bit an EAP-Response packet with EAP type of TEAP with the Start (S) bit
clear and the version as specified in <xref target="version-negotiation"/>. Thi s message clear and the version as specified in <xref target="version-negotiation"/>. Thi s message
encapsulates one or more TLS handshake messages. If the TEAP version encapsulates one or more TLS handshake messages. If the TEAP version
negotiation is successful, then the TEAP conversation continues until negotiation is successful, then the TEAP conversation continues until
the EAP server and EAP peer are ready to enter Phase 2. When the the EAP server and EAP peer are ready to enter Phase 2. When the
full TLS handshake is performed, then the first payload of TEAP Phase full TLS handshake is performed, then the first payload of TEAP Phase
2 MAY be sent along with a server-finished handshake message to 2 <bcp14>MAY</bcp14> be sent along with a server-finished handshake message to
reduce the number of round trips.</t> reduce the number of round trips.</t>
<t>TEAP implementations MUST support mutual peer authentication during <t>TEAP implementations <bcp14>MUST</bcp14> support mutual peer authenti cation during
tunnel establishment using the TLS cipher suites specified in this tunnel establishment using the TLS cipher suites specified in this
section. The TEAP peer does not need to authenticate as part of the section. The TEAP peer does not need to authenticate as part of the
TLS exchange but can alternatively be authenticated through TLS exchange but can alternatively be authenticated through
additional exchanges carried out in Phase 2.</t> additional exchanges carried out in Phase 2.</t>
<t>The TEAP tunnel protects peer identity information exchanged during <t>The TEAP tunnel protects peer identity information exchanged during
Phase 2 from disclosure outside the tunnel. Implementations that Phase 2 from disclosure outside the tunnel. Implementations that
wish to provide identity privacy for the peer identity need to wish to provide identity privacy for the peer identity need to
carefully consider what information is disclosed outside the tunnel carefully consider what information is disclosed outside the tunnel
prior to Phase 2. TEAP implementations SHOULD support the immediate prior to Phase 2. TEAP implementations <bcp14>SHOULD</bcp14> support the immedi ate
renegotiation of a TLS session to initiate a new handshake message renegotiation of a TLS session to initiate a new handshake message
exchange under the protection of the current cipher suite. This exchange under the protection of the current cipher suite. This
allows support for protection of the peer's identity when using TLS allows support for protection of the peer's identity when using TLS
client authentication. An example of the exchanges using TLS client authentication. An example of the exchanges using TLS
renegotiation to protect privacy is shown in Appendix C.</t> renegotiation to protect privacy is shown in <xref target="appendix-c-examples"/ >.</t>
</section> </section>
<section anchor="server-certificate-requirements"> <section anchor="server-certificate-requirements">
<name>Server Certificate Requirements</name> <name>Server Certificate Requirements</name>
<t>Server Certificates MUST include a subjectAltName extension, with the <t>Server certificates <bcp14>MUST</bcp14> include a subjectAltName
dnsName attribute containing an FQDN string. Server certificates MAY also incl extension, with the dnsName attribute containing a Fully Qualified
ude a SubjectDN containing a single element, "CN=" containing the FQDN of the se Domain Name (FQDN) string. Server certificates <bcp14>MAY</bcp14>
rver. However, this use of SubjectDN is deprecated for TEAP, and is forbidden also include a SubjectDN containing a single element, "CN=",
in <xref section="2" sectionFormat="comma" target="RFC9525"/>.</t> which contains the FQDN of the server. However, this use of SubjectDN i
<t>The KeyUsage extension MAY be included, but are not required.</t> s
<t>The ExtendedKeyUsage extensions defined in <xref target="RFC5280"/> M deprecated for TEAP and is forbidden in <xref section="2"
AY also be included, but their use is discouraged. Systems SHOULD use a private sectionFormat="comma" target="RFC9525"/>.</t>
Certification Authority (CA) for EAP in preference to public CAs. The most com <t>The KeyUsage extensions <bcp14>MAY</bcp14> be included but are not re
monly used public CAs are focused on the web, and those certificates are not alw quired.</t>
ays suitable for use with EAP. In contrast, private CAs can be designed for any <!-- [rfced] Please review the following sentence. RFC 5280 doesn't use the
purposes, and can be restricted to an enterprise or an other organization.</t> term "ExtendedKeyUsage" but does use "anyExtendedKeyUsage" and
"Extended Key Usage". Let us know if the text below should be clarified.
Current:
The ExtendedKeyUsage extensions defined in [RFC5280] MAY also be
included, but their use is discouraged.
-->
<t>The ExtendedKeyUsage extensions defined in <xref target="RFC5280"/> <
bcp14>MAY</bcp14> also be included, but their use is discouraged. Systems <bcp1
4>SHOULD</bcp14> use a private Certification Authority (CA) for EAP in preferenc
e to public CAs. The most commonly used public CAs are focused on the web, and
those certificates are not always suitable for use with EAP. In contrast, priva
te CAs can be designed for any purposes and can be restricted to an enterprise o
r an other organization.</t>
</section> </section>
<section anchor="server-certificate-validation"> <section anchor="server-certificate-validation">
<name>Server Certificate Validation</name> <name>Server Certificate Validation</name>
<t>As part of the TLS negotiation, the server usually presents a <t>As part of the TLS negotiation, the server usually presents a
certificate to the peer. In most cases the certificate needs to be certificate to the peer. In most cases, the certificate needs to be
validated, but there are a number of situations where the EAP peer validated, but there are a number of situations where the EAP peer
need not do certificate validation:</t> does not need to do certificate validation:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>when the peer has the Server's End Entity (EE) certificate pinned or loaded directly into it's trusted anchor information <xref target="RFC4949"/ >;</t> <t>when the peer has the server's End Entity (EE) certificate pinned or loaded directly into it's trusted anchor information <xref target="RFC4949"/ >;</t>
</li> </li>
<li> <li>
<t>when the peer is requesting server unauthenticated provisioning;< /t> <t>when the peer is requesting server unauthenticated provisioning;< /t>
</li> </li>
<li> <li>
<t>when the peer is certain that it will be using an authenticated i nner method.</t> <t>when the peer is certain that it will be using an authenticated i nner method.</t>
</li> </li>
</ul> </ul>
<t>In some cases such as onboarding (or "bootstrapping"), the certificat e <t>In some cases, such as onboarding (or "bootstrapping"), the certifica te
validation may be delayed. However, once the onboarding has taken validation may be delayed. However, once the onboarding has taken
place, the validation steps described below MUST still be performed.</t> place, the validation steps described below <bcp14>MUST</bcp14> still be perform
<t>In all other cases, the EAP peer MUST validate the server certificate ed.</t>
. This <t>In all other cases, the EAP peer <bcp14>MUST</bcp14> validate the ser
ver certificate. This
validation is done in the same manner as is done for EAP-TLS, which is validation is done in the same manner as is done for EAP-TLS, which is
discussed in <xref section="5.3" sectionFormat="comma" target="RFC9190"/> and in <xref section="5.3" sectionFormat="comma" target="RFC5216"/>. discussed in <xref section="5.3" sectionFormat="comma" target="RFC9190"/> and in <xref section="5.3" sectionFormat="comma" target="RFC5216"/>.
Further guidance on server identity validation can be found in Further guidance on server identity validation can be found in
<xref section="6" sectionFormat="comma" target="RFC9525"/>.</t> <xref section="6" sectionFormat="comma" target="RFC9525"/>.</t>
<t>Where the EAP peer has an NAI, EAP peers MUST use the realm to perfor <!-- [rfced] FYI: For the following sentence, we note that RFC 9525
m does not have a Section 6.2.1, but a list of reference identifiers is
provided in Section 6.1.2 of RFC 9525; therefore, we have updated the
citation accordingly. Please review and let us know of any objections.
Original:
The realm is used both to construct the list of reference identifiers
as defined in [RFC9525], Section 6.2.1, and as the "source domain"
field of that same section.
Current:
The realm is used both to construct the list of reference identifiers
as defined in [RFC9525], Section 6.1.2, and as the "source domain"
field of that same section.
-->
<t>Where the EAP peer has an NAI, EAP peers <bcp14>MUST</bcp14> use the realm to
perform
the DNS-ID validation as per <xref section="6" sectionFormat="comma" target="RFC 9525"/>. the DNS-ID validation as per <xref section="6" sectionFormat="comma" target="RFC 9525"/>.
The realm is used both to construct the list of reference identifiers The realm is used both to construct the list of reference identifiers
as defined in <xref section="6.2.1" sectionFormat="comma" target="RFC9525"/>, an d as the as defined in <xref section="6.1.2" sectionFormat="comma" target="RFC9525"/>, an d as the
"source domain" field of that same section.</t> "source domain" field of that same section.</t>
<t>When performing server certificate validation, implementations MUST <t>When performing server certificate validation, implementations <bcp14 >MUST</bcp14>
also support the rules in <xref target="RFC5280"/> for validating certificates also support the rules in <xref target="RFC5280"/> for validating certificates
against a known trust anchor. In addition, implementations MUST against a known trust anchor. In addition, implementations <bcp14>MUST</bcp14>
support matching the realm portion of the peer's NAI against a support matching the realm portion of the peer's NAI against a
SubjectAltName of type dnsName within the server certificate. SubjectAltName of type dnsName within the server certificate.
However, in certain deployments, this comparison might not be However, in certain deployments, this comparison might not be
appropriate or enabled.</t> appropriate or enabled.</t>
<t>In most situations, the EAP peer will have no network access during <t>In most situations, the EAP peer will have no network access during
the authentication process. It will therefore have no way of correlating the authentication process. It will therefore have no way of correlating
the server identity given in the certificate presented by the EAP the server identity given in the certificate presented by the EAP
server with a hostname, as is done with other protocols such as HTTPS. server with a hostname, as is done with other protocols such as HTTPS.
Therefore, if the EAP peer has no preconfigured trust anchor, it will Therefore, if the EAP peer has no preconfigured trust anchor, it will
have few, if any ways of validating the servers certificate.</t> have few, if any, ways of validating the server's certificate.</t>
<section anchor="client-certs-phase1"> <section anchor="client-certs-phase1">
<name>Client Certificates sent during Phase 1</name> <name>Client Certificates Sent During Phase 1</name>
<t>Note that since TLS client certificates are sent in the clear with TLS 1.2, if <t>Note that since TLS client certificates are sent in the clear with TLS 1.2, if
identity protection is required, then it is possible for the TLS identity protection is required, then it is possible for the TLS
authentication to be renegotiated after the first server authentication to be renegotiated after the first server
authentication. To accomplish this, the server will typically not authentication. To accomplish this, the server will typically not
request a certificate in the server_hello; then, after the request a certificate in the server_hello; then, after the
server_finished message is sent and before TEAP Phase 2, the server server_finished message is sent and before TEAP Phase 2, the server
MAY send a TLS hello_request. This allows the peer to perform client <bcp14>MAY</bcp14> send a TLS hello_request.
authentication by sending a client_hello if it wants to or send a This allows the peer to perform client
authentication by sending a client_hello if it wants to or sending a
no_renegotiation alert to the server indicating that it wants to no_renegotiation alert to the server indicating that it wants to
continue with TEAP Phase 2 instead. Assuming that the peer permits continue with TEAP Phase 2 instead. Assuming that the peer permits
renegotiation by sending a client_hello, then the server will respond renegotiation by sending a client_hello, then the server will respond
with server_hello, certificate, and certificate_request messages. with server_hello, certificate, and certificate_request messages.
The peer replies with certificate, client_key_exchange, and The peer replies with certificate, client_key_exchange, and
certificate_verify messages. Since this renegotiation occurs within certificate_verify messages. Since this renegotiation occurs within
the encrypted TLS channel, it does not reveal client certificate the encrypted TLS channel, it does not reveal client certificate
details. It is possible to perform certificate authentication using details. It is possible to perform certificate authentication using
EAP (for example, EAP-TLS) within the TLS session in TEAP EAP (for example, EAP-TLS) within the TLS session in TEAP
Phase 2 instead of using TLS handshake renegotiation.</t> Phase 2 instead of using TLS handshake renegotiation.</t>
<t>When TLS 1.3 or later is used, it is RECOMMENDED that client <t>When TLS 1.3 or later is used, it is <bcp14>RECOMMENDED</bcp14> tha
certificates are sent in Phase 1, instead of via Phase 2 and EAP-TLS. t client
certificates are sent in Phase 1 instead of via Phase 2 and EAP-TLS.
Doing so will reduce the number of round trips. Further discussion of Doing so will reduce the number of round trips. Further discussion of
this issue is given below in <xref target="inner-method-limitations"/></t> this issue is given below in <xref target="inner-method-limitations"/></t>
</section> </section>
</section> </section>
<section anchor="resumption"> <section anchor="resumption">
<name>Resumption</name> <name>Resumption</name>
<t>For resumption, <xref section="5.7" sectionFormat="comma" target="RFC 9190"/> discusses EAP-TLS resumption <t>For resumption, <xref section="5.7" sectionFormat="comma" target="RFC 9190"/> discusses EAP-TLS resumption
for all versions of TLS, and is incorporated herein by reference. for all versions of TLS and is incorporated herein by reference.
<xref section="4" sectionFormat="comma" target="RFC9427"/> is also incorporated by reference, as it <xref section="4" sectionFormat="comma" target="RFC9427"/> is also incorporated by reference, as it
provides generic discussion of resumption for TLS-based EAP methods provides generic discussion of resumption for TLS-based EAP methods
when TLS 1.3 is used.</t> when TLS 1.3 is used.</t>
<t>This document only describes TEAP issues when resumption is used for <t>This document only describes TEAP issues when resumption is used for
TLS versions of 1.2 and earlier. It also describes resumption issues TLS versions of 1.2 and earlier. It also describes resumption issues
which are specific to TEAP for TLS 1.3.</t> that are specific to TEAP for TLS 1.3.</t>
<t>If the server agrees to resume the session, Phase 2 is bypassed <t>If the server agrees to resume the session, Phase 2 is bypassed
entirely. If the server does not agree to resume the session, then entirely. If the server does not agree to resume the session, then
the server rejects the resumption as per <xref section="5.7" sectionFormat="comm a" target="RFC9190"/>. It the server rejects the resumption as per <xref section="5.7" sectionFormat="comm a" target="RFC9190"/>. It
then continues with a full handshake. After the full TLS handshake then continues with a full handshake. After the full TLS handshake
has completed, both EAP server and peer MUST proceed with Phase 2.</t> has completed, both EAP server and peer <bcp14>MUST</bcp14> proceed with Phase 2
<t>All TEAP implementations MUST support resumption. Using resumption .</t>
<t>All TEAP implementations <bcp14>MUST</bcp14> support resumption. Usi
ng resumption
can significantly improve the scalability and stability of can significantly improve the scalability and stability of
authentication systems. For example, some environments such as authentication systems. For example, some environments such as
universities may have users re-authenticating multiple times a day, if universities may have users re-authenticating multiple times a day, if
not hourly. Failure to implement resumption would increase the load not hourly. Failure to implement resumption would increase the load
on the user database by orders of magnitude, leading to unnecessary on the user database by orders of magnitude, leading to unnecessary
cost.</t> cost.</t>
<t>The following sections describe how a TEAP session can be resumed <t>The following sections describe how a TEAP session can be resumed
based on server-side or client-side state.</t> based on server-side or client-side state.</t>
<section anchor="resume-server-state"> <section anchor="resume-server-state">
<name>TLS Session Resumption Using Server State</name> <name>TLS Session Resumption Using Server State</name>
skipping to change at line 511 skipping to change at line 559
cache the Session ID, master secret, and cipher suite. The cache the Session ID, master secret, and cipher suite. The
peer attempts to resume a session by including a valid Session ID peer attempts to resume a session by including a valid Session ID
from a previous TLS handshake in its ClientHello message. If the from a previous TLS handshake in its ClientHello message. If the
server finds a match for the Session ID and is willing to establish a server finds a match for the Session ID and is willing to establish a
new connection using the specified session state, the server will new connection using the specified session state, the server will
respond with the same Session ID and proceed with the TEAP Phase 1 respond with the same Session ID and proceed with the TEAP Phase 1
tunnel establishment based on a TLS abbreviated handshake.</t> tunnel establishment based on a TLS abbreviated handshake.</t>
</section> </section>
<section anchor="tls-session-resumption-using-client-state"> <section anchor="tls-session-resumption-using-client-state">
<name>TLS Session Resumption Using Client State</name> <name>TLS Session Resumption Using Client State</name>
<t>TEAP supports the resumption of sessions based on state being store d <t>TEAP supports the resumption of sessions based on the state being stored
on the client side using the TLS SessionTicket extension techniques on the client side using the TLS SessionTicket extension techniques
described in <xref target="RFC5077"/> and <xref target="RFC9190"/>.</t> described in <xref target="RFC5077"/> and <xref target="RFC9190"/>.</t>
</section> </section>
</section> </section>
<section anchor="teap-authentication-phase-2-tunneled-authentication"> <section anchor="teap-authentication-phase-2-tunneled-authentication">
<name>TEAP Authentication Phase 2: Tunneled Authentication</name> <name>TEAP Authentication Phase 2: Tunneled Authentication</name>
<t>The second portion of the TEAP authentication occurs immediately <t>The second portion of the TEAP authentication occurs immediately
after successful completion of Phase 1. Phase 2 occurs even if both after successful completion of Phase 1. Phase 2 occurs even if both
peer and authenticator are authenticated in the Phase 1 TLS peer and authenticator are authenticated in the Phase 1 TLS
negotiation. Phase 2 MUST NOT occur if the Phase 1 TLS handshake negotiation. Phase 2 <bcp14>MUST NOT</bcp14> occur if the Phase 1 TLS handshake
fails, as that will compromise the security as the tunnel has not fails, as that will compromise the security as the tunnel has not
been established successfully. Phase 2 consists of a series of been established successfully. Phase 2 consists of a series of
requests and responses encapsulated in TLV objects defined in requests and responses encapsulated in TLV objects defined in
<xref target="teap-tlv-format"/>. Phase 2 MUST always end with a Crypto-Binding TLV <xref target="teap-tlv-format"/>. Phase 2 <bcp14>MUST</bcp14> always end with a Crypto-Binding TLV
exchange described in <xref target="crypto-binding-tlv"/> and a protected termin ation exchange described in <xref target="crypto-binding-tlv"/> and a protected termin ation
exchange described in <xref target="protected-termination"/>.</t> exchange described in <xref target="protected-termination"/>.</t>
<t>If the peer is not authenticated in Phase 1, the TEAP peer SHOULD sen <t>If the peer is not authenticated in Phase 1, the TEAP peer <bcp14>SHO
d ULD</bcp14> send
one or more Identity-Hint TLVs (<xref target="identity-hint-tlv"/> as soon as th one or more Identity-Hint TLVs (<xref target="identity-hint-tlv"/>) as soon as t
e he
TLS connection has been established. This information lets the TEAP TLS connection has been established. This information lets the TEAP
server choose an authentication type which is appropriate for that server choose an authentication type that is appropriate for that
identity. When the TEAP peer does not provide an Identity-Hint TLV, identity. When the TEAP peer does not provide an Identity-Hint TLV,
the TEAP server does not know which inner method is supported by the the TEAP server does not know which inner method is supported by the
peer. It must necessarily choose an inner method, and propose it to peer. It must choose an inner method and propose it to
the peer, which may reject that inner method. The result will be that the peer, which may reject that inner method. As a result,
the peer fails to authenticate, and fails to obtain network access.</t> the peer fails to authenticate and fails to obtain network access.</t>
<t>The TLV exchange includes the execution of zero or more inner <t>The TLV exchange includes the execution of zero or more inner
methods within the protected tunnel as described in <xref target="inner-eap"/> methods within the protected tunnel as described in Sections <xref target="inner
and <xref target="inner-password"/>. A server MAY proceed directly to the -eap" format="counter"/>
protected termination exchange, without performing any inner and <xref target="inner-password" format="counter"/>. A server <bcp14>MAY</bcp1
4> proceed directly to the
protected termination exchange without performing any inner
authentication if it does not wish to request further authentication authentication if it does not wish to request further authentication
from the peer. A server MAY request one or more authentications from the peer. A server <bcp14>MAY</bcp14> request one or more authentications
within the protected tunnel. After completion of each inner method, within the protected tunnel. After completion of each inner method,
the server decides whether or not to begin another inner method, or the server decides whether or not to begin another inner method or
to send a Result TLV.</t> to send a Result TLV.</t>
<t>Implementations MUST support at least two sequential inner methods, <t>Implementations <bcp14>MUST</bcp14> support at least two sequential i
which allows both Machine and User authentication to be performed. nner methods,
Implementations SHOULD also limit the number of sequential inner which allows both machine and user authentication to be performed.
Implementations <bcp14>SHOULD</bcp14> also limit the number of sequential inner
authentications, as there is no reason to perform a large number of inner authentications, as there is no reason to perform a large number of inner
authentications in one TEAP conversation.</t> authentications in one TEAP conversation.</t>
<t>Implementations wishing to use their own proprietary authentication <t>Implementations wishing to use their own proprietary authentication
method, may substitute the EAP-Payload or Basic-Password-Auth-Req TLV method may substitute the EAP-Payload or Basic-Password-Auth-Req TLV
for the Vendor-Specific TLV which carries another authentication for the Vendor-Specific TLV, which carries another authentication
method. Any vendor-specific authentication method MUST support method. Any vendor-specific authentication method <bcp14>MUST</bcp14> support
calculation of the Crypto-Binding TLV, and MUST use calculation of the Crypto-Binding TLV and <bcp14>MUST</bcp14> use
Intermediate-Result TLV and Result TLV as is done with other Intermediate-Result TLV and Result TLV as is done with other
authentication methods.</t> authentication methods.</t>
<section anchor="inner-method-ordering"> <section anchor="inner-method-ordering">
<name>Inner Method Ordering</name> <name>Inner Method Ordering</name>
<t>Due to issues noted in <xref target="limitations"/>, the order of i nner methods has <t>Due to issues noted in <xref target="limitations"/>, the order of i nner methods has
implications for both security and interoperability.</t> implications for both security and interoperability.</t>
<t>Where the authentication is expected to use multiple inner methods, <t>Where the authentication is expected to use multiple inner methods,
implementations SHOULD order the methods so that a method which implementations <bcp14>SHOULD</bcp14> order the methods so that a method that
derives an EMSK is used first, before any other method. This ordering derives an Extended Master Session Key (EMSK) is used first before any other met
helps to securely tie the inner method to TLS session, and therefore hod. This ordering
helps to securely tie the inner method to the TLS session and therefore
can prevent attacks.</t> can prevent attacks.</t>
<t>Implementations SHOULD support both EAP and basic password for inne <!-- [rfced] Should "passwords" be plural in this instance?
r
methods. Implementations which support multiple types of inner method Original:
(User and Machine) MUST support all of those methods in any order or Implementations SHOULD support both EAP and basic password for inner
methods.
Perhaps:
Implementations SHOULD support both EAP and basic passwords for inner
methods.
-->
<t>Implementations <bcp14>SHOULD</bcp14> support both EAP and basic pa
ssword for inner
methods. Implementations that support multiple types of inner methods
(User and Machine) <bcp14>MUST</bcp14> support all of those methods in any order
or
combination. That is, it is explicitly permitted to "mix and match" combination. That is, it is explicitly permitted to "mix and match"
inner methods.</t> inner methods.</t>
<t>For example, a server can request User authentication from the peer <t>For example, a server can request user authentication from the peer
, and have the peer return machine authentication (or vice versa). If
and have the peer return Machine authentication (or vice versa). If the server is configured to accept machine authentication, it <bcp14>MUST</bcp14
the server is configured to accept Machine authentication, it MUST >
accept that response. If that authentication succeeds, then depending accept that response. If that authentication succeeds, then depending
on local policy, the server SHOULD proceed with requesting User on local policy, the server <bcp14>SHOULD</bcp14> proceed with requesting user
authentication again.</t> authentication again.</t>
<t>Similarly, a peer which is configured to support multiple types of <t>Similarly, a peer that is configured to support multiple types of
inner method (User and Machine) can return a method other that what inner methods (User and Machine) can return a method other than what
the server requested. This action is usually taken by the peer so that it order s the server requested. This action is usually taken by the peer so that it order s
inner methods for increased security. See inner methods for increased security. See
<xref target="choosing-inner-methods"/> for further discussion of this issue.</t > <xref target="choosing-inner-methods"/> for further discussion of this issue.</t >
<t>However, the peer and server MUST NOT assume that either will skip <t>However, the peer and server <bcp14>MUST NOT</bcp14> assume that ei ther will skip
inner methods or other TLV exchanges, as the other peer might have inner methods or other TLV exchanges, as the other peer might have
a different security policy. The peer may have roamed to a network a different security policy. The peer may have roamed to a network
that requires conformance with a different authentication policy, or that requires conformance with a different authentication policy, or
the peer may request the server take additional action (e.g., channel the peer may request the server take additional action (e.g., channel
binding) through the use of the Request-Action TLV as defined in binding) through the use of the Request-Action TLV as defined in
<xref target="request-action-tlv"/>.</t> <xref target="request-action-tlv"/>.</t>
<t>The completion of each inner method is signaled by an <t>The completion of each inner method is signaled by an
Intermediate-Result TLV. Where the Intermediate-Result TLV indicates Intermediate-Result TLV. Where the Intermediate-Result TLV indicates
failure, an Error TLV SHOULD also be included, using the most descriptive error code possible. The failure, an Error TLV <bcp14>SHOULD</bcp14> also be included using the most desc riptive error code possible. The
Intermediate-Result TLV may be accompanied by another TLV indicating Intermediate-Result TLV may be accompanied by another TLV indicating
that the server wishes to perform a subsequent authentication. When that the server wishes to perform a subsequent authentication. When
all inner methods have completed, the server MUST send a Result all inner methods have completed, the server <bcp14>MUST</bcp14> send a Result
TLV indicating success or failure instead of a TLV which carries an TLV indicating success or failure instead of a TLV that carries an
inner method.</t> inner method.</t>
</section> </section>
<section anchor="inner-eap"> <section anchor="inner-eap">
<name>Inner EAP Authentication</name> <name>Inner EAP Authentication</name>
<t>EAP <xref target="RFC3748"/> prohibits use of multiple authenticati on methods within <t>EAP <xref target="RFC3748"/> prohibits use of multiple authenticati on methods within
a single EAP conversation in order to limit vulnerabilities to on-path a single EAP conversation in order to limit vulnerabilities to on-path
attacks. TEAP addresses on-path attacks attacks. TEAP addresses on-path attacks
through support for cryptographic protection of the inner EAP through support for cryptographic protection of the inner EAP
exchange and cryptographic binding of the inner EAP exchange and cryptographic binding of the inner EAP
method(s) to the protected tunnel. Inner methods are executed serially method(s) to the protected tunnel. Inner methods are executed serially
in a sequence. This version of TEAP does not support initiating in a sequence. This version of TEAP does not support initiating
multiple inner methods simultaneously in parallel. The inner methods need multiple inner methods simultaneously in parallel. The inner methods need
not be distinct. For example, EAP-TLS (<xref target="RFC5216"/> and <xref targe t="RFC9190"/>) could be run twice as an inner not be distinct. For example, EAP-TLS (<xref target="RFC5216"/> and <xref targe t="RFC9190"/>) could be run twice as an inner
method, first using machine credentials followed by a second instance method, first using machine credentials, followed by a second instance
using user credentials.</t> using user credentials.</t>
<t>When EAP is used as an inner method, the EAP messages are carried w ithin EAP-Payload TLVs defined in <t>When EAP is used as an inner method, the EAP messages are carried w ithin EAP-Payload TLVs defined in
<xref target="eap-payload-tlv"/>. Note that in this use-case, TEAP is simply a <xref target="eap-payload-tlv"/>. Note that in this use case, TEAP is simply a
carrier for EAP, much as RADIUS is a carrier for EAP. The full EAP carrier for EAP, much as RADIUS is a carrier for EAP. The full EAP
state machine is run as normal, and is carried over the EAP-Payload state machine runs as normal and is carried over the EAP-Payload
TLV. Each distinct EAP authentication MUST be managed as a separate TLV. Each distinct EAP authentication <bcp14>MUST</bcp14> be managed as a separ
ate
EAP state machine.</t> EAP state machine.</t>
<t>A TEAP server therefore MUST begin an EAP authentication with an <t>A TEAP server therefore <bcp14>MUST</bcp14> begin an EAP authentica tion with an
EAP-Request/Identity (carried in an EAP-Payload TLV). However, a TEAP EAP-Request/Identity (carried in an EAP-Payload TLV). However, a TEAP
server MUST NOT finish the EAP conversation with an EAP Success or EAP server <bcp14>MUST NOT</bcp14> finish the EAP conversation with an EAP Success o
Failure packet, the Intermediate-Result TLV is used instead.</t> r EAP
<t>Upon completion of each EAP authentication in the tunnel, the serve Failure packet; the Intermediate-Result TLV is used instead.</t>
r MUST send <t>Upon completion of each EAP authentication in the tunnel, the serve
an Intermediate-Result TLV indicating the result of that authentication. When t r <bcp14>MUST</bcp14> send
he result indicates, success it MUST be accompanied by a Crypto-Binding TLV. The an Intermediate-Result TLV indicating the result of that authentication. When t
peer MUST respond to the Intermediate-Result TLV indicating its own result and he result indicates success, it <bcp14>MUST</bcp14> be accompanied by a Crypto-B
similarly on success MUST accompany the TLV with it's own Crypto-Binding TLV. inding TLV.
<!-- [rfced] May we rephrase the following sentence for improved readability?
Original:
The peer MUST respond to the Intermediate-Result TLV indicating its
own result and similarly on success MUST accompany the TLV with it's own
Crypto-Binding TLV.
Perhaps:
The peer MUST respond to the Intermediate-Result TLV indicating its
own result. Similarly, upon success, the peer MUST accompany the TLV with its
own Crypto-Binding TLV.
-->
The peer <bcp14>MUST</bcp14> respond to the Intermediate-Result TLV indicating i
ts own result and similarly on success <bcp14>MUST</bcp14> accompany the TLV wit
h its own Crypto-Binding TLV.
The Crypto-Binding TLV is The Crypto-Binding TLV is
further discussed in <xref target="crypto-binding-tlv"/> and further discussed in Sections <xref target="crypto-binding-tlv" format="counter"
<xref target="computing-compound-mac"/>. The Intermediate-Result TLVs can be /> and
included with other TLVs which indicate a subsequent authentication, <xref target="computing-compound-mac" format="counter"/>. The Intermediate-Resu
or with the Result TLV used in the protected termination lt TLVs can be
included with other TLVs that indicate a subsequent authentication or with the R
esult TLV used in the protected termination
exchange.</t> exchange.</t>
<t>If both peer and server indicate success, then the authentication i s <t>If both peer and server indicate success, then the authentication i s
considered successful. If either indicates failure, then the authentication is considered successful. If either indicates failure, then the authentication is
considered failed. The result of failure of an EAP authentication does not considered failed. The result of failure of an EAP authentication does not
always imply a failure of the overall authentication. If one always imply a failure of the overall authentication. If one
inner method fails, the server may attempt to authenticate inner method fails, the server may attempt to authenticate
the peer with a different method (EAP or password).</t> the peer with a different method (EAP or password).</t>
</section> </section>
<section anchor="inner-password"> <section anchor="inner-password">
<name>Inner Password Authentication</name> <name>Inner Password Authentication</name>
<t>The authentication server initiates password <t>The authentication server (AS) initiates password
authentication by sending a Basic-Password-Auth-Req TLV defined in authentication by sending a Basic-Password-Auth-Req TLV defined in
<xref target="bp-auth-req-tlv"/>. If the peer wishes to participate in password <xref target="bp-auth-req-tlv"/>. If the peer wishes to participate in password
authentication, then it responds with a Basic-Password-Auth-Resp TLV authentication, then it responds with a Basic-Password-Auth-Resp TLV that contai
as defined in <xref target="bp-auth-resp-tlv"/> that contains the username and p ns the username and password as defined in <xref target="bp-auth-resp-tlv"/>.
assword.
If it does not wish to perform password authentication, then it If it does not wish to perform password authentication, then it
responds with a NAK TLV indicating the rejection of the Basic-Password-Auth-Req responds with a Negative Acknowledgment (NAK) TLV indicating the rejection of th
TLV.</t> e Basic-Password-Auth-Req TLV.</t>
<t>The basic password authentication defined here is similar in functi <t>The basic password authentication defined here is similar in functi
onality to that used by EAP-TTLS (<xref target="RFC5281"/>) with inner password onality to that used by EAP-TTLS <xref target="RFC5281"/> with inner password au
authentication. It shares a similar security and risk analysis.</t> thentication. It shares a similar security and risk analysis.</t>
<t>Multiple round trips of password authentication requests and respon ses <t>Multiple round trips of password authentication requests and respon ses
MAY be used to support some "housekeeping" functions such as a <bcp14>MAY</bcp14> be used to support some "housekeeping" functions such as a
password or pin change before a user is considered to be password or pin change before a user is considered to be
authenticated. Multiple rounds MAY also be used to communicate a authenticated. Multiple rounds <bcp14>MAY</bcp14> also be used to communicate a
user's password, and separately a one-time password such as Time-Based One-Time user's password and, separately, a one-time password such as Time-Based One-Time
Passwords (TOTP) <xref target="RFC6238"/>.</t> Passwords (TOTPs) <xref target="RFC6238"/>.</t>
<t>Implementations MUST limit the number of rounds trips for password <t>Implementations <bcp14>MUST</bcp14> limit the number of round trips
for password
authentication. It is reasonable to use one or two round trips. authentication. It is reasonable to use one or two round trips.
Further round trips are likely to be problematic, and SHOULD be Further round trips are likely to be problematic and <bcp14>SHOULD</bcp14> be
avoided.</t> avoided.</t>
<t>The first Basic-Password-Auth-Req TLV received in a session MUST <t>The first Basic-Password-Auth-Req TLV received in a session <bcp14> MUST</bcp14>
include a prompt, which the peer displays to the user. Subsequent include a prompt, which the peer displays to the user. Subsequent
authentication rounds SHOULD include a prompt, but it is not always authentication rounds <bcp14>SHOULD</bcp14> include a prompt, but it is not alwa ys
necessary.</t> necessary.</t>
<!--[rfced] To clarify the usage of RFC 2119/8174 key words, may we
add "MUST" in the sentence below?
Original:
If the peer
receives subsequent Basic-Password-Auth-Req TLVs in the same
authentication session, it MUST NOT prompt for a Username, and
instead allow the user to enter only a password.
Perhaps:
If the peer
receives subsequent Basic-Password-Auth-Req TLVs in the same
authentication session, it MUST NOT prompt for a username and
MUST instead allow the user to enter only a password.
-->
<t>When the peer first receives a Basic-Password-Auth-Req TLV, it shou ld <t>When the peer first receives a Basic-Password-Auth-Req TLV, it shou ld
allow the user to enter both a Username and a Password, which are then allow the user to enter both a username and a password, which are then
placed in the Basic-Password-Auth-Resp TLV. If the peer receives placed in the Basic-Password-Auth-Resp TLV. If the peer receives
subsequent Basic-Password-Auth-Req TLVs in the same authentication subsequent Basic-Password-Auth-Req TLVs in the same authentication
session, it MUST NOT prompt for a Username, and instead allow the user session, it <bcp14>MUST NOT</bcp14> prompt for a username and instead allow the
to enter only a password. The peer MUST copy the Username used in the user
to enter only a password. The peer <bcp14>MUST</bcp14> copy the username used i
n the
first Basic-Password-Auth-Resp TLV into all subsequent first Basic-Password-Auth-Resp TLV into all subsequent
Basic-Password-Auth-Resp TLVs.</t> Basic-Password-Auth-Resp TLVs.</t>
<t>Servers MUST track the Username across multiple password rounds, an d <t>Servers <bcp14>MUST</bcp14> track the username across multiple pass word rounds and
reject authentication if the identity changes from one reject authentication if the identity changes from one
Basic-Password-Auth-Resp TLV to the next. There is no reason for a Basic-Password-Auth-Resp TLV to the next. There is no reason for a
user (or machine) to change identities in the middle of authentication.</t> user (or machine) to change identities in the middle of authentication.</t>
<t>Upon reception of a Basic-Password-Auth-Resp TLV in <t>Upon reception of a Basic-Password-Auth-Resp TLV in
the tunnel, the server MUST send an Intermediate-Result TLV the tunnel, the server <bcp14>MUST</bcp14> send an Intermediate-Result TLV
indicating the result. The peer MUST respond indicating the result. The peer <bcp14>MUST</bcp14> respond
to the Intermediate-Result TLV indicating its result. If the result to the Intermediate-Result TLV indicating its result. If the result
indicates success, the Intermediate-Result TLV MUST be accompanied by indicates success, the Intermediate-Result TLV <bcp14>MUST</bcp14> be accompanie
a Crypto-Binding TLV. The Crypto-Binding TLV is further discussed in d by
<xref target="crypto-binding-tlv"/> and <xref target="computing-compound-mac"/>. a Crypto-Binding TLV. The Crypto-Binding TLV is further discussed in Sections
</t> <xref target="crypto-binding-tlv" format="counter"/> and <xref target="computing
<t>The Intermediate-Result TLVs can be included with other TLVs which -compound-mac" format="counter"/>.</t>
indicate a subsequent authentication, or with the Result TLV used in <t>The Intermediate-Result TLVs can be included with other TLVs that
indicate a subsequent authentication or with the Result TLV used in
the protected termination exchange.</t> the protected termination exchange.</t>
<t>The use of EAP-FAST-GTC as defined in <xref target="RFC5421"/> is N <t>The use of EAP-FAST-GTC as defined in <xref target="RFC5421"/> is <
OT bcp14>NOT RECOMMENDED</bcp14> with TEAPv1 because EAP-FAST-GTC is not compliant
RECOMMENDED with TEAPv1 because EAP-FAST-GTC is not compliant with with
EAP-GTC defined in <xref target="RFC3748"/>. Implementations should instead mak e EAP-GTC defined in <xref target="RFC3748"/>. Implementations should instead mak e
use of the password authentication TLVs defined in this use of the password authentication TLVs defined in this
specification.</t> specification.</t>
</section> </section>
<section anchor="eap-mschapv2"> <section anchor="eap-mschapv2">
<name>EAP-MSCHAPv2</name> <name>EAP-MSCHAPv2</name>
<t>If using EAP-MSCHAPv2 <xref target="KAMATH"/> as an inner EAP metho <t>If using EAP-MSCHAPv2 <xref target="I-D.kamath-pppext-eap-mschapv2"
d, the EAP-FAST-MSCHAPv2 /> as an inner EAP method, the EAP-FAST-MSCHAPv2
variant defined in <xref section="3.2.3" sectionFormat="comma" target="RFC5422"/ variant defined in <xref section="3.2.3" sectionFormat="comma" target="RFC5422"/
> MUST be used, instead of the derivation defined in <xref target="MSCHAP"/>.</t > <bcp14>MUST</bcp14> be used instead of the derivation defined in <xref target=
> "MSCHAP"/>.</t>
<t>The difference between EAP-MSCHAPv2 and EAP-FAST-MSCHAPv2 is that t he <t>The difference between EAP-MSCHAPv2 and EAP-FAST-MSCHAPv2 is that t he
first and the second 16 octets of EAP-MSCHAPv2 Master Session Key (MSK) are swap first and the second 16 octets of the EAP-MSCHAPv2 Master Session Key (MSK) are
ped when it swapped when it
is used as the Inner Method Session Keys (IMSK) for TEAP.</t> is used as the Inner Method Session Keys (IMSKs) for TEAP.</t>
</section> </section>
<section anchor="inner-method-limitations"> <section anchor="inner-method-limitations">
<name>Limitations on inner methods</name> <name>Limitations on Inner Methods</name>
<t>Implementations SHOULD limit the permitted inner EAP methods to a <t>Implementations <bcp14>SHOULD</bcp14> limit the permitted inner EAP
methods to a
small set such as EAP-TLS and the EAP-FAST-MSCHAPv2 variant of small set such as EAP-TLS and the EAP-FAST-MSCHAPv2 variant of
EAP-MSCHAPv2. These EAP methods are the most commonly supported inner EAP-MSCHAPv2. These EAP methods are the most commonly supported inner
methods in TEAP, and are known to be interoperable among multiple methods in TEAP and are known to be interoperable among multiple
implementations.</t> implementations.</t>
<t>Other EAP methods such as EAP-pwd, EAP-SIM, EAP-AKA, or EAP-AKA' ca n <t>Other EAP methods such as EAP-pwd, EAP-SIM, EAP-AKA, or EAP-AKA' ca n
be used within a TEAP tunnel. Any EAP method which derives both MSK be used within a TEAP tunnel. Any EAP method that derives both MSK
and ESMK is likely to work as an inner method for TEAP, because and EMSK is likely to work as an inner method for TEAP, because
EAP-TLS has that behavior, and it works. EAP methods which derive EAP-TLS has that behavior and it works. EAP methods that derive
only MSK should work, as EAP-FAST-MSCHAPv2 has that behavior, and it only MSK should work, as EAP-FAST-MSCHAPv2 has that behavior, and it
works. Other EAP methods are untested, and may or may not work.</t> works. Other EAP methods are untested and may or may not work.</t>
<t>Tunneled EAP methods such as (PEAP) <xref target="PEAP"/>, EAP-TTLS <t>Tunneled EAP methods such as PEAP <xref target="PEAP"/>, EAP-TTLS <
<xref target="RFC5281"/>, and xref target="RFC5281"/>, and
EAP-FAST <xref target="RFC4851"/> MUST NOT be used for inner EAP authentication. EAP-FAST <xref target="RFC4851"/> <bcp14>MUST NOT</bcp14> be used for inner EAP
authentication.
There is no reason to have multiple layers of TLS in order to protect a There is no reason to have multiple layers of TLS in order to protect a
password exchange.</t> password exchange.</t>
<t>The EAP methods defined in <xref section="5" sectionFormat="comma" <t>The EAP methods defined in <xref section="5" sectionFormat="comma"
target="RFC3748"/> such as target="RFC3748"/>, such as
MD5-Challenge, One-Time Password (OTP), and Generic Token Card (GTC) MD5-Challenge, One-Time Password (OTP), and Generic Token Card (GTC),
do not derive a Master Session Key (MSK) or an Extended Master Session do not derive an MSK or an EMSK and are vulnerable to on-path attacks. The cons
Key (EMSK), and are vulnerable to on-path attacks. The construction truction
of the OTP and GTC methods makes this attack less relevant, as the of the OTP and GTC methods makes this attack less relevant, as the
information being sent is generally a one-time token. However, EAP-OTP information being sent is generally a one-time token. However, EAP-OTP
and EAP-GTC offer no benefit over the basic password authentication and EAP-GTC offer no benefit over the basic password authentication
defined in <xref target="inner-password"/>, which also does not perform crypto-b inding of defined in <xref target="inner-password"/>, which also does not perform crypto-b inding of
the inner method to the TLS session. These EAP methods are therefore the inner method to the TLS session. These EAP methods are therefore
not useful as phase 2 methods within TEAP.</t> not useful as Phase 2 methods within TEAP.</t>
<t>Other EAP methods are less widely used, and highly likely to not wo <t>Other EAP methods are less widely used and highly likely to not wor
rk k
as the inner EAP method for TEAP.</t> as the inner EAP method for TEAP.</t>
<t>In order to protect from on-path attacks, TEAP implementations MUST <t>In order to protect from on-path attacks, TEAP implementations <bcp14>MUST
NOT permit the use of inner EAP methods which fail to perform NOT</bcp14> permit the use of inner EAP methods that fail to perform
crypto-binding of the inner method to the TLS session.</t> crypto-binding of the inner method to the TLS session.</t>
<t>Implementations MUST NOT permit resumption for the inner EAP method s <t>Implementations <bcp14>MUST NOT</bcp14> permit resumption for the i nner EAP methods
such as EAP-TLS. If the user or machine needs to be authenticated, it such as EAP-TLS. If the user or machine needs to be authenticated, it
should use a method which provides full authentication. If the user or machine should use a method that provides full authentication. If the user or machine n
needs eeds
to do resumption, it can perform a full authentication once, and then to do resumption, it can perform a full authentication once and then
rely on the outer TLS session for resumption. This restriction rely on the outer TLS session for resumption. This restriction
applies also to all TLS-based EAP methods which can tunnel other EAP applies also to all TLS-based EAP methods that can tunnel other EAP
methods. As a result, this document updates <xref target="RFC9427"/>.</t> methods. As a result, this document updates <xref target="RFC9427"/>.</t>
<t>In general, the reason to use a non-TLS-based EAP method inside of a <t>In general, the reason to use a non-TLS-based EAP method inside of a
TLS-based EAP method such as TEAP is for privacy. Many previous EAP TLS-based EAP method such as TEAP is for privacy. Many previous EAP
methods may leak information about user identity, and those leaks are methods may leak information about user identity, and those leaks are
prevented by running the method inside of a protected TLS tunnel.</t> prevented by running the method inside of a protected TLS tunnel.</t>
<t>EAP-TLS is permitted in Phase 2 for two use-cases. The first is wh en <t>EAP-TLS is permitted in Phase 2 for two use cases. The first use c ase is when
TLS 1.2 is used, as the client certificate is not protected as with TLS 1.2 is used, as the client certificate is not protected as with
TLS 1.3. It is therefore RECOMMENDED that when TLS 1.3 is used for TLS 1.3. It is therefore <bcp14>RECOMMENDED</bcp14> that when TLS 1.3 is used fo
the outer TEAP exchange, the client certificate is sent in Phase 1, r
instead of doing EAP-TLS in Phase 2. This behavior will simplify the the outer TEAP exchange, the client certificate is sent in Phase 1
authentication exchange, and use fewer round trips than doing EAP-TLS instead of doing EAP-TLS in Phase 2. This behavior will simplify the
inside of TEAP.</t> authentication exchange and use fewer round trips than doing EAP-TLS
<t>The second use-case for EAP-TLS in Phase 2 is where both the user a inside of TEAP.</t>
nd <t>The second use case for EAP-TLS in Phase 2 is where both the user a
nd
machine use client certificates for authentication. Since TLS permits machine use client certificates for authentication. Since TLS permits
only one client certificate to be presented, only one certificate can only one client certificate to be presented, only one certificate can
be used in Phase 1. The second certificate is then presented via be used in Phase 1. The second certificate is then presented via
EAP-TLS in Phase 2.</t> EAP-TLS in Phase 2.</t>
<t>For basic password authentication, it is RECOMMENDED that this meth od <t>For basic password authentication, it is <bcp14>RECOMMENDED</bcp14> that this method
be only used for the exchange of one-time passwords. The existence of be only used for the exchange of one-time passwords. The existence of
password-based EAP methods such as EAP-pwd (<xref target="RFC5931"/> and password-based EAP methods such as EAP-pwd (<xref target="RFC5931"/> and
<xref target="RFC8146"/>) makes most clear-text password exchanges unnecessary. <xref target="RFC8146"/>) makes most cleartext password exchanges unnecessary.
The updates to EAP-pwd in <xref target="RFC8146"/> permit it to be used with The updates to EAP-pwd in <xref target="RFC8146"/> permit it to be used with
databases which store passwords in "salted" form, which greatly databases that store passwords in "salted" form, which greatly
increases security.</t> increases security.</t>
<t>Where no inner method provides an EMSK, the Crypto-Binding TLV <t>Where no inner method provides an EMSK, the Crypto-Binding TLV
offers little protection, as it cannot tie the inner EMSK to the TLS offers little protection, as it cannot tie the inner EMSK to the TLS
session via the TLS-PRF. As a result, the TEAP session will be session via the TLS-PRF. As a result, the TEAP session will be
vulnerable to on-path active attacks. Implementations and deployments vulnerable to on-path active attacks. Implementations and deployments
SHOULD adopt various mitigation strategies described in <xref section="3.2" sect <bcp14>SHOULD</bcp14> adopt various mitigation strategies described in <xref sec
ionFormat="comma" target="RFC7029"/>. Implementations also need to implement th tion="3.2" sectionFormat="comma" target="RFC7029"/>. Implementations also need
e inner method to implement the inner method
ordering described in {#key-derivations}, below, in order to fully prevent on-pa ordering described in <xref target="key-derivations"/> in order to fully prevent
th attacks.</t> on-path attacks.</t>
</section> </section>
<section anchor="protected-termination"> <section anchor="protected-termination">
<name>Protected Termination and Acknowledged Result Indication</name> <name>Protected Termination and Acknowledged Result Indication</name>
<t>A successful TEAP Phase 2 conversation MUST always end in a <t>A successful TEAP Phase 2 conversation <bcp14>MUST</bcp14> always e nd in a
successful Crypto-Binding TLV and Result TLV exchange. A TEAP server successful Crypto-Binding TLV and Result TLV exchange. A TEAP server
may initiate the Crypto-Binding TLV and Result TLV exchange without may initiate the Crypto-Binding TLV and Result TLV exchange without
initiating any inner methods in TEAP Phase 2. After the final initiating any inner methods in TEAP Phase 2. After the final
Result TLV exchange, the TLS tunnel is terminated, and a cleartext Result TLV exchange, the TLS tunnel is terminated, and a cleartext
EAP Success or EAP Failure is sent by the server. Peers implementing EAP Success or EAP Failure is sent by the server. Peers implementing
TEAP MUST NOT accept a cleartext EAP Success or failure packet prior TEAP <bcp14>MUST NOT</bcp14> accept a cleartext EAP Success or Failure packet pr ior
to the peer and server reaching synchronized protected result to the peer and server reaching synchronized protected result
indication.</t> indication.</t>
<t>The Crypto-Binding TLV exchange is used to prove that both the peer <t>The Crypto-Binding TLV exchange is used to prove that both the peer
and server participated in the tunnel establishment and sequence of and server participated in the tunnel establishment and sequence of
authentications. It also provides verification of the TEAP type, authentications. It also provides verification of the TEAP type,
version negotiated, and Outer TLVs exchanged before the TLS tunnel version negotiated, and Outer TLVs exchanged before the TLS tunnel
establishment. Except as noted below, the Crypto-Binding TLV MUST be exchanged and verified establishment. Except as noted below, the Crypto-Binding TLV <bcp14>MUST</bcp14 > be exchanged and verified
before the final Result TLV exchange, regardless of whether or not before the final Result TLV exchange, regardless of whether or not
there is an inner method. The Crypto-Binding TLV there is an inner method. The Crypto-Binding TLV
and Intermediate-Result TLV MUST be included to perform cryptographic and Intermediate-Result TLV <bcp14>MUST</bcp14> be included to perform cryptogra phic
binding after each successful authentication in a sequence of one or more binding after each successful authentication in a sequence of one or more
inner methods. The server may send the final Result TLV along with an inner methods. The server may send the final Result TLV along with an
Intermediate-Result TLV and a Crypto-Binding TLV to indicate its Intermediate-Result TLV and a Crypto-Binding TLV to indicate its
intention to end the conversation. If the peer requires nothing more intention to end the conversation. If the peer requires nothing more
from the server, it will respond with a Result TLV indicating success from the server, it will respond with a Result TLV indicating success
accompanied by a Crypto-Binding TLV and Intermediate-Result TLV if accompanied by a Crypto-Binding TLV and Intermediate-Result TLV if
necessary. The server then tears down the tunnel and sends a necessary. The server then tears down the tunnel and sends a
cleartext EAP Success or EAP Failure.</t> cleartext EAP Success or EAP Failure.</t>
<t>If the peer receives a Result TLV indicating success from the serve r, <t>If the peer receives a Result TLV indicating success from the serve r,
but its authentication policies are not satisfied (for example, it but its authentication policies are not satisfied (for example, it
skipping to change at line 824 skipping to change at line 909
<t>The Peer-Id and Server-Id <xref target="RFC5247"/> may be determined based on the <t>The Peer-Id and Server-Id <xref target="RFC5247"/> may be determined based on the
types of credentials used during either the TEAP tunnel creation or types of credentials used during either the TEAP tunnel creation or
authentication. In the case of multiple peer authentications, all authentication. In the case of multiple peer authentications, all
authenticated peer identities and their corresponding identity types authenticated peer identities and their corresponding identity types
(<xref target="identity-type-tlv"/>) need to be exported. In the case of multip le server (<xref target="identity-type-tlv"/>) need to be exported. In the case of multip le server
authentications, all authenticated server identities need to be authentications, all authenticated server identities need to be
exported.</t> exported.</t>
<t>When X.509 certificates are used for peer authentication, the Peer-Id <t>When X.509 certificates are used for peer authentication, the Peer-Id
is determined by the subject and subjectAltName fields in the peer is determined by the subject and subjectAltName fields in the peer
certificate. As noted in <xref target="RFC5280"/>:</t> certificate. As noted in <xref target="RFC5280"/>:</t>
<artwork><![CDATA[ <blockquote><t>
The subject field identifies the entity associated with the public The subject field identifies the entity associated with the public
key stored in the subject public key field. The subject name MAY key stored in the subject public key field. The subject name <bcp14>MAY</bcp14>
be carried in the subject field and/or the subjectAltName be carried in the subject field and/or the subjectAltName
extension. . . . If subject naming information is present only in extension. . . . If subject naming information is present only in
the subjectAltName extension (e.g., a key bound only to an email the subjectAltName extension (e.g., a key bound only to an email
address or URI), then the subject name MUST be an empty sequence address or URI), then the subject name <bcp14>MUST</bcp14> be an empty sequence
and the subjectAltName extension MUST be critical. and the subjectAltName extension <bcp14>MUST</bcp14> be critical.</t>
Where it is non-empty, the subject field MUST contain an X.500 <t>Where it is non-empty, the subject field <bcp14>MUST</bcp14> contain an X.500
distinguished name (DN). distinguished name (DN).</t>
]]></artwork> </blockquote>
<t>If an inner EAP authentication method is run, then the Peer-Id is obt ained from that <t>If an inner EAP authentication method is run, then the Peer-Id is obt ained from that
inner EAP authentication method.</t> inner EAP authentication method.</t>
<t>When the server uses an X.509 certificate to establish the TLS <t>When the server uses an X.509 certificate to establish the TLS
tunnel, the Server-Id is determined in a similar fashion as stated tunnel, the Server-Id is determined in a similar fashion as stated
above for the Peer-Id, e.g., the subject and subjectAltName fields in above for the Peer-Id, e.g., the subject and subjectAltName fields in
the server certificate define the Server-Id.</t> the server certificate define the Server-Id.</t>
</section> </section>
<section anchor="teap-session-identifier"> <section anchor="teap-session-identifier">
<name>TEAP Session Identifier</name> <name>TEAP Session Identifier</name>
<t>For TLS 1.2 and earlier, the EAP session identifier <xref target="RFC 5247"/> is constructed using the tls-unique <t>For TLS 1.2 and earlier, the EAP session identifier <xref target="RFC 5247"/> is constructed using the tls-unique
from the Phase 1 outer tunnel at the beginning of Phase 2 as from the Phase 1 outer tunnel at the beginning of Phase 2 as
defined by Section 3.1 of <xref target="RFC5929"/>. The Session-Id is defined a s defined by <xref target="RFC5929" section="3.1"/>. The Session-Id is defined as
follows:</t> follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Session-Id = teap_type | tls-unique Session-Id = teap_type | tls-unique]]></artwork>
]]></artwork>
<ul empty="true"> <t>Where:</t>
<li> <ul spacing="normal">
<t>where | denotes concatenation, and teap_type is the EAP Type assi <li>| denotes concatenation,</li>
gned to TEAP</t> <li>teap_type is the EAP Type assigned to TEAP, and</li>
<t>tls-unique = tls-unique from the Phase 1 outer tunnel at the <li>tls-unique = tls-unique from the Phase 1 outer tunnel at the
beginning of Phase 2 as defined by Section 3.1 of <xref target="RFC5929"/></t> beginning of Phase 2 as defined by <xref
</li> target="RFC5929" section="3.1"/>.</li>
</ul> </ul>
<t>The Session-Id derivation for TLS 1.3 is given in <xref section="2.1" sectionFormat="comma" target="RFC9427"/></t> <t>The Session-Id derivation for TLS 1.3 is given in <xref section="2.1" sectionFormat="comma" target="RFC9427"/></t>
</section> </section>
<section anchor="error-handling"> <section anchor="error-handling">
<name>Error Handling</name> <name>Error Handling</name>
<t>TEAP uses the error-handling rules summarized below:</t> <t>TEAP uses the error-handling rules summarized below:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Errors in the outer EAP packet layer are handled as defined in <t>Errors in the outer EAP packet layer are handled as defined in
<xref target="outer-layer-errors"/>.</t> <xref target="outer-layer-errors"/>.</t>
</li> </li>
<li> <li>
skipping to change at line 904 skipping to change at line 991
</li> </li>
<li> <li>
<t>The entire TEAP packet will be ignored if other fields (version , <t>The entire TEAP packet will be ignored if other fields (version ,
length, flags, etc.) are inconsistent with this specification.</t> length, flags, etc.) are inconsistent with this specification.</t>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="tls-layer-errors"> <section anchor="tls-layer-errors">
<name>TLS Layer Errors</name> <name>TLS Layer Errors</name>
<t>If the TEAP server detects an error at any point in the TLS handsha ke <t>If the TEAP server detects an error at any point in the TLS handsha ke
or the TLS layer, the server SHOULD send a TEAP request encapsulating or the TLS layer, the server <bcp14>SHOULD</bcp14> send a TEAP request encapsula ting
a TLS record containing the appropriate TLS alert message rather than a TLS record containing the appropriate TLS alert message rather than
immediately terminating the TEAP exchange so as to allow the peer to immediately terminating the TEAP exchange so as to allow the peer to
inform the user of the cause of the failure. The TEAP peer MUST send a TEAP res inform the user of the cause of the failure. The TEAP peer <bcp14>MUST</bcp14>
ponse to send a TEAP response to
an alert message. The EAP-Response packet sent by the peer SHOULD contain a TEA an alert message. The EAP-Response packet sent by the peer <bcp14>SHOULD</bcp14
P response with a zero-length message. > contain a TEAP response with a zero-length message.
The server MUST terminate the TEAP exchange with an EAP Failure The server <bcp14>MUST</bcp14> terminate the TEAP exchange with an EAP Failure
packet, no matter what the client says.</t> packet no matter what the client says.</t>
<t>If the TEAP peer detects an error at any point in the TLS layer, th e <t>If the TEAP peer detects an error at any point in the TLS layer, th e
TEAP peer SHOULD send a TEAP response encapsulating a TLS record TEAP peer <bcp14>SHOULD</bcp14> send a TEAP response encapsulating a TLS record
containing the appropriate TLS alert message, and which contains a zero-length m containing the appropriate TLS alert message, which contains a zero-length messa
essage. The server then MUST terminate the conversation with an EAP failure, as ge. The server then <bcp14>MUST</bcp14> terminate the conversation with an EAP
discussed in the previous paragraph.</t> failure as discussed in the previous paragraph.</t>
<t>While TLS 1.3 (<xref target="RFC8446"/>) allows for the TLS convers <t>While TLS 1.3 <xref target="RFC8446"/> allows for the TLS conversat
ation to be restarted, it is not clear when that would be useful (or used) for T ion to be restarted, it is not clear when that would be useful (or used) for TEA
EAP. Fatal TLS errors will cause the TLS conversation to fail. Non-fatal TLS e P. Fatal TLS errors will cause the TLS conversation to fail. Non-fatal TLS err
rrors can likely be ignored entirely. As a result, TEAP implementations MUST NO ors can likely be ignored entirely. As a result, TEAP implementations <bcp14>MU
T permit TLS restarts.</t> ST NOT</bcp14> permit TLS restarts.</t>
</section> </section>
<section anchor="phase-2-errors"> <section anchor="phase-2-errors">
<name>Phase 2 Errors</name> <name>Phase 2 Errors</name>
<t>There are a large number of situations where errors can occur durin g <t>There are a large number of situations where errors can occur durin g
Phase 2 processing. This section describes both those errors, and the Phase 2 processing. This section describes both errors and the
recommended processing of them.</t> recommended processing of them.</t>
<t>When the server receives a Result TLV with a fatal Error TLV from t he <t>When the server receives a Result TLV with a fatal Error TLV from t he
peer, it MUST terminate the TLS tunnel and reply with an EAP Failure.</t> peer, it <bcp14>MUST</bcp14> terminate the TLS tunnel and reply with an EAP Fail ure.</t>
<t>When the peer receives a Result TLV with a fatal Error TLV from the <t>When the peer receives a Result TLV with a fatal Error TLV from the
server, it MUST respond with a Result TLV indicating failure. server, it <bcp14>MUST</bcp14> respond with a Result TLV indicating failure.
The server MUST discard any data it receives from the peer, and reply The server <bcp14>MUST</bcp14> discard any data it receives from the peer and re
ply
with an EAP Failure. The final message from the peer is required by with an EAP Failure. The final message from the peer is required by
the EAP state machine, and serves only to allow the server to reply the EAP state machine and serves only to allow the server to reply
to the peer with the EAP Failure.</t> to the peer with the EAP Failure.</t>
<t>The following items describe specific errors and processing in more <t>The following items describe specific errors and processing in more
detail.</t> detail.</t>
<t>Fatal Error processing a TLV</t> <dl spacing="normal" newline="true">
<ul empty="true"> <dt>Fatal Error processing a TLV:</dt>
<li> <dd>Any time the peer or the server finds a fatal error outside of the TLS
<t>Any time the peer or the server finds a fatal error outside of layer during Phase 2 TLV processing, it <bcp14>MUST</bcp14> send a Result
the TLV of failure and an Error TLV using the most descriptive error code
TLS layer during Phase 2 TLV processing, it MUST send a Result TLV of possible.</dd>
failure and an Error TLV using the most descriptive error code possible.</t> <dt>Fatal Error during TLV Exchanges:</dt>
</li> <dd>For errors involving the processing of the sequence of exchanges, such
</ul> as a violation of TLV rules (e.g., multiple EAP-Payload TLVs), the error
<t>Fatal Error during TLV Exchanges</t> code is Unexpected TLVs Exchanged.</dd>
<ul empty="true"> <dt>Fatal Error due to tunnel compromise:</dt>
<li> <dd>For errors involving a tunnel compromise, such as when the Crypto-Binding
<t>For errors involving the processing of the sequence of exchange TLV fails validation, the error code is Tunnel Compromise Error.</dd>
s, <dt>Non-Fatal Error due to inner method:</dt>
such as a violation of TLV rules (e.g., multiple EAP-Payload TLVs), <dd><t>If there is a non-fatal error while running the inner method, the
the error code is Unexpected TLVs Exchanged.</t> receiving side <bcp14>SHOULD NOT</bcp14> silently drop the inner method
</li> exchange. Instead, it <bcp14>SHOULD</bcp14> reply with an Error TLV
</ul> using the most descriptive error code possible.</t>
<t>Fatal Error due to tunnel compromise</t> <t>If there is no error code that matches the particular issue, then the
<ul empty="true"> value Inner Method Error (1001) <bcp14>SHOULD</bcp14> be used. This response
<li> is a positive indication that there was an error processing the current
<t>For errors involving a tunnel compromise such as when the inner method. The side receiving a non-fatal Error TLV <bcp14>MAY</bcp14>
Crypto-Binding TLV fails validation, the error code is Tunnel decide to start a new and different inner method instead or send back a
Compromise Error.</t> Result TLV to terminate the TEAP authentication session.</t></dd>
</li> </dl>
</ul>
<t>Non-Fatal Error due to inner method</t>
<ul empty="true">
<li>
<t>If there is a non-fatal error while running the inner method, t
he
receiving side SHOULD NOT silently drop the inner method exchange.
Instead, it SHOULD reply with an Error TLV containing using the most
descriptive error code possible.</t>
<t>If there is no error code which matches the particular issue, t
hen the value Inner Method Error (1001) SHOULD be used. This response is a posit
ive indication that
there was an error processing the current inner method. The side
receiving a non-fatal Error TLV MAY decide to start a new and different inner me
thod
instead or, send back a Result TLV to terminate the TEAP
authentication session.</t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="fragmentation"> <section anchor="fragmentation">
<name>Fragmentation</name> <name>Fragmentation</name>
<t>Fragmentation of EAP packets is discussed in <xref section="2.1.5." s ectionFormat="comma" target="RFC5216"/> <t>Fragmentation of EAP packets is discussed in <xref section="2.1.5" se ctionFormat="comma" target="RFC5216"/>.
There is no special handling of fragments for TEAP.</t> There is no special handling of fragments for TEAP.</t>
</section> </section>
<section anchor="services-requested-by-the-peer"> <section anchor="services-requested-by-the-peer">
<name>Services Requested by the Peer</name> <name>Services Requested by the Peer</name>
<t>Several TEAP operations, including server unauthenticated <t>Several TEAP operations, including server unauthenticated
provisioning, certificate provisioning, and channel binding, depend on provisioning, certificate provisioning, and channel binding, depend on
the peer trusting the TEAP server. If the peer trusts the provided the peer trusting the TEAP server. If the peer trusts the provided
server certificate, then the server is authenticated.</t> server certificate, then the server is authenticated.</t>
<t>Typically, this authentication process involves the peer <t>Typically, this authentication process involves the peer
validating the certificate to a trust anchor by verifying that the server presen ting the certificate holds the private key, and confirming that the validating the certificate to a trust anchor by verifying that the server presen ting the certificate holds the private key and confirming that the
entity named by the certificate is the intended server. Server entity named by the certificate is the intended server. Server
authentication also occurs when the procedures in <xref target="phase1"/> are us ed authentication also occurs when the procedures in <xref target="phase1"/> are us ed
to resume a session where the peer and server were previously mutually to resume a session where the peer and server were previously mutually
authenticated. Alternatively, the server is deemed to be authenticated. Alternatively, the server is deemed to be
authenticated if an inner EAP method provides mutual authentication authenticated if an inner EAP method provides mutual authentication
along with a Master Session Key (MSK) and/or Extended Master Session along with an MSK and/or EMSK. The inner method <bcp14>MUST</bcp14> also provid
Key (EMSK). The inner method MUST also provide for cryptographic e for cryptographic
binding via the Compound Message Authentication Code (MAC), as binding via the Compound Message Authentication Code (MAC), as
discussed in <xref target="crypto-binding-tlv"/>. This issue is further describ ed in discussed in <xref target="crypto-binding-tlv"/>. This issue is further describ ed in
<xref target="unauth-provisioning"/>.</t> <xref target="unauth-provisioning"/>.</t>
<t>TEAP peers MUST track whether or not server authentication has taken <t>TEAP peers <bcp14>MUST</bcp14> track whether or not server authentica
place. When the server cannot be authenticated, the peer MUST NOT tion has taken
request any services such as certificate provisioning ({#cert-provisioning}) fro place. When the server cannot be authenticated, the peer <bcp14>MUST NOT</bcp14>
m it.</t> request any services such as certificate provisioning (<xref target="cert-provis
<t>Unless the peer requests server unauthenticated provisioning, it MUST ioning"/>) from it.</t>
<!-- [rfced] May we rephrase the following sentence? In particular,
"...authenticate the server, and fail the current authentication session
fails if the server..." seems difficult to parse.
Original:
Unless the peer requests server unauthenticated provisioning, it MUST
authenticate the server, and fail the current authentication session
fails if the server cannot be authenticated.
Perhaps:
Unless the peer requests server unauthenticated provisioning, it MUST
authenticate the server and fail the current authentication session.
The authentication session fails if the server cannot be authenticated.
-->
<t>Unless the peer requests server unauthenticated provisioning, it <bcp
14>MUST</bcp14>
authenticate the server, and fail the current authentication authenticate the server, and fail the current authentication
session fails if the server cannot be authenticated.</t> session fails if the server cannot be authenticated.</t>
<t>An additional complication arises when an inner method authenticates <t>An additional complication arises when an inner method authenticates
multiple parties such as authenticating both the peer machine and the multiple parties, such as authenticating both the peer machine and the
peer user to the EAP server. Depending on how authentication is peer user to the EAP server. Depending on how authentication is
achieved, only some of these parties may have confidence in it. For achieved, only some of these parties may have confidence in it. For
example, if a strong shared secret is used to mutually authenticate example, if a strong shared secret is used to mutually authenticate
the user and the EAP server, the machine may not have confidence that the user and the EAP server, the machine may not have confidence that
the EAP server is the authenticated party if the machine cannot trust the EAP server is the authenticated party if the machine cannot trust
the user not to disclose the shared secret to an attacker. In these the user not to disclose the shared secret to an attacker. In these
cases, the parties who participate in the authentication need to be cases, the parties who participate in the authentication need to be
considered when evaluating whether the peer should request these considered when evaluating whether the peer should request these
services, or whether the server should provide them.</t> services or whether the server should provide them.</t>
<t>The server MUST also authenticate the peer before providing these <t>The server <bcp14>MUST</bcp14> also authenticate the peer before prov
iding these
services. The alternative is to send provisioning data to services. The alternative is to send provisioning data to
unauthenticated and potentially malicious peers, which can have unauthenticated and potentially malicious peers, which can have
negative impacts on security.</t> negative impacts on security.</t>
<t>When a device is provisioned via TEAP, any subsequent authorization <t>When a device is provisioned via TEAP, any subsequent authorization
MUST be done on the authenticated credentials. That is, there may be <bcp14>MUST</bcp14> be done on the authenticated credentials. That is, there ma y be
no credentials (or anonymous credentials) passed in Phase 1, but there no credentials (or anonymous credentials) passed in Phase 1, but there
will be credentials passed or provisioned in Phase 2. If later will be credentials passed or provisioned in Phase 2. If later
authorizations are done on the Phase 1 identity, then a device could authorizations are done on the Phase 1 identity, then a device could
obtain the wrong authorization. If instead authorization is done on obtain the wrong authorization. If authorization is done on
the authenticated credentials, then the device will obtain the correct the authenticated credentials instead, then the device will obtain the correct
kind of network access.</t> kind of network access.</t>
<t>The correct authorization must also be applied to any resumption, as <t>The correct authorization must also be applied to any resumption, as
noted in <xref section="5.7." sectionFormat="comma" target="RFC9190"/> However, noted in <xref section="5.7" sectionFormat="comma" target="RFC9190"/>. However,
as it is possible in TEAP as it is possible in TEAP
for the credentials to change, the new credentials MUST be associated for the credentials to change, the new credentials <bcp14>MUST</bcp14> be associ
ated
with the session ticket. If this association cannot be done, then the with the session ticket. If this association cannot be done, then the
server MUST invalidate any session tickets for the current session. server <bcp14>MUST</bcp14> invalidate any session tickets for the current sessio n.
This invalidation will force a full re-authentication on any This invalidation will force a full re-authentication on any
subsequent connection, at which point the correct authorization will subsequent connection; at which point, the correct authorization will
be associated with any session ticket.</t> be associated with any session ticket.</t>
<t>Note that the act of re-provisioning a device is essentially <t>Note that the act of re-provisioning a device is essentially
indistinguishable from any initial provisioning. The device indistinguishable from any initial provisioning. The device
authenticates, and obtains new credentials via the standard authenticates and obtains new credentials via the standard
provisioning mechanisms. The only caveat is that the device SHOULD provisioning mechanisms. The only caveat is that the device <bcp14>SHOULD
NOT discard the old credentials unless either they are known to have NOT</bcp14> discard the old credentials unless either they are known to have
expired, or the new credentials have been verified to work.</t> expired or the new credentials have been verified to work.</t>
<section anchor="cert-provisioning"> <section anchor="cert-provisioning">
<name>Certificate Provisioning within the Tunnel</name> <name>Certificate Provisioning Within the Tunnel</name>
<t>Provisioning of a peer's certificate is supported in TEAP by <!-- [rfced] We note that RFC 2986 uses "CertificationRequest" rather than "Cert
performing the Simple PKI Request/Response from <xref target="RFC5272"/> using ificateRequest". Should "CertificateRequest" be updated in the
PKCS#10 and PKCS#7 TLVs, respectively. A peer sends the Simple PKI sentence below to match RFC 2986?
Request using a PKCS#10 CertificateRequest <xref target="RFC2986"/> encoded into
the Current:
body of a PKCS#10 TLV (see <xref target="pkcs10-tlv"/>). The TEAP server issues A peer sends the Simple PKI Request using a PKCS#10 CertificateRequest
a [RFC2986] encoded into the body of a PKCS#10 TLV (see Section 4.2.17).
Simple PKI Response using a PKCS#7 <xref target="RFC2315"/> unsigned (i.e. degen
erate) "Certificates Perhaps:
Only" message encoded into the body of a PKCS#7 TLV (see A peer sends the Simple PKI Request using a PKCS#10 CertificationRequest
<xref target="pkcs7-tlv"/>), only after an inner method has run and [RFC2986] encoded into the body of a PKCS#10 TLV (see Section 4.2.17).
provided an identity proof on the peer prior to a certificate is -->
being issued.</t> <t>Provisioning of a peer's certificate is supported in TEAP by
performing the Simple PKI Request/Response from <xref
target="RFC5272"/> using PKCS#10 and PKCS#7 TLVs, respectively. A
peer sends the Simple PKI Request using a PKCS#10 CertificateRequest
<xref target="RFC2986"/> encoded into the body of a PKCS#10 TLV (see
<xref target="pkcs10-tlv"/>). The TEAP server issues a Simple PKI
Response using a PKCS#7 <xref target="RFC2315"/> unsigned
(i.e., degenerate) "Certificates Only" message encoded into the body
of a PKCS#7 TLV (see <xref target="pkcs7-tlv"/>) only after an
inner method has run and provided an identity proof on the peer
prior to a certificate is being issued.</t>
<t>In order to provide linking identity and proof-of-possession by <t>In order to provide linking identity and proof-of-possession by
including information specific to the current authenticated TLS including information specific to the current authenticated TLS
session within the signed certification request, the peer generating session within the signed certification request, the peer generating
the request SHOULD obtain the tls-unique value from the TLS subsystem the request <bcp14>SHOULD</bcp14> obtain the tls-unique value from the TLS subsy stem
as defined in "Channel Bindings for TLS" <xref target="RFC5929"/>. The TEAP pee r as defined in "Channel Bindings for TLS" <xref target="RFC5929"/>. The TEAP pee r
operations between obtaining the tls-unique value through generation operations between obtaining the tls-unique value through generation
of the Certification Signing Request (CSR) that contains the current of the Certification Signing Request (CSR) that contains the current
tls-unique value and the subsequent verification of this value by the tls-unique value and the subsequent verification of this value by the
TEAP server are the "phases of the application protocol during which TEAP server are the "phases of the application protocol during which
application-layer authentication occurs" that are protected by the application-layer authentication occurs" that are protected by the
synchronization interoperability mechanism described in the synchronization interoperability mechanism described in the
interoperability note in "Channel Bindings for TLS" (<xref target="RFC5929"/>, interoperability note in "Channel Bindings for TLS" (<xref target="RFC5929" sect
Section 3.1). When performing renegotiation, TLS ionFormat="comma" section="3.1"/>). When performing renegotiation, TLS
"secure_renegotiation" <xref target="RFC5746"/> MUST be used.</t> "secure_renegotiation" <xref target="RFC5746"/> <bcp14>MUST</bcp14> be used.</t>
<t>The tls-unique value is base-64-encoded as specified in <xref targe <t>The tls-unique value is base-64-encoded as specified in
t="message-formats"/> of <xref section="4" target="RFC4648"/>, and the resulting string is placed in the
<xref target="RFC4648"/>, and the resulting string is placed in the certificatio certification
n request challengePassword field (<xref target="RFC2985" sectionFormat="comma" se
request challengePassword field (<xref target="RFC2985"/>, Section 5.4.1). The ction="5.4.1"/>). The
challengePassword field is limited to 255 octets (Section 7.4.9 of challengePassword field is limited to 255 octets (<xref target="RFC5246" section
<xref target="RFC5246"/> indicates that no existing cipher suite would result in ="7.4.9"/> indicates that no existing cipher suite would result in an
an
issue with this limitation). If tls-unique information is not issue with this limitation). If tls-unique information is not
embedded within the certification request, the challengePassword embedded within the certification request, the challengePassword
field MUST be empty to indicate that the peer did not include the field <bcp14>MUST</bcp14> be empty to indicate that the peer did not include the
optional channel-binding information (any value submitted is verified optional channel-binding information (any value submitted is verified
by the server as tls-unique information).</t> by the server as tls-unique information).</t>
<t>The server SHOULD verify the tls-unique information. This ensures that the <t>The server <bcp14>SHOULD</bcp14> verify the tls-unique information. This ensures that the
signed certificate request is being presented by an authenticated TEAP peer signed certificate request is being presented by an authenticated TEAP peer
which is in possession of the private key.</t> that is in possession of the private key.</t>
<t>The Simple PKI Request/Response generation and processing rules of <t>The Simple PKI Request/Response generation and processing rules of
<xref target="RFC5272"/> SHALL apply to TEAP, with the exception of error <xref target="RFC5272"/> <bcp14>SHALL</bcp14> apply to TEAP, with the exception
conditions. In the event of an error, the TEAP server SHOULD respond of error
conditions. In the event of an error, the TEAP server <bcp14>SHOULD</bcp14> res
pond
with an Error TLV using the most descriptive error code possible; it with an Error TLV using the most descriptive error code possible; it
MAY ignore the PKCS#10 request that generated the error.</t> <bcp14>MAY</bcp14> ignore the PKCS#10 request that generated the error.</t>
</section> </section>
<section anchor="certificate-content-and-uses"> <section anchor="certificate-content-and-uses">
<name>Certificate Content and Uses</name> <name>Certificate Content and Uses</name>
<t>It is not enough to verify that the CSR provided by the peer to the <t>It is not enough to verify that the CSR provided by the peer to the
authenticator is from an authenticated user. The CSR itself should authenticator is from an authenticated user. The CSR itself should
also be examined by the authenticator or Certification Authority (CA) also be examined by the authenticator or CA
before any certificate is issued.</t> before any certificate is issued.</t>
<t>The format of a CSR is complex, and contains a substantial amount o f <t>The format of a CSR is complex and contains a substantial amount of
information. That information could be incorrect, such as a user information. That information could be incorrect, such as a user
claiming a wrong physical address, email address, etc. It is RECOMMENDED that s claiming a wrong physical address, email address, etc. It is <bcp14>RECOMMENDED
ystems provisioning these certificates </bcp14> that systems provisioning these certificates
validate that the CSR both contains the expected data, and also that validate that the CSR contains the expected data and that
is does not contain unexpected data. For example, a CA could refuse it does not contain unexpected data. For example, a CA could refuse
to issue the certificate if the CSR contained unknown fields, or if a to issue the certificate if the CSR contained unknown fields or if a
known field contained an unexpected or invalid value. The CA can modify or refu se a particular CSR to address these deficiencies for any known field contained an unexpected or invalid value. The CA can modify or refu se a particular CSR to address these deficiencies for any
reasons, including local site policy. We note that the "A" in "CA" means for "A uthority", while the "R" in "CSR" means "Request". There is no requirement for a CA to sign any and all CSRs which are presented to it.</t> reasons, including local site policy. We note that the "A" in "CA" means for "A uthority", while the "R" in "CSR" means "Request". There is no requirement for a CA to sign any and all CSRs that are presented to it.</t>
<t>Once an EAP peer receives the signed certificate, the peer could <t>Once an EAP peer receives the signed certificate, the peer could
potentially be (ab) used for in TLS contexts other than TEAP. For example, potentially be (ab)used for in TLS contexts other than TEAP. For example,
the certificate could be used with EAP-TLS, or even with HTTPS. It is NOT RECOM the certificate could be used with EAP-TLS, or even with HTTPS. It is
MENDED to use certificates provisioned via TEAP for <bcp14>NOT RECOMMENDED</bcp14> to use certificates provisioned via TEAP for
any non-TEAP protocol. One method of enforcing this any non-TEAP protocol. One method of enforcing this
restriction is to have different CAs (or different intermediate CAs) restriction is to have different CAs (or different intermediate CAs)
which issue certificates for different uses. For example, TLS-based that issue certificates for different uses. For example, TLS-based
EAP methods could share one CA, and even use different intermediary CAs for diff erent TLS-based EAP methods. HTTPS servers could use an EAP methods could share one CA, and even use different intermediary CAs for diff erent TLS-based EAP methods. HTTPS servers could use an
entirely different CA. The different protocols could then be configured entirely different CA. The different protocols could then be configured
to validate client certificates only from their preferred CA, which would preven to validate client certificates only from their preferred CA, which would preven
t peers from using certificates outside of the intended use-case.</t> t peers from using certificates outside of the intended use case.</t>
<t>Another method of limiting the uses of a certificate is to provisio <!-- [rfced] Please review the following text. RFC 7299 does not contain the
n term "Extended Key Usage" except for a reference to RFC 5294. Are any
updates needed?
Current:
Another method of limiting the uses of a certificate is to provision
it with an appropriate value for the Extended Key Usage field
[RFC7299].
-->
<t>Another method of limiting the uses of a certificate is to provision
it with an appropriate value for the Extended Key Usage field it with an appropriate value for the Extended Key Usage field
<xref target="RFC7299"/>. For example, the id-kp-eapOverLAN <xref target="RFC43 34"/> value <xref target="RFC7299"/>. For example, the id-kp-eapOverLAN <xref target="RFC43 34"/> value
could be used to indicate that this certificate is intended for use could be used to indicate that this certificate is intended for use
only with EAP.</t> only with EAP.</t>
<t>It is difficult to give more detailed recommendations than the abov e. <t>It is difficult to give more detailed recommendations than the abov e.
Each CA or organization may have its own local policy as to what is Each CA or organization may have its own local policy as to what is
permitted or forbidden in a certificate. All we can do in this permitted or forbidden in a certificate. All we can do in this
document is to highlight the issues, and make the reader aware that document is to highlight the issues and make the reader aware that
they have to be addressed.</t> they have to be addressed.</t>
</section> </section>
<section anchor="unauth-provisioning"> <section anchor="unauth-provisioning">
<name>Server Unauthenticated Provisioning Mode</name> <name>Server Unauthenticated Provisioning Mode</name>
<t>In Server Unauthenticated Provisioning Mode, an unauthenticated <t>In Server Unauthenticated Provisioning Mode, an unauthenticated
tunnel is established in Phase 1, and the peer and server negotiate tunnel is established in Phase 1, and the peer and server negotiate
an inner method or methods in Phase 2. This inner method MUST support mutual au thentication, provide key an inner method or methods in Phase 2. This inner method <bcp14>MUST</bcp14> su pport mutual authentication, provide key
derivation, and be resistant to attacks such as on-path and derivation, and be resistant to attacks such as on-path and
dictionary attacks. In most cases, this inner method will be an EAP authenticat dictionary attacks. In most cases, this inner method will be an EAP authenticat
ion method. Example inner methods which satisfy these criteria include EAP-pwd ion method. Example inner methods that satisfy these criteria include EAP-pwd <
<xref target="RFC5931"/> xref target="RFC5931"/>
and EAP-EKE <xref target="RFC6124"/>, but not EAP-FAST-MSCHAPv2.</t> and EAP-EKE <xref target="RFC6124"/> but not EAP-FAST-MSCHAPv2.</t>
<t>This provisioning mode enables the bootstrapping <t>This provisioning mode enables the bootstrapping
of peers when the peer lacks the ability to authenticate the server of peers when the peer lacks the ability to authenticate the server
during Phase 1. This includes both cases in which the cipher suite during Phase 1. This includes both cases in which the cipher suite
negotiated does not provide authentication and in which the negotiated does not provide authentication and in which the
cipher suite negotiated provides the authentication but the peer is cipher suite negotiated provides the authentication, but the peer is
unable to validate the identity of the server for some reason.</t> unable to validate the identity of the server for some reason.</t>
<t>Upon successful completion of the inner method in Phase 2, the peer and <t>Upon successful completion of the inner method in Phase 2, the peer and
server exchange a Crypto-Binding TLV to bind the inner method with server exchange a Crypto-Binding TLV to bind the inner method with
the outer tunnel and ensure that an on-path attack has not the outer tunnel and ensure that an on-path attack has not
been attempted.</t> been attempted.</t>
<t>Support for the Server Unauthenticated Provisioning Mode is optiona l. <t>Support for the Server Unauthenticated Provisioning Mode is optiona l.
The cipher suite TLS_DH_anon_WITH_AES_128_CBC_SHA is RECOMMENDED when The cipher suite TLS_DH_anon_WITH_AES_128_CBC_SHA is <bcp14>RECOMMENDED</bcp14> when
using Server Unauthenticated Provisioning Mode, but other anonymous using Server Unauthenticated Provisioning Mode, but other anonymous
cipher suites MAY be supported as long as the TLS pre-master secret is cipher suites <bcp14>MAY</bcp14> be supported as long as the TLS pre-master secr et is
generated from contribution from both peers.</t> generated from contribution from both peers.</t>
<t>When a strong inner method is not used with Server Unauthenticated <t>When a strong inner method is not used with Server Unauthenticated
Provisioning Mode, it is possible for an attacker to perform an Provisioning Mode, it is possible for an attacker to perform an
on-path attack. In effect, Server Unauthenticated on-path attack. In effect, Server Unauthenticated
Provisioning Mode has similar security issues as just running the Provisioning Mode has similar security issues as just running the
inner method in the open, without the protection of TLS. All of the inner method in the open without the protection of TLS. All of the
information in the tunnel should be assumed to be visible to, and information in the tunnel should be assumed to be visible to, and
modifiable by, an attacker.</t> modifiable by, an attacker.</t>
<t>Implementations SHOULD exchange minimal data in Server <t>Implementations <bcp14>SHOULD</bcp14> exchange minimal data in Serv er
Unauthenticated Provisioning Mode. Instead, they should use that mode Unauthenticated Provisioning Mode. Instead, they should use that mode
to set up a secure / authenticated tunnel, and then use that tunnel to to set up a secure/authenticated tunnel and then use that tunnel to
perform any needed data exchange.</t> perform any needed data exchange.</t>
<t>It is RECOMMENDED that client implementations and deployments <t>It is <bcp14>RECOMMENDED</bcp14> that client implementations and de ployments
authenticate TEAP servers if at all possible. Authenticating the authenticate TEAP servers if at all possible. Authenticating the
server means that a client can be provisioned securely with no chance of server means that a client can be provisioned securely with no chance of
an attacker eaves-dropping on the connection.</t> an attacker eaves-dropping on the connection.</t>
<t>Note that server Unauthenticated Provisioning can only use anonymou s <t>Note that server unauthenticated provisioning can only use anonymou s
cipher suites in TLS 1.2 and earlier. These cipher suites have been cipher suites in TLS 1.2 and earlier. These cipher suites have been
deprecated in TLS 1.3 (<xref section="C.5" sectionFormat="comma" target="RFC8446 "/>). For TLS 1.3, the deprecated in TLS 1.3 (<xref section="C.5" sectionFormat="comma" target="RFC8446 "/>). For TLS 1.3, the
server MUST provide a certificate, and the peer performs server server <bcp14>MUST</bcp14> provide a certificate, and the peer performs server
unauthenticated provisioning by not validating the certificate chain unauthenticated provisioning by not validating the certificate chain
or any of its contents.</t> or any of its contents.</t>
</section> </section>
<section anchor="channel-binding"> <section anchor="channel-binding">
<name>Channel Binding</name> <name>Channel Binding</name>
<t><xref target="RFC6677"/> defines channel bindings for EAP which sol ve the "lying NAS" and <t><xref target="RFC6677"/> defines channel bindings for EAP that solv e the "lying NAS" and
the "lying provider" problems, using a process in which the EAP peer the "lying provider" problems, using a process in which the EAP peer
gives information about the characteristics of the service provided gives information about the characteristics of the service provided
by the authenticator to the Authentication, Authorization, and by the authenticator to the Authentication, Authorization, and
Accounting (AAA) server protected within the EAP authentication method. This al lows Accounting (AAA) server protected within the EAP authentication method. This al lows
the server to verify the authenticator is providing information to the server to verify the authenticator is providing information to
the peer that is consistent with the information received from this the peer that is consistent with the information received from this
authenticator as well as the information stored about this authenticator as well as the information stored about this
authenticator.</t> authenticator.</t>
<t>TEAP supports EAP channel binding using the Channel-Binding TLV <t>TEAP supports EAP channel binding using the Channel-Binding TLV
defined in <xref target="channel-binding-tlv"/>. If the TEAP server wants to re quest the defined in <xref target="channel-binding-tlv"/>. If the TEAP server wants to re quest the
channel-binding information from the peer, it sends an empty channel-binding information from the peer, it sends an empty
Channel-Binding TLV to indicate the request. The peer responds to the Channel-Binding TLV to indicate the request. The peer responds to the
request by sending a Channel-Binding TLV containing a channel-binding request by sending a Channel-Binding TLV containing a channel-binding
message as defined in <xref target="RFC6677"/>. The server validates the message as defined in <xref target="RFC6677"/>. The server validates the
channel-binding message and sends back a Channel-Binding TLV with a result channel-binding message and sends back a Channel-Binding TLV with a result
code. If the server did not initiate the channel-binding request and code. If the server did not initiate the channel-binding request and
the peer still wants to send the channel-binding information to the the peer still wants to send the channel-binding information to the
server, it can do that by using the Request-Action TLV along with the server, it can do that by using the Request-Action TLV along with the
Channel-Binding TLV. The peer MUST only send channel-binding Channel-Binding TLV. The peer <bcp14>MUST</bcp14> only send channel-binding
information after it has successfully authenticated the server and information after it has successfully authenticated the server and
established the protected tunnel.</t> established the protected tunnel.</t>
</section> </section>
</section> </section>
</section> </section>
<!-- DNE -->
<section anchor="message-formats"> <section anchor="message-formats">
<name>Message Formats</name> <name>Message Formats</name>
<t>The following sections describe the message formats used in TEAP. <t>The following sections describe the message formats used in TEAP.
The fields are transmitted from left to right in network byte order.</t> The fields are transmitted from left to right in network byte order.</t>
<section anchor="teap-message-format"> <section anchor="teap-message-format">
<name>TEAP Message Format</name> <name>TEAP Message Format</name>
<t>A summary of the TEAP Request/Response packet format is shown below.< /t> <t>A summary of the TEAP Request/Response packet format is shown below.< /t>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Ver | Message Length : | Type | Flags | Ver | Message Length :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Message Length | Outer TLV Length : Message Length | Outer TLV Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Outer TLV Length | TLS Data... : Outer TLV Length | TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer TLVs... | Outer TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
<t>Code</t>
<ul empty="true">
<li>
<t>The Code field is one octet in length and is defined as follows:<
/t>
<ul empty="true">
<li>
<t>1 Request</t>
<t>2 Response</t>
</li>
</ul>
</li>
</ul>
<t>Identifier</t>
<ul empty="true">
<li>
<t>The Identifier field is one octet and aids in matching responses
with requests. The Identifier field MUST be changed on each
Request packet. The Identifier field in the Response packet MUST
match the Identifier field from the corresponding request.</t>
</li>
</ul>
<t>Length</t>
<ul empty="true">
<li>
<t>The Length field is two octets and indicates the length of the EA
P
packet including the Code, Identifier, Length, Type, Flags, Ver,
Message Length, TLS Data, and Outer TLVs fields. Octets outside
the range of the Length field should be treated as Data Link Layer
padding and should be ignored on reception.</t>
</li>
</ul>
<t>Type</t>
<ul empty="true">
<li>
<t>55 for TEAP</t>
</li>
</ul>
<t>Flags</t>
<artwork><![CDATA[
0 1 2 3 4
+-+-+-+-+-+
|L M S O R|
+-+-+-+-+-+
L Length included; set to indicate the presence of the four-octet
Message Length field. It MUST be present for the first
fragment of a fragmented message. It MUST NOT be present for
any other message.
M More fragments; set on all but the last fragment.
S TEAP start; set in a TEAP Start message sent from the server to <dl spacing="normal" newline="true">
the peer. <dt>Code</dt>
<dd><t>The Code field is one octet in length and is defined as follows:</t>
<dl spacing="normal" newline="false">
<dt>1</dt><dd>Request</dd>
<dt>2</dt><dd>Response</dd>
</dl></dd>
<dt>Identifier</dt>
<dd>The Identifier field is one octet and aids in matching responses with
requests. The Identifier field <bcp14>MUST</bcp14> be changed on each
Request packet. The Identifier field in the Response packet
<bcp14>MUST</bcp14> match the Identifier field from the corresponding
request.</dd>
<dt>Length</dt>
<dd>The Length field is two octets and indicates the length of the EAP
packet including the Code, Identifier, Length, Type, Flags, Ver, Message
Length, TLS Data, and Outer TLVs fields. Octets outside the range of the
Length field should be treated as Data Link Layer padding and should be
ignored on reception.</dd>
<dt>Type</dt>
<dd>55 for TEAP</dd>
<dt>Flags</dt>
<dd>
<artwork><![CDATA[
0 1 2 3 4
+-+-+-+-+-+
|L M S O R|
+-+-+-+-+-+]]></artwork>
O Outer TLV length included; set to indicate the presence of the <dl spacing="normal" newline="false">
four-octet Outer TLV Length field. It MUST be present only in <dt>L</dt>
the initial request and response messages. If the initial <dd>Length included; set to indicate the presence of the four-octet
message is fragmented, then it MUST be present only on the Message Length field. It <bcp14>MUST</bcp14> be present for the first
first fragment. fragment of a fragmented message. It <bcp14>MUST NOT</bcp14> be present
for any other message.</dd>
<dt>M</dt>
<dd>More fragments; set on all but the last fragment.</dd>
<dt>S</dt>
<dd>TEAP start; set in a TEAP Start message sent from the server to the
peer.</dd>
<dt>O</dt>
<dd>Outer TLV length included; set to indicate the presence of the
four-octet Outer TLV Length field. It <bcp14>MUST</bcp14> be present only
in the initial request and response messages. If the initial message is
fragmented, then it <bcp14>MUST</bcp14> be present only on the first
fragment.</dd>
<dt>R</dt>
<dd>Reserved (<bcp14>MUST</bcp14> be zero and ignored upon receipt)</dd>
</dl></dd>
R Reserved (MUST be zero and ignored upon receipt) <dt>Ver</dt>
]]></artwork> <dd>This field contains the version of the protocol. This document
<t>Ver</t> describes version 1 (001 in binary) of TEAP.</dd>
<ul empty="true"> <dt>Message Length</dt>
<li> <dd>The Message Length field is four octets and is present only if the L bit
<t>This field contains the version of the protocol. This document is set. This field provides the total length of the message that may be
describes version 1 (001 in binary) of TEAP.</t> fragmented over the data fields of multiple packets.</dd>
</li> <dt>Outer TLV Length</dt>
</ul> <dd>The Outer TLV Length field is four octets and is present only if the O
<t>Message Length</t> bit is set. This field provides the total length of the Outer TLVs if
<ul empty="true"> present.</dd>
<li> <dt>TLS Data</dt>
<t>The Message Length field is four octets and is present only if th <dd>When the TLS Data field is present, it consists of an encapsulated TLS
e packet in TLS record format. A TEAP packet with Flags and Version fields,
L bit is set. This field provides the total length of the message but with zero length TLS Data field, is used to indicate TEAP acknowledgment
that may be fragmented over the data fields of multiple packets.</t> for either a fragmented message, a TLS Alert message, or a TLS Finished
</li> message.</dd>
</ul> <dt>Outer TLVs</dt>
<t>Outer TLV Length</t> <dd>The Outer TLVs consist of the optional data used to help establish the
<ul empty="true"> TLS tunnel in TLV format. They are only allowed in the first two messages
<li> in the TEAP protocol. That is the first EAP-server-to-peer message and
<t>The Outer TLV Length field is four octets and is present only if first peer-to-EAP-server message. The start of the Outer TLVs can be
the O bit is set. This field provides the total length of the derived from the EAP Length field and Outer TLV Length field.</dd>
Outer TLVs if present.</t> </dl>
</li> <!-- end of DNE -->
</ul>
<t>TLS Data</t>
<ul empty="true">
<li>
<t>When the TLS Data field is present, it consists of an encapsulate
d
TLS packet in TLS record format. A TEAP packet with Flags and
Version fields, but with zero length TLS Data field, is used to
indicate TEAP acknowledgment for either a fragmented message, a
TLS Alert message, or a TLS Finished message.</t>
</li>
</ul>
<t>Outer TLVs</t>
<ul empty="true">
<li>
<t>The Outer TLVs consist of the optional data used to help establis
h
the TLS tunnel in TLV format. They are only allowed in the first
two messages in the TEAP protocol. That is the first
EAP-server-to-peer message and first peer-to-EAP-server message. The start
of the Outer TLVs can be derived from the EAP Length field and
Outer TLV Length field.</t>
</li>
</ul>
</section> </section>
<section anchor="teap-tlv-format"> <section anchor="teap-tlv-format">
<name>TEAP TLV Format and Support</name> <name>TEAP TLV Format and Support</name>
<t>The TLVs defined here are TLV objects. The TLV objects could be used <t>The TLVs defined here are TLV objects. The TLV objects could be used
to carry arbitrary parameters between an EAP peer and EAP server to carry arbitrary parameters between an EAP peer and EAP server
within the protected TLS tunnel.</t> within the protected TLS tunnel.</t>
<t>The EAP peer may not necessarily implement all the TLVs supported by <t>The EAP peer may not necessarily implement all the TLVs supported by
the EAP server. To allow for interoperability, TLVs are designed to the EAP server. To allow for interoperability, TLVs are designed to
allow an EAP server to discover if a TLV is supported by the EAP peer allow an EAP server to discover if a TLV is supported by the EAP peer
using the NAK TLV. The mandatory bit in a TLV indicates whether using the NAK TLV. The mandatory bit in a TLV indicates whether
support of the TLV is required. If the peer or server does not support of the TLV is required. If the peer or server does not
support a TLV marked mandatory, then it MUST send a NAK TLV in the support a TLV marked mandatory, then it <bcp14>MUST</bcp14> send a NAK TLV in th
response, and all the other TLVs in the message MUST be ignored. If e
response, and all the other TLVs in the message <bcp14>MUST</bcp14> be ignored.
If
an EAP peer or server finds an unsupported TLV that is marked as an EAP peer or server finds an unsupported TLV that is marked as
optional, it can ignore the unsupported TLV. It MUST only send a NAK optional, it can ignore the unsupported TLV. It <bcp14>MUST</bcp14> only send a
TLV for a TLV which is marked mandatory but is not understood, and MUST NOT othe NAK
rwise send a NAK TLV. If all TLVs in a message TLV for a TLV that is marked mandatory but is not understood and <bcp14>MUST NOT
are marked optional and none are understood by the peer, then a Result TLV SHOUL </bcp14> otherwise send a NAK TLV. If all TLVs in a message
D be sent to the other side in order to are marked optional and none are understood by the peer, then a Result TLV <bcp1
4>SHOULD</bcp14> be sent to the other side in order to
continue the conversation. It is also possible to send a NAK TLV when all TLVs in a message are marked optional.</t> continue the conversation. It is also possible to send a NAK TLV when all TLVs in a message are marked optional.</t>
<t>Note that a peer or server may support a TLV with the mandatory bit <t>Note that a peer or server may support a TLV with the mandatory bit
set but may not understand the contents. The appropriate response to set but may not understand the contents. The appropriate response to
a supported TLV with content that is not understood is defined by the a supported TLV with content that is not understood is defined by the
individual TLV specification.</t> individual TLV specification.</t>
<t>EAP implementations compliant with this specification MUST support <t>EAP implementations compliant with this specification <bcp14>MUST</bc p14> support
TLV exchanges as well as the processing of mandatory/optional TLV exchanges as well as the processing of mandatory/optional
settings on the TLV. Implementations conforming to this settings on the TLV. Implementations conforming to this
specification MUST support the following TLVs:</t> specification <bcp14>MUST</bcp14> support the following TLVs:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Authority-ID TLV</t> <t>Authority-ID TLV</t>
</li> </li>
<li> <li>
<t>Identity-Type TLV</t> <t>Identity-Type TLV</t>
</li> </li>
<li> <li>
<t>Result TLV</t> <t>Result TLV</t>
</li> </li>
skipping to change at line 1381 skipping to change at line 1459
<t>Basic-Password-Auth-Req TLV</t> <t>Basic-Password-Auth-Req TLV</t>
</li> </li>
<li> <li>
<t>Basic-Password-Auth-Resp TLV</t> <t>Basic-Password-Auth-Resp TLV</t>
</li> </li>
</ul> </ul>
<section anchor="general-tlv-format"> <section anchor="general-tlv-format">
<name>General TLV Format</name> <name>General TLV Format</name>
<t>TLVs are defined as described below. The fields are transmitted fr om <t>TLVs are defined as described below. The fields are transmitted fr om
left to right.</t> left to right.</t>
<t>If a peer or server receives a TLV which is not of the correct form <t>If a peer or server receives a TLV that is not of the correct forma
at, t,
the TLV MUST be discarded. It is generally useful to log an error or the TLV <bcp14>MUST</bcp14> be discarded. It is generally useful to log an erro
debugging message which indicates which TLV had an issue, and what the r or
problem is. However, TLVs which are malformed are invalid, and cannot debugging message that indicates which TLV had an issue and what the
problem is. However, TLVs that are malformed are invalid and cannot
be used.</t> be used.</t>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="true">
<ul empty="true"> <dt>M</dt>
<li> <dd>
<t>0 Optional TLV</t> <dl spacing="normal" newline="false">
<t>1 Mandatory TLV</t> <dt>0</dt><dd>Optional TLV</dd>
</li> <dt>1</dt><dd>Mandatory TLV</dd>
</ul> </dl>
<t>R</t> </dd>
<ul empty="true"> <dt>R</dt>
<li> <dd>Reserved, set to zero (0)</dd>
<t>Reserved, set to zero (0)</t> <dt>TLV Type</dt>
</li> <dd><t>A 14-bit field, denoting the TLV type. Allocated types include:</t>
</ul> <dl spacing="normal" newline="false">
<t>TLV Type</t> <dt>0</dt><dd>Unassigned</dd>
<t>A 14-bit field, denoting the TLV type. Allocated types include:</t <dt>1</dt><dd>Authority-ID TLV (<xref target="authority-id-tlv"/>)</dd>
> <dt>2</dt><dd>Identity-Type TLV (<xref target="identity-type-tlv"/>)</dd>
<ul empty="true"> <dt>3</dt><dd>Result TLV (<xref target="result-tlv"/>)</dd>
<li> <dt>4</dt><dd>NAK TLV (<xref target="nak-tlv"/>)</dd>
<t>0 Unassigned</t> <dt>5</dt><dd>Error TLV (<xref target="error-tlv"/>)</dd>
<t>1 Authority-ID TLV (<xref target="authority-id-tlv"/>)</t> <dt>6</dt><dd>Channel-Binding TLV (<xref target="channel-binding-tlv"/>)</dd
<t>2 Identity-Type TLV (<xref target="identity-type-tlv"/>)</t> >
<t>3 Result TLV (<xref target="result-tlv"/>)</t> <dt>7</dt><dd>Vendor-Specific TLV (<xref target="vendor-specific-tlv"/>)</dd
<t>4 NAK TLV (<xref target="nak-tlv"/>)</t> >
<t>5 Error TLV (<xref target="error-tlv"/>)</t> <dt>8</dt><dd>Request-Action TLV (<xref target="request-action-tlv"/>)</dd>
<t>6 Channel-Binding TLV (<xref target="channel-binding-tlv"/>)</ <dt>9</dt><dd>EAP-Payload TLV (<xref target="eap-payload-tlv"/>)</dd>
t> <dt>10</dt><dd>Intermediate-Result TLV (<xref target="intermediate-result-tl
<t>7 Vendor-Specific TLV (<xref target="vendor-specific-tlv"/>)</ v"/>)</dd>
t> <dt>11</dt><dd>PAC TLV (DEPRECATED)</dd>
<t>8 Request-Action TLV (<xref target="request-action-tlv"/>)</t> <dt>12</dt><dd>Crypto-Binding TLV (<xref target="crypto-binding-tlv"/>)</dd>
<t>9 EAP-Payload TLV (<xref target="eap-payload-tlv"/>)</t> <dt>13</dt><dd>Basic-Password-Auth-Req TLV (<xref target="bp-auth-req-tlv"/>
<t>10 Intermediate-Result TLV (<xref target="intermediate-result-t )</dd>
lv"/>)</t> <dt>14</dt><dd>Basic-Password-Auth-Resp TLV (<xref target="bp-auth-resp-tlv"
<t>11 PAC TLV (DEPRECATED)</t> />)</dd>
<t>12 Crypto-Binding TLV (<xref target="crypto-binding-tlv"/>)</t> <dt>15</dt><dd>PKCS#7 TLV (<xref target="pkcs7-tlv"/>)</dd>
<t>13 Basic-Password-Auth-Req TLV (<xref target="bp-auth-req-tlv"/ <dt>16</dt><dd>PKCS#10 TLV (<xref target="pkcs10-tlv"/>)</dd>
>)</t> <dt>17</dt><dd>Trusted-Server-Root TLV (<xref target="trusted-server-root-tl
<t>14 Basic-Password-Auth-Resp TLV (Section 4.2.15)</t> v"/>)</dd>
<t>15 PKCS#7 TLV (<xref target="pkcs7-tlv"/>)</t> <dt>18</dt><dd>CSR-Attributes TLV (<xref target="csr-attributes-tlv"/>)</dd>
<t>16 PKCS#10 TLV (<xref target="pkcs10-tlv"/>)</t> <dt>19</dt><dd>Identity-Hint TLV (<xref target="identity-hint-tlv"/>)</dd>
<t>17 Trusted-Server-Root TLV (<xref target="trusted-server-root-t </dl></dd>
lv"/>)</t> <dt>Length</dt>
<t>18 CSR-Attributes TLV (<xref target="csr-attributes-tlv"/>)</t> <dd>The length of the Value field in octets.</dd>
<t>19 Identity-Hint TLV (<xref target="identity-hint-tlv"/>)</t> <dt>Value</dt>
</li> <dd>The value of the TLV.</dd>
</ul> </dl>
<t>Length</t>
<ul empty="true">
<li>
<t>The length of the Value field in octets.</t>
</li>
</ul>
<t>Value</t>
<ul empty="true">
<li>
<t>The value of the TLV.</t>
</li>
</ul>
</section> </section>
<section anchor="authority-id-tlv"> <section anchor="authority-id-tlv">
<name>Authority-ID TLV</name> <name>Authority-ID TLV</name>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID... | ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="true">
<ul empty="true"> <dt>M</dt>
<li> <dd>0 - Optional TLV</dd>
<t>0 - Optional TLV</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>1 - Authority-ID</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>The Length field is two octets and contains the length of the ID field
<t>Reserved, set to zero (0)</t> in octets.</dd>
</li> <dt>ID</dt>
</ul> <dd>Hint of the identity of the server to help the peer to match the
<t>TLV Type</t> credentials available for the server. It should be unique across the
<ul empty="true"> deployment.</dd>
<li> </dl>
<t>1 - Authority-ID</t>
</li>
</ul>
<t>Length</t>
<ul empty="true">
<li>
<t>The Length field is two octets and contains the length of the I
D
field in octets.</t>
</li>
</ul>
<t>ID</t>
<ul empty="true">
<li>
<t>Hint of the identity of the server to help the peer to match th
e
credentials available for the server. It should be unique across
the deployment.</t>
</li>
</ul>
</section> </section>
<section anchor="identity-type-tlv"> <section anchor="identity-type-tlv">
<name>Identity-Type TLV</name> <name>Identity-Type TLV</name>
<t>The Identity-Type TLV allows an EAP server to send a hint to help t he <t>The Identity-Type TLV allows an EAP server to send a hint to help t he
EAP peer select the right type of identity, for example, user or EAP peer select the right type of identity, for example, user or
machine. TEAPv1 implementations MUST support this TLV. Only one machine. TEAPv1 implementations <bcp14>MUST</bcp14> support this TLV. Only one
Identity-Type TLV SHOULD be present in the TEAP request or response Identity-Type TLV <bcp14>SHOULD</bcp14> be present in the TEAP request or respon
se
packet.</t> packet.</t>
<t>A server sending the Identity-Type TLV MUST also <t>A server sending the Identity-Type TLV <bcp14>MUST</bcp14> also
include an EAP-Payload TLV or a Basic-Password-Auth-Resp TLV. A include an EAP-Payload TLV or a Basic-Password-Auth-Resp TLV. A
peer sending an Identity-Type TLV MUST also include peer sending an Identity-Type TLV <bcp14>MUST</bcp14> also include
EAP-Payload TLV or a Basic-Password-Auth-Resp TLV.</t> EAP-Payload TLV or a Basic-Password-Auth-Resp TLV.</t>
<t>An EAP peer receiving an Identity-Type request <t>An EAP peer receiving an Identity-Type request
SHOULD respond with an Identity-Type TLV with the requested type. If <bcp14>SHOULD</bcp14> respond with an Identity-Type TLV with the requested type. If
the Identity-Type field does not contain one of the known values, or the Identity-Type field does not contain one of the known values, or
if the EAP peer does not have an identity corresponding to the if the EAP peer does not have an identity corresponding to the
identity type requested, then the peer SHOULD respond with an identity type requested, then the peer <bcp14>SHOULD</bcp14> respond with an
Identity-Type TLV with the one of available identity types.</t> Identity-Type TLV with the one of available identity types.</t>
<t>A server receiving an Identity-Type in the response MUST check if t he <t>A server receiving an Identity-Type in the response <bcp14>MUST</bc p14> check if the
value of the Identity-Type in the response matches the value of the value of the Identity-Type in the response matches the value of the
Identity-Type which was sent in the request. A match means that the Identity-Type that was sent in the request. A match means that the
server can proceed with authentication.</t> server can proceed with authentication.</t>
<t>However, if the values do not match, the server can proceed with <t>However, if the values do not match, the server can proceed with
authentication if and only if the following two conditions match. If authentication if and only if the following two conditions match. If
either of the following two conditions does not match, the server MUST either of the following two conditions does not match, the server <bcp14>MUST</b cp14>
respond with a Result TLV of Failure.</t> respond with a Result TLV of Failure.</t>
<ul empty="true">
<li> <ol spacing="normal" type="1">
<ol spacing="normal" type="1"><li> <li>
<t>The Identity-Type contains a value permitted by the server <t>The Identity-Type contains a value permitted by the server configuration.</
configuration.</t> t>
</li> </li>
<li> <li>
<t>The Identity-Type value was not previously used for a succe <t>The Identity-Type value was not previously used for a successful authentica
ssful authentication.</t> tion.</t>
</li> </li>
</ol> </ol>
</li>
</ul>
<t>The first condition allows a server to be configured to permit only <t>The first condition allows a server to be configured to permit only
User authentication, or else only Machine Authentication. A server user authentication, or else only machine authentication. A server
could also use an Identity-Hint TLV sent in the response to permit could also use an Identity-Hint TLV sent in the response to permit
different types of authentication for different identities. A server different types of authentication for different identities. A server
could also permit or forbid different kinds of authentication based on could also permit or forbid different kinds of authentication based on
other information, such an outer EAP Identity, or fields in an outer other information, such an outer EAP Identity, fields in an outer
EAP client certificate, or other fields received in a RADIUS or EAP client certificate, or other fields received in a RADIUS or
Diameter packet along with the TEAP session. There is no requirement Diameter packet along with the TEAP session. There is no requirement
that a server has to support both User and Machine authentication for that a server has to support both user and machine authentication for
all TEAP sessions.</t> all TEAP sessions.</t>
<t>The second condition ensures that if a particular inner method <t>The second condition ensures that if a particular inner method
succeeds, the server does not attempt a subsequent inner method for succeeds, the server does not attempt a subsequent inner method for
the same Identity-Type. For example, if a user is authenticated via the same Identity-Type. For example, if a user is authenticated via
an inner method of EAP-TLS, there is no benefit to also requesting an inner method of EAP-TLS, there is no benefit to also requesting
additional authentication via a different inner method. Similarly, additional authentication via a different inner method. Similarly,
there is no benefit to repeating an authentication sessions for the there is no benefit to repeating an authentication sessions for the
same user; the result will not change.</t> same user; the result will not change.</t>
<t>This second condition also forbids multiple rounds of challenge / <t>This second condition also forbids multiple rounds of challenge/res
response authentication via the Basic-Password-Auth-Req TLV. TEAPv1 ponse authentication via the Basic-Password-Auth-Req TLV. TEAPv1
supports only one round of Basic-Password-Auth-Req followed by supports only one round of Basic-Password-Auth-Req followed by
Basic-Password-Auth-Resp. The result of that round MUST NOT be Basic-Password-Auth-Resp. The result of that round <bcp14>MUST NOT</bcp14> be
another Basic-Password-Auth-Req TLV.</t> another Basic-Password-Auth-Req TLV.</t>
<t>This second condition also means that a server MUST NOT send an <t>This second condition also means that a server <bcp14>MUST NOT</bcp
Identity-Hint TLV which has the same value as was previously used for 14> send an
Identity-Hint TLV that has the same value as was previously used for
a successful authentication.</t> a successful authentication.</t>
<t>The Identity-Type TLV is defined as follows:</t> <t>The Identity-Type TLV is defined as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identity-Type | | Identity-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="true">
<ul empty="true"> <dt>M</dt>
<li> <dd>Mandatory, set to one (1)</dd>
<t>Mandatory, set to one (1)</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>2 - Identity-Type TLV</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>2</dd>
<t>Reserved, set to zero (0)</t> <dt>Identity-Type</dt>
</li> <dd>
</ul> <t>The Identity-Type field is two octets. Values include:</t>
<t>TLV Type</t> <dl spacing="normal" newline="false">
<ul empty="true"> <dt>1</dt><dd>User</dd>
<li> <dt>2</dt><dd>Machine</dd>
<t>2 - Identity-Type TLV</t> </dl>
</li> </dd>
</ul> </dl>
<t>Length</t>
<ul empty="true">
<li>
<t>2</t>
</li>
</ul>
<t>Identity-Type</t>
<ul empty="true">
<li>
<t>The Identity-Type field is two octets. Values include:</t>
<ul empty="true">
<li>
<t>1 User</t>
<t>2 Machine</t>
</li>
</ul>
</li>
</ul>
</section> </section>
<!-- DNE -->
<section anchor="result-tlv"> <section anchor="result-tlv">
<name>Result TLV</name> <name>Result TLV</name>
<t>The Result TLV provides support for acknowledged success and failur e <t>The Result TLV provides support for acknowledged success and failur e
messages for protected termination within TEAP. If the Status field messages for protected termination within TEAP. If the Status field
does not contain one of the known values, then the peer or EAP server does not contain one of the known values, then the peer or EAP server
MUST treat this as a fatal error of Unexpected TLVs Exchanged. The <bcp14>MUST</bcp14> treat this as a fatal error of Unexpected TLVs Exchanged. T
behavior of the Result TLV is further discussed in <xref target="protected-termi he
nation"/> and behavior of the Result TLV is further discussed in Sections <xref target="protec
<xref target="phase-2-errors"/>.</t> ted-termination" format="counter"/> and
<t>A Result TLV indicating Failure MUST NOT be accompanied by <xref target="phase-2-errors" format="counter"/>.</t>
<!--[rfced] As it is stated that all three items are TLVS, may we update
the listed items to avoid redundancy?
Original:
A Result TLV indicating Failure MUST NOT be accompanied by the
following TLVs: NAK, EAP-Payload TLV, or Crypto-Binding TLV.
Perhaps:
A Result TLV indicating failure MUST NOT be accompanied by the
following TLVs: NAK, EAP-Payload, or Crypto-Binding.
-->
<t>A Result TLV indicating failure <bcp14>MUST NOT</bcp14> be accompan
ied by
the following TLVs: NAK, EAP-Payload TLV, or Crypto-Binding TLV.</t> the following TLVs: NAK, EAP-Payload TLV, or Crypto-Binding TLV.</t>
<t>A Result TLV Indicating Success MUST be accompanied by a Crypto-Bin ding TLV.</t> <t>A Result TLV indicating success <bcp14>MUST</bcp14> be accompanied by a Crypto-Binding TLV.</t>
<t>The Result TLV is defined as follows:</t> <t>The Result TLV is defined as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="true">
<ul empty="true"> <dt>M</dt>
<li> <dd>Mandatory, set to one (1)</dd>
<t>Mandatory, set to one (1)</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>3 - Result TLV</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>2</dd>
<t>Reserved, set to zero (0)</t> <dt>Status</dt>
</li> <dd>
</ul> <t>The Status field is two octets. Values include:</t>
<t>TLV Type</t> <dl spacing="normal" newline="false">
<ul empty="true"> <dt>1</dt><dd>Success</dd>
<li> <dt>2</dt><dd>Failure</dd>
<t>3 - Result TLV</t> </dl>
</li> </dd>
</ul> </dl>
<t>Length</t> <!-- end of DNE -->
<ul empty="true">
<li>
<t>2</t>
</li>
</ul>
<t>Status</t>
<ul empty="true">
<li>
<t>The Status field is two octets. Values include:</t>
<ul empty="true">
<li>
<t>1 Success</t>
<t>2 Failure</t>
</li>
</ul>
</li>
</ul>
</section> </section>
<section anchor="nak-tlv"> <section anchor="nak-tlv">
<name>NAK TLV</name> <name>NAK TLV</name>
<t>The NAK TLV allows a peer to detect TLVs that are not supported by <t>The NAK TLV allows a peer to detect TLVs that are not supported by
the other peer. A TEAP packet can contain 0 or more NAK TLVs. A NAK the other peer. A TEAP packet can contain 0 or more NAK TLVs. A NAK
TLV should not be accompanied by other TLVs. A NAK TLV MUST NOT be TLV should not be accompanied by other TLVs. A NAK TLV <bcp14>MUST NOT</bcp14> be
sent in response to a message containing a Result TLV, instead a sent in response to a message containing a Result TLV, instead a
Result TLV of failure should be sent indicating failure and an Error Result TLV of failure should be sent indicating failure and an Error
TLV of Unexpected TLVs Exchanged. The NAK TLV is defined as follows:</t> TLV of Unexpected TLVs Exchanged. The NAK TLV is defined as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id | | Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAK-Type | TLVs... | NAK-Type | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="true">
<ul empty="true"> <dt>M</dt>
<li> <dd>Mandatory, set to one (1)</dd>
<t>Mandatory, set to one (1)</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>4 - NAK TLV</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>&gt;=6</dd>
<t>Reserved, set to zero (0)</t> <dt>Vendor-Id</dt>
</li> <dd>The Vendor-Id field is four octets and contains the Vendor-Id of the TLV
</ul> that was not supported. The high-order octet is 0, and the low-order three
<t>TLV Type</t> octets are the Structure of Management Information (SMI) Network Management
<ul empty="true"> Private Enterprise Number of the Vendor in network byte order. The
<li> Vendor-Id field <bcp14>MUST</bcp14> be zero for TLVs that are not
<t>4 - NAK TLV</t> Vendor-Specific TLVs.</dd>
</li> <dt>NAK-Type</dt>
</ul> <dd>The NAK-Type field is two octets. The field contains the type of the
<t>Length</t> TLV that was not supported. A TLV of this type <bcp14>MUST</bcp14> have
<ul empty="true"> been included in the previous packet.</dd>
<li> <dt>TLVs</dt>
<t>&gt;=6</t> <dd>This field contains a list of zero or more TLVs, each of which
</li> <bcp14>MUST NOT</bcp14> have the mandatory bit set. These optional TLVs are
</ul> for future extensibility to communicate why the offending TLV was determined
<t>Vendor-Id</t> to be unsupported.</dd>
<ul empty="true"> </dl>
<li>
<t>The Vendor-Id field is four octets and contains the Vendor-Id o
f
the TLV that was not supported. The high-order octet is 0, and
the low-order three octets are the Structure of Management
Information (SMI) Network Management Private Enterprise Number of
the Vendor in network byte order. The Vendor-Id field MUST be
zero for TLVs that are not Vendor-Specific TLVs.</t>
</li>
</ul>
<t>NAK-Type</t>
<ul empty="true">
<li>
<t>The NAK-Type field is two octets. The field contains the type
of
the TLV that was not supported. A TLV of this type MUST have been
included in the previous packet.</t>
</li>
</ul>
<t>TLVs</t>
<ul empty="true">
<li>
<t>This field contains a list of zero or more TLVs, each of which
MUST NOT have the mandatory bit set. These optional TLVs are for
future extensibility to communicate why the offending TLV was
determined to be unsupported.</t>
</li>
</ul>
</section> </section>
<!-- DNE -->
<section anchor="error-tlv"> <section anchor="error-tlv">
<name>Error TLV</name> <name>Error TLV</name>
<t>The Error TLV allows an EAP peer or server to indicate errors to th e <t>The Error TLV allows an EAP peer or server to indicate errors to th e
other party. A TEAP packet can contain 0 or more Error TLVs. The other party. A TEAP packet can contain 0 or more Error TLVs. The
Error-Code field describes the type of error. Error codes 1-999 Error-Code field describes the type of error. Error codes 1-999
represent successful outcomes (informative messages), 1000-1999 represent successful outcomes (informative messages), 1000-1999
represent warnings, and 2000-2999 represent fatal errors. A fatal represent warnings, and 2000-2999 represent fatal errors. A fatal
Error TLV MUST be accompanied by a Result TLV indicating failure, and Error TLV <bcp14>MUST</bcp14> be accompanied by a Result TLV indicating failure, and
the conversation is terminated as described in <xref target="phase-2-errors"/>.< /t> the conversation is terminated as described in <xref target="phase-2-errors"/>.< /t>
<t>Many of the error codes below refer to errors in inner method <t>Many of the error codes below refer to errors in inner method
processing that may be retrieved if made available by the inner processing that may be retrieved if made available by the inner
method. Implementations MUST take care that error messages do not method. Implementations <bcp14>MUST</bcp14> take care that error messages do no t
reveal too much information to an attacker. For example, the usage reveal too much information to an attacker. For example, the usage
of error message 1031 (User account credentials incorrect) is NOT of error message 1031 (User account credentials incorrect) is
RECOMMENDED, because it allows an attacker to determine valid <bcp14>NOT RECOMMENDED</bcp14>, because it allows an attacker to determine valid
usernames by differentiating this response from other responses. It usernames by differentiating this response from other responses. It
should only be used for troubleshooting purposes.</t> should only be used for troubleshooting purposes.</t>
<t>The Error TLV is defined as follows:</t> <t>The Error TLV is defined as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code | | Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="true">
<ul empty="true"> <dt>M</dt>
<li> <dd>Mandatory, set to one (1)</dd>
<t>Mandatory, set to one (1)</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>5 - Error TLV</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>4</dd>
<t>Reserved, set to zero (0)</t> <dt>Error-Code</dt>
</li> <dd>
</ul> <t>The Error-Code field is four octets. Currently defined values for
<t>TLV Type</t> Error-Code include:</t>
<ul empty="true"> <dl spacing="normal" newline="false">
<li> <dt>1</dt><dd>User account expires soon</dd>
<t>5 - Error TLV</t> <dt>2</dt><dd>User account credential expires soon</dd>
</li> <dt>3</dt><dd>User account authorizations change soon</dd>
</ul> <dt>4</dt><dd>Clock skew detected</dd>
<t>Length</t> <dt>5</dt><dd>Contact administrator</dd>
<ul empty="true"> <dt>6</dt><dd>User account credentials change required</dd>
<li> <dt>1001</dt><dd>Inner Method Error</dd>
<t>4</t> <dt>1002</dt><dd>Unspecified authentication infrastructure problem</dd>
</li> <dt>1003</dt><dd> Unspecified authentication failure</dd>
</ul> <dt>1004</dt><dd> Unspecified authorization failure</dd>
<t>Error-Code</t> <dt>1005</dt><dd> User account credentials unavailable</dd>
<ul empty="true"> <dt>1006</dt><dd> User account expired</dd>
<li> <dt>1007</dt><dd> User account locked: try again later</dd>
<t>The Error-Code field is four octets. Currently defined values <dt>1008</dt><dd> User account locked: admin intervention required</dd>
for <dt>1009</dt><dd> Authentication infrastructure unavailable</dd>
Error-Code include:</t> <dt>1010</dt><dd> Authentication infrastructure not trusted</dd>
<ul empty="true"> <dt>1011</dt><dd> Clock skew too great</dd>
<li> <dt>1012</dt><dd> Invalid inner realm</dd>
<t>1 User account expires soon</t> <dt>1013</dt><dd> Token out of sync: administrator intervention required<
<t>2 User account credential expires soon</t> /dd>
<t>3 User account authorizations change soon</t> <dt>1014</dt><dd> Token out of sync: PIN change required</dd>
<t>4 Clock skew detected</t> <dt>1015</dt><dd> Token revoked</dd>
<t>5 Contact administrator</t> <dt>1016</dt><dd> Tokens exhausted</dd>
<t>6 User account credentials change required</t> <dt>1017</dt><dd> Challenge expired</dd>
<t>1001 Inner Method Error</t> <dt>1018</dt><dd> Challenge algorithm mismatch</dd>
<t>1002 Unspecified authentication infrastructure problem</t> <dt>1019</dt><dd> Client certificate not supplied</dd>
<t>1003 Unspecified authentication failure</t> <dt>1020</dt><dd> Client certificate rejected</dd>
<t>1004 Unspecified authorization failure</t> <dt>1021</dt><dd> Realm mismatch between inner and outer identity</dd>
<t>1005 User account credentials unavailable</t> <dt>1022</dt><dd> Unsupported Algorithm In Certificate Signing Request</d
<t>1006 User account expired</t> d>
<t>1007 User account locked: try again later</t> <dt>1023</dt><dd> Unsupported Extension In Certificate Signing Request</d
<t>1008 User account locked: admin intervention required</t> d>
<t>1009 Authentication infrastructure unavailable</t> <dt>1024</dt><dd> Bad Identity In Certificate Signing Request</dd>
<t>1010 Authentication infrastructure not trusted</t> <dt>1025</dt><dd> Bad Certificate Signing Request</dd>
<t>1011 Clock skew too great</t> <dt>1026</dt><dd> Internal CA Error</dd>
<t>1012 Invalid inner realm</t> <dt>1027</dt><dd> General PKI Error</dd>
<t>1013 Token out of sync: administrator intervention require <dt>1028</dt><dd> Inner method's channel-binding data required but not
d</t> supplied</dd>
<t>1014 Token out of sync: PIN change required</t> <dt>1029</dt><dd> Inner method's channel-binding data did not include
<t>1015 Token revoked</t> required information</dd>
<t>1016 Tokens exhausted</t> <dt>1030</dt><dd> Inner method's channel binding failed</dd>
<t>1017 Challenge expired</t> <dt>1031</dt><dd> User account credentials incorrect [USAGE <bcp14>NOT RE
<t>1018 Challenge algorithm mismatch</t> COMMENDED</bcp14>]</dd>
<t>1019 Client certificate not supplied</t> <dt>1032</dt><dd> Inner method not supported</dd>
<t>1020 Client certificate rejected</t> <dt>2001</dt><dd> Tunnel Compromise Error</dd>
<t>1021 Realm mismatch between inner and outer identity</t> <dt>2002</dt><dd> Unexpected TLVs Exchanged</dd>
<t>1022 Unsupported Algorithm In Certificate Signing Request< <dt>2003</dt><dd> The Crypto-Binding TLV is invalid (Version, Received-Ve
/t> r, or Sub-Type)</dd>
<t>1023 Unsupported Extension In Certificate Signing Request< <dt>2004</dt><dd> The first inner method did not derive EMSK</dd>
/t> <dt>2005</dt><dd> The Crypto-Binding TLV did not include a required MSK C
<t>1024 Bad Identity In Certificate Signing Request</t> ompound-MAC</dd>
<t>1025 Bad Certificate Signing Request</t> <dt>2006</dt><dd> The MSK Compound-MAC fails verification</dd>
<t>1026 Internal CA Error</t> <dt>2007</dt><dd> The Crypto-Binding TLV did not include a required EMSK
<t>1027 General PKI Error</t> Compound-MAC</dd>
<t>1028 Inner method's channel-binding data required but not <dt>2008</dt><dd> The EMSK Compound-MAC fails verification</dd>
supplied</t> <dt>2009</dt><dd> The EMSK Compound-MAC exists, but the inner method did
<t>1029 Inner method's channel-binding data did not include r not derive EMSK</dd>
equired </dl>
information</t> </dd>
<t>1030 Inner method's channel binding failed</t> </dl>
<t>1031 User account credentials incorrect [USAGE NOT RECOMME <!-- end of DNE -->
NDED]</t>
<t>1032 Inner method not supported</t>
<t>2001 Tunnel Compromise Error</t>
<t>2002 Unexpected TLVs Exchanged</t>
<t>2003 The Crypto-Binding TLV is invalid (Version, or Receiv
ed-Ver, or Sub-Type)</t>
<t>2004 The first inner method did not derive EMSK</t>
<t>2005 The Crypto-Binding TLV did not include a required MSK
Compound-MAC</t>
<t>2006 The MSK Compound-MAC fails verification</t>
<t>2007 The Crypto-Binding TLV did not include a required EMS
K Compound-MAC</t>
<t>2008 The EMSK Compound-MAC fails verification</t>
<t>2009 The EMSK Compound-MAC exists, but the inner method di
d not derive EMSK</t>
</li>
</ul>
</li>
</ul>
</section> </section>
<!-- DNE -->
<section anchor="channel-binding-tlv"> <section anchor="channel-binding-tlv">
<name>Channel-Binding TLV</name> <name>Channel-Binding TLV</name>
<t>The Channel-Binding TLV provides a mechanism for carrying <t>The Channel-Binding TLV provides a mechanism for carrying
channel-binding data from the peer to the EAP server and a channel-binding channel-binding data from the peer to the EAP server and a channel-binding
response from the EAP server to the peer as described in <xref target="RFC6677"/ >. response from the EAP server to the peer as described in <xref target="RFC6677"/ >.
TEAPv1 implementations MAY support this TLV, which cannot be TEAPv1 implementations <bcp14>MAY</bcp14> support this TLV, which cannot be
responded to with a NAK TLV. If the Channel-Binding data field does responded to with a NAK TLV. If the Channel-Binding data field does
not contain one of the known values or if the EAP server does not not contain one of the known values or if the EAP server does not
support this TLV, then the server MUST ignore the value. The support this TLV, then the server <bcp14>MUST</bcp14> ignore the value. The
Channel-Binding TLV is defined as follows:</t> Channel-Binding TLV is defined as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ... | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="true">
<ul empty="true"> <dt>M</dt>
<li> <dd>0 - Optional TLV</dd>
<t>0 - Optional TLV</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>6 - Channel-Binding TLV</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>variable</dd>
<t>Reserved, set to zero (0)</t> <dt>Data</dt>
</li> <dd>The data field contains a channel-binding message as defined in
</ul> <xref target="RFC6677" section="5.3"/>.</dd>
<t>TLV Type</t> </dl>
<ul empty="true"> <!-- end of DNE -->
<li>
<t>6 - Channel-Binding TLV</t>
</li>
</ul>
<t>Length</t>
<ul empty="true">
<li>
<t>variable</t>
</li>
</ul>
<t>Data</t>
<ul empty="true">
<li>
<t>The data field contains a channel-binding message as defined in
Section 5.3 of <xref target="RFC6677"/>.</t>
</li>
</ul>
</section> </section>
<section anchor="vendor-specific-tlv"> <section anchor="vendor-specific-tlv">
<name>Vendor-Specific TLV</name> <name>Vendor-Specific TLV</name>
<t>The Vendor-Specific TLV is available to allow vendors to support <t>The Vendor-Specific TLV is available to allow vendors to support
their own extended attributes not suitable for general usage. A their own extended attributes not suitable for general usage. A
Vendor-Specific TLV attribute can contain one or more TLVs, referred Vendor-Specific TLV attribute can contain one or more TLVs, referred
to as Vendor TLVs. The TLV type of a particular Vendor TLV is defined by the to as Vendor TLVs. The TLV type of a particular Vendor TLV is defined by the
vendor. All the Vendor TLVs inside a single Vendor-Specific TLV vendor. All the Vendor TLVs inside a single Vendor-Specific TLV
belong to the same vendor. There can be multiple Vendor-Specific belong to the same vendor. There can be multiple Vendor-Specific
TLVs from different vendors in the same message. Error handling in TLVs from different vendors in the same message. Error handling in
the Vendor TLV could use the vendor's own specific error-handling the Vendor TLV could use the vendor's own specific error-handling
mechanism or use the standard TEAP error codes defined.</t> mechanism or use the standard TEAP error codes defined.</t>
<t>Vendor TLVs may be optional or mandatory. Vendor TLVs sent with <t>Vendor TLVs may be optional or mandatory. Vendor TLVs sent with
Result TLVs MUST be marked as optional. If the Vendor-Specific TLV Result TLVs <bcp14>MUST</bcp14> be marked as optional. If the Vendor-Specific T LV
is marked as mandatory, then it is expected that the receiving side is marked as mandatory, then it is expected that the receiving side
needs to recognize the vendor ID, parse all Vendor TLVs within, and needs to recognize the vendor ID, parse all Vendor TLVs within, and
deal with error handling within the Vendor-Specific TLV as defined by deal with error handling within the Vendor-Specific TLV as defined by
the vendor.</t> the vendor.</t>
<t>Where a Vendor-Specific TLV carries an authentication protocol in t he <t>Where a Vendor-Specific TLV carries an authentication protocol in t he
inner method, it MUST define values for MSK and EMSK. Where these inner method, it <bcp14>MUST</bcp14> define values for MSK and EMSK. Where thes
values cannot be derived from cryptographic primitives, they MUST be e
values cannot be derived from cryptographic primitives, they <bcp14>MUST</bcp14>
be
set to zero, as happens when Basic-Password-Auth-Req is used.</t> set to zero, as happens when Basic-Password-Auth-Req is used.</t>
<t>The Vendor-Specific TLV is defined as follows:</t> <t>The Vendor-Specific TLV is defined as follows:</t>
<!-- DNE -->
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id | | Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor TLVs.... | Vendor TLVs....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="true">
<ul empty="true"> <dt>M</dt>
<li> <dd>0 or 1</dd>
<t>0 or 1</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>7 - Vendor-Specific TLV</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>4 + cumulative length of all included Vendor TLVs</dd>
<t>Reserved, set to zero (0)</t> <dt>Vendor-Id</dt>
</li> <dd>The Vendor-Id field is four octets and contains the Vendor-Id of the
</ul> TLV. The high-order octet is 0, and the low-order 3 octets are the SMI
<t>TLV Type</t> Network Management Private Enterprise Number of the Vendor in network byte
<ul empty="true"> order.</dd>
<li> <dt>Vendor TLVs</dt>
<t>7 - Vendor-Specific TLV</t> <dd>This field is of indefinite length. It contains Vendor-Specific TLVs,
</li> in a format defined by the vendor.</dd>
</ul> </dl>
<t>Length</t> <!-- end of DNE -->
<ul empty="true">
<li>
<t>4 + cumulative length of all included Vendor TLVs</t>
</li>
</ul>
<t>Vendor-Id</t>
<ul empty="true">
<li>
<t>The Vendor-Id field is four octets and contains the Vendor-Id o
f
the TLV. The high-order octet is 0, and the low-order 3 octets
are the SMI Network Management Private Enterprise Number of the
Vendor in network byte order.</t>
</li>
</ul>
<t>Vendor TLVs</t>
<ul empty="true">
<li>
<t>This field is of indefinite length. It contains Vendor-Specifi
c
TLVs, in a format defined by the vendor.</t>
</li>
</ul>
</section> </section>
<section anchor="request-action-tlv"> <section anchor="request-action-tlv">
<name>Request-Action TLV</name> <name>Request-Action TLV</name>
<t>The Request-Action TLV MAY be sent at any time. The Request-Action <t>The Request-Action TLV <bcp14>MAY</bcp14> be sent at any time. The
TLV allows the peer or server to request that other side negotiates Request-Action
additional inner methods or process TLVs which are passed inside of TLV allows the peer or server to request that the other side negotiates
additional inner methods or process TLVs that are passed inside of
the Request-Action TLV.</t> the Request-Action TLV.</t>
<t>The receiving side MUST process this TLV. The processing for the T LV <t>The receiving side <bcp14>MUST</bcp14> process this TLV. The proce ssing for the TLV
is as follows:</t> is as follows:</t>
<ul empty="true">
<li> <t indent="3">The receiving entity <bcp14>MAY</bcp14> choose to pr
<t>The receiving entity MAY choose to process any of the TLVs that ocess any of the TLVs that
are included in the message.</t> are included in the message.</t>
<t>If the receiving entity chooses NOT to process any TLV in the <t indent="3">If the receiving entity chooses NOT to process any T LV in the
list, then it sends back a Result TLV with the same code in the list, then it sends back a Result TLV with the same code in the
Status field of the Request-Action TLV.</t> Status field of the Request-Action TLV.</t>
<t>If multiple Request-Action TLVs are in the request, the session <t indent="3">If multiple Request-Action TLVs are in the request, the session
can continue if any of the TLVs in any Request-Action TLV are can continue if any of the TLVs in any Request-Action TLV are
processed.</t> processed.</t>
</li> <t indent="3">If multiple Request-Action TLVs are in the request a
</ul> nd none of
<ul empty="true">
<li>
<t>If multiple Request-Action TLVs are in the request and none of
them is processed, then the most fatal status should be used in them is processed, then the most fatal status should be used in
the Result TLV returned. If a status code in the Request-Action the Result TLV returned. If a status code in the Request-Action
TLV is not understood by the receiving entity, then it SHOULD be TLV is not understood by the receiving entity, then it <bcp14>SHOULD</bcp14> be
treated as a fatal error. Otherwise, the receiving entity MAY send a Request-Ac treated as a fatal error. Otherwise, the receiving entity <bcp14>MAY</bcp14> se
tion TLV containing an Error TLV of value 2002 (Unexpected TLVs Exchanged).</t> nd a Request-Action TLV containing an Error TLV of value 2002 (Unexpected TLVs E
<t>After processing the TLVs or inner method in the request, anoth xchanged).</t>
er <t indent="3">After processing the TLVs or inner method in the req
round of Result TLV exchange MUST occur to synchronize the final uest, another
round of Result TLV exchange <bcp14>MUST</bcp14> occur to synchronize the final
status on both sides.</t> status on both sides.</t>
</li>
</ul> <t>The peer or the server <bcp14>MAY</bcp14> send multiple Request-Act
<t>The peer or the server MAY send multiple Request-Action TLVs to the ion TLVs to the
other side. Two Request-Action TLVs MUST NOT occur in the same TEAP other side. Two Request-Action TLVs <bcp14>MUST NOT</bcp14> occur in the same T
EAP
packet if they have the same Status value. The order of processing packet if they have the same Status value. The order of processing
multiple Request-Action TLVs is implementation dependent. If the multiple Request-Action TLVs is implementation dependent. If the
receiving side processes the optional (non-fatal) items first, it is receiving side processes the optional (non-fatal) items first, it is
possible that the fatal items will disappear at a later time. If the possible that the fatal items will disappear at a later time. If the
receiving side processes the fatal items first, the communication receiving side processes the fatal items first, the communication
time will be shorter.</t> time will be shorter.</t>
<t>The peer or the server MAY return a new set of Request-Action TLVs <t>The peer or the server <bcp14>MAY</bcp14> return a new set of Reque st-Action TLVs
after one or more of the requested items have been processed and the after one or more of the requested items have been processed and the
other side has signaled it wants to end the EAP conversation.</t> other side has signaled it wants to end the EAP conversation.</t>
<t>The Request-Action TLV is defined as follows:</t> <t>The Request-Action TLV is defined as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Action | TLVs.... | Status | Action | TLVs....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="true">
<ul empty="true"> <dt>M</dt>
<li> <dd>Mandatory, set to one (1)</dd>
<t>Mandatory, set to one (1)</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>8 - Request-Action TLV</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>2 + cumulative length of all included TLVs</dd>
<t>Reserved, set to zero (0)</t> <dt>Status</dt>
</li> <dd><t>The Status field is one octet. This indicates the result if the party
</ul> who receives this TLV does not process the action. Values include:</t>
<t>TLV Type</t> <dl spacing="normal" newline="false">
<ul empty="true"> <dt>1</dt><dd>Success</dd>
<li> <dt>2</dt><dd>Failure</dd>
<t>8 - Request-Action TLV</t> </dl>
</li> </dd>
</ul> <dt>Action</dt>
<t>Length</t> <dd><t>The Action field is one octet. Values include:</t>
<ul empty="true"> <dl spacing="normal" newline="false">
<li> <dt>1</dt><dd>Process-TLV</dd>
<t>2 + cumulative length of all included TLVs</t> <dt>2</dt><dd>Negotiate-EAP</dd>
</li> </dl>
</ul> </dd>
<t>Status</t> <dt>TLVs</dt>
<ul empty="true"> <dd>This field is of indefinite length. It contains TLVs that the peer
<li> wants the server to process.</dd>
<t>The Status field is one octet. This indicates the result if th </dl>
e
party who receives this TLV does not process the action. Values
include:</t>
<ul empty="true">
<li>
<t>1 Success</t>
<t>2 Failure</t>
</li>
</ul>
</li>
</ul>
<t>Action</t>
<ul empty="true">
<li>
<t>The Action field is one octet. Values include:</t>
<ul empty="true">
<li>
<t>1 Process-TLV</t>
<t>2 Negotiate-EAP</t>
</li>
</ul>
</li>
</ul>
<t>TLVs</t>
<ul empty="true">
<li>
<t>This field is of indefinite length. It contains TLVs that the
peer wants the server to process.</t>
</li>
</ul>
</section> </section>
<section anchor="eap-payload-tlv"> <section anchor="eap-payload-tlv">
<name>EAP-Payload TLV</name> <name>EAP-Payload TLV</name>
<!-- DNE -->
<t>To allow coalescing an EAP request or response with other TLVs, the <t>To allow coalescing an EAP request or response with other TLVs, the
EAP-Payload TLV is defined, which includes an encapsulated EAP packet EAP-Payload TLV is defined, which includes an encapsulated EAP packet
and a list of optional TLVs. The optional TLVs are provided for and a list of optional TLVs. The optional TLVs are provided for
future extensibility to provide hints about the current EAP future extensibility to provide hints about the current EAP
authentication. Only one EAP-Payload TLV is allowed in a message. authentication. Only one EAP-Payload TLV is allowed in a message.
The EAP-Payload TLV is defined as follows:</t> The EAP-Payload TLV is defined as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP packet... | EAP packet...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs... | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="true">
<ul empty="true"> <dt>M</dt>
<li> <dd>Mandatory, set to one (1)</dd>
<t>Mandatory, set to one (1)</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>9 - EAP-Payload TLV</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>length of embedded EAP packet + cumulative length of additional TLVs</dd>
<t>Reserved, set to zero (0)</t> <dt>EAP packet</dt>
</li> <dd>This field contains a complete EAP packet, including the EAP header
</ul> (Code, Identifier, Length, Type) fields. The length of this field is
<t>TLV Type</t> determined by the Length field of the encapsulated EAP packet.</dd>
<ul empty="true"> <dt>TLVs</dt>
<li> <dd>This (optional) field contains a list of TLVs associated with the EAP
<t>9 - EAP-Payload TLV</t> packet field. The TLVs <bcp14>MUST NOT</bcp14> have the mandatory bit set.
</li> The total length of this field is equal to the Length field of the
</ul> EAP-Payload TLV, minus the Length field in the EAP header of the EAP packet
<t>Length</t> field.</dd>
<ul empty="true"> </dl>
<li> <!-- end of DNE -->
<t>length of embedded EAP packet + cumulative length of additional
TLVs</t>
</li>
</ul>
<t>EAP packet</t>
<ul empty="true">
<li>
<t>This field contains a complete EAP packet, including the EAP
header (Code, Identifier, Length, Type) fields. The length of
this field is determined by the Length field of the encapsulated
EAP packet.</t>
</li>
</ul>
<t>TLVs</t>
<ul empty="true">
<li>
<t>This (optional) field contains a list of TLVs associated with t
he
EAP packet field. The TLVs MUST NOT have the mandatory bit set.
The total length of this field is equal to the Length field of the
EAP-Payload TLV, minus the Length field in the EAP header of the
EAP packet field.</t>
</li>
</ul>
</section> </section>
<section anchor="intermediate-result-tlv"> <section anchor="intermediate-result-tlv">
<name>Intermediate-Result TLV</name> <name>Intermediate-Result TLV</name>
<t>The Intermediate-Result TLV signals <t>The Intermediate-Result TLV signals
intermediate Success and Failure messages for all inner intermediate Success and Failure messages for all inner
methods. The Intermediate-Result TLV MUST be be used for all inner methods.</t> methods. The Intermediate-Result TLV <bcp14>MUST</bcp14> be used for all inner
<t>An Intermediate-Result TLV indicating Success methods.</t>
MUST be accompanied by a Crypto-Binding TLV.</t> <t>An Intermediate-Result TLV indicating success
<t>An Intermediate-Result TLV indicating Failure SHOULD be accompanied <bcp14>MUST</bcp14> be accompanied by a Crypto-Binding TLV.</t>
by an Error TLV which indicates why the authentication failed.</t> <t>An Intermediate-Result TLV indicating failure <bcp14>SHOULD</bcp14>
be accompanied by an Error TLV that indicates why the authentication failed.</t
>
<t>The optional TLVs <t>The optional TLVs
associated with this TLV are provided for future extensibility to associated with this TLV are provided for future extensibility to
provide hints about the current result. The Intermediate-Result TLV provide hints about the current result. The Intermediate-Result TLV
is defined as follows:</t> is defined as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | TLVs... | Status | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="true">
<ul empty="true"> <dt>M</dt>
<li> <dd>Mandatory, set to one (1)</dd>
<t>Mandatory, set to one (1)</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>10 - Intermediate-Result TLV</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>2 + cumulative length of the embedded associated TLVs</dd>
<t>Reserved, set to zero (0)</t> <dt>Status</dt>
</li> <dd>
</ul> <t>The Status field is two octets. Values include:</t>
<t>TLV Type</t> <dl newline="false" spacing="normal">
<ul empty="true"> <dt>1</dt><dd>Success</dd>
<li> <dt>2</dt><dd>Failure</dd>
<t>10 - Intermediate-Result TLV</t> </dl>
</li> </dd>
</ul> <dt>TLVs</dt>
<t>Length</t> <dd>This field is of indeterminate length and contains zero or more of the
<ul empty="true"> TLVs associated with the Intermediate Result TLV. The TLVs in this field
<li> <bcp14>MUST NOT</bcp14> have the mandatory bit set.</dd>
<t>2 + cumulative length of the embedded associated TLVs</t> </dl>
</li>
</ul>
<t>Status</t>
<ul empty="true">
<li>
<t>The Status field is two octets. Values include:</t>
<ul empty="true">
<li>
<t>1 Success</t>
<t>2 Failure</t>
</li>
</ul>
</li>
</ul>
<t>TLVs</t>
<ul empty="true">
<li>
<t>This field is of indeterminate length and contains zero or more
of
the TLVs associated with the Intermediate Result TLV. The TLVs in
this field MUST NOT have the mandatory bit set.</t>
</li>
</ul>
</section> </section>
<section anchor="pac-tlv"> <section anchor="pac-tlv">
<name>PAC TLV</name> <name>PAC TLV</name>
<t><xref target="RFC7170"/> defined a Protected Access Credential (PAC ) to mirror <t><xref target="RFC7170"/> defined a Protected Access Credential (PAC ) to mirror
EAP-FAST <xref target="RFC4851"/>. However, implementation experience and analy sis EAP-FAST <xref target="RFC4851"/>. However, implementation experience and analy sis
determined that the PAC was not necessary. Instead, TEAP performs determined that the PAC was not necessary. Instead, TEAP performs
session resumption using the NewSessionTicket message as defined in session resumption using the NewSessionTicket message as defined in Sections
<xref section="2.1.2" sectionFormat="comma" target="RFC9190"/> and Section 2.1.3 <xref section="2.1.2" sectionFormat="bare" target="RFC9190"/> and <xref section=
. As such, the PAC TLV "2.1.3" sectionFormat="bare" target="RFC9190"/> of <xref target="RFC9190"/>. As
such, the PAC TLV
has been deprecated.</t> has been deprecated.</t>
<t>As the PAC TLV is deprecated, an entity receiving it SHOULD send a <t>As the PAC TLV is deprecated, an entity receiving it <bcp14>SHOULD<
Result TLV indicating failure, and an Error TLV of Unexpected TLVs /bcp14> send a
Result TLV indicating failure and an Error TLV of Unexpected TLVs
Exchanged.</t> Exchanged.</t>
</section> </section>
<section anchor="crypto-binding-tlv"> <section anchor="crypto-binding-tlv">
<name>Crypto-Binding TLV</name> <name>Crypto-Binding TLV</name>
<t>The Crypto-Binding TLV is used to prove that both the peer and serv er <t>The Crypto-Binding TLV is used to prove that both the peer and serv er
participated in the tunnel establishment and sequence of participated in the tunnel establishment and sequence of
authentications. It also provides verification of the TEAP type, authentications. It also provides verification of the TEAP type,
version negotiated, and Outer TLVs exchanged before the TLS tunnel version negotiated, and Outer TLVs exchanged before the TLS tunnel
establishment.</t> establishment.</t>
<t>A Crypto-Binding MUST be accompanied by an Intermediate-Result TLV <t>A Crypto-Binding <bcp14>MUST</bcp14> be accompanied by an Intermedi
indicating Success.</t> ate-Result TLV
<t>The Crypto-Binding TLV MUST be exchanged and validated before any indicating success.</t>
<t>The Crypto-Binding TLV <bcp14>MUST</bcp14> be exchanged and validat
ed before any
Intermediate-Result or Result TLV value is examined, regardless of Intermediate-Result or Result TLV value is examined, regardless of
whether there is an inner method or not. It MUST be whether there is an inner method or not. It <bcp14>MUST</bcp14> be
included with the Intermediate-Result TLV to perform cryptographic included with the Intermediate-Result TLV to perform cryptographic
binding after each successful inner method in a sequence of inner binding after each successful inner method in a sequence of inner
methods, before proceeding with another inner method. If no MSK or methods, before proceeding with another inner method. If no MSK or
EMSK has been generated and a Crypto-Binding TLV is required then the EMSK has been generated and a Crypto-Binding TLV is required, then the
MSK Compound-MAC field contains the MAC using keys generated according MSK Compound-MAC field contains the MAC using keys generated according
to <xref target="computing-compound-mac"/>.</t> to <xref target="computing-compound-mac"/>.</t>
<t>The Crypto-Binding TLV is valid only if the following checks pass o n <t>The Crypto-Binding TLV is valid only if the following checks pass o n
its contents:</t> its contents:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The Version field contain a known value,</t> <t>The Version field contain a known value.</t>
</li> </li>
<li> <li>
<t>The Received-Ver field matches the TEAP version sent by the rec eiver during the EAP version negotiation,</t> <t>The Received-Ver field matches the TEAP version sent by the rec eiver during the EAP version negotiation.</t>
</li> </li>
<li> <li>
<t>The Sub-Type field is set to the correct value for this exchang e,</t> <t>The Sub-Type field is set to the correct value for this exchang e.</t>
</li> </li>
<li> <li>
<t>The Flags field is set to a known value,</t> <t>The Flags field is set to a known value.</t>
</li> </li>
<li> <li>
<t>The Compound-MAC(s) verify correctly.</t> <t>The Compound-MAC(s) verify correctly.</t>
</li> </li>
</ul> </ul>
<t>If any of the above checks fails, then the TLV is invalid. An <t>If any of the above checks fails, then the TLV is invalid. An
invalid Crypto-Binding TLV is a fatal error and is handled as invalid Crypto-Binding TLV is a fatal error and is handled as
described in <xref target="phase-2-errors"/></t> described in <xref target="phase-2-errors"/></t>
<t>See <xref target="cryptographic-calculations"/> for a more detailed discussion of <t>See <xref target="cryptographic-calculations"/> for a more detailed discussion of
how the Compound-MAC fields are constructed and verified.</t> how the Compound-MAC fields are constructed and verified.</t>
skipping to change at line 2282 skipping to change at line 2150
~ Nonce ~ ~ Nonce ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ EMSK Compound-MAC ~ ~ EMSK Compound-MAC ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ MSK Compound-MAC ~ ~ MSK Compound-MAC ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="true">
<ul empty="true"> <dt>M</dt>
<li> <dd>Mandatory, set to one (1)</dd>
<t>Mandatory, set to one (1)</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>12 - Crypto-Binding TLV</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>76</dd>
<t>Reserved, set to zero (0)</t> <dt>Reserved</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>Version</dt>
<t>TLV Type</t> <dd>The Version field is a single octet, which is set to the version of
<ul empty="true"> Crypto-Binding TLV the TEAP method is using. For an implementation
<li> compliant with TEAPv1, the version number <bcp14>MUST</bcp14> be set to one
<t>12 - Crypto-Binding TLV</t> (1).</dd>
</li> <dt>Received-Ver</dt>
</ul> <dd><t>The Received-Ver field is a single octet and <bcp14>MUST</bcp14> be set
<t>Length</t> to the TEAP version number received during version negotiation. Note that
<ul empty="true"> this field only provides protection against downgrade attacks, where a
<li> version of EAP requiring support for this TLV is required on both sides.</t>
<t>76</t> <t>For TEAPv1, this version number <bcp14>MUST</bcp14> be set to one (1).</t>
</li> </dd>
</ul> <dt>Flags</dt>
<t>Reserved</t> <dd><t>The Flags field is four bits. Defined values include:</t>
<ul empty="true"> <dl spacing="normal" newline="false">
<li> <dt>1</dt><dd>EMSK Compound-MAC is present</dd>
<t>Reserved, set to zero (0)</t> <dt>2</dt><dd>MSK Compound-MAC is present</dd>
</li> <dt>3</dt><dd>Both EMSK and MSK Compound-MAC are present</dd>
</ul> </dl>
<t>Version</t> <t>All other values of the Flags field are invalid.</t>
<ul empty="true"> </dd>
<li> <dt>Sub-Type</dt>
<t>The Version field is a single octet, which is set to the versio <dd><t>The Sub-Type field is four bits. Defined values include:</t>
n <dl spacing="normal" newline="false">
of Crypto-Binding TLV the TEAP method is using. For an <dt>0</dt><dd>Binding Request</dd>
implementation compliant with TEAPv1, the version <dt>1</dt><dd>Binding Response</dd>
number MUST be set to one (1).</t> </dl>
</li> <t>All other values of the Sub-Type field are invalid.</t>
</ul> </dd>
<t>Received-Ver</t> <dt>Nonce</dt>
<ul empty="true"> <dd>The Nonce field is 32 octets. It contains a 256-bit nonce that is
<li> temporally unique, used for Compound-MAC key derivation at each end. The
<t>The Received-Ver field is a single octet and MUST be set to the nonce in a request <bcp14>MUST</bcp14> have its least significant bit set to
TEAP version number received during version negotiation. Note zero (0), and the nonce in a response <bcp14>MUST</bcp14> have the same
that this field only provides protection against downgrade value as the request nonce except the least significant bit
attacks, where a version of EAP requiring support for this TLV is <bcp14>MUST</bcp14> be set to one (1).</dd>
required on both sides.</t> <dt>EMSK Compound-MAC</dt>
<t>For TEAPv1, this version number MUST be set to one (1).</t> <dd><t>The EMSK Compound-MAC field is 20 octets. This can be the Server MAC
</li> (B1_MAC) or the Client MAC (B2_MAC). The computation of the MAC is
</ul> described in <xref target="computing-compound-mac"/>.</t>
<t>Flags</t> <t>Note that this field is always 20 octets in length. Any larger MAC is
<ul empty="true"> simply truncated. All validations or comparisons <bcp14>MUST</bcp14> be
<li> done on the truncated value.</t>
<t>The Flags field is four bits. Defined values include</t> </dd>
<ul empty="true"> <dt>MSK Compound-MAC</dt>
<li> <dd><t>The MSK Compound-MAC field is 20 octets. This can be the Server MAC
<t>1 EMSK Compound-MAC is present</t> (B1_MAC) or the Client MAC (B2_MAC). The computation of the MAC is
<t>2 MSK Compound-MAC is present</t> described in <xref target="computing-compound-mac"/>.</t>
<t>3 Both EMSK and MSK Compound-MAC are present</t> <t>Note that this field is always 20 octets in length. Any larger MAC is
<t>All other values of the Flags field are invalid.</t> simply truncated. All validations or comparisons <bcp14>MUST</bcp14> be
</li> done on the truncated value.</t></dd>
</ul> </dl>
</li>
</ul>
<t>Sub-Type</t>
<ul empty="true">
<li>
<t>The Sub-Type field is four bits. Defined values include</t>
<ul empty="true">
<li>
<t>0 Binding Request</t>
<t>1 Binding Response</t>
<t>All other values of the Sub-Type field are invalid.</t>
</li>
</ul>
</li>
</ul>
<t>Nonce</t>
<ul empty="true">
<li>
<t>The Nonce field is 32 octets. It contains a 256-bit nonce that
is
temporally unique, used for Compound-MAC key derivation at each
end. The nonce in a request MUST have its least significant bit
set to zero (0), and the nonce in a response MUST have the same
value as the request nonce except the least significant bit MUST
be set to one (1).</t>
</li>
</ul>
<t>EMSK Compound-MAC</t>
<ul empty="true">
<li>
<t>The EMSK Compound-MAC field is 20 octets. This can be the Serv
er
MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the
MAC is described in <xref target="computing-compound-mac"/>.</t>
<t>Note that this field is always 20 octets in length. Any larger
MAC is simply truncated. All validations or comparisons MUST be done
on the truncated value.</t>
</li>
</ul>
<t>MSK Compound-MAC</t>
<ul empty="true">
<li>
<t>The MSK Compound-MAC field is 20 octets. This can be the Serve
r
MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the
MAC is described in <xref target="computing-compound-mac"/>.</t>
<t>Note that this field is always 20 octets in length. Any larger
MAC is simply truncated. All validations or comparisons MUST be done
on the truncated value.</t>
</li>
</ul>
</section> </section>
<section anchor="bp-auth-req-tlv"> <section anchor="bp-auth-req-tlv">
<name>Basic-Password-Auth-Req TLV</name> <!-- [rfced] For Sections 4.2.14 through 4.2.20, may we update the TLV
definitions to start on a new line to match the convention throughout the
rest of the document? See below for an example.
Current:
M Mandatory, set to one (1)
Perhaps:
M
Mandatory, set to one (1)
-->
<name>Basic-Password-Auth-Req TLV</name>
<t>The Basic-Password-Auth-Req TLV is used by the authentication serve r <t>The Basic-Password-Auth-Req TLV is used by the authentication serve r
to request a username and password from the peer. It contains an to request a username and password from the peer. It contains an
optional user prompt message for the request. The peer is expected to optional user prompt message for the request. The peer is expected to
obtain the username and password and send them in a Basic-Password-Auth-Resp TLV .</t> obtain the username and password and send them in a Basic-Password-Auth-Resp TLV .</t>
<t>The Basic-Password-Auth-Req TLV is defined as follows:</t> <t>The Basic-Password-Auth-Req TLV is defined as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prompt .... | Prompt ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="false">
<ul empty="true"> <dt>M</dt>
<li> <dd>Mandatory, set to one (1)</dd>
<t>Mandatory, set to one (1)</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>13 - Basic-Password-Auth-Req TLV</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>variable</dd>
<t>Reserved, set to zero (0)</t> <dt>Prompt</dt>
</li> <dd>optional user prompt message in UTF-8 <xref target="RFC3629"/> format</dd>
</ul> </dl>
<t>TLV Type</t>
<ul empty="true">
<li>
<t>13 - Basic-Password-Auth-Req TLV</t>
</li>
</ul>
<t>Length</t>
<ul empty="true">
<li>
<t>variable</t>
</li>
</ul>
<t>Prompt</t>
<ul empty="true">
<li>
<t>optional user prompt message in UTF-8 <xref target="RFC3629"/>
format</t>
</li>
</ul>
</section> </section>
<section anchor="bp-auth-resp-tlv"> <section anchor="bp-auth-resp-tlv">
<name>Basic-Password-Auth-Resp TLV</name> <name>Basic-Password-Auth-Resp TLV</name>
<t>The Basic-Password-Auth-Resp TLV is used by the peer to respond to a <t>The Basic-Password-Auth-Resp TLV is used by the peer to respond to a
Basic-Password-Auth-Req TLV with a username and password. The TLV Basic-Password-Auth-Req TLV with a username and password. The TLV
contains a username and password. The username and password are in contains a username and password. The username and password are in
UTF-8 <xref target="RFC3629"/> format.</t> UTF-8 <xref target="RFC3629"/> format.</t>
<t>The Basic-Password-Auth-Resp TLV is defined as follows:</t> <t>The Basic-Password-Auth-Resp TLV is defined as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
skipping to change at line 2462 skipping to change at line 2276
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Userlen | Username | Userlen | Username
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Username ... ... Username ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Passlen | Password | Passlen | Password
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Password ... ... Password ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="false">
<ul empty="true"> <dt>M</dt>
<li> <dd>Mandatory, set to one (1)</dd>
<t>Mandatory, set to one (1)</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>14 - Basic-Password-Auth-Resp TLV</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>variable</dd>
<t>Reserved, set to zero (0)</t> <dt>Userlen</dt>
</li> <dd><t>Length of Username field in octets.</t>
</ul> <t>The value of Userlen <bcp14>MUST NOT</bcp14> be zero.</t></dd>
<t>TLV Type</t> <dt>Username</dt>
<ul empty="true"> <dd><t>Username in UTF-8 <xref target="RFC3629"/> format.</t>
<li> <t>The content of Username <bcp14>SHOULD</bcp14> follow the guidelines set
<t>14 - Basic-Password-Auth-Resp TLV</t> in <xref section="3.1" sectionFormat="comma" target="RFC9427"/>.</t></dd>
</li> <dt>Passlen</dt>
</ul> <dd>
<t>Length</t> <t>Length of Password field in octets.</t>
<ul empty="true"> <t>The value of Passlen <bcp14>MUST NOT</bcp14> be zero.</t>
<li> </dd>
<t>variable</t> <dt>Password</dt>
</li> <dd>
</ul> <t>Password in UTF-8 <xref target="RFC3629"/> format.</t>
<t>Userlen</t> <t>Note that there is no requirement that passwords be humanly readable.
<ul empty="true"> Octets in a passwords may have values less than 0x20, including 0x00.</t>
<li> </dd>
<t>Length of Username field in octets</t> </dl>
<t>The value of Userlen MUST NOT be zero.</t>
</li>
</ul>
<t>Username</t>
<ul empty="true">
<li>
<t>Username in UTF-8 <xref target="RFC3629"/> format</t>
<t>The content of Username SHOULD follow the guidelines set in
<xref section="3.1." sectionFormat="comma" target="RFC9427"/></t>
</li>
</ul>
<t>Passlen</t>
<ul empty="true">
<li>
<t>Length of Password field in octets</t>
<t>The value of Passlen MUST NOT be zero.</t>
</li>
</ul>
<t>Password</t>
<ul empty="true">
<li>
<t>Password in UTF-8 <xref target="RFC3629"/> format</t>
<t>Note that there is no requirement that passwords be humanly
readable. Octets in a passwords may have values less than 0x20,
including 0x00.</t>
</li>
</ul>
</section> </section>
<section anchor="pkcs7-tlv"> <section anchor="pkcs7-tlv">
<name>PKCS#7 TLV</name> <name>PKCS#7 TLV</name>
<t>The PKCS#7 TLV is used by the EAP server to deliver certificate(s) to <t>The PKCS#7 TLV is used by the EAP server to deliver certificate(s) to
the peer. The format consists of a certificate or certificate chain the peer. The format consists of a certificate or certificate chain
in binary DER encoding <xref target="X.690"/> in a degenerate Certificates Only in binary DER encoding <xref target="X.690"/> in a degenerate Certificates Only
PKCS#7 SignedData Content as defined in <xref target="RFC5652"/>.</t> PKCS#7 SignedData Content as defined in <xref target="RFC5652"/>.</t>
<t>When used in response to a Trusted-Server-Root TLV request from the <t>When used in response to a Trusted-Server-Root TLV request from the
peer, the EAP server MUST send the PKCS#7 TLV inside a peer, the EAP server <bcp14>MUST</bcp14> send the PKCS#7 TLV inside a
Trusted-Server-Root TLV. When used in response to a PKCS#10 certificate Trusted-Server-Root TLV. When used in response to a PKCS#10 certificate
enrollment request from the peer, the EAP server MUST send the PKCS#7 enrollment request from the peer, the EAP server <bcp14>MUST</bcp14> send the PK CS#7
TLV without a Trusted-Server-Root TLV. The PKCS#7 TLV is always TLV without a Trusted-Server-Root TLV. The PKCS#7 TLV is always
marked as optional, which cannot be responded to with a NAK TLV. marked as optional, which cannot be responded to with a NAK TLV.
TEAP implementations that support the Trusted-Server-Root TLV or the TEAP implementations that support the Trusted-Server-Root TLV or the
PKCS#10 TLV MUST support this TLV. Peers MUST NOT assume that the PKCS#10 TLV <bcp14>MUST</bcp14> support this TLV. Peers <bcp14>MUST NOT</bcp14> assume that the
certificates in a PKCS#7 TLV are in any order.</t> certificates in a PKCS#7 TLV are in any order.</t>
<t>TEAP servers MAY return self-signed certificates. Peers that handl <t>TEAP servers <bcp14>MAY</bcp14> return self-signed certificates. P
e eers that handle
self-signed certificates or trust anchors MUST NOT implicitly trust self-signed certificates or trust anchors <bcp14>MUST NOT</bcp14> implicitly tru
st
these certificates merely due to their presence in the certificate these certificates merely due to their presence in the certificate
bag. Note: Peers are advised to take great care in deciding whether bag. Note: Peers are advised to take great care in deciding whether
to use a received certificate as a trust anchor. The authenticated to use a received certificate as a trust anchor. The authenticated
nature of the tunnel in which a PKCS#7 bag is received can provide a nature of the tunnel in which a PKCS#7 bag is received can provide a
level of authenticity to the certificates contained therein. Peers level of authenticity to the certificates contained therein. Peers
are advised to take into account the implied authority of the EAP are advised to take into account the implied authority of the EAP
server and to constrain the trust it can achieve through the trust server and to constrain the trust it can achieve through the trust
anchor received in a PKCS#7 TLV.</t> anchor received in a PKCS#7 TLV.</t>
<t>The PKCS#7 TLV is defined as follows:</t> <t>The PKCS#7 TLV is defined as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS#7 Data... | PKCS#7 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="false">
<ul empty="true"> <dt>M</dt>
<li> <dd>0 - Optional TLV</dd>
<t>0 - Optional TLV</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>15 - PKCS#7 TLV</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>The length of the PKCS#7 Data field.</dd>
<t>Reserved, set to zero (0)</t> <dt>PKCS#7 Data</dt>
</li> <dd>This field contains the DER-encoded X.509 certificate or certificate
</ul> chain in a Certificates-Only PKCS#7 SignedData message.</dd>
<t>TLV Type</t> </dl>
<ul empty="true">
<li>
<t>15 - PKCS#7 TLV</t>
</li>
</ul>
<t>Length</t>
<ul empty="true">
<li>
<t>The length of the PKCS#7 Data field.</t>
</li>
</ul>
<t>PKCS#7 Data</t>
<ul empty="true">
<li>
<t>This field contains the DER-encoded X.509 certificate or
certificate chain in a Certificates-Only PKCS#7 SignedData
message.</t>
</li>
</ul>
</section> </section>
<section anchor="pkcs10-tlv"> <section anchor="pkcs10-tlv">
<name>PKCS#10 TLV</name> <name>PKCS#10 TLV</name>
<t>The PKCS#10 TLV is used by the peer to initiate the "simple PKI" <t>The PKCS#10 TLV is used by the peer to initiate the "Simple PKI"
Request/Response from <xref target="RFC5272"/>. The format of the request is as Request/Response from <xref target="RFC5272"/>. The format of the request is as
specified in Section 6.4 of <xref target="RFC4945"/>. The PKCS#10 TLV is always specified in <xref target="RFC4945" section="6.4"/>. The PKCS#10 TLV is always
marked as optional, which cannot be responded to with a NAK TLV.</t> marked as optional, which cannot be responded to with a NAK TLV.</t>
<t>The PKCS#10 TLV is defined as follows:</t> <t>The PKCS#10 TLV is defined as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS#10 Data... | PKCS#10 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="false">
<ul empty="true"> <dt>M</dt>
<li> <dd>0 - Optional TLV</dd>
<t>0 - Optional TLV</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>16 - PKCS#10 TLV</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>The length of the PKCS#10 Data field.</dd>
<t>Reserved, set to zero (0)</t> <dt>PKCS#10 Data</dt>
</li> <dd>This field contains the DER-encoded PKCS#10 certificate request.</dd>
</ul> </dl>
<t>TLV Type</t>
<ul empty="true">
<li>
<t>16 - PKCS#10 TLV</t>
</li>
</ul>
<t>Length</t>
<ul empty="true">
<li>
<t>The length of the PKCS#10 Data field.</t>
</li>
</ul>
<t>PKCS#10 Data</t>
<ul empty="true">
<li>
<t>This field contains the DER-encoded PKCS#10 certificate request
.</t>
</li>
</ul>
</section> </section>
<section anchor="trusted-server-root-tlv"> <section anchor="trusted-server-root-tlv">
<name>Trusted-Server-Root TLV</name> <name>Trusted-Server-Root TLV</name>
<t>Trusted-Server-Root TLV facilitates the request and delivery of a <t>Trusted-Server-Root TLV facilitates the request and delivery of a
trusted server root certificate. The Trusted-Server-Root TLV can be trusted server root certificate. The Trusted-Server-Root TLV can be
exchanged in regular TEAP authentication mode or provisioning mode. exchanged in regular TEAP authentication mode or provisioning mode.
The Trusted-Server-Root TLV is always marked as optional and cannot The Trusted-Server-Root TLV is always marked as optional and cannot
be responded to with a Negative Acknowledgment (NAK) TLV. The be responded to with a NAK TLV. The
Trusted-Server-Root TLV MUST only be sent as an Inner TLV (inside the Trusted-Server-Root TLV <bcp14>MUST</bcp14> only be sent as an Inner TLV (inside
the
protection of the tunnel).</t> protection of the tunnel).</t>
<t>After the peer has determined that it has successfully authenticate d <t>After the peer has determined that it has successfully authenticate d
the EAP server and validated the Crypto-Binding TLV, it MAY send one the EAP server and validated the Crypto-Binding TLV, it <bcp14>MAY</bcp14> send one
or more Trusted-Server-Root TLVs (marked as optional) to request the or more Trusted-Server-Root TLVs (marked as optional) to request the
trusted server root certificates from the EAP server. The EAP server trusted server root certificates from the EAP server. The EAP server
MAY send one or more root certificates with a Public Key <bcp14>MAY</bcp14> send one or more root certificates with a Public Key
Cryptographic System #7 (PKCS#7) TLV inside the Trusted-Server-Root Cryptographic System #7 (PKCS#7) TLV inside the Trusted-Server-Root
TLV. The EAP server MAY also choose not to honor the request.</t> TLV. The EAP server <bcp14>MAY</bcp14> also choose not to honor the request.</t >
<t>The Trusted-Server-Root TLV allows the peer to send a request to th e <t>The Trusted-Server-Root TLV allows the peer to send a request to th e
EAP server for a list of trusted roots. The server may respond with EAP server for a list of trusted roots. The server may respond with
one or more root certificates in PKCS#7 <xref target="RFC2315"/> format.</t> one or more root certificates in PKCS#7 <xref target="RFC2315"/> format.</t>
<t>If the EAP server sets the credential format to <t>If the EAP server sets the credential format to
PKCS#7-Server-Certificate-Root, then the Trusted-Server-Root TLV should contain the PKCS#7-Server-Certificate-Root, then the Trusted-Server-Root TLV should contain the
root of the certificate chain of the certificate issued to the EAP root of the certificate chain of the certificate issued to the EAP
server packaged in a PKCS#7 TLV. If the server certificate is a server packaged in a PKCS#7 TLV. If the server certificate is a
self-signed certificate, then the root is the self-signed self-signed certificate, then the root is the self-signed
certificate.</t> certificate.</t>
<t>If the Trusted-Server-Root TLV credential format contains a value <t>If the Trusted-Server-Root TLV credential format contains a value
unknown to the peer, then the EAP peer should ignore the TLV.</t> unknown to the peer, then the EAP peer should ignore the TLV.</t>
<t>The Trusted-Server-Root TLV is defined as follows:</t> <t>The Trusted-Server-Root TLV is defined as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credential-Format | Cred TLVs... | Credential-Format | Cred TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="false">
<ul empty="true"> <dt>M</dt>
<li> <dd>0 - Optional TLV</dd>
<t>0 - Optional TLV</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>17 - Trusted-Server-Root TLV</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>&gt;=2 octets</dd>
<t>Reserved, set to zero (0)</t> <dt>Credential-Format</dt>
</li> <dd>
</ul> <t>The Credential-Format field is two octets. Values include:</t>
<t>TLV Type</t> <t>1 - PKCS#7-Server-Certificate-Root</t>
<ul empty="true"> </dd>
<li> <dt>Cred TLVs</dt>
<t>17 - Trusted-Server-Root TLV</t> <dd>This field is of indefinite length. It contains TLVs associated with
</li> the credential format. The peer may leave this field empty when using this
</ul> TLV to request server trust roots.</dd>
<t>Length</t> </dl>
<ul empty="true">
<li>
<t>&gt;=2 octets</t>
</li>
</ul>
<t>Credential-Format</t>
<ul empty="true">
<li>
<t>The Credential-Format field is two octets. Values include:</t>
<ul empty="true">
<li>
<t>1 - PKCS#7-Server-Certificate-Root</t>
</li>
</ul>
</li>
</ul>
<t>Cred TLVs</t>
<ul empty="true">
<li>
<t>This field is of indefinite length. It contains TLVs associate
d
with the credential format. The peer may leave this field empty
when using this TLV to request server trust roots.</t>
</li>
</ul>
</section> </section>
<section anchor="csr-attributes-tlv"> <section anchor="csr-attributes-tlv">
<name>CSR-Attributes TLV</name> <name>CSR-Attributes TLV</name>
<t>The CSR-Attributes TLV provides information from the server to the <t>The CSR-Attributes TLV provides information from the server to the
peer on how certificate signing requests should be formed. The peer on how certificate signing requests should be formed. The
purpose of CSR attributes is described in Section 4.5 of <xref target="RFC7030"/ purpose of CSR attributes is described in <xref target="RFC7030" section="4.5"/>
>. .
Servers MAY send the CSR-Attributes TLV directly after the TLS session has Servers <bcp14>MAY</bcp14> send the CSR-Attributes TLV directly after the TLS se
been established. A server MAY also send in the same message a ssion has
been established. A server <bcp14>MAY</bcp14> also send in the same message a
Request-Action frame for a PKCS#10 TLV. This is an indication to the Request-Action frame for a PKCS#10 TLV. This is an indication to the
peer that the server would like the peer to renew its certificate peer that the server would like the peer to renew its certificate
using the parameters provided in this TLV. Servers shall construct using the parameters provided in this TLV. Servers shall construct
the contents of the CSR-Attributes TLV as specified in <xref section="4.5.2" sec tionFormat="comma" target="RFC7030"/> with the the contents of the CSR-Attributes TLV as specified in <xref section="4.5.2" sec tionFormat="comma" target="RFC7030"/> with the
exception that the DER encoding MUST NOT be encoded in base64. The base64 encod exception that the DER encoding <bcp14>MUST NOT</bcp14> be encoded in base64. T
ing is used in <xref target="RFC7030"/> because the transport protocol used ther he base64 encoding is used in <xref target="RFC7030"/> because the transport pro
e requires textual encoding. In contrast, TEAP attributes can transport arbitra tocol used there requires textual encoding. In contrast, TEAP attributes can tr
ry binary data.</t> ansport arbitrary binary data.</t>
<t>Servers and peers MUST follow the guidance provided in <t>Servers and peers <bcp14>MUST</bcp14> follow the guidance provided
<xref target="I-D.ietf-lamps-rfc7030-csrattrs"/> when creating the CSR-Attribute in
s TLV. Peers MAY ignore the contents <xref target="RFC9908"/> when creating the CSR-Attributes TLV. Peers <bcp14>MAY<
/bcp14> ignore the contents
of the TLV if they are unable to do so, but then servers may not of the TLV if they are unable to do so, but then servers may not
process PKCS#10 certificate requests for this or any other reason.</t> process PKCS#10 certificate requests for this or any other reason.</t>
<t>The CSR-Attributes TLV is defined as follows:</t> <t>The CSR-Attributes TLV is defined as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DER Encoded CSR Attributes | | DER Encoded CSR Attributes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="false">
<ul empty="true"> <dt>M</dt>
<li> <dd>0 - Optional TLV</dd>
<t>0 - Optional TLV</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>18 - CSR-Attributes</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>&gt;=2 octets</dd>
<t>Reserved, set to zero (0)</t> </dl>
</li>
</ul>
<t>TLV Type</t>
<ul empty="true">
<li>
<t>18 - CSR-Attributes</t>
</li>
</ul>
<t>Length</t>
<ul empty="true">
<li>
<t>&gt;=2 octets</t>
</li>
</ul>
</section> </section>
<section anchor="identity-hint-tlv"> <section anchor="identity-hint-tlv">
<name>Identity-Hint TLV</name> <name>Identity-Hint TLV</name>
<t>The Identity-Hint TLV is an optional TLV which can be sent by the p <t>The Identity-Hint TLV is an optional TLV that can be sent by the pe
eer to the server at the beginning of the Phase 2 TEAP conversation. The purpos er to the server at the beginning of the Phase 2 TEAP conversation. The purpose
e of the TLV is to provide a "hint" as to the identity or identities which the p of the TLV is to provide a "hint" as to the identity or identities that the pee
eer will be using by subsequent inner methods.</t> r will be using by subsequent inner methods.</t>
<t>The purpose of this TLV is to solve the "bootstrapping" problem for <t>The purpose of this TLV is to solve the "bootstrapping" problem for
the server. In order to perform authentication, the server must choose an inne the server. In order to perform authentication, the server must choose an inne
r method. However, the server has no knowledge of what methods are supported by r method. However, the server has no knowledge of what methods are supported by
the peer. Without an identity hint, the server needs to propose a method, and the peer. Without an identity hint, the server needs to propose a method and t
then have the peer return a response indicating that the requested method is not hen have the peer return a response indicating that the requested method is not
available. This negotiation increases the number of round trips required for T available. This negotiation increases the number of round trips required for TE
EAP to conclude, with no additional benefit.</t> AP to conclude with no additional benefit.</t>
<t>When the Identity-Hint is used, the peer can signal which identitie <t>When the Identity-Hint is used, the peer can signal which identitie
s it has available, which enables the server to choose an inner method which is s it has available, which enables the server to choose an inner method that is a
appropriate for that identity.</t> ppropriate for that identity.</t>
<t>The peer SHOULD send an Identity-Hint TLV for each Identity-Type wh <t>The peer <bcp14>SHOULD</bcp14> send an Identity-Hint TLV for each I
ich is available to it. For example, if the peer can do both Machine and User a dentity-Type that is available to it. For example, if the peer can do both mach
uthentication, it can send two Identity-Hint TLVs, with values "host/name.exampl ine and user authentication, it can send two Identity-Hint TLVs with values "hos
e.com" (for a machine with hostname "name.example.com"), and "user@example.com" t/name.example.com" (for a machine with hostname "name.example.com") and "user@e
(for a person with identity "user@example.com").</t> xample.com" (for a person with identity "user@example.com").</t>
<t>The contents of the Identity-Hint TLV SHOULD be in the format of an <t>The contents of the Identity-Hint TLV <bcp14>SHOULD</bcp14> be in t
NAI <xref target="RFC7542"/>, but we note that as given in the example above, M he format of an NAI <xref target="RFC7542"/>, but we note that as given in the e
achine identities might not follow that format. As these identities are never u xample above, Machine identities might not follow that format. As these identit
sed for AAA routing as discussed in <xref section="3" sectionFormat="comma" targ ies are never used for AAA routing as discussed in <xref section="3" sectionForm
et="RFC7542"/>, the format and definition of these identities are entirely site at="comma" target="RFC7542"/>, the format and definition of these identities are
local. Robust implementations MUST support arbitrary data in the content of thi entirely site local. Robust implementations <bcp14>MUST</bcp14> support arbitr
s TLV, including binary octets.</t> ary data in the content of this TLV, including binary octets.</t>
<t>As the Identity-Hint TLV is a "hint", server implementations are fr <t>As the Identity-Hint TLV is a "hint", server implementations are fr
ee to ignore the hints given, and do whatever is required by site-local policies ee to ignore the hints given and do whatever is required by site-local policies.
.</t> </t>
<t>The Identity-Hint TLV is used only as a guide when selecting which <t>The Identity-Hint TLV is used only as a guide when selecting which
inner methods to use. This TLV has no other meaning, and it MUST NOT be used fo inner methods to use. This TLV has no other meaning, and it <bcp14>MUST NOT</bc
r any other purpose. Specifically. server implementations MUST NOT compare the p14> be used for any other purpose. Specifically, server implementations <bcp14
identities given this TLV to later identities given as part of the inner methods >MUST NOT</bcp14> compare the identities given this TLV to later identities give
. There is no issue with the hint(s) failing to match any subsequent identity w n as part of the inner methods. There is no issue with the hint(s) failing to m
hich is used.</t> atch any subsequent identity that is used.</t>
<t>The Identity-Hint TLV MUST NOT be used for Server Unauthenticated P <t>The Identity-Hint TLV <bcp14>MUST NOT</bcp14> be used for server un
rovisioning. This TLV is only used as a hint for normal authentication.</t> authenticated provisioning. This TLV is only used as a hint for normal authenti
cation.</t>
<t>The Identity-Hint TLV is defined as follows:</t> <t>The Identity-Hint TLV is defined as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length | |M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identity Hint | | Identity Hint |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-]]></artwork>
]]></artwork>
<t>M</t> <dl spacing="normal" newline="false">
<ul empty="true"> <dt>M</dt>
<li> <dd>0 - Optional TLV</dd>
<t>0 - Optional TLV</t> <dt>R</dt>
</li> <dd>Reserved, set to zero (0)</dd>
</ul> <dt>TLV Type</dt>
<t>R</t> <dd>19 - Identity-Hint</dd>
<ul empty="true"> <dt>Length</dt>
<li> <dd>&gt;=2 octets</dd>
<t>Reserved, set to zero (0)</t> </dl>
</li>
</ul>
<t>TLV Type</t>
<ul empty="true">
<li>
<t>19 - Identity-Hint</t>
</li>
</ul>
<t>Length</t>
<ul empty="true">
<li>
<t>&gt;=2 octets</t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="tlv-rules"> <section anchor="tlv-rules">
<name>TLV Rules</name> <name>TLV Rules</name>
<t>To save round trips, multiple TLVs can be sent in a single TEAP <t>To save round trips, multiple TLVs can be sent in a single TEAP
packet. However, multiple EAP Payload TLVs, multiple Basic Password packet. However, multiple EAP Payload TLVs, multiple Basic Password
Authentication TLVs, or an EAP Payload TLV with a Basic Password Authentication TLVs, or an EAP Payload TLV with a Basic Password
Authentication TLV within one single TEAP packet is not supported in Authentication TLV within one single TEAP packet is not supported in
this version and MUST NOT be sent. If the peer or EAP server this version and <bcp14>MUST NOT</bcp14> be sent. If the peer or EAP server
receives multiple EAP Payload TLVs, then it MUST terminate the receives multiple EAP Payload TLVs, then it <bcp14>MUST</bcp14> terminate the
connection with the Result TLV. The order in which TLVs are encoded in a TEAP p acket does not connection with the Result TLV. The order in which TLVs are encoded in a TEAP p acket does not
matter, however there is an order in which TLVs in a packet must be processed:</ matter. However, there is an order in which TLVs in a packet must be processed:<
t> /t>
<!-- [rfced] We believe that parentheses were intended in the following list
item (we also note that this is the only occurrence of "Identity-Request").
If this is not the case, please let us know.
Original:
5. EAP-Payload TLV[Identity-Request] or Basic-Password-Auth-Req TLV
Current:
5. EAP-Payload TLV (Identity-Request) or Basic-Password-Auth-Req TLV
-->
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>Crypto-Binding TLV</t> <t>Crypto-Binding TLV</t>
</li> </li>
<li> <li>
<t>Intermediate-Result TLV</t> <t>Intermediate-Result TLV</t>
</li> </li>
<li> <li>
<t>Result TLV or Request-Action TLV</t> <t>Result TLV or Request-Action TLV</t>
</li> </li>
<li> <li>
<t>Identity-Type TLV</t> <t>Identity-Type TLV</t>
</li> </li>
<li> <li>
<t>EAP-Payload TLV[Identity-Request] or Basic-Password-Auth-Req TLV< /t> <t>EAP-Payload TLV (Identity-Request) or Basic-Password-Auth-Req TLV </t>
</li> </li>
<li> <li>
<t>Other TLVs</t> <t>Other TLVs</t>
</li> </li>
</ol> </ol>
<t>That is, cryptographic binding is checked before any result is used, <t>That is, cryptographic binding is checked before any result is used
and identities are checked before proposing an inner method, as the and identities are checked before proposing an inner method, as the
identity may influence the chosen inner method.</t> identity may influence the chosen inner method.</t>
<t>The following define the meaning of the table entries in the sections <t>The following define the meaning of the table entries in the sections
below:</t> below:</t>
<artwork><![CDATA[ <dl spacing="normal" newline="false">
0 This TLV MUST NOT be present in the message. <dt>0</dt><dd> This TLV <bcp14>MUST NOT</bcp14> be present in the
message.</dd>
0+ Zero or more instances of this TLV MAY be present in the <dt>0+</dt><dd> Zero or more instances of this TLV <bcp14>MAY</bcp14> be
message. present in the message.</dd>
0-1 Zero or one instance of this TLV MAY be present in the message. <dt>0-1</dt><dd>Zero or one instance of this TLV <bcp14>MAY</bcp14> be present in the message.</dd>
1 Exactly one instance of this TLV MUST be present in the <dt>1</dt><dd>Exactly one instance of this TLV <bcp14>MUST</bcp14> be
message. present in the message.</dd>
]]></artwork> </dl>
<section anchor="outer-tlvs"> <section anchor="outer-tlvs">
<name>Outer TLVs</name> <name>Outer TLVs</name>
<!-- [rfced] In RFC 7170, we note that the following instances of text nearly
match each other with a few exceptions, including "in" before "which kind
of packets". Should "in" be removed from the second instance in Section
4.3.2, should "in" be added before "which" in Section 4.3.1, or should
the text be left as is?
Original (4.3.1):
The following table provides a guide to which TLVs may be included in
the TEAP packet outside the TLS channel, which kind of packets, and
in what quantity:
Original (4.3.2):
The following table provides a guide to which Inner TLVs may be
encapsulated in TLS in TEAP Phase 2, in which kind of packets, and in
what quantity.
-->
<t>The following table provides a guide to which TLVs may be included in <t>The following table provides a guide to which TLVs may be included in
the TEAP packet outside the TLS channel, which kind of packets, and the TEAP packet outside the TLS channel, which kind of packets, and
in what quantity:</t> in what quantity:</t>
<artwork><![CDATA[ <table>
Request Response Success Failure TLVs <thead>
0-1 0 0 0 Authority-ID <tr>
0-1 0-1 0 0 Identity-Type <th>Request</th><th>Response</th><th>Success</th><th>Failure</th><th>TLVs<
0+ 0+ 0 0 Vendor-Specific /th>
]]></artwork> </tr>
<t>Outer TLVs MUST be marked as optional. Vendor TLVs inside of a </thead>
Vendor-Specific TLV MUST be marked as optional when included in Outer TLVs. <tbody>
Outer TLVs MUST NOT be included in messages after the first two TEAP <tr>
messages sent by peer and EAP-server respectively. That is the first <td>0-1</td><td>0</td><td>0</td><td>0</td><td>Authority-ID</td>
</tr>
<tr>
<td>0-1</td><td>0-1</td><td>0</td><td>0</td><td>Identity-Type</td>
</tr>
<tr>
<td>0+</td><td>0+</td><td>0</td><td>0</td><td>Vendor-Specific</td>
</tr>
</tbody>
</table>
<t>Outer TLVs <bcp14>MUST</bcp14> be marked as optional. Vendor TLVs
inside of a
Vendor-Specific TLV <bcp14>MUST</bcp14> be marked as optional when included in O
uter TLVs.
Outer TLVs <bcp14>MUST NOT</bcp14> be included in messages after the first two T
EAP
messages sent by peer and EAP-server, respectively. That is, the first
EAP-server-to-peer message and first peer-to-EAP-server message. If EAP-server-to-peer message and first peer-to-EAP-server message. If
the message is fragmented, the whole set of messages is counted as the message is fragmented, the whole set of messages is counted as
one message. If Outer TLVs are included in messages after the first one message. If Outer TLVs are included in messages after the first
two TEAP messages, they MUST be ignored.</t> two TEAP messages, they <bcp14>MUST</bcp14> be ignored.</t>
</section> </section>
<section anchor="inner-tlvs"> <section anchor="inner-tlvs">
<name>Inner TLVs</name> <name>Inner TLVs</name>
<t>The following table provides a guide to which Inner TLVs may be <t>The following table provides a guide to which Inner TLVs may be
encapsulated in TLS in TEAP Phase 2, in which kind of packets, and in encapsulated in TLS in TEAP Phase 2, in which kind of packets, and in
what quantity. The messages are as follows: Request is a TEAP what quantity. The messages are as follows: Request is a TEAP
Request, Response is a TEAP Response, Success is a message containing Request, Response is a TEAP Response, Success is a message containing
a successful Result TLV, and Failure is a message containing a failed a successful Result TLV, and Failure is a message containing a failed
Result TLV.</t> Result TLV.</t>
<artwork><![CDATA[
Request Response Success Failure TLVs <table>
0-1 0-1 0 0 Identity-Type <thead>
0-1 0-1 1 1 Result <tr><th>Request</th><th>Response</th><th>Success</th><th>Failure</th><th>TLV
0+ 0+ 0 0 NAK s</th></tr>
0+ 0+ 0+ 0+ Error </thead>
0-1 0-1 0 0 Channel-Binding <tbody>
0+ 0+ 0+ 0+ Vendor-Specific <tr><td>0-1</td> <td>0-1</td> <td>0</td> <td>0</td>
0+ 0+ 0+ 0+ Request-Action <td>Identity-Type</td></tr>
0-1 0-1 0 0 EAP-Payload <tr><td>0-1</td> <td>0-1</td> <td>1</td> <td>1</td>
0-1 0-1 0-1 0-1 Intermediate-Result <td>Result</td></tr>
0-1 0-1 0-1 0-1 Crypto-Binding <tr><td>0+</td> <td>0+</td> <td>0</td> <td>0</td>
0-1 0 0 0 Basic-Password-Auth-Req <td>NAK</td></tr>
0 0-1 0 0 Basic-Password-Auth-Resp <tr><td>0+</td> <td>0+</td> <td>0+</td> <td>0+</td>
0-1 0 0-1 0 PKCS#7 <td>Error</td></tr>
0 0-1 0 0 PKCS#10 <tr><td>0-1</td> <td>0-1</td> <td>0</td> <td>0</td>
0-1 0-1 0-1 0 Trusted-Server-Root <td>Channel-Binding</td></tr>
0-1 0 0 0 CSR-Attributes TLV <tr><td>0+</td> <td>0+</td> <td>0+</td> <td>0+</td>
0 0+ 0 0 Identity-Hint TLV <td>Vendor-Specific</td></tr>
]]></artwork> <tr><td>0+</td> <td>0+</td> <td>0+</td> <td>0+</td>
<td>Request-Action</td></tr>
<tr><td>0-1</td> <td>0-1</td> <td>0</td> <td>0</td>
<td>EAP-Payload</td></tr>
<tr><td>0-1</td> <td>0-1</td> <td>0-1</td> <td>0-1</td>
<td>Intermediate-Result</td></tr>
<tr><td>0-1</td> <td>0-1</td> <td>0-1</td> <td>0-1</td>
<td>Crypto-Binding</td></tr>
<tr><td>0-1</td> <td>0</td> <td>0</td> <td>0</td>
<td>Basic-Password-Auth-Req</td></tr>
<tr><td>0</td> <td>0-1</td> <td>0</td> <td>0</td>
<td>Basic-Password-Auth-Resp</td></tr>
<tr><td>0-1</td> <td>0</td> <td>0-1</td> <td>0</td>
<td>PKCS#7</td></tr>
<tr><td>0</td> <td>0-1</td> <td>0</td> <td>0</td>
<td>PKCS#10</td></tr>
<tr><td>0-1</td> <td>0-1</td> <td>0-1</td> <td>0</td>
<td>Trusted-Server-Root</td></tr>
<tr><td>0-1</td> <td>0</td> <td>0</td> <td>0</td>
<td>CSR-Attributes TLV</td></tr>
<tr><td>0</td><td>0+</td><td>0</td><td>0</td><td>Identity-Hint TLV</td></tr>
</tbody>
</table>
<t>NOTE: Vendor TLVs (included in Vendor-Specific TLVs) sent with a <t>NOTE: Vendor TLVs (included in Vendor-Specific TLVs) sent with a
Result TLV MUST be marked as optional. Also, the CSR-Attributes TLV Result TLV <bcp14>MUST</bcp14> be marked as optional. Also, the CSR-Attributes TLV
is never transmitted by the peer, and so is treated as a request is never transmitted by the peer, and so is treated as a request
in this table.</t> in this table.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="limitations"> <section anchor="limitations">
<name>Limitations of TEAPv1</name> <name>Limitations of TEAPv1</name>
<t>As noted in <xref target="interoperability"/>, TEAPv1 implementations a re limited <t>As noted in <xref target="interoperability"/>, TEAPv1 implementations a re limited
in functionality as compared to what the protocol is theoretically in functionality as compared to what the protocol is theoretically
capable of. These limitations mean that only a small number of inner capable of. These limitations mean that only a small number of inner
methods are fully supported by existing TEAPv1 implementations.</t> methods are fully supported by existing TEAPv1 implementations.</t>
<t>While <xref target="cryptographic-calculations"/>, below, defines the <t>While <xref target="cryptographic-calculations"/> defines the
cryptographic calculations used for key derivation and crypto-binding, cryptographic calculations used for key derivation and crypto-binding,
this section documents which inner methods are known to work, and why this section documents which inner methods are known to work and why
those methods work. Other inner methods may work, but those results those methods work. Other inner methods may work, but those results
are likely to be implementation-specific.</t> are likely to be implementation-specific.</t>
<t>We discuss the issues here without naming particular implementations <t>We discuss the issues here without naming particular implementations
or making any negative inference about them. The implementations work or making any negative inference about them. The implementations work
well enough together in limited situations. Any interoperability well enough together in limited situations. Any interoperability
issues are due to the complexity and incompleteness of the definitions issues are due to the complexity and incompleteness of the definitions
given in <xref target="RFC7170"/>, and are not due to issues with any particular given in <xref target="RFC7170"/> and are not due to issues with any particular
implementation.</t> implementation.</t>
<t>The interoperability issues are limited to the use and derivation of <t>The interoperability issues are limited to the use and derivation of
the Compound-MAC(s), which are derived from the inner MSK and EMSK. the Compound-MAC(s), which are derived from the inner MSK and EMSK.
In short, implementations are known to derive different values for the In short, implementations are known to derive different values for the
Compound-MAC(s) when more than one inner methods provides an EMSK.</t> Compound-MAC(s) when more than one inner method provides an EMSK.</t>
<section anchor="interoperable-inner-methods"> <section anchor="interoperable-inner-methods">
<name>Interoperable Inner Methods</name> <name>Interoperable Inner Methods</name>
<t>The following inner methods are known to work. These methods work fo r <t>The following inner methods are known to work. These methods work fo r
both User and Machine credentials.</t> both User and Machine credentials.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>EAP-MSCHAPv2</t> <t>EAP-MSCHAPv2</t>
</li> </li>
<li> <li>
<t>EAP-TLS</t> <t>EAP-TLS</t>
skipping to change at line 2957 skipping to change at line 2699
methods work for any order of User and Machine credentials.</t> methods work for any order of User and Machine credentials.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>EAP-MSCHAPv2 followed by EAP-MSCHAPv2</t> <t>EAP-MSCHAPv2 followed by EAP-MSCHAPv2</t>
</li> </li>
<li> <li>
<t>EAP-TLS followed by EAP-MSCHAPv2</t> <t>EAP-TLS followed by EAP-MSCHAPv2</t>
</li> </li>
</ul> </ul>
<t>The following combinations of inner methods are known to work when <t>The following combinations of inner methods are known to work when
both supplicant and authenticator ignore the EMSK Compound-MAC field both the supplicant and authenticator ignore the EMSK Compound-MAC field
of the Crypto-Binding TLV. These methods work for any order of User of the Crypto-Binding TLV. These methods work for any order of User
and Machine credentials .</t> and Machine credentials.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>EAP-MSCHAPv2 followed by EAP-TLS</t> <t>EAP-MSCHAPv2 followed by EAP-TLS</t>
</li> </li>
<li> <li>
<t>EAP-TLS followed by EAP-TLS</t> <t>EAP-TLS followed by EAP-TLS</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="explanation-and-background"> <section anchor="explanation-and-background">
<name>Explanation and Background</name> <name>Explanation and Background</name>
<t>The main reason for the limited set of inner methods is that the most <t>The main reason for the limited set of inner methods is that the most
well-known TEAP supplicant supports only EAP-MSCHAPv2 and EAP-TLS for well-known TEAP supplicant supports only EAP-MSCHAPv2 and EAP-TLS for
the inner methods. Further, this implementation does not encode the the inner methods. Further, this implementation does not encode the
EMSK Compound-MAC field in all of the Crypto-Binding TLVs that it EMSK Compound-MAC field in all of the Crypto-Binding TLVs that it
sends, and ignores that field in all of the Crypto-Binding TLVs that sends and ignores that field in all of the Crypto-Binding TLVs that
it receives.</t> it receives.</t>
<t>The known authenticator implementations support this client, but any <!-- [rfced] May we rephrase the following text for improved readability?
Original:
The known authenticator implementations support this client, but any
other combination of inner methods was not tested. The result is that due to
both the complexity of the cryptographic derivations and the lack of
interoperability testing, each authenticator implemented entirely different
deriviations of the EMSK Compound-MAC field of the Crypto-Binding TLV.
Perhaps:
The known authenticator implementations support this client, but any
other combination of inner methods was not tested. As a result, each
authenticator implemented entirely different derivations of the EMSK
Compound-MAC field of the Crypto-Binding TLV due to both the complexity of the
cryptographic derivations and the lack of interoperability testing.
-->
<t>The known authenticator implementations support this client, but any
other combination of inner methods was not tested. The result is that other combination of inner methods was not tested. The result is that
due to both the complexity of the cryptographic derivations and the due to both the complexity of the cryptographic derivations and the
lack of interoperability testing, each authenticator implemented lack of interoperability testing, each authenticator implemented
entirely different deriviations of the EMSK Compound-MAC field of the entirely different derivations of the EMSK Compound-MAC field of the
Crypto-Binding TLV. This difference was discovered only after Crypto-Binding TLV. This difference was discovered only after
multiple implementations had been shipping for years.</t> multiple implementations had been shipping for years.</t>
</section> </section>
<section anchor="next-steps"> <section anchor="next-steps">
<name>Next Steps</name> <name>Next Steps</name>
<t>Any attempt to change TEAPv1 to address these issues would likely <t>Any attempt to change TEAPv1 to address these issues would likely
result in one or more implementations being non-compliant with the result in one or more implementations being non-compliant with the
updated specification. Even worse, updates to this specification updated specification. Even worse, updates to this specification
would result in multiple incompatible versions of TEAPv1.</t> would result in multiple incompatible versions of TEAPv1.</t>
<t>That approach is not acceptable.</t> <t>That approach is not acceptable.</t>
<t>In the interest of maintaining known interoperability, this <t>In the interest of maintaining known interoperability, this
specification simply documents these issues rather than trying to specification simply documents these issues rather than trying to
correct the problem. Since the TEAP protocol and the Crypto-Binding correct the problem. Since the TEAP protocol and the Crypto-Binding
TLV both contain a version field, the better path forward is to TLV both contain a Version field, the better path forward is to
publish this specification while documenting the large caveats for publish this specification while documenting the large caveats for
TEAPv1. Any changes to the TEAP protocol can then be done in a future TEAPv1. Any changes to the TEAP protocol can then be done in a future
TEAPv2 specification.</t> TEAPv2 specification.</t>
</section> </section>
</section> </section>
<section anchor="cryptographic-calculations"> <section anchor="cryptographic-calculations">
<name>Cryptographic Calculations</name> <name>Cryptographic Calculations</name>
<t>The definitions given in this section are known to work with all <t>The definitions given in this section are known to work with all
implementations, but ony for a few inner methods, as described above implementations but only for a few inner methods, as described above
in <xref target="limitations"/>. In the interest of avoiding additional in <xref target="limitations"/>. In the interest of avoiding additional
complexity in an already complex process, those definitions are given complexity in an already complex process, those definitions are given
as if they work for all possible inner methods.</t> as if they work for all possible inner methods.</t>
<t>We note that some interoperable implementations have been written <t>We note that some interoperable implementations have been written
based on these definitions, which support inner methods other than based on these definitions, which support inner methods other than
EAP-MSCHAPv2 and EAP-TLS. It is therefore useful to document the full EAP-MSCHAPv2 and EAP-TLS. It is therefore useful to document the full
operation of TEAPv1, despite the known issues. We only caution operation of TEAPv1 despite the known issues. We only caution
implemnters that inner methods which are not listed in above in implementors that inner methods that are not listed above in
<xref target="limitations"/> are likly to work with only a subset of existing <xref target="limitations"/> are likely to work with only a subset of existing
TEAPv1 implementations.</t> TEAPv1 implementations.</t>
<t>For key derivation and crypto-binding, TEAP uses the Pseudorandom <t>For key derivation and crypto-binding, TEAP uses the Pseudorandom
Function (PRF) and MAC algorithms negotiated in the underlying TLS Function (PRF) and MAC algorithms negotiated in the underlying TLS
session. Since these algorithms depend on the TLS version and session. Since these algorithms depend on the TLS version and
cipher suite, TEAP implementations need a mechanism to determine the cipher suite, TEAP implementations need a mechanism to determine the
version and cipher suite in use for a particular session. The version and cipher suite in use for a particular session. The
implementation can then use this information to determine which PRF implementation can then use this information to determine which PRF
and MAC algorithm to use.</t> and MAC algorithm to use.</t>
<section anchor="key-derivations"> <section anchor="key-derivations">
<name>TEAP Authentication Phase 1: Key Derivations</name> <name>TEAP Authentication Phase 1: Key Derivations</name>
<t>With TEAPv1, the TLS master secret is generated as specified in TLS. <t>With TEAPv1, the TLS master secret is generated as specified in TLS.
If session resumption is used, then the master secret is obtained as described i n If session resumption is used, then the master secret is obtained as described i n
<xref target="RFC5077"/>.</t> <xref target="RFC5077"/>.</t>
<t>TEAPv1 makes use of the TLS Keying Material Exporters defined in <t>TEAPv1 makes use of the TLS Keying Material Exporters defined in
<xref target="RFC5705"/> to derive the session_key_seed as follows:</t> <xref target="RFC5705"/> to derive the session_key_seed as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
session_key_seed = TLS-Exporter( session_key_seed = TLS-Exporter(
"EXPORTER: teap session key seed",, 40) "EXPORTER: teap session key seed",, 40)]]></artwork>
]]></artwork>
<t>No context data is used in the export process.</t> <t>No context data is used in the export process.</t>
<t>The session_key_seed is used by the TEAP authentication Phase 2 <t>The session_key_seed is used by the TEAP authentication Phase 2
conversation to both cryptographically bind the inner method(s) to conversation to both cryptographically bind the inner method(s) to
the tunnel as well as generate the resulting TEAP session keys. The the tunnel as well as generate the resulting TEAP session keys. The
other TLS keying materials are derived and used as defined in other TLS keying materials are derived and used as defined in
<xref target="RFC5246"/>.</t> <xref target="RFC5246"/>.</t>
</section> </section>
<section anchor="intermediate-compound-key"> <section anchor="intermediate-compound-key">
<name>Intermediate Compound Key Derivations</name> <name>Intermediate Compound Key Derivations</name>
<t>As TEAP can run multiple inner methods, there needs to be a way to <t>As TEAP can run multiple inner methods, there needs to be a way to
cryptographically bind each inner method to the TLS tunnel, and to cryptographically bind each inner method to the TLS tunnel and to
cryptographically bind each method to the previous one. This binding cryptographically bind each method to the previous one. This binding
is done by deriving a number of intermediate keys, and exchanging that is done by deriving a number of intermediate keys and exchanging that
information in the Crypto-Binding TLV.</t> information in the Crypto-Binding TLV.</t>
<t>The key derivation is complicated by a number of factors. An inner <t>The key derivation is complicated by a number of factors. An inner
method can derive MSK, or (as with basic passwords) not derive an MSK. method can derive an MSK or (as with basic passwords) not derive an MSK.
An inner method can derive an EMSK, or perhaps not derive an EMSK, or An inner method can derive an EMSK or perhaps not derive an EMSK, or
some EAP types may derive different EMSKs for the peer and the server. some EAP types may derive different EMSKs for the peer and the server.
All of these cases must be accounted for, and recommendations made for All of these cases must be accounted for and have recommendations made for
how peers and servers can interoperate.</t> how peers and servers can interoperate.</t>
<t>There are a number of intermediate keys used to calculate the final <t>There are a number of intermediate keys used to calculate the final
MSK and EMSK for TEAP. We give a brief overview here in order to MSK and EMSK for TEAP. We give a brief overview here in order to
clarify the detailed definitions and deriviations given below. As clarify the detailed definitions and derivations given below. As
each inner method can derive MSK (or not), and can derive EMSK (or each inner method can derive an MSK (or not) and an EMSK (or
not), there need to be separate intermediate key calculations for MSK not), there need to be separate intermediate key calculations for MSK
and for EMSK. For the purposes of this overview, we just describe the and for EMSK. For the purposes of this overview, we just describe the
derivations at a high level, and state that the MSK/EMSK issue is derivations at a high level and state that the MSK/EMSK issue is
addressed in the more detailed text below.</t> addressed in the more detailed text below.</t>
<t>For each inner method, we derive an Inner Method Session Key (IMSK). <t>For each inner method, we derive an IMSK.
This key depends on the inner key (MSK or EMSK). This IMSK is then This key depends on the inner key (MSK or EMSK). This IMSK is then
tied to the TLS session via the TLS-PRF to derive an Inner Method tied to the TLS session via the TLS-PRF to derive an Inner Method
Compound Key (IMCK). The IMCK is used to generate a Compound-MAC key Compound Key (IMCK). The IMCK is used to generate a Compound-MAC key
(CMK). The CMK is mixed with with various data from the TEAP (CMK). The CMK is mixed with various data from the TEAP
negotiation to create Compound-MAC field of the Crypto-Binding negotiation to create Compound-MAC field of the Crypto-Binding
attribute. This TLV cryptographically binds the inner method to the attribute. This TLV cryptographically binds the inner method to the
protected tunnel, and to the other fields which have been negotiated. protected tunnel and to the other fields that have been negotiated.
The cryptographic binding prevents on-path attacks.</t> The cryptographic binding prevents on-path attacks.</t>
<t>The IMCK for this inner method is then mixed with keys from previous <t>The IMCK for this inner method is then mixed with keys from previous
inner methods, beginning with the TEAP Phase 2 session_key_seed inner methods, beginning with the TEAP Phase 2 session_key_seed
derived above, to yield a Secure ICMK (S-IMCK) for this round. The derived above, to yield a Secure IMCK (S-IMCK) for this round. The
S-IMCK from the final is then used to derive the MSK and EMSK for S-IMCK from the final is then used to derive the MSK and EMSK for
TEAP.</t> TEAP.</t>
<t>We differentiate keys for inner methods by counting inner methods <t>We differentiate keys for inner methods by counting inner methods
starting from 0, and use an index "j" to refer to an arbitrary inner starting from 0 and use an index "j" to refer to an arbitrary inner
method. e.g. IMCK[0] is the IMCK for the first, or "0" inner method. method. For example, IMCK[0] is the IMCK for the first, or "0" inner method.
While TEAPv1 is currently limited to one or two inner methods (j=0 or While TEAPv1 is currently limited to one or two inner methods (j=0 or
j=0,1), further updates could allow for more inner method exchanges.</t> j=0,1), further updates could allow for more inner method exchanges.</t>
<section anchor="generating-the-inner-method-session-key"> <section anchor="generating-the-inner-method-session-key">
<name>Generating the Inner Method Session Key</name> <name>Generating the Inner Method Session Key</name>
<t>Each inner method generates an Inner Method Session Key (IMSK) whic <t>Each inner method generates an IMSK that depends on the EMSK (prefe
h rred) or the MSK if it exists, or else it is
depends on the EMSK (preferred) or the MSK if it exists, or else it is
all zeros. We refer to the IMSK for inner method "j" as IMSK[j].</t> all zeros. We refer to the IMSK for inner method "j" as IMSK[j].</t>
<t>If an inner method supports export of an Extended Master Session Ke <t>If an inner method supports export of an EMSK, then the IMSK <bcp14
y >SHOULD</bcp14> be derived from the EMSK, which is defined in
(EMSK), then the IMSK SHOULD be derived from the EMSK which is defined in
<xref target="RFC5295"/>. The optional data parameter is not used in the deriva tion.</t> <xref target="RFC5295"/>. The optional data parameter is not used in the deriva tion.</t>
<t>The above derivation is not a requirement, as some peer <t>The above derivation is not a requirement, as some peer
implementations of TEAP are also known to not derive IMSK from EMSK, implementations of TEAP are also known to not derive IMSK from EMSK
and to only derive IMSK from MSK. In order to be compatible with and to only derive IMSK from MSK. In order to be compatible with
those implementations, the use of EMSK here is not made mandatory.</t> those implementations, the use of EMSK here is not made mandatory.</t>
<t>Some EAP methods may also have the peer and server derive different <t>Some EAP methods may also have the peer and server derive different
EMSKs. Mandating an EMSK-based derivation there would prevent EMSKs. Mandating an EMSK-based derivation there would prevent
interoperability, as the Crypto-Binding TLV contents which depend on interoperability, as the Crypto-Binding TLV contents that depend on
EMSK could not then be validated by either side. Those methods SHOULD EMSK could not then be validated by either side. Those methods <bcp14>SHOULD
NOT derive IMSK from EMSK unless the method has a way to negotiate how NOT</bcp14> derive IMSK from EMSK unless the method has a way to negotiate how
the EMSK is derived, along with a way signal that both peer and server the EMSK is derived, along with a way to signal that both the peer and server
have derived the same EMSK.</t> have derived the same EMSK.</t>
<t>It is RECOMMENDED that for those EAP methods, implementations take <t>It is <bcp14>RECOMMENDED</bcp14> that for those EAP methods, implem
the entations take the
simpler approach of ignoring EMSK, and always derive IMSK from MSK. simpler approach of ignoring EMSK and always derive IMSK from MSK.
This approach is less secure, as IMSK no longer cryptographically This approach is less secure, as IMSK no longer cryptographically
binds the inner method to the TLS tunnel. A better solution is to binds the inner method to the TLS tunnel. A better solution is to
suggest that deployments of TEAP SHOULD avoid such methods.</t> suggest that deployments of TEAP <bcp14>SHOULD</bcp14> avoid such methods.</t>
<t>The derivation of IMSK[j] from the j'th EMSK is given as follows:</ t> <t>The derivation of IMSK[j] from the j'th EMSK is given as follows:</ t>
<artwork><![CDATA[ <artwork><![CDATA[
IMSK[j] = First 32 octets of TLS-PRF( IMSK[j] = First 32 octets of TLS-PRF(
EMSK[j], EMSK[j],
"TEAPbindkey@ietf.org", "TEAPbindkey@ietf.org",
0x00 | 0x00 | 0x40) 0x00 | 0x00 | 0x40)]]></artwork>
]]></artwork>
<ul empty="true"> <t>Where:</t>
<li> <ul spacing="normal">
<t>where "|" denotes concatenation and the TLS-PRF is defined in <li>"|" denotes concatenation</li>
<xref target="RFC5246"/> as:</t> <li><t>The TLS-PRF is defined in <xref target="RFC5246"/> as:</t>
<artwork><![CDATA[ <artwork><![CDATA[
PRF(secret, label, seed) = P_<hash>(secret, label | seed) PRF(secret, label, seed) = P_<hash>(secret, label | seed)]]></artwork></li>
]]></artwork> <li>The secret is the EMSK from the j'th inner method, the usage l
<t>The secret is the EMSK from the j'th inner method, the usage la abel used is
bel used is
"TEAPbindkey@ietf.org" consisting of the ASCII value for the "TEAPbindkey@ietf.org" consisting of the ASCII value for the
label "TEAPbindkey@ietf.org" (without quotes), the seed label "TEAPbindkey@ietf.org" (without quotes), and the seed
consists of the "\0" null delimiter (0x00) and 2-octet unsigned consists of the "\0" null delimiter (0x00) and 2-octet unsigned
integer length of 64 octets in network byte order (0x00 | 0x40) specified integer length of 64 octets in network byte order (0x00 | 0x40) specified
in <xref target="RFC5295"/>.</t> in <xref target="RFC5295"/>.</li>
</li>
</ul> </ul>
<t>If an inner method does not support export of EMSK but does export
<t>If an inner method does not support the export of EMSK but does exp
ort
MSK, then the IMSK is copied from the MSK of the inner method. If the MSK, then the IMSK is copied from the MSK of the inner method. If the
MSK is longer than 32 octets, the IMSK is copied from the first 32 MSK is longer than 32 octets, the IMSK is copied from the first 32
octets, and the rest of MSK is ignored. If the MSK is shorter than 32 octets and the rest of MSK is ignored. If the MSK is shorter than 32
octets, then the ISMK is copied from MSK, and the remaining data in octets, then the ISMK is copied from MSK and the remaining data in
IMSK is padded with zeros to a length of 32 octets. IMSK[j] is then IMSK is padded with zeros to a length of 32 octets. IMSK[j] is then
this derived value.</t> this derived value.</t>
<t>If inner method does not provide either MSK or EMSK, such as when <t>If the inner method does not provide either MSK or EMSK, such as wh en
basic password authentication is used or when no inner method has been basic password authentication is used or when no inner method has been
run,then both MSK and IMSK[j] are set to all zeroes (i.e., IMSK[j] = run, then both MSK and IMSK[j] are set to all zeroes (i.e., IMSK[j] =
MSK = 32 octets of 0x00s).</t> MSK = 32 octets of 0x00s).</t>
<t>Note that using an MSK of all zeroes opens up TEAP to on-path <t>Note that using an MSK of all zeroes opens up TEAP to on-path
attacks, as discussed below in {#separation-p1-p2}. It is therefore attacks as discussed in <xref target="separation-p1-p2"/>. It is therefore
NOT RECOMMENDED to use inner methods which fail to generate an MSK or <bcp14>NOT RECOMMENDED</bcp14> to use inner methods that fail to generate an MSK
or
EMSK. These methods should only be used in conjunction with another EMSK. These methods should only be used in conjunction with another
inner method which does provide for MSK or EMSK generation.</t> inner method that does provide for MSK or EMSK generation.</t>
<t>It is also RECOMMENDED that TEAP peers order inner methods such tha <t>It is also <bcp14>RECOMMENDED</bcp14> that TEAP peers order inner m
t ethods such that
methods which generate EMSKs are performed before methods which do not methods that generate EMSKs are performed before methods that do not
generate EMSKs. Ordering inner methods in this manner ensures that generate EMSKs. Ordering inner methods in this manner ensures that
the first inner method detects any on-path attackers, and any the first inner method detects any on-path attackers, and any
subsequent inner method used is therefore secure.</t> subsequent inner method used is therefore secure.</t>
<t>For example, Phase 2 could perform both Machine authentication usin <t>For example, Phase 2 could perform both machine authentication usin
g g
EAP-TLS, followed by User authentication via the Basic Password EAP-TLS, followed by user authentication via the Basic Password
Authentication TLVs. In that case, the use of EAP-TLS would allow an Authentication TLVs. In that case, the use of EAP-TLS would allow an
attacker to be detected before the users' password was sent.</t> attacker to be detected before the users' password was sent.</t>
<t>However, it is possible that the peer and server sides might not ha ve <t>However, it is possible that the peer and server sides might not ha ve
the same capability to export EMSK. In order to maintain maximum the same capability to export EMSK. In order to maintain maximum
flexibility while prevent downgrading attack, the following mechanism flexibility while prevent downgrading attack, the following mechanism
is in place.</t> is in place.</t>
</section> </section>
<section anchor="generating-s-imck"> <section anchor="generating-s-imck">
<name>Generating S-IMCK</name> <name>Generating S-IMCK</name>
<t>Once IMSK[j] has been determined, it is mixed via the TLS-PRF with <t>Once IMSK[j] has been determined, it is mixed via the TLS-PRF with
the key S-IMCK[j-1], from a previous round. That mixing derives a the key S-IMCK[j-1] from a previous round. That mixing derives a
new key IMCK[j]. This key is then used to derive both S-IMCK[j] for new key IMCK[j]. This key is then used to derive both S-IMCK[j] for
this round, and CMK[j] for this round.</t> this round and CMK[j] for this round.</t>
<t>The derivation of S-IMCK is as follows:</t> <t>The derivation of S-IMCK is as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
S-IMCK[0] = session_key_seed S-IMCK[0] = session_key_seed
For j = 1 to n-1 do For j = 1 to n-1 do
IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1], IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1],
"Inner Methods Compound Keys", "Inner Methods Compound Keys",
IMSK[j]) IMSK[j])
S-IMCK[j] = first 40 octets of IMCK[j] S-IMCK[j] = first 40 octets of IMCK[j]
CMK[j] = last 20 octets of IMCK[j] CMK[j] = last 20 octets of IMCK[j]]]></artwork>
]]></artwork> <t>where TLS-PRF is the PRF (described above) negotiated as
<t>where TLS-PRF is the PRF described above negotiated as
part of TLS handshake <xref target="RFC5246"/>. The value j refers to a part of TLS handshake <xref target="RFC5246"/>. The value j refers to a
corresponding inner method 1 through n. The special value of corresponding inner method 1 through n. The special value of
S-IMCK[0] is used to bootstrap the calculations, and can be done as S-IMCK[0] is used to bootstrap the calculations and can be done as
soon as the TLS connection is established, and before any inner soon as the TLS connection is established and before any inner
methods are run.</t> methods are run.</t>
<!-- [rfced] We believe that "implement" should be "implementation". Is this
correct?
Original:
In practice, the requirement to use either MSK or EMSK means that an
implement MUST track two independent derivations of IMCK[j], one
which depends on the MSK, and another which depends on EMSK.
Perhaps:
In practice, the requirement to use either MSK or EMSK means that an
implementation MUST track two independent derivations of IMCK[j], one
that depends on the MSK and another that depends on EMSK.
-->
<t>In practice, the requirement to use either MSK or EMSK means that a n <t>In practice, the requirement to use either MSK or EMSK means that a n
implement MUST track two independent derivations of IMCK[j], one which implement <bcp14>MUST</bcp14> track two independent derivations of IMCK[j], one
depends on the MSK, and another which depends on EMSK. That is, we that
depends on the MSK, and another that depends on EMSK. That is, we
have both values derived from MSK:</t> have both values derived from MSK:</t>
<artwork><![CDATA[ <ul spacing="normal">
IMSK_MSK[j] <li>IMSK_MSK[j]</li>
S-IMCK_MSK[j] <li>S-IMCK_MSK[j]</li>
CMK_MSK[j] <li>CMK_MSK[j]</li>
]]></artwork> </ul>
<t>and then also values derived from EMSK:</t> <t>and then also values derived from EMSK:</t>
<artwork><![CDATA[ <ul spacing="normal">
IMSK_EMSK[j] <li>IMSK_EMSK[j]</li>
S-IMCK_EMSK[j] <li>S-IMCK_EMSK[j]</li>
CMK_EMSK[j] <li>CMK_EMSK[j]</li>
]]></artwork> </ul>
<t>At the conclusion of a successfully exchange of Crypto-Binding TLVs <t>At the conclusion of a successful exchange of Crypto-Binding TLVs,
, a a
single S-IMCK[j] is selected based on which Compound-MAC value was single S-IMCK[j] is selected based on which Compound-MAC value was
included in the Crypto-Binding TLV from the client. If EMSK Compound-MAC included in the Crypto-Binding TLV from the client. If EMSK Compound-MAC
was included, S-IMCK[j] is taken from S-IMCK_EMSK[j]. Otherwise, was included, S-IMCK[j] is taken from S-IMCK_EMSK[j]. Otherwise,
S-IMCK[j] is taken from S-IMCK_MSK[j].</t> S-IMCK[j] is taken from S-IMCK_MSK[j].</t>
</section> </section>
<section anchor="choosing-inner-methods"> <section anchor="choosing-inner-methods">
<name>Choosing Inner Methods Securely</name> <name>Choosing Inner Methods Securely</name>
<t>In order to further secure TEAP, implementations can take steps to <t>In order to further secure TEAP, implementations can take steps to
increase their security by carefully ordering inner methods. Where increase their security by carefully ordering inner methods. Where
multiple inner methods are used, implementations SHOULD choose an multiple inner methods are used, implementations <bcp14>SHOULD</bcp14> choose an
ordering so that the first inner method used is one which derives ordering so that the first inner method used is one that derives
EMSK.</t> EMSK.</t>
<t>For an EAP server, it can select the first inner method to be one <t>For an EAP server, it can select the first inner method to be one
which derives EMSK. Since ordering of inner methods is not otherwise that derives EMSK. Since ordering of inner methods is not otherwise
important in EAP, any chosen order is supported by the peer which important in EAP, any chosen order is supported by the peer that
receives this request.</t> receives this request.</t>
<t>For an EAP peer, it can choose its response to a servers request fo <t>For an EAP peer, it can choose its response to a server's request f
r or
a particular type of of authentication. The peer can ignore that a particular type of authentication. The peer can ignore that
request, and return an inner method which derives EMSK. Again, since request and return an inner method that derives EMSK. Again, since
ordering of inner methods is not otherwise important in EAP, any the ordering of inner methods is not otherwise important in EAP, any
chosen order is supported by the server which receives this response. chosen order is supported by the server that receives this response.
Once the more secure authentication has succeed, the server then Once the more secure authentication has succeed, the server then
requests the other type of authentication and the peer can respond requests the other type of authentication and the peer can respond
with the chosen type of authentication.</t> with the chosen type of authentication.</t>
<t>Implementations can also provide configuration flags, policies or <t>Implementations can also provide configuration flags, policies, or
documentated recommendations which control the type of inner methods documented recommendations that control the type of inner methods
used or verify their order. These configurations allow used or verify their order. These configurations allow
implementations and administrators to control their security exposure implementations and administrators to control their security exposure
to on-path attackers.</t> to on-path attackers.</t>
<t>Impementations can permit administators to confgure TEAP so that th e <t>Implementations can permit administrators to configure TEAP so that the
following security checks are enforced:</t> following security checks are enforced:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>verifying that the first inner method used is one which derives <t>Verifying that the first inner method used is one that derives
EMSK. EMSK.
If this is not done, a fatal error can be returned,</t> If this is not done, a fatal error can be returned.</t>
</li> </li>
<li> <li>
<t>verifying that if any inner method derives EMSK, that the recei ved <t>Verifying that if any inner method derives EMSK, the received
Crypto-Binding TLV for that method contains an EMSK Compound-MAC. Crypto-Binding TLV for that method contains an EMSK Compound-MAC.
If an EMSK has been derived and no EMSK Compound-MAC is seen, a If an EMSK has been derived and no EMSK Compound-MAC is seen, a
fatal error can be returned.</t> fatal error can be returned.</t>
</li> </li>
</ul> </ul>
<t>The goal of these suggestions is to enforce the use of the EMSK <t>The goal of these suggestions is to enforce the use of the EMSK
Compound-MAC to protect the TEAP session from on-path attackers. If Compound-MAC to protect the TEAP session from on-path attackers. If
these suggestions are not enforced, then the TEAP session is these suggestions are not enforced, then the TEAP session is
vulnerable.</t> vulnerable.</t>
<t>Most of these suggestions are not normative, as some existing <t>Most of these suggestions are not normative, as some existing
implementations are known to not follow them. Instead, these implementations are known to not follow them. Instead, these
suggestions are here to inform new implementers, along with suggestions are here to inform new implementors, along with
administrators, of the issues surrounding this subject.</t> administrators, of the issues surrounding this subject.</t>
</section> </section>
<section anchor="managing-and-computing-crypto-binding"> <section anchor="managing-and-computing-crypto-binding">
<name>Managing and Computing Crypto-Binding</name> <name>Managing and Computing Crypto-Binding</name>
<t>After an inner method has been completed successfully and the inner <t>After an inner method has been completed successfully and the inner
keys derived, the server sends a Crypto-Binding TLV to the peer. If keys have been derived, the server sends a Crypto-Binding TLV to the peer. If
the inner method has failed, the server does not send a Crypto-Binding the inner method has failed, the server does not send a Crypto-Binding
TLV.</t> TLV.</t>
<t>The peer verifies the Crypto-Binding TLV by applying the rules defi ned <t>The peer verifies the Crypto-Binding TLV by applying the rules defi ned
in <xref target="crypto-binding-tlv"/>. If verification passes, the peer respon ds in <xref target="crypto-binding-tlv"/>. If verification passes, the peer respon ds
with its own Crypto-Binding TLV, which the server in turn verifies. with its own Crypto-Binding TLV, which the server in turn verifies.
If at any point verification fails, the party which makes this If at any point verification fails, the party that makes this
determination terminates the session.</t> determination terminates the session.</t>
<t>The Crypto-Binding TLV is normally sent in conjunction with other T <t>The Crypto-Binding TLV is normally sent in conjunction with other T
LVs LVs that indicate intermediate or final results or that begin
which indicate intermediate results, final results, or which begin negotiation of a new inner method. This negotiation does not otherwise
negotiation of a new inner method. This negotation does not otherwise
affect the Crypto-Binding TLV.</t> affect the Crypto-Binding TLV.</t>
<t>While <xref target="crypto-binding-tlv"/> defines that the Compound -MAC fields <t>While <xref target="crypto-binding-tlv"/> defines that the Compound -MAC fields
exist in the Crypto-Binding TLV, it does not describe the derivation exist in the Crypto-Binding TLV, it does not describe the derivation
and management of those fields. This derivation is complex, and and management of those fields. This derivation is complex and
is therefore located here, along with the other key deriviations.</t> is therefore located here along with the other key derivations.</t>
<t>The following text defines how the server and peer compute, send, a nd <t>The following text defines how the server and peer compute, send, a nd
then verify the Compound-MAC fields Crypto-Binding TLV. Depending on then verify the Compound-MAC fields Crypto-Binding TLV. Depending on
the inner method and site policy, Crypto-Binding TLV can contain only the inner method and site policy, the Crypto-Binding TLV can contain only
an MSK Compound-MAC (Flags=2), it it can contain only the EMSK an MSK Compound-MAC (Flags=2), only the EMSK
Compound-MAC (Flags=2), or it can contain both Compound-MACs Compound-MAC (Flags=2), or both Compound-MACs
(Flags=3). Each party to the TEAP session follows its own set of (Flags=3). Each party to the TEAP session follows its own set of
procedures to compute and verify the Compound-MAC fields.</t> procedures to compute and verify the Compound-MAC fields.</t>
<t>The determination of the contents of the Crypto-Binding TLV is done <t>The determination of the contents of the Crypto-Binding TLV is done
separately for each inner method. If at any point the verification of separately for each inner method. If at any point the verification of
a Compound-MAC fails, the determining party returns a fatal error as a Compound-MAC fails, the determining party returns a fatal error as
described in <xref target="phase-2-errors"/>.</t> described in <xref target="phase-2-errors"/>.</t>
<t>We presume that each of the peer and server have site policies whic
h <!--[rfced] To clarify "(or not)", may we rephrase this sentence as follows?
Original:
We presume that each of the peer and server have site policies which
require (or not) the use of the MSK Compound-MAC and/or the EMSK
Compound-MAC.
Perhaps:
We presume that each peer and server have site policies that may or may not
require the use of the MSK Compound-MAC and/or the EMSK Compound-MAC.
-->
<t>We presume that each peer and server have site policies that
require (or not) the use of the MSK Compound-MAC and/or the EMSK require (or not) the use of the MSK Compound-MAC and/or the EMSK
Compound-MAC. These policies can be enforced globally for all inner Compound-MAC. These policies can be enforced globally for all inner
methods, or they can be enforced separately on each inner method. methods, or they can be enforced separately on each inner method.
These policies could be enabled automatically when the EAP method is These policies could be enabled automatically when the EAP method is
known to always generate an EMSK, and could otherwise be configurable.</t> known to always generate an EMSK and could otherwise be configurable.</t>
<t>The server initiates crypto binding by determining which <t>The server initiates crypto binding by determining which
Compound-MAC(s) to use, computing their value(s), placing the Compound-MAC(s) to use, computing their value(s), placing the
resulting Compond-MAC(s) into the Crypto-Binding TLV, and then sending resulting Compound-MAC(s) into the Crypto-Binding TLV, and then sending
it to the peer.</t> it to the peer.</t>
<t>The steps taken by the server are then as follows.</t> <t>Then, the steps taken by the server are as follows:</t>
<ul empty="true"> <ul spacing="normal">
<li> <li><t>If the inner method is known to generate only MSK, or if
<t>If the inner method is known to generate only MSK, or if the se the server's policy is to not use EMSK Compound-MACs:</t>
rvers <ul spacing="normal">
policy is to not use EMSK Compound-MACs:</t> <li>The server computes the MSK Compound-MAC using the MSK
<ul empty="true"> of the inner method. The server does not use the EMSK
<li> Compound-MAC field (Flags=2).</li>
<t>The server computes the MSK Compound-MAC using the MSK of t
he inner
method. The server does not use the EMSK Compound-MAC field.
(Flags=2)</t>
</li>
</ul> </ul>
<t>Otherwise the EMSK is available.</t> <t>Otherwise, the EMSK is available.</t></li>
<t>If the servers policy permits the use of the MSK Compound-MAC:< <li><t>If the server's policy permits the use of the MSK Compound-MA
/t> C:</t>
<ul empty="true"> <ul spacing="normal">
<li> <li>The sender computes the MSK Compound-MAC along with
<t>The sender computes the MSK Compound-MAC along with the EMS the EMSK Compound-MAC (Flags=3).</li>
K
Compound-MAC. (Flags=3).</t>
</li>
</ul> </ul>
<t>Otherwise the servers policy does not allow the use of the <t>Otherwise, the server's policy does not allow the use of the
MSK Compound-MAC:</t> MSK Compound-MAC:</t>
<t>The server computes only the EMSK Compound-MAC (Flags=1).</t> <ul spacing="normal">
</li> <li>The server computes only the EMSK Compound-MAC (Flags=1).</li
</ul> >
</ul>
</li>
</ul>
<t>The peer verifies the Crypto-Binding TLV it receives from the serve r. <t>The peer verifies the Crypto-Binding TLV it receives from the serve r.
It then replies with its own crypto binding response by determining It then replies with its own crypto binding response by determining
which Compound-MAC(s) to use, computing their value(s), placing the which Compound-MAC(s) to use, computing their value(s), placing the
resulting Compond-MAC(s) into the Crypto-Binding TLV, and then sending resulting Compound-MAC(s) into the Crypto-Binding TLV, and then sending
it to the server. The result of this process is either a fatal error, it to the server. The result of this process is either a fatal error
or one or more Compound-MACs which are placed in the Crypto-Binding or one or more Compound-MACs that are placed in the Crypto-Binding
TLV, and sent to the server.</t> TLV and sent to the server.</t>
<t>The steps taken by the peer are then as follows.</t> <t>Then, the steps taken by the peer are as follows:</t>
<ul empty="true"> <ul spacing="normal">
<li> <li><t>If the peer site policy requires the use of the EMSK
<t>If the peer site policy requires the use of the EMSK Compound-M Compound-MAC:</t>
AC:</t> <ul spacing="normal">
<ul empty="true"> <li>The peer checks if the Flags field indicates the presence
<li> of the EMSK Compound MAC (Flags=1 or 3). If the Flags field
<t>The peer checks if the Flags field indicates the presence o has any other value, the peer returns a fatal error.</li>
f the <li>The peer checks if the inner method has derived an EMSK.
EMSK Compound MAC (Flags=1 or 3). If the Flags field has any other If not, the peer returns a fatal error.</li>
value, the peer returns a fatal error.</t>
<t>The peer checks if the inner method has derived an EMSK. I
f not,
the peer returns a fatal error.</t>
</li>
</ul> </ul>
<t>Otherwise the peer site policy does not require the use of the <t>Otherwise, the peer site policy does not require the use of the
EMSK EMSK Compound-MAC and the EMSK may or may not exist.</t></li>
Compound-MAC, and the EMSK may or may not exist.</t> <li><t>If the inner method is known to generate only MSK and not EMS
<t>If the inner method is known to generate only MSK and not EMSK: K:</t>
&gt; <ul spacing="normal">
&gt; The peer checks if the Flags field indicates that only the MSK <li>The peer checks if the Flags field indicates that only the
&gt; Compound-MAC exists (Flags=2). If the Flags field has any other MSK Compound-MAC exists (Flags=2). If the Flags field has any
&gt; value, the peer returns a fatal error.</t> other value, the peer returns a fatal error.</li>
<t>Otherwise the MSK exists, the EMSK may or may not exist, and th </ul>
e <t>Otherwise, the MSK exists, the EMSK may or may not exist, and
peer allows the use of the EMSK Compound-MAC. The peer may have the peer allows the use of the EMSK Compound-MAC. The peer may
received one or two Compound-MACs (Flags=1,2,3). Any Compound-MAC have received one or two Compound-MACs (Flags=1,2,3). Any
which is present is verified. No futher action is taken by the peer Compound-MAC that is present is verified. No futher action is
if a particular Compound-MAC is not present. No further action is taken by the peer if a particular Compound-MAC is not present.
taken by the peer if an unexpected Compound-MAC is present.</t> No further action is taken by the peer if an unexpected
<t>Note that due to earlier validation of the Flags field Compound-MAC is present.</t>
(<xref target="crypto-binding-tlv"/>), at least one Compound-MAC must now exist. <t>Note that due to earlier validation of the Flags field (<xref
(Flags=1,2,3)</t> target="crypto-binding-tlv"/>), at least one Compound-MAC must
<t>If the peer has received an MSK Compound-MAC, it verifies it an now exist (Flags=1,2,3).</t></li>
d <li>If the peer has received an MSK Compound-MAC, it verifies
returns a fatal error if verification fails.</t> it and returns a fatal error if verification fails.</li>
<t>If EMSK is available, and the peer has received an EMSK <li>If EMSK is available and the peer has received an EMSK
Compound-MAC, it verifies it and returns a fatal error if Compound-MAC, it verifies it and returns a fatal error if
verification fails.</t> verification fails.</li>
</li>
</ul> </ul>
<t>The peer creates a crypto binding response by determining which <t>The peer creates a crypto binding response by determining which
Compound-MAC(s) to use, computing their value(s), placing the Compound-MAC(s) to use, computing their value(s), placing the
resulting Compond-MAC(s) into the Crypto-Binding TLV, and then sending resulting Compound-MAC(s) into the Crypto-Binding TLV, and then sending
it to the server.</t> it to the server.</t>
<t>The steps taken by the peer are then as follows.</t> <t>The steps taken by the peer are then as follows.</t>
<ul empty="true"> <ul spacing="normal">
<li> <li><t>If the peer received an MSK Compound-MAC from the
<t>If the peer received an MSK Compound-MAC from the server:</t> server:</t>
<ul empty="true"> <ul spacing="normal">
<li> <li>Since the MSK always exists, this step is always
<t>Since the MSK always exists, this step is always possible. possible. The peer computes the MSK Compound-MAC for the
The peer response (Flags=2).</li>
computes the MSK Compound-MAC for the response. (Flags=2)</t>
</li>
</ul>
<t>If the peers site policy requires the use of the EMSK Compound-
MAC,</t>
<ul empty="true">
<li>
<t>The preceding steps taken by the peer ensures that the EMSK
exists,
and the server had sent an EMSK Compound-MAC. The peer computes
the EMSK Compound-MAC for the response. The Flags field is
updated. (Flags=1,3)</t>
</li>
</ul> </ul>
<t>Otherwise if the EMSK exists:</t> </li>
<ul empty="true"> <li><t>If the peer site policy requires the use of the EMSK Compound
<li> -MAC:</t>
<t>The peer computes the EMSK Compound-MAC for the response. T <ul spacing="normal">
he Flags <li>The preceding steps taken by the peer ensures that the
field is updated. (Flags=1,3)</t> EMSK exists and the server had sent an EMSK Compound-MAC.
</li> The peer computes the EMSK Compound-MAC for the response. The
Flags field is updated (Flags=1,3).</li>
</ul> </ul>
</li> <t>Otherwise, if the EMSK exists:</t>
</ul> <ul spacing="normal">
<t>The server processes the response from the peer via the following s <li>The peer computes the EMSK Compound-MAC for the
teps:</t> response. The Flags field is updated (Flags=1,3).</li>
<ul empty="true">
<li>
<t>If the server site policy requires the use of the EMSK Compound
-MAC:</t>
<ul empty="true">
<li>
<t>The server checks if the Flags field indicates the presence
of the
EMSK Compound MAC (Flags=1 or 3). If the Flags field has any other
value, the server returns a fatal error.</t>
<t>The server checks if the inner method has derived an EMSK.
If not,
the server returns a fatal error.</t>
</li>
</ul> </ul>
<t>If the inner method is known to generate only MSK and not EMSK: </li></ul>
&gt; <t>The server processes the response from the peer via the following
&gt; The server checks if the Flags field indicates that only the MSK steps:</t>
&gt; Compound-MAC exists (Flags=2). If the Flags field has any other <ul spacing="normal">
&gt; value, the server returns a fatal error.</t> <li><t>If the server site policy requires the use of the EMSK Comp
<t>Otherwise the MSK exists, and the EMSK may or may not exist. T ound-MAC:</t>
he <ul spacing="normal">
server may have received one or two Compound-MACs (Flags=1,2,3). <li>The server checks if the Flags field indicates the
Any Compound-MAC which is present is verified. No further action is presence of the EMSK Compound MAC (Flags=1 or 3). If the
taken by the server if a particular Compound-MAC is not present. No Flags field has any other value, the server returns a fatal
further action is taken by the server if an unexpected Compound-MAC is error.</li>
present.</t> <li>The server checks if the inner method has derived an EMSK.
<t>If the server has received an MSK Compound-MAC, it verifies it If not, the server returns a fatal error.</li>
and </ul></li>
returns a fatal error if verification fails.</t> <li><t>If the inner method is known to generate only MSK and not E
<t>If EMSK is available, and the server has received an EMSK MSK:</t>
Compound-MAC, it verifies it and returns a fatal error if <ul spacing="normal">
verification fails.</t> <li>The server checks if the Flags field indicates that only
</li> the MSK Compound-MAC exists (Flags=2). If the Flags field has
any other value, the server returns a fatal error.</li>
</ul>
<t>Otherwise, the MSK exists and the EMSK may or may not exist.
The server may have received one or two Compound-MACs
(Flags=1,2,3). Any Compound-MAC that is present is verified.
No further action is taken by the server if a particular
Compound-MAC is not present. No further action is taken by the
server if an unexpected Compound-MAC is present.</t></li>
<li>If the server has received an MSK Compound-MAC, it verifies
it and returns a fatal error if verification fails.</li>
<li>If EMSK is available and the server has received an EMSK
Compound-MAC, it verifies it and returns a fatal error if
verification fails.</li>
</ul> </ul>
<t>Once the above steps have concluded, the server either continues <t>Once the above steps have concluded, the server either continues
authentication with another inner method, or it returns a Result TLV.</t> authentication with another inner method or it returns a Result TLV.</t>
</section> </section>
<section anchor="oops"> <section anchor="oops">
<name>Unintended Side Effects</name> <name>Unintended Side Effects</name>
<t>In earlier drafts of this document, the descriptions of the key <t>In earlier drafts of this document, the descriptions of the key
derivations had issues which were only discovered after TEAP had been derivations had issues that were only discovered after TEAP had been
widely implemented. These issues need to be documented in order to widely implemented. These issues need to be documented in order to
enable interoparable implementations.</t> enable interoperable implementations.</t>
<t>As noted above, some inner EAP methods derive MSK, but do not deriv <t>As noted above, some inner EAP methods derive MSK but do not derive
e
EMSK. When there is no EMSK, it is therefore not possible to derive EMSK. When there is no EMSK, it is therefore not possible to derive
IMCK_EMSK[j] from it. The choice of multiple implementations was IMCK_EMSK[j] from it. The choice of multiple implementations was
then to simply define:</t> then to simply define:</t>
<artwork><![CDATA[ <artwork><![CDATA[
IMCK_EMSK[j] = IMCK_EMSK[j - 1] IMCK_EMSK[j] = IMCK_EMSK[j - 1]]]></artwork>
]]></artwork> <t>This definition can be trivially implemented by simply keeping a
<t>This definition can be trivially implementation by simply keeping a
cached copy of IMCK_EMSK in a data structure. If EMSK is available, cached copy of IMCK_EMSK in a data structure. If EMSK is available,
IMCK_EMCK is updated from it via the TLS-PRF function as defined IMCK_EMCK is updated from it via the TLS-PRF function as defined
above. If EMSK is not available, then the IMCK_EMSK value is above. If EMSK is not available, then the IMCK_EMSK value is
unmodified.</t> unmodified.</t>
<t>This behavior was not explicitly anticipated by earlier drafts of t his <t>This behavior was not explicitly anticipated by earlier drafts of t his
document. It instead appears to be an accidental outcome of document. It instead appears to be an accidental outcome of
implementing the derivations above, with the limitiation of a missing implementing the derivations above with the limitation of a missing
EMSK. This behavior is explicitly called out here in the interest of EMSK. This behavior is explicitly called out here in the interest of
fully documenting TEAP.</t> fully documenting TEAP.</t>
<t>Another unintended consequence is in the calculation of the <t>Another unintended consequence is in the calculation of the
Crypto-Binding TLV. That TLV includes compound MACs which depend on Crypto-Binding TLV. That TLV includes compound MACs that depend on
the MSK and EMSK of the current authentication method. Where the the MSK and EMSK of the current authentication method. Where the
current method does not provide an EMSK, the Crypto-Binding TLV does current method does not provide an EMSK, the Crypto-Binding TLV does
not include a compound MAC which depends on the EMSK. Where the not include a compound MAC that depends on the EMSK. Where the
current method does not provide an MSK, the Crypto-Binding TLV current method does not provide an MSK, the Crypto-Binding TLV
includes a compound MAC which depends on a special "all zero" IMSK as includes a compound MAC that depends on a special "all zero" IMSK as
discussed earlier.</t> discussed earlier.</t>
<t>The result of this definition is that the final Crypto-Binding TLV in <t>The result of this definition is that the final Crypto-Binding TLV in
an inner TEAP exchange may not include a compond MAC which depends on an inner TEAP exchange may not include a compound MAC that depends on
EMSK, even if earlier EAP methods in the phase 2 exchange provided an EMSK, even if earlier EAP methods in the Phase 2 exchange provided an
ESMK. This result likely has negative affects on security, though the EMSK. This result likely has negative effects on security, though the
full impact is unknown at the time of writing this document.</t> full impact is unknown at the time of writing this document.</t>
<!--[rfced] To clarify that "earlier versions" is referring to "TEAPv1",
may we update "document" to "specification" at the end of this sentence?
Original:
For this document, we can only ensure
that the behavior of TEAPv1 is fully documented, even if that
behavior was an unintended consequence of unclear text in earlier
versions of this document.
Perhaps:
For this document, we can only ensure
that the behavior of TEAPv1 is fully documented, even if that
behavior was an unintended consequence of unclear text in earlier
versions of this specification.
-->
<t>These design flaws have nonetheless resulted in multiple interopera ble <t>These design flaws have nonetheless resulted in multiple interopera ble
implementations. We note that these implementations seem to support implementations. We note that these implementations seem to support
only EAP-TLS and the EAP-FAST-MSCHAPv2 variant of EAP-MSCHAPv2. Other only EAP-TLS and the EAP-FAST-MSCHAPv2 variant of EAP-MSCHAPv2. Other
inner EAP methods may work by accident, but are not likely to work by inner EAP methods may work by accident but are not likely to work by
design. For this document, we can only ensure that the behavior of design. For this document, we can only ensure that the behavior of
TEAPv1 is fully documented, even if that behavior was an unintended TEAPv1 is fully documented, even if that behavior was an unintended
consequence of unclear text in earlier versions of this document.</t> consequence of unclear text in earlier versions of this document.</t>
<t>We expect that these issues will be addressed in a future revision of <t>We expect that these issues will be addressed in a future revision of
TEAP.</t> TEAP.</t>
</section> </section>
</section> </section>
<section anchor="computing-compound-mac"> <section anchor="computing-compound-mac">
<name>Computing the Compound-MAC</name> <name>Computing the Compound-MAC</name>
<!-- [rfced] Please review the following text. We note that the abbreviation
"CMK" follows "Compound Session Key" even though "CMK" is the
abbreviation for "Compound MAC key". Please let us know how this sentence
should be updated.
Current:
After each successful inner EAP authentication, EAP
EMSK and/or MSKs are cryptographically combined with key material
from TEAP Phase 1 to generate a Compound Session Key (CMK).
Perhaps (Compound Session key):
After each successful inner EAP authentication, EAP
EMSK and/or MSKs are cryptographically combined with key material
from TEAP Phase 1 to generate a Compound Session Key.
Or: (CMK with no expansion):
After each successful inner EAP authentication, EAP
EMSK and/or MSKs are cryptographically combined with key material
from TEAP Phase 1 to generate a CMK.
-->
<t>For inner methods that generate keying material, further <t>For inner methods that generate keying material, further
protection against on-path attacks is provided through protection against on-path attacks is provided through
cryptographically binding keying material established by both TEAP cryptographically binding keying material established by both TEAP
Phase 1 and TEAP Phase 2 conversations. After each successful inner Phase 1 and TEAP Phase 2 conversations. After each successful inner
EAP authentication, EAP EMSK and/or MSKs are cryptographically EAP authentication, EAP EMSK and/or MSKs are cryptographically
combined with key material from TEAP Phase 1 to generate a Compound combined with key material from TEAP Phase 1 to generate a Compound Session Key
Session Key (CMK). The CMK is used to calculate the Compound-MAC as (CMK). The CMK is used to calculate the Compound-MAC as
part of the Crypto-Binding TLV described in <xref target="crypto-binding-tlv"/>, which part of the Crypto-Binding TLV described in <xref target="crypto-binding-tlv"/>, which
helps provide assurance that the same entities are involved in all helps provide assurance that the same entities are involved in all
communications in TEAP. During the calculation of the Compound-MAC, communications in TEAP. During the calculation of the Compound-MAC,
the MAC field is filled with zeros.</t> the MAC field is filled with zeros.</t>
<t>The Compound-MAC computation is as follows:</t> <t>The Compound-MAC computation is as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Compound-MAC = the first 20 octets of MAC( CMK[n], BUFFER ) Compound-MAC = the first 20 octets of MAC( CMK[n], BUFFER )]]></artwork>
]]></artwork>
<t>where n is the number of the last successfully executed inner <t>where n is the number of the last successfully executed inner
method, MAC is the MAC function negotiated in TLS (e.g. TLS 1.2 in <xref target= "RFC5246"/>), and method, MAC is the MAC function negotiated in TLS (e.g., TLS 1.2 in <xref target ="RFC5246"/>), and
BUFFER is created after concatenating these fields in the following BUFFER is created after concatenating these fields in the following
order:</t> order:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>The entire Crypto-Binding TLV attribute with both the EMSK and MS K <t>The entire Crypto-Binding TLV attribute with both the EMSK and MS K
Compound-MAC fields zeroed out.</t> Compound-MAC fields zeroed out.</t>
</li> </li>
<li> <li>
<t>The EAP Type sent by the other party in the first TEAP message, <t>The EAP Type sent by the other party in the first TEAP message,
which MUST be TEAP, encoded as one octet of 0x37.</t> which <bcp14>MUST</bcp14> be TEAP, encoded as one octet of 0x37.</t>
</li> </li>
<li> <li>
<t>All the Outer TLVs from the first TEAP message sent by EAP server <t>All the Outer TLVs from the first TEAP message sent by the EAP se
to peer. If a single TEAP message is fragmented into multiple rver
to the peer. If a single TEAP message is fragmented into multiple
TEAP packets, then the Outer TLVs in all the fragments of that TEAP packets, then the Outer TLVs in all the fragments of that
message MUST be included.</t> message <bcp14>MUST</bcp14> be included.</t>
</li> </li>
<li> <li>
<t>All the Outer TLVs from the first TEAP message sent by the peer t o <t>All the Outer TLVs from the first TEAP message sent by the peer t o
the EAP server. If a single TEAP message is fragmented into the EAP server. If a single TEAP message is fragmented into
multiple TEAP packets, then the Outer TLVs in all the fragments of multiple TEAP packets, then the Outer TLVs in all the fragments of
that message MUST be included.</t> that message <bcp14>MUST</bcp14> be included.</t>
</li> </li>
</ol> </ol>
<t>If no inner method is run, then no MSK or EMSK <t>If no inner method is run, then no MSK or EMSK
will be generated. If an IMSK needs to be generated then the MSK will be generated. If an IMSK needs to be generated, then the MSK
and therefore the IMSK is set to all zeroes (i.e., IMSK = MSK = 32 octets of 0x0 0s).</t> and therefore the IMSK is set to all zeroes (i.e., IMSK = MSK = 32 octets of 0x0 0s).</t>
<t>Note that there is no boundary marker between the fields in steps (3) <t>Note that there is no boundary marker between the fields in steps (3)
and (4). However, the server calculates the compound MAC using the and (4). However, the server calculates the compound MAC using the
outer TLVs it sent, and the outer TLVs it received from the peer. On outer TLVs it sent and the outer TLVs it received from the peer. On
the other side, the peer calculates the compound MAC using the outer the other side, the peer calculates the compound MAC using the outer
TLVs it sent, and the outer TLVs it received from the server. As a TLVs it sent and the outer TLVs it received from the server. As a
result, and modification in transit of the outer TLVs will be detected result, any modification in transit of the outer TLVs will be detected
because the two sides will calculate different values for the compound because the two sides will calculate different values for the compound
MAC.</t> MAC.</t>
<t>If no key generating inner method is run then no MSK or EMSK will be <t>If no key-generating inner method is run, then no MSK or EMSK will be
generated. If an IMSK needs to be generated then the MSK and therefore generated. If an IMSK needs to be generated, then the MSK and therefore
the IMSK is set to all zeroes (i.e., IMSK = MSK = 32 octets of 0x00s)</t> the IMSK is set to all zeroes (i.e., IMSK = MSK = 32 octets of 0x00s)</t>
</section> </section>
<section anchor="eap-master-session-key-generation"> <section anchor="eap-master-session-key-generation">
<name>EAP Master Session Key Generation</name> <name>EAP Master Session Key Generation</name>
<t>TEAP authentication assures the Master Session Key (MSK) and Extended <t>TEAP authentication assures the MSK and EMSK output from running TEAP
Master Session Key (EMSK) output from running TEAP are the combined result are the combined result
of all inner methods by generating an Intermediate of all inner methods by generating an IMCK. The IMCK is mutually derived by the
Compound Key (IMCK). The IMCK is mutually derived by the peer and peer and
the server as described in <xref target="intermediate-compound-key"/> by combini ng the MSKs from the server as described in <xref target="intermediate-compound-key"/> by combini ng the MSKs from
inner methods with key material from TEAP Phase 1. The resulting inner methods with key material from TEAP Phase 1. The resulting
MSK and EMSK are generated from the final ("n"th) inner method, as part of the I MCK[n] key hierarchy via the MSK and EMSK are generated from the final ("n"th) inner method, as part of the I MCK[n] key hierarchy via the
following derivation:</t> following derivation:</t>
<artwork><![CDATA[ <artwork><![CDATA[
MSK = the first 64 octets of TLS-PRF(S-IMCK[n], MSK = the first 64 octets of TLS-PRF(S-IMCK[n],
"Session Key Generating Function") "Session Key Generating Function")
EMSK = the first 64 octets of TLS-PRF(S-IMCK[n], EMSK = the first 64 octets of TLS-PRF(S-IMCK[n],
"Extended Session Key Generating Function") "Extended Session Key Generating Function")]]></artwork>
]]></artwork> <t>The secret is S-IMCK[n], where n is the
<t>The secret is S-IMCK[n] where n is the
number of the last generated number of the last generated
S-IMCK[j] from <xref target="intermediate-compound-key"/>. The label is the ASC II S-IMCK[j] from <xref target="intermediate-compound-key"/>. The label is the ASC II
value for the string without quotes. The seed is empty (0 length) and value for the string without quotes. The seed is empty (0 length) and
is omitted from the derivation.</t> is omitted from the derivation.</t>
<t>The EMSK is typically only known to the TEAP peer and server and is <t>The EMSK is typically only known to the TEAP peer and server and is
not provided to a third party. The derivation of additional keys and not provided to a third party. The derivation of additional keys and
transportation of these keys to a third party are outside the scope transportation of these keys to a third party are outside the scope
of this document.</t> of this document.</t>
<t>If no inner method has created an MSK or EMSK, the MSK <t>If no inner method has created an MSK or EMSK, the MSK
and EMSK will be generated directly from the session_key_seed meaning and EMSK will be generated directly from the session_key_seed meaning
S-IMCK[0] = session_key_seed.</t> S-IMCK[0] = session_key_seed.</t>
<t>As we noted above, not all inner methods generate both MSK and EMSK, <t>As we noted above, not all inner methods generate both MSK and EMSK,
so we have to maintain two independent derivations of S-IMCK[j], one so we have to maintain two independent derivations of S-IMCK[j], one
for each of MSK[j] and EMSK[j]. The final derivation using for each of MSK[j] and EMSK[j]. The final derivation using
S-IMCK[n] must choose only one of these keys.</t> S-IMCK[n] must choose only one of these keys.</t>
<t>If the Crypto-Binding TLV contains an EMSK compound MAC, then the <t>If the Crypto-Binding TLV contains an EMSK compound MAC, then the
derivation is taken from the S-IMCK_EMSK[n]. Otherwise it is taken derivation is taken from the S-IMCK_EMSK[n]. Otherwise, it is taken
from the S-IMCK_MSK[n].</t> from the S-IMCK_MSK[n].</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<!-- [rfced] Should this citation be to BCP26 or RFC 8126?
Current:
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the TEAP
protocol, in accordance with BCP 26 [RFC8126].
-->
<t>This section provides guidance to the Internet Assigned Numbers <t>This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the TEAP Authority (IANA) regarding registration of values related to the TEAP
protocol, in accordance with BCP 26 <xref target="RFC8126"/>.</t> protocol in accordance with BCP 26 <xref target="RFC8126"/>.</t>
<t>Except as noted below, IANA is instructed to update the "Tunnel <t>Except as noted below, IANA has updated the "Tunnel
Extensible Authentication Protocol (TEAP) Parameters" registry to Extensible Authentication Protocol (TEAP) Parameters" registry to
change the Reference field in all tables from <xref target="RFC7170"/> to [THIS- DOCUMENT].</t> change the Reference field in all tables from <xref target="RFC7170"/> to RFC 99 30.</t>
<section anchor="teap-tlv-types"> <section anchor="teap-tlv-types">
<name>TEAP TLV Types</name> <name>TEAP TLV Types</name>
<t>IANA is instructed to update the references in the "TEAP TLV Types" <t>IANA has updated the references in the "TEAP TLV Types"
registry to from <xref target="RFC7170"/> to [THIS-DOCUMENT], and add TLV 18 and registry from <xref target="RFC7170"/> to RFC 9930 and added TLV 18 and TLV 19 t
TLV 19 to o
to the registry. The Unassigned values then begin at 20 instead of at 18.</t> the registry. The Unassigned values then begin at 20 instead of at 18.</t>
<artwork><![CDATA[ <table>
Value,Description,Reference <thead><tr><th>Value</th><th>Description</th><th>Reference</th></tr></thead>
18,CSR-Attributes TLV,[THIS-DOCUMENT] <tbody>
19,Identity-Hint TLV,[THIS-DOCUMENT] <tr><td>18</td><td>CSR-Attributes TLV</td><td>RFC 9930</td></tr>
20-16383,Unassigned, <tr><td>19</td><td>Identity-Hint TLV</td><td>RFC 9930</td></tr>
]]></artwork> <tr><td>20-16383</td><td colspan="2">Unassigned</td></tr>
<t>IANA is instructed to close the "TEAP PAC TLV (value 11) PAC </tbody>
</table>
<t>IANA has closed the "TEAP PAC TLV (value 11) PAC
Attribute Type Codes" and "TEAP PAC TLV (value 11) PAC-Type Type Attribute Type Codes" and "TEAP PAC TLV (value 11) PAC-Type Type
Codes" to new registrations, and update update those registries with with a NOTE Codes" registries to new registrations and updated those registries with the fol
:</t> lowing note:</t>
<artwork><![CDATA[ <blockquote>This registry has been closed. See RFC 9930.</blockquote>
This registry has been closed. See [THIS-DOCUMENT].
]]></artwork>
</section> </section>
<section anchor="teap-error-tlv-value-5-error-codes"> <section anchor="teap-error-tlv-value-5-error-codes">
<name>TEAP Error TLV (value 5) Error Codes</name> <name>TEAP Error TLV (value 5) Error Codes</name>
<t>IANA is instructed to update the "TEAP Error TLV (value 5) Error Code <t>IANA has updated the "TEAP Error TLV (value 5) Error Codes" registry
s" registry to add the following entries"</t> to add the following entries:</t>
<artwork><![CDATA[ <table>
Value,Description,Reference <thead><tr><th>Value</th><th>Description</th><th>Reference</th></tr></thead>
1032,Inner method not supported,[THIS-DOCUMENT] <tbody>
2003,The Crypto-Binding TLV is invalid (Version, or Received-Ver, or Sub-Type),[ <tr><td>1032</td><td>Inner method not supported</td><td>RFC 9930</td></tr>
THIS-DOCUMENT] <tr><td>2003</td><td>The Crypto-Binding TLV is invalid (Version, or Received
2004,The first inner method did not derive EMSK,[THIS-DOCUMENT] -Ver, or Sub-Type)</td><td>RFC 9930</td></tr>
2005,The Crypto-Binding TLV did not include a required MSK Compound-MAC,[THIS-DO <tr><td>2004</td><td>The first inner method did not derive EMSK</td><td>RFC
CUMENT] 9930</td></tr>
2006,The MSK Compound-MAC fails verification,[THIS-DOCUMENT] <tr><td>2005</td><td>The Crypto-Binding TLV did not include a required MSK C
2007,The Crypto-Binding TLV did not include a required EMSK Compound-MAC,[THIS-D ompound-MAC</td><td>RFC 9930</td></tr>
OCUMENT] <tr><td>2006</td><td>The MSK Compound-MAC fails verification</td><td>RFC 993
2008,The EMSK Compound-MAC fails verification,[THIS-DOCUMENT] 0</td></tr>
2009,The EMSK Compound-MAC exists, but the inner method did not derive EMSK,[THI <tr><td>2007</td><td>The Crypto-Binding TLV did not include a required EMSK
S-DOCUMENT] Compound-MAC</td><td>RFC 9930</td></tr>
]]></artwork> <tr><td>2008</td><td>The EMSK Compound-MAC fails verification</td><td>RFC 99
30</td></tr>
<tr><td>2009</td><td>The EMSK Compound-MAC exists, but the inner method did
not derive EMSK</td><td>RFC 9930</td></tr>
</tbody>
</table>
</section> </section>
<section anchor="tls-exporter-labels"> <section anchor="tls-exporter-labels">
<name>TLS Exporter Labels</name> <name>TLS Exporter Labels</name>
<t>IANA is instructed to update the "TLS Exporter Labels" registry to ch <t>IANA has updated the "TLS Exporter Labels" registry to change the Ref
ange the Reference field for Value "EXPORTER: teap session key seed" as follows: erence field for Value "EXPORTER: teap session key seed" as follows:</t>
</t> <table>
<artwork><![CDATA[ <thead><tr><th>Value</th><th>DTLS-OK</th><th>Recommended</th><th>Reference</th
Value,DTLS-OK,Recommended,Reference ></tr></thead>
EXPORTER: teap session key seed,N,Y,[THIS-DOCUMENT] <tbody><tr><td>EXPORTER: teap session key seed</td><td>N</td><td>Y</td><td>RFC
]]></artwork> 9930</td></tr></tbody>
</table>
</section> </section>
<section anchor="extended-master-session-key-emsk-parameters"> <section anchor="extended-master-session-key-emsk-parameters">
<name>Extended Master Session Key (EMSK) Parameters</name> <name>Extended Master Session Key (EMSK) Parameters</name>
<t>IANA is instructed to update the "User Specific Root Keys (USRK) Key <t>IANA has updated the "User Specific Root Keys (USRK) Key Labels" regi
Labels" registry to change the Reference field for Value "TEAPbindkey@ietf.org" stry to change the Reference field for Value "TEAPbindkey@ietf.org" as follows:<
as follows:</t> /t>
<artwork><![CDATA[ <table>
Value,Description,Reference <thead><tr><th>Label</th><th>Description</th><th>Reference</th></tr></thead>
TEAPbindkey@ietf.org,TEAP binding usage label,[THIS-DOCUMENT] <tbody><tr><td>TEAPbindkey@ietf.org</td><td>TEAP binding usage label</td><td>R
]]></artwork> FC 9930</td></tr></tbody>
</table>
</section> </section>
<section anchor="extensible-authentication-protocol-eap-registry"> <section anchor="extensible-authentication-protocol-eap-registry">
<name>Extensible Authentication Protocol (EAP) Registry</name> <name>Extensible Authentication Protocol (EAP) Registry</name>
<t>IANA is instructed to update the "Method Types" registry to change th <t>IANA has updated the "Method Types" registry to change the Reference
e Reference field for Value "55" as follows:</t> field for Value "55" as follows:</t>
<artwork><![CDATA[ <table>
Value,Description,Reference <thead><tr><th>Value</th><th>Description</th><th>Reference</th></tr></thead>
55,TEAP,[THIS-DOCUMENT] <tbody><tr><td>55</td><td>TEAP</td><td>RFC 9930</td></tr></tbody>
]]></artwork> </table>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>TEAP is designed with a focus on wireless media, where the medium <t>TEAP is designed with a focus on wireless media, where the medium
itself is inherent to eavesdropping. Whereas in wired media an itself is inherent to eavesdropping. Whereas in wired media an
attacker would have to gain physical access to the wired medium, attacker would have to gain physical access to the wired medium,
wireless media enables anyone to capture information as it is wireless media enables anyone to capture information as it is
transmitted over the air, enabling passive attacks. Thus, physical transmitted over the air, enabling passive attacks. Thus, physical
security can not be assumed, and security vulnerabilities are far security can not be assumed, and security vulnerabilities are far
skipping to change at line 3648 skipping to change at line 3457
<name>Mutual Authentication and Integrity Protection</name> <name>Mutual Authentication and Integrity Protection</name>
<t>As a whole, TEAP provides message and integrity protection by <t>As a whole, TEAP provides message and integrity protection by
establishing a secure tunnel for protecting the inner establishing a secure tunnel for protecting the inner
method(s). The confidentiality and integrity protection is defined method(s). The confidentiality and integrity protection is defined
by TLS and provides the same security strengths afforded by TLS by TLS and provides the same security strengths afforded by TLS
employing a strong entropy shared master secret. The integrity of employing a strong entropy shared master secret. The integrity of
the key generating inner methods executed within the TEAP the key generating inner methods executed within the TEAP
tunnel is verified through the calculation of the Crypto-Binding TLV. tunnel is verified through the calculation of the Crypto-Binding TLV.
This ensures that the tunnel endpoints are the same as the inner This ensures that the tunnel endpoints are the same as the inner
method endpoints.</t> method endpoints.</t>
<t>Where Server Unauthenticated Provisioning is performed, TEAP requires <t>Where server unauthenticated provisioning is performed, TEAP requires
that the inner provisioning method provide for both peer and server authenticati on.</t> that the inner provisioning method provide for both peer and server authenticati on.</t>
</section> </section>
<section anchor="method-negotiation"> <section anchor="method-negotiation">
<name>Method Negotiation</name> <name>Method Negotiation</name>
<t>As is true for any negotiated EAP protocol, EAP NAK message used to <t>As is true for any negotiated EAP protocol, EAP NAK messages used to
suggest an alternate EAP authentication method are sent unprotected and, suggest an alternate EAP authentication method are sent unprotected and,
as such, are subject to spoofing. During unprotected EAP method as such, are subject to spoofing. During unprotected EAP method
negotiation, NAK packets may be interjected as active attacks to negotiation, NAK packets may be interjected as active attacks to
bid-down to a weaker form of authentication, such as EAP-MD5 bid-down to a weaker form of authentication, such as EAP-MD5
(which only provides one-way authentication and does not derive a (which only provides one-way authentication and does not derive a
key). Both the peer and server should have a method selection policy key). Both the peer and server should have a method selection policy
that prevents them from negotiating down to weaker methods. Inner that prevents them from negotiating down to weaker methods. Inner
method negotiation resists attacks because it is protected by the method negotiation resists attacks because it is protected by the
mutually authenticated TLS tunnel established. Selection of TEAP as mutually authenticated TLS tunnel established. Selection of TEAP as
an authentication method does not limit the potential inner an authentication method does not limit the potential inner
methods, so TEAP should be selected when available.</t> methods, so TEAP should be selected when available.</t>
<t>An attacker cannot readily determine the inner method used, <t>An attacker cannot readily determine the inner method used,
except perhaps by traffic analysis. It is also important that peer except perhaps by traffic analysis. It is also important that peer
implementations limit the use of credentials with an unauthenticated implementations limit the use of credentials with an unauthenticated
or unauthorized server.</t> or unauthorized server.</t>
</section> </section>
<section anchor="separation-p1-p2"> <section anchor="separation-p1-p2">
<name>Separation of Phase 1 and Phase 2 Servers</name> <name>Separation of Phase 1 and Phase 2 Servers</name>
<t>Separation of the TEAP Phase 1 from the Phase 2 conversation is NOT <t>Separation of the TEAP Phase 1 from the Phase 2 conversation is
RECOMMENDED. Allowing the Phase 1 conversation to be terminated at a <bcp14>NOT RECOMMENDED</bcp14>. Allowing the Phase 1 conversation to be
terminated at a
different server than the Phase 2 conversation can introduce different server than the Phase 2 conversation can introduce
vulnerabilities if there is not a proper trust relationship and vulnerabilities if there is not a proper trust relationship and
protection for the protocol between the two servers. Some protection for the protocol between the two servers. Some
vulnerabilities include:</t> vulnerabilities include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Loss of identity protection</t> <t>Loss of identity protection</t>
</li> </li>
<li> <li>
<t>Offline dictionary attacks</t> <t>Offline dictionary attacks</t>
</li> </li>
<li> <li>
<t>Lack of policy enforcement</t> <t>Lack of policy enforcement</t>
</li> </li>
<li> <li>
<t>on-path active attacks (as described in <xref target="RFC7029"/>) </t> <t>On-path active attacks (as described in <xref target="RFC7029"/>) </t>
</li> </li>
</ul> </ul>
<t>There may be cases where a trust relationship exists between the <t>There may be cases where a trust relationship exists between the
Phase 1 and Phase 2 servers, such as on a campus or between two Phase 1 and Phase 2 servers, such as on a campus or between two
offices within the same company, where there is no danger in offices within the same company, where there is no danger in
revealing the inner identity and credentials of the peer to entities revealing the inner identity and credentials of the peer to entities
between the two servers. In these cases, using a proxy solution between the two servers. In these cases, using a proxy solution
without end-to-end protection of TEAP MAY be used. The TEAP without end-to-end protection of TEAP <bcp14>MAY</bcp14> be used. The TEAP
encrypting/decrypting gateway MUST, at a minimum, provide support for encrypting/decrypting gateway <bcp14>MUST</bcp14>, at a minimum, provide support
for
IPsec, TLS, or similar protection in order to provide confidentiality IPsec, TLS, or similar protection in order to provide confidentiality
for the portion of the conversation between the gateway and the EAP for the portion of the conversation between the gateway and the EAP
server. In addition, separation of the TEAP server and Inner servers server. In addition, separation of the TEAP servers and Inner servers
allows for crypto-binding based on the inner method MSK to be allows for crypto-binding based on the inner method MSK to be
thwarted as described in <xref target="RFC7029"/>. thwarted as described in <xref target="RFC7029"/>.
If the inner method derives an EMSK, then this threat is mitigated as If the inner method derives an EMSK, then this threat is mitigated as
TEAP uses the Crypto-Binding TLV tie the inner EMSK to the TLS session via the T TEAP uses the Crypto-Binding TLV to tie the inner EMSK to the TLS session via th
LS-PRF, as described above in <xref target="cryptographic-calculations"/>.</t> e TLS-PRF, as described above in <xref target="cryptographic-calculations"/>.</t
<t>On the other hand, if the inner method is not deriving EMSK as with >
<t>On the other hand, if the inner method is not deriving EMSK, as with
password authentication or unauthenticated provisioning, then this password authentication or unauthenticated provisioning, then this
threat still exists. Implementations therefore need to limit the use of threat still exists. Implementations therefore need to limit the use of
inner methods as discussed above in <xref target="inner-method-limitations"/></t > inner methods as discussed above in <xref target="inner-method-limitations"/></t >
</section> </section>
<section anchor="mitigation-of-known-vulnerabilities-and-protocol-deficien cies"> <section anchor="mitigation-of-known-vulnerabilities-and-protocol-deficien cies">
<name>Mitigation of Known Vulnerabilities and Protocol Deficiencies</nam e> <name>Mitigation of Known Vulnerabilities and Protocol Deficiencies</nam e>
<t>TEAP addresses the known deficiencies and weaknesses in some EAP <t>TEAP addresses the known deficiencies and weaknesses in some EAP
authentication methods. By employing a shared secret between the peer and serve r to authentication methods. By employing a shared secret between the peer and serve r to
establish a secured tunnel, TEAP enables:</t> establish a secured tunnel, TEAP enables:</t>
<!-- [rfced] Should "EAP method" be plural?
Current:
Protected inner method negotiation, including EAP method
Perhaps:
Protected inner method negotiation, including EAP methods
-->
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Per-packet confidentiality and integrity protection</t> <t>Per-packet confidentiality and integrity protection</t>
</li> </li>
<li> <li>
<t>User identity protection</t> <t>User identity protection</t>
</li> </li>
<li> <li>
<t>Better support for notification messages</t> <t>Better support for notification messages</t>
</li> </li>
skipping to change at line 3770 skipping to change at line 3587
credential-based inner method. The protection is based on credential-based inner method. The protection is based on
strong cryptographic algorithms in TLS to provide message strong cryptographic algorithms in TLS to provide message
confidentiality and integrity. The keys derived for the protection confidentiality and integrity. The keys derived for the protection
relies on strong random challenges provided by both peer and server relies on strong random challenges provided by both peer and server
as well as an established key with strong entropy. Implementations as well as an established key with strong entropy. Implementations
should follow the recommendation in <xref target="RFC4086"/> when generating ran dom should follow the recommendation in <xref target="RFC4086"/> when generating ran dom
numbers.</t> numbers.</t>
<section anchor="user-identity-protection-and-verification"> <section anchor="user-identity-protection-and-verification">
<name>User Identity Protection and Verification</name> <name>User Identity Protection and Verification</name>
<t>The initial identity request response exchange is sent in cleartext <t>The initial identity request response exchange is sent in cleartext
outside the protection of TEAP. Typically, the Network Access outside the protection of TEAP. Typically, the NAI <xref target="RFC7542"/> in
Identifier (NAI) <xref target="RFC7542"/> in the identity response is useful onl the identity response is useful only
y
for the realm of information that is used to route the authentication for the realm of information that is used to route the authentication
requests to the right EAP server. This means that the identity requests to the right EAP server. This means that the identity
response may contain an anonymous identity and just contain realm response may contain an anonymous identity and just contain realm
information. In other cases, the identity exchange may be eliminated information. In other cases, the identity exchange may be eliminated
altogether if there are other means for establishing the destination altogether if there are other means for establishing the destination
realm of the request. In no case should an intermediary place any realm of the request. In no case should an intermediary place any
trust in the identity information in the identity response since it trust in the identity information in the identity response since it
is unauthenticated and may not have any relevance to the is unauthenticated and may not have any relevance to the
authenticated identity. TEAP implementations should not attempt to authenticated identity. TEAP implementations should not attempt to
compare any identity disclosed in the initial cleartext EAP Identity compare any identity disclosed in the initial cleartext EAP Identity
response packet with those Identities authenticated in Phase 2.</t> response packet with those Identities authenticated in Phase 2.</t>
<t>When the server is authenticated, identity request/response exchang es <t>When the server is authenticated, identity request/response exchang es
sent after the TEAP tunnel is established are protected from sent after the TEAP tunnel is established are protected from
modification and eavesdropping by attackers. For server modification and eavesdropping by attackers. For server
unauthenticated provisioning, the outer TLS session provides little unauthenticated provisioning, the outer TLS session provides little
security, and the provisioning method must necessarily provide this security, and the provisioning method must provide this
protection instead.</t> protection instead.</t>
<t>When a client certificate is sent outside of the TLS tunnel in Phas e <t>When a client certificate is sent outside of the TLS tunnel in Phas e
1, the peer MUST include Identity-Type as an outer TLV, in order to 1, the peer <bcp14>MUST</bcp14> include Identity-Type as an outer TLV in order t o
signal the type of identity which that client certificate is for. signal the type of identity which that client certificate is for.
Further, when a client certificate is sent outside of the TLS tunnel, Further, when a client certificate is sent outside of the TLS tunnel,
the server MUST proceed with Phase 2. If there is no Phase 2 data, the server <bcp14>MUST</bcp14> proceed with Phase 2. If there is no Phase 2 dat
then the EAP server MUST reject the session.</t> a,
then the EAP server <bcp14>MUST</bcp14> reject the session.</t>
<t>Issues related to confidentiality of a client certificate are <t>Issues related to confidentiality of a client certificate are
discussed above in <xref target="client-certs-phase1"/></t> discussed above in <xref target="client-certs-phase1"/></t>
<t>Note that the Phase 2 data could simply be a Result TLV with value <t>Note that the Phase 2 data could simply be a Result TLV with value
Success, along with a Crypto-Binding TLV. Success, along with a Crypto-Binding TLV.
This Phase 2 data serves as a protected success indication as This Phase 2 data serves as a protected success indication as
discussed in <xref section="2.1.1" sectionFormat="comma" target="RFC9190"/></t> discussed in <xref section="2.1.1" sectionFormat="comma" target="RFC9190"/></t>
</section> </section>
</section> </section>
<section anchor="dictionary-attack-resistance"> <section anchor="dictionary-attack-resistance">
<name>Dictionary Attack Resistance</name> <name>Dictionary Attack Resistance</name>
<t>TEAP was designed with a focus on protected inner methods <t>TEAP was designed with a focus on protected inner methods
that typically rely on weak credentials, such as password-based that typically rely on weak credentials, such as password-based
secrets. TEAP mitigates offline dictionary attacks by allowing the secrets. TEAP mitigates offline dictionary attacks by allowing the
establishment of a mutually authenticated encrypted TLS tunnel establishment of a mutually authenticated encrypted TLS tunnel
providing confidentiality and integrity to protect the weak providing confidentiality and integrity to protect the weak
credential-based inner method.</t> credential-based inner method.</t>
<t>TEAP mitigates dictionary attacks by permitting inner methods such as <t>TEAP mitigates dictionary attacks by permitting inner methods, such a
EAP-pwd which are not vulnerable to dictionary attacks.</t> s
EAP-pwd, that are not vulnerable to dictionary attacks.</t>
<t>TEAP implementations can mitigate online "brute force" <t>TEAP implementations can mitigate online "brute force"
dictionary attempts by limiting the number of failed authentication dictionary attempts by limiting the number of failed authentication
attempts for a particular identity.</t> attempts for a particular identity.</t>
<section anchor="protection-against-on-path-attacks"> <section anchor="protection-against-on-path-attacks">
<name>Protection against On-Path Attacks</name> <name>Protection Against On-Path Attacks</name>
<t>TEAP provides protection from on-path attacks in a few ways:</t> <t>TEAP provides protection from on-path attacks in a few ways:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>By using a certificates or a session ticket to mutually <t>By using a certificates or a session ticket to mutually
authenticate the peer and server during TEAP authentication Phase 1 authenticate the peer and server during TEAP authentication Phase 1
establishment of a secure TLS tunnel.</t> establishment of a secure TLS tunnel.</t>
</li> </li>
<li> <li>
<t>When the TLS tunnel is not secured, by using the keys generated by the inner method <t>When the TLS tunnel is not secured, by using the keys generated by the inner method
(if the inner methods are key generating) in the crypto-binding (if the inner methods are key generating) in the crypto-binding
exchange and in the generation of the key material exported by exchange and in the generation of the key material exported by
skipping to change at line 3852 skipping to change at line 3668
based on Diffie-Hellman), then crypto binding can detect an attacker based on Diffie-Hellman), then crypto binding can detect an attacker
in the conversation if a strong inner method is used.</t> in the conversation if a strong inner method is used.</t>
<t>TEAP crypto binding does not guarantee protection from on-path atta cks <t>TEAP crypto binding does not guarantee protection from on-path atta cks
when the client does not verify the server, and the inner method does when the client does not verify the server, and the inner method does
not produce an EMSK. The only way to close this vulnerability is to not produce an EMSK. The only way to close this vulnerability is to
define TEAPv2, which would then have different crypto binding define TEAPv2, which would then have different crypto binding
derivations.</t> derivations.</t>
</section> </section>
</section> </section>
<section anchor="protecting-against-forged-cleartext-eap-packets"> <section anchor="protecting-against-forged-cleartext-eap-packets">
<name>Protecting against Forged Cleartext EAP Packets</name> <name>Protecting Against Forged Cleartext EAP Packets</name>
<t>EAP Success and EAP Failure packets are, in general, sent in <t>EAP Success and EAP Failure packets are, in general, sent in
cleartext and may be forged by an attacker without detection. Forged cleartext and may be forged by an attacker without detection. Forged
EAP Failure packets can be used to attempt to convince an EAP peer to EAP Failure packets can be used to attempt to convince an EAP peer to
disconnect. Forged EAP Success packets may be used to attempt to disconnect. Forged EAP Success packets may be used to attempt to
convince a peer that authentication has succeeded, even though the convince a peer that authentication has succeeded, even though the
authenticator has not authenticated itself to the peer.</t> authenticator has not authenticated itself to the peer.</t>
<t>By providing message confidentiality and integrity, TEAP provides <t>By providing message confidentiality and integrity, TEAP provides
protection against these attacks. Once the peer and authentication protection against these attacks. Once the peer and authentication server (AS)
server (AS) initiate the TEAP authentication Phase 2, compliant TEAP initiate the TEAP authentication Phase 2, compliant TEAP
implementations MUST silently discard all cleartext EAP messages, implementations <bcp14>MUST</bcp14> silently discard all cleartext EAP messages,
unless both the TEAP peer and server have indicated success or unless both the TEAP peer and server have indicated success or
failure using a protected mechanism. Protected mechanisms include failure using a protected mechanism. Protected mechanisms include
the TLS alert mechanism and the protected termination mechanism the TLS alert mechanism and the protected termination mechanism
described in <xref target="protected-termination"/>.</t> described in <xref target="protected-termination"/>.</t>
<t>The success/failure decisions within the TEAP tunnel indicate the <t>The success/failure decisions within the TEAP tunnel indicate the
final decision of the TEAP authentication conversation. After a final decision of the TEAP authentication conversation. After a
success/failure result has been indicated by a protected mechanism, success/failure result has been indicated by a protected mechanism,
the TEAP peer can process unprotected EAP Success and EAP Failure the TEAP peer can process unprotected EAP Success and EAP Failure
messages; however, the peer MUST ignore any unprotected EAP Success messages; however, the peer <bcp14>MUST</bcp14> ignore any unprotected EAP Succe ss
or Failure messages where the result does not match the result of the or Failure messages where the result does not match the result of the
protected mechanism.</t> protected mechanism.</t>
<t>To abide by <xref target="RFC3748"/>, the server sends a cleartext EA P Success or <t>To abide by <xref target="RFC3748"/>, the server sends a cleartext EA P Success or
EAP Failure packet to terminate the EAP conversation. However, since EAP Failure packet to terminate the EAP conversation. However, since
EAP Success and EAP Failure packets are not retransmitted, the final EAP Success and EAP Failure packets are not retransmitted, the final
packet may be lost. While a TEAP-protected EAP Success or EAP packet may be lost. While a TEAP-protected EAP Success or EAP
Failure packet should not be a final packet in a TEAP conversation, Failure packet should not be a final packet in a TEAP conversation,
it may occur based on the conditions stated above, so an EAP peer it may occur based on the conditions stated above, so an EAP peer
should not rely upon the unprotected EAP Success and Failure should not rely upon the unprotected EAP Success and Failure
messages.</t> messages.</t>
</section> </section>
<section anchor="use-of-clear-text-passwords"> <section anchor="use-of-clear-text-passwords">
<name>Use of Clear-text Passwords</name> <name>Use of Cleartext Passwords</name>
<t>TEAP can carry clear-text passwords in the Basic-Password-Auth-Resp <t>TEAP can carry cleartext passwords in the Basic-Password-Auth-Resp
TLV. Implementations should take care to protect this data. For TLV. Implementations should take care to protect this data. For
example, passwords should not normally be logged, and password data example, passwords should not normally be logged, and password data
should be securely scrubbed from memory when it is no longer needed.</t> should be securely scrubbed from memory when it is no longer needed.</t>
</section> </section>
<section anchor="accidental-or-unintended-behavior"> <section anchor="accidental-or-unintended-behavior">
<name>Accidental or Unintended Behavior</name> <name>Accidental or Unintended Behavior</name>
<t>Due to the complexity of TEAP, and the long time between <xref target ="RFC7170"/> <t>Due to the complexity of TEAP, and the long time between <xref target ="RFC7170"/>
and any substantial implementation, there are many accidental or and any substantial implementation, there are many accidental or
unintended behaviors in the protocol.</t> unintended behaviors in the protocol.</t>
<t>The first one is that EAP-FAST-MSCHAPv2 is used instead of <t>The first one is that EAP-FAST-MSCHAPv2 is used instead of
EAP-MSCHAPv2. While <xref target="RFC7170"/> defined TEAP to use EAP-MSCHAPv2, an EAP-MSCHAPv2. While <xref target="RFC7170"/> defined TEAP to use EAP-MSCHAPv2, an
early implementor or implementors instead used EAP-FAST-MSCHAPv2. The early implementor or implementors instead used EAP-FAST-MSCHAPv2. The
choice for this document was either to define a new version of TEAP choice for this document was either to define a new version of TEAP
which used EAP-MSCHAPv2, or instead to document implemented behavior. that used EAP-MSCHAPv2 or instead to document implemented behavior.
The choice taken here was to document running code.</t> The choice taken here was to document running code.</t>
<t>The issues discussed in <xref target="oops"/> could have security imp acts, but no <t>The issues discussed in <xref target="oops"/> could have security imp acts, but no
analysis has been performed. The choice of using a special "all zero" analysis has been performed. The choice of using a special "all zero"
IMSK in <xref target="intermediate-compound-key"/> was made for simplicity, but could IMSK in <xref target="intermediate-compound-key"/> was made for simplicity but c ould
also have negative security impacts.</t> also have negative security impacts.</t>
<t>The definition of the Crypto-Binding TLV means that it the final <t>The definition of the Crypto-Binding TLV means that the final
Crypto-Binding TLV values might not depend on all previous values of Crypto-Binding TLV values might not depend on all previous values of
MSK and EMSK. This limitation could have negative security impacts, MSK and EMSK. This limitation could have negative security impacts,
but again no analysis has been performed.</t> but again, no analysis has been performed.</t>
<t>We suggest that the TEAP protocol be revised to TEAP version 2, which <t>We suggest that the TEAP protocol be revised to TEAP version 2, which
could address these issues. There are proposals at this time to could address these issues. There are proposals at this time to
better derive the various keying materials and cryptographic binding better derive the various keying materials and cryptographic binding
derivations. However, in the interest of documenting running code, we derivations. However, in the interest of documenting running code, we
are publishing this document with the acknowledgement that there are are publishing this document with the acknowledgment that there are
improvements to be made.</t> improvements to be made.</t>
</section> </section>
<section anchor="implicit-challenge"> <section anchor="implicit-challenge">
<name>Implicit Challenge</name> <name>Implicit Challenge</name>
<t>Certain authentication protocols that use a challenge/response <t>Certain authentication protocols that use a challenge/response
mechanism rely on challenge material that is not generated by the mechanism rely on challenge material that is not generated by the
authentication server, and therefore the material may require special authentication server; therefore, the material may require special
handling. For EAP-TTLS, these challenges are defined in <xref section="11.1" se ctionFormat="comma" target="RFC5281"/>.</t> handling. For EAP-TTLS, these challenges are defined in <xref section="11.1" se ctionFormat="comma" target="RFC5281"/>.</t>
<t>In EAP-MSCHAPv2, the authenticator issues a challenge to the <t>In EAP-MSCHAPv2, the authenticator issues a challenge to the
supplicant, the supplicant then hashes the challenge with the password supplicant. Then, the supplicant hashes the challenge with the password
and forwards the response to the authenticator. The response also and forwards the response to the authenticator. The response also
includes a Peer-Challenge, which is created by the supplicant. Since includes a Peer-Challenge, which is created by the supplicant. Since
the challenge is random, it is not associated with the TLS tunnel, and the challenge is random, it is not associated with the TLS tunnel and
the protocol may be susceptible to a replay attack.</t> the protocol may be susceptible to a replay attack.</t>
<t>The Crypto-Binding TLV provides protection against intermediaries, bu t <t>The Crypto-Binding TLV provides protection against intermediaries, bu t
it does not provide protection against a replay attack. We suggest it does not provide protection against a replay attack. We suggest
that any TEAPv2 specification correct this issue.</t> that any TEAPv2 specification correct this issue.</t>
</section> </section>
<section anchor="security-claims"> <section anchor="security-claims">
<name>Security Claims</name> <name>Security Claims</name>
<t>This section provides the needed security claim requirement for EAP <t>This section provides the needed security claim requirement for EAP
<xref target="RFC3748"/>.</t> <xref target="RFC3748"/>.</t>
<artwork><![CDATA[ <dl spacing="normal" newline="false">
Auth. mechanism: Certificate-based, shared-secret-based, and <dt>Auth. mechanism:</dt><dd> Certificate-based, shared-secret-based, an
various tunneled authentication mechanisms. d
various tunneled authentication mechanisms.</dd>
Cipher Suite negotiation: Yes <dt>Cipher Suite negotiation:</dt><dd>Yes</dd>
Mutual authentication: Yes <dt>Mutual authentication:</dt><dd> Yes</dd>
Integrity protection: Yes. Any method executed within the TEAP <dt>Integrity protection:</dt><dd> Yes. Any method executed within the TEAP
tunnel is integrity protected. The tunnel is integrity protected. The
cleartext EAP headers outside the tunnel are cleartext EAP headers outside the tunnel are
not integrity protected. Server not integrity protected. Server
unauthenticated provisioning provides its own unauthenticated provisioning provides its own
protection mechanisms. protection mechanisms.</dd>
Replay protection: Yes <dt>Replay protection:</dt><dd> Yes</dd>
Confidentiality: Yes <dt>Confidentiality:</dt><dd> Yes</dd>
Key derivation: Yes <dt>Key derivation:</dt><dd> Yes</dd>
Key strength: See Note 1 below. <dt>Key strength:</dt><dd> See Note 1 below.</dd>
Dictionary attack prot.: See Note 2 below. <dt>Dictionary attack prot.:</dt><dd> See Note 2 below.</dd>
Fast reconnect: Yes <dt>Fast reconnect:</dt><dd> Yes</dd>
Cryptographic binding: Yes <dt>Cryptographic binding:</dt><dd> Yes</dd>
Session independence: Yes <dt>Session independence:</dt><dd> Yes</dd>
Fragmentation: Yes <dt>Fragmentation:</dt><dd> Yes</dd>
Key Hierarchy: Yes <dt>Key Hierarchy:</dt><dd> Yes</dd>
Channel binding: Yes <dt>Channel binding:</dt><dd> Yes</dd>
]]></artwork> </dl>
<t>Notes</t>
<t>Note 1. BCP 86 <xref target="RFC3766"/> offers advice on appropriate <t>Notes:</t>
key sizes. The <!-- [rfced] Should this citation be to BCP 86 or RFC 3766?
National Institute for Standards and Technology (NIST) also
offers advice on appropriate key sizes in <xref target="NIST-SP-800-57"/>. Current:
<xref target="RFC3766"/>, <xref target="cryptographic-calculations"/> advises us Note 1. BCP 86 [RFC3766] offers advice on appropriate key sizes. The
e of the following required RSA or National Institute for Standards and Technology (NIST) also offers
DH (Diffie-Hellman) module and DSA (Digital Signature Algorithm) advice on appropriate key sizes in [NIST-SP-800-57].
subgroup size in bits for a given level of attack resistance in -->
bits. Based on the table below, a 2048-bit RSA key is required
to provide 112-bit equivalent key strength:</t> <!-- [rfced] It is unclear to us if the citations in the following
<artwork><![CDATA[ sentence are meant to point to Section 6 of RFC 3766 or to both RFC 3766
Attack Resistance RSA or DH Modulus DSA subgroup and Section 6 of this document (current). We have left the citations as
(bits) size (bits) size (bits) is. Please review and let us know how the citations may be updated for
----------------- ----------------- ------------ clarity.
70 947 129
80 1228 148 Current:
90 1553 167 [RFC3766], Section 6 advises use of the following required RSA or DH
100 1926 186 (Diffie-Hellman) module and DSA (Digital Signature Algorithm) subgroup
150 4575 284 size in bits for a given level of attack resistance in bits.
200 8719 383 -->
250 14596 482 <ul spacing="normal">
]]></artwork> <li><t>Note 1. BCP 86 <xref target="RFC3766"/> offers advice on appropriate
<t>Note 2. TEAP protects against offline dictionary attacks when secure key sizes. The National Institute for Standards and Technology (NIST) also
inner offers advice on appropriate key sizes in <xref target="NIST-SP-800-57"/>.
methods are used. TEAP protects against online dictionary attacks by <xref target="RFC3766"/>, <xref target="cryptographic-calculations"/>
limiting the number of failed authentications for a particular advises use of the following required RSA or Diffie-Hellman (DH) module and
identity.</t> Digital Signature Algorithm (DSA) subgroup size in bits for a given level of
attack resistance in bits. Based on the table below, a 2048-bit RSA key is
required to provide 112-bit equivalent key strength:</t>
<table>
<thead><tr><th>Attack Resistance (bits)</th><th>RSA or DH Modulus size (bits)<
/th><th>DSA subgroup size (bits)</th></tr></thead>
<tbody>
<tr><td>70</td><td> 947</td><td>
129</td></tr>
<tr><td>80</td><td> 1228</td><td>
148</td></tr>
<tr><td>90</td><td> 1553</td><td>
167</td></tr>
<tr><td>100</td><td> 1926</td><td>
186</td></tr>
<tr><td>150</td><td> 4575</td><td>
284</td></tr>
<tr><td>200</td><td> 8719</td><td>
383</td></tr>
<tr><td>250</td><td> 14596</td><td>
482</td></tr>
</tbody>
</table>
</li>
<li><t>Note 2. TEAP protects against offline dictionary attacks when secure
inner methods are used. TEAP protects against online dictionary attacks by
limiting the number of failed authentications for a particular identity.</t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="acknowledgments"> <!-- [rfced] May we move the "Changes from RFC 7170" section to the
<name>Acknowledgments</name> Appendix?
<t>Nearly all of the text in this document was taken directly from -->
<xref target="RFC7170"/>. We are grateful to the original authors and reviewers
for
that document. The acknowledgments given here are only for the
changes which resulted in this document.</t>
<t>Alexander Clouter provided substantial and detailed technical feedback
on nearly every aspect of the specification. The corrections in this
document are based on his work.</t>
<t>We wish to thank the many reviewers and commenters in the EMU WG,
including Eliot Lear, Joe Salowey, Heikki Vatiainen,
Bruno Pereria Vidal, and Michael Richardson. Many corner cases and
edge conditions were caught and corrected as a result of their
feedback.</t>
<t>Jouni Malinin initially pointed out the issues with RFC 7170. Those
comments resulted in substantial discussion on the EMU WG mailing
list, and eventually this document. Jouni also made substantial
contributions in analyzing corner cases, which resulted in the text in
<xref target="oops"/>.</t>
</section>
<section anchor="changes-from-rfc-7170"> <section anchor="changes-from-rfc-7170">
<name>Changes from RFC 7170</name> <name>Changes from RFC 7170</name>
<t>Alan DeKok was added as editor.</t> <t>Alan DeKok was added as an editor.</t>
<t>The document was converted to Markdown, from the <xref target="RFC7170" <!-- [rfced] May we update the following text for conciseness?
/> text output.</t>
Original:
The document was converted to Markdown, from the [RFC7170] text
output.
Any formatting changes mostly result from differences between using
Markdown versus XML for source.
Perhaps:
Any formatting changes from [RFC7170] may have resulted from changing
from XML to Markdown as the source file when editing the draft
-->
<t> The document was converted to Markdown from the [RFC7170] text output.</t>
<t>Any formatting changes mostly result from differences between using Mar kdown <t>Any formatting changes mostly result from differences between using Mar kdown
versus XML for source.</t> versus XML for source.</t>
<t>The IANA considerations section was replaced with a note to change the <t>The IANA Considerations section was replaced with a note to change the
IANA registry references to this document.</t> IANA registry references to this document.</t>
<t>A new section was added to explain that the inner EAP-MSCHAPv2 <t>A new section was added to explain that the inner EAP-MSCHAPv2
derivation follows EAP-FAST. This is the largest technical change derivation follows EAP-FAST. This is the largest technical change
from the previous revision of this document, and follows existing implementation s.</t> from the previous revision of this document and follows existing implementations .</t>
<t>Many small changes have been made throughout the document to correct <t>Many small changes have been made throughout the document to correct
inconsistencies, and to address mistakes. At a high level:</t> inconsistencies and to address mistakes. At a high level:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>All open errata have been addressed.</t> <t>All open errata have been addressed.</t>
</li> </li>
<li> <li>
<t>A new term "inner method" has been defined.</t> <t>A new term "inner method" has been defined.</t>
</li> </li>
<li> <li>
<t>The definitions and derivation of IMSK, S-IMCK, etc. have been corr ected and clarified.</t> <t>The definitions and derivation of IMSK, S-IMCK, etc. have been corr ected and clarified.</t>
</li> </li>
<li> <li>
<t>The diagrams in Appendix C have been updated to match the TEAP stat e machine</t> <t>The diagrams in <xref target="appendix-c-examples"/> have been upda ted to match the TEAP state machine.</t>
</li> </li>
</ul> </ul>
<t>All uses of the PAC were removed. It had not been implemented, and <t>All uses of the PAC were removed. It had not been implemented, and
there were no plans by implementors to use it.</t> there were no plans by implementors to use it.</t>
<t>Text was added on recommendations for inner and outer identities.</t> <t>Text was added on recommendations for inner and outer identities.</t>
<t><xref target="oops"/> was added late in the document life cycle, in ord <t><xref target="oops"/> was added late in the document life cycle in orde
er to r to
document accidental behavior which could result in interability document accidental behavior that could result in interoperability
issues.</t> issues.</t>
</section> </section>
<section numbered="false" anchor="appendix-a-evaluation-against-tunnel-based
-eap-method-requirements"> </middle>
<name>Appendix A Evaluation against Tunnel-Based EAP Method Requirements</ <back>
name> <displayreference target="I-D.kamath-pppext-eap-mschapv2" to="KAMATH"/>
<references anchor="sec-combined-references">
<name>References</name>
<!-- [rfced] References
a) FYI: We've added URLs for the following references and updated them
accordingly. Please review and let us know if you have any objections.
[IEEE.802-1X.2020]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Port-Based Network Access Control", IEEE Std
802.1X-2020, DOI 10.1109/IEEESTD.2020.9018454, February
2020, <https://doi.org/10.1109/IEEESTD.2020.9018454>.
[KAMATH] Kamath, V. and A. Palekar, "Microsoft EAP CHAP
Extensions", Work in Progress, Internet-Draft, draft-
kamath-pppext-eap-mschapv2-02, 19 June 2007,
<https://datatracker.ietf.org/doc/html/draft-kamath-
pppext-eap-mschapv2-02>.
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
Authentication Protocol (PEAP)", 24 June 2021,
<https://learn.microsoft.com/en-
us/openspecs/windows_protocols/ms-peap/5308642b-90c9-4cc4-
beec-fb367325c0f9>.
b) FYI: We've updated these reference to their most current versions.
Please review and let us know if you have any objections.
[NIST-SP-800-57]
Barker, E., "Recommendation for Key Management: Part 1 -
General", NIST SP 800-57 Part 1 Rev. 5,
DOI 10.6028/NIST.SP.800-57pt1r5, May 2020,
<https://doi.org/10.6028/NIST.SP.800-57pt1r5>.
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
Authentication Protocol (PEAP)", 24 June 2021,
<https://learn.microsoft.com/en-
us/openspecs/windows_protocols/ms-peap/5308642b-90c9-4cc4-
beec-fb367325c0f9>.
[X.690] ITU-T, "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", February 2021,
<https://www.itu.int/rec/T-REC-X.690>.
c) RFCs 5077, 5246, and 6961 have been obsoleted by RFC 8446. May we replace
them with RFC 8446? If they must be referenced, we suggest mentioning
RFC 8446 (e.g., RFC 6961 has been obsoleted by RFC 8446). See Section
4.8.6 in the RFC Style Guide (RFC 7322).
-->
<references anchor="sec-normative-references">
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
985.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
748.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
077.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
216.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
246.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
295.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
705.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
746.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
929.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
677.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
030.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
996.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
190.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
427.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
525.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.99
08.xml"/>
</references>
<references anchor="sec-informative-references">
<name>Informative References</name>
<reference anchor="IEEE.802-1X.2020">
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks--Port-
Based Network Access Control</title>
<author>
<organization>IEEE</organization>
</author>
<date month="2" year="2020"/>
</front>
<seriesInfo name="IEEE Std" value="802.1X-2020"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9018454"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.kamath-p
ppext-eap-mschapv2.xml"/>
<reference anchor="MSCHAP" target="https://learn.microsoft.com/en-us/ope
nspecs/windows_protocols/ms-chap/5a860bf5-2aeb-485b-82ee-fac1e8e6b76f">
<front>
<title>Master Session Key (MSK) Derivation</title>
<author>
<organization>Microsoft Corporation</organization>
</author>
<date day="23" month="4" year="2024"/>
</front>
</reference>
<reference anchor="NIST-SP-800-57">
<front>
<title>Recommendation for Key Management: Part 1 - General</title>
<author fullname="Elaine Barker"/>
<date year="2020" month="May"/>
</front>
<seriesInfo name="NIST SP" value="800-57 Part 1 Rev. 5"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/>
</reference>
<reference anchor="PEAP" target="https://learn.microsoft.com/en-us/opens
pecs/windows_protocols/ms-peap/5308642b-90c9-4cc4-beec-fb367325c0f9">
<front>
<title>[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP
)</title>
<author>
<organization>Microsoft Corporation</organization>
</author>
<date day="24" year="2021" month="June"/>
</front>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
315.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
579.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
629.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
766.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
017.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
072.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
086.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
648.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
851.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
945.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
962.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
247.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
272.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
280.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
281.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
421.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
422.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
652.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
931.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
066.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
124.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
678.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
960.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
961.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
029.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
170.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
542.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
325.xml"/>
<reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690">
<front>
<title>Information technology - ASN.1 encoding rules: Specification
of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER) </title>
<author>
<organization>ITU-T</organization>
</author>
<date year="2021" month="February"/>
</front>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
949.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
238.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
146.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
299.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
334.xml"/>
</references>
</references>
<section numbered="true" anchor="appendix-a-evaluation-against-tunnel-based-
eap-method-requirements">
<name>Evaluation Against Tunnel-Based EAP Method Requirements</name>
<t>This section evaluates all tunnel-based EAP method requirements <t>This section evaluates all tunnel-based EAP method requirements
described in <xref target="RFC6678"/> against TEAP version 1.</t> described in <xref target="RFC6678"/> against TEAP version 1.</t>
<section numbered="false" anchor="a1-requirement-411-rfc-compliance"> <section numbered="true" anchor="a1-requirement-411-rfc-compliance">
<name>A.1. Requirement 4.1.1: RFC Compliance</name> <name>Requirement 4.1.1: RFC Compliance</name>
<t>TEAPv1 meets this requirement by being compliant with RFC 3748 <t>TEAPv1 meets this requirement by being compliant with <xref target="R
<xref target="RFC3748"/>, RFC 4017 <xref target="RFC4017"/>, RFC 5247 <xref targ FC3748"/>, <xref target="RFC4017"/>, <xref target="RFC5247"/>, and <xref target=
et="RFC5247"/>, and RFC 4962 "RFC4962"/>. It is also compliant with the "cryptographic algorithm
<xref target="RFC4962"/>. It is also compliant with the "cryptographic algorith
m
agility" requirement by leveraging TLS 1.2 for all cryptographic agility" requirement by leveraging TLS 1.2 for all cryptographic
algorithm negotiation.</t> algorithm negotiation.</t>
</section> </section>
<section numbered="false" anchor="a2-requirement-421-tls-requirements"> <section numbered="true" anchor="a2-requirement-421-tls-requirements">
<name>A.2. Requirement 4.2.1: TLS Requirements</name> <name>Requirement 4.2.1: TLS Requirements</name>
<t>TEAPv1 meets this requirement by mandating TLS version 1.2 support as <t>TEAPv1 meets this requirement by mandating TLS version 1.2 support as
defined in <xref target="phase1"/>.</t> defined in <xref target="phase1"/>.</t>
</section> </section>
<section numbered="false" anchor="a3-requirement-42111-cipher-suite-negoti <section numbered="true" anchor="a3-requirement-42111-cipher-suite-negotia
ation"> tion">
<name>A.3. Requirement 4.2.1.1.1: Cipher Suite Negotiation</name> <name>Requirement 4.2.1.1.1: Cipher Suite Negotiation</name>
<t>TEAPv1 meets this requirement by using TLS to provide protected <t>TEAPv1 meets this requirement by using TLS to provide protected
cipher suite negotiation.</t> cipher suite negotiation.</t>
</section> </section>
<section numbered="false" anchor="a4-requirement-42112-tunnel-data-protect <section numbered="true" anchor="a4-requirement-42112-tunnel-data-protecti
ion-algorithms"> on-algorithms">
<name>A.4. Requirement 4.2.1.1.2: Tunnel Data Protection Algorithms</na <name>Requirement 4.2.1.1.2: Tunnel Data Protection Algorithms</name>
me>
<t>TEAPv1 meets this requirement by mandating cipher suites <t>TEAPv1 meets this requirement by mandating cipher suites
as defined in <xref target="phase1"/>.</t> as defined in <xref target="phase1"/>.</t>
</section> </section>
<section numbered="false" anchor="a5-requirement-42113-tunnel-authenticati <section numbered="true" anchor="a5-requirement-42113-tunnel-authenticatio
on-and-key-establishment"> n-and-key-establishment">
<name>A.5. Requirement 4.2.1.1.3: Tunnel Authentication and Key Establi <name>Requirement 4.2.1.1.3: Tunnel Authentication and Key Establishment
shment</name> </name>
<t>TEAPv1 meets this requirement by mandating cipher suites which only <t>TEAPv1 meets this requirement by mandating cipher suites that only
include cipher suites that use strong cryptographic algorithms. They include cipher suites that use strong cryptographic algorithms. They
do not include cipher suites providing mutually anonymous do not include cipher suites providing mutually anonymous
authentication or static Diffie-Hellman cipher suites as defined in authentication or static Diffie-Hellman cipher suites as defined in
<xref target="phase1"/>.</t> <xref target="phase1"/>.</t>
</section> </section>
<section numbered="false" anchor="a6-requirement-4212-tunnel-replay-protec <section numbered="true" anchor="a6-requirement-4212-tunnel-replay-protect
tion"> ion">
<name>A.6. Requirement 4.2.1.2: Tunnel Replay Protection</name> <name>Requirement 4.2.1.2: Tunnel Replay Protection</name>
<t>TEAPv1 meets this requirement by using TLS to provide sufficient <t>TEAPv1 meets this requirement by using TLS to provide sufficient
replay protection.</t> replay protection.</t>
</section> </section>
<section numbered="false" anchor="a7-requirement-4213-tls-extensions"> <section numbered="true" anchor="a7-requirement-4213-tls-extensions">
<name>A.7. Requirement 4.2.1.3: TLS Extensions</name> <name>Requirement 4.2.1.3: TLS Extensions</name>
<t>TEAPv1 meets this requirement by allowing TLS extensions, such as TLS <t>TEAPv1 meets this requirement by allowing TLS extensions, such as TLS
Certificate Status Request extension <xref target="RFC6066"/> and SessionTicket Certificate Status Request extension <xref target="RFC6066"/> and SessionTicket
extension <xref target="RFC5077"/>, to be used during TLS tunnel establishment.< /t> extension <xref target="RFC5077"/>, to be used during TLS tunnel establishment.< /t>
</section> </section>
<section numbered="false" anchor="a8-requirement-4214-peer-identity-privac <section numbered="true" anchor="a8-requirement-4214-peer-identity-privacy
y"> ">
<name>A.8. Requirement 4.2.1.4: Peer Identity Privacy</name> <name>Requirement 4.2.1.4: Peer Identity Privacy</name>
<t>TEAPv1 meets this requirement by establishment of the TLS tunnel and <t>TEAPv1 meets this requirement by establishment of the TLS tunnel and
protection identities specific to the inner method. In addition, the protection identities specific to the inner method. In addition, the
peer certificate can be sent confidentially (i.e., encrypted).</t> peer certificate can be sent confidentially (i.e., encrypted).</t>
</section> </section>
<section numbered="false" anchor="a9-requirement-4215-session-resumption"> <section numbered="true" anchor="a9-requirement-4215-session-resumption">
<name>A.9. Requirement 4.2.1.5: Session Resumption</name> <name>Requirement 4.2.1.5: Session Resumption</name>
<t>TEAPv1 meets this requirement by mandating support of TLS session <t>TEAPv1 meets this requirement by mandating support of TLS session
resumption as defined in <xref target="resume-server-state"/> and TLS session resumption as defined in <xref target="resume-server-state"/> and TLS session
resumption using the methods defined in <xref target="RFC9190"/></t> resumption using the methods defined in <xref target="RFC9190"/>.</t>
</section> </section>
<section numbered="false" anchor="a10-requirement-422-fragmentation"> <section numbered="true" anchor="a10-requirement-422-fragmentation">
<name>A.10. Requirement 4.2.2: Fragmentation</name> <name>Requirement 4.2.2: Fragmentation</name>
<t>TEAPv1 meets this requirement by leveraging fragmentation support <t>TEAPv1 meets this requirement by leveraging fragmentation support
provided by TLS as defined in <xref target="fragmentation"/>.</t> provided by TLS as defined in <xref target="fragmentation"/>.</t>
</section> </section>
<section numbered="false" anchor="a11-requirement-423-protection-of-data-e <section numbered="true" anchor="a11-requirement-423-protection-of-data-ex
xternal-to-tunnel"> ternal-to-tunnel">
<name>A.11. Requirement 4.2.3: Protection of Data External to Tunnel</n <name>Requirement 4.2.3: Protection of Data External to Tunnel</name>
ame>
<t>TEAPv1 meets this requirement by including the TEAP version number <t>TEAPv1 meets this requirement by including the TEAP version number
received in the computation of the Crypto-Binding TLV as defined in received in the computation of the Crypto-Binding TLV as defined in
<xref target="crypto-binding-tlv"/>.</t> <xref target="crypto-binding-tlv"/>.</t>
</section> </section>
<section numbered="false" anchor="a12-requirement-431-extensible-attribute <section numbered="true" anchor="a12-requirement-431-extensible-attribute-
-types"> types">
<name>A.12. Requirement 4.3.1: Extensible Attribute Types</name> <name>Requirement 4.3.1: Extensible Attribute Types</name>
<t>TEAPv1 meets this requirement by using an extensible TLV data layer <t>TEAPv1 meets this requirement by using an extensible TLV data layer
inside the tunnel as defined in <xref target="teap-tlv-format"/>.</t> inside the tunnel as defined in <xref target="teap-tlv-format"/>.</t>
</section> </section>
<section numbered="false" anchor="a13-requirement-432-requestchallenge-res <section numbered="true" anchor="a13-requirement-432-requestchallenge-resp
ponse-operation"> onse-operation">
<name>A.13. Requirement 4.3.2: Request/Challenge Response Operation</na <name>Requirement 4.3.2: Request/Challenge Response Operation</name>
me>
<t>TEAPv1 meets this requirement by allowing multiple TLVs to be sent in <t>TEAPv1 meets this requirement by allowing multiple TLVs to be sent in
a single EAP request or response packet, while maintaining the half-duplex a single EAP request or response packet, while maintaining the half-duplex
operation typical of EAP.</t> operation typical of EAP.</t>
</section> </section>
<section numbered="false" anchor="a14-requirement-433-indicating-criticali <section numbered="true" anchor="a14-requirement-433-indicating-criticalit
ty-of-attributes"> y-of-attributes">
<name>A.14. Requirement 4.3.3: Indicating Criticality of Attributes</na <name>Requirement 4.3.3: Indicating Criticality of Attributes</name>
me>
<t>TEAPv1 meets this requirement by having a mandatory bit in each TLV <t>TEAPv1 meets this requirement by having a mandatory bit in each TLV
to indicate whether it is mandatory to support or not as defined in to indicate whether it is mandatory to support or not as defined in
<xref target="teap-tlv-format"/>.</t> <xref target="teap-tlv-format"/>.</t>
</section> </section>
<section numbered="false" anchor="a15-requirement-434-vendor-specific-supp <section numbered="true" anchor="a15-requirement-434-vendor-specific-suppo
ort"> rt">
<name>A.15. Requirement 4.3.4: Vendor-Specific Support</name> <name>Requirement 4.3.4: Vendor-Specific Support</name>
<t>TEAPv1 meets this requirement by having a Vendor-Specific TLV to <t>TEAPv1 meets this requirement by having a Vendor-Specific TLV to
allow vendors to define their own attributes as defined in allow vendors to define their own attributes as defined in
<xref target="vendor-specific-tlv"/>.</t> <xref target="vendor-specific-tlv"/>.</t>
</section> </section>
<section numbered="false" anchor="a16-requirement-435-result-indication"> <section numbered="true" anchor="a16-requirement-435-result-indication">
<name>A.16. Requirement 4.3.5: Result Indication</name> <name>Requirement 4.3.5: Result Indication</name>
<t>TEAPv1 meets this requirement by having a Result TLV to exchange the <t>TEAPv1 meets this requirement by having a Result TLV to exchange the
final result of the TEAP authentication so both the peer and server final result of the TEAP authentication so both the peer and server
have a synchronized state as defined in <xref target="result-tlv"/>.</t> have a synchronized state as defined in <xref target="result-tlv"/>.</t>
</section> </section>
<section numbered="false" anchor="a17-requirement-436-internationalization <section numbered="true" anchor="a17-requirement-436-internationalization-
-of-display-strings"> of-display-strings">
<name>A.17. Requirement 4.3.6: Internationalization of Display Strings< <name>Requirement 4.3.6: Internationalization of Display Strings</name>
/name>
<t>TEAPv1 meets this requirement by supporting UTF-8 format in the <t>TEAPv1 meets this requirement by supporting UTF-8 format in the
Basic-Password-Auth-Req TLV as defined in <xref target="bp-auth-req-tlv"/> and t he Basic-Password-Auth-Req TLV as defined in <xref target="bp-auth-req-tlv"/> and t he
Basic-Password-Auth-Resp TLV as defined in <xref target="bp-auth-resp-tlv"/>.</t > Basic-Password-Auth-Resp TLV as defined in <xref target="bp-auth-resp-tlv"/>.</t >
</section> </section>
<section numbered="false" anchor="a18-requirement-44-eap-channel-binding-r <section numbered="true" anchor="a18-requirement-44-eap-channel-binding-re
equirements"> quirements">
<name>A.18. Requirement 4.4: EAP Channel-Binding Requirements</name> <name>Requirement 4.4: EAP Channel-Binding Requirements</name>
<t>TEAPv1 meets this requirement by having a Channel-Binding TLV to <t>TEAPv1 meets this requirement by having a Channel-Binding TLV to
exchange the EAP channel-binding data as defined in <xref target="channel-bindin g-tlv"/>.</t> exchange the EAP channel-binding data as defined in <xref target="channel-bindin g-tlv"/>.</t>
</section> </section>
<section numbered="false" anchor="a19-requirement-4511-confidentiality-and <section numbered="true" anchor="a19-requirement-4511-confidentiality-and-
-integrity"> integrity">
<name>A.19. Requirement 4.5.1.1: Confidentiality and Integrity</name> <name>Requirement 4.5.1.1: Confidentiality and Integrity</name>
<t>TEAPv1 meets this requirement by running the password authentication <t>TEAPv1 meets this requirement by running the password authentication
inside a protected TLS tunnel.</t> inside a protected TLS tunnel.</t>
</section> </section>
<section numbered="false" anchor="a20-requirement-4512-authentication-of-s <section numbered="true" anchor="a20-requirement-4512-authentication-of-se
erver"> rver">
<name>A.20. Requirement 4.5.1.2: Authentication of Server</name> <name>Requirement 4.5.1.2: Authentication of Server</name>
<t>TEAPv1 meets this requirement by mandating authentication of the <t>TEAPv1 meets this requirement by mandating authentication of the
server before establishment of the protected TLS and then running server before establishment of the protected TLS and then running
inner password authentication as defined in <xref target="phase1"/>.</t> inner password authentication as defined in <xref target="phase1"/>.</t>
</section> </section>
<section numbered="false" anchor="a21-requirement-4513-server-certificate- <section numbered="true" anchor="a21-requirement-4513-server-certificate-r
revocation-checking"> evocation-checking">
<name>A.21. Requirement 4.5.1.3: Server Certificate Revocation Checking <name>Requirement 4.5.1.3: Server Certificate Revocation Checking</name>
</name>
<t>TEAPv1 meets this requirement by supporting TLS Certificate Status <t>TEAPv1 meets this requirement by supporting TLS Certificate Status
Request extension <xref target="RFC6066"/> during tunnel establishment.</t> Request extension <xref target="RFC6066"/> during tunnel establishment.</t>
</section> </section>
<section numbered="false" anchor="a22-requirement-452-internationalization <section numbered="true" anchor="a22-requirement-452-internationalization"
"> >
<name>A.22. Requirement 4.5.2: Internationalization</name> <name>Requirement 4.5.2: Internationalization</name>
<t>TEAPv1 meets this requirement by supporting UTF-8 format in <t>TEAPv1 meets this requirement by supporting UTF-8 format in
Basic-Password-Auth-Req TLV as defined in <xref target="bp-auth-req-tlv"/> and Basic-Password-Auth-Req TLV as defined in <xref target="bp-auth-req-tlv"/> and
Basic-Password-Auth-Resp TLV as defined in Section 4.2.15.</t> Basic-Password-Auth-Resp TLV as defined in <xref target="bp-auth-resp-tlv"/>.</t >
</section> </section>
<section numbered="false" anchor="a23-requirement-453-metadata"> <section numbered="true" anchor="a23-requirement-453-metadata">
<name>A.23. Requirement 4.5.3: Metadata</name> <name>Requirement 4.5.3: Metadata</name>
<t>TEAPv1 meets this requirement by supporting Identity-Type TLV as <t>TEAPv1 meets this requirement by supporting Identity-Type TLV as
defined in <xref target="identity-type-tlv"/> to indicate whether the authentica tion is defined in <xref target="identity-type-tlv"/> to indicate whether the authentica tion is
for a user or a machine.</t> for a user or a machine.</t>
</section> </section>
<section numbered="false" anchor="a24-requirement-454-password-change"> <section numbered="true" anchor="a24-requirement-454-password-change">
<name>A.24. Requirement 4.5.4: Password Change</name> <name>Requirement 4.5.4: Password Change</name>
<t>TEAPv1 meets this requirement by supporting multiple <t>TEAPv1 meets this requirement by supporting multiple
Basic-Password-Auth-Req TLV and Basic-Password-Auth-Resp TLV exchanges within a Basic-Password-Auth-Req TLV and Basic-Password-Auth-Resp TLV exchanges within a
single EAP authentication, which allows "housekeeping"" functions single EAP authentication, which allows "housekeeping"" functions
such as password change.</t> such as password change.</t>
</section> </section>
<section numbered="false" anchor="a25-requirement-461-method-negotiation"> <section numbered="true" anchor="a25-requirement-461-method-negotiation">
<name>A.25. Requirement 4.6.1: Method Negotiation</name> <name>Requirement 4.6.1: Method Negotiation</name>
<t>TEAPv1 meets this requirement by supporting inner EAP method <t>TEAPv1 meets this requirement by supporting inner EAP method
negotiation within the protected TLS tunnel.</t> negotiation within the protected TLS tunnel.</t>
</section> </section>
<section numbered="false" anchor="a26-requirement-462-chained-methods"> <section numbered="true" anchor="a26-requirement-462-chained-methods">
<name>A.26. Requirement 4.6.2: Chained Methods</name> <name>Requirement 4.6.2: Chained Methods</name>
<t>TEAPv1 meets this requirement by supporting inner EAP method chaining <t>TEAPv1 meets this requirement by supporting inner EAP method chaining
within protected TLS tunnels as defined in <xref target="inner-eap"/>.</t> within protected TLS tunnels as defined in <xref target="inner-eap"/>.</t>
</section> </section>
<section numbered="false" anchor="a27-requirement-463-cryptographic-bindin <section numbered="true" anchor="a27-requirement-463-cryptographic-binding
g-with-the-tls-tunnel"> -with-the-tls-tunnel">
<name>A.27. Requirement 4.6.3: Cryptographic Binding with the TLS Tunne <name>Requirement 4.6.3: Cryptographic Binding with the TLS Tunnel</name
l</name> >
<t>TEAPv1 meets this requirement by supporting cryptographic binding of <t>TEAPv1 meets this requirement by supporting cryptographic binding of
the inner EAP method keys with the keys derived from the TLS tunnel the inner EAP method keys with the keys derived from the TLS tunnel
as defined in <xref target="crypto-binding-tlv"/>.</t> as defined in <xref target="crypto-binding-tlv"/>.</t>
</section> </section>
<section numbered="false" anchor="a28-requirement-464-peer-initiated-eap-a <section numbered="true" anchor="a28-requirement-464-peer-initiated-eap-au
uthentication"> thentication">
<name>A.28. Requirement 4.6.4: Peer-Initiated EAP Authentication</name> <name>Requirement 4.6.4: Peer-Initiated EAP Authentication</name>
<t>TEAPv1 meets this requirement by supporting the Request-Action TLV as <t>TEAPv1 meets this requirement by supporting the Request-Action TLV as
defined in <xref target="request-action-tlv"/> to allow a peer to initiate anoth er inner defined in <xref target="request-action-tlv"/> to allow a peer to initiate anoth er inner
EAP method.</t> EAP method.</t>
</section> </section>
<section numbered="false" anchor="a29-requirement-465-method-metadata"> <section numbered="true" anchor="a29-requirement-465-method-metadata">
<name>A.29. Requirement 4.6.5: Method Metadata</name> <name>Requirement 4.6.5: Method Metadata</name>
<t>TEAPv1 meets this requirement by supporting the Identity-Type TLV as <t>TEAPv1 meets this requirement by supporting the Identity-Type TLV as
defined in <xref target="identity-type-tlv"/> to indicate whether the authentica tion is defined in <xref target="identity-type-tlv"/> to indicate whether the authentica tion is
for a user or a machine.</t> for a user or a machine.</t>
</section> </section>
</section> </section>
<section numbered="false" anchor="appendix-b-major-differences-from-eap-fast <section numbered="true" anchor="appendix-b-major-differences-from-eap-fast"
"> >
<name>Appendix B. Major Differences from EAP-FAST</name> <name>Major Differences from EAP-FAST</name>
<t>This document is a new standard tunnel EAP method based on revision <t>This document is a new standard tunnel EAP method based on revision
of EAP-FAST version 1 <xref target="RFC4851"/> that contains improved flexibilit y, of EAP-FAST version 1 <xref target="RFC4851"/> that contains improved flexibilit y,
particularly for negotiation of cryptographic algorithms. The major particularly for negotiation of cryptographic algorithms. The major
changes are:</t> changes are:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>The EAP method name has been changed from EAP-FAST to TEAP; this <t>The EAP method name has been changed from EAP-FAST to TEAP; this
change thus requires that a new EAP Type be assigned.</t> change thus requires that a new EAP Type be assigned.</t>
</li> </li>
<li> <li>
<t>This version of TEAP MUST support TLS 1.2 <xref target="RFC5246"/>. TLS 1.1 and earlier MUST NOT be used with TEAP.</t> <t>This version of TEAP <bcp14>MUST</bcp14> support TLS 1.2 <xref targ et="RFC5246"/>. TLS 1.1 and earlier <bcp14>MUST NOT</bcp14> be used with TEAP.< /t>
</li> </li>
<li> <li>
<t>The key derivation now makes use of TLS keying material exporters <t>The key derivation now makes use of TLS keying material exporters
<xref target="RFC5705"/> and the PRF and hash function negotiated in TLS. This <xref target="RFC5705"/> and the PRF and hash function negotiated in TLS. This
is to simplify implementation and better support cryptographic is to simplify implementation and better support cryptographic
algorithm agility.</t> algorithm agility.</t>
</li> </li>
<li> <li>
<t>TEAP is in full conformance with TLS ticket extension <xref target= "RFC5077"/>.</t> <t>TEAP is in full conformance with TLS ticket extension <xref target= "RFC5077"/>.</t>
</li> </li>
skipping to change at line 4265 skipping to change at line 4270
<t>Basic password authentication on the TLV level has been added in <t>Basic password authentication on the TLV level has been added in
addition to the existing inner EAP method.</t> addition to the existing inner EAP method.</t>
</li> </li>
<li> <li>
<t>Additional TLV types have been defined to support EAP channel <t>Additional TLV types have been defined to support EAP channel
binding and metadata. They are the Identity-Type TLV and binding and metadata. They are the Identity-Type TLV and
Channel-Binding TLVs, defined in <xref target="teap-tlv-format"/>.</t> Channel-Binding TLVs, defined in <xref target="teap-tlv-format"/>.</t>
</li> </li>
</ol> </ol>
</section> </section>
<section numbered="false" anchor="appendix-c-examples"> <section numbered="true" anchor="appendix-c-examples">
<name>Appendix C. Examples</name> <name>Examples</name>
<section numbered="false" anchor="c1-successful-authentication"> <section numbered="true" anchor="c1-successful-authentication">
<name>C.1. Successful Authentication</name> <name>Successful Authentication</name>
<t>The following exchanges show a successful TEAP authentication with <t>The following exchanges show a successful TEAP authentication with
basic password authentication. The basic password authentication. The
conversation will appear as follows:</t> conversation will appear as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/ <- EAP-Request/
Identity Identity
EAP-Response/ EAP-Response/
Identity (MyID1) -> Identity (MyID1) ->
skipping to change at line 4320 skipping to change at line 4325
Crypto-Binding TLV (Request), Crypto-Binding TLV (Request),
Result TLV (Success) Result TLV (Success)
Intermediate-Result TLV (Success), Intermediate-Result TLV (Success),
Crypto-Binding TLV(Response), Crypto-Binding TLV(Response),
Result TLV (Success) -> Result TLV (Success) ->
TLS channel torn down TLS channel torn down
(messages sent in cleartext) (messages sent in cleartext)
<- EAP-Success <- EAP-Success]]></artwork>
]]></artwork>
</section> </section>
<section numbered="false" anchor="c2-failed-authentication"> <section numbered="true" anchor="c2-failed-authentication">
<name>C.2. Failed Authentication</name> <name>Failed Authentication</name>
<t>The following exchanges show a failed TEAP authentication due to <t>The following exchanges show a failed TEAP authentication due to
wrong user credentials. The conversation will appear as follows:</t> wrong user credentials. The conversation will appear as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/Identity <- EAP-Request/Identity
EAP-Response/ EAP-Response/
Identity (MyID1) -> Identity (MyID1) ->
skipping to change at line 4371 skipping to change at line 4375
<- Intermediate-Result TLV (Failure), <- Intermediate-Result TLV (Failure),
Result TLV (Failure) Result TLV (Failure)
Intermediate-Result TLV (Failure), Intermediate-Result TLV (Failure),
Result TLV (Failure) -> Result TLV (Failure) ->
TLS channel torn down TLS channel torn down
(messages sent in cleartext) (messages sent in cleartext)
<- EAP-Failure <- EAP-Failure]]></artwork>
]]></artwork>
</section> </section>
<section numbered="false" anchor="c3-full-tls-handshake-using-certificate- <section numbered="true" anchor="c3-full-tls-handshake-using-certificate-b
based-cipher-suite"> ased-cipher-suite">
<name>C.3. Full TLS Handshake Using Certificate-Based Cipher Suite</nam <name>Full TLS Handshake Using Certificate-Based Cipher Suite</name>
e>
<t>In the case within TEAP Phase 1 where an abbreviated TLS handshake is <t>In the case within TEAP Phase 1 where an abbreviated TLS handshake is
tried, fails, and falls back to the certificate-based full TLS tried, fails, and falls back to the certificate-based full TLS
handshake, the conversation will appear as follows:</t> handshake, the conversation will appear as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/Identity <- EAP-Request/Identity
EAP-Response/ EAP-Response/
Identity (MyID1) -> Identity (MyID1) ->
skipping to change at line 4453 skipping to change at line 4456
Crypto-Binding TLV (Request), Crypto-Binding TLV (Request),
Result TLV (Success) Result TLV (Success)
Intermediate-Result TLV (Success), Intermediate-Result TLV (Success),
Crypto-Binding TLV (Response), Crypto-Binding TLV (Response),
Result TLV (Success) -> Result TLV (Success) ->
// TLS channel torn down // TLS channel torn down
(messages sent in cleartext) (messages sent in cleartext)
<- EAP-Success <- EAP-Success]]></artwork>
]]></artwork>
</section> </section>
<section numbered="false" anchor="c4-client-authentication-during-phase-1- <section numbered="true" anchor="c4-client-authentication-during-phase-1-w
with-identity-privacy"> ith-identity-privacy">
<name>C.4. Client Authentication during Phase 1 with Identity Privacy</ <name>Client Authentication During Phase 1 with Identity Privacy</name>
name>
<t>In the case where a certificate-based TLS handshake occurs within <t>In the case where a certificate-based TLS handshake occurs within
TEAP Phase 1 and client certificate authentication and identity TEAP Phase 1 and client certificate authentication and identity
privacy is desired (and therefore TLS renegotiation is being used to privacy is desired (and therefore TLS renegotiation is being used to
transmit the peer credentials in the protected TLS tunnel), the transmit the peer credentials in the protected TLS tunnel), the
conversation will appear as follows for TLS 1.2:</t> conversation will appear as follows for TLS 1.2:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/Identity <- EAP-Request/Identity
EAP-Response/ EAP-Response/
skipping to change at line 4527 skipping to change at line 4529
TLS finished, TLS finished,
Crypto-Binding TLV (Request), Crypto-Binding TLV (Request),
Result TLV (Success) Result TLV (Success)
Crypto-Binding TLV (Response), Crypto-Binding TLV (Response),
Result TLV (Success)) -> Result TLV (Success)) ->
//TLS channel torn down //TLS channel torn down
(messages sent in cleartext) (messages sent in cleartext)
<- EAP-Success <- EAP-Success]]></artwork>
]]></artwork>
</section> </section>
<section numbered="false" anchor="c5-fragmentation-and-reassembly"> <section numbered="true" anchor="c5-fragmentation-and-reassembly">
<name>C.5. Fragmentation and Reassembly</name> <name>Fragmentation and Reassembly</name>
<t>In the case where TEAP fragmentation is required, the conversation <t>In the case where TEAP fragmentation is required, the conversation
will appear as follows:</t> will appear as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/ <- EAP-Request/
Identity Identity
EAP-Response/ EAP-Response/
Identity (MyID) -> Identity (MyID) ->
<- EAP-Request/ <- EAP-Request/
skipping to change at line 4620 skipping to change at line 4621
Crypto-Binding TLV (Request), Crypto-Binding TLV (Request),
Result TLV (Success) Result TLV (Success)
Intermediate-Result TLV (Success), Intermediate-Result TLV (Success),
Crypto-Binding TLV (Response), Crypto-Binding TLV (Response),
Result TLV (Success) -> Result TLV (Success) ->
// TLS channel torn down // TLS channel torn down
(messages sent in cleartext) (messages sent in cleartext)
<- EAP-Success <- EAP-Success]]></artwork>
]]></artwork>
</section> </section>
<section numbered="false" anchor="c6-sequence-of-eap-methods"> <section numbered="true" anchor="c6-sequence-of-eap-methods">
<name>C.6. Sequence of EAP Methods</name> <name>Sequence of EAP Methods</name>
<t>When TEAP is negotiated with a sequence of EAP method X followed by <t>When TEAP is negotiated with a sequence of EAP method X followed by
method Y, the conversation will occur as follows:</t> method Y, the conversation will occur as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/ <- EAP-Request/
Identity Identity
EAP-Response/ EAP-Response/
Identity (MyID1) -> Identity (MyID1) ->
<- EAP-Request/ <- EAP-Request/
skipping to change at line 4729 skipping to change at line 4729
Crypto-Binding TLV (Response), Crypto-Binding TLV (Response),
Result TLV (Success) -> Result TLV (Success) ->
// Compound-MAC calculated using keys generated from EAP // Compound-MAC calculated using keys generated from EAP
methods X and Y and the TLS tunnel. Compound keys are methods X and Y and the TLS tunnel. Compound keys are
generated using keys generated from EAP methods X and Y generated using keys generated from EAP methods X and Y
and the TLS tunnel. and the TLS tunnel.
// TLS channel torn down (messages sent in cleartext) // TLS channel torn down (messages sent in cleartext)
<- EAP-Success <- EAP-Success]]></artwork>
]]></artwork>
</section> </section>
<section numbered="false" anchor="c7-failed-crypto-binding"> <section numbered="true" anchor="c7-failed-crypto-binding">
<name>C.7. Failed Crypto-Binding</name> <name>Failed Crypto-Binding</name>
<t>The following exchanges show a failed crypto-binding validation. The <t>The following exchanges show a failed crypto-binding validation. The
conversation will appear as follows:</t> conversation will appear as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/ <- EAP-Request/
Identity Identity
EAP-Response/ EAP-Response/
Identity (MyID1) -> Identity (MyID1) ->
<- EAP-Request/ <- EAP-Request/
skipping to change at line 4800 skipping to change at line 4799
Result TLV (Success) Result TLV (Success)
Intermediate-Result TLV (Success), Intermediate-Result TLV (Success),
Result TLV (Failure) Result TLV (Failure)
Error TLV with Error TLV with
(Error Code = 2001) -> (Error Code = 2001) ->
// TLS channel torn down // TLS channel torn down
(messages sent in cleartext) (messages sent in cleartext)
<- EAP-Failure <- EAP-Failure]]></artwork>
]]></artwork>
</section> </section>
<section numbered="false" anchor="c8-sequence-of-eap-method-with-vendor-sp <section numbered="true" anchor="c8-sequence-of-eap-method-with-vendor-spe
ecific-tlv-exchange"> cific-tlv-exchange">
<name>C.8. Sequence of EAP Method with Vendor-Specific TLV Exchange</na <name>Sequence of EAP Method with Vendor-Specific TLV Exchange</name>
me>
<t>When TEAP is negotiated with a sequence of EAP methods followed by a <t>When TEAP is negotiated with a sequence of EAP methods followed by a
Vendor-Specific TLV exchange, the conversation will occur as follows:</t> Vendor-Specific TLV exchange, the conversation will occur as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/ <- EAP-Request/
Identity Identity
EAP-Response/ EAP-Response/
Identity (MyID1) -> Identity (MyID1) ->
<- EAP-Request/ <- EAP-Request/
skipping to change at line 4891 skipping to change at line 4889
<- Vendor-Specific TLV <- Vendor-Specific TLV
Vendor-Specific TLV -> Vendor-Specific TLV ->
<- Result TLV (Success) <- Result TLV (Success)
Result TLV (Success) -> Result TLV (Success) ->
// TLS channel torn down (messages sent in cleartext) // TLS channel torn down (messages sent in cleartext)
<- EAP-Success <- EAP-Success]]></artwork>
]]></artwork>
</section> </section>
<section numbered="false" anchor="c9-peer-requests-inner-method-after-serv <section numbered="true" anchor="c9-peer-requests-inner-method-after-serve
er-sends-result-tlv"> r-sends-result-tlv">
<name>C.9. Peer Requests Inner Method after Server Sends Result TLV</na <name>Peer Requests Inner Method After Server Sends Result TLV</name>
me>
<t>In the case where the peer is authenticated during Phase 1 and the <t>In the case where the peer is authenticated during Phase 1 and the
server sends back a Result TLV but the peer wants to request another server sends back a Result TLV but the peer wants to request another
inner method, the conversation will appear as follows:</t> inner method, the conversation will appear as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/Identity <- EAP-Request/Identity
EAP-Response/ EAP-Response/
Identity (MyID1) -> Identity (MyID1) ->
skipping to change at line 4974 skipping to change at line 4971
Crypto-Binding TLV (Request), Crypto-Binding TLV (Request),
Result TLV (Success) Result TLV (Success)
Intermediate Result TLV (Success), Intermediate Result TLV (Success),
Crypto-Binding TLV (Response), Crypto-Binding TLV (Response),
Result TLV (Success)) -> Result TLV (Success)) ->
// TLS channel torn down // TLS channel torn down
(messages sent in cleartext) (messages sent in cleartext)
<- EAP-Success <- EAP-Success]]></artwork>
]]></artwork>
</section> </section>
<section numbered="false" anchor="c10-channel-binding"> <section numbered="true" anchor="c10-channel-binding">
<name>C.10. Channel Binding</name> <name>Channel Binding</name>
<t>The following exchanges show a successful TEAP authentication with <t>The following exchanges show a successful TEAP authentication with
basic password authentication and channel binding using a basic password authentication and channel binding using a
Request-Action TLV. The conversation will appear as follows:</t> Request-Action TLV. The conversation will appear as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/ <- EAP-Request/
Identity Identity
EAP-Response/ EAP-Response/
Identity (MyID1) -> Identity (MyID1) ->
skipping to change at line 5036 skipping to change at line 5032
TLV=Channel-Binding TLV)-> TLV=Channel-Binding TLV)->
<- Channel-Binding TLV (Response), <- Channel-Binding TLV (Response),
Result TLV (Success), Result TLV (Success),
Result TLV (Success) -> Result TLV (Success) ->
TLS channel torn down TLS channel torn down
(messages sent in cleartext) (messages sent in cleartext)
<- EAP-Success <- EAP-Success]]></artwork>
]]></artwork>
</section> </section>
<section numbered="false" anchor="c11-pkcs-exchange"> <section numbered="true" anchor="c11-pkcs-exchange">
<name>C.11. PKCS Exchange</name> <name>PKCS Exchange</name>
<t>The following exchanges show the peer sending a PKCS#10 TLV, and <t>The following exchanges show the peer sending a PKCS#10 TLV and
server replying with a PKCS7 TLV. The exchange below assumes that the server replying with a PKCS7 TLV. The exchange below assumes that the
EAP peer is authenticated in Phase 1, either via bi-directional EAP peer is authenticated in Phase 1, either via bidirectional
certificate exchange, or some other TLS method such as a proof of certificate exchange or some other TLS method such as a proof of
knowledge (TLS-POK). The conversation will appear as follows:</t> knowledge (TLS-POK). The conversation will appear as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
,----. ,-------. ,----. ,-------.
|Peer| |AuthSrv| |Peer| |AuthSrv|
`-+--' `---+---' `-+--' `---+---'
| EAP-Request / Identity | | EAP-Request / Identity |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - | <- - - - - - - - - - - - - - - - - - - - - - - - - -
| | | |
| EAP-Response / Identity (MYID1) | | EAP-Response / Identity (MYID1) |
| - - - - - - - - - - - - - - - - - - - - - - - - - > | - - - - - - - - - - - - - - - - - - - - - - - - - >
skipping to change at line 5097 skipping to change at line 5092
| Crypto-Binding TLV(Request), | | Crypto-Binding TLV(Request), |
| Result TLV(Success) | | Result TLV(Success) |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - | <- - - - - - - - - - - - - - - - - - - - - - - - - -
| | | |
| Intermediate-Result TLV response(Success), | | Intermediate-Result TLV response(Success), |
| Crypto-Binding TLV(Response), | | Crypto-Binding TLV(Response), |
| Result TLV(Success) | | Result TLV(Success) |
| - - - - - - - - - - - - - - - - - - - - - - - - - > | - - - - - - - - - - - - - - - - - - - - - - - - - >
| | | |
| EAP Success | | EAP Success |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - | <- - - - - - - - - - - - - - - - - - - - - - - - - -]]></artwork>
]]></artwork>
</section> </section>
<section numbered="false" anchor="c12-failure-scenario"> <section numbered="true" anchor="c12-failure-scenario">
<name>C.12. Failure Scenario</name> <name>Failure Scenario</name>
<t>The following exchanges shows a failure scenario. The conversation <t>The following exchanges show a failure scenario. The conversation
will appear as follows:</t> will appear as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
,----. ,-------. ,----. ,-------.
|Peer| |AuthSrv| |Peer| |AuthSrv|
`-+--' `---+---' `-+--' `---+---'
| EAP-Request / Identity | | EAP-Request / Identity |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - - | <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
| | | |
| EAP-Response / Identity (MYID1) | | EAP-Response / Identity (MYID1) |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - -> | - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
skipping to change at line 5146 skipping to change at line 5140
| | | |
| Intermediate-Result TLV request(Failure), | | Intermediate-Result TLV request(Failure), |
| Result TLV(Failure) | | Result TLV(Failure) |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - - | <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
| | | |
| Intermediate-Result TLV response(Failure), | | Intermediate-Result TLV response(Failure), |
| Result TLV(Failure) | | Result TLV(Failure) |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - -> | - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
| | | |
| EAP Failure | | EAP Failure |
| <- - - - - - - - - - - - - - - - - - - - - - - - - - - - | <- - - - - - - - - - - - - - - - - - - - - - - - - - - -]]></artwork>
]]></artwork>
</section> </section>
<section numbered="false" anchor="c13-client-certificate-in-phase-1"> <section numbered="true" anchor="c13-client-certificate-in-phase-1">
<name>C.13. Client certificate in Phase 1</name> <name>Client Certificate in Phase 1</name>
<t>The following exchanges shows a scenario where the client certificate <t>The following exchanges show a scenario where the client certificate
is sent in Phase 1, and no additional authentication or provisioning is sent in Phase 1 and no additional authentication or provisioning
is performed in Phase 2. The conversation will appear as follows:</t> is performed in Phase 2. The conversation will appear as follows:</t>
<artwork><![CDATA[ <artwork><![CDATA[
,----. ,-------. ,----. ,-------.
|Peer| |AuthSrv| |Peer| |AuthSrv|
`-+--' `---+---' `-+--' `---+---'
| EAP-Request / Identity | | EAP-Request / Identity |
| <- - - - - - - - - - - - - - - - - - - - - | <- - - - - - - - - - - - - - - - - - - - -
| | | |
| EAP-Response / Identity (MYID1) | | EAP-Response / Identity (MYID1) |
| - - - - - - - - - - - - - - - - - - - - -> | - - - - - - - - - - - - - - - - - - - - ->
skipping to change at line 5197 skipping to change at line 5190
| | | |
| Crypto-Binding TLV(Request), | | Crypto-Binding TLV(Request), |
| Result TLV(Success) | | Result TLV(Success) |
| <- - - - - - - - - - - - - - - - - - - - - | <- - - - - - - - - - - - - - - - - - - - -
| | | |
| Crypto-Binding TLV(Response), | | Crypto-Binding TLV(Response), |
| Result TLV(Success) | | Result TLV(Success) |
| - - - - - - - - - - - - - - - - - - - - -> | - - - - - - - - - - - - - - - - - - - - ->
| | | |
| EAP Success | | EAP Success |
| <- - - - - - - - - - - - - - - - - - - - - | <- - - - - - - - - - - - - - - - - - - - -]]></artwork>
]]></artwork>
</section> </section>
</section> </section>
</middle>
<back>
<references anchor="sec-combined-references">
<name>References</name>
<references anchor="sec-normative-references">
<name>Normative References</name>
<reference anchor="BCP14">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC2985">
<front>
<title>PKCS #9: Selected Object Classes and Attribute Types Version
2.0</title>
<author fullname="M. Nystrom" initials="M." surname="Nystrom"/>
<author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
<date month="November" year="2000"/>
<abstract>
<t>This memo represents a republication of PKCS #9 v2.0 from RSA L
aboratories' Public-Key Cryptography Standards (PKCS) series, and change control
is retained within the PKCS process. The body of this document, except for the
security considerations section, is taken directly from that specification. This
memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2985"/>
<seriesInfo name="DOI" value="10.17487/RFC2985"/>
</reference>
<reference anchor="RFC2986">
<front>
<title>PKCS #10: Certification Request Syntax Specification Version
1.7</title>
<author fullname="M. Nystrom" initials="M." surname="Nystrom"/>
<author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
<date month="November" year="2000"/>
<abstract>
<t>This memo represents a republication of PKCS #10 v1.7 from RSA
Laboratories' Public-Key Cryptography Standards (PKCS) series, and change contro
l is retained within the PKCS process. The body of this document, except for the
security considerations section, is taken directly from the PKCS #9 v2.0 or the
PKCS #10 v1.7 document. This memo provides information for the Internet communi
ty.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2986"/>
<seriesInfo name="DOI" value="10.17487/RFC2986"/>
</reference>
<reference anchor="RFC3748">
<front>
<title>Extensible Authentication Protocol (EAP)</title>
<author fullname="B. Aboba" initials="B." surname="Aboba"/>
<author fullname="L. Blunk" initials="L." surname="Blunk"/>
<author fullname="J. Vollbrecht" initials="J." surname="Vollbrecht"/
>
<author fullname="J. Carlson" initials="J." surname="Carlson"/>
<author fullname="H. Levkowetz" initials="H." role="editor" surname=
"Levkowetz"/>
<date month="June" year="2004"/>
<abstract>
<t>This document defines the Extensible Authentication Protocol (E
AP), an authentication framework which supports multiple authentication methods.
EAP typically runs directly over data link layers such as Point-to-Point Protoc
ol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for dup
licate elimination and retransmission, but is reliant on lower layer ordering gu
arantees. Fragmentation is not supported within EAP itself; however, individual
EAP methods may support this. This document obsoletes RFC 2284. A summary of the
changes between this document and RFC 2284 is available in Appendix A. [STANDAR
DS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3748"/>
<seriesInfo name="DOI" value="10.17487/RFC3748"/>
</reference>
<reference anchor="RFC5077">
<front>
<title>Transport Layer Security (TLS) Session Resumption without Ser
ver-Side State</title>
<author fullname="J. Salowey" initials="J." surname="Salowey"/>
<author fullname="H. Zhou" initials="H." surname="Zhou"/>
<author fullname="P. Eronen" initials="P." surname="Eronen"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<date month="January" year="2008"/>
<abstract>
<t>This document describes a mechanism that enables the Transport
Layer Security (TLS) server to resume sessions and avoid keeping per-client sess
ion state. The TLS server encapsulates the session state into a ticket and forwa
rds it to the client. The client can subsequently resume a session using the obt
ained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5077"/>
<seriesInfo name="DOI" value="10.17487/RFC5077"/>
</reference>
<reference anchor="RFC5216">
<front>
<title>The EAP-TLS Authentication Protocol</title>
<author fullname="D. Simon" initials="D." surname="Simon"/>
<author fullname="B. Aboba" initials="B." surname="Aboba"/>
<author fullname="R. Hurst" initials="R." surname="Hurst"/>
<date month="March" year="2008"/>
<abstract>
<t>The Extensible Authentication Protocol (EAP), defined in RFC 37
48, provides support for multiple authentication methods. Transport Layer Securi
ty (TLS) provides for mutual authentication, integrity-protected ciphersuite neg
otiation, and key exchange between two endpoints. This document defines EAP-TLS,
which includes support for certificate-based mutual authentication and key deri
vation.</t>
<t>This document obsoletes RFC 2716. A summary of the changes betw
een this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5216"/>
<seriesInfo name="DOI" value="10.17487/RFC5216"/>
</reference>
<reference anchor="RFC5246">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</titl
e>
<author fullname="T. Dierks" initials="T." surname="Dierks"/>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2008"/>
<abstract>
<t>This document specifies Version 1.2 of the Transport Layer Secu
rity (TLS) protocol. The TLS protocol provides communications security over the
Internet. The protocol allows client/server applications to communicate in a way
that is designed to prevent eavesdropping, tampering, or message forgery. [STAN
DARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5246"/>
<seriesInfo name="DOI" value="10.17487/RFC5246"/>
</reference>
<reference anchor="RFC5295">
<front>
<title>Specification for the Derivation of Root Keys from an Extende
d Master Session Key (EMSK)</title>
<author fullname="J. Salowey" initials="J." surname="Salowey"/>
<author fullname="L. Dondeti" initials="L." surname="Dondeti"/>
<author fullname="V. Narayanan" initials="V." surname="Narayanan"/>
<author fullname="M. Nakhjiri" initials="M." surname="Nakhjiri"/>
<date month="August" year="2008"/>
<abstract>
<t>The Extensible Authentication Protocol (EAP) defined the Extend
ed Master Session Key (EMSK) generation, but reserved it for unspecified future
uses. This memo reserves the EMSK for the sole purpose of deriving root keys. Ro
ot keys are master keys that can be used for multiple purposes, identified by us
age definitions. This document also specifies a mechanism for avoiding conflicts
between root keys by deriving them in a manner that guarantees cryptographic se
paration. Finally, this document also defines one such root key usage: Domain-Sp
ecific Root Keys are root keys made available to and used within specific key ma
nagement domains. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5295"/>
<seriesInfo name="DOI" value="10.17487/RFC5295"/>
</reference>
<reference anchor="RFC5705">
<front>
<title>Keying Material Exporters for Transport Layer Security (TLS)<
/title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="March" year="2010"/>
<abstract>
<t>A number of protocols wish to leverage Transport Layer Security
(TLS) to perform key establishment but then use some of the keying material for
their own purposes. This document describes a general mechanism for allowing th
at. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5705"/>
<seriesInfo name="DOI" value="10.17487/RFC5705"/>
</reference>
<reference anchor="RFC5746">
<front>
<title>Transport Layer Security (TLS) Renegotiation Indication Exten
sion</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="M. Ray" initials="M." surname="Ray"/>
<author fullname="S. Dispensa" initials="S." surname="Dispensa"/>
<author fullname="N. Oskov" initials="N." surname="Oskov"/>
<date month="February" year="2010"/>
<abstract>
<t>Secure Socket Layer (SSL) and Transport Layer Security (TLS) re
negotiation are vulnerable to an attack in which the attacker forms a TLS connec
tion with the target server, injects content of his choice, and then splices in
a new TLS connection from a client. The server treats the client's initial TLS h
andshake as a renegotiation and thus believes that the initial data transmitted
by the attacker is from the same entity as the subsequent client data. This spec
ification defines a TLS extension to cryptographically tie renegotiations to the
TLS connections they are being performed over, thus preventing this attack. [ST
ANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5746"/>
<seriesInfo name="DOI" value="10.17487/RFC5746"/>
</reference>
<reference anchor="RFC5929">
<front>
<title>Channel Bindings for TLS</title>
<author fullname="J. Altman" initials="J." surname="Altman"/>
<author fullname="N. Williams" initials="N." surname="Williams"/>
<author fullname="L. Zhu" initials="L." surname="Zhu"/>
<date month="July" year="2010"/>
<abstract>
<t>This document defines three channel binding types for Transport
Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-teln
et, in accordance with RFC 5056 (On Channel Binding).</t>
<t>Note that based on implementation experience, this document cha
nges the original definition of 'tls-unique' channel binding type in the channel
binding type IANA registry. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5929"/>
<seriesInfo name="DOI" value="10.17487/RFC5929"/>
</reference>
<reference anchor="RFC6677">
<front>
<title>Channel-Binding Support for Extensible Authentication Protoco
l (EAP) Methods</title>
<author fullname="S. Hartman" initials="S." role="editor" surname="H
artman"/>
<author fullname="T. Clancy" initials="T." surname="Clancy"/>
<author fullname="K. Hoeper" initials="K." surname="Hoeper"/>
<date month="July" year="2012"/>
<abstract>
<t>This document defines how to implement channel bindings for Ext
ensible Authentication Protocol (EAP) methods to address the "lying Network Acce
ss Service (NAS)" problem as well as the "lying provider" problem. [STANDARDS-TR
ACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6677"/>
<seriesInfo name="DOI" value="10.17487/RFC6677"/>
</reference>
<reference anchor="RFC7030">
<front>
<title>Enrollment over Secure Transport</title>
<author fullname="M. Pritikin" initials="M." role="editor" surname="
Pritikin"/>
<author fullname="P. Yee" initials="P." role="editor" surname="Yee"/
>
<author fullname="D. Harkins" initials="D." role="editor" surname="H
arkins"/>
<date month="October" year="2013"/>
<abstract>
<t>This document profiles certificate enrollment for clients using
Certificate Management over CMS (CMC) messages over a secure transport. This pr
ofile, called Enrollment over Secure Transport (EST), describes a simple, yet fu
nctional, certificate management protocol targeting Public Key Infrastructure (P
KI) clients that need to acquire client certificates and associated Certificatio
n Authority (CA) certificates. It also supports client-generated public/private
key pairs as well as key pairs generated by the CA.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7030"/>
<seriesInfo name="DOI" value="10.17487/RFC7030"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC8996">
<front>
<title>Deprecating TLS 1.0 and TLS 1.1</title>
<author fullname="K. Moriarty" initials="K." surname="Moriarty"/>
<author fullname="S. Farrell" initials="S." surname="Farrell"/>
<date month="March" year="2021"/>
<abstract>
<t>This document formally deprecates Transport Layer Security (TLS
) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have
been moved to Historic status. These versions lack support for current and recom
mended cryptographic algorithms and mechanisms, and various government and indus
try profiles of applications using TLS now mandate avoiding these old TLS versio
ns. TLS version 1.2 became the recommended version for IETF protocols in 2008 (s
ubsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient ti
me to transition away from older versions. Removing support for older versions f
rom implementations reduces the attack surface, reduces opportunity for misconfi
guration, and streamlines library and product maintenance.</t>
<t>This document also deprecates Datagram TLS (DTLS) version 1.0 (
RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1.</t>
<t>This document updates many RFCs that normatively refer to TLS v
ersion 1.0 or TLS version 1.1, as described herein. This document also updates t
he best practices for TLS usage in RFC 7525; hence, it is part of BCP 195.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="195"/>
<seriesInfo name="RFC" value="8996"/>
<seriesInfo name="DOI" value="10.17487/RFC8996"/>
</reference>
<reference anchor="RFC9190">
<front>
<title>EAP-TLS 1.3: Using the Extensible Authentication Protocol wit
h TLS 1.3</title>
<author fullname="J. Preuß Mattsson" initials="J." surname="Preuß Ma
ttsson"/>
<author fullname="M. Sethi" initials="M." surname="Sethi"/>
<date month="February" year="2022"/>
<abstract>
<t>The Extensible Authentication Protocol (EAP), defined in RFC 37
48, provides a standard mechanism for support of multiple authentication methods
. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwa
rds compatible with existing implementations of EAP-TLS. TLS 1.3 provides signif
icantly improved security and privacy, and reduced latency when compared to earl
ier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves securit
y and privacy by always providing forward secrecy, never disclosing the peer ide
ntity, and by mandating use of revocation checking when compared to EAP-TLS with
earlier versions of TLS. This document also provides guidance on authentication
, authorization, and resumption for EAP-TLS in general (regardless of the underl
ying TLS version used). This document updates RFC 5216.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9190"/>
<seriesInfo name="DOI" value="10.17487/RFC9190"/>
</reference>
<reference anchor="RFC9427">
<front>
<title>TLS-Based Extensible Authentication Protocol (EAP) Types for
Use with TLS 1.3</title>
<author fullname="A. DeKok" initials="A." surname="DeKok"/>
<date month="June" year="2023"/>
<abstract>
<t>The Extensible Authentication Protocol-TLS (EAP-TLS) (RFC 5216)
has been updated for TLS 1.3 in RFC 9190. Many other EAP Types also depend on T
LS, such as EAP-Flexible Authentication via Secure Tunneling (EAP-FAST) (RFC 485
1), EAP-Tunneled TLS (EAP-TTLS) (RFC 5281), the Tunnel Extensible Authentication
Protocol (TEAP) (RFC 7170). It is possible that many vendor-specific EAP method
s, such as the Protected Extensible Authentication Protocol (PEAP), depend on TL
S as well. This document updates those methods in order to use the new key deriv
ation methods available in TLS 1.3. Additional changes necessitated by TLS 1.3 a
re also discussed.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9427"/>
<seriesInfo name="DOI" value="10.17487/RFC9427"/>
</reference>
<reference anchor="RFC9525">
<front>
<title>Service Identity in TLS</title>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<author fullname="R. Salz" initials="R." surname="Salz"/>
<date month="November" year="2023"/>
<abstract>
<t>Many application technologies enable secure communication betwe
en two entities by means of Transport Layer Security (TLS) with Internet Public
Key Infrastructure using X.509 (PKIX) certificates. This document specifies proc
edures for representing and verifying the identity of application services in su
ch interactions.</t>
<t>This document obsoletes RFC 6125.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9525"/>
<seriesInfo name="DOI" value="10.17487/RFC9525"/>
</reference>
<reference anchor="I-D.ietf-lamps-rfc7030-csrattrs">
<front>
<title>Clarification and enhancement of RFC7030 CSR Attributes defin
ition</title>
<author fullname="Michael Richardson" initials="M." surname="Richard
son">
<organization>Sandelman Software Works</organization>
</author>
<author fullname="Owen Friel" initials="O." surname="Friel">
<organization>Cisco</organization>
</author>
<author fullname="David von Oheimb" initials="D." surname="von Oheim
b">
<organization>Siemens</organization>
</author>
<author fullname="Dan Harkins" initials="D." surname="Harkins">
<organization>The Industrial Lounge</organization>
</author>
<date day="8" month="May" year="2025"/>
<abstract>
<t> This document updates RFC7030, Enrollment over Secure Transp
ort
(EST), clarifying how the Certificate Signiing Request (CSR)
Attributes Response can be used by an EST server to specify both CSR
attribute Object IDs (OID) and also CSR attribute values, in
particular X.509 extension values, that the server expects the client
to include in subsequent CSR request.
RFC7030 (EST) is ambiguous in its specification of the CSR Attributes <!-- [rfced] Please review all verified errata reports for this document and ens
Response. This has resulted in implementation challenges and ure
implementor confusion. As a result, there was not universal that all relevant errata have been addressed. See https://www.rfc-editor.org/err
understanding of what was specified. This document clarifies the ata/rfc7170.
encoding rules. -->
This document therefore also provides a new straightforward approach: <section anchor="acknowledgments" numbered="false">
using a template for CSR contents that may be partially filled in by <name>Acknowledgments</name>
the server. This also allows an EST server to specify a subject <t>Nearly all of the text in this document was taken directly from <xref
Distinguished Name (DN). target="RFC7170"/>. We are grateful to the original authors and
reviewers for that document. The acknowledgments given here are only
for the changes that resulted in this document.</t>
<t><contact fullname="Alexander Clouter"/> provided substantial and
detailed technical feedback on nearly every aspect of the specification.
The corrections in this document are based on his work.</t>
<t>We wish to thank the many reviewers and commenters in the EMU WG,
including <contact fullname="Eliot Lear"/>, <contact fullname="Joe
Salowey"/>, <contact fullname="Heikki Vatiainen"/>, <contact
fullname="Bruno Pereria Vidal"/>, and <contact fullname="Michael
Richardson"/>. Many corner cases and edge conditions were caught and
corrected as a result of their feedback.</t>
<t><contact fullname="Jouni Malinin"/> initially pointed out the issues
with <xref target="RFC7170"/>. Those comments resulted in substantial dis
cussion on the
EMU WG mailing list, and eventually this document. Jouni also made
substantial contributions in analyzing corner cases, which resulted in
the text in <xref target="oops"/>.</t>
</section>
</t> <!--[rfced] Citations
</abstract>
</front> It appears that the section citations in the following sentences weren't
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-rfc7030-csra properly converted from Markdown. We have updated the citations based on
ttrs-22"/> the anchor tags. Please review and let us know if any further updates are
</reference> needed.
</references>
<references anchor="sec-informative-references"> a) {#key-derivations} appears to be a broken citation to Section 6.1 (TEAP
<name>Informative References</name> Authentication Phase 1: Key Derivations).
<reference anchor="IEEE.802-1X.2020">
<front> Original:
<title>*** BROKEN REFERENCE ***</title> Implementations also need to implement the inner method ordering
<author> described in {#key-derivations}, below, in order to fully prevent on-
<organization/> path attacks.
</author>
<date/> Current:
</front> Implementations also need to implement the inner method ordering
</reference> described in Section 6.1 in order to fully prevent
<reference anchor="KAMATH"> on-path attacks
<front>
<title>Microsoft EAP CHAP Extensions</title> b) {#cert-provisioning} appears to be a broken citation to Section 3.11.1
<author initials="R. H. and A." surname="Palekar" fullname="Ryan Hur (Certificate Provisioning Within the Tunnel).
st and Ashwin Palekar">
<organization/> Original:
</author> When the server cannot be authenticated, the peer MUST NOT
<date year="2007" month="June"/> request any services such as certificate provisioning ({#cert-
</front> provisioning}) from it.
</reference>
<reference anchor="MSCHAP" target="https://learn.microsoft.com/en-us/ope Current:
nspecs/windows_protocols/ms-chap/5a860bf5-2aeb-485b-82ee-fac1e8e6b76f"> When the server cannot be authenticated, the peer MUST NOT
<front> request any services such as certificate provisioning (Section 3.11.1)
<title>Master Session Key (MSK) Derivation</title> from it
<author initials="M." surname="Corporation" fullname="Microsoft Corp
oration"> c) {#separation-p1-p2} appears to a broken citation to Section 8.3
<organization/> (Separation of Phase 1 and Phase 2 Servers).
</author>
<date>n.d.</date> Original:
</front> Note that using an MSK of all zeroes opens up TEAP to on-path attacks,
</reference> as discussed below in {#separation-p1-p2}.
<reference anchor="NIST-SP-800-57">
<front> Current:
<title>Recommendation for Key Management</title> Note that using an MSK of all zeroes opens up TEAP to on-path
<author initials="N. I. of S. and" surname="Technology" fullname="Na attacks as discussed in Section 8.3.
tional Institute of Standards and Technology">
<organization/> -->
</author> <!-- [rfced] Abbreviations
<date year="2012" month="July"/>
</front> a) FYI: Expansions appear for abbreviations upon first use per
</reference> Section 3.6 of RFC 7322 ("RFC Style Guide") and abbreviations are used
<reference anchor="PEAP"> after introduction. Please review each expansion in the document carefully to
<front> ensure correctness.
<title>[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP
)</title> b) Should instances of "TEAP protocol" and "EAP protocol" be updated to simply
<author initials="M." surname="Corporation" fullname="Microsoft Corp read "TEAP" and "EAP" to avoid redundancy (if expanded, "TEAP protocol" would
oration"> read "Tunnel Extensible Authentication Protocol protocol" and "EAP protocol"
<organization/> would read "Extensible Authentication Protocol"). Please review and let us
</author> know if any updates are needed.
<date year="2014" month="February"/> -->
</front>
</reference> <!-- [rfced] Please review the "Inclusive Language" portion of the online
<reference anchor="RFC2315"> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
<front> and let us know if any changes are needed. Updates of this nature typically
<title>PKCS #7: Cryptographic Message Syntax Version 1.5</title> result in more precise language, which is helpful for readers. For example, plea
<author fullname="B. Kaliski" initials="B." surname="Kaliski"/> se consider if "master" or "deficiency" should be updated. -->
<date month="March" year="1998"/>
<abstract> <!-- [rfced] Terminology
<t>This document describes a general syntax for data that may have
cryptography applied to it, such as digital signatures and digital envelopes. T a) Please review the following terms and let us know how we should
his memo provides information for the Internet community. It does not specify an update for consistency.
Internet standard of any kind.</t>
</abstract> Compound MAC vs. Compound-MAC vs. compound MAC
</front> crypto-binding vs. crypto binding
<seriesInfo name="RFC" value="2315"/> Inner Method vs. inner method
<seriesInfo name="DOI" value="10.17487/RFC2315"/>
</reference> b) Per usage in RFC 7170, may we update all instances of "outer TLV" to
<reference anchor="RFC3579"> "Outer TLV" for consistency?
<front> -->
<title>RADIUS (Remote Authentication Dial In User Service) Support F <section anchor="contributors" numbered="false" toc="include">
or Extensible Authentication Protocol (EAP)</title>
<author fullname="B. Aboba" initials="B." surname="Aboba"/>
<author fullname="P. Calhoun" initials="P." surname="Calhoun"/>
<date month="September" year="2003"/>
<abstract>
<t>This document defines Remote Authentication Dial In User Servic
e (RADIUS) support for the Extensible Authentication Protocol (EAP), an authenti
cation framework which supports multiple authentication mechanisms. In the propo
sed scheme, the Network Access Server (NAS) forwards EAP packets to and from the
RADIUS server, encapsulated within EAP-Message attributes. This has the advanta
ge of allowing the NAS to support any EAP authentication method, without the nee
d for method- specific code, which resides on the RADIUS server. While EAP was o
riginally developed for use with PPP, it is now also in use with IEEE 802. This
memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3579"/>
<seriesInfo name="DOI" value="10.17487/RFC3579"/>
</reference>
<reference anchor="RFC3629">
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author fullname="F. Yergeau" initials="F." surname="Yergeau"/>
<date month="November" year="2003"/>
<abstract>
<t>ISO/IEC 10646-1 defines a large character set called the Univer
sal Character Set (UCS) which encompasses most of the world's writing systems. T
he originally proposed encodings of the UCS, however, were not compatible with m
any current applications and protocols, and this has led to the development of U
TF-8, the object of this memo. UTF-8 has the characteristic of preserving the fu
ll US-ASCII range, providing compatibility with file systems, parsers and other
software that rely on US-ASCII values but are transparent to other values. This
memo obsoletes and replaces RFC 2279.</t>
</abstract>
</front>
<seriesInfo name="STD" value="63"/>
<seriesInfo name="RFC" value="3629"/>
<seriesInfo name="DOI" value="10.17487/RFC3629"/>
</reference>
<reference anchor="RFC3766">
<front>
<title>Determining Strengths For Public Keys Used For Exchanging Sym
metric Keys</title>
<author fullname="H. Orman" initials="H." surname="Orman"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="April" year="2004"/>
<abstract>
<t>Implementors of systems that use public key cryptography to exc
hange symmetric keys need to make the public keys resistant to some predetermine
d level of attack. That level of attack resistance is the strength of the system
, and the symmetric keys that are exchanged must be at least as strong as the sy
stem strength requirements. The three quantities, system strength, symmetric key
strength, and public key strength, must be consistently matched for any network
protocol usage. While it is fairly easy to express the system strength requirem
ents in terms of a symmetric key length and to choose a cipher that has a key le
ngth equal to or exceeding that requirement, it is harder to choose a public key
that has a cryptographic strength meeting a symmetric key strength requirement.
This document explains how to determine the length of an asymmetric key as a fu
nction of a symmetric key strength requirement. Some rules of thumb for estimati
ng equivalent resistance to large-scale attacks on various algorithms are given.
The document also addresses how changing the sizes of the underlying large inte
gers (moduli, group sizes, exponents, and so on) changes the time to use the alg
orithms for key exchange. This document specifies an Internet Best Current Pract
ices for the Internet Community, and requests discussion and suggestions for imp
rovements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="86"/>
<seriesInfo name="RFC" value="3766"/>
<seriesInfo name="DOI" value="10.17487/RFC3766"/>
</reference>
<reference anchor="RFC4017">
<front>
<title>Extensible Authentication Protocol (EAP) Method Requirements
for Wireless LANs</title>
<author fullname="D. Stanley" initials="D." surname="Stanley"/>
<author fullname="J. Walker" initials="J." surname="Walker"/>
<author fullname="B. Aboba" initials="B." surname="Aboba"/>
<date month="March" year="2005"/>
<abstract>
<t>The IEEE 802.11i MAC Security Enhancements Amendment makes use
of IEEE 802.1X, which in turn relies on the Extensible Authentication Protocol (
EAP). This document defines requirements for EAP methods used in IEEE 802.11 wir
eless LAN deployments. The material in this document has been approved by IEEE 8
02.11 and is being presented as an IETF RFC for informational purposes. This mem
o provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4017"/>
<seriesInfo name="DOI" value="10.17487/RFC4017"/>
</reference>
<reference anchor="RFC4072">
<front>
<title>Diameter Extensible Authentication Protocol (EAP) Application
</title>
<author fullname="P. Eronen" initials="P." role="editor" surname="Er
onen"/>
<author fullname="T. Hiller" initials="T." surname="Hiller"/>
<author fullname="G. Zorn" initials="G." surname="Zorn"/>
<date month="August" year="2005"/>
<abstract>
<t>The Extensible Authentication Protocol (EAP) provides a standar
d mechanism for support of various authentication methods. This document defines
the Command-Codes and AVPs necessary to carry EAP packets between a Network Acc
ess Server (NAS) and a back-end authentication server. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4072"/>
<seriesInfo name="DOI" value="10.17487/RFC4072"/>
</reference>
<reference anchor="RFC4086">
<front>
<title>Randomness Requirements for Security</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd"/>
<author fullname="J. Schiller" initials="J." surname="Schiller"/>
<author fullname="S. Crocker" initials="S." surname="Crocker"/>
<date month="June" year="2005"/>
<abstract>
<t>Security systems are built on strong cryptographic algorithms t
hat foil pattern analysis attempts. However, the security of these systems is de
pendent on generating secret quantities for passwords, cryptographic keys, and s
imilar quantities. The use of pseudo-random processes to generate secret quantit
ies can result in pseudo-security. A sophisticated attacker may find it easier t
o reproduce the environment that produced the secret quantities and to search th
e resulting small set of possibilities than to locate the quantities in the whol
e of the potential number space.</t>
<t>Choosing random quantities to foil a resourceful and motivated
adversary is surprisingly difficult. This document points out many pitfalls in u
sing poor entropy sources or traditional pseudo-random number generation techniq
ues for generating such quantities. It recommends the use of truly random hardwa
re techniques and shows that the existing hardware on many systems can be used f
or this purpose. It provides suggestions to ameliorate the problem when a hardwa
re solution is not available, and it gives examples of how large such quantities
need to be for some applications. This document specifies an Internet Best Curr
ent Practices for the Internet Community, and requests discussion and suggestion
s for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="106"/>
<seriesInfo name="RFC" value="4086"/>
<seriesInfo name="DOI" value="10.17487/RFC4086"/>
</reference>
<reference anchor="RFC4648">
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
<date month="October" year="2006"/>
<abstract>
<t>This document describes the commonly used base 64, base 32, and
base 16 encoding schemes. It also discusses the use of line-feeds in encoded da
ta, use of padding in encoded data, use of non-alphabet characters in encoded da
ta, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRA
CK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4648"/>
<seriesInfo name="DOI" value="10.17487/RFC4648"/>
</reference>
<reference anchor="RFC4851">
<front>
<title>The Flexible Authentication via Secure Tunneling Extensible A
uthentication Protocol Method (EAP-FAST)</title>
<author fullname="N. Cam-Winget" initials="N." surname="Cam-Winget"/
>
<author fullname="D. McGrew" initials="D." surname="McGrew"/>
<author fullname="J. Salowey" initials="J." surname="Salowey"/>
<author fullname="H. Zhou" initials="H." surname="Zhou"/>
<date month="May" year="2007"/>
<abstract>
<t>This document defines the Extensible Authentication Protocol (E
AP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-
FAST is an EAP method that enables secure communication between a peer and a ser
ver by using the Transport Layer Security (TLS) to establish a mutually authenti
cated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to con
vey authentication related data between the peer and the EAP server. This memo p
rovides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4851"/>
<seriesInfo name="DOI" value="10.17487/RFC4851"/>
</reference>
<reference anchor="RFC4945">
<front>
<title>The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2,
and PKIX</title>
<author fullname="B. Korver" initials="B." surname="Korver"/>
<date month="August" year="2007"/>
<abstract>
<t>The Internet Key Exchange (IKE) and Public Key Infrastructure f
or X.509 (PKIX) certificate profile both provide frameworks that must be profile
d for use in a given application. This document provides a profile of IKE and PK
IX that defines the requirements for using PKI technology in the context of IKE/
IPsec. The document complements protocol specifications such as IKEv1 and IKEv2,
which assume the existence of public key certificates and related keying materi
als, but which do not address PKI issues explicitly. This document addresses tho
se issues. The intended audience is implementers of PKI for IPsec. [STANDARDS-TR
ACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4945"/>
<seriesInfo name="DOI" value="10.17487/RFC4945"/>
</reference>
<reference anchor="RFC4962">
<front>
<title>Guidance for Authentication, Authorization, and Accounting (A
AA) Key Management</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="B. Aboba" initials="B." surname="Aboba"/>
<date month="July" year="2007"/>
<abstract>
<t>This document provides guidance to designers of Authentication,
Authorization, and Accounting (AAA) key management protocols. The guidance is a
lso useful to designers of systems and solutions that include AAA key management
protocols. Given the complexity and difficulty in designing secure, long-lastin
g key management algorithms and protocols by experts in the field, it is almost
certainly inappropriate for IETF working groups without deep expertise in the ar
ea to be designing their own key management algorithms and protocols based on Au
thentication, Authorization, and Accounting (AAA) protocols. The guidelines in t
his document apply to documents requesting publication as IETF RFCs. Further, th
ese guidelines will be useful to other standards development organizations (SDOs
) that specify AAA key management. This document specifies an Internet Best Curr
ent Practices for the Internet Community, and requests discussion and suggestion
s for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="132"/>
<seriesInfo name="RFC" value="4962"/>
<seriesInfo name="DOI" value="10.17487/RFC4962"/>
</reference>
<reference anchor="RFC5247">
<front>
<title>Extensible Authentication Protocol (EAP) Key Management Frame
work</title>
<author fullname="B. Aboba" initials="B." surname="Aboba"/>
<author fullname="D. Simon" initials="D." surname="Simon"/>
<author fullname="P. Eronen" initials="P." surname="Eronen"/>
<date month="August" year="2008"/>
<abstract>
<t>The Extensible Authentication Protocol (EAP), defined in RFC 37
48, enables extensible network access authentication. This document specifies th
e EAP key hierarchy and provides a framework for the transport and usage of keyi
ng material and parameters generated by EAP authentication algorithms, known as
"methods". It also provides a detailed system-level security analysis, describin
g the conditions under which the key management guidelines described in RFC 4962
can be satisfied. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5247"/>
<seriesInfo name="DOI" value="10.17487/RFC5247"/>
</reference>
<reference anchor="RFC5272">
<front>
<title>Certificate Management over CMS (CMC)</title>
<author fullname="J. Schaad" initials="J." surname="Schaad"/>
<author fullname="M. Myers" initials="M." surname="Myers"/>
<date month="June" year="2008"/>
<abstract>
<t>This document defines the base syntax for CMC, a Certificate Ma
nagement protocol using the Cryptographic Message Syntax (CMS). This protocol ad
dresses two immediate needs within the Internet Public Key Infrastructure (PKI)
community:</t>
<t>1. The need for an interface to public key certification produc
ts and services based on CMS and PKCS #10 (Public Key Cryptography Standard), an
d</t>
<t>2. The need for a PKI enrollment protocol for encryption only k
eys due to algorithm or hardware design.</t>
<t>CMC also requires the use of the transport document and the req
uirements usage document along with this document for a full definition. [STANDA
RDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5272"/>
<seriesInfo name="DOI" value="10.17487/RFC5272"/>
</reference>
<reference anchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert
ificate Revocation List (CRL) Profile</title>
<author fullname="D. Cooper" initials="D." surname="Cooper"/>
<author fullname="S. Santesson" initials="S." surname="Santesson"/>
<author fullname="S. Farrell" initials="S." surname="Farrell"/>
<author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="W. Polk" initials="W." surname="Polk"/>
<date month="May" year="2008"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certif
icate revocation list (CRL) for use in the Internet. An overview of this approac
h and model is provided as an introduction. The X.509 v3 certificate format is d
escribed in detail, with additional information regarding the format and semanti
cs of Internet name forms. Standard certificate extensions are described and two
Internet-specific extensions are defined. A set of required certificate extensi
ons is specified. The X.509 v2 CRL format is described in detail along with stan
dard and Internet-specific extensions. An algorithm for X.509 certification path
validation is described. An ASN.1 module and examples are provided in the appen
dices. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
</reference>
<reference anchor="RFC5281">
<front>
<title>Extensible Authentication Protocol Tunneled Transport Layer S
ecurity Authenticated Protocol Version 0 (EAP-TTLSv0)</title>
<author fullname="P. Funk" initials="P." surname="Funk"/>
<author fullname="S. Blake-Wilson" initials="S." surname="Blake-Wils
on"/>
<date month="August" year="2008"/>
<abstract>
<t>EAP-TTLS is an EAP (Extensible Authentication Protocol) method
that encapsulates a TLS (Transport Layer Security) session, consisting of a hand
shake phase and a data phase. During the handshake phase, the server is authenti
cated to the client (or client and server are mutually authenticated) using stan
dard TLS procedures, and keying material is generated in order to create a crypt
ographically secure tunnel for information exchange in the subsequent data phase
. During the data phase, the client is authenticated to the server (or client an
d server are mutually authenticated) using an arbitrary authentication mechanism
encapsulated within the secure tunnel. The encapsulated authentication mechanis
m may itself be EAP, or it may be another authentication protocol such as PAP, C
HAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authent
ication protocols to be used against existing authentication databases, while pr
otecting the security of these legacy protocols against eavesdropping, man-in-th
e-middle, and other attacks. The data phase may also be used for additional, arb
itrary data exchange. This memo provides information for the Internet community.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5281"/>
<seriesInfo name="DOI" value="10.17487/RFC5281"/>
</reference>
<reference anchor="RFC5421">
<front>
<title>Basic Password Exchange within the Flexible Authentication vi
a Secure Tunneling Extensible Authentication Protocol (EAP-FAST)</title>
<author fullname="N. Cam-Winget" initials="N." surname="Cam-Winget"/
>
<author fullname="H. Zhou" initials="H." surname="Zhou"/>
<date month="March" year="2009"/>
<abstract>
<t>The Flexible Authentication via Secure Tunneling Extensible Aut
hentication Protocol (EAP-FAST) method enables secure communication between a pe
er and a server by using Transport Layer Security (TLS) to establish a mutually
authenticated tunnel. Within this tunnel, a basic password exchange, based on th
e Generic Token Card method (EAP-GTC), may be executed to authenticate the peer.
This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5421"/>
<seriesInfo name="DOI" value="10.17487/RFC5421"/>
</reference>
<reference anchor="RFC5422">
<front>
<title>Dynamic Provisioning Using Flexible Authentication via Secure
Tunneling Extensible Authentication Protocol (EAP-FAST)</title>
<author fullname="N. Cam-Winget" initials="N." surname="Cam-Winget"/
>
<author fullname="D. McGrew" initials="D." surname="McGrew"/>
<author fullname="J. Salowey" initials="J." surname="Salowey"/>
<author fullname="H. Zhou" initials="H." surname="Zhou"/>
<date month="March" year="2009"/>
<abstract>
<t>The Flexible Authentication via Secure Tunneling Extensible Aut
hentication Protocol (EAP-FAST) method enables secure communication between a pe
er and a server by using Transport Layer Security (TLS) to establish a mutually
authenticated tunnel. EAP- FAST also enables the provisioning credentials or oth
er information through this protected tunnel. This document describes the use of
EAP-FAST for dynamic provisioning. This memo provides information for the Inter
net community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5422"/>
<seriesInfo name="DOI" value="10.17487/RFC5422"/>
</reference>
<reference anchor="RFC5652">
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="September" year="2009"/>
<abstract>
<t>This document describes the Cryptographic Message Syntax (CMS).
This syntax is used to digitally sign, digest, authenticate, or encrypt arbitra
ry message content. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="70"/>
<seriesInfo name="RFC" value="5652"/>
<seriesInfo name="DOI" value="10.17487/RFC5652"/>
</reference>
<reference anchor="RFC5931">
<front>
<title>Extensible Authentication Protocol (EAP) Authentication Using
Only a Password</title>
<author fullname="D. Harkins" initials="D." surname="Harkins"/>
<author fullname="G. Zorn" initials="G." surname="Zorn"/>
<date month="August" year="2010"/>
<abstract>
<t>This memo describes an Extensible Authentication Protocol (EAP)
method, EAP-pwd, which uses a shared password for authentication. The password
may be a low-entropy one and may be drawn from some set of possible passwords, l
ike a dictionary, which is available to an attacker. The underlying key exchange
is resistant to active attack, passive attack, and dictionary attack. This docu
ment is not an Internet Standards Track specification; it is published for infor
mational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5931"/>
<seriesInfo name="DOI" value="10.17487/RFC5931"/>
</reference>
<reference anchor="RFC6066">
<front>
<title>Transport Layer Security (TLS) Extensions: Extension Definiti
ons</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd"/>
<date month="January" year="2011"/>
<abstract>
<t>This document provides specifications for existing TLS extensio
ns. It is a companion document for RFC 5246, "The Transport Layer Security (TLS)
Protocol Version 1.2". The extensions specified are server_name, max_fragment_l
ength, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_reque
st. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6066"/>
<seriesInfo name="DOI" value="10.17487/RFC6066"/>
</reference>
<reference anchor="RFC6124">
<front>
<title>An EAP Authentication Method Based on the Encrypted Key Excha
nge (EKE) Protocol</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="G. Zorn" initials="G." surname="Zorn"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<author fullname="S. Fluhrer" initials="S." surname="Fluhrer"/>
<date month="February" year="2011"/>
<abstract>
<t>The Extensible Authentication Protocol (EAP) describes a framew
ork that allows the use of multiple authentication mechanisms. This document def
ines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted
Key Exchange (EKE) protocol. This method provides mutual authentication through
the use of a short, easy to remember password. Compared with other common authen
tication methods, EAP-EKE is not susceptible to dictionary attacks. Neither does
it require the availability of public-key certificates. This document is not an
Internet Standards Track specification; it is published for informational purpo
ses.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6124"/>
<seriesInfo name="DOI" value="10.17487/RFC6124"/>
</reference>
<reference anchor="RFC6678">
<front>
<title>Requirements for a Tunnel-Based Extensible Authentication Pro
tocol (EAP) Method</title>
<author fullname="K. Hoeper" initials="K." surname="Hoeper"/>
<author fullname="S. Hanna" initials="S." surname="Hanna"/>
<author fullname="H. Zhou" initials="H." surname="Zhou"/>
<author fullname="J. Salowey" initials="J." role="editor" surname="S
alowey"/>
<date month="July" year="2012"/>
<abstract>
<t>This memo defines the requirements for a tunnel-based Extensibl
e Authentication Protocol (EAP) Method. This tunnel method will use Transport La
yer Security (TLS) to establish a secure tunnel. The tunnel will provide support
for password authentication, EAP authentication, and the transport of additiona
l data for other purposes. This document is not an Internet Standards Track spec
ification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6678"/>
<seriesInfo name="DOI" value="10.17487/RFC6678"/>
</reference>
<reference anchor="RFC6960">
<front>
<title>X.509 Internet Public Key Infrastructure Online Certificate S
tatus Protocol - OCSP</title>
<author fullname="S. Santesson" initials="S." surname="Santesson"/>
<author fullname="M. Myers" initials="M." surname="Myers"/>
<author fullname="R. Ankney" initials="R." surname="Ankney"/>
<author fullname="A. Malpani" initials="A." surname="Malpani"/>
<author fullname="S. Galperin" initials="S." surname="Galperin"/>
<author fullname="C. Adams" initials="C." surname="Adams"/>
<date month="June" year="2013"/>
<abstract>
<t>This document specifies a protocol useful in determining the cu
rrent status of a digital certificate without requiring Certificate Revocation L
ists (CRLs). Additional mechanisms addressing PKIX operational requirements are
specified in separate documents. This document obsoletes RFCs 2560 and 6277. It
also updates RFC 5912.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6960"/>
<seriesInfo name="DOI" value="10.17487/RFC6960"/>
</reference>
<reference anchor="RFC6961">
<front>
<title>The Transport Layer Security (TLS) Multiple Certificate Statu
s Request Extension</title>
<author fullname="Y. Pettersen" initials="Y." surname="Pettersen"/>
<date month="June" year="2013"/>
<abstract>
<t>This document defines the Transport Layer Security (TLS) Certif
icate Status Version 2 Extension to allow clients to specify and support several
certificate status methods. (The use of the Certificate Status extension is com
monly referred to as "OCSP stapling".) Also defined is a new method based on the
Online Certificate Status Protocol (OCSP) that servers can use to provide statu
s information about not only the server's own certificate but also the status of
intermediate certificates in the chain.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6961"/>
<seriesInfo name="DOI" value="10.17487/RFC6961"/>
</reference>
<reference anchor="RFC7029">
<front>
<title>Extensible Authentication Protocol (EAP) Mutual Cryptographic
Binding</title>
<author fullname="S. Hartman" initials="S." surname="Hartman"/>
<author fullname="M. Wasserman" initials="M." surname="Wasserman"/>
<author fullname="D. Zhang" initials="D." surname="Zhang"/>
<date month="October" year="2013"/>
<abstract>
<t>As the Extensible Authentication Protocol (EAP) evolves, EAP pe
ers rely increasingly on information received from the EAP server. EAP extension
s such as channel binding or network posture information are often carried in tu
nnel methods; peers are likely to rely on this information. Cryptographic bindin
g is a facility described in RFC 3748 that protects tunnel methods against man-i
n-the-middle attacks. However, cryptographic binding focuses on protecting the s
erver rather than the peer. This memo explores attacks possible when the peer is
not protected from man-in-the-middle attacks and recommends cryptographic bindi
ng based on an Extended Master Session Key, a new form of cryptographic binding
that protects both peer and server along with other mitigations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7029"/>
<seriesInfo name="DOI" value="10.17487/RFC7029"/>
</reference>
<reference anchor="RFC7170">
<front>
<title>Tunnel Extensible Authentication Protocol (TEAP) Version 1</t
itle>
<author fullname="H. Zhou" initials="H." surname="Zhou"/>
<author fullname="N. Cam-Winget" initials="N." surname="Cam-Winget"/
>
<author fullname="J. Salowey" initials="J." surname="Salowey"/>
<author fullname="S. Hanna" initials="S." surname="Hanna"/>
<date month="May" year="2014"/>
<abstract>
<t>This document defines the Tunnel Extensible Authentication Prot
ocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure com
munication between a peer and a server by using the Transport Layer Security (TL
S) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV
objects are used to convey authentication-related data between the EAP peer and
the EAP server.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7170"/>
<seriesInfo name="DOI" value="10.17487/RFC7170"/>
</reference>
<reference anchor="RFC7542">
<front>
<title>The Network Access Identifier</title>
<author fullname="A. DeKok" initials="A." surname="DeKok"/>
<date month="May" year="2015"/>
<abstract>
<t>In order to provide inter-domain authentication services, it is
necessary to have a standardized method that domains can use to identify each o
ther's users. This document defines the syntax for the Network Access Identifier
(NAI), the user identifier submitted by the client prior to accessing resources
. This document is a revised version of RFC 4282. It addresses issues with inter
national character sets and makes a number of other corrections to RFC 4282.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7542"/>
<seriesInfo name="DOI" value="10.17487/RFC7542"/>
</reference>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations are often coordinated by a central record keeper. For IETF protocols,
that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This document
defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Consideratio
ns is clear and addresses the various issues that are likely in the operation of
a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC9325">
<front>
<title>Recommendations for Secure Use of Transport Layer Security (T
LS) and Datagram Transport Layer Security (DTLS)</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<author fullname="T. Fossati" initials="T." surname="Fossati"/>
<date month="November" year="2022"/>
<abstract>
<t>Transport Layer Security (TLS) and Datagram Transport Layer Sec
urity (DTLS) are used to protect data exchanged over a wide range of application
protocols and can also form the basis for secure transport protocols. Over the
years, the industry has witnessed several serious attacks on TLS and DTLS, inclu
ding attacks on the most commonly used cipher suites and their modes of operatio
n. This document provides the latest recommendations for ensuring the security o
f deployed services that use TLS and DTLS. These recommendations are applicable
to the majority of use cases.</t>
<t>RFC 7525, an earlier version of the TLS recommendations, was pu
blished when the industry was transitioning to TLS 1.2. Years later, this transi
tion is largely complete, and TLS 1.3 is widely available. This document updates
the guidance given the new environment and obsoletes RFC 7525. In addition, thi
s document updates RFCs 5288 and 6066 in view of recent attacks.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="195"/>
<seriesInfo name="RFC" value="9325"/>
<seriesInfo name="DOI" value="10.17487/RFC9325"/>
</reference>
<reference anchor="X.690">
<front>
<title>SN.1 encoding rules: Specification of Basic Encoding Rules (B
ER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</titl
e>
<author initials="" surname="ITU-T" fullname="ITU-T">
<organization/>
</author>
<date year="2008" month="November"/>
</front>
</reference>
<reference anchor="RFC4949">
<front>
<title>Internet Security Glossary, Version 2</title>
<author fullname="R. Shirey" initials="R." surname="Shirey"/>
<date month="August" year="2007"/>
<abstract>
<t>This Glossary provides definitions, abbreviations, and explanat
ions of terminology for information system security. The 334 pages of entries of
fer recommendations to improve the comprehensibility of written material that is
generated in the Internet Standards Process (RFC 2026). The recommendations fol
low the principles that such writing should (a) use the same term or definition
whenever the same concept is mentioned; (b) use terms in their plainest, diction
ary sense; (c) use terms that are already well-established in open publications;
and (d) avoid terms that either favor a particular vendor or favor a particular
technology or mechanism over other, competing techniques that already exist or
could be developed. This memo provides information for the Internet community.</
t>
</abstract>
</front>
<seriesInfo name="FYI" value="36"/>
<seriesInfo name="RFC" value="4949"/>
<seriesInfo name="DOI" value="10.17487/RFC4949"/>
</reference>
<reference anchor="RFC6238">
<front>
<title>TOTP: Time-Based One-Time Password Algorithm</title>
<author fullname="D. M'Raihi" initials="D." surname="M'Raihi"/>
<author fullname="S. Machani" initials="S." surname="Machani"/>
<author fullname="M. Pei" initials="M." surname="Pei"/>
<author fullname="J. Rydell" initials="J." surname="Rydell"/>
<date month="May" year="2011"/>
<abstract>
<t>This document describes an extension of the One-Time Password (
OTP) algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm, as def
ined in RFC 4226, to support the time-based moving factor. The HOTP algorithm sp
ecifies an event-based OTP algorithm, where the moving factor is an event counte
r. The present work bases the moving factor on a time value. A time-based varian
t of the OTP algorithm provides short-lived OTP values, which are desirable for
enhanced security.</t>
<t>The proposed algorithm can be used across a wide range of netwo
rk applications, from remote Virtual Private Network (VPN) access and Wi-Fi netw
ork logon to transaction-oriented Web applications. The authors believe that a c
ommon and shared algorithm will facilitate adoption of two-factor authentication
on the Internet by enabling interoperability across commercial and open-source
implementations. This document is not an Internet Standards Track specification;
it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6238"/>
<seriesInfo name="DOI" value="10.17487/RFC6238"/>
</reference>
<reference anchor="RFC8146">
<front>
<title>Adding Support for Salted Password Databases to EAP-pwd</titl
e>
<author fullname="D. Harkins" initials="D." surname="Harkins"/>
<date month="April" year="2017"/>
<abstract>
<t>EAP-pwd is an Extensible Authentication Protocol (EAP) method t
hat utilizes a shared password for authentication using a technique that is resi
stant to dictionary attacks. It includes support for raw keys and double hashing
of a password in the style of Microsoft Challenge Handshake Authentication Prot
ocol version 2 (MSCHAPv2), but it does not include support for salted passwords.
There are many existing databases of salted passwords, and it is desirable to a
llow their use with EAP-pwd.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8146"/>
<seriesInfo name="DOI" value="10.17487/RFC8146"/>
</reference>
<reference anchor="RFC7299">
<front>
<title>Object Identifier Registry for the PKIX Working Group</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<date month="July" year="2014"/>
<abstract>
<t>When the Public-Key Infrastructure using X.509 (PKIX) Working G
roup was chartered, an object identifier arc was allocated by IANA for use by th
at working group. This document describes the object identifiers that were assig
ned in that arc, returns control of that arc to IANA, and establishes IANA alloc
ation policies for any future assignments within that arc.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7299"/>
<seriesInfo name="DOI" value="10.17487/RFC7299"/>
</reference>
<reference anchor="RFC4334">
<front>
<title>Certificate Extensions and Attributes Supporting Authenticati
on in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)</tit
le>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="T. Moore" initials="T." surname="Moore"/>
<date month="February" year="2006"/>
<abstract>
<t>This document defines two Extensible Authentication Protocol (E
AP) extended key usage values and a public key certificate extension to carry Wi
reless LAN (WLAN) System Service identifiers (SSIDs). This document obsoletes RF
C 3770. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4334"/>
<seriesInfo name="DOI" value="10.17487/RFC4334"/>
</reference>
</references>
</references>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f
alse">
<name>Contributors</name> <name>Contributors</name>
<contact initials="H." surname="Zhou" fullname="Han Zhou"> <contact initials="H." surname="Zhou" fullname="Han Zhou">
<organization/> <organization/>
<address> <address>
</address> </address>
</contact> </contact>
<contact initials="J." surname="Salowey" fullname="Joseph Salowey"> <contact initials="J." surname="Salowey" fullname="Joseph Salowey">
<organization/> <organization/>
<address> <address>
<email>joe@salowey.net</email> <email>joe@salowey.net</email>
skipping to change at line 6058 skipping to change at line 5323
</address> </address>
</contact> </contact>
<contact initials="S." surname="Hanna" fullname="Steve Hanna"> <contact initials="S." surname="Hanna" fullname="Steve Hanna">
<organization/> <organization/>
<address> <address>
<email>steve.hanna@infineon.com</email> <email>steve.hanna@infineon.com</email>
</address> </address>
</contact> </contact>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAIAvN2gAA+y9bXfb1pU/+v58CiznRaUZUpFkS37oHd9hZHuim9jx31LS
zu10eUEkJKImCQ4ASlEdz2e/+/nsA4Cy0kk6vbOidsUSCZzHffbZj789Ho9D
W7aL4ll2vlmtikX28se2WDXlxaLIJpt2Xqzacpq3ZbXK3tZVW02rRbZz/nLy
djf7oagb/Pwg5BcXdXENTcDnYVZNV/kSGpzV+WU7Lov2clwsN+P6cvr44PH+
RdmMDw9DaNp8NXufL6oVPNrWmyKU65p+a9rD/f2n+4chr4v8WXa6aot6VbTh
5upZ9vL199lNVX8oV1fZVV1t1uHDTXxk/AK7DDDeZ1nTzkKzuViWDQ7y/HYN
3Zy+PH8VqoumWhRt0TzLcDxhs57l9NfTR4ePQ1iXzzL4+SKb5qts0xRZXtf5
bbZTXmb5YpHdFs1uVtXZPG/m2byoi5BlsCrP8Av4tanqti4um2fUxKy4zDeL
toEn9PvbJX+Nf4YcFriqn4UwzsoVfDjZy14U31Qfsp2Xs114mtdxsoCR0Ofw
UbHMy8UzGAqs3r9e1kVR57Ny0+xV9VUI02rV1uXFpsVGs2wsDXwN7/+/82rj
Pvp/qqZYz7MzWP+b4jbgjKXlv1TFvzb88R6uenznTb6a3mYn+XL8B1h++sre
Wk3z5Q18+q/TsplWe9Nq6V48a4vrAkexyv07DX68N8eP/7VcXZarolrRm2FV
1UuguesCZ/HVyduDR8+yd69Onhw8fgQfwG+HT58cPbNfj+XXh48fPZFfj/Yf
P9ZfDw+O7ddH8den2sLR4/34a3zg6eFT+fX42Bp7vP9wX3598sieffL0qf76
9OCpPoD0pL8eHVIXp+MXe3QgFvly3dCRgAbH06bO27ZugBJgIfzkT1++fLn3
ZP9wfPDHvcP9Q2r6m8nryfnXz2gpMzm8D16X07pqqss2gzOYnXwN/5GTXK2a
B/ws0jls/WZVZHDCHvOHSoMZ//COvbsFkvl6UzdtBnSWTZo5bG72Nl8UH/Ia
Hn19hj10h5DDjtbZWUEnLvumgFPz+uybXaDdurwmHvLgjj7jDE6qel3V9AI/
wktiz5//8fxZNm/bdfPsyy8XRV6v9pb6MhLQl8VqvGm+rNYw/XUxbb6Ewc+q
m+b9WjhY8+WyGU/n+frLo/zJ8f7F5dH4MC8uxo+eHF2MnxwWxfgynx4UT4rj
i8fHl9Dtm9Oz8/HZ2/GT/f3x0WMeiE77XQFdLovVjLkkjJWm/jpf5VcFfN7y
pHXxF7ew+AeHob8OvAwP3lA7+QK4WgN9bNoiqy7hDMFG5PWsoQ05L6bzVbWo
rm6x8bcvdS90TH96fTbGT//8jLh2MW2L2b04O7606wf8qrioN3lNg360ddDb
9g7P58MDPV0Pjx7rkXp4bKfr4eNjPTyP9g8e26+PD+1XO+GPju2Ew14d6K9P
Hx3Zr8f6Ghz2yAIex0+f7MdftYWjR4fuV3v2+Mh+ffpQHzjet/EeHxw+ijxC
R3b89Hg//qqvPd63GeO1o79Cd8pEDg6NiTxkdvHHvWPmJnFnz97sHWTFalrN
8AqsNwu8uc6AystL3U2glq/yppxmL/Wxd/hYtvPVy3e7I2Dgq2oFzy5635/A
90ReL0qgvNXVpmzmSDedx17AY55E3lTXxfICTj4wlSdbSeT0/PvxeQjXxWpD
nI1ub7rQ4Q++EEBK+FfkjnSZwRNlO99c0Mfjm6svo/ywB9/AnTkeZ/lF09b5
FP46n5dNBqLHBk8cXrxwncC9Oy/uL9cEkWuuVa7Zy0iiyaDlPGupmfFF3uCS
wKfLAiY5gy7yFjYkh4ab0BTTTV1kyBA2K23/omhvimIFbazhuqYFzrOmqKGf
7OIWZAxcWxhROK9zYFggQWTf5rfESaG1sgU2ev7t2W6m3AuliQLEp4sF7A80
tdy0GxBNbkmckHnBGHnAMIc/wDoC98a14M9G2fm3P2TVxV+AL8DUYMAbnFRb
oQBxDbwrTxZoXBcLahG2O7fZYHO4DDYn+SDwzHDtki0xsQsJnCQvekukL/oQ
L0xYkbCsrnFJUNyi9W88eTfZZV0toTeQYKx1krBa7A/EyT2mjWU5my2KEL5A
8bCuZpspMaUw6WzlPbgikYXsNxLDKvQIQPejaGhziQy4H5pm8SN8hPOsoIua
1olfb7LNagaf4OqtmVXLGaZ2k5ZgTdPB+2GguHohOwm7na9uMxTiahA1kJYi
8VCzmzXSWUMDSXebNg7kWqKLBiS0GjhF8SNzhG2noAnULIrLnyHijx9FdPr0
KaVjPADd2boOdMh8VmATytV0sZkV/n6DufAFlv2JLr8RNcDnH77fPjJ4bHyO
wws0PLwYPn0a0cZhC68WMP8BArkuc25EmQwMLlBjryZn5zJXvKc+fYLJfA27
Aas5wpneEnHjChclEQSwxVlVj5XSQcOIkiAKAyM7YiDKgIYEFzJw8EVD4kbu
pAOY5PRD2LJNMAoaE15WsP7Vpl0Ym4RNaJHs6uI/N2Vd8Kmi1llVg9a37f5e
n/02U9BD/tsMeJTdzMvpHM8c9wkf6vJ2VhdoNgOJDvQSYRD2HFAZcRFc7UVe
XxUggS1LUDFGeE6qGk5fgGeWRdHScJMFkCWiI+WXjpddF2bresvCJAzMrQ6O
6/qA91avrGl9u26rqzpfw9TDzERn3gw8YTdAMsDBz+CCOkT2Dkspfz7ElUIO
QEQWqMmSX4adTVrOfMs6OWTAMLnX38OyCS8BMgSpPp8xRyqQvzZwMwO9kvYL
M3wD54+5CmwWbG7Z4ihalFBRyoDVXlcN7zssM7EImrafx34gqZZ+PxgJczdp
HZRt0B8v8NaZFeu64PtNB43KF5HABO7fzXROc8/83ONwiQiqFYwpX68XMDwc
Fa6rLCdtRYgfPIT5ffEF2xdAnajzi3KBHOO0aTawDtnHL8rOV5+6ZwF18hwW
ERjYBdJLWwI/TSiVZoEXohJyUwR9wBPtFH5x1yCu2LSqa74x5AbM25AQG4zf
8x1oje9IkLj+ArPkbnrDoJNBDLkrWOLSpnR0AQwJmbJjV0SUSArUY7jBbpeb
RVuukTyW8F9cmdwIM+mZxJTix5aHAPOxlbzJkVJhuYEESBwpLy+h6VULawNy
VJEjp0ha5+UM3S5xUd2+LYpRdrFpmS7kYMNeFa1MOFxuVlNmw7j3enwjBcre
feawz6sbo/yq/tDIGlf1LXefL5oqFD+uF0QtN3xN6zDkRWgerhuZczIFmOqp
42YNzrm8vJWzgGNY6x6CoJAvajjTtyiowtL8mI55hJdTSAkbemOSx7XTHYEl
aIp1DtoekqeIZUVG1ptFMImDGhFifAvqeoNyRZH96c87XyzKZSm7AprJRQES
y4i24HJT0704K5vphu0J1WXoHjYZFB/SVAl657g4bkyRfYBbFxYe7sgHyOAe
jPjf7M139Pu7l//n+9N3L1/g72dfT7791n4J8sTZ1999/+2L+Ft88+S7169f
vnnBL8OnWfJRePB68u8PmMs/+O7t+el3bybfPuDt95wClxa27qJIqDxvQkJx
X528zQ4eZX9C1frg4Omf6Te0jP0ZaKZYcTdEyvwnShsBuF2R1yQXgtwxzdew
6osGngVyBbo0Xg7LeF7UeDuibSGE18BP9di38Yv+2IGQEnaGpjg8EpPZrBRz
Br4v9ENX3Yz3+xnszu26GH9brK7a+fiHfLEpUFb8YTeE53St0+1t1LRpYev/
ipK06C/litQZ5j4iCcQPoA0cp/QIzyLZwYW2HreL6zE/swszP4ULvM5e07WN
HU9WHS1I5WyTSBras0ZvEj7tqCHB8S1nBbSBZ40ukuJHYbT28jSv6xIFGlQC
cYIy8JKGwV1BCyLU5yT2DA8INhEv1Rq17OzLbJ03DVI5vJw+PsqIs3UFzcE2
WaqoiYHjJsAU4BpbiW6CGpDXNEcil8aRw9ObxYw4Ggwfh5K93YCYPyXL2Em8
P25Ncs123n5zAvqBLhUSY9TAvoNlui6LG6CVgYWopsAUmZ/eVNl6DhwGhnjZ
ilpFcgCaO0A/OJ3he8A5UMoD5ePLugCVYAUsyTomRorvXZZo/6TmRkyEBXDL
6haVnYIWxSsz8PKsmecf6AwDtV4DDRCrTZRyZELaE8k8HV1+bdqMKUHfraaF
U95x+aO2ORvRYEBxqqAxGius+BXdIChekVqpGrrYHOCg5Vd8ZSufZcW/bnIT
JRLFTGXiWXflUVpiY0/5V/5kXcE2l8CTxXayhBUhmZRuMWd2gD7wENyiiB0i
AXWJFvYHPSjC1uhOcJLGKEOJD3kkLimJ4APiCOj8jd4k7tpGU/0IFTga+OHe
wR4Kv9iPCcPx64d7qBLSQGHArMJnRk1yIfBRRfva7bLaNNmbosWrPptMp0XT
CPFdlvD2zpvJ6S5yjwFp4ujRoR/WIxILWaAy3hofOMKBZSA1QBdw9Qa6UlHG
Y1kNpE9WZJiJ24hhFAs4uYM9AjmjzteS/gZiiLwEuyoMbFZBTy1w2AUwcGoX
piMMF3kWfgnnvlWFW00SHcVvRH8b7fAew1pVmxXp+TuTyWQX5Ygfb7MVLyWJ
+RmL+W5Y0Dos+lhHwWJz+QHFkpbGGmgfYOeQNeNi0DIhQUOXiwqtodIDShOT
1a2QYxn7QMUeeSgR4U3ZFLu67SS5ucWoE49AFHEHKCrLL2BQvc5gDE6ytOsr
d9YOpilgpgW9laPxfnKyi/NdlnVd1WGLpmz6QCoWA1sCwaoskNuQiRLu7Num
ROmDb/5CTF04Q+iJxHHcaLgWYCB5fUuck5RFYZfQHu4GmkVZhMPDvGQ51Kye
cEhuxGV0Xk4/gLi7xObgssz9vR22HNnD5Mj2vn4ommEWNUMcO/DJ0NEn91hK
pIF7bqgqdcoUgQ5oMnTg1Tpm80RV7HYt2m98SSjM7tJrPIipdTiomSfS+/dw
P+HwcZUvNwsxJYosj8Md9WyxZBdUCzPQKyv7cE20dQWrrsPEywhOLHyH1DPg
vnOi3C5vPgokeITxeEcrN6+OG3aWM3XKGIDbwdWu9gvYTFsTsvPCYVx9EDtl
o0Y5kGOqaakMHATTST2dl0j8G7RIvq5mxYK3zPpMHljiA6zb42psiKRKlXdV
9Pwv+AnZP4/t55/ZZ/FzPwnZT5n9/JT887lPWPKEX7mNtwX/9X9hu8/hE+aZ
Y/cJz8g/w3KrtdHrgzguLEX8RHZm6JP/xlzsk19kTWlzPj5j39e/PKBZD1DB
g09MB29VznG3DMq8TuPQOza9QomLjOLxl5Uo2Xz54CIHtrTqyT781IMejxpo
W4T7B17JsPeJv2zYUJbXZnRwI+GLEQXMhZhUezrHjhe/GzJ8j0wXgL+Ldrq3
G1gzUVkAJViRMnkB7aoDrljSJQO30zUbzUDtI5+hPYNDWua3yAnxH7xjyRqF
4jSxAzUNOLa3hO9QGoH1eAXvFT/meAUx/zqPviNqe2Ct4GK7mrckZWV4fSxk
yLe/pxXL021Hg6Lbze3vVnVi5TFZKWlvlPU2ZGCEwXqByV4IWcBaWJ+g8jS0
jrPiupwWnYUIcmtQ2Ef2ZB9usAPcDFA62BxNYl5/cCJdMdMN6wr6BOHp7a5Y
ZPPs3eTF6fdnthSwX6qh6NLTjIiIxDGlDye7hlTCNDErc9Dgllm5WKA7QoRF
/Py6xPsjoIwFj8JGLPHO8aJanl0VK/IrLXMW+lE5Ab7MRrI8gKzOcUxoYbqF
a2mZuYUFGaPeIHn+Hh9nWSafog9UHm7iNtRFjtYCINUK3Vko8tzKPOymwRZh
KWozhge0EQj5ov9zfTBeH+4mSl00ayQWKtY3l3Y4kZaCtiTyjidKs5kN0BLf
eqoCj8lnhW3ozUcXPrIm8eGC5JavQVmi6/iGfb7wzO9JMkDdeFOvVJGDN6J0
brYV1dm0VdciMgvnjSERgNwDKBW5x9AS0WWUqWX4fL5p5DCxoIeCk9g5ojLE
4iFIBjhr2r4Z+q1vyCpBll4WF1zfrJbzx0yjpZqDWDbHFpVsxZYuREsObtyu
ebkOKpCZ+2FITPjcDwkEvKk4U9nYn7LvSINFPditCl259287uaCxqZe2CNgY
2s6aXX8V/4y2h6eYijf+B++Q7g/Mci2H4ztSlXFAP3Mc95j50GhYLrrz5+8x
jnsM45cdxwmZE+s0ZIGNi99O3oyE/4+yF2W+RHVOBAIZx8+g6+Gfnqi2hWup
pIZEyweVQmvW+e2iymfqEHShKYkGOGi5jfbegXgWsTDl9UUJ3K4mAYsXoLFj
LrbVGJrDf1sUy2SxYBFLzXbquGGJpWuw67NiuvBsxsDVX0tEA+om8UlcJOxY
OPdUdjQ6QbFh8dsEWZWuHBXFhj+CnNuNHQVNGW/+ixjuE68A7NlH9iRRPYms
8XshJhF2jx4/xUiC2khLrA37jw97/WWD/YW+OOPCiZLL0LET1M83jbBY/KRz
I2LPGiJCL5AeLAIw2RLFFpRKwsFMLY3cGsj+Y7/skyD/dr30poG6uERzc5VV
yvuoV9dLiL3oTRq90dgT00q0PKMxW2whSnMh8YUQ8eetKir8Flp9eM3GbTWm
fTSDCvq22ahd8NfxYX0IjTgsxuhbJfp18it2+HFgwc28WqAARcqKftmQXwNt
d7x85GWWRtW/cr8lpJUj98pNDF1z2gpZ6On0vSWD98HIU4Y///Nise6Ysv0u
oNt1Vbmx2cvcBzd/GA0t8HJA6x56EZHCvOjz16KuSBtCSTM2qb0MDZGcHLSl
FgJD/NE8pipS6o6PhKaRWcjciZhloCMhBZDK1hhEdMleuoZ1UROGyEwrc3IU
poESwmrlC+G06J/VY5kGAIC+MhXZg2emrZCrLXl27J/d5TOtWSRviquqZXtP
9vELCQEar+KnnzonXAIrgLk+HAN/t4bEsh1lPt31V4v8qgnyNR9AidvMLjct
RXGRqNyJFmCXLBoBbjDUB/Uh+AYDR+i+WtegyaGxX4bcdPdMIiE7sRQuclF1
Agt7sld/3x1MsC1NGiM/NuWqpKtARxTGfwBLrV+4FcV+pkUxa1Jud7CXesCQ
Sbxjd1k8lcSbQV0t/iU1QYoeTCNqJKIqHZNYCuegomGLOusyRiXCaA/3lA3Z
5Wwxi7QA+lr/gLSZGCGaQAPlCx1mII4+eKMz9nimsCltebXBoGa84NcVspOL
2676BuN8aOM8t4HOqoIt4zJiHSA3o80jV9AphZxjNfXLZBbZvWZBzL0phJ56
K44uIV1x6TWOBebxaGAedDPZqht5UzNoMmFTsH5x10KNTGE0tnNTglzFfiKL
D9sLpxJXMCWfazocIL1ZQ+dQF+NN/kHjJ9HLI4RdwGpaaJAtEll5KoyeJIM1
MmQLxaUHRMC6zssFxdOEcJSuidyTg7ub0kzmliIkk6CNpbOh4ybXSt4W6q2L
fge37eEVjAoZFEzCpgmHfVXc2PhhwMfbBzw02KENCzxK2q7eiJDjlqsN+XO7
p2XrlMW2eL2N/cxwXlcbEMxBcFCPY7rzTNo0GSIbUOGLQvkIqf6RjUTihlmR
zIdGVXKpwdoMjeIS1ra5J4WOAqsITDoaeE+Gt3VLwYQuIpsbKFgSuSjizs0C
JhN2jCSNxA0gQ/a+KOOPTHVR34D54a1GpmHy2okRZVnN0LJBKhMJ3GQG0eAw
7AU9etMW6OeinI1n6A7J2xbPVRUVm8iKUJ7AbWiEcDWWpXdvCfGDfFSABDDL
YGeRSpQ/+DWP9MPBIOOvxG2PelLiEo8yhLr2Uf0D2eGcHa3YVa23wEBjNGZ4
hGPh8uQEBBuqyJgD74PoM52LmchoDBkLH5pgQyj7a+fJjERgPO3FjA6vxDVw
lH15BQoD8uMyF2tgfBJZPjxJg9nB1Sj9l9wMLQmsiQ/13LoYQCLX+aKckXJ6
UVyiuJqvbsO2ToHnuL8w+gTUTdE+md2Ega7oVAnhx+4ounKF0Td5I7S1koDh
PFyClr3ICvRdszW6EZ/HrBcogetAwS7jwzG9QNIkkgRmEqu3FId+qZzz0nJ5
OMkl8r04uxFLDNcUg3YWGxH2653necOcV/m3XNPM1uEGmmJeIsWx4mP9tkaa
DsQcDSOlhJRgJT73skjyRr6Dz4f4PG88kTIfgi7hxyX4fVT/ObohNOWC403R
0k1ZABSd/bkxRsWCRO0gMSPTCqQt1IgtPAkjTTai78lwIpOLA5PoRPIBdtIH
WBGKGeyq71Fk4kcmlANVH+pigWbfKmqVMXJra3JKvuokVyF9DsRqnUuTUTq9
JPO1MItuJJaeR//Kwd5hJlkoNA5YUbziNKEqdATfAZWFm/U3ftSFUIGdlus5
ydMlpr2H8E/46fuXJy++fvn+3dnk/R9Oz79+P3l59v7g8Mn7fzt5/f7s68nh
0XHyHPz3jicDm7mTjrLXk3/HudoFjeyjo2rRwG0yofWxNEjmSXsWxvXw8Cj6
Wx9RRIgP6Q/s2Rp++GHyMIb7nxI30mhgPi4W0ZWunQaf0bq8+Po9PpauyclX
J7gm6YaCWB1cphaJWUjBNyp0JaGU4nVqAksbvQA5DOJgd1qMoYJbocRcgylJ
SejByts5rQNIv2SeQqso3fnk1cP4zmRiNGs5sTIADBG8LCXWCN1mGjytBj5o
6AXf+EaXZp6xT2AjyT3J5BBlWQ4xXYIy3bBGIk1Fa008jUgbI4mr1Qx3pS4Z
yCvKn+IlkNuwqFtWmAuMOUWOozqttSIZPvvHxxJUhGf2tSYu/IwWnh5jaJfL
yEM32YJy6dAMl01jU2NhfxbfrDT13QoTj3yvQXqNRv7vTs7e7lqf+8y1QFwB
UY7kFbx3cauAV4he7nrWnQc1yUlmoiDRmrqoCUzPRHAESZB7TJSs7Cse6RC+
10jPs/Hbs2/wKHXi4dXJOJfwMQnDQhmIJWWMFQiaG4SNME2vKHdojCcFpPUY
JkRhavgRusE71hKXN4R5oZkNC213FJOwgxpV1e6K74HMAbNiXbAgU0kWDK87
hXOTNoE2rG5vPMpSrbE1C1Y4Qxg2xm21VWBXPvolWVjxwSYUpKxe9H4UmtMG
NXY5iAWMPaX4ypdAIejPJQuZZuDyX2oM5/TUNuMnd852w0XZjvqia242pihx
DRjlxCoocc4VbkkoNcYUb+14J6qXp1Qmx1HZOrwGo6tbcc4Hay3zrWU7E/18
fPoCP9n1BmQf08DBdNkcQyHkquSV/l0TmyQ2F30UuEvliozGmpItlocF6kst
B96AolsTz5rG0EtObKNIw2az5JdZ1wip7Soay7Zo1mnUdsOEGLrWH1m0xBDn
FFdpwvYYFL2WhUqz4f7cfVZqEqkueMc7mfrV8p1KVCoERreCp7JEJywbF+Xo
TBD9s+DsEPDLIqS2R0vbZWmrpiCQGQUCowujVmO5pk62FPuDuebJyPHkcPyq
eD2SpAChZV1yajIcmoxDqSELjHvhcytDG2NOImEq9FYI2QPQ00bCe0SXxnzc
aoNbVpdrtIsOWqgTeU/EBJ58KiizQh6G7lOnkfelgYRAWrJlJx6FAdOnmj28
1Iy0lkS4+cwYNIdOKTMNoZwI/2ZB57IDajCH9bgCWSYG4ES/rCXVUES17bMz
psjURXJveNDGDnxIhraqZoygviAK2UFVaFE1pFg6P2L0T3V9CJjIeEMuqMim
rN81ZuJOOffQjr59K0sZYHbIoRYxYImTBP2oy0aHVswGRhagJ7aDxjMwSFES
2O51iHIptoGQCgyW5OSCn/UyExNlj9iDbft28INCMx0TYlQtiBym0ayJK9dv
ANfRs/sbNvGZHgSKIJ7TLvzBZKUedW0oklh8O10F3lYyq+luWqwxkOJkTSLF
j9mJ5Coyp/IiZZqw2H9AtSPxaVOOKgY8TBbtG0z9Mhl0FC+A2aqh7xBcisLp
Mi8yrLJX/+fFGwwKhz9h3tLnNOkTGBoZJ2K/Z9wvvJnIHxpUyXQ0yh6cvPmX
B/4RHBB1mFzHKTBCaalCrhvK37O0b43oHqmNCD64KGczdjmyknfklbxDSc0t
MKT9e+K1UV4Xhi2zm0kmrghumvWk0hq+BQ/1m2l6AcYIM4QSsi5frw9YgVLC
4fnMVhtUDlB5OeMgRj2E7Ncjqmq9PoDDN3Eo2zmZcIS9RPutyZteiAq45uy7
k4kGcS6rhpI2l+TkIQEqPkMLcFlNNwK5gLt1U1yoA5isP55IdL3yxU1+29BB
tcR6AyzgHMdTvr3rvAESsTlNmixGALIioJbC9aZGv4IkgMlToCUC0U4l7wAz
MDhhtmxIDoEP2EBf1Vf5SrKLth68H9g6WRI2THJDEVtzp3zk6DbGbMNgyI+b
e+VKvRPkAaFp84pTaiIxN/fsinywZCsNZis1MhHUgtzJBE0Jdzxz6hvN0zSR
J9CFgfsBCrzv5tomSkYfMzfQdYPqGMmMKiS/RCmK+ebOy5e7SUtrtFDMyDQF
UhCl4iMMAeeko7MR3icgR7KUTedVkrQHJ+T/ZtSup58+/b4/FDgQouGUlKzC
y71KBQG6RPHswTPDbeCAcwERQL2MDK0k6Av3Sxv0Rhcy1mdNtSxkx1Qpr1YX
VV6Tboia44OLqmox+nmNCsOD3VF3a0Ncc9UzZgXGgc0836s0w9M1T/sBV+Yq
UMz3KCr0kn3QFmtvFKeEFpEEW5mpya88H0z95nMhSrSnGnGUCPV5QnfTMRtk
HAclga8K1eoavG40qruxb4UxjZMo4vC5lMwjMs958x1iOXa+3wuvBCvgagOD
wqW05Ix49bsRCw+5JLnaEsuSK+OYrow/9I4W7Qq8/mZyOrIPmxh+wQbLfLEk
nsurT9rJizdnqLC6UeSkXgzdV9T5ubWk+i35MtG8o/Hv7P001B7l9qUlmYKU
1L+YOn3tHe4Z1BFzgPCggatoiigPSzg+DySGwACpcINV/Kc1WulM3WkdZjvd
lENeuUAXpBc1CdWue5UiCWlT0JG/gEJ+hZgZ6NH8sEKJi3iPcB7mvqovbBmC
KU/oIlFhhdefQKd6MiVmmlqv4SwVxfBRVMhV/HJRbANnKnrtMOxTmJZL+hC5
iOKO4IZDTkLZDZJk6y0SFFCKV6+ceLpz4mXROfHEEMlEtqq6iXuqKs6LrhJJ
LuqGFHrhqdHapY3d5GRzpHwgDm0NbvJ2KC1QrHshyp0aXXQuN0gUapBCWoQ8
GHk2Q98xi4txs8q7vz4/f3tGJ4tHC+t92T/dKxTkC7J1X23QdeNpaaT3CFsW
L4sbagTlFJJ8YM6OROOUm3TDQRD5Ijth7SOR8MluIG5zDe/7+AXrKWNsohmb
MyvCLsF9NhW1ndvsCWfet8ZmII8hhXMIThk1NUouYhSBE1et4Tmpwor6UIdM
2PMblSSUBAyRgY0oYpLuw89VSIWITMMxm2WTCF5Mc5Zei4lnIi6klvUsOXLv
5wWojOTdRFOtDkWo6r0ZZlzUK1txVuYkdy6NQz+igFJ+QxmCbEPCnt7LmNRu
JgqrCSjxgpBd6y4gUL5Y/3Ba9AjPASkOyTAX2MOqls7DCnv1Wmm+KOpWRVEz
NLOBX22UrqmghrVoDbcQWIEBGzJx8oTW6AkH1TUdwdZZOJOa31cJemP7v9+5
kd9aUQbiB7ra0d5INygNrAZWWqplNWlExvOhuH2vGj4DgPmWJXbEGTLPSpbX
6HgkphDGIWF2TxwPbmQMjSgY20wwKoiLmKWsBt6PiGC9o4uJ9xhEwZzWHztP
O47eOwREci5lgu9c+iQBkcN2u8HVar8pk9hq23lkbmb9cCadZAlUIlA4OnVe
R1y6Utyr5g9iMpIzsJVzmSfRjQajZXSQYvPFie2FFxWJIpWS1Gesqln2ahBt
imEmEWEqxkazmC12clIZxqwyjD2UFama7wzsIIRXihewZiFkUNhF9BEViRud
jXuNcOlQiPeRxiRRiyUE6FLQl9HCDNdcSQfQZMO9MABD8Qh6Jf7ERp7YgH+T
b9k2qDOaPc6IIphkPzp8B3GqDyCF3gzgFfYQJMkskQIlKgIZve96UgEZegwu
kIJWB4MpCH41r4HAaj5KNNXYdtIU9hBicobBJCmIZCdWwFuyOCyx4UwGgobg
7xo2ytlxamBlMTO7mAU8rSAh3UbvSDfI1EIdh5rE4+4Fq7oQaJ154WeVqBp9
mqNFCcSNO26oPCO/iJ11ZP7xDu+5TALKT4wox/aLSrxTzi8TVU0JdeSeoql+
oqC/dzo54uwQIIO4kjsnqOGhGYk4CUPlLZFyZflAblD8OIrFafUvOPPdHH82
xXXzrMgyUKyuy7pacRC/whBtViXRH6U6o8ZPgiJmxSKhjX3zMGYDRWzLJXlm
Z/ktSWO49XNQw4g0NKAKLSu6KH5/bwhsC85uTdh6pBZW+SyI5Y5ScjGD7YLA
oW45DpSOxzKHRWo3M5gSSIUcAV9l6CoQSBeQCBp1VscgokYhJ/UQcdq2Rh0z
O4imOqDbWTD8VvGEMRBBLYyf/yTMIRGPkbIUiiRyUtlrseJhPEQBAjL3oVlP
1IpGew0gzyCzAyWvcOFv3mpBMbX8/RBwDcunSof97xNRVSkeKHI6L8S+xm+c
vhhBj4S4AstZF63INF1fhwaNtS26xz13ya33C011YzGLVBDXUSCXVR4zVTqO
zhVlB7A+8jVJmN1cMNW9QErGZBGJJFTpP/akFxHeu0JMLoYuoC/I4chFl2N0
MOqUaBN7Yn9QeIkYPIg71xlAwlnMgywSxLD306iTJXiuZ8NaS+R+9yBMUeqI
MJUCY9pKwpUpJqfhmyoeDqLoi4JOWQtKh51ikQ/pnKS+2hQ8Kbo2GIEXxeLQ
BxnD+ihd5CQyet0ZY3n4LKJppw8wi1AYutRkchdknzoVEb2erhYHdCRXibQk
+wc0aVl53EZBRoRLum5ihGXew4DpmntpbKplowbr5djYi4W5UXdqM3DvuQtQ
UglyCaAj8ZOi2qpl2ejlbfhGzjGr0VAMSuXg/dx60F2goyIXcNNKUFKDwF2E
NSF6UKNhgBQu0vQSkn2+9OczrJOlECdPoacwHwg0j/7d+8TyS0UEF04rQdVI
V9tbsufH7vndKJWpH4DEqO7e9yMTXcgzqazBB7UobN74a4wnohxOjsXXzzHO
SCYDwkDFUpcGOTieh/vc3WM1EXgXyaJwmYHKfqfzCn1veQ+alKyNBs7hLYLM
o/PW7Dsu6mUobsNhnPTmPIqJPV0xFc2uOgAfvFo2aUJOK/cZC+JLtKyprFFi
YINN0LcyUq6OjkBUIDFzXTZYvQkoarH4K1YN783RaHkKJVc3EK2K0YmlK3hK
4Y7tq+qCTLOppXQvIhoYqVqoHccOOLi2JEfYo+00XhvvYwoMpD+w8gmHdZcC
e+NHivq0S+UiNNJ88u92L5qzjg1DYfDgZdEigiPDkBpn5s8VILErMLNtyuhC
Q17UPKOwzulbwWBwhDaSYeu7/jym73Oi55bFM6UlvU4YLdxTmdekZsWU1FzQ
NcWRTNMho+YVgS0pFKkn04qht9kSmGQuDAa6qxAJ5Iqo2Jzw3+BsOagwhfRS
rZTtiKRbvUY5dcVwBt8PAO+wDdZ5AbvDcPiVDIjZsZJ0B9PZbb3qBFZ+VUle
jzdQ5Qxf7xodbAmpGje4F+w3sHg3ghso1QRaiqRAtw+zvaKl6PaUwnSLkE8Q
ED8X1hLz//itxvPVXDoJPuBDNEYxB7Of6VpTifcHBlFWxHE6/bw9HILWGIEM
DoNijG7vB8WckEpw+fPbc96YbalTcmteFz7k/xxyo3SPtxCjiMIJaNV3qFXi
CD6mdrFKPgeN7MWGlVi248AKRW6WAsHjvDhbUenFysAgcmcCsIV7QqfBhYTP
si5SfOLO7adeIvaphpMgTcVqBekZ3BInJ5mVGFej1Wq4GAPqSg42nMt5EHlk
L19zeDzbrtAhMnLZeOLFchcY1m2QpQwYodwwxh5Wn0FWXvLUktuXoDTOor1I
Yn/Z/UVWElQJycshuSD9w9aJBDSbDvlFqMqY3je0E8mdNhAIyackxqqq/YMS
sDubHXaYqSExM6fb7TBODGi4lIgkXXmpfSTkg8jWCMQX0ccIL0Xt0FhuoZyW
eBmy/0Jo4MGy/FEQDkHTfRASMthje65Zg6yYF66o3lZD/Di55jgvicxDJoXU
BYG0GV9PX8eIEwQNJAtnvkvaeeJXpdRG81tWkpa8pTlLRQ/ymCQGssqgqn/e
jY9khaSYaca0JUugospAygQBfpso70JFiWbuYnxwsbqshrzrsNRnwBngClnc
xoxJA9FPZruVqJLdywaIiveNlt7OK58/KWsjkqKZWWngUXDPzV2qQWEUuaPO
a47kr8zdxva3lKbk8LAJb2a8jKIyC9LLSDZGlclz12Z3e7WMLPovOlVgeojw
puPmjViZsaQZIxSQvNx8KNedASsSdiL6mkSgXniCH6JwBaT0BJnB+DXTi0jp
/IYaTusqXwotq9wdhE4FxxBpALUmdMmJPhq76IYuCGGinOa70jPr9hg30KM8
yhbvFHtXeyN15AXRYhEbmcLS1d6qd7Pkh40n/LZcsx2FW3ofcxeS3U5KxWck
VtKuNHX8Au+9bXe9r+ewNblcoTGacGkpynBNUTo2fu+FxSScNZqjKN7Eqs3A
/nEy97SaOZAPtmpuG4VEyXEAQL4qdWqR1qIDO5gH2myEVIAvET+phg6Jsf1I
b9SEMZS8J2NcF96R4XoQXBsn4Yd0TEO5585nmQ/KiqETfBiFqwFT3Meo+oFM
hQ84mG5ksfPyAg26QofGDodFOfVWWwB3L9umdMgRrCRcbxYrlaxKXm/LMY1J
pSQlzGaY0UkpQvSAShpBT4yP4E9xpfrx/KUuSbQKkc18sB5V7x2e8E6za7G5
fU3xNKEDgvLjwo3EKkuqskmQU0xSU42I9HBENPEeSoykRCDVDguXCE4LX+Sr
oto0FElLaIWLhSWWp49jlG8QeJIZ4c9P266fSn3IOxY82bf57kqxFvTVbLCC
CkoYHObohbmRBO3wYV+KSBFT4BRASs6rmoI1CTfwe+SLci9pvIAgM5As7Po2
zVr0tIgpgFuj6T4R69b0OLLQdfgs2jUlb4uZbJbFGCotaKQppiNDi2DMYIzu
FkRGiWUFXVICywRcmaAsOw8p5Br6SsmQR/Z9XT0MINmQpZBLZpkjP6kO1NFR
A/Pzl3gb6L4PVQfS5Nwl1aHmZTVMbi4Q4AeDrtfEtmeKgrbEdo+hriQ3NTig
sC+t0MiOTsZe97u0m2BqJNZOE0o4NstoYGtarMOg8JhJnCs5uvvuazQdn6Oc
QqCqCwMX8MD0O7V1h24LTOD8zL0bo07pm2pQ+vbWW3nQru2RXT2KMTVwjw6Y
C/ai3EVvOQj3e4gLVGsH/RA3Kx0RCZYqtWeVFa8Q/4GMSDCn8DbEPaScAWxk
YIAkDA1gzJQgqqSS72f9DCxKwwA2OPIxgZtvVrMxnALFkt0yYU1RCSr4+GhT
+l7t34IwdofoMUJsFnNPukX1mBB3+0PYz8EAVx1p3kYg6+5C7XqWj6C5hImr
ibU/UQCMwDKTC+/XHj5edKzviBcaEXmG2YnenUFcTcKA/YukYSCcwqILiMFD
r1ZFqvVFkC8Pgi9e9a7dP2oHPY1ClUgcNuYcmq3dC21qPNwmuelbgoY8WFfC
AQJYSbe7IkTvMFt2L8KLNcWhjEHx0IvQu8ycEE1YB+Vagmm3jCOGBncQC7eM
qVmTLTXvVeWL42rWfGA5NFALqIpyxZXuyCUkLRO025DbQbUAM1FtGXnojvzN
5Jth3vyXVCK9Y9VFh+vYyLqkLiugJnRhmxlVZvNFR6W4q6SC3LJk50U7rFgt
KBZM+Fu6ZM9bM89rhoKQDhPjaV02H6z+EwJWq8DqoiZxBbbNatgJHRxEi7fX
UDDVgzlIvcWHoqBEqizW4tDo/TxYb3juMFVCEsfFZsqyJVuFlANxSl3i/IX5
p9NpkiRNAw6PtY2ga2z6d/EgjoTbWunTHBnOGIO44poYNhB8Ov6KrDrfwUP4
pzGIJts5/+6cIFwwI+748CEVzRx2Fw05aGQGvCOXjiH1o+o5hpgdNLkrxixu
NfQ9JVADGhPr9zwtq3ZBdxQ0hT7rKS+KFcIL+XUFu6C5s6w83MWkPCRZDG0i
A2XMPcZIinWrTl9jWXD7rxd4VYjMgvu1RynEcv92Waesm4y23z6mXrKFOOa1
hljoTLQW659nJzNo7ubGZHdt5qhzcRZ7DNIzhAq61nMyixqzy41qPHo4zooz
BE1uuIvrdli9jjg4SeWOoRvyPUVddVxb5mVQ6RNFd15PKaqs0xE1R4wi6RoE
WwPGRY88PuuIqdNqzSKkrZITnsJd9MZLwamqKEDEyYe7XkBOeCbpPDSCts4F
aClu1LSuQNA1Dd+4ARMcZxdInELfc072CtWbkhLhKM/cORkrv/aj1DzpumRp
C4iRkR9hqbZvAoziqIWknCKZ88rZjEEQOtxE1CMkn1hV+nOrHT6nJGXblaQw
qCT1aEKzR36e6mKNydHgv0OUe70cvbXRYY0rDGtc2VaNpmvLj2LbtsipuzQa
Zr6f0WiyuzWacC+NJrtbowlbNRpf8fc8ms9fSvHK8b+dn2QDeaxHjw4POHMB
+Ezw+SSWu3R9AJOb5thg0ppwdc4wywXPnIwX+O1QqTgOku9cyszDjY9hodvg
bP/bhKOOaSpre9jwokvggF6fnXwNEzkkZY9NaP5jGOE3k9eT86/RrOfMZjHd
wkxnPH1r7zqvaeoDy3roS5QeUgq20rak8ERzNjZOPu1UnKXWuC8D31AdalpY
oZFkKprBk4yTwdQESYt5ugJYiYHx4DirgKQ4EjJpcKCe5c7rs292ObHjBkui
zziZBBQAZ3zkQ+4iG1wLILCdUhuKQiJ79W0MX8iq1HjZdAMiXKjDp63+9ijs
Rb90d285Xi00S7rEitZETjX7ujIqnWXV7a8ug18zZkxNkXQiYkYHMiSG9aVh
bJI9Jhnl8KpkZMe69hyVgQ4JKgynd2U3tmJPUUT9WPwM1zcztnCfnb7mXybf
TEZi/cPff4f8zZA2xUqceyAoCcTxmN1c31jCNDjK6uwbctW/PHtNARtRAOYw
wJ652kHUCP8JuiNzDQ2+KOb5dVnVhhrIpYezZLZ+MIFWHWNGhO/gCwpD3Nnd
rb0E7aW/slSSZNWSX3uU9Ys7Un94lDX+e2hbdt6+xKqDf8J//jyKSqrTUVkE
0jH70sQ9QNEYUDJgJZJE7l7cGfnuTP6ikkuaJ5d4shStyemVnYvIT/Du+qFH
MHhNAHr94mh8Mke3DcVO9lS+bAcVPl7hf5MkuvMKowVOEFt5B66gXcVKlqq9
+XZWxmA3CkzUeS7QcxhntBuPo/ruFh4a1mPBzl2JxZLrOOLph1HzmOGK1FXh
2u7kNxEA+QWaeWugj+scMaAkBtoHNktuA6V1NloHMlWhW1yOvegWQGKB7oPe
EDgEAlbGnb+AFi4xqEJdJXcaXELH5NSJmDXNijIELSZac20TAYwzRPsRV+08
Sae9i6VKIJbDCMVUPQm278QFy2UzfHBp2W9AgBcsJykYW17N4YOkDjqjq8ot
171Q/K12OnBWRBVJSGa0PVsvkAZI15cPjOhfY7zoaKL1uCm95R4McOsu9xbj
iRtKJ0l1aCFQIU6u0qgckAYVFSiP3ZRmGaAiHIRXM4RXcsVYJi35Bods2Ft7
Q/VmViU5ZyWDJ8aoh4FWCWbIggCx+AF7Z8iWLrWpYhb4ZZKxrG5uBd7Co0Q1
iAvJHBZVejDj18IdVhrPbpVXXKQgwo6J6iWIJ5YMvFnPSA+z7GU2kq2UfYxE
bdM7gJd7BZQ6NJ4sVkHOw+ADZroTFzCjCxKqH5oPCZZMc+ncJOiqXBT5hyST
I7/A2Hk2Topu74HU8Hk6xEFiMSXzGhbKomp6w3aaVFLEWcUMxi41sdESeC7F
0GdAyuqfJsm65NzqILAgMWdf2EUfoqBflCRnhhU0R1rtjsbt+qn/Q/nglMzt
CBM3IiYkbB9MFy4gOF1lVqn6JLKAw8BEclNhSSLeKMj4klNWOgcpAYsgarss
bjqmUiqPlHTpqm8Ljz2PaozuiEfK8jtXKtIbw0Apa0BZSnnDphlaFabeHn85
M8wYxe0g+RKNwQMrq8ZeQeUZZfFh95SXtuMexGrLVYrZYXWEI9rPdZmHgQ3i
eNs7L/atwBItgxZTPPGFVFs04bKdR2xP3JeeFV8PSPFjCXRE2GKXJjAOcLqO
fqLemacPDzjwJrCh/8kB4qfvigDFihXC8oypnkZPIG18SjZ7w5Ulws5oX6UC
63Hret2VkrYStaCgyeAWjo2ZpnHO2NKDBoF4Zw+oWqCKRVfAYluKgOI41SbG
qWp4/apKb2i75iTifVtpmkACHSpXbbvwYLCCPIHERRk4SZw7xdBHIcDStbWO
DsG9v3vVv12KNFddcsLCFuF4SrGMUUbuShhUWCECdgWNlJxV65ZUbbwoYC/K
K8XuQ7/RFV6e/czcx/uHTxMLzKDxiS5dBVmOqABdCSloykCnoy8+FLfjaLhp
Po0Y2WSU6EiMNqw5Al1dgS0fb+NN5Gx6uCKTKar+oCpi9JFYBE+tugDWZRlK
4PyEcUguCTgBIUpCf7rZqKjcB/fmgHm1k/JiCh9mnLnYp8DFYwXDeJhgt7Wl
2XIhBvzFbLmsYyVxV5AD1oCVWISBpkcm7IoYJTVUqf6QyPyu8FDox0QZlIRe
lRKhblC8bwnP0OgJoxVpnDFAnHMF7qhvdJmEXWWEOK0G+W6kSl3kDLfX3K6m
87palX8tfF2d1BLP4v0Wy3lMvkzrAUh8n12bXBcgDsHFOJgHbRAigN/hqM8+
UkjjoGWM5xF0lEnfLhkeMxNGVsknQqTxHrpCsRGFXNzcKQWEZIhoPfqRt0ez
q+RQbyFhNevGXrB7HjVCdsQuiSaHyH0Ee3SV1zPSQGGKacJkaNVG0zGRbfWA
0NZ8zsVi/goPhOWDgDUwX3DeKHDPcYZ+/F7ut9ZnmnYyf1SWsQgi8lsNrpCH
/98amC9ndmBvfK1KFM/QdLrSrE7tNEmU7Lp2JUECI+cpZBdnYxlIWpdTcXET
YA2fvDoQ2h7uEVSY3bWPCHBj4kyypCQPgsBeo/Z3k5xGPn+EP7K9PprjcR0g
AOecv3NyWXeJAscCNIPJJKVDv8ZtaAjEJMVbKxmfsOSAG1c/pheQj0eqbJaK
nbjB6iplm6SoWAL1NM0oM1Bqxdrsp57ISg/kpOhtIJvPZYa4ULJfIao24Bb8
S71NJLbP1poAiQLnVKpf25KmXLYUrtoV1f1UhsCV96Q+hIwwGQfJrHm3L7Jx
ZWwWiS7wIJWuialhw40J/UOJOXVxv8wcc32X16qh95vrhRoKbCpNzDLa66y8
WhEUAMacKAgMEpvlRKW4YPx40gqRiBVyZhesk8Tk2ukdImzhviX84tCwKalC
pbDAFiz5u2aY6NIZzCuYQRNxejA5JDgCYVtWvxxOl35kizt1YThlpxlgY07W
O0881EEyjlIneCuxyRKBqO0OjiQETpKiYpVIEkhlTnHvxSb3K1eCIP2i4G0j
7FdYzvEpX8cccgJ/segz+JXVl0NMH8MZ5/aKWbJ9wVJtfe4GSUwCPKuViedp
zRRU+ZiiBiBbT10ZO59zNFCFBoNgFotOOUVf8YRTouiCK2vGEKa7icI1rHIT
ziKkGCz4GVdC9VV3gQ1ZucEtoxwEouVxdpBjUgRjHGnsKVhPEh72x72j/ad9
MF6zPgwsDrMN2eNAhS/iLoqszljTfJRT3Gk6kha9w8BjCXj7xGXdO2ztZyH8
F/ywPUqaF66rYOKCZcKLnzdNNWV0rFiuiqpHBKxGyMBVFismDUp5CXyA2taL
X76m8KnXk39HI43LGGl7Q4J5fylcPJ1+MOirvYz/B5zHNU/0k9bKEcsTW4Uk
SGVbWRXN/cxpChdk6qP3pALFEnhmkHw35KHfvzvd9SC3yTw1VmjFRc9M+gwW
3bBtFPoqKPNINAuzvGi44mpMTY4Glk7i5iicGvtGAt0PnER0tWG8KRrfzos3
wJWIJlCISuJKhlEqOJXJzVf5FMIWEG4OEj1LK4hGdHdzPsDSJBs2IvUOVQoy
p5YgH2cW2WR6oFjulwDoy7yZlwzbRHlRs5BfoPaoEoPMZ5QxFdz3JPq8cT9o
ljTS4Tn0NUO0MzB/toGqad5hmsbkOAPwtZeSe0FCo8mxW8xc1m67aMYbQoqL
+oHim7H9XaUHlrsoFWwlPjkD4G3MtwqMKpqvDvAhsYIePiVb1vncIPtsU/hN
aISzCBtlSVnmH/0X1A3W7wnu6ic/bibV52Ij/4+foEVkdDRjXO+VcFc6XtYE
G6Bp7c7xb+BrVoWSMtGeQ5OxF+w+/nGfpYLXtyxWdq/F4ivfLYCLtXJItBGe
2Ko8JBC/VOOBiIsFla9FUBGEwo3WpCF5ZGxiDJdhaDbLZV6TYYasCbAzB3vc
kF01PHVCE2OrD8Vd0G2XVPBOpGt6aUxPOknosNs2zjE25+LyuVw6xTkRzLnm
hmKCLudFzclGHf0tD/c+l+BV17fDCdxWFDWYH3oG8v9s08VpGjDtyXw0AIny
JHsp1kYalHMc0Wgu4hIKfprreSsDRevso73sh7JaaFTapQtso3h72l2/RcwR
3IKEtrpicw5XcFIoAGz9aE+gIMcR4HDGFNTAVcn/UvCT2Ag4G4zsKmVDampq
Ndi9eywcH+hHgNZnMpWNvyXykGX+OEBYn0REj2W/KX+LnttKsUJ/Bnsb0NLM
1I+ShbPS5UQiDLtKcAd8w25WHPvGuifx6VtzNbAmN2OKZx8TgUELKJ/W92Ss
OnkYdWl2ncv9siMmxFHAcKN2PsouF/kVdFW0071dGZdARZqCTx6xoYBTPEqd
pUR+11lIX8bT0NK4miKKM7RDpHQjsEcZ606kSJmxcASv/BBajJZUeBlL3jog
SyqLmjFC+hS9ZZ1Scx4FsccksjoXJQfBFyIIaVSdfRlrsy03FfnCK5e0IMUc
JMbJBW1IDcPchQQLO+lVzfSgEjJbqfMKDeerdOjy9suBcrDepO/hLE3k67Qu
WjKCEo6ZgKyT4IxynOygjoaBZfFJ2GI6CJp1vaoQQwmPitltFMoWjtNeSk+c
zHNfaoqEEwYRPHvzTYgn88QTfg7xsBghQS2anDi8jH3j5sBibk1ojzgsHSMC
bbBGoGAWGtm9SWoGJmtiAXufnzxiZ7MgB7qaLWnPWrGlwarBsVQDhcpzzRgW
yTFkQxEjJGxthwv9zVxcNMKWtzkjxBd6ASIcbq6FsoYGgDMmXIbV+LL7OsYP
SSybY4lFhNBPfLzbMeRdKJjUV8AJmz9T7mFjgamxhkUyK8nXxTbsFeZzY2f8
4E41WbGBcQFOCkMRcHVXoEB8VxgtxM1ZEFdA6gXuRcGfsSnhN8sBNWrYDK5o
/7TkEfFHRdzASKua2NVhBdEfyememKw9wBF6SXN/21Cc44IGcz/PhXLeHlvD
Y4Vxt8hgMCyC05hlYCleW5xeGJqeRlKhG0hvmaQBX04JM4NMbfMwHJpaWl8T
Zo6YF+y2UU5SyUC8X9VMMemin3sZBqaHlUUNt9+wJ4VOnVmWzSXsNuJKNBiH
47bFPUeoRqh/YTQ9x/DqqNRUkwLI8/Yye9cyxWL1f+4k/qQU1iFtauw10kAP
cRXN0s9NepcC9ZGYfiZgVTptGRO281Ljc3DqBLyjmst1tTDnQO9cJr7GiJwG
bViyM6g2VYT5jOK62KDMctlBU2l2sRVT5XgeQHbfr0ylIIFVBz7rzY0Ll4rF
1wT7rfPL+8/aJLQgJ7w74B9kVGVfG7A/bFYw8P3YOg10D8ufrcYDQ0+CX+BN
li7EB03WMU96N3Rd+ljLHuwQtBF9PUSnImHgNdLA61RfZAbSQu99l1AAA+FA
RCJaaaHDKo08nSySUio081lafd6ZNMhf7jkFy26nc9H5nT+SoAKdCY+dcUkq
FA9y52B//2A35npzCR+LEGZhixYcxlXSWKMGzQbA5zLCm9wJeu6kkFwk9b8H
AgdwI5Kd8XsbVxIz+xnKmQAH8J6XkuQUsmWoHgnVPI8JbsD0ibdcYG5DwmDw
lPQkYni1h+WhUekgWrwCOc2EEZAsLv3fIFik33M6m4j2Tc+PNFAO9XDvYO9o
79OnJDOGOHy+iM4pRGCRjpo0jY0skSXsgPrxotMBrZ+Y/UyQK6I9YxqXOEpi
9ZHhar3BV+sddUo9+m8Izo3BFRXIbSQQo3AbRlwWKsqY6GgawuR9/vRUo0wY
Y3JmoW+L7VeiK5vU7YO3qNYblNj04aKYwhn1aOGidepBdgzXeVJeEleby80l
5fU0UomdFUMtzavFTOfJJbU/FBJlThipdVKvL4gbZ0XYmrLD/cBcytYjydLC
w86GHGUc9KS170zEwxWBu5Kzyc3rebBrPrAwVMomlrPuxord4Beq9ADfXG5a
wlrtwXtMFi1m4yPbWaQotGRpLpbDwCBcyLOfE2PRXNxhN6HIh/nckXLKTqvP
J2oNQP1poGOMLOuDJVrAk0a+nkgaODBuFkU7UEQneBvsvJ6cYGpYpxLzlmRz
K1OhFfEsU92FlpJll0//2B9tSkVXJT3BT+hA7GvlpHS4nWrYe1lXr5Hw4H4S
jpGS6n6xWOjqlt4mjqdCyzbWBLr0F/hdMilQqknCL7FE1verhcR3xAAsAsG5
RwFzh8XsnnHzi5UokptxGIJDZKvy8h4LhLB/Kw90y1nxerLrstGKe90kV99M
ExziRU1+cRNl04pnSRympTWpOksfKhSK6UfKfV4o1DRacaniWA99TAt7SYYC
QQux0N3EoRm6MPHGGVfNxrAbhs8MMXKLauu0NZ5wQkyaSa0uH2SqfKiPIKYZ
Gp2ZME3q1DW9tjsgK0/i7KzClzt0BLO61c02XE6JlsfLJY5FSljgYV9UWo8o
mRf7sjnCu6gtZKJBtHgrGa/reDPvQYR1hsfRrcZvHTITkVSBEqbGlhWtRp0w
XjZnzjlo5oaVfzyujDbhXpEFkpeUTYoNpKvzEyvtHTTqVUJeuQG5aV2/wp3z
eMPQnkjNj4RfkDGhrUL32JOGXbUceIPXWI5hhGTHQ844cslyhJi9Kq6koyWI
gm3DJfR81gXadWcFAcNTSIMMQv1jkox/28XuqOryr8w2NKSAaj9UvU0sZgli
q8PQZxGe440CyJo+omiHUpOr1e0S5+a+2c24+KVP0yK8JWotqMvDtyUvsIZg
s0syuEDso0KzIZkau2b8vNRZG1Px2mQFCQs3SKUffOGGTn/SKndn+EX+Kyuh
IcLq1mV0Qqf0TBN3HVPg07QNH8oVpa8Nlh2ShzqDoLpKimjGaZqMob66TbJG
4eJPw4F61UFBm/D4rE23ALjWClajst81QxZirkHF/9zXFgNjwUQhVvWTi6yl
mnYaQ4hitzxM0X52o+GKxwVN8GPFLUfoNXTf+4ajMVwvVNPXpCBXtE/w/sDz
iI7M6bWdep6UYYu9eDStWPprlFGuI+X+kiej3bp/VOowWRq1EnRnsOfrwBPB
TVsuxJsIKgmHwJBL4T7kS7boH8p74lqRK81/WSRcTfgft5XIKmKTZvpteput
YimCQc/yOlUIY+SzMli6vKfA/vLWI8DoJNjwQOnlar/Fb0EJSoMaWSKL8Yy3
KSAJ8dfixzXXtxdK6I6c7mWq2KZ5EYr8IQ6DEycxvvWz8uW12Ug2JEKGkLzE
2b0cTdvNbXWIK6zzXtwGV5MLOzojj0f29ptT1eG/NCch7ayYDR4fwsHmYPG3
35ycfXGwT9tHvz8mG+GILDnFlNUoypDie1mjh11fQfoSc1WeaZtubfQRGsDh
0yeYoQiCTjWj+UglsotqdstLoC2grWWnKQrWID9Mm4N9DvH0TlQTj6iuUB6S
VZDZJ0N7LMN4eIDQHZuVhP3slHugWswKTitvi93sgZtBE74Dsnxgxv3u6LPO
6B/b4IMO/jGPXaRTTk7pytWo6hAq+Gqm5bbJfG2hr/Ah5ahEqYVyrNickNJM
YLQNWphZH9SBhKRFufqQhNaKD6C6HMP/kdNbldkQ7Tw+kNIXyd6inXCieoj5
lnY0ZOnjuMsIIOq0N9kSzW5QsVDrL8Vr00Vosf3SfDCEbgCcmUo6d+BnH5yI
0UlM1I2GVz0YiF0zPTZEG5hhWvFQ+qF1Mhote6DziQArJ8kKnGH5aoqA4Ynu
nJy9G8LDlbUOvY5cIKneRf10tLKRpyW0yJ8mhX16EMOo2rmIE9Hq1VbTaqE+
EYaLc0+MJapmqPbrA55NXntcOBlHTAfU+Ki0mpfLlUnyWlsKj+o8iyLOZ/Z4
x23yKLh4vF0FXHd8FtY7FoodEV0/4Dpc75OvlHQeUza2h1AT4a23ZyVXAh4f
Pxorc8kbVxxZbDPCgKRAKwjU1WVgHKVjhKoz77D4wsks29bMCLIUKzQ5dmYZ
mSp+kYEWcfzwjjLvI+wliomPeKHOMR9jy6uEm7UsJajt8OhIUdt2tJnH0MxT
m8rRIa1azPohYkFnxo8ssCSVsiUgwRDxqaQKmalixFOEXVPA67j8nbBwzFws
lkBTmg4ytFopk+rNO7iQa8xCoDBvn9TXJmlMs3JG6rlC0SIlV2u1yTDhGhSO
H+4OympMPnDUFfKjcVmcPsWXwpcG572bKsrCWNka3WVl7jU1CharZlMXUVQL
Pb4emTZhbeA8IvADlfjpXhjGZq3gF4KQxwtJgRajyVvmcJcUFBlv19nNHtZI
gCQjnX09+fZbYnq3GhU8ip724kcHgEo+LLRxsC2tiQknkj9/aZ6uBILAr7cC
mPadgj/PZ/17zDpE75fkl5HqKyJVNKnAVqmowwyjEOdqV649qSj7NJNCow1I
EhYbVKy48lUViUUIG64s87skYWki7aUlustGdY8OHQiY87m0WLZNsbiMCMqN
ZPnkSZZM2jb8P71eJ6xvYXmSk8lucHUXO0K3iU7nFEZB+YQk4tFQGkkN+9F8
LRoMRjVGc9IhEOdww1iL3YNDhWfiWbZCPBi0SYrhyIUEEDzydJGXXIFXLBPr
+W2DnikttTTiTBT3Zzs1FJ4eOgoLQ01qumJrqc9bCqZEJ5tLxtxEHLEwAzR/
CSLBQkrfUTqTYqrFGNnklW4BI1jniSxLXVwikqLWD+07rS5tXNI40o6E4HK8
LCl5aNQN7lP3dJ6Mh8AHOaiX+KvS4ISMc8tqhsROKFmXDDjlXOk4CpTHJR2I
VxTlzWkJN3upqDyr28CoVYkPlasoNnivWRroHwqWY2z9H0wesFAzQY0kl0Ko
D4ywH4wkuoEeficPn73Tpx8IZ3zQg4umCCWCPGDYbpgwWjiBk9AB4T1d4BSb
zCGRR2aOW4SWie/Qji1RUmnE16DgXzhxn81w3k4Kp2Inv9j1wJAaQYgZrE0s
2LiyAERHSaFLLlMXwijmFUEeIipBls2ffn1+/vbMThDaHJJTxGhjSZLfkAmW
AK1w+QiVjFZEhGdE41wZyBfeI8gRpnwQQYVzkGtibCaTRAxeOJmwtdWHM8QE
B/x6125QPDg9cKj44oYhwZIjaAhpwQMd8fKR84DgEk4mfNpp3XBFhkZT39Jg
0z4HIeOwKhSuu1yP2h+ds1XQmM9kEdQ2ZR/pAuvLZB+8KFzVUGQmxtmGoLNI
TVcFsiQXPDSO/gucLy/qjbgc+JJn9ya9wjd22l4S6hYd7Ir+Rd44X/kXnyTB
VS//jahiXU3fNHryJ5ethRX5SGZRiMXSZc5o9D5/z/GKyBAFo+rx4VNWeRNq
oGHPxh/WWH7wO9iabydvBHbq0cOHj0Biok5CerwG5N6yZ9+y1bjkaGJGJNOT
uacyB24wcllyVmHWE1eE5xBFwoyRkFhRzIkjkEiA+Xx7gQqnAU8jseAqNx3T
vIJazcoXs5Ww/xv2fIQIrldRqbeLElQFARLpZNwCp7whfxxiEyjctyEbyoFG
oE4qkkrLS2YsxeD9UIgql6PdJr9htZx9gzJgAZ+UUotaP5JjNbLvO/6nxNr4
GmXGj0P++k9kLLpvGyO+OtOYnwhSZOmZHa+P6qndUA8DxAld41iV5Fl1APz6
QROxJPBA6MbITGCgOYSYWcfj4lD4koQ4usoZ9crkMUPDAml9xuyZys5HkLCV
ALup47Q7QvV0DRfBsnC3l3z0OllmAtxGkCO3KrHBvY9FKk2JVGQ4B0JnILov
v3nJnx8fHD5CdR5dcCiZ9eCkSfgtOzLiEimnoEIyjRg/qxZxzdZYwAdtWswJ
YzwQ7vGClpAPY6l1jbaEPIQk+PcgbjLNTaLiaXGRFGJBGG8XCBFaycH5yq53
o5gYQswaComBwTVkAUEdPYNspBun08NB31ipHSdBuyIfVRKjgYyPQhZYKFSs
EYdclBYkbLuRQvFMpHWe1SUWy6ZugRxCC0O/WQINJA9LkuKK1z2p/WLJW3Ug
4siUjbYUcp9IrTXiT2eu6Cu5Eu7LqzCbXKwiHMufbBKIEu9ffP0e3c7v/3B6
/vX7ycuz9weHT96ffHXyHjT5rgpEaKd8Td+f0+EW8xVt7u2EVLieFMbWm78G
loGixARHlVA362K85CAwCykJURknAQJF27qE/kpF+rFyf010/Ut8SrcwtIBK
i2g7PL0wML2Og5fVFIsISUorr0K638z0CpC/UHG9b5dEJb0yZOrLabK/oDPb
hWiHLsUTYa6L1Uih98Qq5KsHM4QzXsaSZZBY/BKcKYkhYffrxoIFMxw1n2WG
sCcFsKTjfUGxljFsZmtVBzt/iPOyhBuJU070og2fJT9aYgkkJwHAAUzTIUS+
HCggBWGTuQ4vntAvO0YVxUdQNOjYgixDW4W40bcUxSM6usfJ32JWEFm6m37V
xclMOL+zhlHsGnKUxcKXDfchjEILCrBEKi1zIRPkubaNV8Z4LVSoXHF8gqD5
ORovQKhqxhjSv5ZgM7pXzJOfON2bezAOyv4S4NmtXKNUEOQE3cHg49OHzSsN
cguwkqmiF/Yz/0bZZE1hcz9mJ3tHnz7tikQvT456ERN2PaaqeSKrCWVobGMv
yCkRFS44wO2OQGjYhnIV2CBCCPFtw3r9ytLyOr6bwEba4+PHiGzBjrymGzne
KJiySksYms32kAVFWL+ZnD2gs+w+k+nXD7S2XTMy33GM8nbyhlmpr8i00Yf+
FvdAnU9ROmtgjRp/72NAg0WnD1ovxa066UivEx8zwjxpMp2iqZHiVSeTyW4M
HVcHm/Nm3CV0kqjFCaMewcQbebujVAmx56EAThItv6xAZf2c9NQJY8UARfku
m461GPOLisVCr9TEHc3wQ7r43Vc1EFmu54ZrSqeU46ztQngJRmWniETHPdOp
qeqt/Dc5Jl20lQ9rDHd5dzoZiGWrEIgCHBQGhtfRts3v4qulWb1TMcXreJKS
skNtu9ykvOuXChoZMVCui09qmg+tInEzuAzWmEHWSRbO0LAk/l7wYqdyUybC
dfSwOVzfbqcxNnwWiRaOLGrxuncG+XnXxsm6umxVMQEwGu2to7AhLMKYVICt
DMy4V/qO452LmD9ju5JwJAo5KVsWukyv6EQvz/y64VJ4Bd4JVyZHIJO2TINX
7JbOPnYd1Z+6yaiS6uzyUbFxS56VdhRPnvOUqAVGvyBTSA03v9hi6LAsikvS
12uyp5Qri5u8uG0Ljn5xOEvpmBl6GuFuTDOjp3pORMFbEH9QSbXgblaMj7On
yEX7Wf/nYOCzw4HPHuLrB/DVw+xRdpQdZ4+zJ9nTn/NZ+Ofxf/N/4ScaCmWK
0A/+HQGp+G/7+ZaBD/zPT7/YGAidycbwCjFO4LcfYBA2Bt3Jzjie/QJjeJbd
3UlcB8OEkSd+sc67DbtFtt9QonuBPrS9vV9s4V3Pzb3aFSQuJBpMvyWHGRKQ
RYFQcDSGfuDZFLQMMr14FLDMUMCeh+fPgcDlBMIf+PehhfWBBuIQ0rg/R6ID
vZL7qmT7IeXBMtvXGtXPmetq8o6w2V6ThsInuNlYFCSfzuF1DdhiFrHtfRHB
ugyFUoCe87jogd6LJhCkuJh6xYcghCdrIdRi64DFXyTwhu1dMbym0N0Qzsf5
rDKw6JxsZUdHbmwj6WdEB3XEB3SE5xPT0dNDMzI67YGdM1tHf5gUdGRviWS0
11qko+3OK2rsLWKUMgVhD9m35eoDQxrRVGYs2Kz8K4ojUrlytpzvSQR8dGQ5
siHQvEJwLM6Yr/vQnwZ3Tr/NXmdn2XfZu5+2PKsff2vMVCFpf0/qfFesY4fr
NKILVZt6TJvrOuhwLEXePG2NhBUDU21xVAvItaDJwux10r9gxSLGzamr+Jy2
6Noh3U5cW4IxpN++hv+jD8fyknnClFq6MJvqIkf8a3kkvnyWiYiN2d38YoQ6
OqOUb5UoeFQdyGxQT+IgVeaLzX/nme/ib9gXv5S2Q32GfsfOKDppOkyNz3ci
a0y+Vyy8KAXL464RXRUKvNFdlTSKcssoBEPYTYkqR/V35V2GzA1XeJbtaFOI
kMR8Rw7dxqC01+1uCD8oEy+bNDaD+ZPWS7C4L3Ogn/tyYYaScMElGOidg2xn
f/8AKQPEYpDvdh0sYHpGlHUOnRwuBrapEx7ahZFVGJNvoSsWDuUesFklHoS2
QsyClPfK1hDny1tFdHZnz6odkkFO5OEEeJlhAzAKoyuTyPyGKfB+MxSW/N3f
PENowDF+WDLpADmvXA84Tsvy1Q/jIOUFhQtHa0KjIXYG81XMBE7GrjEPGMfi
eyz+YqB7MEyWMVH3eY73GKfVShARMiR6iOhZ5pWOcOQyRAlQYuaMnLkVxrEo
G8lRGeKvcE3KJCYpCBkF5+Dnr+Bsk2oWGWtc3N52m/FFic3CTImW1F8/Lxbr
6LiVDfe1Z1hTtTU81/QaTm1A8c1hKNKd8pzED2VNhuTWCYaR7EL3HnokmVmP
22rMicPOOMAsCD/Gr+PDXRA2vApgDFrP1K0HW4q52qoTsXBgydlgctjCuqNS
iV+9iqUH1Nn18QtEnkXrkCjEog8nBcENW4xQjAhTWIVQ90kavYT2foYuzWs4
kDWqrwgKt0So45iZ4COxxAus9ltnFdxSWfDcWTotZ1mLeJTIFKwGFd7Zrc4r
OsE84pVmdJ8rthUHdKWB+6MIrgmcRIF5A78gk4l2SUwEI65ISdta1cL1nhpr
o/nlzeQbZ1BZYn5aW8EKEmtbaVuu+gRlHQcNLVA7AXeo+F6dYizo1xUrlHih
7X1uf5nXH/AAa++da1gArmSomumgt73GWfKys4zFfHWVGFSsfI5Aj+IYg6eK
OEzB6cKgjriGVg8BK+rxgPPGotTNyOVCjjtvO/EmmqtoWkF4iSyHBXx314V4
r3o3V3Bim7aqpGySiaC0AjcERZWsG28Klynl1cntps0pkZk6M36Ija5Qc+Ta
2NqbD2W29GEHDRRhkejKFOs9bwtFf7kSa0ErXaiLKSnnQ1Nl4A/1x6r9MRID
gzMMTSobmFTiu8q7204VjRLCNOt8cjACyr24FcoJZHXUSWTOG8mXdzFoCbRp
lhIXdSbvGqWlW+3tBH08ZGyki2w7hAPJIBf5dkTcJHwo+PohTdf1kMK72TJ9
qSuOa9WSN0qxh5kSe0NaWSJnxW6L7SMSfU/tqLjzz0L4pxjWPj59QZ6KfxIt
HT4hGxp/5oqf/JPSEfxmyQb0SNcojQ+kaHPY+jCUNnwzUNrrn7KvsITnWFNk
xjhceOs/7/y2WTO4IHoB/43r/bobFuVFuyTMfBSTwtgkq9iMW83GITEbMypt
73Q4wMqESSGFKtyv5HPzBc9Rx75ymaQrFzM73rECumCpwiAW1VUERQMlelZc
bK6uvFNE+na3Ev6NPc1zzhZlLDcGqpWUHHFownd7Lqmf1i+GcS/zBQ6+mHlU
a0lvoIT7EJPY/rfYuV//9C6xZeM6RpPz39HOvfXnB0pA+EUMu2ygfY16Aezc
d3rZ4RlD7MADKnAtrJ4O3rtAZk1W5kdq8iDdZ2d/lw5gxuaySXbwaIxyk+hA
VITBUNpQeoDHOA6nEj8TFSMSe8ozGdP3Ky3EoCPq8rWMCv/k9mk548Rqev4w
6zO9bFulIHrjYebv7x0u/YV/u2ceZXbj0gOr/IP79ihzqVr0PddSiE8cZ4OO
y51tDmR+6zFsPVz30NKZJlnbW9f8hd4S7q0n2ZBTcWdLSTN+52nWZe8yD1BZ
1vyhe/pgf2txP15p/2VvLQ8OsreTE376xcu3716eTM5fvpDvDodCE3e2YJLJ
Ow/vuln45Ys1gXXAYP7Tv/nozlsnZqc+2jvcOziSl46SBP9Ocj8/cpwiGHTR
C/ghaAABmorZWGrAvKsqt4itfCm6bw1f+refYArOeNJyjCAco7hQTT3O7XP/
ztN4NL4uV+3A0QA9UHvp+BJSE9UPnEug3gw2F8GdQJ/rK76cH8k9fI33jvPH
3ln+9L/0dulcLf8Yt8vpi1/hahmnd8vPuEaQ5Y8TIvmZbq3EapySLbT1fIBq
sYvnGR0JjaseDtFWy1iMaKqiuw6a8NAx+XVeLnKNoo2NsOwXXVCSVZ1Pa9Dy
xNIWwyTlzPSvtI/9+0wsSv1nBfu/ZzURXXJesqKqUwtmEmiKBcqz5IDjDBVs
EmP0DEArKXbKtS+wgjYB0e2xc+b6YBiKP6ozZSN60XfsZihCfxJRsVZztDch
uqKaqmNKEYo9iusQhDiJbmoHl8ng4YKmUPCKJdciWSnuujVQwgkGlsMux7s6
U/kn/PyeCL2xk1852KGsTkjzzC1LrD+6gcKbIr2dcsnP9BU+Ur30XvK78wFK
a+EAiZTmZxYIBH2Zgls94k3q65bQqqQUZBylA1bz9UA6Ex6gLpuwjDme3rTo
pKemOxZcSNPMHVx7b15MP6iHKLkc737ZA3YnJXLT1yQhMZdyvtaKhv9NhFW5
cOk2Rv+i7U7qyMoypVU+QzCdUbZOiupi0d2q5bYTvN1ui13gYELcnXm3mTNq
IE+PYArcOlOfOEuqz7xh9NQfGMVZbC8cAS3H+gnPMfeoz1Vdrj/vSMwJTBE3
NN1UFpE0lKEGuZWbXJOUDOjYMp7z7TXMFaCAXCG2Bsb2HcdPEmAlnQNLoeAm
hO+bHloPZ0MvGnHsvBaA0TQYmWhLfAnsmiC+xuHuAyJnSp5mEJSxhJjDa8Vq
O5STphDHcqxbBqJz1GRN9+4HsnT3e9CauYENty6IUjEZVq7s3andhpUV5+Ia
m/QMV3zrJRjT00lBL4t7Jjvuu8mL0+/PkFe+KNmboz7KNEBUY4wZu3BrPn8Q
o69WYuacVr2DKbfoe4Ws1X3ur3sgW7PrULEomwIJz1FfgglDbhlfbMBD7hNd
F7MmOaR2fiVzTFA1BMwqyQLCYdGbWHszOVbd/GUaBgkpXZB3TNXv55teRlSA
1q3qRbEqLktODEUCEx6L4bYOS7mzeIgFkG+pOoDg6pwDtbgls+FQV3WxLqR2
1arbuG6GypqB1gJn+ns9ZsjeKOmUbmhN4dGiQ+ne0az4sDQxqqBGSHEuHq14
R9mX5ocami92fYdubvJhsHB8iTORzrCvbe8z52fX4jYpSUy/Mnu6MoAYuWkX
swQbz+fwrrHeuVZJCpLPp6E6ISRmO6nDOCFf2XPxJdCeCX5bQ3fBwD0Q7r4H
tmgAW+Irf9Oyfw0tO13+n9GHV6FfR2ewKMt4KnYOdn+eLn0IunTfCeQU6sOQ
ipFpHG0q4Ce69p7YpZ0Bl8JzkXLwIrFoXb1NWJN1gtZHZ2cV3dV9a0FEjUsX
jsEzmNAnpVoVHB8LD1p8yWXlE5+ssGOEnxSYGHHUn4FmupH4pXB/RSbVNiTf
TCQQqXJQKOBF3it9dXlHaSYG1LsoQB0qKxN3fX0zV4KhW7/BJj52E6c6FMFq
cVhRu13SaYYrp4kgnAR45lN0oOarMoZ1dJyRaCsfdTVnEnf6xt1u56ex8zPZ
X8OKTjoezGLf65HRb5zv78j58EdO0s/r41fgfA+B8zmfdMryeJDK6/zhvx+T
AxoR6oxsTmufEptTb9FHdRUBg6O+9AtTztSOyIVPmQ0YNirVRPFBVC6ahCKV
u+GLqHQr19onwBSMxpFOWUHCgBvWw9gGqYVB0tMVA4n0pWi2EqnJFDmvxMX4
kyRZMO7EKGLnh47arSX7onFUeuhWckyK+gV9/TPMNAZQ/cYS/r4sIfkRj+bp
bPsjv8IYYO9TcSxdh/P7Zjj9DzCyR8DINEzHcbH/eP4vxxg0L6upvCwu79aI
7sRBEp+vNLDbIv3UHGUcSA4SIlaNOYhNkrmabH8kAbLkdalu5Pt2XheFdS6B
gWdtvZm2eI7h1MIqAbeQ0P1Tj2179vp0N3sjCZzxseytQL6+RDfzGosUZW+0
Bq8MgGe1JQE0G1wokTKgAdqGSyk1n/LiAXc8GkCUunQTjNqGrxQLR0q3Qpwr
99mFifI8kizpRRp/RIZ4bnkqmcX2Wslo8YucW4R4P+UizxYSJU7LoTfJORUH
wGw3/Iohv5/HW4ERyXqRtJohgFAWlfMLMkmgVvschFmiiAJx6ZoyAkQhnttm
xQH0N3M2rlaXl4VL/84byvpgWdcgW1z4qXjRYpDGxxihIZpH/C71lnWiwHy6
j9RDFY+EXMpYj+met7J1KTQR6IOxy5iMmSyOPgSnV2NOMN29yQ7GT58+DXWh
vjFnI6g2Lawhlo81M+Z1zBHaHWUH+/v744P0/Zu8xptbgOgO8YlDeCKLTzhN
hkUE+iC48pvbxPY7izSPLPs+qQ6OVK4VNztBfr7AYKLUvBZAEWyscGtFUYEZ
gTni5llZ29QqmZQjjWk4ddHWVGQMjYnLHJ2E5ioS0z81E8yy1431ZL0Qof2m
CucnwzPllX0qAVElc4wJxDpjFPGXQAyktbp6QI0bCm1WejGx7GD/4UG2w6Ze
BgxJ3NYGPrwrgKfB4fuMYAW4hHvZunPi8aHsGDLAQ0AbJJaabHB1zPpZKhSM
rxlLqRd8jCwll7zlQQRCMg4qqiRZOutqgxh084ojzdabel01hdqkIy3+JvLF
n/+BKBPH2Lb+/BJj+OWFryMQvmJktBO/HgXHrvXe7zHwVPoCYj7hih2IXiv0
KG5UvgRdAz2FM8uy5NRy7aIma6pqFbXQ7lPxbA+98LD/QqeEmkCWuXce0Tsn
i2r6IWs+FDeiuWK8Jn1/xN/jdYe1rWaIdobYkG2lNsHju4ZpXWo2jbyEVaez
gXrU8etDDB6N9TK67ubVZZ03JnlKOHR8++Gdb6t90R5/1H88lvDqPX10x3Q3
K7tB4gvHg5vt1uJx5wHcjmL2DFgiXLFXKGhwRTx74cmWF2iDOP0KMYy1tkXa
29OsW0K2s5xDkzjY/9xbVqXS9XVwkBAXXn5XaESND2CIr0Cz840NXy/iTh48
xNSyDwV5X/H+x3oyz1JC/Mx8Dx4NNvH29M1W4jw40lfg1oZ/3TfH8k0DuzjP
O7N9TJHB4k3r7vLBE/9tvrjCkLj5MluWDYU1xAef4qJ1PcymNmAJQHv2cH/w
2br4iz/F8NwBBhLDylp3lkzIy07RG+QE1xiZ+C6fRbNcTWzop6uktkSn0lFs
4GHawEtWC2Cz7tsAbOFX+cz8GPd+74jfu9ezxxkHQqM6czLp8KND2FpNWcFi
JJ1vnygzY0Hxd00PUYoycpXQFKEX3+5v6dP7NdatM+Oo2AuX1u7D/W3tGlba
JeFuxzcO7uB0Jltm//Gn788m//ayC6j/59jOYdpzqgHrdUdXgpTXw5rXIECi
NcCv9KHcC1tMg/Gph1LgoR9+HmtBZjuSDU7OjHcSrjFGqBP84GxzQWr/bmz1
kWr7GJqTBBfoXnDicYb1v+NrR1sH091CRyHQglX+Hr+enMTmjrm57gNSKtpX
BovvPP5bhvBy+xiecHu9J+4cxNNtL1EhqMZKx35+aT2OZDKbj0MJGGIUGHre
/JK5q0NGJdkxCRtjQAaPXoLl1y9wzRbtHnpbqht1XpFGOKW7oxF72L2wLQh3
8u+9GFxXgZj9Ahoox2YViZZLUmrbgYWKwBQUyBPu4UyV6iydOfYypuNAzfea
VHyN6ceubMsgUOJvOmH8+XvohISP8Q+WanAMbw9hfDpF7zqvCec5BMUlQc7g
CNyZTLeiWHpITGghFs97iEchOazEqIbSvj4O5XwJoxp6vvQ5CK1iLXAbPvYP
jW1lTUUvCi0KEvOH5OItW0tlkJxVti9RtPtQ79ZCYvyks5+YkrWmCsJYwDKJ
4T4aRS1zUIrjxhjC+OhAWjhPU1C/nUfgnNPkG8Y4RuveYnD1AhoJLdxcQrO0
TY6wFOAQC4/rtMKpycS3Y9Cfrr6WP8VmI1AJGxqAhmYLRhQN6chdHRxicPTF
77heiZVhZcO2NhLiHcV1VbhfKcTMRmpvG5Vl3FPPEi+Y2D7NdI9bqPaVvSxZ
20ZRfUM088YQDgOOiJAEdocM7YLHmhjCx8DyIirYWXGsGJdPAHIIXi6wu9MK
BPm/+tXLTl+MkKgwfhEoxc+E44TYHj1DOyxdfkW6Rw47ZfAUeMIMsVsG8EdH
9uBrKEpgmbB+oKcVXbV6p1HuGRliCPfpTEsk+hHsC/zCVU35lmwkE6HxBdU9
FA6nXV7V+RrkAqy2iOWIriX26da8Zo7LUqX4eY6441IBZFtYpaAk7d3Jw367
o/+Od3T68z/jqh8Ygvrnf3HZAZo++HkSw2OQGIY4lTcNZ/+cTTdLhCBD9SOm
ICKHMa+sm9mv5sb/rL++461/KO1DC+arf336c33wkgx5pw8+uV86PuiSYsxB
hMKTj5VdeAU5cdJm3b1un4tAQbkTgs2cCgWR93Igai9H/uNAgrwFpvae1kIv
hHrVEsJlWy4VcCx9ITjHsg8XjZpcUpfVwQVZ6aHG5xak5aA41JViJc9TPI91
LmGhUngutINzEQ6cXpxWEGLKRSwtSfN8nuDeaHqr3NcJn36epe2KLQ6Xbjqv
Ksn7kS6cu9YiL4QSu7EMhnWHCVUiP/R64R64amOnm/OIo/WcAh2iSJGgzTtX
taXbkNA2ZReNtJAEEFqobn+VZbQmMvafaWS6PndP82IoxQOzjEWgJuQoyqJL
163kUp1DyPLok9CFoIv3bxlPhMZSXrOU+g/crFPNqQYaRwo0vEYu8blRdagT
2VwX7aZeKYxarm+6Je+erucqLHTgouTcdykjbrYlFeMoInxwEqeNacmtYIqN
himNLCmcTD2w6j4Q0hd1hj3jbA+yUe5stVHuMuFMCL0/CUuQDa/ShKoe+Uh6
C7RhWTVuua0sEUOzTacbTg6/XU3ndWXyMnDSfAFNyG5gkhzmjCGnUH+7cjVv
lNGVuZPGkhAabBG5zE01+GwEeqORek2KcJoV7POSBVSLSKIn5KD6ir5yL166
lQ13DhbNwYklDdP1UW1etabMhA4r1bPB3N/0qB2sB0uktgvUiKWYyVAsdbhC
xH1T1YbJkh+lZK5Z2aCkDeowpR6Rz0+vofsMxTcofXPsjQZd4fHC9qxgIRzg
uqUb/I4t5yMMA1oVN4zmfDm0loErUnirQHXpaRc5BI3NAtsim1H5xZGNVBO7
grWlN2PZDq3aQamYHmhv6/X+m+oRf35V1cMSBqRL2YPuGGSYP08N2PrFrxAq
8oQSDnrAeT7x4F6KAUvEd2coWEWDWBjTY/lLwqOBUVNUIoiFlS/CzfJcUhlT
JD2M2ePEbk5+iMGk90l/kDtZRi4rMTjybakVb3kkY1w+a/+NCsJjQuP/m/WG
GNQra4McTPjE3CO9yHpo7GgHneNjFxsLFQU1sk4rYEDNVG/8YXwSlihjngUX
Y+v2E9nQyHD/pAZqB+w6iwGngb1JGsGbhNzqtdcLw9UyZBSKtC0aV+vDIWZM
40uccVwT1Y3Iu+gAiurSW0QtM6Yp7ybWn88HH/6NIf89GPLgTySuX7bCzPDP
P3I+xlMMCexgoTomH7l6sbwoZrPkYG69AEy1FzsGI9fKad4aoi8FgQvXw6hT
rYULucy5gPjO3bVbdmMRFjyANjxS0TybdbH2omIlmFwac50i8TsK6rDvHWVG
u9uzEJhNNU015TrMVh7NN2x1NM5VNbpPZoLcVP1CBX7KwL8pFHvbbHkcacIr
rNCm6b/gKjDKvvgm0qkI/NcWtMWP26AWFQpsy3ssIjfBv23ptnh3aN5vkk7N
UkqMbbf6SFt6UaePj9i2NtR4xSBW25ooe9nA4edlA9+vbZ1uxBjrtu719j78
bq8ipgaBmnMjuW5Dn45FGOvew9uyYsLn7mEmhbs3KPx2o8af/6nc6P8/3HgH
GGSxjYjuo9/QbaC3oSP++6g6/81k7Dv1BEsp8rXo7PJJEt+8W2XwIkoWyNnX
/G0k1k4byb1uJ7oBBDFXKh8/Pni8b5WPUdJ/a0gXE2biJzHsfwfe3SWkypLi
IvGaejWBjqmpR0+ODqg0a4R3S41baJSsSyppxVnX+eK2KZvg8+3UPIWj1HRF
LQ9y66uWc1Kc1I8OYtImZrUkBukKo74pbs74+/OSLsThYBqaxNODp/sji6o5
3DvYO4TlofIr7rOHGA5ChU8FD04XFa1GZFuK5bTx6mj8Qyz26NcjVr7I+Bvt
a9GgzMbg8PlMt55FuGMFDjGJXUIY+/GYHwewkTWAcTCaVav84CUixkWy5Zpn
iqvuEooJB9yUa60xjs9IESCrD8SFX+gdhOeSmurJbciJXILHphGUPuYzKbmK
8T6joNW7zAU26xUNVNs1OhQuNfAvlq4JyRAJaqSzItukia1iQ+iLJHtb11pb
j8PE8WvlYxt0vroNQ91RjLFREPsKKOIlX7JBoC6u8nq2wAMPKy7FaXANGD+s
h2dW48lMyswFMzsN8jEvLzFCH57cNCgkaLQbG3MpN9iln3Y9E7mnklSeHOmC
CGykBtioA6OLmXZ6iRBpGNqCbA3/tZPMQWqtrPiQcOgL9pjDKvSjk/t52vgx
86kPxW3ju5piZTF0IMBaERQ3tLRBUhlPtc1lPt3dTjBlw9SxBRWTEEQb8uoi
OGFJtaC42ApVAOHIAVevzALvch9rO5JHfQC7PO+xRuko6iEkN3fiT8Po3E3t
9Myse2AxUF660tD4eAWLxMHeBs4KYApnf3IZD7e2wVXZug0Mzsxv4U6zq3Xr
paPFrdT4iI5TkKCvC11fikh3Xsw0CQBvEVh7yQgY3sQU6EnK6FHQGJdN+lz2
MghFRZFF2Hs5auNpvpiSeAUcdVdgQUk8gduY1A3FgmKOGubVDcdn90iabX5Y
DI6ysZQ1EUc2rWV4cr/pDH8HncHqZ0qfeqz5b39y937ik/GTnrG/A2b8Z39+
Cv915/dvKrwA7vr5r19gDP+o69DPZ9n+8795HfoZSdt//jHW4VdQrhGicaBe
ltOrHx+HoK19pmVhEzGM0AsDdDFJzDup1KNYxspdx3KNB6qWOXAFmGygQl3D
4pCAUOQEPpMqkZ2Sa5yQNOr0tuIAQhWa00XdwyWITE8nOCDC9GYZ6wPGVtnc
mkg40r2BMItwMyDU7CH/aq1Ar1PoSWwz/UZgGAklFlOymzabgagClznVNWfY
jAY3gUPBXYlj9RmWNAYPgWm2whL9sibBduJxMGDolZQu55Uum+5Mty60VDp/
PiR1URTqRUnWmBcphIEWMlCjTJ/Lxcq9Dh30sw89zLKvcGovNYi99wqbTf07
mPbBOoNml7Gc52fjSpzBpPX2NDtUT2K979RBCNLj0skY9l9IkYq7h9sZRDpi
ukMNcoouVBvrw8NoNPPe7zw7PDqmKl0rekHqLCIpF7CgUouOSpKMotU+WWxQ
ejhFgI82otfkhAJVrNT1wm2T2qGO7whPhVrLosBy7uiGIAMAqhYlxnp2+FmM
UU5a9EUVkvguStcS/GQfsMhvgz5RrKWa/FD/XBjg+eCR6Ce2KuTHFo0R9uBw
30N+lVZqmDaWrSvPSZnc+erg/Ws00kkglWTn81eH9JUsLCuU3mAiTZQDiEhb
tU9kDrEOaOrnyhc3+a0bOzZmcRQTUJgWeX1lI8eLA1n9LcI4rNhyxjlXYuSg
RFPKLlqu87psDAAJ80yw0MtzLYxpDUh0Xujp4lab/bcV/5VWHA2Md9VS+9gt
pCZmxrveUXvjxaCTTKyMLgCeAfoRMooO/1oaTROou1xtZYWIGd4fkQDW0WSs
IeqxGIrFLiYZZFWoLshcgg8PD4PNnMyVlsyQPlOj5z4r9JtKLT+/okr9lmni
l08j+qUUAUQsvqtG7mBSMs8KP7vzBAChfn/+avyEnT4Pjw+ffvokWTJ3HXsp
hOjPfbP+7MGXtzonX4EPtPIO2u62VG74z5hxsYUdRK9acLLNXY9uOc4kUYVt
a7N3v2n+dnx//eOLqDJwLfb7pG9wZ3+BjrhB4BBJw/LZL8WHgIyGJ6IE9otP
RBv+5SbyK7C/R1vZnxYBH+J/Qhb44bcWb2Ab16n1SHIYHmgro6ZU5Qsc4Pj2
uGUiK3jHGryLj2rjWsPeD0T8wswdiB1ebUBTXwDbYNsLhQawM/vR4ePozH64
d7D3CbitUE06T9vXz85TiW5gnkZ18I41+Ll5emF2sNwUf6l8Fr1y2XyzzLHO
GFot8hluH8YGm8ybu6cRcIA0O1GHFxyYDtL8/o+H+yMLSEdVev/H/X2NkoiF
eT/GqrxyV7kvOzdTiqmDu0Kl2yICGLqQQDh00uc5+eUoyRR9KAhGxAAVHlKt
ShpBdJASHUeInZXXt9mLl+8wRrKiWfzpj3vHT/f/zAsxK9Sp6HHIGgqkDjKP
M6qRTaAqJ0JwSWQE79zR8dEhoYr8AZ1ZknLXAezfVoZYJXKVvKmq5ai7YlzK
U/Nr/CILykbY0j7DEGwblBZQdgsYilUN52fJ8W3p2LJ7jy2oaIEhc1snL1uc
0gxraqEPYtFDTVIhZxA1ifCYemhMdF4iylGxdVukwpevML2tnOpbWBQXAwvH
a7OMxzZMPW0R4bn5St4n+UglZfs8Lm3j07yaYnE55prtfr8aGwH1yO7PsO1h
mhdOGbqczis/blyqclq2rPQ2hFgDdJK8vQQuhKiqm0LMu2UtJsGpZY16WrrI
r8SM+0wGiRPOZ9elBMcQQjMhTzJOc4nhQdOSgxI40gLVVqpyGI3G/rxTIqmf
khBVUngurHJFwnehNdCZJHHrlsB4OWJBO+Lqmtd8xBbFNbzl6xhKvkZn2o3q
zBzzUBflSjcpDM2/XOFhFCg/bIu2IuKdxgrJGGfuoMwIuB19y6pN8zqUjIWO
BaEKstvV1eZqHh8IvFCdSoiRKveGWPlv0rf8/B1iWGXl8dq5lyD5uQd+warh
CNUcCePu+vVuGhZo7z7blnGBr8KtPaZbGyjuj3tH+087Vz4m6HcvfSZjf5WP
KSeqd5XDy5YDFSUa4fIs0hzsd2Ua+XqLuo2pcBSSih8+INshvnf6IIhz4st3
Ccggiw2Hjw8pKtTJOWlmLt2HTYgIyDBFlVmP9x4ZrNmjp4+OrKXOcH+p+3Ro
KX5jCn9npgBL/4/IFY6VKzBp3IMtyERSviAf3pcxDEivZnzmg71Nuvv4hQBi
j/k2HdfwjZ74Le9c5lNMDHHpvxGnQ7QZuqfzIG1bBXNswY1RrWpb+mFvSojR
rCS1XxEaH8mGHeP+EhE7GJwGxAr4hDAR4UNO8NzWTfSJ9DkDR+gTWwjb2EJx
xfkHEysWSSrDDvCL3Sjbb11NhsGQUhON6FUUELzisGMspEKqDelE0cefiHBU
VZECYo0Zz/Mkc45dry1jFli8LHSbyocdlSYNIG4Hg/QYCE6RN9DnY5iLw3Nu
sp3+Uu+msETF54inGQKpFYryZTHduCy7ot+WbObbzQWI/tk3xW04SZDozm5h
LMsMbs8dvkV3vdK5RX8KUbPzWiKMiALTBZKIUOmrbF6tOm6jcCfZduGdEEOF
MWFsEStN8dauOYJTcxx1gXE1NLlOHkSDiC9ZH+5ePTiYIlvQJXz48ODI27RP
ezi7TSH5765ehNz7bSWikc7YyTE0+/+vvS/rjuM40n3PX1EXfjAw7oYIkOA2
I52BSHCEkUjxEJRsXVlHUwAKQIndXT1dDYKwrPvbb8aakVlZ3Y1FJG0TfjAF
VGXlGhnLF19YpGzP3DDrj6CRYRaw03xkugpT5g+1t17ZNIntDUiYLE8zxoJS
S/KDcWteHPbYomZA2MtaqAH0aWs6h/nslZudOTUxC/RwufMJoZgNp7PphRai
4nk0LMdBAVogTj8pQ+9PGQqZV8NntNjSB/jL6nl+71FHAk7Dnt2TVBwUVJFz
nWGKRtUd/5VS+cSG6xM29OXiZvQfIX3PN6GJL51janECIIBHFYGN9JPVeApF
L4jlVFLXGJ5nLk/xLaMLhIQ7J3MdvBruBqplnG+cw87vA6jQFgHTCzdihHdE
yjQpAP1vZV7LdSy4X5aMDdrUqtNcRgvhnwevLBl0CnoRi+/e5o5afA/u3L0D
LucD4yhUH2xmZMc15WRw/tCcM7gkOdCrRw5TejSXiysgprc3fiNDrIx5eBEt
z8kMY0N49xrbQLl0OHPqWPRYO62a68ifv8AZHNVvqiTIDcxXmKBjnI4hu3Fa
Qh/mMD+a7419V9+tTF8L9V9CooaUxsOkH7kmM7MKSqW1zXVpBnbRME9SqRQI
IIcjllFGMQobPBJLB8IZZVvdv8eHhf4jvCNeCdsF/02pI0eev3LSouta2Y0p
QxEjSxxTgvp/7+bAwSBNY14pTgWUFOLcUrNXwVoJTZezw9r/FybWYvQFGNwB
9snTjKiA4C5PAnUleJHNQrlff/0/+8Onm3U1PxmOyvG0Hc5OjmBsw6N2Bp1o
YWJBLByBC1mWvbtQm+Kk99vYXOuywi4QOyqlXUn1lpjW/djv/EYLYUzUPw8C
C6wkoXVaYJK2AViM+O1LrcJXtkqRltljnzSL96pZ4A8cyD0+eyCczZLkflbo
w3tUNIAiLd5HvfoF0p5w7abhV/WEdFlgPJFfAvWF5TrpPExy3DJvBLei2vaJ
t9RIdpaAh9VpPcFrU5xEkKrnt9zrDpcgqwvh9tST21rurLJYg76vIUqZPimD
QipP+nddCZGv9k8oGOka8T1vzw8pmTauLaR8nLYnmjWAhmkzYtj02iHoI14y
Tqe+0TWpi6eQSTXjvazlks4hDzj29wzs7I1B12GDOslDtmQD5o0zJA4oxGdT
UYFhqLzKNMcg90JFMLNwEEmWgO4kzCVMcvQFrQTgB4kTUypzPuPMJwFPjjOu
PJYanDbp36bggJBVhowYcCJo+Q3RLEwOCSi+IF/ZZTdR8myiaPXnY2ryk084
lYPjaqgyD+ji9lNmiKEPvd5xUs8l4D/vHAy+jwdhjHAaiBBIsoHCBmT3lA5E
HPMVXj8pY15+uUOOkd9jfuJnGI2g/QUeMO6eJRSNWBQmmaMNb2Oiuf4JRXP4
ki18Us/T8ricWK3D93coJs88h8DkhCCCVMUs2eAcvyR11lsznZ61vCqMW1k7
a9r5Z4AA2uSPbx4147VinVN3+Xv4CjyKWKG1zvOcCLEGGMb/zDXkD6S/qakd
3f/dxyXzPNUfuxMcmJBYow5BID/+F7v7rM3t3PMaJGkfF+g5Y3iB3zSn9Vss
FYivcy8oz3qgE2222rg+PcMKd0H3KufBECM2jjZ6BauygxwJmSq7u7twgvB8
gruVsqGt/ul7bNBV0HkzPPKYo/0YPLrdj8J/INygRTuzOcI6Jq+aQ4xx5+o9
CzgjqKFYQUiACQExFupbBYQTa6xsOiszSf7G48tlIOcy7Q5WXJ9VdDKCwklE
UrhmtNn8mQDpi9NrqRIOadRDHHUxbQCZoQzQ2S7h4qBDHRERCHwj3bitRrAQ
iKggTi1La0/oCpGd0BhfEaSdjqsSrmXqrVQ+Yesk8I2pMsuXIVhWXDIAcp02
+6ZJW6M8ispe07ANaHdba5+4lzuPlC3Sr8pRi+9pqSVE8Dn0cAZ/BCwJIM+A
jqCmWkRUhhMGZa9+OfAq/kxVle6KZOeJzKDiu0kUfADMvEZu7EIgkStkirVC
mA6dxZYmcJJGieRctD0+mRDv2YTgH62MiovR//NxmRDAvhltowUWBE74q3NQ
VH79g7cUhjP4NxH1tqDnGV1rEBjq0UVobQRiraGMYsMxb/VYfRmUNEMCadtF
cHMAeSelkelhFFlpIxIMW9qAlKOC4JDpr1BK1m1cRpUqjJnEYE2UZvHQWk57
5Xo3wTylk14w/jnXWsCGA+MaOJz8vTfhm1ilXoc5jawORcS9Fr5i44Eqo2Fq
zUgvLeewOGe0SuxQYrMw0yqDkIltDK7yw0CXf+yF0tZmLlF/e7OXK+rupiVw
QjqnDj/4vc1EiYVf7mymbKJ//VGf4kZ+ggYX5Qvd36TCFewsf02pvoOkpJew
N0G2JNDfRLRUyiTOVgMSSyfKUPIW2VZMfR2XJ6OsXKf3Fbio6snJiNigUBHy
SnCVWIt0dQQSJC5uBo+zCqCRd9T4feNYPE1cwbTBWqzodyFXC90sep/ZTc+J
5J1SM+7On+Cd/2tZASGnH3yDbWRjc2WguCFOyTDNDbdMc3BkpbXljZlm6D7c
e1eiD72/GU4BXdwpktPofAksa+kC0DSbOrik0QECI5wlLhloCveg59qeU6+m
h2D9NwdSPVNszDc1lSqhp1sqxIcH1u/j/z0vcQ/JevKZKDSxHoYljLZKB0l3
cMtT73+sgnEn869dgbkO95+at4ZbC9+KzjNvG3jgT8XC19KKVrQYhu1uYRXF
TIFLhPzkyur1N0R6uS23FL6/2ekLnxj7uDIGh2gOFb8GcxkvT31C/G9KOQgi
T8AlFUQvAMYDOnrBsis058KzQy+PKUQn8Z7JMX8Tfg1/Ng2Hapv7VA1LMyQB
v1IiVEjcIxdnzaiS8iXabRCUgIcmJi84cLZNy06YVq7qmxsnc6NPxNUV2U4L
bNCTa57M8CafTxcVEKgneA7h//AaJ0fnINySuSMJJzs6knxth8HOKqvbyx1I
xiruiFdSqEgPr/5NfzXQ01y3oVKAqa3kSss6GK7dQURo3fMyErZhIXujftxQ
tFxNSORey/2L+re6UHmx+3XPw3/q/guZSFcfQlI5efXvpJJu5ReTul8r99Qo
Uz0v6b/DvzJa3eovx4ri6jdOj0Ln9IllQ+1LoezpQui6/o7zpFb+IkcWl86N
/i6HzFt5gjKYidDTJYeh43/gO9bfY3uPoxt03crtzBXaboRKxzHR78JLencE
sdp8JNhhgICAIuWkHdfzJMxBkqxt8CK0xeo4/uAEQIDXAFwWxTdQrlc4QU6Y
Dcobw6Pw+9/QnwieW6UxwbIAzbSalUQ4vzGQN3PORGyrQtXs5HxyRGMF9b5s
xXlG8FwJl4Qaxnih+5ttTs445+8ivMGaE7pEWm6dvwbqPrmFyZtYtGPARoTY
ScQmS55ORNRGUaPqXd2izzE/Jgyd+KtgGfsmkNX6C23A9giZNrFpZZ8PrraU
PwkAzRF/84CMcjZcvDl7dD5Gb33OSQqDVOggVFmlXXJxBuWmIRojD8LfpJRh
0gboAvQqoQjgNTL8KCsM0C0jTCc7rJLp0mL0MG2V+NvJ0wnezLZAm1vyLSfA
XHxqq7gns49I5fINmY+XEDAjLLc3E6GC+lEVah2MWdFI9ySMxF1UI0CKUHZZ
c1rxqGWzggv7XImpgWQn3fOOuw/jD0mFXHHlHW5v1H2kBMuESJjxoRBBaJ1G
QQxxOzN/zwhqzK3z95jv+NLMkYtHyAZx2uHCdFhGyZ3GHEWMbOiu41KwCU+u
mF44aFsFPHiuo0Libn9C9QBT1vhkX1Jbfnec4CrObWVyODYpXS8aIWMKTZQT
Nmrtjg0q7oR74qRMCk3JqGJl9zm9kWrKSw6Rih97erAwFsYJKTYIzjKOYwXo
IMiPf0N94/nBk6+8gNnm//SaddoJv3cgtKPiecVOubRTIUlXOAdW7hz3hiRj
vtf9j9xsOLjKNJ8gn0fEw4YnIzg2AQ8RglQ9ZGsCkspUgOlbx+6UuZ4pK5bP
GSxt/3ThwkMFuXfTUTkJQv9Lb0SdogeaJnJcYjoNQK4UfaHiimzQeEbrUMcO
C+2i0BvSHFOqdphWvgE5bBONRixv6vvM5aJUz85nIEGZRzItfyoVBMkjiye6
lxZvgiWAeheMh1TPHdZhZgsTdwD/6SrtuHquFQ9ZbNL0JDsskV1RJv0RUsPR
1QhE/RRNNHu9uzBSAmOOoBC+poInFXvGUl/rLpiLRXIfIl0iyO5WC5+OoEg1
fj25CuDDGBpFjETPYL3KpnHsIJnxO3U4xAuOnfDh9Rw7CO1xs/7avuBofOMV
XA0HgxskFNtNl+GsPCYy//asRnQSHovLqpwRfrp4Ub2bFwfzatpCoadLAH8C
IpugKFjSmFW8OWJkZlzdslXdJIB3vfIpCzSJMpPSTh1W0BGo25tw2sJMnE8p
LUuUIoGF7YEO4EUPuDHoGUZ+1W38rKMeha6EyUFNwz8EVxvHa4xOv8n+fYTY
lBQFRgjSEUB62R7Yn/BF7qe9opQjEDriA6GjkW4mOvMu6qZQEAbVNJrWWTmn
OhSIwL2k2LUTln82AQBlBsH4Wnz/5BoW20CIPxM7GiwsPDOhsMFby3E8YMze
HGtll1BzrZldlDPKP2jc9Bwh5JmpB9VnVOmQBLGL5Itek3/r7S1UWBxPOKmN
tM8UxxePARHIoMow9SIFmKikFzWznWwVsNniPLcn1ob4dYFBwjBIo3taBI6x
JzIXMeqco1GiaLYk9Bo/TEIZnQCk3Uq6AVHOSEIAgnscG5HGcNsg+GC698q3
DdFpmOqHRgwi+YjvFpAFXYp8lHjcgM0UO1wYGA7Z+V4JWDpc+CNAq3BB7RQt
+WeLXWqbcaReZ0WTlKO+mIGd7vWYklAufBJMv0SpllslvisaPSqu71amDBYy
lmcUZPMaPXg5Ef5N+5W8yd7addhpuZiE/9kv0rRmEgA+53hWATpZkTQ+8vcE
iCAa62SuxC3J5aYWAsgXSF3kGCxW0KgnLl18tkjekAUZNpzY8ABkwf0ghrnr
NcyfrWQ+0yk8F2jly7Y6P25m/sFm7J6xh6JYf/nq2QapyUAgPTqFMM/ZuDXV
hiTW5i+9aja6pLvtQKpWWdkF9lVogcrBC8sqqFUmvu6O6imWKz+vIdEwSwUE
OFV0U4N0qdsxmVCcOIwXjQ3Y2wahy2DtMSowmNmh068hApuws4ucooyMOk4y
ij5Oq+/nznWmTvBahLyAcSUABYonbD2GbN7iqdFnfv2DX9Sh0XC8LPtzyhMP
8zgu2zkmq3r9HE+Eqb2T5LvAuYG8zEyNMQuB5Whq2i7RwFKzNuGJyo3t3Hnw
AEm1eKOOyzcVthkw3wcwSMyZAVQYpJR59R9cULNu9bKdB3cgOzfYyRS2xn7/
7Gfm57bKw6OK7lOfw7eH8q11V2R/1vb+8vLbV6/3Xj32qmI51UmCswXNrA0G
xb07G+IdbQig6JUtAi2GlB6CdkrujimG1elYwk6SowvgeJOzmHrVkaOLD1nK
4bh3IHWGqY2plPy8oTOoDLuFQdugY4kf0E4Bw/KclOY+gF8idQGvZRs5SOAg
CA6us7Tb9+7jTkmKuKo2nTkLUUlX5ZH2XSBPLaUd+BM7O4/Uw+haJqSL4t2h
wJnXwLFyaM9EoqUQwbZFpdFqaoySX9xE/PJ0Vr2tm3Ms+y5GAYtprD4KStEh
y3MKw1lnrpkvWBb6PrNPCADfWVHFOzJbCRaNv/juqFsuTEFgR6wiG75/Uh55
e4n8g5FnmSDjdFS9ZYSgrfWSXXeHiNFSJsMNcvHRw/419FXtJgB50x77s7BN
f4+fldM2aUH+7FBNkWp55MTt+NngYXWzhUD7PCR2uF01o4FSDRMSBPvExF/k
t6bZ9xp8M/Y3hxCNj8tjvG2w0hTlz4XigYSiC5oU5sq/pmIXWPBiwWJrkULR
cSuOl4OWaJ2QmhtBqswpTlNxOKurkwKMzbe111oJ+BUyWNyRvxShIhi5a6V2
llUmxV8qtjAp0+jzRzi6656YeF8U61Rvj8H75o97/FdHfw2Hlc9qW0F66Lzq
zEocUYCB+5bwJoZ/oyOUMh3mIfsnQJNkNgYA1f8F1liuNtQpIg/DHCG9p2cF
Mstx5GleGtJP+PRnOBKCLXsbkW3scDXEpcnwBqEJJFWuM4PYs7DVrQe34GKg
KDDX9/13N4BFxg+LDjWoXK3oXNQm/GGdqgPi3GyIBNqnXuP97+Z1Fck6uQj8
wsvvhl7fMddz0jMXyXLftSdfS/EA+LctuKkXUNkpqeHWnzzX9/w/4bVx/a7i
woycVDJDYYq3sPrlEUJhM4vg0GB4sN9nk5rVmjZrQd55Md927lzNj9YitPF9
gS/QZcql50iLDEZU0LmJGSiPUITLhLJWJkM07bmAjoDLYbI1kTUuO0lrbScU
ZQzOodxRLrlDQ+KfYlMtLKaj4jhVCCjHxQ/8kqq2QLoJQET2YV3XD4a4RUJX
0QfMOgf9MSwuyjvtv+wjoyemohB1UgnG8TUQhCp8MzbnDi8JzdQJijh/3GdU
rxY6c2cgig4nx3tbfO2XNcp1P6H8LzDXNb/F3ph+cNXm6SYu0V9/BJZbzmAJ
S8ZQKLz41u6sJRBQisiKXdhKmXO/JU2oi912AKaKx7j+y+d34Mb0/zfY8gL3
hLzZ6oo7Qqcb8vdgbxjaaTaQUF4JccN/0UEWJ1GfoHJur3NJiAxoV5BwdFBc
It3o+pjitM+qYy1iglLtBKDWaEkTmrwagV8Oa/yABwRQ9Wz067LRSvBNGvUV
FrgkefnXH3/5Sapmxg9paIENAUoR24OK9YCfeE62lZ2VdZTGxv7Cr4eUs07o
EUes2S1dJftRoBhUICMKSaVZEH+oNVzChccShFwYsYKITlRLbI0+L9S9QN1J
XWbicyEFB2gp1NVm1DiabRgdanOO5SR6RDqP0K1u028PKVzAzmCkgyJvWMd/
J9FfqCiG9XE12WhOqpvWGwcqBFEoLS4AxxAnxQYFr6NwYtwH9heRwjMKHH45
JAeZmVxSe8jhzaLddZ3PXMkpU4ZOkxhpY6jXhWJPdKYxCsMeWFN2+bKoapQA
AJPFjWORErQRARSUX6/ifMJ85PIOJcmyhRVuM0g8cLp/cefixvajGjVa2xhf
4wTcUIs7rcONSyAHA/V3SBXl2De5B1/tPfn2+fO9F0/3nhaSPMluUrOq3VA9
Mv3CBU7koLMQRADFHGJvMOVkd2B4lsj5shuVVDIbhcCpavECHIgwgWQ3mAEI
pKVKhluoZBhzFElg2NPfNqNzObFeu2/PT0+Jta6EMzcdNZdjyXfF08myBj3Q
WBA+yZyPkBIq/4JA+uWPUo+uNnl+Xf8MvAkvfl48Q0CylmXDnpBmaZ00e/T8
wPxqDToMc+Iv8P8EvpHNZna6Zp8AAvzi7+H/gufmCy4tuPbXv6/5MYGLGxmg
wd41kWir5sby9YviR/Zi/OQHiCRNBTb9BQL/fOfJZzYoRuUhaHygCG344b78
+T/8mTj7Iv677x4+oK0wZ1RwvOlpiac6NhJIqgGCl1oloQ5F7PKTJRT9JlVk
9+DJ/n5UcBoKY1FzPY2sC4jpf89hHjeEWgBJpGwRAPj12l//6pWYybm/coGB
E3SUWbEOS0RO5+0hlaY8nzCh3Bdo7MGJCJSk9++ZkmCTao6+88PLueRErdsl
D+5PbIsX7tFOz62tQXsJS4TbG+cfIj/4DP3e4emPL2x0n0xre1GjtdVNdNUc
Msfv8eHHCKGeicHCpk/4ADl5WHauhJP4PcHKa9oa/x5xSuGbznyTx3TwvPNh
lXn0oTFHSjl320lfp97yFcMCNSyqYRBWMirHKNJELdCzcDVoKbb9k571EhYR
vsGMfTsgSQaeqDOKSBlPVOps1bzsGaGtJrHSjDca2GZudj4Z0BWKDAlsbugg
kJSDK7GzflkBfHaz2hyEpz7Hhf88ln+we9sNLGQpfoVzSRzjjWSa9FoBoCin
yoPBVqDTMqpRvj/6GRB39wd2pwBacbo1nG7/1g2o4WUf3Z/E7J8LfUGiQGzM
c3dnjj0wryPIEZOsCaOsaKBeYvwiwSgG/aGNHJmhots0lWLexO0jqy79IDWW
xoVKW0cdeC00kq1mP9rR4eZBl2o8Xh0nOROx1irxv4Skv/iNY1R2XfwiYE/h
q130nQSoxyX+2i/zuaB9XDj58WmowNPQEoor8gb40bGWMrl0Pfw4cmGYgCop
KOKXEp4QMfVJmRTWm5gqJD5WuIEdB24HERYsQyiiTqblqcESQsdyFG0Vq/aM
3rowdmw5cTIhbDLQnIU14wZm7R+DkACUDib9OqepzWg8htC5+v9SWwArDxsa
D9BYnWqqCO1mdFIjl81e17YRQIr/x7t6fD52JwAH4DcJosHGgtZSRpGBYxUu
D0EkagTVoUeomI7Ko6prwpPTxblvIZyrMkskoOFslskgP1LqIWRDjDy11KZv
aLj104AukzKEQ4LLB/iN6neU1zrDVOrSAXUgtMEt/CROOfhdjysI96R+8ycG
8olziU7Ek+f6N+t4ymm87IZCjv+MWkt/BkfO5103WEEu6F/83xB5NRlu+aVS
fRXfRJU4nO37dzJqMX8EJzCOY65F0N4oltauJc+yBr6hv5VmoQf09Xv26/xH
fdxPGj07gorB27lHSdcmTduo0TA8+GeCj7EAg7J1wg0C5xcq5LRnYI3Z4GFh
Knn9Ql4b0i8IUYWc0KlQhZnn2ipCS4bqYTnSkmBOdgu542Q/KR0Y9t/GG0IY
Q+BMUP+haSZio2MOb8jo940ayk5622SWd3M1vKZBILXprPRNHLGQi4qK0bXc
1X0wN4TxKuUkeGWYdWAGSElyDJKfQKGOwW0jZ2eAjsSs5y2YwHRXR64HfEo1
AM61v6jIcsfzyaj3yL3ln0/sxZ9px4ZzZn7hd6P8F+065S3DKz/3gb3MF/Y6
n9iLv7EXfWSXBD4Rj0mF+jImrRcPKZLGduG4A2DbJkYKI6UQlTbiW0kAVDSn
UeiC9qy/nJxNy+rxC6nFQMjdTbADuuW74aaTxgZJn8AhwuS6ZnpYEmMCzUXt
r2C37K3gNkWyX2BHg07G0otiA34Gf/3DET8xxLMx5LPxG54JvSDFeU0aCyp1
XZcOInpAkLSAjgWXiNDNwczU/DZcqeD/94ePFrHJKmhUqM0ryXm0AfGRIqAm
7Qa7WZQXzukH2iYoEhn9ThQ0PYlyOzr2eD0LRCmkfhhutpGgTDMNkyoEJRGi
ZvncEqBLO5lD3INm08gWADnj9ZiS+BRwJUoEhSKLBSvZbZ60kCWMMqjQjayV
BswAKfePh8dzCczCccE8CblrZTyvAUQQMIAJwJBslbCIt1LY8DThwuvfM0nN
puA/sSFm+f3imSx2T70SNwAWmqPKrT6jRXZG3dIZFTZm7Eo6pzRNm6TfaVya
D1CikWs1DiEBEHpDMKmVLzdENGVWk2bEZ6CTyhe1C2zjNKT8+3APZo40Cnmx
A704PqlPzxnreTIqT72UFT42sEYFGoqqRgrcYCZUYE9uRtgh6UkcBRQngZ8D
xkvUMy4IKIZu1JGW7I9OXARvzWOvRdegXQCwhrks5ftWKIF5AEagC2Z+MO9o
btKpmYKKPtdP2C+cnIqgtGLHBTNBv4tUNsIu5A/QEdL+/BsPPuL8vIrQYjc9
e6Rq3fWgRA2QemAOvNaQfC/6FR01YNzpfr4+CQpUMIjDlwahl1JHz6UJ6cqi
OQ8Mq6YqxaR7Y3L/5U/GOgowuEmTyRXBSx5ZBX0LC4bKhshpUxpAEnvycZmJ
upYXxtq/4jSO8giZ53Uul0GE8sNburuzhBQk+bCAnWVP2IInttW6dW/PRxPC
jPvhPG/aeX4o0uKEoGtvqxBVVBT0wozKiCcTEyn2J/6uL6lv/mZKv4bWCZaD
Qx8GstNrJhD6TDQk5eJzOlCPLmV3+IOJhqNWO2jPD3/xs8xqzvNyUp6SF+8Y
NwKRcSaAE66NlF4luqskrfY4KY1kIZ8OIQ0aUzPCGnPHAGTT3fOmwErggOn0
gchAojaDw5yK+nQTUyyDLR7ZuuoNXgLWcDodXQqCAJnpJPIiKRQxrh24rjfI
rU2t81UDzhtmjBHSYrxqWrprQFOATZMrExX4pYUF028uuOKl+wihRpPq0l8t
QJoQfRqmSb7sFQ1hoCQ8NKYNie+EQ77C/ibMwQRKZ4L57iyhnAQ6ScjhZ9aq
jt9UYLrft04S5I+5xo+Fz3FC+4AhNfqfjWgNiPeJgFRo5UySpJeIyzlJgAyK
YXlyIoIni0ZNKQaiRTaUAizHu0Cu1qGg6LeDUGPUnlmknzF80X4cw4klaxlP
OuiX9A3N4+tiZqt3TMhlvajACQtnFn4RBbmDvqQQ3FqzOl5HPjvCmfMEnHEN
BlP8jDQqlCvVAA8jdQRFctBSclOWTxB+itY7aqeTrjRABydkVqBmdTnIIhHK
ieajgZvfcUQg6sL6M9DQPt/eICfivPNWzzVm3gN4TvweuhXs463j5++CqED0
EZ1Mm6CmtyA59lREUB4OVYw4Jh98I1NNhecWTq96Eu2Rl2TWtGJJ9rCDQuQE
/Tq6DDTf3WBiJJSgxUgw+VEkEEsjqqSDwkRxySpIm6hiJYgvU+wGTusUIgLD
7SE+gcGrPxOnnhbWrhg4kXORoyso7Cal+Hfs41LIcKrddHaTb/Qzhn11towq
5voR1rREfylOR80hClVJjIuccQMGlF123jNL4ye5uzIu/a6UFyK+eAxCNqDw
EJz0wtY3U6imUyWHgSY20BZQKNR2MBwPjSFC6tdre69REdyW8SaKKcXkg7Ad
aDVSOgryOg74KPCV7e0VdEshbQYEFvj3LiSWYDuhGSym3Ses1ZHXVpweMY90
FR4OuXPQ0xRbvkxRbXEomwAA2e9G4+Gk6Rzr5KIIktSD2tbNA2AFST9WwRlI
19X1Wy7jZWaexUeb38ahIFKKHIBmzIXbVcOkelBPcvomNKCyE5Em6rkL79lS
AZv4UFQxsJVxk3XZLjuW0fAha3DJ8JMbEk+yfz8+zEGgZ0aR9FNnp9TyRaG7
/uVsh7PLFd1I2Ztsa+MqCq9hYkjLlm1C1Br37qyC6vKcSSO3UnJi1esVH13X
dRt/BEc3KoLKWf2SjiGFmSBOQvGM6PoZOGaFFUBydNBMGi4GNXsc4k472HL4
xE57n0iha2uxQKFylEExMnW6uoZ53yEhXY6cLixycG8pyccx1zPFLyJz7VHY
zV/EbRd2b8Ks3d0IICDbLII1pS4ANIObITKgMuoACJQF/e6YkMEvomHuEzia
A2hk6ac6B70z33rURXfIOURiWRKgTBQyK7HeEBcKI8dDJARXvzTY+zPnaNPC
mepbYaF1Y0mZCkIGtQeZfsuL25lxGJYA6RfOmU4r3JN4dEIl4EUHIS0viYCJ
L9RnZ/MZ4rMvm3ywPcA9DkQUUXDriwCWV77nVkQ0XKgvII5EMkeDtR0RADjC
kziNPHXsESCtYp74FyE6pc36RrqyBT2Yxfmkejel4F/arrSJyxLgYUyaU5Uz
f03MBNFtzAyzE/yL6z32NWTkzaGaJ7jnJoktg8mPfqPreYin254PreqtS5Yx
/NDc09uxRoYrXOWcyVGfZBwseiY7Kks40NmuZEVAtze9ffHv5noTLn1KM4MX
V7ukP079+tauw0XbIFV6+BYM9DcoRcngCVIHvKu+Q4Tpw78JDmtTZQc0s1jN
lAwrjYQViWZsBtFe71IfmEsdpgEnvm8uLcIvNMejhmbiHGUkgkIhlo1L2Ogl
T4NcsRnboDsVr9M7CV9nKqfNcPrvplZEfZJ2vqPa2GVZpTPaF2hGyxpn+2LN
WylS0UbNhS1HGjrD1UzcC9bnsUutnhurdWJLfEyKnfLKL1Htsn2/unK35HO3
qmNdabp/fy1r+dD79azl+imlyX6hZSZZb7qy1uSbSNWmlZSmJeqN+JuuqDf5
ZjpN9za8SHMCFdTqTvHB/jh0lZ7O/F7aiqI+CH5JlxLuGamkGQf62BgHj3U9
OfeXSQLtsGD9JDGJHPShg1ExAQiOfjeBmBTmxR4AhmMPw0TA+tI0U0Z6iXZ7
PCtP5oG9QdAc4sMGx/Q0omkEFgGLaYRrU4gOcWdfQAyYkkwDEyPVosC4gBAu
ugvfN/+UoYpUnzI3aNgqpGPkg1CGDXL5CvtHmeVR2zTc45w1z+RrMKs2FdXS
rVBqksmnlbwLKXmqBfXIW1wn5Gl4+BTOLhBqFwH96O6sWd4AWKemC6qXrRLQ
iaggQnldpkfEKJYBXxYWa1l8bv+zGBZbgrfkmJuWoWQ3/ByjZiO7MLQjsSQj
fvFNVSFRZumOSn8fgJd8eing1p/pTAIHISYwUUF5SHso8idWpoRJLJjckmem
A38X8nfDg+RwUePmo8K4UUqZ9JDQnl6WnU/GzTFJX56Uw8of3BpCtkyx6uUg
xBrmiA3wR7SeaoZv9hgpKIpzgAg0AbF4oBUVrqQJUN9gmSrAopzPj2BTNicB
kiFe64gzhTawenMx689Gksf+7GB2iGCE7YDq1o4F4iNwl/mdLtQ1pCwoe6Ij
QISlq2Tmh10WTedB1kB2IubBHOHJkKqjAdy9hMq15GKNJC4pAiyaWTf/Wq0Z
oaWQGCCRNqRQOfXy/5kwKkCjz0/25b5pIChv7eELQK4jPQYD1SqTHdi26BxX
7cWCTjidrWUfLxWbvyb5bmuUBgkRSM1o4w3NdmriTDbSwtJCE9Yh546H0D/L
WZT9it8WdSuZup7OO1qHColGT/TQWdHNu23KuVT6IZ5GuPvd3sFzPRI8Mi46
gCVfpQpAydclMNAyZg+JQJHlHyB9kG/rD6nXoVBiTZjtmSZjXo+pqLh/T8FL
Kg8cBy/9itWniKe8YDVh4lVK/z4mslPnuJxTgEMbrtAUt0VkG4FddE7XaEo5
XVVIoMjAVqc03ZBUoVqx/+9nuwevA0soMAKVhNuw7KECU3fdi1RqPSACiYUc
k1srpadUe+DnHE2JUktFyshFhdcT9pfs+rD7VLh5cRW4W2LBBcqX7B5iP7Ai
HnVdEWPOijE/Yn/fjCoANgNipA6Kk2VHTtf4z8hXSNCcsBhSemE0QvFvaayE
r7eA1C3OfRCOHQD1W5dVrIz/+gf1ZwUav3F59BuBu5Nax9AbNfkSvkFlrBGK
JbxlAWCNDsyIDInMFz5ZnAPUQ9iHnM/xl2zGDuwQxJcgwRSTd+JejGiQLFsj
kuWhPonYAFOPi2K6XdLHAW7OPb4uPqPUVq4r2WGGINJ1w+AU+o1KienXVg/d
lotIdrqUW3nWuThoG5K2+q6fFDWS8UEz+M55uTINub2l34mzkgwWPkSYPRkV
3Kwnb5vR20pI8GFaxv6UHLEo4fJtgGw6n8nO7N71ifsOL+1A0w+GPqogIadd
YHp2LmiHKzIsmywYvWCz/qJkOvDhYrLd5KdB8eV3z57tvSo2otS6iSTVBdZA
VLPAi5+kIvm7gWR0QLUMCja9daCirsaEvyBv15GsCv61tbldSO0WSscjNj/H
PQQ0nFRiwn1vyDVo5hVLJ/egut8oK4LKysLEEhl/bj8pOxtTTDYGL0AUxt5y
zgLeMHce9Ui/etv0HTgkWGhW6i9CU1wjHdFQ0lFcJFuWcMBBdilxRblHUoe3
JOQ78Vpgev/dB/6rdzcLoJiEFk1pxITWwX5F+2XqDAOWWxC7cS3mfP1GigXI
Be1M1VHL+GD6w/UksEfcCt8fmA9Pn9ByjOw28KO7d+3RqV+W6WrDaK82ypCV
de1ROk4C6B0lOjc7rkpghqDP+D+aXEwnF6myM29K6gCR/xha2kDgrP19zpSW
wWAn85BpPBZxTXjxshrPhHUSHMKhAcY6rNg2A0qhi6qSMyBHl9xG63c3sG/r
9zZs9W/jPdKLgyRNpPkr2sk1Zk0QUR6CyEX8N/WQRc58UPDI0KKDC7n3Jsa9
UifoQ+56ndCdugsJ66QV09tksgvLyISK2dV6XZqGZZsIMYE7rI5KgXWB/5YY
BfCxcB/3FZHSUTpMVuE9C0rCacj0z2zh3A6Wrjmzg6+0gYtoA7tb2cBURMgf
8S6jnpIZeIPM5ai1Ua+Q8GD3dWBJJV4ioe1zuaeQtg9W0N/5tBX8/E2UQptD
pIWqabQtHPO4dHgnzbogFWIA669AqTr2WjlqshKKiYK1hAdXbGTbVcl6WbY3
iBIThmCwiSTTY4rQVdTQCPoFl37kGMGKFbqBEtLP9bXJ2vxsI3Exl21htU9K
QJ78hN0489ZPOTs6uxTfnLNV08VTRaoZaGbQhZiH4V4/D8MkZiXL7T7/Gamv
sIaEC3u0ma/1ASWQXP4ldppaHjFJzfYzE2uPLqM96hLYjG5cjcU7hReXWMNY
tURiMRcRi4GjVWhkA3+YwlopaRAKF/mtfodJozYkuaLhOqC6OTqsleJYnV9O
2bhDY1wDieijlTxii0bH0lrkJwsWI6QSe6N5dkzKIPcyZgcJ9VqIVRaPG4h5
TN01NkbLtLNpq7jxbfn39qiZVi5jr2c0D/AIqdI9sWJ7EOkPVpCbU3ZcQxUi
wL6HuyypVQBcEnBWDUNGl+eEYhcXVRy+YOxtIuzUEI04tIj7s22gEWLYNPQ3
S8gqwkZFugqnmRJEhEbUXPwNpZARyWJWk/iKzGlB+BMnmeM+Qp3eriatSo/p
20khtbpHUEpdnFFkqBOg3Yh0YRKRLkgwB15w6QvyPFRR2t99setNoglsMc5M
5hiC1EHSGpJQJJ1sbubChQM/8XJktyVyvuIFyowWeZkazBReh/Y3vFw/LWeM
eDqljEne/ayczCoqrW7OoZP6UFhYHTj2Z/R5vE6+fPKy2L5PFufDrW2qHrH3
Dqp4FaXEyrjyLI4R/fkUyqHvUJwGP7f2GpkyHcpSinelNVmkVtU6dG2jeCmE
ue2aDImqRpDPFhp9VUlNt6gUHxYZY9PH1DqFHv31x9df7R8Mn3775Lvney9e
/2RKxMCeAWPUL87S0czkw2pLr8VtrDnT5ZV6wmwux8fYyNZDcm/BPx+hXdbw
h6lVPkTfTUrZGLzKc6KYPa3R17x9R+NKDSYqbT2UWvLfI0ziaQjeDnQ23dbD
Qbco9CDpsNt6NOhUse48tH1nuHX/7sO7g9DVAftS8rN8NGraykzpS28owDSs
00W2tbUBv3LaN3IgPPF2v98nMGeLXsMK9/iG4zeQJPciOjMM/uDl1lWnUsT4
mCYGMG0uFu3meeXAAS9+yCKGYXnd/aCqis4epPmQjbiHKALT+Z0N/h32eYXt
ubZKO9Gpwo0X+YTACQQDXVtlv9y5uz3YtzejofP0C97dFHfuDl7nxTaOC+G0
xfr35D5HNMMrNvyG34OZ639xcH6Iy7mRa/7e4PVZnq6vPrb013jxZd7f6eue
vB9iUgxLO+5CWDLt3sd2u/A7AIhEmJHcyw+u0akuPDLT8MOBam/X6NajnrcF
SUWVvKurr0M4Ft8caNGq4hvQcVc7Bd3X4k2/4CoBLQa3/PIKVRlfMx8WMCu+
/dofFCY88UchHJolzQ5eDH7on5EFnPZiHIf7c5W5QkrIA64AWbxq/NIAh12x
/t3BK98YtHv9GcyzGPdOW1bG5NoYoJyTAJLhYV4ycUv0D1Q/XvEoV5k8rppA
N/815mdn56qzsbODY+8bJ1F5gXbY0Tuxyl/LsWWJqpT+20dYG8v/94ziy2hn
DthmhQHAL87Hrp631eiEJuSM3F+YCPG2ao9nDVbHFewCEpthi8fUXMQFShyh
Ym5ADLGYnl22YDlisdhWa5mGFs7HAxf3kBN6EQQKBgJGzKYYJ7X1uMqWS0+g
dciWbMN0SkVZzwbUEGVi+8MEMX4u6gK61jkwGnHvXGDpKScoxQ4pXjYWckF9
QEhYgDRUgmYn5cydotUo6XjzM/hP8FcKhbja68pDBFd4VEvTRfzo6I5DFfPu
g3sPpdDbc3RNpTsdWZOB4htbfqmBXDQjS7/izUjqQaplIi55tNT1XRMEPrx0
GrGl+mnMasXF72BE8jg7s2xQbL0VHwamTnPJc/hG7xfD+N3hZSHoBO2xRix1
Dv2hRI9GC+gNCHmhqw4KaVZjIObnbs9nDas/gFhrz0rcfLYuI/c09Ko5UbbV
HhdvG2KBcOLqwNnjeIIMwlei5b3x0gyPB+qdnXQGbtvfFUhP0KpnFGembDvr
EB5FahA4+wfko/EKfNhGvo8vYaLh0sGhtoGJmbeOwPWddobmY2rf449aQulc
zYkuJxlsbnr3RaBJwQ0MNvmMXV4ADDdBVVsSmcL9L3a/1q3NAXct2YAsZ2B/
I3F015MttBwzjqSdT0LZKd/1gSP+trMBPULURIismTbNCYlJjovbVwNExjLA
DLCrHFJD6Mwho31+4S+2iNcOYguGclgfD4+FwqC4qEqQu8i61OF5C5TtCN95
uuPWKcSKrhc9VV7EDqFKSIZkzjC8UHEyx57JLyVK3OFpPgtXQKlFfJA1Ed0i
mPdB+0crbvl2xmRQ6+yAT1mKSNMQA13kvt3bllHH70xML5DZkogPc0zrcpAz
36mTPz4EoQaIxatAQV4dhZbhaQHnlt9DOnWI1KS5auYkA1NGjLZh6pQzobRQ
4lJksTAsAlDeUa9bf1dRjm55XI9CLlzV1c2RQdNV5OmR0o8wDzMvN712WE7K
kb8JWyWvRzLAQJdIC5YrSRSGx/k7XpqyqG8Fze4PQzTHkHxOv2pm9d8q2Twk
Aw6UUB9as8ggAQUdMC1Bhnzfufh1dU9LO+rVyyGMYODe8HeG3B6CkEoepK9t
FZ0yslXgnzpG/hgXYonK8kilkPPf5mqWs+b43GuDqZZBiTehvhLQfQMoEARj
OydPIKzHWT1Fj7m5VLVAp2jDNgaNkVCaT9jizTjzaTJBkavwm6ZFD3HNXiJz
efu/fntyMoLtd1zjbyDszWcRXgWWZP8qp34x7QvsJP9HxZnF8m49Da6Rx+3O
9qPfftuQap8sOam6KOm2ZW5aOPnIjN7ldhfPRhCeCKI9KsdT0KZNBP+icQ0c
HvYc8f1PfPRQQGtyaVRtBQQcl1icpAa+z7dVOYo0pzCvVHk8nCTL+YM8hQTZ
cv1ruS/V4nFiBlL9Albs3aXWNHISN/JKwtArIBXpW/NE0j3f/UHKS7CmhHqO
N1xAb/ENf3ZcyT+93j+v4EIBrMeAqn1Chu7Ya/qqFkhhGCCS3X/pdbBBgTUN
GoAbjGtIa7J6oaEojhhKg1LpdJv7ZmNuqHDG7GxJLw3+1QWIzETjUIOizYsU
E+giR5kQ2nCGPnQoxuYFGuqOgAZXC4oRfzdelDO+/vv2/qbLJfgpx78BsHP1
CzZHsLrAvD4Vfvi4ln2O0LC2l8ke9xKnoL+a6SDuOmVGRWBFxl0OLQP8BmZT
EYwDDgwS1g+ySZK1UUpqrh5WcI1k11eTRu+ccNVbvdXMluPZaucQ3yOxAXsi
rWwWcn44Xym9C5OIflRCJpoVS8k9xFZ4TkgrpiXj/fc1hl6/T63QyXFwdzz1
NtRR7Q8nSAiGbDDsmFaawrfH5jFsAFStCT0FoCSu2JemqAVN7MvLIjKzyK7i
OLk9a6mWCBlcolupWRkqu1LOADkB8Np56WeHFOWVbUn/FjrA8jfVl1zZLUgh
2FEBWsQGBNxbL1VvjPZgpMjTFYlbMaj6/+YVFcST57ip8+/A9w7IWO1AUAAn
4v+8ewSLN6qOTwN96Wfg1SX3yDGPwD/5jOzbWTWMF7BVW1TOLzLMTfm1eLc1
i6705NEYK975O+4nvxp+4YbNyRC2AqS9yePA0xQUYApFEiPxhLGg5Hsaa2pw
csI19AnRnt4PSb7bmIuPQ6bCMd4QEBpxTOCAeZ+TCqqpiIoMuXx1OzufziNt
ShJLQGeGX/o9C0ge6mZXBIE/oTydVcSIqT1muIRBddEESPlxlG7VaLTJx/mi
XODvm2Z3rFjtCuSYMdMenHqrawTNR0Qpldd0dLDRecZM1xW4XjlpNIcMk8sG
4uJ+jstRqlwaLat3ow1gjRI/E/TZhT5z/c8Ok2qVOJfk/nXsEYpLQZejU4i/
n41bwWobdYMlglsof/ijljo4Ur9Z/viZRxb1iXimZr4Vb5ccnUFmHlQCDpgZ
yZNIS3byhigoj8VmVsAWwy0Ru726N5jj4xaonhMid9U67t15eP+338gYNd4w
6jaDnqR6MUpdiSIbVyR2/nsTeCKAEZEnjoKclhIDSjShOV11G3h6ITcHUnOc
Bfp0FVdYENnwtE1fcKXDXZScjjp6Apk96y929zdYy9q5t+3HK4mRoWvcJcrl
gNQTZGQNVBvlaEyiPripSYaF5I8ZgFTJRR2Lr8D/z8AALHYVIbdR0phiNLZ3
TnsHBpFwuIJ/YtJMLscgyiLr4hfE4vBj2HNnus2Fs1DMsgERTUWU0QccnKC1
oPHr1V9/pCp8U61WhGThr6j3iCiyvuU54sCAm1wmg6eS5pUKV2CfJg12SO4K
spoZQ+eFBhLWYVkHMgHTNbRL07u+WFiiqOcO8/xipZFIjS+1Chl6JCF88dbA
fFz8jnwBlhCjNWmC3pkWFPZCD9B6CIsBK1IKGkkfQYNE4EFI26UDpEcCt8x+
Z1ew/sQZxAB94GdQ+4u7OxFrmDzGbNkySUTy9KBzdD/rHF28V+ecxaKXRfCS
W/GFrIN6gyEwNkJ9w/xHoSm8wg3LPuS/sZBcqvArYjwYM+oX9eJ9PqpcyAVV
OqyMu5uIvSqQKV6RCO5VMigiUxbBOzKxJRcSKo6qGeufQdCJbBOrM3gmZYXc
lgHmY26FAAYUx4P4GLolFB4/iMgUtDy0KdMhSyok7lAZMNvRE+BdeUYZhAN2
V15rTAMLqsahIPGQ6DeyIYUxRh0q4rcB1oEBkySc2YwXamxW/SKc6YEZfp9y
Mw2OLr3eMbc+Mxy/S12PMUdPD+HpdoiJyVsbSXpI1GkmG2aSBYg7GmoPGjyC
fdwBaftJge/eyFH0DZwKNEFLc7rYfjB2Q5wVLvf/o61HdwYQgcZHtje3Nrd+
+w1t06dBXdsl/foVeuFBFn4kuiqaV6qI9uuZKEeMrzeYqMJeXxY9MQP2g0XR
A0cSABpbbLMmpURWUG15YsOg8oMhXuFM3JLnDCuJTi+ODd0r3EChygjZPGnT
8vlcWTDpEuhFMMtrhzPQdtDVu+bituCaw34SlwUrAQFBT2UyUi1JX8RgoKVB
0kuW9FCreXI287eT4UuwUHfF5IwD4tZn3i3h0nLCdnVRAFcepVZ+eal+VSMd
0E9c6o3iO/iG8nJk+0TqQdZDckxRxJxRxU7r3PaUsm2hjD0mZip3TXSFSMER
9L2gkRWyt9CCCbB2Tn+xu8itZzxzXEcmiplvKCNI5At1qkHSaSCfrGYaGdoh
kz/+TutydWsp9ORF97kacWYTYkmN2Z2el962mVfVsj3heBL4hmDPb2krVUKc
FiJgqI5qrCsIrppS7VCnDcgcbtDSgvjj7AUP05Jagu4/ts5svsCphiUz6ymm
8J0D6544iOGPEfoBwgEVGDJa3RBKZwEYV3w39BheJTwPVWHucRe52ddlbPbr
wfouXh3s4sJqWgeVu0fWkIAlOmukGsVb5bHkaaGLGmaY1MHJKaavTlJXJcbU
xn7i2mYicxaaEJotoeZioohSvAOpzzkH9+BjZufcrTjnfZMtdxc9gMY/5Srm
IhrrYRvFs+10tp/WJ96+HX5VjUbjcsJTnW59mClKlSzMIjg5ulGQ9CRAatIp
wgDRrR0uLeGQngZTKkSOU1S8yQbhJQUJwqqGUhF8D4iDgBiQAakDZsf4qLgq
gSNYEsrjt9tS24jgbjidaAmGiG88dkucRkHul8GdJZeTN1vApfskMuNeEjrE
IbkF63+UeuP/+xl7fQVCUkJdnFo8NKOBeEtcMA3FeD3EO/mU/Z/21HE4kPYC
OQKoZy73SXamim8jGK/h2Jo6kziRQA6HR1dbLuzgEjxMt2UXWuZGsSxvb6FF
5YAxVD7m6Ya4AtH0jo1gAkXGZTK+FMOOTD9CGS1U7xLUXY5khcK0AZqonIKq
FCQ6EAus9d2DjUKKj/T6YNkMIALkERL6ENYwUd/QSmq9yjWZM4dfOcN674ln
QUIjA29dI2ZTGSOyeYB4MIQjNFgczcxJ0MIEptkU0MrqfjJedn+rkAQnt1w5
8vdfeMBa6vyyrRoUCrd3K/DIC0PzgpSiSKMtx9VRTVxACf4vWOnHquE5yY47
EqKf3hWz0lY5b/ytlHyeqaw0HyVMMpzp3HSSiR2WCUtbcqGIFK/WI2yErqL9
dyifFQgKjAOCCryC06qnTYD/iCCR5ozqw+NSYe/VP64jZ2nJKpfbL36hvKw4
BMXET4IBz2Yr+MUb+yBsza6oQzkgAB91MCQrpZQNVJh2RZnNdRYMipk6ixvG
8edZHPpLao76PBR4K3Eph/l1a5CZyyWjMI5GdDTQpuQ/on3zOh3XAMjMkS33
yFsKMYThCKrDswuTKsEq0aaV+858Fi358yk3sGjXpTuObs7vCGWG1+QQ1+4l
W/5iz6HSWM68kXkUHhL3gGb3fVm23iqQd4eApx6+qtqpI1rCNNjPI8Cy10cl
VbsMVjvglr1qTDeat2xKeHtgPmomQGsO4nKengrAXHEL0JKzUEAu4e1F1fnh
oWRrj6txM+MqVwRwnDQF+IX8/p7gtUfztWu4JmeWIvZLpkJz7um5Zqdy9T32
fHHYlYUpOp2Q5k5C+yb/0VHh+ksAxYL3h2I60SQOTCyAoqO2a84wSgpLW6D3
k2Ar1/PDJDAwQYSOsEteJxGXkCzpEhI7OkQ2h1Ow9yTDGypDZV6CuXBABGdI
UoGAbmb/s9VP4vc7PWOSaSZ9PUlJ79BdxizBSB+LeidVimTuOU0XIC1UPxO6
iQxw1AloQ5o2lLs6x1hWTShoKVUaVwm6Yd8VMg6gY+JlYGa7yF0IlyiwDW+w
V5OK0glcn9gTOYFs0jiBnYZLTCHnHW5cURO6dJZun6lnl1BvwJDGJWPS0d0K
hKiX1BvsrkPYK/EyCi1k2nktRKicmP1cbSZUVxvOzAwTqiT7jjHoR+gmpjxF
HQzA0jXE8Pg5v51tpr/EBgN2yM5/71gGDrkZMVFn0hSLlgPZDQVHr35s0W0F
WEpEhqSy499ky4rN5KhbDEdi1Zc2Eq04CwjwdzQtIB9LFrAoeQAAT9AdRqRD
J4CnEqYmoRtsGURpQ/w5g8zc210m3IgD154BIKd02NNzE8SMDrJw9ZYBsoN/
MCRREEbwa+GNg4r4sghKDLuUxPc+79LiiWADnHvilV2M7cZqYwCT4AdAeJUB
UqBBORfUZPGq60PB1SZRazTYEz9g6mVJTHDDq6XNgf4gpaT4ADvA940oZ+IZ
aSvD14gBpU1hwBDlrLJ5UUyY93Br4CQksYURiU2kOI9F4TwOtCMZMootMzcS
tAU4mJ/tUiAt4b/FyG/PhPVK39Vllgscr0I/BRfl7DipmcG3bNSfTeHwoUdA
All235defxrq4g9CGQFhKREKf+0r4LhR/4z7CTnsiNcYqL4ApA9tc0SZNDoO
E5JTriM94qyHtuctpBIIyXmJxfVKCRH011zO+drFDDZhfEQGedHk6nmXGTnz
avp9ZMVlYUWhJNA3yHlD++8kGFuzmSpxuDUkDUHSLUdlPe6l98CQBapbQbge
wRuy3fHEn7A2HmfzYWYnKJ6bwYJ5rBxFT4JLl2JAAwZYDsk/KL+EJSr6fkQ0
0np2oinGpvb9eUL+wwP0Wxp84+PiB8CRcuZh3AL0F/+6n8Fg4mB+QMkO5TAk
Ha0va653FCFi0UF6iqLQ/3Js5J15nQhyRyxsiJsHWdzbCuXi5z5O2Sj9by7C
IIR9xPUo+5sxuz5atFe08ZNJl1V5Erumwu7Cv34t5bJL+6L9q+RXPrZdAcIL
DGdvEVeM78XTNEqIHdp8HJ7d1mcBl4pAM/QCpl99kruvdZdJUnwgLzqqHuu7
z5h2Mh1OGM9XQmLW+asXsbgLzBfDXykHG8bRciQfYn9PXhYP74uT4T4A5Brw
/7YAKEWldQLU/16RmdXMu+y1zr+JouNeYDf9idr3Iqyec5y0OPDW0zFeHUgX
49d60ng78bJYf7F/8HqDLojVPoQ6Mbw1PHg5fHjnznDnwU+bznR4sCxQhl8A
PLgpzhT4RJSSAgI63oR7+lWxnkQbIAP6fERBvqf+Kf/30xosvgMAnWBO967A
Ljf8BXx4OmvOp9h96P1hrZHe0xqcuCOvqI2I+Qa32UzRBuDohscBl259FEgd
JKRGZbF9597DoX9Og1DI7ULjcAbvubW1jY/Bn7zODVL8jT0Qpu5GB/iA+4bm
pPBz8hymwAth8wNTIYOlM78Ofd/onnucifwfzZ+wjWH6U/T/ln/s70X2PLjT
7QX9PLr3oO9PW9uP5P2Hfe9vbW8/7H3/3kN5/1Hv+zs7d3vfv/+A39+60/v+
o+37ve8/vC/v7/S9f2/nwU7f+9sP7/H7273ff/hg61Hf+3cf3pX3+76/dW/n
UW//7z3cNlIKcFJqmmFRAyV074e/XFABwyNKJDAJqqh/S+pXvtVJP6bGXQXe
0YV1OAvrMNkPaC750ZI7BkxkFk9C2N/1qpB3I6Loc8b9swlKI5JmgrED4F5W
1710OkU/KWWstlwo6m1dXYAQhhQ2KiAaqr+8jsw+Mu1IgAU4LAQfGTnMDGhS
7cTWgUg5C3dH1bsSq38/GRGeT6Hi1vWG2dvVnOZ4DpcIknCceFX10HfMITU5
Th1Yvn4CW6xbwHMYqchK4oCKcs0s8FG9GxyQeoahx4CxJp/BBeT44EyWkzds
FSJiVuYPrXREnQOzjdjge8+/K/78XwNn0mRGtVfCvvG9HhT/3VTFQelFenU5
KL6q6jdv6uJ731u/HavJwH3pLfUGsobA+iy+r49LsmWK5356S3+BvIL/93cs
ju459McPbyJYZ9SpwVy3Dm6sb3VUnoN/hrqM88F5+nFsop45mWk/Cf/dnE9q
/5URkL4KXhcgokDKUFEhnnnwp6Eh5ndlAdsSJ79pK8czFBcJsSvObjh0SNkp
BNZHMLP9OZRqwph3Tzi2eHsVBfUV3WDoKjNfcBanQGgo8Bf9jTwiYfYG2V2s
B9OpixBP9BPe+ejUllHDNi8nxdPq6+YNleo4ZhJ4bx6Czcw+OHu6KWbBMM7n
5ewNEAgMAsoiIuuDrhDVMKbU40Ecl4SVk7M4bto5Qg9xYbEdCfBDzq84wckv
KR904PDyd/1fnn9DbsbmfHYkDlOkHTqK6HvUorzAgnVcbp1RklTXxVIOEXOR
0hEZ0kI8YYmoQKex/QBNI+QPv/NfqidFQuRhXSeWRZNpjNSZbZKeMDJQzsgt
qHKGehzwROq+NIVO4v7SzpQPYdIlAhc7Nd3wtLZjDEzzSqGTE/2VuGc5vU2O
le4SRCXgoQWpAsvQzin7kX1Xjfolx6DJvSHLFdwLZ/XpGememI8IrPyNtz8g
TQwgUaEDWt5lEx7DBQCvRrFmcSlrwcHKbi14OvYqtyzCLTXuPmb1Eh/poKjm
R5vmy0YegXTya8LFzbjluvT3GqU27U7BdqrfFU/M+1KBDXliJeJKic4Q2vO/
PPLWegVHc0Q5w3xZAC8jCsdZNW7eEh//HMv9UZixmtjAg/qUIMaA3MkN5GxM
EAkahVE4AFNj9SQ4sGEHY86izVQivYHmGIZPN2OtCQ6+iRCZCO0g5zuLJ90m
o/rEC/rLo1EVw+TDZRfiVqGeEIo8cm6zxKg5M4WBRI693KjGyALsFnuBBUq0
KeJVHZIVg9n35Dh5FTxKrfv1MalS1fHnaydeXldrvyU+KuaXgusMGFSp0UNt
lL0xM9toN9/8/v0HD73A1K5Zn/4WRxg3gYjcdK64BwDxxyjNnzDo5Kjq6fEe
Vm4aVxUSwQRjDBuC5LeK7hfBrujtCG40F0X44bf37mw9kJy1rQfy253tew+0
zgr+FjYJPv/o/ja1Av8CJdASoCSfhW2y1pMz6MpTXOa1dAAjzHw8JQ8oFX1B
HRfkl23KaVPW9yZTvN2Z4m2YYmhxhW2xbJLHJZ4j7mJY323NkIa0gOCBR6gM
ZTZIB+/mOkj7IPIrWm6n63WWLtwkPVM9cjH6MjOT93o6uv2YD17xFES6gY+r
g+Lm0xtDNMuI7i0zqTs9fb2rfc3wwIGfa89iw2+310XgkJI4RfKAhp+WZNmS
YXHpuNxqvjEDt9PcC0loTANRoG+BonCUYF6TJqNpd5lpv5+d9rBB2OdqaPZu
cSe35ydEyzB3s9S3Kx18kO3g3cdMq4p8mJDge71uaRIMtFZpawGyDiBnE54A
l+Xc63avOHNXX+Er5A76RmFrsvv2NSZEuOS5nTsPUDRTCBRRDZIFkaHkYh0X
p+NhdjruPcbgmc1F9rrU0eU1Z6WTbhHHylLWpaB7qDUt/oQkTT3imkFgG2Lz
zPwyyhbhvBZs6s8Cl3fRBCTdw4+yc7LzWHllXwXSh5vKB7kkqOyG5L24QCtR
dCUd/rEaUux4iCrmBhOkZ1sIuSmhanMcEYYkNc5K8yrJncz4/QmOQgTXHLi5
0U9sc1pf0ybvIzy1M/roPV2zra4itQ2n2txFforxeoJDPsOszYal0jUHE/wr
qu/L/U/NOa3PpMkAoSxfP/SlK2QzdQp14F315i5oDpbaN2KHv65oYxDRRGQU
tIx02zCnXtZiykMnMNhZPqB3hgEMyW0QxtHVgu7CrmPJ+JnG8eH0Ubz/26nU
VrqhsA6V2qD8FQlRSQDQcm/C4ongllmRJIej52ZUaZ0Q2RW+1yfD43NABrpG
+ivZmVweVqegq1/dhT28zymmvsknUCL3SPNrQ02Ca04BmGAIDSOJBLBIiNxg
0VZ/YUG55HkTwNgXZ0xOQHxY+k4okFsQHVBmD/cufFdTuwsX0PfezGtmQ2Xh
PmAJccOBps0iVVdDxGP++MIfW4MeRI9kQcWKtf5Dd3D04lCuq/iEdnWiu3Cb
cKbyfiAeuuHQTOoz+qmM74vAypGjNYufb5uQk5DSpjAxaXs5OTrzyimxT6J/
I39FjebxNHQ1r7ub9x9zVRcO6NZ/U+H4tG5RhTvAIk3X3eC8LWGCvnv9bPiQ
vZUskF0eyvy/XTGMozqcIh/U0H8DhyawrZ5m2unSdtppPEdddcyfBFgnjrHr
PXELlqvum7RtPhJ2AxFkn5/TtDSQ/N3RJY/FA+zqVjts6WYygRQYc80RCujQ
QszShCC+s2zSR5QDTC6Erkq0Q2ZNYkRCBSg6LTdVDFP7jBI3OAvjkHCCWb06
Hgfv0InMBfPq9TH9LTWrt7t61g7ZT0yMbY2bV9Xbhht+clYdvYHv3/gYw6i6
FpRbbEGxNbTIEtruKlI7sMI5+XTrwugWBNFVhJBgP9Gy2dEZ6KpgO7Cyz6t5
iZkVNx51zKxC/UqdYxK0HgKhCo0up4IkYFC0G1tHIfBz4NHCf7HnXUfY1bB2
0NiV40AhtZsPVCscL1xXfzYXLppyAAner3RGGU0Zy5mKgqJAa2eNn4U3VQU0
P2trWlW7dSnrB4eCdIq66th9kM8Zfvkbz5JGzjIU7xbiuFA0d7Wr+3Bs/Uri
rnrOrCi33lmYN9TzHfc018s2c3iJsdRrw0GodlWj+3DwYkCfXM8R2vhGBqwZ
XRbrL5UcOkNHjgvtR8zZJ3FLQ+eS0RH6Ddrtrg50XxxSw31O2aU4THz53nwS
oNt8jwx3SULmZRTbgcMSH1IhRUZEqVTTmmAsdAmEDQoTqWPuqkX3wUTgQ3d7
AhhG+CGFcAjffYnokV8A5meQAbh7JFS+IFAX8rJaTvBqGfspd7zZrYqukQi6
I7sbPxJCNhz7erizBTAHpO2SopmcZ+J3N2T4UVBy4ALSiuFIVnwhnf8i572f
Fj96hS+Vs4p4cV6zti1kuUCKHgrn4dPH8TxJxtC/E7JItfZz3QkcWKCZgsZx
6alOD5JLEdkNTm2SKcfJ7WzdSxhOAoL3MexHv91ifrnZqJaE5hffvlaHNIqL
1+TuuLspZJ82TD/xh2cM0AGBzEK7SWaSENnMWgo97jy4s8Mecgyov3qG/4Z0
E73zbNETYidlEIZDggrOZzu5TBAT2NBhzHbcF3bkCKYf2j2GDyLi3ncBYpUN
ESdqLVEUjcRslHXk+2b8LcwODy7AQV5RrBsEiwbCecog6G9NTfgJp8rNIHvj
olGiBVUlqLgpO83Fra71U4f7T9Wp56iOEqFWnPP3LCorvbZDIzxJ3zPUWHct
IQbAmZZ8N2BVkhvGf8/fibuhnjHapOC9NLALkVnG+2TMVCeXGBJ3sATluJkW
/snIQq9JZwxiP28rODINPMR/aY+SmXt0Dy/4n2D4nxO3ATW50oUW4ciDitie
4d3ThtZyDh7keT9ctI6SZGt5a7Bac+nHVs7i0mwMobX99p3C2FHy+0bzPDqo
6hzauj+bg37+Y4h7U7zDyx5XTk/+b3qXPLj6ska71p9f7j/d2iiGX9xyNzBR
z++0zyk9/PvPt5a9geV/wcadzQfFATpnW/A22xO74RYOq/+j60hzhQRBP59V
fk1xyB/BmDGOBe4E6tZgpTfoIPxMAeufwRW79D2UxAAbA/rUK0+j2R9LO5D/
kLyVVEzSVpXiA6MRNukrvLixbMH8ei2wQgc2PZbfWGSUDkL8Be8ycBfLe6Dy
ob5iSRmiPaV3lilVH0TYOqgnU2CAhyxheScxVAm9t1Fsbm4uHrkf977NaDfu
8XWWuRvLd0gmPrfOW3+Ft3Pf1F6v3rtuJ9ZlFcJDuRbs3NvN5sXxBMuE9Ww1
yxO+dIOJRBCOGrrawJ32jED0t3CtccpD7ko7Rg4Od4GAGbQ6DMtpKKP4D3Sb
6W115evqYxDeny6sTxfWP82FtaCPveKb2ZdWuB5ioS3vLb8gOl/I/fG9yn5h
nCLZD4GEZ2D6wne/8pPbngH703dot9rsfAJqW5Rr/nbYZ/xMyavIhW20piDX
rvOm5uEheHm0HOWZfhyrHdeAosdC7pw04XcSsKsevVEap5Q7gGx4wO1pWwMG
86x+p/RcKbkbpedCucJ90neb0F9zsiJ7ldCfPvss/FW2B44etgj68Jh43a8J
5ol4ATilSh2hlxk/oUBp/Bt7yjc/MJxTGO/UFnARzm1VqiXa31XF/pWl/moX
Xf+c936wc8mR0U5/jGCgwXu0ES8YpyJSRJbo+7kEdKdslRFSfgR0HrTgMh0J
OQDhMH34ub/qhYtzGo72sud/NB94U13+LPro4KdVXjQf+pn3+dIXi3RIPx83
k3AXXG0Hpb0IXzd7KxqX6+k+0QUn7/erDZHWsNx/8j62yTW0LDuKpQ9Dr16W
l6OmhBvn+x+v45b6acOc3iU61lW1LN/iMyT9w/sydBSJkJpyVLWaNilNPOOx
Q2BIv7pLJEkovBFHW4Z6p4FLKQrQZidIdlq0o+MLaHvjp0iepYUIFR68VA7J
Dut+v/cnWkDdcn/56SrDMa/FVykH9P5iDFxSFWhIgbH3deDQXTjGW3Fy3MjH
scjFsXLX8j1IPBxLHBzJ0UnV3JtouVkHB2BJnhC7+m7qkUC0kSqncLZWS6WI
9Fyux9zVSGPFFsllBSLiIrWY0lm7FXi6mU9aCm1K3QPpAJVngKJmPWang6/P
KhvrhPKAmGvIlONOCHkDjtQWZF6A6iCK/VWCD1TfkcKRy9Tsq+jZnxTtf11F
e+OjUFj+NfRa+uO11yunvH5STrO9es/KqVUzr6qo4lVBFPMdIxjqf7Io69xA
LkxN9M5yR55f5N/7zF3/0N32qesx8j6Idbj62lzHTX61U3LTKN9CHfjaqm2s
HLxX1RYwwFG6J5E+VGXbVuPD0crKK97ccaKn4QzsulHd9dyov5d+d8Ur4Mr6
38dwCV0hWndz5epDD/ZfTLvq+1mXs11sPS6+GRTPiSzUr/wV13o1IX4VpeM6
y6qj2X5MQ6GRXHUgtzmOGwzi7vV044/iUteNt2CH3XrAvndOrjaBYRctNQP/
CSyDH1PLYIVBpH6Onz65rT+5rT+5rf/B3Nb3kXjfz9KEigPtKUteD1AdKyBL
ToNJpWCmzTZpayx7xewQpkMufuhDTlCBtH9+jX8VUPknlf82B/svpvL/IyqN
S4/EP4G+1c00WvbGbSho/4T6mUvk6s8yn9dQ235a3X5dVRP7/dSwQuf920wS
xV9ER1MNbWl+xAce2kpTbzWxrCL1+yqJH/zQPpEqjM93nxRSXqY6ZjI2TLwP
JeawKoNtO+hikh+bsXP8V15IiadIMWtBRYDwPx7iXFeNn6k8oTRZTT6kcqiS
Cq0k5tKjtPRUTuWGTneXj2pqCD2bNjDHamJYrlaKDntLpB5DoZcZTGExn9XT
djOn4y/cWSvp+Mm6LzMTVz7WZhF/uPrRjuTykr2oJ/MHe6CLngPNTy6Xn58M
vS9ucpxhDcIAhb6TzvMPuVNd6DeouagyW2h74QfT75hTvlCMZM3Y2zdgH4TE
snhZbpJYFhOSQKnY+vi66dCfbNZ/ZJv1Ixis7xKzqSEhOW/ZVcwRfu0rRD88
vbJdGMaOnWB0Y64TVwoKfATz2e3rVay7ZQG1q+p9SxS/YjWDrbhGwt1tmW3F
7XnWzXYMkkdz9lbRMNLBDOz8rgDfAMySrTT//bZJMtzoUYcG0ZmSr+SaUkXh
gw2GL1Aht7r5kEKDKw7tw+uBxZJs/Kvk4/fkbepf92YzRCd/b1O3cCrxD0+a
46r4HModpgjghXmaNwgGZLM0H/ZGAkgA5KiS9R64vVBBHEsqXe6z6n/8FD/4
8OrJe40ffOCx/l7hg6vHDa4XMPgXzCr8J4gWfPL93x42Y7mT6mNz8X9c/ftH
8NNnVIaB2ayLNAp1c6ce7PDNlVzZOe0xdpwtdGX3KVyhiXpyJf/2+wke3K4X
PbdO8fbrcZMvWuDVvOW5qV/cq2UtLjI2rgkJun1fKvAOo07MR631KwpMnGwG
0Jlgp9IB5uWErq+aBKA5oMDVG9TuUKPMZquaIgeUB4TcLFFtk8Nzk1d6UUJh
Z5MbxFTLzlYK+8TX8jGkkRotMcpGloqh0NtPuabvcaj/MtCo6yzYR2HsfATG
/nuARt0+xebVbB949VoZq6vycqYVBeQv61S75nN2y3kxg498LkU2qqFfpqUg
yqtjxWMTQQ2lT9bVP6119btmuN6uEbA8Ffb94uWxHCozwhc3QRrcmJmd6Fy4
J4JU4LKcritl/iGpb5c9fm0i91vux5Vv0k/EuJ+Icf+ZiHHfM5P77euIg99b
i3s5azBGbmHD/t+fZ6qLrJIUi7OQqdSZ6es15+EjI5CHkt4vv35ysCTmvPDW
VT8ROJOo2ik0+YetO3QCoNqL0qROR5daX42ee0D36OuzUECnOKywyFcLNdi5
rhJ4PkC4571cfirYw+U3fI11s97Wpb8Ahsf1jAoxliNnPSIh2t34njf+GFL5
MFgA9spKFT+sW9qcQKW2N5PmYlQd+y6CDBu+/PbrjSupAP/P/7gB3Nmby/ZR
9DPgm37T/R30hb9f6eW/g0g6mL39u/uf4Z+Gwz9e6eX/8V/1Lw3/6PdX+llz
sRXGJZZ8HV/0u+/K/8t8cbXxJi/aC8r2c/35D6i5pC9evatf3FZX4zhjcoku
fhHu2Ej/WfWLVlG6UldjtWrJix9yAyQ6Sv+09s1qR/Hr+eJHs3NS/Wu1MUZa
5Apf7HgrV+1q+qJ6H1d6McAU+n4+8JZbcbdlxqi7rascL35R5mb5asQvxvPZ
o2HHL37QTV5giCxXQTTz4oeVOaa7oOeQOtT74nuf1YP6lKyjJwev0ARppaeo
keVi7fQi/JHPa1BwV5qcrBHA9sXCF4PWHJTmVb74YTZAH8Z1xiIhmTWzcxZa
SQu+eMUJ+jgOMv2gwsJI594Xr7WOqGuLnbO9WbDtWBwcVZNyVjdXN3VazmWC
VlpuZbOj/fcT7F1X+8efG5kANJc3sQPwZ5ExUKxoD9xkTW9yPs2nu31ewTgo
bnBu8H/XPjy5ni8wE8DXtuTtlfyk6dsfdsEW6VS9OvqHX7BFSnluoeK3u1p5
r3YYKXIfw4Lpz5KVW/L2qupw/u3VzIVFb/erw9m3PwbZEH6Wqcnm7Y9ks+jP
l+Vitbn4iKa8X+EjLVlLyWXfNrqblpVb4dsffsGW6rnpuG9j2B/Bcic/cJWK
brno7WsvGCmypMfe3ZSM4Qjep+7v6ym1oswaNGkXROjqEHdQZzsYjpPGBqjS
ivUz8J6/raEkGkT1fSPTagb13K3bfrurRt+aE/06ivN1VOU+5XiZVnzV3XHF
jWy27kq67lWP2VUPVnyUlru7k6O31MudPL/UuZ08v9Sn/f6WayVHYo//sNdb
/V6XdwWXdL7//Z7o+PnlLs+Fz2f8zpnnFyqf3ecX65vvafus6oLW7uvOWexA
7jiPl6jm8vyqfub3uj1X8Ef2qSx9Xrb3s7wr+wmv6j99v8Kffxa4AK88naQr
AUoOklrc/wcnMLfG5T8DAA==
</rfc> </rfc>
 End of changes. 514 change blocks. 
4818 lines changed or deleted 2596 lines changed or added

This html diff was produced by rfcdiff 1.48.