<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 2.6.10) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-emu-rfc7170bis-22" number="9930" category="std" consensus="true" submissionType="IETF" obsoletes="7170" updates="9427" tocInclude="true" sortRefs="true" symRefs="true" version="3"> version="3" xml:lang="en">

<!-- xml2rfc v2v3 conversion 3.24.0 [rfced] FYI: We have updated the short title of this document,
which appears in the running header in the PDF output, as follows.
Please let us know any objections.

Original:
 TEAP

Current:
 TEAP Version 1
-->
  <front>
    <title abbrev="TEAP">Tunnel abbrev="TEAP Version 1">Tunnel Extensible Authentication Protocol (TEAP) Version 1</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-emu-rfc7170bis-22"/> name="RFC" value="9930"/>
    <author initials="A." surname="DeKok (Ed)" surname="DeKok" fullname="Alan DeKok"> DeKok" role="editor">
      <organization/>
      <address>
        <email>aland@freeradius.org</email>
      </address>
    </author>
    <date year="2025" month="May" day="28"/>
    <area>Internet</area>
    <workgroup>EMU working group</workgroup>
    <keyword>Internet-Draft</keyword> year="2026" month="February"/>
    <area>SEC</area>
    <workgroup>emu</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
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>
      <?line 120?>
<t>This document defines the Tunnel Extensible Authentication Protocol
(TEAP) version 1.  TEAP is a tunnel-based EAP method that enables
secure communication between a peer and a server by using the
Transport Layer Security (TLS) 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.  This document obsoletes RFC 7170 and updates RFC 9427 by
moving all TEAP specifications from those documents to this one.</t>
    </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/browse/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>
  <middle>
    <?line 131?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>A tunnel-based Extensible Authentication Protocol (EAP) method is an
EAP method that establishes a secure tunnel and executes other EAP
methods under the protection of that secure tunnel.  A tunnel-based
EAP method can be used in any lower-layer protocol that supports EAP
authentication.  There are several existing tunnel-based EAP methods
that use Transport Layer Security (TLS) <xref target="RFC8446"/> to establish the
secure tunnel.  EAP methods supporting this include Protected EAP
(PEAP) <xref target="PEAP"/>, EAP Tunneled Transport Layer Security (EAP-TTLS) <xref target="RFC5281"/>, and EAP Flexible Authentication via Secure Tunneling
(EAP-FAST) <xref target="RFC4851"/>.  However, they all are either vendor-specific or
informational, and the industry calls for a Standards Track
tunnel-based EAP method.  <xref target="RFC6678"/> outlines the list of requirements for a
standard tunnel-based EAP method.</t>
      <t>This document describes the Tunnel Extensible Authentication Protocol
(TEAP) version 1, which is based on EAP-FAST <xref target="RFC4851"/>.  The changes from EAP-FAST to TEAP are largely minor, minor in order
to meet the requirements outlined in <xref target="RFC6678"/> for a standard
tunnel-based EAP method.</t>
      <t>This specification describes TEAPv1, and document also defines cryptographic derivations for use with TLS 1.2.  When TLS 1.3 is used, the
definitions of cryptographic derivations in <xref target="RFC9427"/> MUST <bcp14>MUST</bcp14> be used
instead of the ones given here.</t>
      <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
such, the definitions given here are only applicable for TLS 1.2, 1.2 and
for TLS 1.3.</t>
      <section anchor="interoperability">
        <name>Interoperability Issues</name>
        <t>This document contains substantial changes from <xref target="RFC7170"/>.  These
changes are largely clarifications and corrections to that
specification.</t>
<!-- [rfced] Should "functionality" be plural in this sentence?

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"/>, target="RFC7170"/> in the
specification of the cryptographic binding cryptographic-binding information.  While there
were multiple implementations of <xref target="RFC7170"/>, the text in that
document was interpreted differently by each implementation.  The
implementations are interoperable, interoperable but only for a subset of the
functionality described in <xref target="RFC7170"/>.</t>
        <t>This specification describes how TEAPv1 works in theory, theory but also
explains what subset of TEAPv1 is currently interoperable.  In order
to simplify the description of an already complex specification, all
interoperabiliy
interoperability issues are documented separately from the normal
protocol operation.</t>
        <t>Please see <xref target="limitations"/>, below, target="limitations"/> for further discussion of
interoperability issues.</t>
      </section>
      <section anchor="specification-requirements">
        <name>Specification Requirements</name>
        <t>The
        <name>Requirements Language</name>
	<t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 [RFC2119] [RFC8174] BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t> here.
</t>
      </section>
      <section anchor="terminology">
        <name>Terminology</name>
        <t>Much of the terminology in this document comes from <xref target="RFC3748"/>.
Additional terms are defined below:</t>
        <t>Type-Length-Value (TLV)</t>
        <ul empty="true">
          <li>
            <t>The
<dl spacing="normal" newline="true">
  <dt>Type-Length-Value (TLV)</dt>
  <dd>The TEAP protocol utilizes objects in TLV format.  The TLV format is
  defined in <xref target="teap-tlv-format"/>.</t>
          </li>
        </ul>
        <t>Inner Method</t>
        <ul empty="true">
          <li>
            <t>An target="teap-tlv-format"/>.</dd>
  <dt>Inner Method</dt>
  <dd>An authentication method which that is sent as application data inside of a
  TLS exchange which that is carried over TEAP.  The inner method can be an EAP
  authentication method, a username / password 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> exchange.</dd>
</dl>
      </section>
    </section>
    <section anchor="protocol-overview">
      <name>Protocol Overview</name>
      <t>TEAP authentication occurs in two phases after the initial EAP
Identity request/response exchange.  In the first phase, TEAP employs
the TLS <xref target="RFC8446"/> handshake to provide an authenticated key exchange
and to establish a protected tunnel.  Once the tunnel is established,
the second phase begins with the peer and server engaging in further
conversations to establish the required authentication and
authorization policies.  TEAP makes use of TLV objects to carry out
the inner authentication, results, and other information, such as
channel-binding information.</t>
      <t>As discussed in <xref section="2.1.7" sectionFormat="comma" sectionFormat="of" target="RFC9190"/> and <xref section="3.1" sectionFormat="comma" sectionFormat="of" target="RFC9427"/>,
the outer EAP Identity SHOULD <bcp14>SHOULD</bcp14> be an anonymous Network Access
Identifier (NAI) as described in <xref section="2.4" sectionFormat="comma" sectionFormat="of" target="RFC7542"/>.  While <xref section="5.1" sectionFormat="comma" sectionFormat="of" target="RFC3748"/> places no
limits on the contents of the Identity field, <xref section="2.6" sectionFormat="comma" sectionFormat="of" target="RFC7542"/>
states that Identities which that do not follow the NAI format cannot be
transported in an Authentication, Authorization, and Accounting (AAA)
proxy network.  As such, Identities in non-NAI form are likely to not
work outside of limited and local networks.</t>
      <t>Any inner identities (EAP or otherwise) SHOULD <bcp14>SHOULD</bcp14> also
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
EAP-FAST <xref target="RFC4851"/>.  However, implementation experience and analysis
determined that the PAC was not necessary.  Instead, TEAP performs
session resumption using the NewSessionTicket message as defined in
Sections <xref section="2.1.2" sectionFormat="comma" sectionFormat="bare" target="RFC9190"/> and <xref section="2.1.3" sectionFormat="comma" sectionFormat="bare" target="RFC9190"/> of <xref target="RFC9190"/>.  As such, the PAC has
been deprecated.</t>
      <t>The TEAP conversation is used to establish or resume an existing
session to typically establish network connectivity between a peer
and the network.  Upon successful execution of TEAP, the EAP peer and
EAP server both derive strong session key material (Master Session Key <xref target="RFC3748"/>) that can then be
communicated to the network access server (NAS) for use in
establishing a link-layer security association.</t>
      <section anchor="architectural-model">
        <name>Architectural Model</name>
        <t>The network architectural model for TEAP usage is shown below:</t>
        <figure>
          <name>TEAP Architectural Model</name>
          <artwork><![CDATA[
 +----------+      +----------+      +----------+      +----------+
 |          |      |          |      |          |      |  Inner   |
 |   Peer   |<---->|  Authen- |<---->|   TEAP   |<---->|  Method  |
 |          |      |  ticator |      |  server  |      |  server  |
 |          |      |          |      |          |      |          |
 +----------+      +----------+      +----------+      +----------+
]]></artwork>      +----------+]]></artwork>
        </figure>
        <t>The Peer and Authenticator are defined in <xref section="1.2" sectionFormat="comma" target="RFC3748"/>, target="RFC3748"/>.
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
TEAP server, server and handles the application data (inner methods, EAP, passwords, etc.)
inside of the TLS tunnel.</t>
        <t>The entities depicted above are logical entities and may or may not
correspond to separate network components.  For example, the TEAP
server and Inner Method server might be a single entity; the
authenticator and TEAP server might be a single entity; or the
functions of the authenticator, TEAP server, and Inner Method server
might be combined into a single physical device.  For example,
typical IEEE 802.11 deployments place the authenticator in an access
point (AP) while a RADIUS server may provide the TEAP and inner
method server components.  The above diagram illustrates the division
of labor among entities in a general manner and shows how a
distributed system might be constructed; however, actual systems
might be realized more simply.  The security considerations in
<xref target="separation-p1-p2"/> provide an additional discussion of the implications of
separating the TEAP server from the Inner Method server.</t>
      </section>
      <section anchor="protocol-layering-model">
        <name>Protocol-Layering Model</name> <t>TEAP packets are encapsulated
        within EAP; EAP in turn requires a transport protocol.  TEAP packets
        encapsulate TLS, which is then used to encapsulate user authentication
        information.  Thus, TEAP messaging can be described using a layered
        model, where each layer encapsulates the layer above it.  The
        following diagram clarifies the relationship between protocols:</t>
        <figure>
          <name>Protocol-Layering Model</name>
          <artwork><![CDATA[
 +------------------------------------------+
 | Inner EAP Method | Other TLV information |
 |------------------------------------------|
 |         TLV Encapsulation (TLVs)         |
 |------------------------------------------+---------------------+
 |                      TLS                 | Optional Outer TLVs |
 |----------------------------------------------------------------|
 |                            TEAP                                |
 |----------------------------------------------------------------|
 |                            EAP                                 |
 |----------------------------------------------------------------|
 |     Carrier Protocol (EAP over LAN, RADIUS, Diameter, etc.)    |
 +----------------------------------------------------------------+
]]></artwork>
 +----------------------------------------------------------------+]]></artwork>
        </figure>
        <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 parameters
between an EAP peer and an EAP server.  All data exchanges in the TEAP
protected TEAP-protected tunnel are encapsulated in a TLV layer.</t>
        <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
transport EAP between the peer and the authenticator; RADIUS
<xref target="RFC3579"/> or Diameter <xref target="RFC4072"/> may be used to transport EAP between
the authenticator and the EAP server.</t>
      </section>
      <section anchor="outer-tlvs-versus-inner-tlvs">
        <name>Outer TLVs versus Versus Inner TLVs</name>
        <t>TEAP packets may include TLVs both inside and outside the TLS tunnel
defined as follows:</t>
        <t>Outer TLVs</t>
        <ul empty="true">
          <li>
            <t>This
<dl spacing="normal" newline="true">
  <dt>Outer TLVs</dt>
  <dd>This term is used to refer to optional TLVs outside the TLS tunnel,
  which 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.  If the message is fragmented, the whole set of fragments is
  counted as one message.</t>
          </li>
        </ul>
        <t>Inner TLVs</t>
        <ul empty="true">
          <li>
            <t>This message.</dd>
  <dt>Inner TLVs</dt>
  <dd>This term is used to refer to TLVs sent within the TLS tunnel.  In 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> used.</dd>
</dl>
      </section>
    </section>
    <section anchor="teap-protocol">
      <name>TEAP Protocol</name>
      <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
<xref target="message-formats"/>, and the cryptographic calculations are given in <xref target="cryptographic-calculations"/>.</t>
      <section anchor="version-negotiation">
        <name>Version Negotiation</name>
        <t>TEAP packets contain a 3-bit Version field, following the TLS Flags
field, which enables future TEAP implementations to be backward
compatible with previous versions of the protocol.  This
specification documents the TEAP version 1 protocol; implementations
of this specification MUST <bcp14>MUST</bcp14> use a Version field set to 1.</t>
        <t>Version negotiation proceeds as follows:</t>
        <ol spacing="normal" type="1"><li> type="1">
	  <li>
            <t>In the first EAP-Request sent with EAP type=TEAP, the EAP server
MUST
<bcp14>MUST</bcp14> set the Version field to the highest version it supports.</t>
          </li>
          <li>
            <t>If the EAP peer supports this version of the protocol, it responds
with an EAP-Response of EAP type=TEAP, including the version number
proposed by the TEAP server.</t>
          </li>
          <li>
            <t>If the TEAP peer does not support the proposed version but supports
a lower version, it responds with an EAP-Response of EAP type=TEAP and
sets the Version field to its highest supported version.</t>
          </li>
          <li>
            <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.
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>
          </li>
          <li>
            <t>If the TEAP server does not support the version number proposed by
the TEAP peer, it MUST <bcp14>MUST</bcp14> either terminate the conversation with an EAP
Failure or negotiate a new EAP type.</t>
          </li>
          <li>
            <t>If the TEAP server does support the version proposed by the TEAP
peer, then the conversation continues using the version proposed by
the TEAP peer.</t>
          </li>
        </ol>
        <t>The version negotiation procedure guarantees that the TEAP peer and
server will agree to the latest version supported by both parties.
If version negotiation fails, then use of TEAP will not be possible,
and another mutually acceptable EAP method will need to be negotiated
if authentication is to proceed.</t>
        <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
peers MUST <bcp14>MUST</bcp14> exchange the TEAP version number received during version
negotiation using the Crypto-Binding TLV described in <xref target="crypto-binding-tlv"/>.
The receiver of the Crypto-Binding TLV MUST <bcp14>MUST</bcp14> verify that the version
received in the Crypto-Binding TLV matches the version sent by the
receiver in the TEAP version negotiation.</t>
        <t>Intermediate results are signaled via the Intermediate-Result TLV (<xref target="intermediate-result-tlv"/>).
However, the Crypto-Binding TLV MUST <bcp14>MUST</bcp14> be validated before any
Intermediate-Result TLV or Result TLV is examined.  If the
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>
        <t>The true success or failure of TEAP is conveyed by the Result TLV, TLV
with value Success or Failure.  However, as EAP terminates with either
a cleartext EAP Success or Failure, a peer will also receive a
cleartext EAP Success or Failure.  The received cleartext EAP Success
or Failure MUST <bcp14>MUST</bcp14> match that received in the Result TLV; the peer SHOULD <bcp14>SHOULD</bcp14>
silently discard those cleartext EAP Success or Failure messages which that
do not coincide with the status sent in the protected Result TLV.</t>
      </section>
      <section anchor="phase1">
        <name>TEAP Authentication Phase 1: Tunnel Establishment</name>
        <t>TEAP relies on the TLS handshake <xref target="RFC8446"/> to establish an
authenticated and protected tunnel.  The TLS version offered by the
peer and server MUST <bcp14>MUST</bcp14> be TLS version 1.2 <xref target="RFC5246"/> or later.  This
version of the TEAP implementation MUST <bcp14>MUST</bcp14> support the following TLS
cipher suites:</t>
        <ul spacing="normal">
          <li>
            <t>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</t>
          </li>
          <li>
            <t>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</t>
          </li>
        </ul>
<!-- [rfced] Section 4.3 of [RFC9325] states the following:

"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 MAY <bcp14>MAY</bcp14> be supported.  Implementations MUST <bcp14>MUST</bcp14> implement
the recommended cipher suites in <xref section="4.2" sectionFormat="comma" target="RFC9325"/> for TLS 1.2, 1.2
and in <xref section="4.3" sectionFormat="comma" target="RFC9325"/> for TLS 1.3.</t>
        <t>It is REQUIRED <bcp14>REQUIRED</bcp14> that anonymous
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
mutual authentication, key generation, and resistance to on-path
and dictionary attacks.  TLS cipher suites that do not provide
confidentiality MUST NOT <bcp14>MUST NOT</bcp14> be used.  During the TEAP Phase 1, the TEAP endpoints MAY <bcp14>MAY</bcp14> negotiate TLS compression.
During TLS tunnel establishment, TLS extensions MAY <bcp14>MAY</bcp14> be used.  For
instance, the Certificate Status Request extension <xref target="RFC6066"/> and the
Multiple Certificate Status Request extension <xref target="RFC6961"/> can be used
to leverage a certificate-status protocol such as the Online Certificate
Status Protocol (OCSP) <xref target="RFC6960"/> to check the validity of server
certificates.  TLS renegotiation indications defined in RFC 5746
<xref target="RFC5746"/> MUST <bcp14>MUST</bcp14> be supported.</t>
        <t>Use of TLS-PSK is NOT RECOMMENDED. <bcp14>NOT RECOMMENDED</bcp14>.  TEAP has not been designed to work
with TLS-PSK, and no use-cases, use cases, security analyses, or implementations
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
deploy it.</t>
        <t>The EAP server initiates the TEAP conversation with an EAP request
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
identity TLV.  The TLS payload in the initial packet is empty.  The
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
peer select the appropriate credential to use.  Assuming that the
peer supports TEAP, the conversation continues with the peer sending
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"/>.  This message
encapsulates one or more TLS handshake messages.  If the TEAP version
negotiation is successful, then the TEAP conversation continues until
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
2 MAY <bcp14>MAY</bcp14> be sent along with a server-finished handshake message to
reduce the number of round trips.</t>
        <t>TEAP implementations MUST <bcp14>MUST</bcp14> support mutual peer authentication during
tunnel establishment using the TLS cipher suites specified in this
section.  The TEAP peer does not need to authenticate as part of the
TLS exchange but can alternatively be authenticated through
additional exchanges carried out in Phase 2.</t>
        <t>The TEAP tunnel protects peer identity information exchanged during
Phase 2 from disclosure outside the tunnel.  Implementations that
wish to provide identity privacy for the peer identity need to
carefully consider what information is disclosed outside the tunnel
prior to Phase 2.  TEAP implementations SHOULD <bcp14>SHOULD</bcp14> support the immediate
renegotiation of a TLS session to initiate a new handshake message
exchange under the protection of the current cipher suite.  This
allows support for protection of the peer's identity when using TLS
client authentication.  An example of the exchanges using TLS
renegotiation to protect privacy is shown in Appendix C.</t> <xref target="appendix-c-examples"/>.</t>
      </section>
      <section anchor="server-certificate-requirements">
        <name>Server Certificate Requirements</name>
        <t>Server Certificates MUST certificates <bcp14>MUST</bcp14> include a subjectAltName
        extension, with the dnsName attribute containing an FQDN a Fully Qualified
        Domain Name (FQDN) string.  Server certificates MAY <bcp14>MAY</bcp14>
        also include a SubjectDN containing a single element, "CN=" containing "CN=",
        which contains the FQDN of the server.  However, this use of SubjectDN is
        deprecated for TEAP, TEAP and is forbidden in <xref section="2"
        sectionFormat="comma" target="RFC9525"/>.</t>
        <t>The KeyUsage extension MAY extensions <bcp14>MAY</bcp14> be included, included but are not required.</t>
<!-- [rfced] Please review the following sentence. RFC 5280 doesn't use the
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"/> MAY <bcp14>MAY</bcp14> also be included, but their use is discouraged.  Systems SHOULD <bcp14>SHOULD</bcp14> use a private Certification Authority (CA) for EAP in preference 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, private CAs can be designed for any purposes, purposes and can be restricted to an enterprise or an other organization.</t>
      </section>
      <section anchor="server-certificate-validation">
        <name>Server Certificate Validation</name>
        <t>As part of the TLS negotiation, the server usually presents a
certificate to the peer.  In most cases cases, the certificate needs to be
validated, but there are a number of situations where the EAP peer
need
does not need to do certificate validation:</t>
        <ul spacing="normal">
          <li>
            <t>when the peer has the Server's server's End Entity (EE) certificate pinned or loaded directly into it's trusted anchor information <xref target="RFC4949"/>;</t>
          </li>
          <li>
            <t>when the peer is requesting server unauthenticated provisioning;</t>
          </li>
          <li>
            <t>when the peer is certain that it will be using an authenticated inner method.</t>
          </li>
        </ul>
        <t>In some cases cases, such as onboarding (or "bootstrapping"), the certificate
validation may be delayed.  However, once the onboarding has taken
place, the validation steps described below MUST <bcp14>MUST</bcp14> still be performed.</t>
        <t>In all other cases, the EAP peer MUST <bcp14>MUST</bcp14> validate the server certificate.  This
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"/>.
Further guidance on server identity validation can be found in
<xref section="6" sectionFormat="comma" target="RFC9525"/>.</t>
<!-- [rfced] FYI: For the following sentence, we note that RFC 9525
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 MUST <bcp14>MUST</bcp14> use the realm to perform
the DNS-ID validation as per <xref section="6" sectionFormat="comma" target="RFC9525"/>.
The realm is used both to construct the list of reference identifiers
as defined in <xref section="6.2.1" section="6.1.2" sectionFormat="comma" target="RFC9525"/>, and as the
"source domain" field of that same section.</t>
        <t>When performing server certificate validation, implementations MUST <bcp14>MUST</bcp14>
also support the rules in <xref target="RFC5280"/> for validating certificates
against a known trust anchor.  In addition, implementations MUST <bcp14>MUST</bcp14>
support matching the realm portion of the peer's NAI against a
SubjectAltName of type dnsName within the server certificate.
However, in certain deployments, this comparison might not be
	appropriate or enabled.</t>
        <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 server identity given in the certificate presented by the EAP
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
have few, if any any, ways of validating the servers server's certificate.</t>
        <section anchor="client-certs-phase1">
          <name>Client Certificates sent during Sent During Phase 1</name>
          <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
authentication to be renegotiated after the first server
authentication.  To accomplish this, the server will typically not
request a certificate in the server_hello; then, after the
server_finished message is sent and before TEAP Phase 2, the server
MAY
<bcp14>MAY</bcp14> send a TLS hello_request.
This allows the peer to perform client
authentication by sending a client_hello if it wants to or send sending a
no_renegotiation alert to the server indicating that it wants to
continue with TEAP Phase 2 instead.  Assuming that the peer permits
renegotiation by sending a client_hello, then the server will respond
with server_hello, certificate, and certificate_request messages.
The peer replies with certificate, client_key_exchange, and
certificate_verify messages.  Since this renegotiation occurs within
the encrypted TLS channel, it does not reveal client certificate
details.  It is possible to perform certificate authentication using
EAP (for example, EAP-TLS) within the TLS session in TEAP
Phase 2 instead of using TLS handshake renegotiation.</t>
          <t>When TLS 1.3 or later is used, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that client
certificates are sent in Phase 1, 1 instead of via Phase 2 and EAP-TLS.
Doing so will reduce the number of round trips.  Further discussion of
this issue is given below in <xref target="inner-method-limitations"/></t>
        </section>
      </section>
      <section anchor="resumption">
        <name>Resumption</name>
        <t>For resumption, <xref section="5.7" sectionFormat="comma" target="RFC9190"/> discusses EAP-TLS resumption
for all versions of TLS, TLS and is incorporated herein by reference.
<xref section="4" sectionFormat="comma" target="RFC9427"/> is also incorporated by reference, as it
provides generic discussion of resumption for TLS-based EAP methods
when TLS 1.3 is used.</t>
        <t>This document only describes TEAP issues when resumption is used for
TLS versions of 1.2 and earlier.  It also describes resumption issues
which
that are specific to TEAP for TLS 1.3.</t>
        <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
the server rejects the resumption as per <xref section="5.7" sectionFormat="comma" target="RFC9190"/>.  It
then continues with a full handshake.  After the full TLS handshake
has completed, both EAP server and peer MUST <bcp14>MUST</bcp14> proceed with Phase 2.</t>
        <t>All TEAP implementations MUST <bcp14>MUST</bcp14> support resumption.  Using resumption
can significantly improve the scalability and stability of
authentication systems.  For example, some environments such as
universities may have users re-authenticating multiple times a day, if
not hourly.  Failure to implement resumption would increase the load
on the user database by orders of magnitude, leading to unnecessary
cost.</t>
        <t>The following sections describe how a TEAP session can be resumed
based on server-side or client-side state.</t>
        <section anchor="resume-server-state">
          <name>TLS Session Resumption Using Server State</name>
          <t>TEAP session resumption is achieved in the same manner TLS achieves
session resumption.  To support session resumption, the server and peer
cache the Session ID, master secret, and cipher suite.  The
peer attempts to resume a session by including a valid Session ID
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
new connection using the specified session state, the server will
respond with the same Session ID and proceed with the TEAP Phase 1
tunnel establishment based on a TLS abbreviated handshake.</t>
        </section>
        <section anchor="tls-session-resumption-using-client-state">
          <name>TLS Session Resumption Using Client State</name>
<t>TEAP supports the resumption of sessions based on the state being stored
on the client side using the TLS SessionTicket extension techniques
described in <xref target="RFC5077"/> and <xref target="RFC9190"/>.</t>
        </section>
      </section>
      <section anchor="teap-authentication-phase-2-tunneled-authentication">
        <name>TEAP Authentication Phase 2: Tunneled Authentication</name>
        <t>The second portion of the TEAP authentication occurs immediately
after successful completion of Phase 1.  Phase 2 occurs even if both
peer and authenticator are authenticated in the Phase 1 TLS
negotiation.  Phase 2 MUST NOT <bcp14>MUST NOT</bcp14> occur if the Phase 1 TLS handshake
fails, as that will compromise the security as the tunnel has not
been established successfully.  Phase 2 consists of a series of
requests and responses encapsulated in TLV objects defined in
<xref target="teap-tlv-format"/>.  Phase 2 MUST <bcp14>MUST</bcp14> always end with a Crypto-Binding TLV
exchange described in <xref target="crypto-binding-tlv"/> and a protected termination
exchange described in <xref target="protected-termination"/>.</t>
        <t>If the peer is not authenticated in Phase 1, the TEAP peer SHOULD <bcp14>SHOULD</bcp14> send
one or more Identity-Hint TLVs (<xref target="identity-hint-tlv"/> target="identity-hint-tlv"/>) as soon as the
TLS connection has been established.  This information lets the TEAP
server choose an authentication type which that is appropriate for that
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
peer.  It must necessarily choose an inner method, method and propose it to
the peer, which may reject that inner method.  The result will be that  As a result,
the peer fails to authenticate, authenticate and fails to obtain network access.</t>
        <t>The TLV exchange includes the execution of zero or more inner
methods within the protected tunnel as described in Sections <xref target="inner-eap"/> target="inner-eap" format="counter"/>
and <xref target="inner-password"/>. target="inner-password" format="counter"/>.  A server MAY <bcp14>MAY</bcp14> proceed directly to the
protected termination exchange, exchange without performing any inner
authentication if it does not wish to request further authentication
from the peer.  A server MAY <bcp14>MAY</bcp14> request one or more authentications
within the protected tunnel.  After completion of each inner method,
the server decides whether or not to begin another inner method, method or
to send a Result TLV.</t>
        <t>Implementations MUST <bcp14>MUST</bcp14> support at least two sequential inner methods,
which allows both Machine machine and User user authentication to be performed.
Implementations SHOULD <bcp14>SHOULD</bcp14> also limit the number of sequential inner
authentications, as there is no reason to perform a large number of inner
authentications in one TEAP conversation.</t>
        <t>Implementations wishing to use their own proprietary authentication
method,
method may substitute the EAP-Payload or Basic-Password-Auth-Req TLV
for the Vendor-Specific TLV TLV, which carries another authentication
method.  Any vendor-specific authentication method MUST <bcp14>MUST</bcp14> support
calculation of the Crypto-Binding TLV, TLV and MUST <bcp14>MUST</bcp14> use
Intermediate-Result TLV and Result TLV as is done with other
authentication methods.</t>
        <section anchor="inner-method-ordering">
          <name>Inner Method Ordering</name>
          <t>Due to issues noted in <xref target="limitations"/>, the order of inner methods has
implications for both security and interoperability.</t>
          <t>Where the authentication is expected to use multiple inner methods,
implementations SHOULD <bcp14>SHOULD</bcp14> order the methods so that a method which that
derives an EMSK Extended Master Session Key (EMSK) is used first, first before any other method.  This ordering
helps to securely tie the inner method to the TLS session, session and therefore
can prevent attacks.</t>
          <t>Implementations
<!-- [rfced] Should "passwords" be plural in this instance?

Original:
 Implementations SHOULD support both EAP and basic password for inner
 methods.

Perhaps:
 Implementations which SHOULD support both EAP and basic passwords for inner
 methods.
-->

          <t>Implementations <bcp14>SHOULD</bcp14> support both EAP and basic password for inner
methods.  Implementations that support multiple types of inner method methods
(User and Machine) MUST <bcp14>MUST</bcp14> support all of those methods in any order or
combination.  That is, it is explicitly permitted to "mix and match"
inner methods.</t>
          <t>For example, a server can request User user authentication from the peer, peer
and have the peer return Machine machine authentication (or vice versa).  If
the server is configured to accept Machine machine authentication, it MUST <bcp14>MUST</bcp14>
accept that response.  If that authentication succeeds, then depending
on local policy, the server SHOULD <bcp14>SHOULD</bcp14> proceed with requesting User user
authentication again.</t>
          <t>Similarly, a peer which that is configured to support multiple types of
inner method methods (User and Machine) can return a method other that than what
the server requested.  This action is usually taken by the peer so that it orders
inner methods for increased security.  See
<xref target="choosing-inner-methods"/> for further discussion of this issue.</t>
          <t>However, the peer and server MUST NOT <bcp14>MUST NOT</bcp14> assume that either will skip
inner methods or other TLV exchanges, as the other peer might have
a different security policy.  The peer may have roamed to a network
that requires conformance with a different authentication policy, or
the peer may request the server take additional action (e.g., channel
binding) through the use of the Request-Action TLV as defined in
<xref target="request-action-tlv"/>.</t>
          <t>The completion of each inner method is signaled by an
Intermediate-Result TLV.  Where the Intermediate-Result TLV indicates
failure, an Error TLV SHOULD <bcp14>SHOULD</bcp14> also be included, included using the most descriptive error code possible.  The
Intermediate-Result TLV may be accompanied by another TLV indicating
that the server wishes to perform a subsequent authentication.  When
all inner methods have completed, the server MUST <bcp14>MUST</bcp14> send a Result
TLV indicating success or failure instead of a TLV which that carries an
inner method.</t>
        </section>
        <section anchor="inner-eap">
          <name>Inner EAP Authentication</name>
          <t>EAP <xref target="RFC3748"/> prohibits use of multiple authentication methods within
a single EAP conversation in order to limit vulnerabilities to on-path
attacks.  TEAP addresses on-path attacks
through support for cryptographic protection of the inner EAP
exchange and cryptographic binding of the inner EAP
method(s) to the protected tunnel.  Inner methods are executed serially
in a sequence.  This version of TEAP does not support initiating
multiple inner methods simultaneously in parallel.  The inner methods need
not be distinct.  For example, EAP-TLS (<xref target="RFC5216"/> and <xref target="RFC9190"/>) could be run twice as an inner
method, first using machine credentials credentials, followed by a second instance
using user credentials.</t>
          <t>When EAP is used as an inner method, the EAP messages are carried within EAP-Payload TLVs defined in
<xref target="eap-payload-tlv"/>.  Note that in this use-case, use case, TEAP is simply a
carrier for EAP, much as RADIUS is a carrier for EAP.  The full EAP
state machine is run runs  as normal, normal and is carried over the EAP-Payload
TLV.  Each distinct EAP authentication MUST <bcp14>MUST</bcp14> be managed as a separate
EAP state machine.</t>
          <t>A TEAP server therefore MUST <bcp14>MUST</bcp14> begin an EAP authentication with an
EAP-Request/Identity (carried in an EAP-Payload TLV).  However, a TEAP
server MUST NOT <bcp14>MUST NOT</bcp14> finish the EAP conversation with an EAP Success or EAP
Failure packet, packet; the Intermediate-Result TLV is used instead.</t>
          <t>Upon completion of each EAP authentication in the tunnel, the server MUST <bcp14>MUST</bcp14> send
an Intermediate-Result TLV indicating the result of that authentication.  When the result indicates, success indicates success, it MUST <bcp14>MUST</bcp14> be accompanied by a Crypto-Binding 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 its own result and similarly on success <bcp14>MUST</bcp14> accompany the TLV with its own Crypto-Binding TLV.
The Crypto-Binding TLV is
further discussed in Sections <xref target="crypto-binding-tlv"/> target="crypto-binding-tlv" format="counter"/> and
<xref target="computing-compound-mac"/>. target="computing-compound-mac" format="counter"/>.  The Intermediate-Result TLVs can be
included with other TLVs which that indicate a subsequent authentication, authentication or with the Result TLV used in the protected termination
exchange.</t>
          <t>If both peer and server indicate success, 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
always imply a failure of the overall authentication.  If one
inner method fails, the server may attempt to authenticate
the peer with a different method (EAP or password).</t>
        </section>
        <section anchor="inner-password">
          <name>Inner Password Authentication</name>
          <t>The authentication server (AS) initiates password
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
authentication, then it responds with a Basic-Password-Auth-Resp TLV
as defined in <xref target="bp-auth-resp-tlv"/> that contains the username and password. password as defined in <xref target="bp-auth-resp-tlv"/>.
If it does not wish to perform password authentication, then it
responds with a NAK Negative Acknowledgment (NAK) TLV indicating the rejection of the Basic-Password-Auth-Req TLV.</t>
          <t>The basic password authentication defined here is similar in functionality to that used by EAP-TTLS (<xref target="RFC5281"/>) <xref target="RFC5281"/> with inner password authentication.  It shares a similar security and risk analysis.</t>
          <t>Multiple round trips of password authentication requests and responses
MAY
<bcp14>MAY</bcp14> be used to support some "housekeeping" functions such as a
password or pin change before a user is considered to be
authenticated.  Multiple rounds MAY <bcp14>MAY</bcp14> also be used to communicate a
user's password, and separately password and, separately, a one-time password such as Time-Based One-Time Passwords (TOTP) (TOTPs) <xref target="RFC6238"/>.</t>
          <t>Implementations MUST <bcp14>MUST</bcp14> limit the number of rounds round trips for password
authentication.  It is reasonable to use one or two round trips.
Further round trips are likely to be problematic, problematic and SHOULD <bcp14>SHOULD</bcp14> be
avoided.</t>
          <t>The first Basic-Password-Auth-Req TLV received in a session MUST <bcp14>MUST</bcp14>
include a prompt, which the peer displays to the user.  Subsequent
authentication rounds SHOULD <bcp14>SHOULD</bcp14> include a prompt, but it is not always
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 should
allow the user to enter both a Username username and a Password, password, which are then
placed in the Basic-Password-Auth-Resp TLV.  If the peer receives
subsequent Basic-Password-Auth-Req TLVs in the same authentication
session, it MUST NOT <bcp14>MUST NOT</bcp14> prompt for a Username, username and instead allow the user
to enter only a password.  The peer MUST <bcp14>MUST</bcp14> copy the Username username used in the
first Basic-Password-Auth-Resp TLV into all subsequent
Basic-Password-Auth-Resp TLVs.</t>
          <t>Servers MUST <bcp14>MUST</bcp14> track the Username username across multiple password rounds, rounds and
reject authentication if the identity changes from one
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>
          <t>Upon reception of a Basic-Password-Auth-Resp TLV in
the tunnel, the server MUST <bcp14>MUST</bcp14> send an Intermediate-Result TLV
indicating the result.  The peer MUST <bcp14>MUST</bcp14> respond
to the Intermediate-Result TLV indicating its result.  If the result
indicates success, the Intermediate-Result TLV MUST <bcp14>MUST</bcp14> be accompanied by
a Crypto-Binding TLV.  The Crypto-Binding TLV is further discussed in Sections
<xref target="crypto-binding-tlv"/> target="crypto-binding-tlv" format="counter"/> and <xref target="computing-compound-mac"/>.</t> target="computing-compound-mac" format="counter"/>.</t>
          <t>The Intermediate-Result TLVs can be included with other TLVs which that
indicate a subsequent authentication, authentication or with the Result TLV used in
the protected termination exchange.</t>
          <t>The use of EAP-FAST-GTC as defined in <xref target="RFC5421"/> is NOT
RECOMMENDED <bcp14>NOT RECOMMENDED</bcp14> with TEAPv1 because EAP-FAST-GTC is not compliant with
EAP-GTC defined in <xref target="RFC3748"/>.  Implementations should instead make
use of the password authentication TLVs defined in this
specification.</t>
        </section>
        <section anchor="eap-mschapv2">
          <name>EAP-MSCHAPv2</name>
          <t>If using EAP-MSCHAPv2 <xref target="KAMATH"/> target="I-D.kamath-pppext-eap-mschapv2"/> as an inner EAP method, the EAP-FAST-MSCHAPv2
variant defined in <xref section="3.2.3" sectionFormat="comma" target="RFC5422"/> MUST <bcp14>MUST</bcp14> be used, used instead of the derivation defined in <xref target="MSCHAP"/>.</t>
          <t>The difference between EAP-MSCHAPv2 and EAP-FAST-MSCHAPv2 is that the
first and the second 16 octets of the EAP-MSCHAPv2 Master Session Key (MSK) are swapped when it
is used as the Inner Method Session Keys (IMSK) (IMSKs) for TEAP.</t>
        </section>
        <section anchor="inner-method-limitations">
          <name>Limitations on inner methods</name> Inner Methods</name>
          <t>Implementations SHOULD <bcp14>SHOULD</bcp14> limit the permitted inner EAP methods to a
small set such as EAP-TLS and the EAP-FAST-MSCHAPv2 variant of
EAP-MSCHAPv2.  These EAP methods are the most commonly supported inner
methods in TEAP, TEAP and are known to be interoperable among multiple
implementations.</t>
          <t>Other EAP methods such as EAP-pwd, EAP-SIM, EAP-AKA, or EAP-AKA' can
be used within a TEAP tunnel.  Any EAP method which that derives both MSK
and ESMK EMSK is likely to work as an inner method for TEAP, because
EAP-TLS has that behavior, behavior and it works.  EAP methods which that derive
only MSK should work, as EAP-FAST-MSCHAPv2 has that behavior, and it
works.  Other EAP methods are untested, untested and may or may not work.</t>
          <t>Tunneled EAP methods such as (PEAP) PEAP <xref target="PEAP"/>, EAP-TTLS <xref target="RFC5281"/>, and
EAP-FAST <xref target="RFC4851"/> MUST NOT <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
password exchange.</t>
          <t>The EAP methods defined in <xref section="5" sectionFormat="comma" target="RFC3748"/> target="RFC3748"/>, such as
MD5-Challenge, One-Time Password (OTP), and Generic Token Card (GTC) (GTC),
do not derive a Master Session Key (MSK) an MSK or an Extended Master Session
Key (EMSK), EMSK and are vulnerable to on-path attacks.  The construction
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
and EAP-GTC offer no benefit over the basic password authentication
defined in <xref target="inner-password"/>, which also does not perform crypto-binding of
the inner method to the TLS session.  These EAP methods are therefore
not useful as phase Phase 2 methods within TEAP.</t>
          <t>Other EAP methods are less widely used, used and highly likely to not work
as the inner EAP method for TEAP.</t>
<t>In order to protect from on-path attacks, TEAP implementations MUST
NOT <bcp14>MUST
NOT</bcp14> permit the use of inner EAP methods which that fail to perform
crypto-binding of the inner method to the TLS session.</t>
          <t>Implementations MUST NOT <bcp14>MUST NOT</bcp14> permit resumption for the inner EAP methods
such as EAP-TLS.  If the user or machine needs to be authenticated, it
should use a method which that provides full authentication.  If the user or machine needs
to do resumption, it can perform a full authentication once, once and then
rely on the outer TLS session for resumption.  This restriction
applies also to all TLS-based EAP methods which that can tunnel other EAP
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
TLS-based EAP method such as TEAP is for privacy.  Many previous EAP
methods may leak information about user identity, and those leaks are
prevented by running the method inside of a protected TLS tunnel.</t>
          <t>EAP-TLS is permitted in Phase 2 for two use-cases. use cases.  The first use case is when
TLS 1.2 is used, as the client certificate is not protected as with
TLS 1.3. It is therefore RECOMMENDED <bcp14>RECOMMENDED</bcp14> that when TLS 1.3 is used for
   the outer TEAP exchange, the client certificate is sent in Phase 1, 1
   instead of doing EAP-TLS in Phase 2. This behavior will simplify the
   authentication exchange, exchange and use fewer round trips than doing EAP-TLS
   inside of TEAP.</t>
          <t>The second use-case use case for EAP-TLS in Phase 2 is where both the user and
machine use client certificates for authentication.  Since TLS permits
only one client certificate to be presented, only one certificate can
be used in Phase 1.  The second certificate is then presented via
EAP-TLS in Phase 2.</t>
          <t>For basic password authentication, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that this method
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
<xref target="RFC8146"/>) makes most clear-text cleartext password exchanges unnecessary.
The updates to EAP-pwd in <xref target="RFC8146"/> permit it to be used with
databases which that store passwords in "salted" form, which greatly
increases security.</t>
          <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
session via the TLS-PRF.  As a result, the TEAP session will be
vulnerable to on-path active attacks.  Implementations and deployments
SHOULD
<bcp14>SHOULD</bcp14> adopt various mitigation strategies described in <xref section="3.2" sectionFormat="comma" target="RFC7029"/>.  Implementations also need to implement the inner method
ordering described in {#key-derivations}, below, <xref target="key-derivations"/> in order to fully prevent on-path attacks.</t>
        </section>
        <section anchor="protected-termination">
          <name>Protected Termination and Acknowledged Result Indication</name>
          <t>A successful TEAP Phase 2 conversation MUST <bcp14>MUST</bcp14> always end in a
successful Crypto-Binding TLV and Result TLV exchange.  A TEAP server
may initiate the Crypto-Binding TLV and Result TLV exchange without
initiating any inner methods in TEAP Phase 2.  After the final
Result TLV exchange, the TLS tunnel is terminated, and a cleartext
EAP Success or EAP Failure is sent by the server.  Peers implementing
TEAP MUST NOT <bcp14>MUST NOT</bcp14> accept a cleartext EAP Success or failure Failure packet prior
to the peer and server reaching synchronized protected result
indication.</t>
          <t>The Crypto-Binding TLV exchange is used to prove that both the peer
and server participated in the tunnel establishment and sequence of
authentications.  It also provides verification of the TEAP type,
version negotiated, and Outer TLVs exchanged before the TLS tunnel
establishment.  Except as noted below, the Crypto-Binding TLV MUST <bcp14>MUST</bcp14> be exchanged and verified
before the final Result TLV exchange, regardless of whether or not
there is an inner method.  The Crypto-Binding TLV
and Intermediate-Result TLV MUST <bcp14>MUST</bcp14> be included to perform cryptographic
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
Intermediate-Result TLV and a Crypto-Binding TLV to indicate its
intention to end the conversation.  If the peer requires nothing more
from the server, it will respond with a Result TLV indicating success
accompanied by a Crypto-Binding TLV and Intermediate-Result TLV if
necessary.  The server then tears down the tunnel and sends a
cleartext EAP Success or EAP Failure.</t>
          <t>If the peer receives a Result TLV indicating success from the server,
but its authentication policies are not satisfied (for example, it
requires a particular authentication mechanism to be run), it may request further action from the server using
the Request-Action TLV.  The Request-Action TLV is sent with a Status
field indicating what EAP Success/Failure result the peer would
expect if the requested action is not granted.  The value of the
Action field indicates what the peer would like to do next.  The
format and values for the Request-Action TLV are defined in
<xref target="request-action-tlv"/>.</t>
          <t>Upon receiving the Request-Action TLV, the server may process the
request or ignore it, based on its policy.  If the server ignores the
request, it proceeds with termination of the tunnel and sends the
cleartext EAP Success or Failure message based on the Status field of
the peer's Request-Action TLV.  If the server honors and processes
the request, it continues with the requested action.  The
conversation completes with a Result TLV exchange.  The Result TLV
may be included with the TLV that completes the requested action.</t>
          <t>Error handling for Phase 2 is discussed in <xref target="phase-2-errors"/>.</t>
        </section>
      </section>
      <section anchor="determining-peer-id-and-server-id">
        <name>Determining Peer-Id and Server-Id</name>
        <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
authentication.  In the case of multiple peer authentications, all
authenticated peer identities and their corresponding identity types
(<xref target="identity-type-tlv"/>) need to be exported.  In the case of multiple server
authentications, all authenticated server identities need to be
exported.</t>
        <t>When X.509 certificates are used for peer authentication, the Peer-Id
is determined by the subject and subjectAltName fields in the peer
certificate.  As noted in <xref target="RFC5280"/>:</t>
        <artwork><![CDATA[
<blockquote><t>
The subject field identifies the entity associated with the public
key stored in the subject public key field.  The subject name MAY <bcp14>MAY</bcp14>
be carried in the subject field and/or the subjectAltName
extension. . . . If subject naming information is present only in
the subjectAltName extension (e.g., a key bound only to an email
address or URI), then the subject name MUST <bcp14>MUST</bcp14> be an empty sequence
and the subjectAltName extension MUST <bcp14>MUST</bcp14> be critical.

Where critical.</t>

<t>Where it is non-empty, the subject field MUST <bcp14>MUST</bcp14> contain an X.500
distinguished name (DN).
]]></artwork> (DN).</t>
</blockquote>
        <t>If an inner EAP authentication method is run, then the Peer-Id is obtained from that
inner EAP authentication method.</t>
        <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
above for the Peer-Id, e.g., the subject and subjectAltName fields in
the server certificate define the Server-Id.</t>
      </section>
      <section anchor="teap-session-identifier">
        <name>TEAP Session Identifier</name>
        <t>For TLS 1.2 and earlier, the EAP session identifier <xref target="RFC5247"/> is constructed using the tls-unique
from the Phase 1 outer tunnel at the beginning of Phase 2 as
defined by Section 3.1 of <xref target="RFC5929"/>. target="RFC5929" section="3.1"/>.  The Session-Id is defined as
follows:</t>
        <artwork><![CDATA[
   Session-Id = teap_type | tls-unique
]]></artwork> tls-unique]]></artwork>

        <t>Where:</t>
	<ul empty="true">
          <li>
            <t>where | spacing="normal">
	  <li>| denotes concatenation, and teap_type concatenation,</li>
	  <li>teap_type is the EAP Type assigned to TEAP</t>
            <t>tls-unique TEAP, and</li>
          <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>
          </li>
          target="RFC5929" section="3.1"/>.</li>
        </ul>

        <t>The Session-Id derivation for TLS 1.3 is given in <xref section="2.1" sectionFormat="comma" target="RFC9427"/></t>
      </section>
      <section anchor="error-handling">
        <name>Error Handling</name>
        <t>TEAP uses the error-handling rules summarized below:</t>
        <ol spacing="normal" type="1"><li>
            <t>Errors in the outer EAP packet layer are handled as defined in
<xref target="outer-layer-errors"/>.</t>
          </li>
          <li>
            <t>Errors in the TLS layer are communicated via TLS alert messages
in both phases of TEAP.</t>
          </li>
          <li>
            <t>The Intermediate-Result TLVs carry success or failure indications
of the individual inner methods in TEAP Phase 2.  Errors within an
EAP conversation in Phase 2 are expected to be handled by the
individual EAP authentication methods.</t>
          </li>
          <li>
            <t>Violations of the Inner TLV rules are handled using Result TLVs
together with Error TLVs.</t>
          </li>
          <li>
            <t>Tunnel-compromised errors (errors caused by a failed or missing
Crypto-Binding) are handled using Result TLVs and Error TLVs.</t>
          </li>
        </ol>
        <section anchor="outer-layer-errors">
          <name>Outer-Layer Errors</name>
          <t>Errors on the TEAP outer-packet layer are handled in the following
ways:</t>
          <ol spacing="normal" type="1"><li>
              <t>If Outer TLVs are invalid or contain unknown values, they will be
ignored.</t>
            </li>
            <li>
              <t>The entire TEAP packet will be ignored if other fields (version,
length, flags, etc.) are inconsistent with this specification.</t>
            </li>
          </ol>
        </section>
        <section anchor="tls-layer-errors">
          <name>TLS Layer Errors</name>
          <t>If the TEAP server detects an error at any point in the TLS handshake
or the TLS layer, the server SHOULD <bcp14>SHOULD</bcp14> send a TEAP request encapsulating
a TLS record containing the appropriate TLS alert message rather than
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 <bcp14>MUST</bcp14> send a TEAP response to
an alert message.  The EAP-Response packet sent by the peer SHOULD <bcp14>SHOULD</bcp14> contain a TEAP response with a zero-length message.
The server MUST <bcp14>MUST</bcp14> terminate the TEAP exchange with an EAP Failure
packet,
packet no matter what the client says.</t>
          <t>If the TEAP peer detects an error at any point in the TLS layer, the
TEAP peer SHOULD <bcp14>SHOULD</bcp14> send a TEAP response encapsulating a TLS record
containing the appropriate TLS alert message, and which contains a zero-length message.  The server then MUST <bcp14>MUST</bcp14> terminate the conversation with an EAP failure, failure as discussed in the previous paragraph.</t>
          <t>While TLS 1.3 (<xref target="RFC8446"/>) <xref target="RFC8446"/> allows for the TLS conversation to be restarted, it is not clear when that would be useful (or used) for TEAP.  Fatal TLS errors will cause the TLS conversation to fail.  Non-fatal TLS errors can likely be ignored entirely.  As a result, TEAP implementations MUST NOT <bcp14>MUST NOT</bcp14> permit TLS restarts.</t>
        </section>
        <section anchor="phase-2-errors">
          <name>Phase 2 Errors</name>
          <t>There are a large number of situations where errors can occur during
Phase 2 processing.  This section describes both those errors, errors and the
recommended processing of them.</t>
          <t>When the server receives a Result TLV with a fatal Error TLV from the
peer, it MUST <bcp14>MUST</bcp14> terminate the TLS tunnel and reply with an EAP Failure.</t>
          <t>When the peer receives a Result TLV with a fatal Error TLV from the
server, it MUST <bcp14>MUST</bcp14>  respond with a Result TLV indicating failure.
The server MUST <bcp14>MUST</bcp14> discard any data it receives from the peer, peer and reply
with an EAP Failure.  The final message from the peer is required by
the EAP state machine, machine and serves only to allow the server to reply
to the peer with the EAP Failure.</t>
          <t>The following items describe specific errors and processing in more
detail.</t>
          <t>Fatal
<dl spacing="normal" newline="true">
  <dt>Fatal Error processing a TLV</t>
          <ul empty="true">
            <li>
              <t>Any TLV:</dt>
  <dd>Any time the peer or the server finds a fatal error outside of the TLS
  layer during Phase 2 TLV processing, it MUST <bcp14>MUST</bcp14> send a Result
  TLV of failure and an Error TLV using the most descriptive error code possible.</t>
            </li>
          </ul>
          <t>Fatal
  possible.</dd>
  <dt>Fatal Error during TLV Exchanges</t>
          <ul empty="true">
            <li>
              <t>For Exchanges:</dt>
  <dd>For errors involving the processing of the sequence of exchanges, such
  as a violation of TLV rules (e.g., multiple EAP-Payload TLVs), the error
  code is Unexpected TLVs Exchanged.</t>
            </li>
          </ul>
          <t>Fatal Exchanged.</dd>
  <dt>Fatal Error due to tunnel compromise</t>
          <ul empty="true">
            <li>
              <t>For compromise:</dt>
  <dd>For errors involving a tunnel compromise compromise, such as when the Crypto-Binding
  TLV fails validation, the error code is Tunnel Compromise Error.</t>
            </li>
          </ul>
          <t>Non-Fatal Error.</dd>
  <dt>Non-Fatal Error due to inner method</t>
          <ul empty="true">
            <li>
              <t>If method:</dt>
  <dd><t>If there is a non-fatal error while running the inner method, the
  receiving side SHOULD NOT <bcp14>SHOULD NOT</bcp14> silently drop the inner method
  exchange.  Instead, it SHOULD <bcp14>SHOULD</bcp14> reply with an Error TLV containing
  using the most descriptive error code possible.</t>
  <t>If there is no error code which that matches the particular issue, then the
  value Inner Method Error (1001) SHOULD <bcp14>SHOULD</bcp14> be used. This response
  is a positive indication that there was an error processing the current
  inner method.  The side receiving a non-fatal Error TLV MAY <bcp14>MAY</bcp14>
  decide to start a new and different inner method instead or, or send back a
  Result TLV to terminate the TEAP authentication session.</t>
            </li>
          </ul> session.</t></dd>
</dl>
        </section>
      </section>
      <section anchor="fragmentation">
        <name>Fragmentation</name>
        <t>Fragmentation of EAP packets is discussed in <xref section="2.1.5." section="2.1.5" sectionFormat="comma" target="RFC5216"/> target="RFC5216"/>.
There is no special handling of fragments for TEAP.</t>
      </section>
      <section anchor="services-requested-by-the-peer">
        <name>Services Requested by the Peer</name>
        <t>Several TEAP operations, including server unauthenticated
provisioning, certificate provisioning, and channel binding, depend on
the peer trusting the TEAP server. If the peer trusts the provided
server certificate, then the server is authenticated.</t>
        <t>Typically, this authentication process involves the peer
validating the certificate to a trust anchor by verifying that the server presenting the certificate holds the private key, key and confirming that the
entity named by the certificate is the intended server.  Server
authentication also occurs when the procedures in <xref target="phase1"/> are used
to resume a session where the peer and server were previously mutually
authenticated.  Alternatively, the server is deemed to be
authenticated if an inner EAP method provides mutual authentication
along with a Master Session Key (MSK) an MSK and/or Extended Master Session
Key (EMSK). EMSK.  The inner method MUST <bcp14>MUST</bcp14> also provide for cryptographic
binding via the Compound Message Authentication Code (MAC), as
discussed in <xref target="crypto-binding-tlv"/>.  This issue is further described in
<xref target="unauth-provisioning"/>.</t>
        <t>TEAP peers MUST <bcp14>MUST</bcp14> track whether or not server authentication has taken
place. When the server cannot be authenticated, the peer MUST NOT <bcp14>MUST NOT</bcp14>
request any services such as certificate provisioning ({#cert-provisioning}) (<xref target="cert-provisioning"/>) from it.</t>
        <t>Unless

<!-- [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 <bcp14>MUST</bcp14>
authenticate the server, and fail the current authentication
session fails if the server cannot be authenticated.</t>
        <t>An additional complication arises when an inner method authenticates
multiple parties parties, such as authenticating both the peer machine and the
peer user to the EAP server.  Depending on how authentication is
achieved, only some of these parties may have confidence in it.  For
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 EAP server is the authenticated party if the machine cannot trust
the user not to disclose the shared secret to an attacker.  In these
cases, the parties who participate in the authentication need to be
considered when evaluating whether the peer should request these
services,
services or whether the server should provide them.</t>
        <t>The server MUST <bcp14>MUST</bcp14> also authenticate the peer before providing these
services.  The alternative is to send provisioning data to
unauthenticated and potentially malicious peers, which can have
negative impacts on security.</t>
        <t>When a device is provisioned via TEAP, any subsequent authorization
MUST
<bcp14>MUST</bcp14> be done on the authenticated credentials.  That is, there may be
no credentials (or anonymous credentials) passed in Phase 1, but there
will be credentials passed or provisioned in Phase 2.  If later
authorizations are done on the Phase 1 identity, then a device could
obtain the wrong authorization.  If instead authorization is done on
the authenticated credentials, credentials instead, then the device will obtain the correct
kind of network access.</t>
        <t>The correct authorization must also be applied to any resumption, as
noted in <xref section="5.7." section="5.7" sectionFormat="comma" target="RFC9190"/> target="RFC9190"/>.  However, as it is possible in TEAP
for the credentials to change, the new credentials MUST <bcp14>MUST</bcp14> be associated
with the session ticket.  If this association cannot be done, then the
server MUST <bcp14>MUST</bcp14> invalidate any session tickets for the current session.
This invalidation will force a full re-authentication on any
subsequent connection, connection; at which point point, the correct authorization will
be associated with any session ticket.</t>
        <t>Note that the act of re-provisioning a device is essentially
indistinguishable from any initial provisioning.  The device
authenticates,
authenticates and obtains new credentials via the standard
provisioning mechanisms.  The only caveat is that the device SHOULD
NOT <bcp14>SHOULD
NOT</bcp14> discard the old credentials unless either they are known to have
expired,
expired or the new credentials have been verified to work.</t>
        <section anchor="cert-provisioning">
          <name>Certificate Provisioning within Within the Tunnel</name>
<!-- [rfced] We note that RFC 2986 uses "CertificationRequest" rather than "CertificateRequest". Should "CertificateRequest" be updated in the
sentence below to match RFC 2986?

Current:
 A peer sends the Simple PKI Request using a PKCS#10 CertificateRequest
 [RFC2986] encoded into the body of a PKCS#10 TLV (see Section 4.2.17).

Perhaps:
 A peer sends the Simple PKI Request using a PKCS#10 CertificationRequest
 [RFC2986] encoded into the body of a PKCS#10 TLV (see Section 4.2.17).
-->
<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.
          (i.e., degenerate) "Certificates Only" message encoded into the body
          of a PKCS#7 TLV (see <xref target="pkcs7-tlv"/>), 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
including information specific to the current authenticated TLS
session within the signed certification request, the peer generating
the request SHOULD <bcp14>SHOULD</bcp14> obtain the tls-unique value from the TLS subsystem
as defined in "Channel Bindings for TLS" <xref target="RFC5929"/>.  The TEAP peer
operations between obtaining the tls-unique value through generation
of the Certification Signing Request (CSR) that contains the current
tls-unique value and the subsequent verification of this value by the
TEAP server are the "phases of the application protocol during which
application-layer authentication occurs" that are protected by the
synchronization interoperability mechanism described in the
interoperability note in "Channel Bindings for TLS" (<xref target="RFC5929"/>,
Section 3.1). target="RFC5929" sectionFormat="comma" section="3.1"/>).  When performing renegotiation, TLS
"secure_renegotiation" <xref target="RFC5746"/> MUST <bcp14>MUST</bcp14> be used.</t>
          <t>The tls-unique value is base-64-encoded as specified in
<xref target="message-formats"/> of
<xref section="4" target="RFC4648"/>, and the resulting string is placed in the certification
request challengePassword field (<xref target="RFC2985"/>, Section 5.4.1). target="RFC2985" sectionFormat="comma" section="5.4.1"/>).  The
challengePassword field is limited to 255 octets (Section 7.4.9 of
<xref target="RFC5246"/> (<xref target="RFC5246" section="7.4.9"/> indicates that no existing cipher suite would result in an
issue with this limitation).  If tls-unique information is not
embedded within the certification request, the challengePassword
field MUST <bcp14>MUST</bcp14> be empty to indicate that the peer did not include the
optional channel-binding information (any value submitted is verified
by the server as tls-unique information).</t>
          <t>The server SHOULD <bcp14>SHOULD</bcp14> verify the tls-unique information.  This ensures that the
signed certificate request is being presented by an authenticated TEAP peer
which
that is in possession of the private key.</t>
          <t>The Simple PKI Request/Response generation and processing rules of
<xref target="RFC5272"/> SHALL <bcp14>SHALL</bcp14> apply to TEAP, with the exception of error
conditions.  In the event of an error, the TEAP server SHOULD <bcp14>SHOULD</bcp14> respond
with an Error TLV using the most descriptive error code possible; it
MAY
<bcp14>MAY</bcp14> ignore the PKCS#10 request that generated the error.</t>
        </section>
        <section anchor="certificate-content-and-uses">
          <name>Certificate Content and Uses</name>
          <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
also be examined by the authenticator or Certification Authority (CA) CA
before any certificate is issued.</t>
          <t>The format of a CSR is complex, complex and contains a substantial amount of
information.  That information could be incorrect, such as a user
claiming a wrong physical address, email address, etc.  It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that systems provisioning these certificates
validate that the CSR both contains the expected data, data and also that
is
it does not contain unexpected data.  For example, a CA could refuse
to issue the certificate if the CSR contained unknown fields, fields or if a
known field contained an unexpected or invalid value.  The CA can modify or refuse a particular CSR to address these deficiencies for any
reasons, including local site policy.  We note that the "A" in "CA" means for "Authority", while the "R" in "CSR" means "Request".  There is no requirement for a CA to sign any and all CSRs  which that are presented to it.</t>
          <t>Once an EAP peer receives the signed certificate, the peer could
potentially be (ab) used (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 RECOMMENDED
<bcp14>NOT RECOMMENDED</bcp14> to use certificates provisioned via TEAP for
any non-TEAP protocol.  One method of enforcing this
restriction is to have different CAs (or different intermediate CAs)
which
that issue certificates for different uses.  For example, TLS-based
EAP methods could share one CA, and even use different intermediary CAs for different TLS-based EAP methods.  HTTPS servers could use an
entirely different CA.  The different protocols could then be configured
to validate client certificates only from their preferred CA, which would prevent peers from using certificates outside of the intended use-case.</t> use case.</t>
<!-- [rfced] Please review the following text. RFC 7299 does not contain the
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
<xref target="RFC7299"/>.  For example, the id-kp-eapOverLAN <xref target="RFC4334"/> value
could be used to indicate that this certificate is intended for use
only with EAP.</t>
          <t>It is difficult to give more detailed recommendations than the above.
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
document is to highlight the issues, issues and make the reader aware that
they have to be addressed.</t>
        </section>
        <section anchor="unauth-provisioning">
          <name>Server Unauthenticated Provisioning Mode</name>
          <t>In Server Unauthenticated Provisioning Mode, an unauthenticated
tunnel is established in Phase 1, and the peer and server negotiate
an inner method or methods in Phase 2.  This inner method MUST <bcp14>MUST</bcp14> support mutual authentication, provide key
derivation, and be resistant to attacks such as on-path and
dictionary attacks.  In most cases, this inner method will be an EAP authentication method.  Example inner methods which that satisfy these criteria include EAP-pwd <xref target="RFC5931"/>
and EAP-EKE <xref target="RFC6124"/>, target="RFC6124"/> but not EAP-FAST-MSCHAPv2.</t>
          <t>This provisioning mode enables the bootstrapping
of peers when the peer lacks the ability to authenticate the server
during Phase 1.  This includes both cases in which the cipher suite
negotiated does not provide authentication and in which the
cipher suite negotiated provides the authentication authentication, but the peer is
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
server exchange a Crypto-Binding TLV to bind the inner method with
the outer tunnel and ensure that an on-path attack has not
been attempted.</t>
          <t>Support for the Server Unauthenticated Provisioning Mode is optional.
The cipher suite TLS_DH_anon_WITH_AES_128_CBC_SHA is RECOMMENDED <bcp14>RECOMMENDED</bcp14> when
using Server Unauthenticated Provisioning Mode, but other anonymous
cipher suites MAY <bcp14>MAY</bcp14> be supported as long as the TLS pre-master secret is
generated from contribution from both peers.</t>
          <t>When a strong inner method is not used with Server Unauthenticated
Provisioning Mode, it is possible for an attacker to perform an
on-path attack.  In effect, Server Unauthenticated
Provisioning Mode has similar security issues as just running the
inner method in the open, open without the protection of TLS.  All of the
information in the tunnel should be assumed to be visible to, and
modifiable by, an attacker.</t>
          <t>Implementations SHOULD <bcp14>SHOULD</bcp14> exchange minimal data in Server
Unauthenticated Provisioning Mode.  Instead, they should use that mode
to set up a secure / authenticated tunnel, secure/authenticated tunnel and then use that tunnel to
perform any needed data exchange.</t>
          <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that client implementations and deployments
authenticate TEAP servers if at all possible.  Authenticating the
server means that a client can be provisioned securely with no chance of
an attacker eaves-dropping on the connection.</t>
          <t>Note that server Unauthenticated Provisioning unauthenticated provisioning can only use anonymous
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
server MUST <bcp14>MUST</bcp14> provide a certificate, and the peer performs server
unauthenticated provisioning by not validating the certificate chain
or any of its contents.</t>
        </section>
        <section anchor="channel-binding">
          <name>Channel Binding</name>
          <t><xref target="RFC6677"/> defines channel bindings for EAP which that solve the "lying NAS" and
the "lying provider" problems, using a process in which the EAP peer
gives information about the characteristics of the service provided
by the authenticator to the Authentication, Authorization, and
Accounting (AAA) server protected within the EAP authentication method.  This allows
the server to verify the authenticator is providing information to
the peer that is consistent with the information received from this
authenticator as well as the information stored about this
authenticator.</t>
          <t>TEAP supports EAP channel binding using the Channel-Binding TLV
defined in <xref target="channel-binding-tlv"/>.  If the TEAP server wants to request the
channel-binding information from the peer, it sends an empty
Channel-Binding TLV to indicate the request.  The peer responds to the
request by sending a Channel-Binding TLV containing a channel-binding
message as defined in <xref target="RFC6677"/>.  The server validates the
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
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
Channel-Binding TLV.  The peer MUST <bcp14>MUST</bcp14> only send channel-binding
information after it has successfully authenticated the server and
established the protected tunnel.</t>
        </section>
      </section>
    </section>
<!-- DNE -->
    <section anchor="message-formats">
      <name>Message Formats</name>
      <t>The following sections describe the message formats used in TEAP.
The fields are transmitted from left to right in network byte order.</t>
      <section anchor="teap-message-format">
        <name>TEAP Message Format</name>
        <t>A summary of the TEAP Request/Response packet format is shown below.</t>
        <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |   Identifier  |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Flags | Ver |        Message Length         :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:         Message Length        |         Outer TLV Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:     Outer TLV Length          |         TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Outer TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        <t>Code</t>
        <ul empty="true">
          <li>
            <t>The
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<dl spacing="normal" newline="true">
  <dt>Code</dt>
  <dd><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
  <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 MUST <bcp14>MUST</bcp14> be changed on each
  Request packet.  The Identifier field in the Response packet MUST
  <bcp14>MUST</bcp14> match the Identifier field from the corresponding request.</t>
          </li>
        </ul>
        <t>Length</t>
        <ul empty="true">
          <li>
            <t>The
  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.</t>
          </li>
        </ul>
        <t>Type</t>
        <ul empty="true">
          <li>
            <t>55 for TEAP</t>
          </li>
        </ul>
        <t>Flags</t> 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|
      +-+-+-+-+-+

   L  Length
+-+-+-+-+-+]]></artwork>

  <dl spacing="normal" newline="false">
    <dt>L</dt>
    <dd>Length included; set to indicate the presence of the four-octet
    Message Length field.  It MUST <bcp14>MUST</bcp14> be present for the first
    fragment of a fragmented message.  It MUST NOT <bcp14>MUST NOT</bcp14> be present
    for any other message.

   M  More message.</dd>
    <dt>M</dt>
    <dd>More fragments; set on all but the last fragment.

   S  TEAP fragment.</dd>
    <dt>S</dt>
    <dd>TEAP start; set in a TEAP Start message sent from the server to the peer.

   O  Outer
    peer.</dd>
    <dt>O</dt>
    <dd>Outer TLV length included; set to indicate the presence of the
    four-octet Outer TLV Length field.  It MUST <bcp14>MUST</bcp14> be present only
    in the initial request and response messages.  If the initial message is
    fragmented, then it MUST <bcp14>MUST</bcp14> be present only on the first fragment.

   R  Reserved (MUST
    fragment.</dd>
    <dt>R</dt>
    <dd>Reserved (<bcp14>MUST</bcp14> be zero and ignored upon receipt)
]]></artwork>
        <t>Ver</t>
        <ul empty="true">
          <li>
            <t>This receipt)</dd>
  </dl></dd>

  <dt>Ver</dt>
  <dd>This field contains the version of the protocol.  This document
  describes version 1 (001 in binary) of TEAP.</t>
          </li>
        </ul>
        <t>Message Length</t>
        <ul empty="true">
          <li>
            <t>The TEAP.</dd>
  <dt>Message Length</dt>
  <dd>The Message Length field is four octets and is present only if the L bit
  is set.  This field provides the total length of the message that may be
  fragmented over the data fields of multiple packets.</t>
          </li>
        </ul>
        <t>Outer packets.</dd>
  <dt>Outer TLV Length</t>
        <ul empty="true">
          <li>
            <t>The Length</dt>
  <dd>The Outer TLV Length field is four octets and is present only if the O
  bit is set.  This field provides the total length of the Outer TLVs if present.</t>
          </li>
        </ul>
        <t>TLS Data</t>
        <ul empty="true">
          <li>
            <t>When
  present.</dd>
  <dt>TLS Data</dt>
  <dd>When the TLS Data field is present, it consists of an encapsulated 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
  message.</dd>
  <dt>Outer TLVs</dt>
  <dd>The Outer TLVs consist of the optional data used to help establish 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> field.</dd>
</dl>
<!-- end of DNE -->
      </section>
      <section anchor="teap-tlv-format">
        <name>TEAP TLV Format and Support</name>
        <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
within the protected TLS tunnel.</t>
        <t>The EAP peer may not necessarily implement all the TLVs supported by
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
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 a TLV marked mandatory, then it MUST <bcp14>MUST</bcp14> send a NAK TLV in the
response, and all the other TLVs in the message MUST <bcp14>MUST</bcp14> be ignored.  If
an EAP peer or server finds an unsupported TLV that is marked as
optional, it can ignore the unsupported TLV.  It MUST <bcp14>MUST</bcp14> only send a NAK
TLV for a TLV which that is marked mandatory but is not understood, understood and MUST NOT <bcp14>MUST NOT</bcp14> otherwise send a NAK TLV.  If all TLVs in a message
are marked optional and none are understood by the peer, then a Result TLV SHOULD <bcp14>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>
        <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
a supported TLV with content that is not understood is defined by the
individual TLV specification.</t>
        <t>EAP implementations compliant with this specification MUST <bcp14>MUST</bcp14> support
TLV exchanges as well as the processing of mandatory/optional
settings on the TLV.  Implementations conforming to this
specification MUST <bcp14>MUST</bcp14> support the following TLVs:</t>
        <ul spacing="normal">
          <li>
            <t>Authority-ID TLV</t>
          </li>
          <li>
            <t>Identity-Type TLV</t>
          </li>
          <li>
            <t>Result TLV</t>
          </li>
          <li>
            <t>NAK TLV</t>
          </li>
          <li>
            <t>Error TLV</t>
          </li>
          <li>
            <t>Request-Action TLV</t>
          </li>
          <li>
            <t>EAP-Payload TLV</t>
          </li>
          <li>
            <t>Intermediate-Result TLV</t>
          </li>
          <li>
            <t>Crypto-Binding TLV</t>
          </li>
          <li>
            <t>Basic-Password-Auth-Req TLV</t>
          </li>
          <li>
            <t>Basic-Password-Auth-Resp TLV</t>
          </li>
        </ul>
        <section anchor="general-tlv-format">
          <name>General TLV Format</name>
          <t>TLVs are defined as described below.  The fields are transmitted from
left to right.</t>
          <t>If a peer or server receives a TLV which that is not of the correct format,
the TLV MUST <bcp14>MUST</bcp14> be discarded.  It is generally useful to log an error or
debugging message which that indicates which TLV had an issue, issue and what the
problem is.  However, TLVs which that are malformed are invalid, invalid and cannot
be used.</t>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|            TLV Type       |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>0  Optional TLV</t>
              <t>1  Mandatory TLV</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<dl spacing="normal" newline="true">
  <dt>M</dt>
  <dd>
    <dl spacing="normal" newline="false">
      <dt>0</dt><dd>Optional TLV</dd>
      <dt>1</dt><dd>Mandatory TLV</dd>
    </dl>
  </dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>TLV Type</t>
          <t>A (0)</dd>
  <dt>TLV Type</dt>
  <dd><t>A 14-bit field, denoting the TLV type.  Allocated types include:</t>
          <ul empty="true">
            <li>
              <t>0  Unassigned</t>
              <t>1  Authority-ID
  <dl spacing="normal" newline="false">
    <dt>0</dt><dd>Unassigned</dd>
    <dt>1</dt><dd>Authority-ID TLV (<xref target="authority-id-tlv"/>)</t>
              <t>2  Identity-Type target="authority-id-tlv"/>)</dd>
    <dt>2</dt><dd>Identity-Type TLV (<xref target="identity-type-tlv"/>)</t>
              <t>3  Result target="identity-type-tlv"/>)</dd>
    <dt>3</dt><dd>Result TLV (<xref target="result-tlv"/>)</t>
              <t>4  NAK target="result-tlv"/>)</dd>
    <dt>4</dt><dd>NAK TLV (<xref target="nak-tlv"/>)</t>
              <t>5  Error target="nak-tlv"/>)</dd>
    <dt>5</dt><dd>Error TLV (<xref target="error-tlv"/>)</t>
              <t>6  Channel-Binding target="error-tlv"/>)</dd>
    <dt>6</dt><dd>Channel-Binding TLV (<xref target="channel-binding-tlv"/>)</t>
              <t>7  Vendor-Specific target="channel-binding-tlv"/>)</dd>
    <dt>7</dt><dd>Vendor-Specific TLV (<xref target="vendor-specific-tlv"/>)</t>
              <t>8  Request-Action target="vendor-specific-tlv"/>)</dd>
    <dt>8</dt><dd>Request-Action TLV (<xref target="request-action-tlv"/>)</t>
              <t>9  EAP-Payload target="request-action-tlv"/>)</dd>
    <dt>9</dt><dd>EAP-Payload TLV (<xref target="eap-payload-tlv"/>)</t>
              <t>10 Intermediate-Result target="eap-payload-tlv"/>)</dd>
    <dt>10</dt><dd>Intermediate-Result TLV (<xref target="intermediate-result-tlv"/>)</t>
              <t>11 PAC target="intermediate-result-tlv"/>)</dd>
    <dt>11</dt><dd>PAC TLV (DEPRECATED)</t>
              <t>12 Crypto-Binding (DEPRECATED)</dd>
    <dt>12</dt><dd>Crypto-Binding TLV (<xref target="crypto-binding-tlv"/>)</t>
              <t>13 Basic-Password-Auth-Req target="crypto-binding-tlv"/>)</dd>
    <dt>13</dt><dd>Basic-Password-Auth-Req TLV (<xref target="bp-auth-req-tlv"/>)</t>
              <t>14 Basic-Password-Auth-Resp target="bp-auth-req-tlv"/>)</dd>
    <dt>14</dt><dd>Basic-Password-Auth-Resp TLV (Section 4.2.15)</t>
              <t>15 PKCS#7 (<xref target="bp-auth-resp-tlv"/>)</dd>
    <dt>15</dt><dd>PKCS#7 TLV (<xref target="pkcs7-tlv"/>)</t>
              <t>16 PKCS#10 target="pkcs7-tlv"/>)</dd>
    <dt>16</dt><dd>PKCS#10 TLV (<xref target="pkcs10-tlv"/>)</t>
              <t>17 Trusted-Server-Root target="pkcs10-tlv"/>)</dd>
    <dt>17</dt><dd>Trusted-Server-Root TLV (<xref target="trusted-server-root-tlv"/>)</t>
              <t>18 CSR-Attributes target="trusted-server-root-tlv"/>)</dd>
    <dt>18</dt><dd>CSR-Attributes TLV (<xref target="csr-attributes-tlv"/>)</t>
              <t>19 Identity-Hint target="csr-attributes-tlv"/>)</dd>
    <dt>19</dt><dd>Identity-Hint TLV (<xref target="identity-hint-tlv"/>)</t>
            </li>
          </ul>
          <t>Length</t>
          <ul empty="true">
            <li>
              <t>The target="identity-hint-tlv"/>)</dd>
  </dl></dd>
  <dt>Length</dt>
  <dd>The length of the Value field in octets.</t>
            </li>
          </ul>
          <t>Value</t>
          <ul empty="true">
            <li>
              <t>The octets.</dd>
  <dt>Value</dt>
  <dd>The value of the TLV.</t>
            </li>
          </ul> TLV.</dd>
</dl>
        </section>
        <section anchor="authority-id-tlv">
          <name>Authority-ID TLV</name>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<dl spacing="normal" newline="true">
  <dt>M</dt>
  <dd>0 - Optional TLV</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved, TLV</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>TLV Type</t>
          <ul empty="true">
            <li>
              <t>1 - Authority-ID</t>
            </li>
          </ul>
          <t>Length</t>
          <ul empty="true">
            <li>
              <t>The (0)</dd>
  <dt>TLV Type</dt>
  <dd>1 - Authority-ID</dd>
  <dt>Length</dt>
  <dd>The Length field is two octets and contains the length of the ID field
  in octets.</t>
            </li>
          </ul>
          <t>ID</t>
          <ul empty="true">
            <li>
              <t>Hint octets.</dd>
  <dt>ID</dt>
  <dd>Hint of the identity of the server to help the peer to match the
  credentials available for the server.  It should be unique across the deployment.</t>
            </li>
          </ul>
  deployment.</dd>
</dl>
        </section>
        <section anchor="identity-type-tlv">
          <name>Identity-Type TLV</name>
          <t>The Identity-Type TLV allows an EAP server to send a hint to help the
EAP peer select the right type of identity, for example, user or
machine.  TEAPv1 implementations MUST <bcp14>MUST</bcp14> support this TLV.  Only one
Identity-Type TLV SHOULD <bcp14>SHOULD</bcp14> be present in the TEAP request or response
packet.</t>
          <t>A server sending the Identity-Type TLV MUST <bcp14>MUST</bcp14> also
include an EAP-Payload TLV or a Basic-Password-Auth-Resp TLV.  A
peer sending an Identity-Type TLV MUST <bcp14>MUST</bcp14> also include
EAP-Payload TLV or a Basic-Password-Auth-Resp TLV.</t>
          <t>An EAP peer receiving an Identity-Type request
SHOULD
<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
if the EAP peer does not have an identity corresponding to the
identity type requested, then the peer SHOULD <bcp14>SHOULD</bcp14> respond with an
Identity-Type TLV with the one of available identity types.</t>
          <t>A server receiving an Identity-Type in the response MUST <bcp14>MUST</bcp14> check if the
value of the Identity-Type in the response matches the value of the
Identity-Type which that was sent in the request.  A match means that the
server can proceed with authentication.</t>
          <t>However, if the values do not match, the server can proceed with
authentication if and only if the following two conditions match.  If
either of the following two conditions does not match, the server MUST <bcp14>MUST</bcp14>
respond with a Result TLV of Failure.</t>
          <ul empty="true">
            <li>

<ol spacing="normal" type="1"><li> type="1">
<li>
  <t>The Identity-Type contains a value permitted by the server configuration.</t>
</li>
<li>
  <t>The Identity-Type value was not previously used for a successful authentication.</t>
</li>
</ol>
            </li>
          </ul>

          <t>The first condition allows a server to be configured to permit only
User
user authentication, or else only Machine Authentication. machine authentication.  A server
could also use an Identity-Hint TLV sent in the response to permit
different types of authentication for different identities.  A server
could also permit or forbid different kinds of authentication based on
other information, such an outer EAP Identity, or fields in an outer
EAP client certificate, or other fields received in a RADIUS or
Diameter packet along with the TEAP session.  There is no requirement
that a server has to support both User user and Machine machine authentication for
all TEAP sessions.</t>
          <t>The second condition ensures that if a particular inner method
succeeds, the server does not attempt a subsequent inner method for
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
additional authentication via a different inner method.  Similarly,
there is no benefit to repeating an authentication sessions for the
same user; the result will not change.</t>
          <t>This second condition also forbids multiple rounds of challenge /
response challenge/response authentication via the Basic-Password-Auth-Req TLV.  TEAPv1
supports only one round of Basic-Password-Auth-Req followed by
Basic-Password-Auth-Resp.  The result of that round MUST NOT <bcp14>MUST NOT</bcp14> be
another Basic-Password-Auth-Req TLV.</t>
          <t>This second condition also means that a server MUST NOT <bcp14>MUST NOT</bcp14> send an
Identity-Hint TLV which that has the same value as was previously used for
a successful authentication.</t>
          <t>The Identity-Type TLV is defined as follows:</t>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identity-Type         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>Mandatory,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<dl spacing="normal" newline="true">
  <dt>M</dt>
  <dd>Mandatory, set to one (1)</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved, (1)</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>TLV Type</t>
          <ul empty="true">
            <li>
              <t>2 (0)</dd>
  <dt>TLV Type</dt>
  <dd>2 - Identity-Type TLV</t>
            </li>
          </ul>
          <t>Length</t>
          <ul empty="true">
            <li>
              <t>2</t>
            </li>
          </ul>
          <t>Identity-Type</t>
          <ul empty="true">
            <li> TLV</dd>
  <dt>Length</dt>
  <dd>2</dd>
  <dt>Identity-Type</dt>
  <dd>
    <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>
    <dl spacing="normal" newline="false">
      <dt>1</dt><dd>User</dd>
      <dt>2</dt><dd>Machine</dd>
    </dl>
  </dd>
</dl>
        </section>
<!-- DNE -->
        <section anchor="result-tlv">
          <name>Result TLV</name>
          <t>The Result TLV provides support for acknowledged success and failure
messages for protected termination within TEAP.  If the Status field
does not contain one of the known values, then the peer or EAP server
MUST
<bcp14>MUST</bcp14> treat this as a fatal error of Unexpected TLVs Exchanged.  The
behavior of the Result TLV is further discussed in Sections <xref target="protected-termination"/> target="protected-termination" format="counter"/> and
	  <xref target="phase-2-errors"/>.</t>
          <t>A 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 accompanied by
the following TLVs: NAK, EAP-Payload TLV, or Crypto-Binding TLV.</t>
          <t>A Result TLV Indicating Success MUST indicating success <bcp14>MUST</bcp14> be accompanied by a Crypto-Binding TLV.</t>
          <t>The Result TLV is defined as follows:</t>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Status            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>Mandatory,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<dl spacing="normal" newline="true">
  <dt>M</dt>
  <dd>Mandatory, set to one (1)</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved, (1)</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>TLV Type</t>
          <ul empty="true">
            <li>
              <t>3 (0)</dd>
  <dt>TLV Type</dt>
  <dd>3 - Result TLV</t>
            </li>
          </ul>
          <t>Length</t>
          <ul empty="true">
            <li>
              <t>2</t>
            </li>
          </ul>
          <t>Status</t>
          <ul empty="true">
            <li> TLV</dd>
  <dt>Length</dt>
  <dd>2</dd>
  <dt>Status</dt>
  <dd>
    <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>
    <dl spacing="normal" newline="false">
      <dt>1</dt><dd>Success</dd>
      <dt>2</dt><dd>Failure</dd>
    </dl>
  </dd>
</dl>
<!-- end of DNE -->
        </section>
        <section anchor="nak-tlv">
          <name>NAK TLV</name>
          <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
 TLV should not be accompanied by other TLVs.  A NAK TLV MUST NOT <bcp14>MUST NOT</bcp14> be
 sent in response to a message containing a Result TLV, instead a
 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>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Vendor-Id                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            NAK-Type           |           TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>Mandatory,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<dl spacing="normal" newline="true">
  <dt>M</dt>
  <dd>Mandatory, set to one (1)</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved, (1)</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>TLV Type</t>
          <ul empty="true">
            <li>
              <t>4 (0)</dd>
  <dt>TLV Type</dt>
  <dd>4 - NAK TLV</t>
            </li>
          </ul>
          <t>Length</t>
          <ul empty="true">
            <li>
              <t>&gt;=6</t>
            </li>
          </ul>
          <t>Vendor-Id</t>
          <ul empty="true">
            <li>
              <t>The TLV</dd>
  <dt>Length</dt>
  <dd>&gt;=6</dd>
  <dt>Vendor-Id</dt>
  <dd>The Vendor-Id field is four octets and contains the Vendor-Id of 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 <bcp14>MUST</bcp14> be zero for TLVs that are not
  Vendor-Specific TLVs.</t>
            </li>
          </ul>
          <t>NAK-Type</t>
          <ul empty="true">
            <li>
              <t>The TLVs.</dd>
  <dt>NAK-Type</dt>
  <dd>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 <bcp14>MUST</bcp14> have
  been included in the previous packet.</t>
            </li>
          </ul>
          <t>TLVs</t>
          <ul empty="true">
            <li>
              <t>This packet.</dd>
  <dt>TLVs</dt>
  <dd>This field contains a list of zero or more TLVs, each of which
MUST NOT
  <bcp14>MUST NOT</bcp14> 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> unsupported.</dd>
</dl>
        </section>
<!-- DNE -->
        <section anchor="error-tlv">
          <name>Error TLV</name>
          <t>The Error TLV allows an EAP peer or server to indicate errors to 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
represent successful outcomes (informative messages), 1000-1999
represent warnings, and 2000-2999 represent fatal errors.  A fatal
Error TLV MUST <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>
          <t>Many of the error codes below refer to errors in inner method
processing that may be retrieved if made available by the inner
method.  Implementations MUST <bcp14>MUST</bcp14> take care that error messages do not
reveal too much information to an attacker.  For example, the usage
of error message 1031 (User account credentials incorrect) is NOT
RECOMMENDED,
<bcp14>NOT RECOMMENDED</bcp14>, because it allows an attacker to determine valid
usernames by differentiating this response from other responses.  It
should only be used for troubleshooting purposes.</t>
          <t>The Error TLV is defined as follows:</t>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Error-Code                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>Mandatory,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<dl spacing="normal" newline="true">
  <dt>M</dt>
  <dd>Mandatory, set to one (1)</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved, (1)</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>TLV Type</t>
          <ul empty="true">
            <li>
              <t>5 (0)</dd>
  <dt>TLV Type</dt>
  <dd>5 - Error TLV</t>
            </li>
          </ul>
          <t>Length</t>
          <ul empty="true">
            <li>
              <t>4</t>
            </li>
          </ul>
          <t>Error-Code</t>
          <ul empty="true">
            <li> TLV</dd>
  <dt>Length</dt>
  <dd>4</dd>
  <dt>Error-Code</dt>
  <dd>
    <t>The Error-Code field is four octets.  Currently defined values for
    Error-Code include:</t>
              <ul empty="true">
                <li>
                  <t>1     User
    <dl spacing="normal" newline="false">
      <dt>1</dt><dd>User account expires soon</t>
                  <t>2     User soon</dd>
      <dt>2</dt><dd>User account credential expires soon</t>
                  <t>3     User soon</dd>
      <dt>3</dt><dd>User account authorizations change soon</t>
                  <t>4     Clock soon</dd>
      <dt>4</dt><dd>Clock skew detected</t>
                  <t>5     Contact administrator</t>
                  <t>6     User detected</dd>
      <dt>5</dt><dd>Contact administrator</dd>
      <dt>6</dt><dd>User account credentials change required</t>
                  <t>1001  Inner required</dd>
      <dt>1001</dt><dd>Inner Method Error</t>
                  <t>1002  Unspecified Error</dd>
      <dt>1002</dt><dd>Unspecified authentication infrastructure problem</t>
                  <t>1003 problem</dd>
      <dt>1003</dt><dd>  Unspecified authentication failure</t>
                  <t>1004 failure</dd>
      <dt>1004</dt><dd>  Unspecified authorization failure</t>
                  <t>1005 failure</dd>
      <dt>1005</dt><dd>  User account credentials unavailable</t>
                  <t>1006 unavailable</dd>
      <dt>1006</dt><dd>  User account expired</t>
                  <t>1007 expired</dd>
      <dt>1007</dt><dd>  User account locked: try again later</t>
                  <t>1008 later</dd>
      <dt>1008</dt><dd>  User account locked: admin intervention required</t>
                  <t>1009 required</dd>
      <dt>1009</dt><dd>  Authentication infrastructure unavailable</t>
                  <t>1010 unavailable</dd>
      <dt>1010</dt><dd>  Authentication infrastructure not trusted</t>
                  <t>1011 trusted</dd>
      <dt>1011</dt><dd>  Clock skew too great</t>
                  <t>1012 great</dd>
      <dt>1012</dt><dd>  Invalid inner realm</t>
                  <t>1013 realm</dd>
      <dt>1013</dt><dd>  Token out of sync: administrator intervention required</t>
                  <t>1014 required</dd>
      <dt>1014</dt><dd>  Token out of sync: PIN change required</t>
                  <t>1015 required</dd>
      <dt>1015</dt><dd>  Token revoked</t>
                  <t>1016 revoked</dd>
      <dt>1016</dt><dd>  Tokens exhausted</t>
                  <t>1017 exhausted</dd>
      <dt>1017</dt><dd>  Challenge expired</t>
                  <t>1018 expired</dd>
      <dt>1018</dt><dd>  Challenge algorithm mismatch</t>
                  <t>1019 mismatch</dd>
      <dt>1019</dt><dd>  Client certificate not supplied</t>
                  <t>1020 supplied</dd>
      <dt>1020</dt><dd>  Client certificate rejected</t>
                  <t>1021 rejected</dd>
      <dt>1021</dt><dd>  Realm mismatch between inner and outer identity</t>
                  <t>1022 identity</dd>
      <dt>1022</dt><dd>  Unsupported Algorithm In Certificate Signing Request</t>
                  <t>1023 Request</dd>
      <dt>1023</dt><dd>  Unsupported Extension In Certificate Signing Request</t>
                  <t>1024 Request</dd>
      <dt>1024</dt><dd>  Bad Identity In Certificate Signing Request</t>
                  <t>1025 Request</dd>
      <dt>1025</dt><dd>  Bad Certificate Signing Request</t>
                  <t>1026 Request</dd>
      <dt>1026</dt><dd>  Internal CA Error</t>
                  <t>1027 Error</dd>
      <dt>1027</dt><dd>  General PKI Error</t>
                  <t>1028 Error</dd>
      <dt>1028</dt><dd>  Inner method's channel-binding data required but not
supplied</t>
                  <t>1029
      supplied</dd>
      <dt>1029</dt><dd> Inner method's channel-binding data did not include
      required
information</t>
                  <t>1030 information</dd>
      <dt>1030</dt><dd>  Inner method's channel binding failed</t>
                  <t>1031 failed</dd>
      <dt>1031</dt><dd>  User account credentials incorrect [USAGE NOT RECOMMENDED]</t>
                  <t>1032 <bcp14>NOT RECOMMENDED</bcp14>]</dd>
      <dt>1032</dt><dd>  Inner method not supported</t>
                  <t>2001 supported</dd>
      <dt>2001</dt><dd>  Tunnel Compromise Error</t>
                  <t>2002 Error</dd>
      <dt>2002</dt><dd>  Unexpected TLVs Exchanged</t>
                  <t>2003 Exchanged</dd>
      <dt>2003</dt><dd>  The Crypto-Binding TLV is invalid (Version, or Received-Ver, or Sub-Type)</t>
                  <t>2004 Sub-Type)</dd>
      <dt>2004</dt><dd>  The first inner method did not derive EMSK</t>
                  <t>2005 EMSK</dd>
      <dt>2005</dt><dd>  The Crypto-Binding TLV did not include a required MSK Compound-MAC</t>
                  <t>2006 Compound-MAC</dd>
      <dt>2006</dt><dd>  The MSK Compound-MAC fails verification</t>
                  <t>2007 verification</dd>
      <dt>2007</dt><dd>  The Crypto-Binding TLV did not include a required EMSK Compound-MAC</t>
                  <t>2008 Compound-MAC</dd>
      <dt>2008</dt><dd>  The EMSK Compound-MAC fails verification</t>
                  <t>2009 verification</dd>
      <dt>2009</dt><dd>  The EMSK Compound-MAC exists, but the inner method did not derive EMSK</t>
                </li>
              </ul>
            </li>
          </ul> EMSK</dd>
    </dl>
  </dd>
</dl>
<!-- end of DNE -->
        </section>
<!-- DNE -->
        <section anchor="channel-binding-tlv">
          <name>Channel-Binding TLV</name>
          <t>The Channel-Binding TLV provides a mechanism for carrying
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"/>.
TEAPv1 implementations MAY <bcp14>MAY</bcp14> support this TLV, which cannot be
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
support this TLV, then the server MUST <bcp14>MUST</bcp14> ignore the value.  The
Channel-Binding TLV is defined as follows:</t>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<dl spacing="normal" newline="true">
  <dt>M</dt>
  <dd>0 - Optional TLV</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved, TLV</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>TLV Type</t>
          <ul empty="true">
            <li>
              <t>6 (0)</dd>
  <dt>TLV Type</dt>
  <dd>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 TLV</dd>
  <dt>Length</dt>
  <dd>variable</dd>
  <dt>Data</dt>
  <dd>The data field contains a channel-binding message as defined in
Section 5.3 of
  <xref target="RFC6677"/>.</t>
            </li>
          </ul> target="RFC6677" section="5.3"/>.</dd>
</dl>
<!-- end of DNE -->
        </section>
        <section anchor="vendor-specific-tlv">
          <name>Vendor-Specific TLV</name>
          <t>The Vendor-Specific TLV is available to allow vendors to support
their own extended attributes not suitable for general usage.  A
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
vendor.  All the Vendor TLVs inside a single Vendor-Specific TLV
belong to the same vendor.  There can be multiple Vendor-Specific
TLVs from different vendors in the same message.  Error handling in
the Vendor TLV could use the vendor's own specific error-handling
mechanism or use the standard TEAP error codes defined.</t>
          <t>Vendor TLVs may be optional or mandatory.  Vendor TLVs sent with
Result TLVs MUST <bcp14>MUST</bcp14> be marked as optional.  If the Vendor-Specific TLV
is marked as mandatory, then it is expected that the receiving side
needs to recognize the vendor ID, parse all Vendor TLVs within, and
deal with error handling within the Vendor-Specific TLV as defined by
the vendor.</t>
          <t>Where a Vendor-Specific TLV carries an authentication protocol in the
inner method, it MUST <bcp14>MUST</bcp14> define values for MSK and EMSK.  Where these
values cannot be derived from cryptographic primitives, they MUST <bcp14>MUST</bcp14> be
set to zero, as happens when Basic-Password-Auth-Req is used.</t>
          <t>The Vendor-Specific TLV is defined as follows:</t>
<!-- DNE -->
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Vendor-Id                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Vendor TLVs....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>0 or 1</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<dl spacing="normal" newline="true">
  <dt>M</dt>
  <dd>0 or 1</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>TLV Type</t>
          <ul empty="true">
            <li>
              <t>7 (0)</dd>
  <dt>TLV Type</dt>
  <dd>7 - Vendor-Specific TLV</t>
            </li>
          </ul>
          <t>Length</t>
          <ul empty="true">
            <li>
              <t>4 TLV</dd>
  <dt>Length</dt>
  <dd>4 + cumulative length of all included Vendor TLVs</t>
            </li>
          </ul>
          <t>Vendor-Id</t>
          <ul empty="true">
            <li>
              <t>The TLVs</dd>
  <dt>Vendor-Id</dt>
  <dd>The Vendor-Id field is four octets and contains the Vendor-Id of 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
  order.</dd>
  <dt>Vendor TLVs</dt>
  <dd>This field is of indefinite length.  It contains Vendor-Specific TLVs,
  in a format defined by the vendor.</t>
            </li>
          </ul> vendor.</dd>
</dl>
<!-- end of DNE -->
        </section>
        <section anchor="request-action-tlv">
          <name>Request-Action TLV</name>
          <t>The Request-Action TLV MAY <bcp14>MAY</bcp14> be sent at any time.  The Request-Action
TLV allows the peer or server to request that the other side negotiates
additional inner methods or process TLVs which that are passed inside of
the Request-Action TLV.</t>
          <t>The receiving side MUST <bcp14>MUST</bcp14> process this TLV.  The processing for the TLV
is as follows:</t>
          <ul empty="true">
            <li>
              <t>The

              <t indent="3">The receiving entity MAY <bcp14>MAY</bcp14> choose to process any of the TLVs that
are included in the message.</t>
              <t>If
              <t indent="3">If the receiving entity chooses NOT to process any TLV in the
list, then it sends back a Result TLV with the same code in the
Status field of the Request-Action TLV.</t>
              <t>If
              <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
processed.</t>
            </li>
          </ul>
          <ul empty="true">
            <li>
              <t>If
              <t indent="3">If multiple Request-Action TLVs are in the request and none of
them is processed, then the most fatal status should be used in
the Result TLV returned.  If a status code in the Request-Action
TLV is not understood by the receiving entity, then it SHOULD <bcp14>SHOULD</bcp14> be
treated as a fatal error.  Otherwise, the receiving entity MAY <bcp14>MAY</bcp14> send a Request-Action TLV containing an Error TLV of value 2002 (Unexpected TLVs Exchanged).</t>
              <t>After
              <t indent="3">After processing the TLVs or inner method in the request, another
round of Result TLV exchange MUST <bcp14>MUST</bcp14> occur to synchronize the final
status on both sides.</t>
            </li>
          </ul>

          <t>The peer or the server MAY <bcp14>MAY</bcp14> send multiple Request-Action TLVs to the
other side.  Two Request-Action TLVs MUST NOT <bcp14>MUST NOT</bcp14> occur in the same TEAP
packet if they have the same Status value.  The order of processing
multiple Request-Action TLVs is implementation dependent.  If the
receiving side processes the optional (non-fatal) items first, it is
possible that the fatal items will disappear at a later time.  If the
receiving side processes the fatal items first, the communication
time will be shorter.</t>
          <t>The peer or the server MAY <bcp14>MAY</bcp14> return a new set of Request-Action TLVs
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>
          <t>The Request-Action TLV is defined as follows:</t>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Status   |      Action    |                TLVs....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>Mandatory,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-]]></artwork>

<dl spacing="normal" newline="true">
  <dt>M</dt>
  <dd>Mandatory, set to one (1)</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved, (1)</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>TLV Type</t>
          <ul empty="true">
            <li>
              <t>8 (0)</dd>
  <dt>TLV Type</dt>
  <dd>8 - Request-Action TLV</t>
            </li>
          </ul>
          <t>Length</t>
          <ul empty="true">
            <li>
              <t>2 TLV</dd>
  <dt>Length</dt>
  <dd>2 + cumulative length of all included TLVs</t>
            </li>
          </ul>
          <t>Status</t>
          <ul empty="true">
            <li>
              <t>The TLVs</dd>
  <dt>Status</dt>
  <dd><t>The Status field is one octet.  This indicates the result if the 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
  <dl spacing="normal" newline="false">
    <dt>1</dt><dd>Success</dd>
    <dt>2</dt><dd>Failure</dd>
  </dl>
  </dd>
  <dt>Action</dt>
  <dd><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
  <dl spacing="normal" newline="false">
    <dt>1</dt><dd>Process-TLV</dd>
    <dt>2</dt><dd>Negotiate-EAP</dd>
  </dl>
  </dd>
  <dt>TLVs</dt>
  <dd>This field is of indefinite length.  It contains TLVs that the peer
  wants the server to process.</t>
            </li>
          </ul> process.</dd>
</dl>
        </section>
        <section anchor="eap-payload-tlv">
          <name>EAP-Payload TLV</name>
<!-- DNE -->
          <t>To allow coalescing an EAP request or response with other TLVs, the
EAP-Payload TLV is defined, which includes an encapsulated EAP packet
and a list of optional TLVs.  The optional TLVs are provided for
future extensibility to provide hints about the current EAP
authentication.  Only one EAP-Payload TLV is allowed in a message.
The EAP-Payload TLV is defined as follows:</t>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          EAP packet...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>Mandatory,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<dl spacing="normal" newline="true">
  <dt>M</dt>
  <dd>Mandatory, set to one (1)</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved, (1)</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>TLV Type</t>
          <ul empty="true">
            <li>
              <t>9 (0)</dd>
  <dt>TLV Type</dt>
  <dd>9 - EAP-Payload TLV</t>
            </li>
          </ul>
          <t>Length</t>
          <ul empty="true">
            <li>
              <t>length TLV</dd>
  <dt>Length</dt>
  <dd>length of embedded EAP packet + cumulative length of additional
TLVs</t>
            </li>
          </ul>
          <t>EAP packet</t>
          <ul empty="true">
            <li>
              <t>This TLVs</dd>
  <dt>EAP packet</dt>
  <dd>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 packet.</dd>
  <dt>TLVs</dt>
  <dd>This (optional) field contains a list of TLVs associated with the EAP
  packet field.  The TLVs MUST NOT <bcp14>MUST NOT</bcp14> 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>
  field.</dd>
</dl>
<!-- end of DNE -->
        </section>
        <section anchor="intermediate-result-tlv">
          <name>Intermediate-Result TLV</name>
          <t>The Intermediate-Result TLV signals
intermediate Success and Failure messages for all inner
methods.  The Intermediate-Result TLV MUST be <bcp14>MUST</bcp14> be used for all inner methods.</t>
          <t>An Intermediate-Result TLV indicating Success
MUST success
<bcp14>MUST</bcp14> be accompanied by a Crypto-Binding TLV.</t>
          <t>An Intermediate-Result TLV indicating Failure SHOULD failure <bcp14>SHOULD</bcp14> be accompanied by an Error TLV which that indicates why the authentication failed.</t>
          <t>The optional TLVs
associated with this TLV are provided for future extensibility to
provide hints about the current result.  The Intermediate-Result TLV
is defined as follows:</t>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Status            |        TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>Mandatory,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<dl spacing="normal" newline="true">
  <dt>M</dt>
  <dd>Mandatory, set to one (1)</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved, (1)</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>TLV Type</t>
          <ul empty="true">
            <li>
              <t>10 (0)</dd>
  <dt>TLV Type</dt>
  <dd>10 - Intermediate-Result TLV</t>
            </li>
          </ul>
          <t>Length</t>
          <ul empty="true">
            <li>
              <t>2 TLV</dd>
  <dt>Length</dt>
  <dd>2 + cumulative length of the embedded associated TLVs</t>
            </li>
          </ul>
          <t>Status</t>
          <ul empty="true">
            <li> TLVs</dd>
  <dt>Status</dt>
  <dd>
    <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
    <dl newline="false" spacing="normal">
      <dt>1</dt><dd>Success</dd>
      <dt>2</dt><dd>Failure</dd>
    </dl>
  </dd>
  <dt>TLVs</dt>
  <dd>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
  <bcp14>MUST NOT</bcp14> have the mandatory bit set.</t>
            </li>
          </ul> set.</dd>
</dl>
        </section>
        <section anchor="pac-tlv">
          <name>PAC TLV</name>
          <t><xref target="RFC7170"/> defined a Protected Access Credential (PAC) to mirror
EAP-FAST <xref target="RFC4851"/>.  However, implementation experience and analysis
determined that the PAC was not necessary.  Instead, TEAP performs
session resumption using the NewSessionTicket message as defined in Sections
<xref section="2.1.2" sectionFormat="comma" sectionFormat="bare" target="RFC9190"/> and Section 2.1.3. <xref section="2.1.3" sectionFormat="bare" target="RFC9190"/> of <xref target="RFC9190"/>.  As such, the PAC TLV
has been deprecated.</t>
          <t>As the PAC TLV is deprecated, an entity receiving it SHOULD <bcp14>SHOULD</bcp14> send a
Result TLV indicating failure, failure and an Error TLV of Unexpected TLVs
Exchanged.</t>
        </section>
        <section anchor="crypto-binding-tlv">
          <name>Crypto-Binding TLV</name>
          <t>The Crypto-Binding TLV is used to prove that both the peer and server
participated in the tunnel establishment and sequence of
authentications.  It also provides verification of the TEAP type,
version negotiated, and Outer TLVs exchanged before the TLS tunnel
establishment.</t>
          <t>A Crypto-Binding MUST <bcp14>MUST</bcp14> be accompanied by an Intermediate-Result TLV
indicating Success.</t> success.</t>
          <t>The Crypto-Binding TLV MUST <bcp14>MUST</bcp14> be exchanged and validated before any
Intermediate-Result or Result TLV value is examined, regardless of
whether there is an inner method or not.  It MUST <bcp14>MUST</bcp14> be
included with the Intermediate-Result TLV to perform cryptographic
binding after each successful inner method in a sequence of inner
methods, before proceeding with another inner method.  If no MSK or
EMSK has been generated and a Crypto-Binding TLV is required required, then the
MSK Compound-MAC field contains the MAC using keys generated according
to <xref target="computing-compound-mac"/>.</t>
          <t>The Crypto-Binding TLV is valid only if the following checks pass on
its contents:</t>
          <ul spacing="normal">
            <li>
              <t>The Version field contain a known value,</t> value.</t>
            </li>
            <li>
              <t>The Received-Ver field matches the TEAP version sent by the receiver during the EAP version negotiation,</t> negotiation.</t>
            </li>
            <li>
              <t>The Sub-Type field is set to the correct value for this exchange,</t> exchange.</t>
            </li>
            <li>
              <t>The Flags field is set to a known value,</t> value.</t>
            </li>
            <li>
              <t>The Compound-MAC(s) verify correctly.</t>
            </li>
          </ul>
          <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
described in <xref target="phase-2-errors"/></t>
          <t>See <xref target="cryptographic-calculations"/> for a more detailed discussion of
how the Compound-MAC fields are constructed and verified.</t>
          <t>The Crypto-Binding TLV is defined as follows:</t>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Reserved   |    Version    |  Received-Ver.| Flags|Sub-Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                             Nonce                             ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                   EMSK Compound-MAC                           ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                    MSK Compound-MAC                           ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>Mandatory,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<dl spacing="normal" newline="true">
  <dt>M</dt>
  <dd>Mandatory, set to one (1)</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved, (1)</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>TLV Type</t>
          <ul empty="true">
            <li>
              <t>12 (0)</dd>
  <dt>TLV Type</dt>
  <dd>12 - Crypto-Binding TLV</t>
            </li>
          </ul>
          <t>Length</t>
          <ul empty="true">
            <li>
              <t>76</t>
            </li>
          </ul>
          <t>Reserved</t>
          <ul empty="true">
            <li>
              <t>Reserved, TLV</dd>
  <dt>Length</dt>
  <dd>76</dd>
  <dt>Reserved</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>Version</t>
          <ul empty="true">
            <li>
              <t>The (0)</dd>
  <dt>Version</dt>
  <dd>The Version field is a single octet, which is set to the version of
  Crypto-Binding TLV the TEAP method is using.  For an implementation
  compliant with TEAPv1, the version number MUST <bcp14>MUST</bcp14> be set to one (1).</t>
            </li>
          </ul>
          <t>Received-Ver</t>
          <ul empty="true">
            <li>
              <t>The
  (1).</dd>
  <dt>Received-Ver</dt>
  <dd><t>The Received-Ver field is a single octet and MUST <bcp14>MUST</bcp14> be set
  to the TEAP version number received during version negotiation.  Note that
  this field only provides protection against downgrade attacks, where a
  version of EAP requiring support for this TLV is required on both sides.</t>
  <t>For TEAPv1, this version number MUST <bcp14>MUST</bcp14> be set to one (1).</t>
            </li>
          </ul>
          <t>Flags</t>
          <ul empty="true">
            <li>
              <t>The
  </dd>
  <dt>Flags</dt>
  <dd><t>The Flags field is four bits.  Defined values include</t>
              <ul empty="true">
                <li>
                  <t>1  EMSK include:</t>
  <dl spacing="normal" newline="false">
    <dt>1</dt><dd>EMSK Compound-MAC is present</t>
                  <t>2  MSK present</dd>
    <dt>2</dt><dd>MSK Compound-MAC is present</t>
                  <t>3  Both present</dd>
    <dt>3</dt><dd>Both EMSK and MSK Compound-MAC are present</t> present</dd>
  </dl>
    <t>All other values of the Flags field are invalid.</t>
                </li>
              </ul>
            </li>
          </ul>
          <t>Sub-Type</t>
          <ul empty="true">
            <li>
              <t>The
  </dd>
  <dt>Sub-Type</dt>
  <dd><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> include:</t>
  <dl spacing="normal" newline="false">
    <dt>0</dt><dd>Binding Request</dd>
    <dt>1</dt><dd>Binding Response</dd>
  </dl>
  <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
  </dd>
  <dt>Nonce</dt>
  <dd>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 <bcp14>MUST</bcp14> have its least significant bit set to
  zero (0), and the nonce in a response MUST <bcp14>MUST</bcp14> have the same
  value as the request nonce except the least significant bit MUST
  <bcp14>MUST</bcp14> be set to one (1).</t>
            </li>
          </ul>
          <t>EMSK Compound-MAC</t>
          <ul empty="true">
            <li>
              <t>The (1).</dd>
  <dt>EMSK Compound-MAC</dt>
  <dd><t>The EMSK Compound-MAC field is 20 octets.  This can be the Server 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 <bcp14>MUST</bcp14> be
  done on the truncated value.</t>
            </li>
          </ul>
          <t>MSK Compound-MAC</t>
          <ul empty="true">
            <li>
              <t>The
  </dd>
  <dt>MSK Compound-MAC</dt>
  <dd><t>The MSK Compound-MAC field is 20 octets.  This can be the Server 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 <bcp14>MUST</bcp14> be
  done on the truncated value.</t>
            </li>
          </ul> value.</t></dd>
</dl>
        </section>
        <section anchor="bp-auth-req-tlv">
<!-- [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 server
to request a username and password from the peer.  It contains an
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>
          <t>The Basic-Password-Auth-Req TLV is defined as follows:</t>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Prompt ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>Mandatory,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<dl spacing="normal" newline="false">
  <dt>M</dt>
  <dd>Mandatory, set to one (1)</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved, (1)</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>TLV Type</t>
          <ul empty="true">
            <li>
              <t>13 (0)</dd>
  <dt>TLV Type</dt>
  <dd>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 TLV</dd>
  <dt>Length</dt>
  <dd>variable</dd>
  <dt>Prompt</dt>
  <dd>optional user prompt message in UTF-8 <xref target="RFC3629"/> format</t>
            </li>
          </ul> format</dd>
</dl>
        </section>
        <section anchor="bp-auth-resp-tlv">
          <name>Basic-Password-Auth-Resp TLV</name>
          <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
contains a username and password.  The username and password are in
UTF-8 <xref target="RFC3629"/> format.</t>
          <t>The Basic-Password-Auth-Resp TLV is defined as follows:</t>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Userlen     |             Username
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ...     Username    ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Passlen     |             Password
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ...     Password    ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>Mandatory,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

<dl spacing="normal" newline="false">
  <dt>M</dt>
  <dd>Mandatory, set to one (1)</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved, (1)</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>TLV Type</t>
          <ul empty="true">
            <li>
              <t>14 (0)</dd>
  <dt>TLV Type</dt>
  <dd>14 - Basic-Password-Auth-Resp TLV</t>
            </li>
          </ul>
          <t>Length</t>
          <ul empty="true">
            <li>
              <t>variable</t>
            </li>
          </ul>
          <t>Userlen</t>
          <ul empty="true">
            <li>
              <t>Length TLV</dd>
  <dt>Length</dt>
  <dd>variable</dd>
  <dt>Userlen</dt>
  <dd><t>Length of Username field in octets</t> octets.</t>
  <t>The value of Userlen MUST NOT <bcp14>MUST NOT</bcp14> be zero.</t>
            </li>
          </ul>
          <t>Username</t>
          <ul empty="true">
            <li>
              <t>Username zero.</t></dd>
  <dt>Username</dt>
  <dd><t>Username in UTF-8 <xref target="RFC3629"/> format</t> format.</t>
  <t>The content of Username SHOULD <bcp14>SHOULD</bcp14> follow the guidelines set
  in <xref section="3.1." section="3.1" sectionFormat="comma" target="RFC9427"/></t>
            </li>
          </ul>
          <t>Passlen</t>
          <ul empty="true">
            <li> target="RFC9427"/>.</t></dd>
  <dt>Passlen</dt>
  <dd>
    <t>Length of Password field in octets</t> octets.</t>
    <t>The value of Passlen MUST NOT <bcp14>MUST NOT</bcp14> be zero.</t>
            </li>
          </ul>
          <t>Password</t>
          <ul empty="true">
            <li>
  </dd>
  <dt>Password</dt>
  <dd>
    <t>Password in UTF-8 <xref target="RFC3629"/> format</t> 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>
  </dd>
</dl>
        </section>
        <section anchor="pkcs7-tlv">
          <name>PKCS#7 TLV</name>
          <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
in binary DER encoding <xref target="X.690"/> in a degenerate Certificates Only
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
peer, the EAP server MUST <bcp14>MUST</bcp14> send the PKCS#7 TLV inside a
Trusted-Server-Root TLV.  When used in response to a PKCS#10 certificate
enrollment request from the peer, the EAP server MUST <bcp14>MUST</bcp14> send the PKCS#7
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.
TEAP implementations that support the Trusted-Server-Root TLV or the
PKCS#10 TLV MUST <bcp14>MUST</bcp14> support this TLV.  Peers MUST NOT <bcp14>MUST NOT</bcp14> assume that the
certificates in a PKCS#7 TLV are in any order.</t>
          <t>TEAP servers MAY <bcp14>MAY</bcp14> return self-signed certificates.  Peers that handle
self-signed certificates or trust anchors MUST NOT <bcp14>MUST NOT</bcp14> implicitly trust
these certificates merely due to their presence in the certificate
bag.  Note: Peers are advised to take great care in deciding whether
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
level of authenticity to the certificates contained therein.  Peers
are advised to take into account the implied authority of the EAP
server and to constrain the trust it can achieve through the trust
anchor received in a PKCS#7 TLV.</t>
          <t>The PKCS#7 TLV is defined as follows:</t>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           PKCS#7 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-]]></artwork>

<dl spacing="normal" newline="false">
  <dt>M</dt>
  <dd>0 - Optional TLV</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved, TLV</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>TLV Type</t>
          <ul empty="true">
            <li>
              <t>15 (0)</dd>
  <dt>TLV Type</dt>
  <dd>15 - PKCS#7 TLV</t>
            </li>
          </ul>
          <t>Length</t>
          <ul empty="true">
            <li>
              <t>The TLV</dd>
  <dt>Length</dt>
  <dd>The length of the PKCS#7 Data field.</t>
            </li>
          </ul>
          <t>PKCS#7 Data</t>
          <ul empty="true">
            <li>
              <t>This field.</dd>
  <dt>PKCS#7 Data</dt>
  <dd>This field contains the DER-encoded X.509 certificate or certificate
  chain in a Certificates-Only PKCS#7 SignedData
message.</t>
            </li>
          </ul> message.</dd>
</dl>
        </section>
        <section anchor="pkcs10-tlv">
          <name>PKCS#10 TLV</name>
          <t>The PKCS#10 TLV is used by the peer to initiate the "simple "Simple PKI"
Request/Response from <xref target="RFC5272"/>.  The format of the request is as
specified in Section 6.4 of <xref target="RFC4945"/>. target="RFC4945" section="6.4"/>.  The PKCS#10 TLV is always
marked as optional, which cannot be responded to with a NAK TLV.</t>
          <t>The PKCS#10 TLV is defined as follows:</t>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           PKCS#10 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-]]></artwork>

<dl spacing="normal" newline="false">
  <dt>M</dt>
  <dd>0 - Optional TLV</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved, TLV</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>TLV Type</t>
          <ul empty="true">
            <li>
              <t>16 (0)</dd>
  <dt>TLV Type</dt>
  <dd>16 - PKCS#10 TLV</t>
            </li>
          </ul>
          <t>Length</t>
          <ul empty="true">
            <li>
              <t>The TLV</dd>
  <dt>Length</dt>
  <dd>The length of the PKCS#10 Data field.</t>
            </li>
          </ul>
          <t>PKCS#10 Data</t>
          <ul empty="true">
            <li>
              <t>This field.</dd>
  <dt>PKCS#10 Data</dt>
  <dd>This field contains the DER-encoded PKCS#10 certificate request.</t>
            </li>
          </ul> request.</dd>
</dl>
        </section>
        <section anchor="trusted-server-root-tlv">
          <name>Trusted-Server-Root TLV</name>
          <t>Trusted-Server-Root TLV facilitates the request and delivery of a
trusted server root certificate.  The Trusted-Server-Root TLV can be
exchanged in regular TEAP authentication mode or provisioning mode.
The Trusted-Server-Root TLV is always marked as optional and cannot
be responded to with a Negative Acknowledgment (NAK) NAK TLV.  The
Trusted-Server-Root TLV MUST <bcp14>MUST</bcp14> only be sent as an Inner TLV (inside the
protection of the tunnel).</t>
          <t>After the peer has determined that it has successfully authenticated
the EAP server and validated the Crypto-Binding TLV, it MAY <bcp14>MAY</bcp14> send one
or more Trusted-Server-Root TLVs (marked as optional) to request the
trusted server root certificates from the EAP server.  The EAP server
MAY
<bcp14>MAY</bcp14> send one or more root certificates with a Public Key
Cryptographic System #7 (PKCS#7) TLV inside the Trusted-Server-Root
TLV.  The EAP server MAY <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 the
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>
          <t>If the EAP server sets the credential format to
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
server packaged in a PKCS#7 TLV.  If the server certificate is a
self-signed certificate, then the root is the self-signed
certificate.</t>
          <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>
          <t>The Trusted-Server-Root TLV is defined as follows:</t>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Credential-Format   |     Cred TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-]]></artwork>

<dl spacing="normal" newline="false">
  <dt>M</dt>
  <dd>0 - Optional TLV</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved, TLV</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </li>
          </ul>
          <t>TLV Type</t>
          <ul empty="true">
            <li>
              <t>17 (0)</dd>
  <dt>TLV Type</dt>
  <dd>17 - Trusted-Server-Root TLV</t>
            </li>
          </ul>
          <t>Length</t>
          <ul empty="true">
            <li>
              <t>&gt;=2 octets</t>
            </li>
          </ul>
          <t>Credential-Format</t>
          <ul empty="true">
            <li> TLV</dd>
  <dt>Length</dt>
  <dd>&gt;=2 octets</dd>
  <dt>Credential-Format</dt>
  <dd>
    <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
  </dd>
  <dt>Cred TLVs</dt>
  <dd>This field is of indefinite length.  It contains TLVs associated with
  the credential format.  The peer may leave this field empty when using this
  TLV to request server trust roots.</t>
            </li>
          </ul> roots.</dd>
</dl>
        </section>
        <section anchor="csr-attributes-tlv">
          <name>CSR-Attributes TLV</name>
          <t>The CSR-Attributes TLV provides information from the server to 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"/>. target="RFC7030" section="4.5"/>.
Servers MAY <bcp14>MAY</bcp14> send the CSR-Attributes TLV directly after the TLS session has
been established.  A server MAY <bcp14>MAY</bcp14> also send in the same message a
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
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" sectionFormat="comma" target="RFC7030"/> with the
exception that the DER encoding MUST NOT <bcp14>MUST NOT</bcp14> be encoded in base64.  The base64 encoding is used in <xref target="RFC7030"/> because the transport protocol used there requires textual encoding.  In contrast, TEAP attributes can transport arbitrary binary data.</t>
          <t>Servers and peers MUST <bcp14>MUST</bcp14> follow the guidance provided in
<xref target="I-D.ietf-lamps-rfc7030-csrattrs"/> target="RFC9908"/> when creating the CSR-Attributes TLV. Peers MAY <bcp14>MAY</bcp14> ignore the contents
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>
          <t>The CSR-Attributes TLV is defined as follows:</t>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                DER Encoded CSR Attributes                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-]]></artwork>

<dl spacing="normal" newline="false">
  <dt>M</dt>
  <dd>0 - Optional TLV</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved, TLV</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </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> (0)</dd>
  <dt>TLV Type</dt>
  <dd>18 - CSR-Attributes</dd>
  <dt>Length</dt>
  <dd>&gt;=2 octets</dd>
</dl>
        </section>
        <section anchor="identity-hint-tlv">
          <name>Identity-Hint TLV</name>
          <t>The Identity-Hint TLV is an optional TLV which that can be sent by the peer to the server at the beginning of the Phase 2 TEAP conversation.  The purpose of the TLV is to provide a "hint" as to the identity or identities which that the peer will be using by subsequent inner methods.</t>
          <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 inner 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, method and then have the peer return a response indicating that the requested method is not available.  This negotiation increases the number of round trips required for TEAP to conclude, conclude with no additional benefit.</t>
          <t>When the Identity-Hint is used, the peer can signal which identities it has available, which enables the server to choose an inner method which that is appropriate for that identity.</t>
          <t>The peer SHOULD <bcp14>SHOULD</bcp14> send an Identity-Hint TLV for each Identity-Type which that is available to it.  For example, if the peer can do both Machine machine and User user authentication, it can send two Identity-Hint TLVs, TLVs with values "host/name.example.com" (for a machine with hostname "name.example.com"), "name.example.com") and "user@example.com" (for a person with identity "user@example.com").</t>
          <t>The contents of the Identity-Hint TLV SHOULD <bcp14>SHOULD</bcp14> be in the format of an NAI <xref target="RFC7542"/>, but we note that as given in the example above, Machine identities might not follow that format.  As these identities are never used for AAA routing as discussed in <xref section="3" sectionFormat="comma" target="RFC7542"/>, the format and definition of these identities are entirely site local.  Robust implementations MUST <bcp14>MUST</bcp14> support arbitrary data in the content of this TLV, including binary octets.</t>
          <t>As the Identity-Hint TLV is a "hint", server implementations are free to ignore the hints given, given and do whatever is required by site-local policies.</t>
          <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 <bcp14>MUST NOT</bcp14> be used for any other purpose.  Specifically.  Specifically, server implementations MUST NOT <bcp14>MUST NOT</bcp14> compare the identities given this TLV to later identities given as part of the inner methods.  There is no issue with the hint(s) failing to match any subsequent identity which that is used.</t>
          <t>The Identity-Hint TLV MUST NOT <bcp14>MUST NOT</bcp14> be used for Server Unauthenticated Provisioning. server unauthenticated provisioning.  This TLV is only used as a hint for normal authentication.</t>
          <t>The Identity-Hint TLV is defined as follows:</t>
          <artwork><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Identity Hint                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork>
          <t>M</t>
          <ul empty="true">
            <li>
              <t>0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-]]></artwork>

<dl spacing="normal" newline="false">
  <dt>M</dt>
  <dd>0 - Optional TLV</t>
            </li>
          </ul>
          <t>R</t>
          <ul empty="true">
            <li>
              <t>Reserved, TLV</dd>
  <dt>R</dt>
  <dd>Reserved, set to zero (0)</t>
            </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> (0)</dd>
  <dt>TLV Type</dt>
  <dd>19 - Identity-Hint</dd>
  <dt>Length</dt>
  <dd>&gt;=2 octets</dd>
</dl>
        </section>
      </section>
      <section anchor="tlv-rules">
        <name>TLV Rules</name>
        <t>To save round trips, multiple TLVs can be sent in a single TEAP
packet.  However, multiple EAP Payload TLVs, multiple Basic Password
Authentication TLVs, or an EAP Payload TLV with a Basic Password
Authentication TLV within one single TEAP packet is not supported in
this version and MUST NOT <bcp14>MUST NOT</bcp14> be sent.  If the peer or EAP server
receives multiple EAP Payload TLVs, then it MUST <bcp14>MUST</bcp14> terminate the
connection with the Result TLV.  The order in which TLVs are encoded in a TEAP packet does not
matter, however
matter. However, there is an order in which TLVs in a packet must be processed:</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>
            <t>Crypto-Binding TLV</t>
          </li>
          <li>
            <t>Intermediate-Result TLV</t>
          </li>
          <li>
            <t>Result TLV or Request-Action TLV</t>
          </li>
          <li>
            <t>Identity-Type TLV</t>
          </li>
          <li>
            <t>EAP-Payload TLV[Identity-Request] TLV (Identity-Request) or Basic-Password-Auth-Req TLV</t>
          </li>
          <li>
            <t>Other TLVs</t>
          </li>
        </ol>
        <t>That is, cryptographic binding is checked before any result is used, used
and identities are checked before proposing an inner method, as the
identity may influence the chosen inner method.</t>
        <t>The following define the meaning of the table entries in the sections
below:</t>
        <artwork><![CDATA[
0
<dl spacing="normal" newline="false">
  <dt>0</dt><dd> This TLV MUST NOT <bcp14>MUST NOT</bcp14> be present in the message.

0+
  message.</dd>

  <dt>0+</dt><dd> Zero or more instances of this TLV MAY <bcp14>MAY</bcp14> be
  present in the
      message.

0-1   Zero message.</dd>

  <dt>0-1</dt><dd>Zero or one instance of this TLV MAY <bcp14>MAY</bcp14> be present in the message.

1     Exactly message.</dd>

  <dt>1</dt><dd>Exactly one instance of this TLV MUST <bcp14>MUST</bcp14> be
  present in the
      message.
]]></artwork> message.</dd>
</dl>
        <section anchor="outer-tlvs">
          <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
the TEAP packet outside the TLS channel, which kind of packets, and
in what quantity:</t>
          <artwork><![CDATA[
Request  Response    Success   Failure   TLVs
0-1      0           0         0         Authority-ID
0-1      0-1         0         0         Identity-Type
0+       0+          0         0         Vendor-Specific
]]></artwork>
<table>
  <thead>
    <tr>
      <th>Request</th><th>Response</th><th>Success</th><th>Failure</th><th>TLVs</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <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 MUST <bcp14>MUST</bcp14> be marked as optional.  Vendor TLVs inside of a
Vendor-Specific TLV MUST <bcp14>MUST</bcp14> be marked as optional when included in Outer TLVs.
Outer TLVs MUST NOT <bcp14>MUST NOT</bcp14> be included in messages after the first two TEAP
messages sent by peer and EAP-server EAP-server, respectively.  That is is, the first
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
one message.  If Outer TLVs are included in messages after the first
two TEAP messages, they MUST <bcp14>MUST</bcp14> be ignored.</t>
        </section>
        <section anchor="inner-tlvs">
          <name>Inner TLVs</name>
          <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
what quantity.  The messages are as follows: Request is a TEAP
Request, Response is a TEAP Response, Success is a message containing
a successful Result TLV, and Failure is a message containing a failed
Result TLV.</t>
          <artwork><![CDATA[
Request  Response    Success   Failure   TLVs
0-1      0-1         0         0         Identity-Type
0-1      0-1         1         1         Result
0+       0+          0         0         NAK
0+       0+          0+        0+        Error
0-1      0-1         0         0         Channel-Binding
0+       0+          0+        0+        Vendor-Specific
0+       0+          0+        0+        Request-Action
0-1      0-1         0         0         EAP-Payload
0-1      0-1         0-1       0-1       Intermediate-Result
0-1      0-1         0-1       0-1       Crypto-Binding
0-1      0           0         0         Basic-Password-Auth-Req
0        0-1         0         0         Basic-Password-Auth-Resp
0-1      0           0-1       0         PKCS#7
0        0-1         0         0         PKCS#10
0-1      0-1         0-1       0         Trusted-Server-Root
0-1      0           0         0         CSR-Attributes TLV
0        0+          0         0         Identity-Hint TLV
]]></artwork>

<table>
  <thead>
    <tr><th>Request</th><th>Response</th><th>Success</th><th>Failure</th><th>TLVs</th></tr>
  </thead>
<tbody>
<tr><td>0-1</td>      <td>0-1</td>         <td>0</td>         <td>0</td>         <td>Identity-Type</td></tr>
<tr><td>0-1</td>      <td>0-1</td>         <td>1</td>         <td>1</td>         <td>Result</td></tr>
<tr><td>0+</td>       <td>0+</td>          <td>0</td>         <td>0</td>         <td>NAK</td></tr>
<tr><td>0+</td>       <td>0+</td>          <td>0+</td>        <td>0+</td>        <td>Error</td></tr>
<tr><td>0-1</td>      <td>0-1</td>         <td>0</td>         <td>0</td>         <td>Channel-Binding</td></tr>
<tr><td>0+</td>       <td>0+</td>          <td>0+</td>        <td>0+</td>        <td>Vendor-Specific</td></tr>
<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
Result TLV MUST <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
in this table.</t>
        </section>
      </section>
    </section>
    <section anchor="limitations">
      <name>Limitations of TEAPv1</name>
      <t>As noted in <xref target="interoperability"/>, TEAPv1 implementations are limited
in functionality as compared to what the protocol is theoretically
capable of.  These limitations mean that only a small number of inner
methods are fully supported by existing TEAPv1 implementations.</t>
      <t>While <xref target="cryptographic-calculations"/>, below, target="cryptographic-calculations"/> defines the
cryptographic calculations used for key derivation and crypto-binding,
this section documents which inner methods are known to work, work and why
those methods work.  Other inner methods may work, but those results
are likely to be implementation-specific.</t>
      <t>We discuss the issues here without naming particular implementations
or making any negative inference about them.  The implementations work
well enough together in limited situations.  Any interoperability
issues are due to the complexity and incompleteness of the definitions
given in <xref target="RFC7170"/>, target="RFC7170"/> and are not due to issues with any particular
implementation.</t>
      <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.
In short, implementations are known to derive different values for the
Compound-MAC(s) when more than one inner methods method provides an EMSK.</t>
      <section anchor="interoperable-inner-methods">
        <name>Interoperable Inner Methods</name>
        <t>The following inner methods are known to work.  These methods work for
both User and Machine credentials.</t>
        <ul spacing="normal">
          <li>
            <t>EAP-MSCHAPv2</t>
          </li>
          <li>
            <t>EAP-TLS</t>
          </li>
        </ul>
        <t>The following combinations of inner methods are known to work.  These
methods work for any order of User and Machine credentials.</t>
        <ul spacing="normal">
          <li>
            <t>EAP-MSCHAPv2 followed by EAP-MSCHAPv2</t>
          </li>
          <li>
            <t>EAP-TLS followed by EAP-MSCHAPv2</t>
          </li>
        </ul>
        <t>The following combinations of inner methods are known to work when
both the supplicant and authenticator ignore the EMSK Compound-MAC field
of the Crypto-Binding TLV.  These methods work for any order of User
and Machine credentials .</t> credentials.</t>
        <ul spacing="normal">
          <li>
            <t>EAP-MSCHAPv2 followed by EAP-TLS</t>
          </li>
          <li>
            <t>EAP-TLS followed by EAP-TLS</t>
          </li>
        </ul>
      </section>
      <section anchor="explanation-and-background">
        <name>Explanation and Background</name>
        <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
the inner methods.  Further, this implementation does not encode the
EMSK Compound-MAC field in all of the Crypto-Binding TLVs that it
sends,
sends and ignores that field in all of the Crypto-Binding TLVs that
it receives.</t>
        <t>The
<!-- [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
due to both the complexity of the cryptographic derivations and the
lack of interoperability testing, each authenticator implemented
entirely different derivations of the EMSK Compound-MAC field of the
Crypto-Binding TLV.  This difference was discovered only after
multiple implementations had been shipping for years.</t>
      </section>
      <section anchor="next-steps">
        <name>Next Steps</name>
        <t>Any attempt to change TEAPv1 to address these issues would likely
result in one or more implementations being non-compliant with the
updated specification.  Even worse, updates to this specification
would result in multiple incompatible versions of TEAPv1.</t>
        <t>That approach is not acceptable.</t>
        <t>In the interest of maintaining known interoperability, this
specification simply documents these issues rather than trying to
correct the problem.  Since the TEAP protocol and the Crypto-Binding
TLV both contain a version Version field, the better path forward is to
publish this specification while documenting the large caveats for
TEAPv1.  Any changes to the TEAP protocol can then be done in a future
TEAPv2 specification.</t>
      </section>
    </section>
    <section anchor="cryptographic-calculations">
      <name>Cryptographic Calculations</name>
      <t>The definitions given in this section are known to work with all
implementations,
implementations but ony only for a few inner methods, as described above
in <xref target="limitations"/>.  In the interest of avoiding additional
complexity in an already complex process, those definitions are given
as if they work for all possible inner methods.</t>
      <t>We note that some interoperable implementations have been written
based on these definitions, which support inner methods other than
EAP-MSCHAPv2 and EAP-TLS.  It is therefore useful to document the full
operation of TEAPv1, TEAPv1 despite the known issues.  We only caution
implemnters
implementors that inner methods which that are not listed in above in
<xref target="limitations"/> are likly likely to work with only a subset of existing
TEAPv1 implementations.</t>
      <t>For key derivation and crypto-binding, TEAP uses the Pseudorandom
Function (PRF) and MAC algorithms negotiated in the underlying TLS
session.  Since these algorithms depend on the TLS version and
cipher suite, TEAP implementations need a mechanism to determine the
version and cipher suite in use for a particular session.  The
implementation can then use this information to determine which PRF
and MAC algorithm to use.</t>
      <section anchor="key-derivations">
        <name>TEAP Authentication Phase 1: Key Derivations</name>
        <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 in
<xref target="RFC5077"/>.</t>
        <t>TEAPv1 makes use of the TLS Keying Material Exporters defined in
<xref target="RFC5705"/> to derive the session_key_seed as follows:</t>
        <artwork><![CDATA[
   session_key_seed = TLS-Exporter(
                      "EXPORTER: teap session key seed",, 40)
]]></artwork> 40)]]></artwork>
        <t>No context data is used in the export process.</t>
        <t>The session_key_seed is used by the TEAP authentication Phase 2
conversation to both cryptographically bind the inner method(s) to
the tunnel as well as generate the resulting TEAP session keys.  The
other TLS keying materials are derived and used as defined in
<xref target="RFC5246"/>.</t>
      </section>
      <section anchor="intermediate-compound-key">
        <name>Intermediate Compound Key Derivations</name>
        <t>As TEAP can run multiple inner methods, there needs to be a way to
cryptographically bind each inner method to the TLS tunnel, tunnel and to
cryptographically bind each method to the previous one.  This binding
is done by deriving a number of intermediate keys, keys and exchanging that
information in the Crypto-Binding TLV.</t>
        <t>The key derivation is complicated by a number of factors.  An inner
method can derive MSK, an MSK or (as with basic passwords) not derive an MSK.
An inner method can derive an EMSK, EMSK or perhaps not derive an EMSK, or
some EAP types may derive different EMSKs for the peer and the server.
All of these cases must be accounted for, for and have recommendations made for
how peers and servers can interoperate.</t>
        <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
clarify the detailed definitions and deriviations derivations given below.  As
each inner method can derive an MSK (or not), not) and can derive an EMSK (or
not), there need to be separate intermediate key calculations for MSK
and for EMSK.  For the purposes of this overview, we just describe the
derivations at a high level, level and state that the MSK/EMSK issue is
addressed in the more detailed text below.</t>
        <t>For each inner method, we derive an Inner Method Session Key (IMSK). IMSK.
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
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
negotiation to create Compound-MAC field of the Crypto-Binding
attribute.  This TLV cryptographically binds the inner method to the
protected tunnel, tunnel and to the other fields which that have been negotiated.
The cryptographic binding prevents on-path attacks.</t>
        <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
derived above, to yield a Secure ICMK IMCK (S-IMCK) for this round.  The
S-IMCK from the final is then used to derive the MSK and EMSK for
TEAP.</t>
        <t>We differentiate keys for inner methods by counting inner methods
starting from 0, 0 and use an index "j" to refer to an arbitrary inner
method.  e.g. 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
j=0,1), further updates could allow for more inner method exchanges.</t>
        <section anchor="generating-the-inner-method-session-key">
          <name>Generating the Inner Method Session Key</name>
          <t>Each inner method generates an Inner Method Session Key (IMSK) which IMSK that 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>
          <t>If an inner method supports export of an Extended Master Session Key
(EMSK), EMSK, then the IMSK SHOULD <bcp14>SHOULD</bcp14> be derived from the EMSK EMSK, which is defined in
<xref target="RFC5295"/>.  The optional data parameter is not used in the derivation.</t>
          <t>The above derivation is not a requirement, as some peer
implementations of TEAP are also known to not derive IMSK from EMSK, EMSK
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>
          <t>Some EAP methods may also have the peer and server derive different
EMSKs.  Mandating an EMSK-based derivation there would prevent
interoperability, as the Crypto-Binding TLV contents which that depend on
EMSK could not then be validated by either side.  Those methods SHOULD
NOT <bcp14>SHOULD
NOT</bcp14> derive IMSK from EMSK unless the method has a way to negotiate how
the EMSK is derived, along with a way to signal that both the peer and server
have derived the same EMSK.</t>
          <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that for those EAP methods, implementations take the
simpler approach of ignoring EMSK, EMSK and always derive IMSK from MSK.
This approach is less secure, as IMSK no longer cryptographically
binds the inner method to the TLS tunnel.  A better solution is to
suggest that deployments of TEAP SHOULD <bcp14>SHOULD</bcp14> avoid such methods.</t>
          <t>The derivation of IMSK[j] from the j'th EMSK is given as follows:</t>
          <artwork><![CDATA[
   IMSK[j] = First 32 octets of TLS-PRF(
          EMSK[j],
          "TEAPbindkey@ietf.org",
          0x00 | 0x00 | 0x40)
]]></artwork> 0x40)]]></artwork>

          <t>Where:</t>
	  <ul empty="true">
            <li>
              <t>where "|" spacing="normal">
	    <li>"|" denotes concatenation and the concatenation</li>
	    <li><t>The TLS-PRF is defined in <xref target="RFC5246"/> as:</t>
              <artwork><![CDATA[
   PRF(secret, label, seed) = P_<hash>(secret, label | seed)
]]></artwork>
              <t>The seed)]]></artwork></li>
              <li>The secret is the EMSK from the j'th inner method, the usage label used is
"TEAPbindkey@ietf.org" consisting of the ASCII value for the
label "TEAPbindkey@ietf.org" (without quotes), and the seed
consists of the "\0" null delimiter (0x00) and 2-octet unsigned
integer length of 64 octets in network byte order (0x00 | 0x40) specified
in <xref target="RFC5295"/>.</t>
            </li> target="RFC5295"/>.</li>
          </ul>

          <t>If an inner method does not support the export of EMSK but does export
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
octets,
octets and the rest of MSK is ignored.  If the MSK is shorter than 32
octets, then the ISMK is copied from MSK, MSK and the remaining data in
IMSK is padded with zeros to a length of 32 octets.  IMSK[j] is then
this derived value.</t>
          <t>If the inner method does not provide either MSK or EMSK, such as when
basic password authentication is used or when no inner method has been
run,then
run, then both MSK and IMSK[j] are set to all zeroes (i.e., IMSK[j] =
MSK = 32 octets of 0x00s).</t>
          <t>Note that using an MSK of all zeroes opens up TEAP to on-path
attacks,
attacks as discussed below in {#separation-p1-p2}. <xref target="separation-p1-p2"/>.  It is therefore
NOT RECOMMENDED
<bcp14>NOT RECOMMENDED</bcp14> to use inner methods which that fail to generate an MSK or
EMSK.  These methods should only be used in conjunction with another
inner method which that does provide for MSK or EMSK generation.</t>
          <t>It is also RECOMMENDED <bcp14>RECOMMENDED</bcp14> that TEAP peers order inner methods such that
methods which that  generate EMSKs are performed before methods which that do not
generate EMSKs.  Ordering inner methods in this manner ensures that
the first inner method detects any on-path attackers, and any
subsequent inner method used is therefore secure.</t>
          <t>For example, Phase 2 could perform both Machine machine authentication using
EAP-TLS, followed by User user authentication via the Basic Password
Authentication TLVs.  In that case, the use of EAP-TLS would allow an
attacker to be detected before the users' password was sent.</t>
          <t>However, it is possible that the peer and server sides might not have
the same capability to export EMSK.  In order to maintain maximum
flexibility while prevent downgrading attack, the following mechanism
is in place.</t>
        </section>
        <section anchor="generating-s-imck">
          <name>Generating S-IMCK</name>
          <t>Once IMSK[j] has been determined, it is mixed via the TLS-PRF with
the key S-IMCK[j-1], 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
this round, round and CMK[j] for this round.</t>
          <t>The derivation of S-IMCK is as follows:</t>
          <artwork><![CDATA[
   S-IMCK[0] = session_key_seed
   For j = 1 to n-1 do
        IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1],
             "Inner Methods Compound Keys",
             IMSK[j])
        S-IMCK[j] = first 40 octets of IMCK[j]
        CMK[j] = last 20 octets of IMCK[j]
]]></artwork> IMCK[j]]]></artwork>
          <t>where TLS-PRF is the PRF described above (described above) negotiated as
part of TLS handshake <xref target="RFC5246"/>.  The value j refers to a
corresponding inner method 1 through n.  The special value of
S-IMCK[0] is used to bootstrap the calculations, calculations and can be done as
soon as the TLS connection is established, established and before any inner
methods are run.</t>
          <t>In
<!-- [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 an
implement <bcp14>MUST</bcp14> track two independent derivations of IMCK[j], one that
depends on the MSK, and another that depends on EMSK.  That is, we
have both values derived from MSK:</t>
          <artwork><![CDATA[
   IMSK_MSK[j]
   S-IMCK_MSK[j]
   CMK_MSK[j]
]]></artwork>
<ul spacing="normal">
  <li>IMSK_MSK[j]</li>
  <li>S-IMCK_MSK[j]</li>
  <li>CMK_MSK[j]</li>
</ul>
          <t>and then also values derived from EMSK:</t>
          <artwork><![CDATA[
   IMSK_EMSK[j]
   S-IMCK_EMSK[j]
   CMK_EMSK[j]
]]></artwork>
<ul spacing="normal">
  <li>IMSK_EMSK[j]</li>
  <li>S-IMCK_EMSK[j]</li>
  <li>CMK_EMSK[j]</li>
</ul>
          <t>At the conclusion of a successfully successful exchange of Crypto-Binding TLVs, a
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
was included, S-IMCK[j] is taken from S-IMCK_EMSK[j].  Otherwise,
S-IMCK[j] is taken from S-IMCK_MSK[j].</t>
        </section>
        <section anchor="choosing-inner-methods">
          <name>Choosing Inner Methods Securely</name>
          <t>In order to further secure TEAP, implementations can take steps to
increase their security by carefully ordering inner methods.  Where
multiple inner methods are used, implementations SHOULD <bcp14>SHOULD</bcp14> choose an
ordering so that the first inner method used is one which that derives
EMSK.</t>
          <t>For an EAP server, it can select the first inner method to be one
which
that derives EMSK. Since ordering of inner methods is not otherwise
important in EAP, any chosen order is supported by the peer which that
receives this request.</t>
          <t>For an EAP peer, it can choose its response to a servers server's request for
a particular type of of authentication.  The peer can ignore that
request,
request and return an inner method which that derives EMSK.  Again, since
the ordering of inner methods is not otherwise important in EAP, any
chosen order is supported by the server which that receives this response.
Once the more secure authentication has succeed, the server then
requests the other type of authentication and the peer can respond
with the chosen type of authentication.</t>
          <t>Implementations can also provide configuration flags, policies policies, or
documentated
documented recommendations which that control the type of inner methods
used or verify their order.  These configurations allow
implementations and administrators to control their security exposure
to on-path attackers.</t>
          <t>Impementations
          <t>Implementations can permit administators administrators to confgure configure TEAP so that the
following security checks are enforced:</t>
          <ul spacing="normal">
            <li>
              <t>verifying
              <t>Verifying that the first inner method used is one which that derives EMSK.
If this is not done, a fatal error can be returned,</t> returned.</t>
            </li>
            <li>
              <t>verifying
              <t>Verifying that if any inner method derives EMSK, that the received
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
fatal error can be returned.</t>
            </li>
          </ul>
          <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
these suggestions are not enforced, then the TEAP session is
vulnerable.</t>
          <t>Most of these suggestions are not normative, as some existing
implementations are known to not follow them.  Instead, these
suggestions are here to inform new implementers, implementors, along with
administrators, of the issues surrounding this subject.</t>
        </section>
        <section anchor="managing-and-computing-crypto-binding">
          <name>Managing and Computing Crypto-Binding</name>
          <t>After an inner method has been completed successfully and the inner
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
TLV.</t>
          <t>The peer verifies the Crypto-Binding TLV by applying the rules defined
in <xref target="crypto-binding-tlv"/>.  If verification passes, the peer responds
with its own Crypto-Binding TLV, which the server in turn verifies.
If at any point verification fails, the party which that makes this
determination terminates the session.</t>
          <t>The Crypto-Binding TLV is normally sent in conjunction with other TLVs
which that indicate intermediate results, or final results, results or which that begin
negotiation of a new inner method. This negotation negotiation does not otherwise
affect the Crypto-Binding TLV.</t>
          <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
and management of those fields.  This derivation is complex, complex and
is therefore located here, here along with the other key deriviations.</t> derivations.</t>
          <t>The following text defines how the server and peer compute, send, and
then verify the Compound-MAC fields Crypto-Binding TLV.  Depending on
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
Compound-MAC (Flags=2), or it can contain both Compound-MACs
(Flags=3).  Each party to the TEAP session follows its own set of
procedures to compute and verify the Compound-MAC fields.</t>
          <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
a Compound-MAC fails, the determining party returns a fatal error as
	  described in <xref target="phase-2-errors"/>.</t>
          <t>We

<!--[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
Compound-MAC.  These policies can be enforced globally for all inner
methods, or they can be enforced separately on each inner method.
These policies could be enabled automatically when the EAP method is
known to always generate an EMSK, EMSK and could otherwise be configurable.</t>
          <t>The server initiates crypto binding by determining which
Compound-MAC(s) to use, computing their value(s), placing the
resulting Compond-MAC(s) Compound-MAC(s) into the Crypto-Binding TLV, and then sending
it to the peer.</t>
          <t>The
          <t>Then, the steps taken by the server are then as follows.</t> follows:</t>
          <ul empty="true">
            <li>
              <t>If spacing="normal">
            <li><t>If the inner method is known to generate only MSK, or if
            the servers server's policy is to not use EMSK Compound-MACs:</t>
              <ul empty="true">
                <li>
                  <t>The spacing="normal">
                <li>The server computes the MSK Compound-MAC using the MSK
                of the inner method.  The server does not use the EMSK
                Compound-MAC field.
(Flags=2)</t>
                </li> field (Flags=2).</li>
              </ul>
              <t>Otherwise
              <t>Otherwise, the EMSK is available.</t>
              <t>If available.</t></li>
            <li><t>If the servers server's policy permits the use of the MSK Compound-MAC:</t>
              <ul empty="true">
                <li>
                  <t>The spacing="normal">
                <li>The sender computes the MSK Compound-MAC along with
                the EMSK
Compound-MAC. (Flags=3).</t>
                </li> Compound-MAC (Flags=3).</li>
              </ul>
              <t>Otherwise
              <t>Otherwise, the servers server's policy does not allow the use of the
              MSK Compound-MAC:</t>
              <t>The
	      <ul spacing="normal">
		<li>The server computes only the EMSK Compound-MAC (Flags=1).</t> (Flags=1).</li>
              </ul>
	    </li>
	  </ul>
          <t>The peer verifies the Crypto-Binding TLV it receives from the server.
It then replies with its own crypto binding response by determining
which Compound-MAC(s) to use, computing their value(s), placing the
resulting Compond-MAC(s) 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, error
or one or more Compound-MACs which that are placed in the Crypto-Binding
TLV,
TLV and sent to the server.</t>
          <t>The
          <t>Then, the steps taken by the peer are then as follows.</t> follows:</t>
          <ul empty="true">
            <li>
              <t>If spacing="normal">
            <li><t>If the peer site policy requires the use of the EMSK
            Compound-MAC:</t>
              <ul empty="true">
                <li>
                  <t>The spacing="normal">
                <li>The peer 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 peer returns a fatal error.</t>
                  <t>The error.</li>
                <li>The peer checks if the inner method has derived an EMSK.
                If not, the peer returns a fatal error.</t>
                </li> error.</li>
              </ul>
              <t>Otherwise
            <t>Otherwise, the peer site policy does not require the use of the
            EMSK
Compound-MAC, Compound-MAC and the EMSK may or may not exist.</t>
              <t>If exist.</t></li>
            <li><t>If the inner method is known to generate only MSK and not EMSK:
&gt;
&gt; The EMSK:</t>
              <ul spacing="normal">
		<li>The peer checks if the Flags field indicates that only the
		MSK
&gt; Compound-MAC exists (Flags=2).  If the Flags field has any
		other
&gt; value, the peer returns a fatal error.</t>
              <t>Otherwise error.</li>
	      </ul>
              <t>Otherwise, the MSK exists, the EMSK may or may not exist, and
              the peer allows the use of the EMSK Compound-MAC.  The peer may
              have received one or two Compound-MACs (Flags=1,2,3).  Any
              Compound-MAC
which that is present is verified.  No futher action is
              taken by the peer if a particular Compound-MAC is not present.
              No further action is taken by the peer if an unexpected
              Compound-MAC is present.</t>
              <t>Note that due to earlier validation of the Flags field (<xref
              target="crypto-binding-tlv"/>), at least one Compound-MAC must
              now exist.
(Flags=1,2,3)</t>
              <t>If exist (Flags=1,2,3).</t></li>
              <li>If the peer has received an MSK Compound-MAC, it verifies
              it and returns a fatal error if verification fails.</t>
              <t>If fails.</li>
              <li>If EMSK is available, available and the peer has received an EMSK
              Compound-MAC, it verifies it and returns a fatal error if
              verification fails.</t>
            </li> fails.</li>
          </ul>
          <t>The peer creates a crypto binding response by determining which
Compound-MAC(s) to use, computing their value(s), placing the
resulting Compond-MAC(s) Compound-MAC(s) into the Crypto-Binding TLV, and then sending
it to the server.</t>
          <t>The steps taken by the peer are then as follows.</t>
          <ul empty="true">
            <li>
              <t>If spacing="normal">
            <li><t>If the peer received an MSK Compound-MAC from the
            server:</t>
              <ul empty="true">
                <li>
                  <t>Since spacing="normal">
                <li>Since the MSK always exists, this step is always
                possible. The peer computes the MSK Compound-MAC for the response.  (Flags=2)</t>
                </li>
                response (Flags=2).</li>
              </ul>
              <t>If
	    </li>
            <li><t>If the peers peer site policy requires the use of the EMSK Compound-MAC,</t> Compound-MAC:</t>
              <ul empty="true">
                <li>
                  <t>The spacing="normal">
                <li>The preceding steps taken by the peer ensures that the
                EMSK exists, 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> updated (Flags=1,3).</li>
              </ul>
              <t>Otherwise
              <t>Otherwise, if the EMSK exists:</t>
              <ul empty="true">
                <li>
                  <t>The spacing="normal">
                <li>The peer computes the EMSK Compound-MAC for the
                response. The Flags field is updated. (Flags=1,3)</t>
                </li>
              </ul>
            </li> updated (Flags=1,3).</li>
              </ul>
            </li></ul>
            <t>The server processes the response from the peer via the following steps:</t>
            <ul empty="true">
            <li>
              <t>If spacing="normal">
              <li><t>If the server site policy requires the use of the EMSK Compound-MAC:</t>
              <ul empty="true">
                <li>
                  <t>The spacing="normal">
                <li>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
                error.</li>
                <li>The server checks if the inner method has derived an EMSK.
                If not, the server returns a fatal error.</t>
                </li>
              </ul>
              <t>If error.</li>
              </ul></li>
              <li><t>If the inner method is known to generate only MSK and not EMSK:
&gt;
&gt; The EMSK:</t>
	      <ul spacing="normal">
		<li>The server checks if the Flags field indicates that only
		the MSK
&gt; Compound-MAC exists (Flags=2).  If the Flags field has
		any other
&gt; value, the server returns a fatal error.</t>
              <t>Otherwise error.</li>
	      </ul>
	      <t>Otherwise, the MSK exists, 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 which 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>
              <t>If present.</t></li>
              <li>If the server has received an MSK Compound-MAC, it verifies
              it and returns a fatal error if verification fails.</t>
              <t>If fails.</li>
              <li>If EMSK is available, available and the server has received an EMSK
              Compound-MAC, it verifies it and returns a fatal error if
              verification fails.</t>
            </li> fails.</li>
          </ul>
          <t>Once the above steps have concluded, the server either continues
authentication with another inner method, method or it returns a Result TLV.</t>
        </section>
        <section anchor="oops">
          <name>Unintended Side Effects</name>
          <t>In earlier drafts of this document, the descriptions of the key
derivations had issues which that were only discovered after TEAP had been
widely implemented.  These issues need to be documented in order to
enable interoparable interoperable implementations.</t>
          <t>As noted above, some inner EAP methods derive MSK, MSK but do not 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
then to simply define:</t>
          <artwork><![CDATA[
    IMCK_EMSK[j] = IMCK_EMSK[j - 1]
]]></artwork> 1]]]></artwork>
          <t>This definition can be trivially implementation implemented by simply keeping a
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
above.  If EMSK is not available, then the IMCK_EMSK value is
unmodified.</t>
          <t>This behavior was not explicitly anticipated by earlier drafts of this
document.  It instead appears to be an accidental outcome of
implementing the derivations above, above with the limitiation limitation of a missing
EMSK.  This behavior is explicitly called out here in the interest of
fully documenting TEAP.</t>
          <t>Another unintended consequence is in the calculation of the
Crypto-Binding TLV.  That TLV includes compound MACs which that depend on
the MSK and EMSK of the current authentication method.  Where the
current method does not provide an EMSK, the Crypto-Binding TLV does
not include a compound MAC which that depends on the EMSK.  Where the
current method does not provide an MSK, the Crypto-Binding TLV
includes a compound MAC which that depends on a special "all zero" IMSK as
discussed earlier.</t>
          <t>The result of this definition is that the final Crypto-Binding TLV in
an inner TEAP exchange may not include a compond compound MAC which that depends on
EMSK, even if earlier EAP methods in the phase Phase 2 exchange provided an
ESMK.
EMSK.  This result likely has negative affects effects on security, though the
	  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 interoperable
implementations.  We note that these implementations seem to support
only EAP-TLS and the EAP-FAST-MSCHAPv2 variant of EAP-MSCHAPv2.  Other
inner EAP methods may work by accident, accident but are not likely to work by
design.  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.</t>
          <t>We expect that these issues will be addressed in a future revision of
TEAP.</t>
        </section>
      </section>
      <section anchor="computing-compound-mac">
        <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
protection against on-path attacks is provided through
cryptographically binding keying material established by both TEAP
Phase 1 and TEAP Phase 2 conversations.  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).  The CMK is used to calculate the Compound-MAC as
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
communications in TEAP.  During the calculation of the Compound-MAC,
the MAC field is filled with zeros.</t>
        <t>The Compound-MAC computation is as follows:</t>
        <artwork><![CDATA[
   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
method, MAC is the MAC function negotiated in TLS (e.g. (e.g., TLS 1.2 in <xref target="RFC5246"/>), and
BUFFER is created after concatenating these fields in the following
	order:</t>
        <ol spacing="normal" type="1"><li>
            <t>The entire Crypto-Binding TLV attribute with both the EMSK and MSK
 Compound-MAC fields zeroed out.</t>
          </li>
          <li>
            <t>The EAP Type sent by the other party in the first TEAP message,
which MUST <bcp14>MUST</bcp14> be TEAP, encoded as one octet of 0x37.</t>
          </li>
          <li>
            <t>All the Outer TLVs from the first TEAP message sent by the EAP server
to the peer.  If a single TEAP message is fragmented into multiple
TEAP packets, then the Outer TLVs in all the fragments of that
message MUST <bcp14>MUST</bcp14> be included.</t>
          </li>
          <li>
            <t>All the Outer TLVs from the first TEAP message sent by the peer to
the EAP server.  If a single TEAP message is fragmented into
multiple TEAP packets, then the Outer TLVs in all the fragments of
that message MUST <bcp14>MUST</bcp14> be included.</t>
          </li>
        </ol>
        <t>If no inner method is run, then no MSK or EMSK
will be generated.  If an IMSK needs to be generated generated, then the MSK
and therefore the IMSK is set to all zeroes (i.e., IMSK = MSK = 32 octets of 0x00s).</t>
        <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
outer TLVs it sent, sent and the outer TLVs it received from the peer.  On
the other side, the peer calculates the compound MAC using the outer
TLVs it sent, sent and the outer TLVs it received from the server.  As a
result, and any modification in transit of the outer TLVs will be detected
because the two sides will calculate different values for the compound
MAC.</t>
        <t>If no key generating key-generating inner method is run run, then no MSK or EMSK will be
generated. If an IMSK needs to be generated generated, then the MSK and therefore
the IMSK is set to all zeroes (i.e., IMSK = MSK = 32 octets of 0x00s)</t>
      </section>
      <section anchor="eap-master-session-key-generation">
        <name>EAP Master Session Key Generation</name>
        <t>TEAP authentication assures the Master Session Key (MSK) MSK and Extended
Master Session Key (EMSK) EMSK output from running TEAP are the combined result
of all inner methods by generating an Intermediate
Compound Key (IMCK). IMCK.  The IMCK is mutually derived by the peer and
the server as described in <xref target="intermediate-compound-key"/> by combining the MSKs from
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 IMCK[n] key hierarchy via the
following derivation:</t>
        <artwork><![CDATA[
   MSK  = the first 64 octets of TLS-PRF(S-IMCK[n],
          "Session Key Generating Function")
   EMSK = the first 64 octets of TLS-PRF(S-IMCK[n],
          "Extended Session Key Generating Function")
]]></artwork> Function")]]></artwork>
        <t>The secret is S-IMCK[n] S-IMCK[n], where n is the
number of the last generated
S-IMCK[j] from <xref target="intermediate-compound-key"/>.  The label is the ASCII
value for the string without quotes.  The seed is empty (0 length) and
is omitted from the derivation.</t>
        <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
transportation of these keys to a third party are outside the scope
of this document.</t>
        <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
S-IMCK[0] = session_key_seed.</t>
        <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
for each of MSK[j] and EMSK[j].  The final derivation using
S-IMCK[n] must choose only one of these keys.</t>
        <t>If the Crypto-Binding TLV contains an EMSK compound MAC, then the
derivation is taken from the S-IMCK_EMSK[n].  Otherwise  Otherwise, it is taken
from the S-IMCK_MSK[n].</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This

<!-- [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
Authority (IANA) regarding registration of values related to the TEAP
protocol in accordance with BCP 26 <xref target="RFC8126"/>.</t>
      <t>Except as noted below, IANA is instructed to update has updated the "Tunnel
Extensible Authentication Protocol (TEAP) Parameters" registry to
change the Reference field in all tables from <xref target="RFC7170"/> to [THIS-DOCUMENT].</t> RFC 9930.</t>
      <section anchor="teap-tlv-types">
        <name>TEAP TLV Types</name>
        <t>IANA is instructed to update has updated the references in the "TEAP TLV Types"
registry to from <xref target="RFC7170"/> to [THIS-DOCUMENT], RFC 9930 and add added TLV 18 and TLV 19 to
to
the registry.  The Unassigned values then begin at 20 instead of at 18.</t>
        <artwork><![CDATA[
Value,Description,Reference
18,CSR-Attributes TLV,[THIS-DOCUMENT]
19,Identity-Hint TLV,[THIS-DOCUMENT]
20-16383,Unassigned,
]]></artwork>
<table>
  <thead><tr><th>Value</th><th>Description</th><th>Reference</th></tr></thead>
  <tbody>
    <tr><td>18</td><td>CSR-Attributes TLV</td><td>RFC 9930</td></tr>
    <tr><td>19</td><td>Identity-Hint TLV</td><td>RFC 9930</td></tr>
    <tr><td>20-16383</td><td colspan="2">Unassigned</td></tr>
  </tbody>
</table>
        <t>IANA is instructed to close has closed the "TEAP PAC TLV (value 11) PAC
Attribute Type Codes" and "TEAP PAC TLV (value 11) PAC-Type Type
Codes" registries to new registrations, registrations and update update updated those registries with with a NOTE:</t>
        <artwork><![CDATA[
This the following note:</t>
<blockquote>This registry has been closed. See [THIS-DOCUMENT].
]]></artwork> RFC 9930.</blockquote>
      </section>
      <section anchor="teap-error-tlv-value-5-error-codes">
        <name>TEAP Error TLV (value 5) Error Codes</name>
        <t>IANA is instructed to update has updated the "TEAP Error TLV (value 5) Error Codes" registry to add the following entries"</t>
        <artwork><![CDATA[
Value,Description,Reference
1032,Inner entries:</t>
<table>
  <thead><tr><th>Value</th><th>Description</th><th>Reference</th></tr></thead>
  <tbody>
    <tr><td>1032</td><td>Inner method not supported,[THIS-DOCUMENT]
2003,The supported</td><td>RFC 9930</td></tr>
    <tr><td>2003</td><td>The Crypto-Binding TLV is invalid (Version, or Received-Ver, or Sub-Type),[THIS-DOCUMENT]
2004,The Sub-Type)</td><td>RFC 9930</td></tr>
    <tr><td>2004</td><td>The first inner method did not derive EMSK,[THIS-DOCUMENT]
2005,The EMSK</td><td>RFC 9930</td></tr>
    <tr><td>2005</td><td>The Crypto-Binding TLV did not include a required MSK Compound-MAC,[THIS-DOCUMENT]
2006,The Compound-MAC</td><td>RFC 9930</td></tr>
    <tr><td>2006</td><td>The MSK Compound-MAC fails verification,[THIS-DOCUMENT]
2007,The verification</td><td>RFC 9930</td></tr>
    <tr><td>2007</td><td>The Crypto-Binding TLV did not include a required EMSK Compound-MAC,[THIS-DOCUMENT]
2008,The Compound-MAC</td><td>RFC 9930</td></tr>
    <tr><td>2008</td><td>The EMSK Compound-MAC fails verification,[THIS-DOCUMENT]
2009,The verification</td><td>RFC 9930</td></tr>
    <tr><td>2009</td><td>The EMSK Compound-MAC exists, but the inner method did not derive EMSK,[THIS-DOCUMENT]
]]></artwork> EMSK</td><td>RFC 9930</td></tr>
</tbody>
</table>
      </section>
      <section anchor="tls-exporter-labels">
        <name>TLS Exporter Labels</name>
        <t>IANA is instructed to update has updated the "TLS Exporter Labels" registry to change the Reference field for Value "EXPORTER: teap session key seed" as follows:</t>
        <artwork><![CDATA[
Value,DTLS-OK,Recommended,Reference
EXPORTER:
<table>
  <thead><tr><th>Value</th><th>DTLS-OK</th><th>Recommended</th><th>Reference</th></tr></thead>
  <tbody><tr><td>EXPORTER: teap session key seed,N,Y,[THIS-DOCUMENT]
]]></artwork> seed</td><td>N</td><td>Y</td><td>RFC 9930</td></tr></tbody>
</table>
      </section>
      <section anchor="extended-master-session-key-emsk-parameters">
        <name>Extended Master Session Key (EMSK) Parameters</name>
        <t>IANA is instructed to update has updated the "User Specific Root Keys (USRK) Key Labels" registry to change the Reference field for Value "TEAPbindkey@ietf.org" as follows:</t>
        <artwork><![CDATA[
Value,Description,Reference
TEAPbindkey@ietf.org,TEAP
<table>
  <thead><tr><th>Label</th><th>Description</th><th>Reference</th></tr></thead>
  <tbody><tr><td>TEAPbindkey@ietf.org</td><td>TEAP binding usage label,[THIS-DOCUMENT]
]]></artwork> label</td><td>RFC 9930</td></tr></tbody>
</table>
      </section>
      <section anchor="extensible-authentication-protocol-eap-registry">
        <name>Extensible Authentication Protocol (EAP) Registry</name>
        <t>IANA is instructed to update has updated the "Method Types" registry to change the Reference field for Value "55" as follows:</t>
        <artwork><![CDATA[
Value,Description,Reference
55,TEAP,[THIS-DOCUMENT]
]]></artwork>
<table>
  <thead><tr><th>Value</th><th>Description</th><th>Reference</th></tr></thead>
  <tbody><tr><td>55</td><td>TEAP</td><td>RFC 9930</td></tr></tbody>
</table>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TEAP is designed with a focus on wireless media, where the medium
itself is inherent to eavesdropping.  Whereas in wired media an
attacker would have to gain physical access to the wired medium,
wireless media enables anyone to capture information as it is
transmitted over the air, enabling passive attacks.  Thus, physical
security can not be assumed, and security vulnerabilities are far
greater.  The threat model used for the security evaluation of TEAP
is defined in EAP <xref target="RFC3748"/>.</t>
      <section anchor="mutual-authentication-and-integrity-protection">
        <name>Mutual Authentication and Integrity Protection</name>
        <t>As a whole, TEAP provides message and integrity protection by
establishing a secure tunnel for protecting the inner
method(s).  The confidentiality and integrity protection is defined
by TLS and provides the same security strengths afforded by TLS
employing a strong entropy shared master secret.  The integrity of
the key generating inner methods executed within the TEAP
tunnel is verified through the calculation of the Crypto-Binding TLV.
This ensures that the tunnel endpoints are the same as the inner
method endpoints.</t>
        <t>Where Server Unauthenticated Provisioning server unauthenticated provisioning is performed, TEAP requires
that the inner provisioning method provide for both peer and server authentication.</t>
      </section>
      <section anchor="method-negotiation">
        <name>Method Negotiation</name>
        <t>As is true for any negotiated EAP protocol, EAP NAK message messages used to
suggest an alternate EAP authentication method are sent unprotected and,
as such, are subject to spoofing.  During unprotected EAP method
negotiation, NAK packets may be interjected as active attacks to
bid-down to a weaker form of authentication, such as EAP-MD5
(which only provides one-way authentication and does not derive a
key).  Both the peer and server should have a method selection policy
that prevents them from negotiating down to weaker methods.  Inner
method negotiation resists attacks because it is protected by the
mutually authenticated TLS tunnel established.  Selection of TEAP as
an authentication method does not limit the potential inner
methods, so TEAP should be selected when available.</t>
        <t>An attacker cannot readily determine the inner method used,
except perhaps by traffic analysis.  It is also important that peer
implementations limit the use of credentials with an unauthenticated
or unauthorized server.</t>
      </section>
      <section anchor="separation-p1-p2">
        <name>Separation of Phase 1 and Phase 2 Servers</name>
        <t>Separation of the TEAP Phase 1 from the Phase 2 conversation is NOT
RECOMMENDED.
	<bcp14>NOT RECOMMENDED</bcp14>.  Allowing the Phase 1 conversation to be terminated at a
different server than the Phase 2 conversation can introduce
vulnerabilities if there is not a proper trust relationship and
protection for the protocol between the two servers.  Some
vulnerabilities include:</t>
        <ul spacing="normal">
          <li>
            <t>Loss of identity protection</t>
          </li>
          <li>
            <t>Offline dictionary attacks</t>
          </li>
          <li>
            <t>Lack of policy enforcement</t>
          </li>
          <li>
            <t>on-path
            <t>On-path active attacks (as described in <xref target="RFC7029"/>)</t>
          </li>
        </ul>
        <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
offices within the same company, where there is no danger in
revealing the inner identity and credentials of the peer to entities
between the two servers.  In these cases, using a proxy solution
without end-to-end protection of TEAP MAY <bcp14>MAY</bcp14> be used.  The TEAP
encrypting/decrypting gateway MUST, <bcp14>MUST</bcp14>, at a minimum, provide support for
IPsec, TLS, or similar protection in order to provide confidentiality
for the portion of the conversation between the gateway and the EAP
server.  In addition, separation of the TEAP server servers and Inner servers
allows for crypto-binding based on the inner method MSK to be
thwarted as described in <xref target="RFC7029"/>.
If the inner method derives an EMSK, then this threat is mitigated as
TEAP uses the Crypto-Binding TLV to tie the inner EMSK to the TLS session via the TLS-PRF, as described above in <xref target="cryptographic-calculations"/>.</t>
        <t>On the other hand, if the inner method is not deriving EMSK EMSK, as with
password authentication or unauthenticated provisioning, then this
threat still exists.  Implementations therefore need to limit the use of
inner methods as discussed above in <xref target="inner-method-limitations"/></t>
      </section>
      <section anchor="mitigation-of-known-vulnerabilities-and-protocol-deficiencies">
        <name>Mitigation of Known Vulnerabilities and Protocol Deficiencies</name>
        <t>TEAP addresses the known deficiencies and weaknesses in some EAP
authentication methods.  By employing a shared secret between the peer and server to
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">
          <li>
            <t>Per-packet confidentiality and integrity protection</t>
          </li>
          <li>
            <t>User identity protection</t>
          </li>
          <li>
            <t>Better support for notification messages</t>
          </li>
          <li>
            <t>Protected inner method negotiation, including EAP method</t>
          </li>
          <li>
            <t>Sequencing of inner methods, including EAP methods</t>
          </li>
          <li>
            <t>Strong mutually derived MSKs</t>
          </li>
          <li>
            <t>Acknowledged success/failure indication</t>
          </li>
          <li>
            <t>Faster re-authentications through session resumption</t>
          </li>
          <li>
            <t>Mitigation of offline dictionary attacks</t>
          </li>
          <li>
            <t>Mitigation of on-path attacks</t>
          </li>
          <li>
            <t>Mitigation of some denial-of-service attacks</t>
          </li>
        </ul>
        <t>It should be noted that in TEAP, as in many other authentication
protocols, a denial-of-service attack can be mounted by adversaries
sending erroneous traffic to disrupt the protocol.  This is a problem
in many authentication or key agreement protocols and is therefore
noted for TEAP as well.</t>
        <t>TEAP was designed with a focus on protected inner methods
that typically rely on weak credentials, such as password-based
secrets.  To that extent, the TEAP authentication mitigates several
vulnerabilities, such as offline dictionary attacks, by protecting the weak
credential-based inner method.  The protection is based on
strong cryptographic algorithms in TLS to provide message
confidentiality and integrity.  The keys derived for the protection
relies on strong random challenges provided by both peer and server
as well as an established key with strong entropy.  Implementations
should follow the recommendation in <xref target="RFC4086"/> when generating random
numbers.</t>
        <section anchor="user-identity-protection-and-verification">
          <name>User Identity Protection and Verification</name>
          <t>The initial identity request response exchange is sent in cleartext
outside the protection of TEAP.  Typically, the Network Access
Identifier (NAI) NAI <xref target="RFC7542"/> in the identity response is useful only
for the realm of information that is used to route the authentication
requests to the right EAP server.  This means that the identity
response may contain an anonymous identity and just contain realm
information.  In other cases, the identity exchange may be eliminated
altogether if there are other means for establishing the destination
realm of the request.  In no case should an intermediary place any
trust in the identity information in the identity response since it
is unauthenticated and may not have any relevance to the
authenticated identity.  TEAP implementations should not attempt to
compare any identity disclosed in the initial cleartext EAP Identity
response packet with those Identities authenticated in Phase 2.</t>
          <t>When the server is authenticated, identity request/response exchanges
sent after the TEAP tunnel is established are protected from
modification and eavesdropping by attackers.  For server
unauthenticated provisioning, the outer TLS session provides little
security, and the provisioning method must necessarily provide this
protection instead.</t>
          <t>When a client certificate is sent outside of the TLS tunnel in Phase
1, the peer MUST <bcp14>MUST</bcp14> include Identity-Type as an outer TLV, TLV in order to
signal the type of identity which that client certificate is for.
Further, when a client certificate is sent outside of the TLS tunnel,
the server MUST <bcp14>MUST</bcp14> proceed with Phase 2.  If there is no Phase 2 data,
then the EAP server MUST <bcp14>MUST</bcp14> reject the session.</t>
          <t>Issues related to confidentiality of a client certificate are
discussed above in <xref target="client-certs-phase1"/></t>
          <t>Note that the Phase 2 data could simply be a Result TLV with value
Success, along with a Crypto-Binding TLV.
This Phase 2 data serves as a protected success indication as
discussed in <xref section="2.1.1" sectionFormat="comma" target="RFC9190"/></t>
        </section>
      </section>
      <section anchor="dictionary-attack-resistance">
        <name>Dictionary Attack Resistance</name>
        <t>TEAP was designed with a focus on protected inner methods
that typically rely on weak credentials, such as password-based
secrets.  TEAP mitigates offline dictionary attacks by allowing the
establishment of a mutually authenticated encrypted TLS tunnel
providing confidentiality and integrity to protect the weak
credential-based inner method.</t>
        <t>TEAP mitigates dictionary attacks by permitting inner methods methods, such as
EAP-pwd which
EAP-pwd, that are not vulnerable to dictionary attacks.</t>
        <t>TEAP implementations can mitigate online "brute force"
dictionary attempts by limiting the number of failed authentication
attempts for a particular identity.</t>
        <section anchor="protection-against-on-path-attacks">
          <name>Protection against Against On-Path Attacks</name>
          <t>TEAP provides protection from on-path attacks in a few ways:</t>
          <ol spacing="normal" type="1"><li>
              <t>By using a certificates or a session ticket to mutually
authenticate the peer and server during TEAP authentication Phase 1
establishment of a secure TLS tunnel.</t>
            </li>
            <li>
              <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
exchange and in the generation of the key material exported by
the inner method described in <xref target="cryptographic-calculations"/>.</t>
            </li>
          </ol>
          <t>TEAP crypto binding does not guarantee protection from on-path attacks
if the client allows a connection to an untrusted server, such as in
the case where the client does not properly validate the server's
certificate.  If the TLS cipher suite derives the master secret solely
from the contribution of secret data from one side of the
conversation (such as cipher suites based on RSA key transport), then
an attacker who can convince the client to connect and engage in
authentication can impersonate the client to another server even if a
strong inner method is executed within the tunnel.  If the TLS
cipher suite derives the master secret from the contribution of
secrets from both sides of the conversation (such as in cipher suites
based on Diffie-Hellman), then crypto binding can detect an attacker
in the conversation if a strong inner method is used.</t>
          <t>TEAP crypto binding does not guarantee protection from on-path attacks
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
define TEAPv2, which would then have different crypto binding
derivations.</t>
        </section>
      </section>
      <section anchor="protecting-against-forged-cleartext-eap-packets">
        <name>Protecting against Against Forged Cleartext EAP Packets</name>
        <t>EAP Success and EAP Failure packets are, in general, sent in
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
disconnect.  Forged EAP Success packets may be used to attempt to
convince a peer that authentication has succeeded, even though the
authenticator has not authenticated itself to the peer.</t>
        <t>By providing message confidentiality and integrity, TEAP provides
protection against these attacks.  Once the peer and authentication server (AS) initiate the TEAP authentication Phase 2, compliant TEAP
implementations MUST <bcp14>MUST</bcp14> silently discard all cleartext EAP messages,
unless both the TEAP peer and server have indicated success or
failure using a protected mechanism.  Protected mechanisms include
the TLS alert mechanism and the protected termination mechanism
described in <xref target="protected-termination"/>.</t>
        <t>The success/failure decisions within the TEAP tunnel indicate the
final decision of the TEAP authentication conversation.  After a
success/failure result has been indicated by a protected mechanism,
the TEAP peer can process unprotected EAP Success and EAP Failure
messages; however, the peer MUST <bcp14>MUST</bcp14> ignore any unprotected EAP Success
or Failure messages where the result does not match the result of the
protected mechanism.</t>
        <t>To abide by <xref target="RFC3748"/>, the server sends a cleartext EAP Success or
EAP Failure packet to terminate the EAP conversation.  However, since
EAP Success and EAP Failure packets are not retransmitted, the final
packet may be lost.  While a TEAP-protected EAP Success or EAP
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
should not rely upon the unprotected EAP Success and Failure
messages.</t>
      </section>
      <section anchor="use-of-clear-text-passwords">
        <name>Use of Clear-text Cleartext Passwords</name>
        <t>TEAP can carry clear-text cleartext passwords in the Basic-Password-Auth-Resp
TLV.  Implementations should take care to protect this data.  For
example, passwords should not normally be logged, and password data
should be securely scrubbed from memory when it is no longer needed.</t>
      </section>
      <section anchor="accidental-or-unintended-behavior">
        <name>Accidental or Unintended Behavior</name>
        <t>Due to the complexity of TEAP, and the long time between <xref target="RFC7170"/>
and any substantial implementation, there are many accidental or
unintended behaviors in the protocol.</t>
        <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
early implementor or implementors instead used EAP-FAST-MSCHAPv2.  The
choice for this document was either to define a new version of TEAP
which
that used EAP-MSCHAPv2, EAP-MSCHAPv2 or instead to document implemented behavior.
The choice taken here was to document running code.</t>
        <t>The issues discussed in <xref target="oops"/> could have security impacts, but no
analysis has been performed.  The choice of using a special "all zero"
IMSK in <xref target="intermediate-compound-key"/> was made for simplicity, simplicity but could
also have negative security impacts.</t>
        <t>The definition of the Crypto-Binding TLV means that it the final
Crypto-Binding TLV values might not depend on all previous values of
MSK and EMSK.  This limitation could have negative security impacts,
but again again, no analysis has been performed.</t>
        <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
better derive the various keying materials and cryptographic binding
derivations.  However, in the interest of documenting running code, we
are publishing this document with the acknowledgement acknowledgment that there are
improvements to be made.</t>
      </section>
      <section anchor="implicit-challenge">
        <name>Implicit Challenge</name>
        <t>Certain authentication protocols that use a challenge/response
mechanism rely on challenge material that is not generated by the
authentication server, and therefore server; therefore, the material may require special
handling.  For EAP-TTLS, these challenges are defined in <xref section="11.1" sectionFormat="comma" target="RFC5281"/>.</t>
        <t>In EAP-MSCHAPv2, the authenticator issues a challenge to the
supplicant,
supplicant. Then, the supplicant then hashes the challenge with the password
and forwards the response to the authenticator. The response also
includes a Peer-Challenge, which is created by the supplicant.  Since
the challenge is random, it is not associated with the TLS tunnel, tunnel and
the protocol may be susceptible to a replay attack.</t>
        <t>The Crypto-Binding TLV provides protection against intermediaries, but
it does not provide protection against a replay attack.  We suggest
that any TEAPv2 specification correct this issue.</t>
      </section>
      <section anchor="security-claims">
        <name>Security Claims</name>
        <t>This section provides the needed security claim requirement for EAP
<xref target="RFC3748"/>.</t>
        <artwork><![CDATA[
Auth. mechanism:
<dl spacing="normal" newline="false">
<dt>Auth. mechanism:</dt><dd>         Certificate-based, shared-secret-based, and
                         various tunneled authentication mechanisms.

Cipher mechanisms.</dd>

<dt>Cipher Suite negotiation: Yes

Mutual authentication:   Yes

Integrity protection: negotiation:</dt><dd>Yes</dd>

<dt>Mutual authentication:</dt><dd>   Yes</dd>

<dt>Integrity protection:</dt><dd>    Yes.  Any method executed within the TEAP
                         tunnel is integrity protected.  The
                         cleartext EAP headers outside the tunnel are
                         not integrity protected.  Server
                         unauthenticated provisioning provides its own
                         protection mechanisms.

Replay protection:       Yes

Confidentiality:         Yes

Key derivation:          Yes

Key strength: mechanisms.</dd>

<dt>Replay protection:</dt><dd>       Yes</dd>

<dt>Confidentiality:</dt><dd>         Yes</dd>

<dt>Key derivation:</dt><dd>          Yes</dd>

<dt>Key strength:</dt><dd>            See Note 1 below.

Dictionary below.</dd>

<dt>Dictionary attack prot.: prot.:</dt><dd> See Note 2 below.

Fast reconnect:          Yes

Cryptographic binding:   Yes

Session independence:    Yes

Fragmentation:           Yes

Key Hierarchy:           Yes

Channel binding:         Yes
]]></artwork>
        <t>Notes</t>
        <t>Note below.</dd>

<dt>Fast reconnect:</dt><dd>          Yes</dd>

<dt>Cryptographic binding:</dt><dd>   Yes</dd>

<dt>Session independence:</dt><dd>    Yes</dd>

<dt>Fragmentation:</dt><dd>           Yes</dd>

<dt>Key Hierarchy:</dt><dd>           Yes</dd>

<dt>Channel binding:</dt><dd>         Yes</dd>
</dl>

<t>Notes:</t>
<!-- [rfced] Should this citation be to BCP 86 or RFC 3766?

Current:
   Note 1. BCP 86 [RFC3766] offers advice on appropriate key sizes. The
   National Institute for Standards and Technology (NIST) also offers
   advice on appropriate key sizes in [NIST-SP-800-57].
-->

<!-- [rfced] It is unclear to us if the citations in the following
sentence are meant to point to Section 6 of RFC 3766 or to both RFC 3766
and Section 6 of this document (current). We have left the citations as
is. Please review and let us know how the citations may be updated for
clarity.

Current:
  [RFC3766], Section 6 advises use of the following required RSA or DH
  (Diffie-Hellman) module and DSA (Digital Signature Algorithm) subgroup
  size in bits for a given level of attack resistance in bits.
-->
<ul spacing="normal">
  <li><t>Note 1. BCP 86 <xref target="RFC3766"/> offers advice on appropriate
  key sizes.  The National Institute for Standards and Technology (NIST) also
  offers advice on appropriate key sizes in <xref target="NIST-SP-800-57"/>.
  <xref target="RFC3766"/>, <xref target="cryptographic-calculations"/>
  advises use of the following required RSA or
DH (Diffie-Hellman) Diffie-Hellman (DH) module and DSA (Digital
  Digital Signature Algorithm) 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>
        <artwork><![CDATA[
    Attack

<table>
  <thead><tr><th>Attack Resistance     RSA (bits)</th><th>RSA or DH Modulus            DSA subgroup
     (bits) size (bits) (bits)</th><th>DSA subgroup size (bits)
    -----------------     -----------------            ------------
       70                        947                        129
       80                       1228                        148
       90                       1553                        167
      100                       1926                        186
      150                       4575                        284
      200                       8719                        383
      250                      14596                        482
]]></artwork>
        <t>Note (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 anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Nearly all of
<!-- [rfced] May we move the text in this document was taken directly "Changes 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 7170" section to the text in
<xref target="oops"/>.</t>
    </section>
Appendix?
-->
    <section anchor="changes-from-rfc-7170">
      <name>Changes from RFC 7170</name>
      <t>Alan DeKok was added as an editor.</t>
      <t>The
<!-- [rfced] May we update the following text for conciseness?

Original:
 The document was converted to Markdown, from the <xref target="RFC7170"/> [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 Markdown
versus XML for source.</t>
      <t>The IANA considerations Considerations section was replaced with a note to change the
IANA registry references to this document.</t>
      <t>A new section was added to explain that the inner EAP-MSCHAPv2
derivation follows EAP-FAST.  This is the largest technical change
from the previous revision of this document, document and follows existing implementations.</t>
      <t>Many small changes have been made throughout the document to correct
inconsistencies,
inconsistencies and to address mistakes.  At a high level:</t>
      <ul spacing="normal">
        <li>
          <t>All open errata have been addressed.</t>
        </li>
        <li>
          <t>A new term "inner method" has been defined.</t>
        </li>
        <li>
          <t>The definitions and derivation of IMSK, S-IMCK, etc. have been corrected and clarified.</t>
        </li>
        <li>
          <t>The diagrams in Appendix C <xref target="appendix-c-examples"/> have been updated to match the TEAP state machine</t> machine.</t>
        </li>
      </ul>
      <t>All uses of the PAC were removed.  It had not been implemented, and
there were no plans by implementors to use it.</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, cycle in order to
document accidental behavior which that could result in interability interoperability
issues.</t>
    </section>

  </middle>
  <back>
    <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.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2985.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3748.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5077.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5216.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5295.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5705.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5746.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5929.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6677.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7030.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8996.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9190.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9427.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9525.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9908.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-pppext-eap-mschapv2.xml"/>

        <reference anchor="MSCHAP" target="https://learn.microsoft.com/en-us/openspecs/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/openspecs/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.2315.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3579.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3766.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4017.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4072.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4851.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4945.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4962.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5247.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5272.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5281.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5421.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5422.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5931.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6124.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6678.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6960.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6961.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7029.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7170.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7542.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.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.4949.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6238.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8146.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7299.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4334.xml"/>
      </references>
    </references>

    <section numbered="false" numbered="true" anchor="appendix-a-evaluation-against-tunnel-based-eap-method-requirements">
      <name>Appendix A Evaluation against
      <name>Evaluation Against Tunnel-Based EAP Method Requirements</name>
      <t>This section evaluates all tunnel-based EAP method requirements
described in <xref target="RFC6678"/> against TEAP version 1.</t>
      <section numbered="false" numbered="true" anchor="a1-requirement-411-rfc-compliance">
        <name>A.1.  Requirement
        <name>Requirement 4.1.1: RFC Compliance</name>
        <t>TEAPv1 meets this requirement by being compliant with RFC 3748 <xref target="RFC3748"/>, RFC 4017 <xref target="RFC4017"/>, RFC 5247 <xref target="RFC5247"/>, and RFC 4962 <xref target="RFC4962"/>.  It is also compliant with the "cryptographic algorithm
agility" requirement by leveraging TLS 1.2 for all cryptographic
algorithm negotiation.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a2-requirement-421-tls-requirements">
        <name>A.2.  Requirement
        <name>Requirement 4.2.1: TLS Requirements</name>
        <t>TEAPv1 meets this requirement by mandating TLS version 1.2 support as
defined in <xref target="phase1"/>.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a3-requirement-42111-cipher-suite-negotiation">
        <name>A.3.  Requirement
        <name>Requirement 4.2.1.1.1: Cipher Suite Negotiation</name>
        <t>TEAPv1 meets this requirement by using TLS to provide protected
cipher suite negotiation.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a4-requirement-42112-tunnel-data-protection-algorithms">
        <name>A.4.  Requirement
        <name>Requirement 4.2.1.1.2: Tunnel Data Protection Algorithms</name>
        <t>TEAPv1 meets this requirement by mandating cipher suites
as defined in <xref target="phase1"/>.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a5-requirement-42113-tunnel-authentication-and-key-establishment">
        <name>A.5.  Requirement
        <name>Requirement 4.2.1.1.3: Tunnel Authentication and Key Establishment</name>
        <t>TEAPv1 meets this requirement by mandating cipher suites which that only
include cipher suites that use strong cryptographic algorithms.  They
do not include cipher suites providing mutually anonymous
authentication or static Diffie-Hellman cipher suites as defined in
<xref target="phase1"/>.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a6-requirement-4212-tunnel-replay-protection">
        <name>A.6.  Requirement
        <name>Requirement 4.2.1.2: Tunnel Replay Protection</name>
        <t>TEAPv1 meets this requirement by using TLS to provide sufficient
replay protection.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a7-requirement-4213-tls-extensions">
        <name>A.7.  Requirement
        <name>Requirement 4.2.1.3: TLS Extensions</name>
        <t>TEAPv1 meets this requirement by allowing TLS extensions, such as TLS
Certificate Status Request extension <xref target="RFC6066"/> and SessionTicket
extension <xref target="RFC5077"/>, to be used during TLS tunnel establishment.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a8-requirement-4214-peer-identity-privacy">
        <name>A.8.  Requirement
        <name>Requirement 4.2.1.4: Peer Identity Privacy</name>
        <t>TEAPv1 meets this requirement by establishment of the TLS tunnel and
protection identities specific to the inner method.  In addition, the
peer certificate can be sent confidentially (i.e., encrypted).</t>
      </section>
      <section numbered="false" numbered="true" anchor="a9-requirement-4215-session-resumption">
        <name>A.9.  Requirement
        <name>Requirement 4.2.1.5: Session Resumption</name>
        <t>TEAPv1 meets this requirement by mandating support of TLS session
resumption as defined in <xref target="resume-server-state"/> and TLS session
resumption using the methods defined in <xref target="RFC9190"/></t> target="RFC9190"/>.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a10-requirement-422-fragmentation">
        <name>A.10.  Requirement
        <name>Requirement 4.2.2: Fragmentation</name>
        <t>TEAPv1 meets this requirement by leveraging fragmentation support
provided by TLS as defined in <xref target="fragmentation"/>.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a11-requirement-423-protection-of-data-external-to-tunnel">
        <name>A.11.  Requirement
        <name>Requirement 4.2.3: Protection of Data External to Tunnel</name>
        <t>TEAPv1 meets this requirement by including the TEAP version number
received in the computation of the Crypto-Binding TLV as defined in
<xref target="crypto-binding-tlv"/>.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a12-requirement-431-extensible-attribute-types">
        <name>A.12.  Requirement
        <name>Requirement 4.3.1: Extensible Attribute Types</name>
        <t>TEAPv1 meets this requirement by using an extensible TLV data layer
inside the tunnel as defined in <xref target="teap-tlv-format"/>.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a13-requirement-432-requestchallenge-response-operation">
        <name>A.13.  Requirement
        <name>Requirement 4.3.2: Request/Challenge Response Operation</name>
        <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
operation typical of EAP.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a14-requirement-433-indicating-criticality-of-attributes">
        <name>A.14.  Requirement
        <name>Requirement 4.3.3: Indicating Criticality of Attributes</name>
        <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
<xref target="teap-tlv-format"/>.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a15-requirement-434-vendor-specific-support">
        <name>A.15.  Requirement
        <name>Requirement 4.3.4: Vendor-Specific Support</name>
        <t>TEAPv1 meets this requirement by having a Vendor-Specific TLV to
allow vendors to define their own attributes as defined in
<xref target="vendor-specific-tlv"/>.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a16-requirement-435-result-indication">
        <name>A.16.  Requirement
        <name>Requirement 4.3.5: Result Indication</name>
        <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
have a synchronized state as defined in <xref target="result-tlv"/>.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a17-requirement-436-internationalization-of-display-strings">
        <name>A.17.  Requirement
        <name>Requirement 4.3.6: Internationalization of Display Strings</name>
        <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 the
Basic-Password-Auth-Resp TLV as defined in <xref target="bp-auth-resp-tlv"/>.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a18-requirement-44-eap-channel-binding-requirements">
        <name>A.18.  Requirement
        <name>Requirement 4.4: EAP Channel-Binding Requirements</name>
        <t>TEAPv1 meets this requirement by having a Channel-Binding TLV to
exchange the EAP channel-binding data as defined in <xref target="channel-binding-tlv"/>.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a19-requirement-4511-confidentiality-and-integrity">
        <name>A.19.  Requirement
        <name>Requirement 4.5.1.1: Confidentiality and Integrity</name>
        <t>TEAPv1 meets this requirement by running the password authentication
inside a protected TLS tunnel.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a20-requirement-4512-authentication-of-server">
        <name>A.20.  Requirement
        <name>Requirement 4.5.1.2: Authentication of Server</name>
        <t>TEAPv1 meets this requirement by mandating authentication of the
server before establishment of the protected TLS and then running
inner password authentication as defined in <xref target="phase1"/>.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a21-requirement-4513-server-certificate-revocation-checking">
        <name>A.21.  Requirement
        <name>Requirement 4.5.1.3: Server Certificate Revocation Checking</name>
        <t>TEAPv1 meets this requirement by supporting TLS Certificate Status
Request extension <xref target="RFC6066"/> during tunnel establishment.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a22-requirement-452-internationalization">
        <name>A.22.  Requirement
        <name>Requirement 4.5.2: Internationalization</name>
        <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-Resp TLV as defined in Section 4.2.15.</t> <xref target="bp-auth-resp-tlv"/>.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a23-requirement-453-metadata">
        <name>A.23.  Requirement
        <name>Requirement 4.5.3: Metadata</name>
        <t>TEAPv1 meets this requirement by supporting Identity-Type TLV as
defined in <xref target="identity-type-tlv"/> to indicate whether the authentication is
for a user or a machine.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a24-requirement-454-password-change">
        <name>A.24.  Requirement
        <name>Requirement 4.5.4: Password Change</name>
        <t>TEAPv1 meets this requirement by supporting multiple
Basic-Password-Auth-Req TLV and Basic-Password-Auth-Resp TLV exchanges within a
single EAP authentication, which allows "housekeeping"" functions
such as password change.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a25-requirement-461-method-negotiation">
        <name>A.25.  Requirement
        <name>Requirement 4.6.1: Method Negotiation</name>
        <t>TEAPv1 meets this requirement by supporting inner EAP method
negotiation within the protected TLS tunnel.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a26-requirement-462-chained-methods">
        <name>A.26.  Requirement
        <name>Requirement 4.6.2: Chained Methods</name>
        <t>TEAPv1 meets this requirement by supporting inner EAP method chaining
within protected TLS tunnels as defined in <xref target="inner-eap"/>.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a27-requirement-463-cryptographic-binding-with-the-tls-tunnel">
        <name>A.27.  Requirement
        <name>Requirement 4.6.3: Cryptographic Binding with the TLS Tunnel</name>
        <t>TEAPv1 meets this requirement by supporting cryptographic binding of
the inner EAP method keys with the keys derived from the TLS tunnel
as defined in <xref target="crypto-binding-tlv"/>.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a28-requirement-464-peer-initiated-eap-authentication">
        <name>A.28.  Requirement
        <name>Requirement 4.6.4: Peer-Initiated EAP Authentication</name>
        <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 another inner
EAP method.</t>
      </section>
      <section numbered="false" numbered="true" anchor="a29-requirement-465-method-metadata">
        <name>A.29.  Requirement
        <name>Requirement 4.6.5: Method Metadata</name>
        <t>TEAPv1 meets this requirement by supporting the Identity-Type TLV as
defined in <xref target="identity-type-tlv"/> to indicate whether the authentication is
for a user or a machine.</t>
      </section>
    </section>
    <section numbered="false" numbered="true" anchor="appendix-b-major-differences-from-eap-fast">
      <name>Appendix B.  Major
      <name>Major Differences from EAP-FAST</name>
      <t>This document is a new standard tunnel EAP method based on revision
of EAP-FAST version 1 <xref target="RFC4851"/> that contains improved flexibility,
particularly for negotiation of cryptographic algorithms.  The major
changes are:</t>
      <ol spacing="normal" type="1"><li>
          <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>
        </li>
        <li>
          <t>This version of TEAP MUST <bcp14>MUST</bcp14> support TLS 1.2 <xref target="RFC5246"/>.  TLS 1.1 and earlier MUST NOT <bcp14>MUST NOT</bcp14> be used with TEAP.</t>
        </li>
        <li>
          <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
is to simplify implementation and better support cryptographic
algorithm agility.</t>
        </li>
        <li>
          <t>TEAP is in full conformance with TLS ticket extension <xref target="RFC5077"/>.</t>
        </li>
        <li>
          <t>Support is provided for passing optional Outer TLVs in the first
two message exchanges, in addition to the Authority-ID TLV data
in EAP-FAST.</t>
        </li>
        <li>
          <t>Basic password authentication on the TLV level has been added in
addition to the existing inner EAP method.</t>
        </li>
        <li>
          <t>Additional TLV types have been defined to support EAP channel
binding and metadata.  They are the Identity-Type TLV and
Channel-Binding TLVs, defined in <xref target="teap-tlv-format"/>.</t>
        </li>
      </ol>
    </section>
    <section numbered="false" numbered="true" anchor="appendix-c-examples">
      <name>Appendix C.  Examples</name>
      <name>Examples</name>
      <section numbered="false" numbered="true" anchor="c1-successful-authentication">
        <name>C.1.  Successful
        <name>Successful Authentication</name>
        <t>The following exchanges show a successful TEAP authentication with
basic password authentication.  The
conversation will appear as follows:</t>
        <artwork><![CDATA[
   Authenticating Peer     Authenticator
   -------------------     -------------
                           <- EAP-Request/
                           Identity
   EAP-Response/
   Identity (MyID1) ->
                           <- EAP-Request/
                           EAP-Type=TEAP, V=1
                           (TEAP Start, S bit set, Authority-ID)

   EAP-Response/
   EAP-Type=TEAP, V=1
   (TLS client_hello) ->

                           <- EAP-Request/
                           EAP-Type=TEAP, V=1
                           (TLS server_hello,
                           (TLS change_cipher_spec,
                            TLS finished)

   EAP-Response/
   EAP-Type=TEAP, V=1 ->
   (TLS change_cipher_spec,
    TLS finished)

   TLS channel established
   (messages sent within the TLS channel)

                          <- Basic-Password-Auth-Req TLV, Challenge

   Basic-Password-Auth-Resp TLV, Response with both
   username and password) ->

   optional additional exchanges (new pin mode,
   password change, etc.) ...

                        <- Intermediate-Result TLV (Success),
                            Crypto-Binding TLV (Request),
                            Result TLV (Success)

   Intermediate-Result TLV (Success),
   Crypto-Binding TLV(Response),
   Result TLV (Success) ->

   TLS channel torn down
   (messages sent in cleartext)

                           <- EAP-Success
]]></artwork> EAP-Success]]></artwork>
      </section>
      <section numbered="false" numbered="true" anchor="c2-failed-authentication">
        <name>C.2.  Failed
        <name>Failed Authentication</name>
        <t>The following exchanges show a failed TEAP authentication due to
wrong user credentials.  The conversation will appear as follows:</t>
        <artwork><![CDATA[
   Authenticating Peer     Authenticator
   -------------------     -------------
                           <- EAP-Request/Identity

   EAP-Response/
   Identity (MyID1) ->

                           <- EAP-Request/
                           EAP-Type=TEAP, V=1
                           (TEAP Start, S bit set, Authority-ID)

   EAP-Response/
   EAP-Type=TEAP, V=1
   (TLS client_hello) ->

                           <- EAP-Request/
                           EAP-Type=TEAP, V=1
                           (TLS server_hello,
                           (TLS change_cipher_spec,
                            TLS finished)

   EAP-Response/
   EAP-Type=TEAP, V=1 ->
   (TLS change_cipher_spec,
    TLS finished)

   TLS channel established
   (messages sent within the TLS channel)

                          <- Basic-Password-Auth-Req TLV, Challenge

   Basic-Password-Auth-Resp TLV, Response with both
   username and password) ->

                           <- Intermediate-Result TLV (Failure),
                              Result TLV (Failure)

   Intermediate-Result TLV (Failure),
   Result TLV (Failure) ->

   TLS channel torn down
   (messages sent in cleartext)

                           <- EAP-Failure
]]></artwork> EAP-Failure]]></artwork>
      </section>
      <section numbered="false" numbered="true" anchor="c3-full-tls-handshake-using-certificate-based-cipher-suite">
        <name>C.3.  Full
        <name>Full TLS Handshake Using Certificate-Based Cipher Suite</name>
        <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
handshake, the conversation will appear as follows:</t>
        <artwork><![CDATA[
  Authenticating Peer    Authenticator
  -------------------    -------------
                         <- EAP-Request/Identity
  EAP-Response/
  Identity (MyID1) ->

  // Identity sent in the clear.  May be a hint to help route
     the authentication request to EAP server, instead of the
     full user identity.

                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TEAP Start, S bit set, Authority-ID)
  EAP-Response/
  EAP-Type=TEAP, V=1
  (TLS client_hello with
  SessionTicket extension)->

  // If the server rejects the session resumption,
     it falls through to the full TLS handshake.

                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TLS server_hello,
                           TLS certificate,
                          [TLS server_key_exchange,]
                          [TLS certificate_request,]
                           TLS server_hello_done)

  EAP-Response/
  EAP-Type=TEAP, V=1
  ([TLS certificate,]
   TLS client_key_exchange,
  [TLS certificate_verify,]
   TLS change_cipher_spec,
   TLS finished) ->
                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TLS change_cipher_spec,
                           TLS finished,
                           EAP-Payload TLV[EAP-Request/
                           Identity])

  // TLS channel established
     (messages sent within the TLS channel)

  // First EAP Payload TLV is coalesced with the TLS Finished as
     Application Data and protected by the TLS tunnel.

  EAP-Payload TLV
  [EAP-Response/Identity (MyID2)]->

  // identity protected by TLS.

                           <- EAP-Payload TLV
                           [EAP-Request/EAP-Type=X]

  EAP-Payload TLV
  [EAP-Response/EAP-Type=X] ->

  // Method X exchanges followed by Protected Termination

                       <- Intermediate-Result TLV (Success),
                           Crypto-Binding TLV (Request),
                           Result TLV (Success)

  Intermediate-Result TLV (Success),
  Crypto-Binding TLV (Response),
  Result TLV (Success) ->

  // TLS channel torn down
  (messages sent in cleartext)

                          <- EAP-Success
]]></artwork> EAP-Success]]></artwork>
      </section>
      <section numbered="false" numbered="true" anchor="c4-client-authentication-during-phase-1-with-identity-privacy">
        <name>C.4.  Client
        <name>Client Authentication during During Phase 1 with Identity Privacy</name>
        <t>In the case where a certificate-based TLS handshake occurs within
TEAP Phase 1 and client certificate authentication and identity
privacy is desired (and therefore TLS renegotiation is being used to
transmit the peer credentials in the protected TLS tunnel), the
conversation will appear as follows for TLS 1.2:</t>
        <artwork><![CDATA[
  Authenticating Peer     Authenticator
  -------------------     -------------
                         <- EAP-Request/Identity
  EAP-Response/
  Identity (MyID1) ->

  // Identity sent in the clear.  May be a hint to help route
     the authentication request to EAP server, instead of the
     full user identity.

                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TEAP Start, S bit set, Authority-ID)
  EAP-Response/
  EAP-Type=TEAP, V=1
  (TLS client_hello)->
                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TLS server_hello,
                           TLS certificate,
                          [TLS server_key_exchange,]
                          [TLS certificate_request,]
                           TLS server_hello_done)
  EAP-Response/
  EAP-Type=TEAP, V=1
  (TLS client_key_exchange,
   TLS change_cipher_spec,
   TLS finished) ->
                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TLS change_cipher_spec,
                           TLS finished,
                           EAP-Payload TLV[EAP-Request/
                           Identity])

  // TLS channel established
     (EAP Payload messages sent within the TLS channel)

  // peer sends TLS client_hello to request TLS renegotiation
  TLS client_hello ->

                          <- TLS server_hello,
                           TLS certificate,
                           [TLS server_key_exchange,]
                           [TLS certificate_request,]
                           TLS server_hello_done
  [TLS certificate,]
   TLS client_key_exchange,
  [TLS certificate_verify,]
   TLS change_cipher_spec,
   TLS finished ->

                          <- TLS change_cipher_spec,
                             TLS finished,
                             Crypto-Binding TLV (Request),
                             Result TLV (Success)

  Crypto-Binding TLV (Response),
  Result TLV (Success)) ->

  //TLS channel torn down
  (messages sent in cleartext)

                          <- EAP-Success
]]></artwork> EAP-Success]]></artwork>
      </section>
      <section numbered="false" numbered="true" anchor="c5-fragmentation-and-reassembly">
        <name>C.5.  Fragmentation
        <name>Fragmentation and Reassembly</name>
        <t>In the case where TEAP fragmentation is required, the conversation
will appear as follows:</t>
        <artwork><![CDATA[
  Authenticating Peer     Authenticator
  -------------------     -------------
                          <- EAP-Request/
                          Identity
  EAP-Response/
  Identity (MyID) ->
                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TEAP Start, S bit set, Authority-ID)

  EAP-Response/
  EAP-Type=TEAP, V=1
  (TLS client_hello)->

                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TLS server_hello,
                           TLS certificate,
                          [TLS server_key_exchange,]
                          [TLS certificate_request,]
                           TLS server_hello_done)
                          (Fragment 1: L, M bits set)

  EAP-Response/
  EAP-Type=TEAP, V=1 ->

                          <- EAP-Request/
                             EAP-Type=TEAP, V=1
                          (Fragment 2: M bit set)
  EAP-Response/
  EAP-Type=TEAP, V=1 ->
                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (Fragment 3)
  EAP-Response/
  EAP-Type=TEAP, V=1
  ([TLS certificate,]
   TLS client_key_exchange,
  [TLS certificate_verify,]
   TLS change_cipher_spec,
   TLS finished)
   (Fragment 1: L, M bits set)->

                           <- EAP-Request/
                          EAP-Type=TEAP, V=1
  EAP-Response/
  EAP-Type=TEAP, V=1
  (Fragment 2)->
                         <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TLS change_cipher_spec,
                           TLS finished,
                          [EAP-Payload TLV[
                          EAP-Request/Identity]])

  // TLS channel established
     (messages sent within the TLS channel)

  // First EAP Payload TLV is coalesced with the TLS Finished as
     Application Data and protected by the TLS tunnel.

  EAP-Payload TLV
  [EAP-Response/Identity (MyID2)]->

  // identity protected by TLS.

                           <- EAP-Payload TLV
                           [EAP-Request/EAP-Type=X]

  EAP-Payload TLV
  [EAP-Response/EAP-Type=X] ->

  // Method X exchanges followed by Protected Termination

                       <- Intermediate-Result TLV (Success),
                           Crypto-Binding TLV (Request),
                           Result TLV (Success)

  Intermediate-Result TLV (Success),
  Crypto-Binding TLV (Response),
  Result TLV (Success) ->

  // TLS channel torn down
  (messages sent in cleartext)

                          <- EAP-Success
]]></artwork> EAP-Success]]></artwork>
      </section>
      <section numbered="false" numbered="true" anchor="c6-sequence-of-eap-methods">
        <name>C.6.  Sequence
        <name>Sequence of EAP Methods</name>
        <t>When TEAP is negotiated with a sequence of EAP method X followed by
method Y, the conversation will occur as follows:</t>
        <artwork><![CDATA[
  Authenticating Peer     Authenticator
  -------------------     -------------
                          <- EAP-Request/
                          Identity
  EAP-Response/
  Identity (MyID1) ->
                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TEAP Start, S bit set, Authority-ID)

  EAP-Response/
  EAP-Type=TEAP, V=1
  (TLS client_hello)->

                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TLS server_hello,
                           TLS certificate,
                          [TLS server_key_exchange,]
                          [TLS certificate_request,]
                           TLS server_hello_done)
  EAP-Response/
  EAP-Type=TEAP, V=1
  ([TLS certificate,]
   TLS client_key_exchange,
  [TLS certificate_verify,]
   TLS change_cipher_spec,
   TLS finished) ->
                         <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TLS change_cipher_spec,
                           TLS finished,
                           Identity-Type TLV,
                          EAP-Payload TLV[
                          EAP-Request/Identity])

  // TLS channel established
     (messages sent within the TLS channel)

  // First EAP Payload TLV is coalesced with the TLS Finished as
     Application Data and protected by the TLS tunnel

  Identity_Type TLV
  EAP-Payload TLV
  [EAP-Response/Identity] ->

                          <- EAP-Payload TLV
                        [EAP-Request/EAP-Type=X]

  EAP-Payload TLV
  [EAP-Response/EAP-Type=X] ->

         // Optional additional X Method exchanges...

                         <- EAP-Payload TLV
                        [EAP-Request/EAP-Type=X]

  EAP-Payload TLV
  [EAP-Response/EAP-Type=X]->

                          <- Intermediate Result TLV (Success),
                           Crypto-Binding TLV (Request),
                           Identity-Type TLV,
                          EAP-Payload TLV[
                          EAP-Request/Identity])

  // Compound-MAC calculated using keys generated from
     EAP method X and the TLS tunnel.

  // Next EAP conversation started (with EAP-Request/Identity)
     after successful completion of previous method X.  The
     Intermediate-Result and Crypto-Binding TLVs are sent in
     the next packet to minimize round trips.

  Intermediate Result TLV (Success),
  Crypto-Binding TLV (Response),
  EAP-Payload TLV [EAP-Response/Identity (MyID2)] ->

         // Optional additional EAP method Y exchanges...

                         <- EAP Payload TLV [
                         EAP-Type=Y]

  EAP Payload TLV
  [EAP-Type=Y] ->

                         <- Intermediate-Result TLV (Success),
                           Crypto-Binding TLV (Request),
                           Result TLV (Success)

  Intermediate-Result TLV (Success),
  Crypto-Binding TLV (Response),
  Result TLV (Success) ->

  // Compound-MAC calculated using keys generated from EAP
     methods X and Y and the TLS tunnel.  Compound keys are
     generated using keys generated from EAP methods X and Y
     and the TLS tunnel.

  // TLS channel torn down (messages sent in cleartext)

                          <- EAP-Success
]]></artwork> EAP-Success]]></artwork>
      </section>
      <section numbered="false" numbered="true" anchor="c7-failed-crypto-binding">
        <name>C.7.  Failed
        <name>Failed Crypto-Binding</name>
        <t>The following exchanges show a failed crypto-binding validation.  The
conversation will appear as follows:</t>
        <artwork><![CDATA[
  Authenticating Peer     Authenticator
  -------------------     -------------
                          <- EAP-Request/
                          Identity
  EAP-Response/
  Identity (MyID1) ->
                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TEAP Start, S bit set, Authority-ID)

  EAP-Response/
  EAP-Type=TEAP, V=1
  (TLS client_hello) ->
                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TLS Server Key Exchange
                           TLS Server Hello Done)
  EAP-Response/
  EAP-Type=TEAP, V=1 ->
  (TLS Client Key Exchange
   TLS change_cipher_spec,
   TLS finished)

                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TLS change_cipher_spec
                           TLS finished)
                           EAP-Payload TLV[
                           EAP-Request/Identity])

     // TLS channel established
        (messages sent within the TLS channel)

     // First EAP Payload TLV is coalesced with the TLS Finished as
        Application Data and protected by the TLS tunnel.

  EAP-Payload TLV/
  EAP Identity Response ->

                         <-  EAP Payload TLV, EAP-Request,
                             (EAP-FAST-MSCHAPV2, Challenge)

  EAP Payload TLV, EAP-Response,
  (EAP-FAST-MSCHAPV2, Response) ->

                         <-  EAP Payload TLV, EAP-Request,
                             (EAP-FAST-MSCHAPV2, Success Request)

  EAP Payload TLV, EAP-Response,
  (EAP-FAST-MSCHAPV2, Success Response) ->

                       <- Intermediate-Result TLV (Success),
                           Crypto-Binding TLV (Request),
                              Result TLV (Success)

     Intermediate-Result TLV (Success),
     Result TLV (Failure)
     Error TLV with
     (Error Code = 2001) ->

  // TLS channel torn down
     (messages sent in cleartext)

                       <- EAP-Failure
]]></artwork> EAP-Failure]]></artwork>
      </section>
      <section numbered="false" numbered="true" anchor="c8-sequence-of-eap-method-with-vendor-specific-tlv-exchange">
        <name>C.8.  Sequence
        <name>Sequence of EAP Method with Vendor-Specific TLV Exchange</name>
        <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>
        <artwork><![CDATA[
  Authenticating Peer     Authenticator
  -------------------     -------------
                          <- EAP-Request/
                          Identity
  EAP-Response/
  Identity (MyID1) ->
                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TEAP Start, S bit set, Authority-ID)

  EAP-Response/
  EAP-Type=TEAP, V=1
  (TLS client_hello)->
                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TLS server_hello,
                           TLS certificate,
                   [TLS server_key_exchange,]
                   [TLS certificate_request,]
                       TLS server_hello_done)

  EAP-Response/
  EAP-Type=TEAP, V=1
  ([TLS certificate,]
   TLS client_key_exchange,
  [TLS certificate_verify,]
   TLS change_cipher_spec,
   TLS finished) ->
                         <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TLS change_cipher_spec,
                           TLS finished,
                          EAP-Payload TLV[
                          EAP-Request/Identity])

  // TLS channel established
     (messages sent within the TLS channel)

  // First EAP Payload TLV is coalesced with the TLS Finished as
     Application Data and protected by the TLS tunnel.

  EAP-Payload TLV
  [EAP-Response/Identity] ->

                        <- EAP-Payload TLV
                        [EAP-Request/EAP-Type=X]

  EAP-Payload TLV
  [EAP-Response/EAP-Type=X] ->

                         <- EAP-Payload TLV
                        [EAP-Request/EAP-Type=X]

  EAP-Payload TLV
  [EAP-Response/EAP-Type=X]->

                          <- Intermediate Result TLV (Success),
                           Crypto-Binding TLV (Request),
                           Vendor-Specific TLV,

  // Vendor-Specific TLV exchange started after successful
     completion of previous method X.  The Intermediate-Result
     and Crypto-Binding TLVs are sent with Vendor-Specific TLV
     in next packet to minimize round trips.

  // Compound-MAC calculated using keys generated from
     EAP method X and the TLS tunnel.

  Intermediate Result TLV (Success),
  Crypto-Binding TLV (Response),
  Vendor-Specific TLV ->

      // Optional additional Vendor-Specific TLV exchanges...

                         <- Vendor-Specific TLV

  Vendor-Specific TLV ->
                         <- Result TLV (Success)

  Result TLV (Success) ->

  // TLS channel torn down (messages sent in cleartext)

                          <- EAP-Success
]]></artwork> EAP-Success]]></artwork>
      </section>
      <section numbered="false" numbered="true" anchor="c9-peer-requests-inner-method-after-server-sends-result-tlv">
        <name>C.9.  Peer
        <name>Peer Requests Inner Method after After Server Sends Result TLV</name>
        <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
inner method, the conversation will appear as follows:</t>
        <artwork><![CDATA[
  Authenticating Peer    Authenticator
  -------------------    -------------
                         <- EAP-Request/Identity
  EAP-Response/
  Identity (MyID1) ->

  // Identity sent in the clear.  May be a hint to help route
     the authentication request to EAP server, instead of the
     full user identity. TLS client certificate is also sent.

                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TEAP Start, S bit set, Authority-ID)
  EAP-Response/
  EAP-Type=TEAP, V=1
  (TLS client_hello)->
                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TLS server_hello,
                           TLS certificate,
                          [TLS server_key_exchange,]
                          [TLS certificate_request,]
                           TLS server_hello_done)

  EAP-Response/
  EAP-Type=TEAP, V=1
  [TLS certificate,]
   TLS client_key_exchange,
  [TLS certificate_verify,]
   TLS change_cipher_spec,
   TLS finished ->
                          <- EAP-Request/
                          EAP-Type=TEAP, V=1
                          (TLS change_cipher_spec,
                           TLS finished,
                           Crypto-Binding TLV (Request),
                            Result TLV (Success))

  // TLS channel established
     (TLV Payload messages sent within the TLS channel)

   Crypto-Binding TLV(Response),
   Request-Action TLV
   (Status=Failure, Action=Negotiate-EAP)->

                        <- EAP-Payload TLV
                            [EAP-Request/Identity]

  EAP-Payload TLV
  [EAP-Response/Identity] ->

                        <- EAP-Payload TLV
                        [EAP-Request/EAP-Type=X]

  EAP-Payload TLV
  [EAP-Response/EAP-Type=X] ->

                         <- EAP-Payload TLV
                        [EAP-Request/EAP-Type=X]

  EAP-Payload TLV
  [EAP-Response/EAP-Type=X]->

                          <- Intermediate Result TLV (Success),
                             Crypto-Binding TLV (Request),
                             Result TLV (Success)

  Intermediate Result TLV (Success),
  Crypto-Binding TLV (Response),
  Result TLV (Success)) ->

  // TLS channel torn down
  (messages sent in cleartext)

                          <- EAP-Success
]]></artwork> EAP-Success]]></artwork>
      </section>
      <section numbered="false" numbered="true" anchor="c10-channel-binding">
        <name>C.10.  Channel
        <name>Channel Binding</name>
        <t>The following exchanges show a successful TEAP authentication with
basic password authentication and channel binding using a
Request-Action TLV.  The conversation will appear as follows:</t>
        <artwork><![CDATA[
   Authenticating Peer     Authenticator
   -------------------     -------------
                           <- EAP-Request/
                           Identity
   EAP-Response/
   Identity (MyID1) ->

                           <- EAP-Request/
                           EAP-Type=TEAP, V=1
                           (TEAP Start, S bit set, Authority-ID)

   EAP-Response/
   EAP-Type=TEAP, V=1
   (TLS client_hello) ->

                           <- EAP-Request/
                           EAP-Type=TEAP, V=1
                           (TLS server_hello,
                           (TLS change_cipher_spec,
                            TLS finished)

   EAP-Response/
   EAP-Type=TEAP, V=1 ->
   (TLS change_cipher_spec,
    TLS finished)

   TLS channel established
   (messages sent within the TLS channel)

                          <- Basic-Password-Auth-Req TLV, Challenge

   Basic-Password-Auth-Resp TLV, Response with both
   username and password) ->

   optional additional exchanges (new pin mode,
   password change, etc.) ...

                        <- Crypto-Binding TLV (Request),
                            Result TLV (Success),

   Crypto-Binding TLV(Response),
   Request-Action TLV
   (Status=Failure, Action=Process TLV,
   TLV=Channel-Binding TLV)->

                            <- Channel-Binding TLV (Response),
                            Result TLV (Success),

   Result TLV (Success) ->

   TLS channel torn down
   (messages sent in cleartext)

                           <- EAP-Success
]]></artwork> EAP-Success]]></artwork>
      </section>
      <section numbered="false" numbered="true" anchor="c11-pkcs-exchange">
        <name>C.11. PKCS
        <name>PKCS Exchange</name>
        <t>The following exchanges show the peer sending a PKCS#10 TLV, TLV and
server replying with a PKCS7 TLV. The exchange below assumes that the
EAP peer is authenticated in Phase 1, either via bi-directional bidirectional
certificate exchange, exchange or some other TLS method such as a proof of
knowledge (TLS-POK).  The conversation will appear as follows:</t>
        <artwork><![CDATA[
,----.                                             ,-------.
|Peer|                                             |AuthSrv|
`-+--'                                             `---+---'
  |               EAP-Request / Identity               |
  | <- - - - - - - - - - - - - - - - - - - - - - - - - -
  |                                                    |
  |           EAP-Response / Identity (MYID1)          |
  |  - - - - - - - - - - - - - - - - - - - - - - - - - >
  |                                                    |
  |             EAP-Request/EAP-Type=TEAP,             |
  |              V=1(TEAP Start,                       |
  |              S bit set,                            |
  |              Authority-ID)                         |
  | <- - - - - - - - - - - - - - - - - - - - - - - - - -
  |                                                    |
  |             EAP-Response/EAP-Type=TEAP,            |
  |              V=1(TLS client_hello)                 |
  |  - - - - - - - - - - - - - - - - - - - - - - - - - >
  |                                                    |
  |             EAP-Request/ EAP-Type=TEAP,            |
  |              V=1(TLS server_hello,                 |
  |              TLS certificate,                      |
  |              TLS certificate_request,              |
  |              TLS finished)                         |
  | <- - - - - - - - - - - - - - - - - - - - - - - - - -
  |                                                    |
  |        EAP-Response/EAP-Type=TEAP,                 |
  |         V=1(TLS change_cipher_spec,                |
  |             TLS certificate,                       |
  |        TLS finished) TLS channel established       |
  |  - - - - - - - - - - - - - - - - - - - - - - - - - >
  |                                                    |
  |               Send Request-Action TLV              |
  | <- - - - - - - - - - - - - - - - - - - - - - - - - -
  |                                                    |
  |                   Send PKCS10 TLV                  |
  |  - - - - - - - - - - - - - - - - - - - - - - - - - >
  |                                                    |
  | Sign the CSR and send PKCS7 TLV Intermediate-Result|
  | TLV request(Success),                              |
  |  Crypto-Binding TLV(Request),                      |
  |  Result TLV(Success)                               |
  | <- - - - - - - - - - - - - - - - - - - - - - - - - -
  |                                                    |
  |     Intermediate-Result TLV response(Success),     |
  |      Crypto-Binding TLV(Response),                 |
  |      Result TLV(Success)                           |
  |  - - - - - - - - - - - - - - - - - - - - - - - - - >
  |                                                    |
  |                     EAP Success                    |
  | <- - - - - - - - - - - - - - - - - - - - - - - - - -
]]></artwork> -]]></artwork>
      </section>
      <section numbered="false" numbered="true" anchor="c12-failure-scenario">
        <name>C.12. Failure
        <name>Failure Scenario</name>
        <t>The following exchanges shows show a failure scenario. The conversation
will appear as follows:</t>
        <artwork><![CDATA[
,----.                                                  ,-------.
|Peer|                                                  |AuthSrv|
`-+--'                                                  `---+---'
  |                  EAP-Request / Identity                 |
  | <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
  |                                                         |
  |             EAP-Response / Identity (MYID1)             |
  |  - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
  |                                                         |
  |          EAP-Request/EAP-Type=TEAP, V=1                 |
  |          (TEAP Start, S bit set, Authority-ID)          |
  | <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
  |                                                         |
  |    EAP-Response/EAP-Type=TEAP, V=1(TLS client_hello)    |
  |  - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
  |                                                         |
  | EAP-Request/ EAP-Type=TEAP, V=1                         |
  | (TLS server_hello,(TLS change_cipher_spec, TLS finished)|
  | <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
  |                                                         |
  |             EAP-Response/EAP-Type=TEAP, V=1             |
  |             (TLS change_cipher_spec,                    |
  |             TLS finished)                               |
  |             TLS channel established                     |
  |  - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
  |                                                         |
  |                    Request-Action TLV                   |
  | <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
  |                                                         |
  |                      Bad PKCS10 TLV                     |
  |  - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
  |                                                         |
  |        Intermediate-Result TLV request(Failure),        |
  |        Result TLV(Failure)                              |
  | <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
  |                                                         |
  |        Intermediate-Result TLV response(Failure),       |
  |        Result TLV(Failure)                              |
  |  - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
  |                                                         |
  |                       EAP Failure                       |
  | <- - - - - - - - - - - - - - - - - - - - - - - - - - - -
]]></artwork> -]]></artwork>
      </section>
      <section numbered="false" numbered="true" anchor="c13-client-certificate-in-phase-1">
        <name>C.13. Client certificate
        <name>Client Certificate in Phase 1</name>
        <t>The following exchanges shows show a scenario where the client certificate
is sent in Phase 1, 1 and no additional authentication or provisioning
is performed in Phase 2. The conversation will appear as follows:</t>
        <artwork><![CDATA[
,----.                                    ,-------.
|Peer|                                    |AuthSrv|
`-+--'                                    `---+---'
  |           EAP-Request / Identity          |
  | <- - - - - - - - - - - - - - - - - - - - -
  |                                           |
  |      EAP-Response / Identity (MYID1)      |
  |  - - - - - - - - - - - - - - - - - - - - ->
  |                                           |
  |         EAP-Request/EAP-Type=TEAP,        |
  |          V=1(TEAP Start,                  |
  |          S bit set,                       |
  |          Authority-ID)                    |
  | <- - - - - - - - - - - - - - - - - - - - -
  |                                           |
  |        EAP-Response/EAP-Type=TEAP,        |
  |         V=1(TLS client_hello)             |
  |  - - - - - - - - - - - - - - - - - - - - ->
  |                                           |
  |        EAP-Request/ EAP-Type=TEAP,        |
  |         V=1(TLS server_hello,             |
  |         TLS certificate,                  |
  |         TLS certificate_request,          |
  |         TLS change_cipher_spec,           |
  |         TLS finished)                     |
  | <- - - - - - - - - - - - - - - - - - - - -
  |                                           |
  |   EAP-Response/EAP-Type=TEAP,             |
  |    V=1(TLS certificate,                   |
  |        TLS change_cipher_spec,            |
  |   TLS finished) TLS channel established   |
  |  - - - - - - - - - - - - - - - - - - - - ->
  |                                           |
  |        Crypto-Binding TLV(Request),       |
  |        Result TLV(Success)                |
  | <- - - - - - - - - - - - - - - - - - - - -
  |                                           |
  |  Crypto-Binding TLV(Response),            |
  |  Result TLV(Success)                      |
  |  - - - - - - - - - - - - - - - - - - - - ->
  |                                           |
  |                EAP Success                |
  | <- - - - - - - - - - - - - - - - - - - - -
]]></artwork> -]]></artwork>
      </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</title>
            <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 protocol specifications. This

<!-- [rfced] Please review all verified errata reports for this document aims to reduce the ambiguity by clarifying and ensure
that only UPPERCASE usage of the key words all relevant errata 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 been addressed. See https://www.rfc-editor.org/errata/rfc7170.
-->

    <section anchor="acknowledgments" numbered="false">
      <name>Acknowledgments</name>
      <t>Nearly all of PKCS #9 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of text in this document, except for the security considerations section, is document was taken directly from that specification. This memo provides information for <xref
      target="RFC7170"/>. We are grateful to 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, original authors and change control is retained within the PKCS process. The body of this document, except
      reviewers for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 that document. This memo provides information for the Internet community.</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 (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support  The acknowledgments given here are only
      for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. 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. [STANDARDS-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 Server-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 session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained 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 resulted in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.</t>
              <t>This document obsoletes RFC 2716. A summary of the changes between this document document.</t>
      <t><contact fullname="Alexander Clouter"/> provided substantial 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</title>
            <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
      detailed technical feedback on nearly every aspect of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. specification.
      The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-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 Extended 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 Extended 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. Root keys are master keys that can be used for multiple purposes, identified by usage definitions. This document also specifies a mechanism for avoiding conflicts between root keys by deriving them corrections in a manner that guarantees cryptographic separation. Finally, this document also defines one such root key usage: Domain-Specific Root Keys are root keys made available to and used within specific key management 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 that. [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 Extension</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) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection 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 handshake 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 specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack. [STANDARDS-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-telnet, in accordance with RFC 5056 (On Channel Binding).</t>
              <t>Note that based on implementation experience, this document changes 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 Protocol (EAP) Methods</title>
            <author fullname="S. Hartman" initials="S." role="editor" surname="Hartman"/>
            <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 Extensible Authentication Protocol (EAP) methods to address the "lying Network Access Service (NAS)" problem as well as the "lying provider" problem. [STANDARDS-TRACK]</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="Harkins"/>
            <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 profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification 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</title>
            <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 Security (TLS) protocol. TLS allows client/server applications his work.</t>
      <t>We wish to communicate over thank the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</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 recommended cryptographic algorithms and mechanisms, and various government many reviewers and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 commenters in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, EMU WG,
      including <contact fullname="Eliot Lear"/>, <contact fullname="Joe
      Salowey"/>, <contact fullname="Heikki Vatiainen"/>, <contact
      fullname="Bruno Pereria Vidal"/>, and streamlines library <contact fullname="Michael
      Richardson"/>.  Many corner cases and product maintenance.</t>
              <t>This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, edge conditions were caught and there is no DTLS version 1.1.</t>
              <t>This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1,
      corrected as described herein. This document also updates the 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 with TLS 1.3</title>
            <author fullname="J. Preuß Mattsson" initials="J." surname="Preuß Mattsson"/>
            <author fullname="M. Sethi" initials="M." surname="Sethi"/>
            <date month="February" year="2022"/>
            <abstract>
              <t>The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, 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 result of their feedback.</t>
      <t><contact fullname="Jouni Malinin"/> initially pointed out the underlying 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 issues
      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 <xref target="RFC7170"/>.  Those comments resulted in RFC 9190. Many other EAP Types also depend on TLS, such as EAP-Flexible Authentication via Secure Tunneling (EAP-FAST) (RFC 4851), EAP-Tunneled TLS (EAP-TTLS) (RFC 5281), the Tunnel Extensible Authentication Protocol (TEAP) (RFC 7170). It is possible that many vendor-specific EAP methods, such as the Protected Extensible Authentication Protocol (PEAP), depend substantial discussion on TLS as well. This document updates those methods in order to use the new key derivation methods available in TLS 1.3. Additional changes necessitated by TLS 1.3 are 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 between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such 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 definition</title>
            <author fullname="Michael Richardson" initials="M." surname="Richardson">
              <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 Oheimb">
              <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 Transport
   (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)
      EMU WG mailing list, and eventually this document.  Jouni 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 made
      substantial contributions in its specification of the CSR Attributes
   Response.  This has analyzing corner cases, which resulted in implementation challenges and
   implementor confusion.  As a result, there was not universal
   understanding of what was specified.  This document clarifies
      the
   encoding rules.

   This document therefore also provides a new straightforward approach:
   using a template for CSR contents that may be partially filled text in by
   the server.  This also allows an EST server to specify a subject
   Distinguished Name (DN).

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-rfc7030-csrattrs-22"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="IEEE.802-1X.2020">
          <front>
            <title>*** BROKEN REFERENCE ***</title>
            <author>
              <organization/>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="KAMATH">
          <front>
            <title>Microsoft EAP CHAP Extensions</title>
            <author initials="R. H. and A." surname="Palekar" fullname="Ryan Hurst and Ashwin Palekar">
              <organization/>
            </author>
            <date year="2007" month="June"/>
          </front>
        </reference>
        <reference anchor="MSCHAP" target="https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-chap/5a860bf5-2aeb-485b-82ee-fac1e8e6b76f">
          <front>
            <title>Master Session Key (MSK) Derivation</title>
            <author initials="M." surname="Corporation" fullname="Microsoft Corporation">
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="NIST-SP-800-57">
          <front>
            <title>Recommendation for Key Management</title>
            <author initials="N. I. of S. and" surname="Technology" fullname="National Institute of Standards and Technology">
              <organization/>
            </author>
            <date year="2012" month="July"/>
          </front>
        </reference>
        <reference anchor="PEAP">
          <front>
            <title>[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)</title>
            <author initials="M." surname="Corporation" fullname="Microsoft Corporation">
              <organization/>
            </author>
            <date year="2014" month="February"/>
          </front>
        </reference>
        <reference anchor="RFC2315">
          <front>
            <title>PKCS #7: Cryptographic Message Syntax Version 1.5</title>
            <author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
            <date month="March" year="1998"/>
            <abstract>
              <t>This document describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. This memo provides information for the Internet community. <xref target="oops"/>.</t>
    </section>

<!--[rfced] Citations

It does not specify an Internet standard of any kind.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2315"/>
          <seriesInfo name="DOI" value="10.17487/RFC2315"/>
        </reference>
        <reference anchor="RFC3579">
          <front>
            <title>RADIUS (Remote Authentication Dial In User Service) Support For 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 Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method- specific code, which resides on the RADIUS server. While EAP was originally 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 Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full 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 Symmetric 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 exchange symmetric keys need to make the public keys resistant to some predetermined level of attack. That level of attack resistance is the strength of the system, and the symmetric keys appears that are exchanged must be at least as strong as the system 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 requirements section citations in terms of a symmetric key length and to choose a cipher that has a key length 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 function of a symmetric key strength requirement. Some rules of thumb for estimating equivalent resistance to large-scale attacks on various algorithms are given. The document also addresses how changing the sizes of the underlying large integers (moduli, group sizes, exponents, and so on) changes the time to use the algorithms for key exchange. This document specifies an Internet Best Current Practices for following sentences weren't
properly converted from Markdown. We have updated the Internet Community, and requests discussion and suggestions for improvements.</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 citations based on
the Extensible Authentication Protocol (EAP). This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments. The material in this document has been approved by IEEE 802.11 and is being presented as an IETF RFC for informational purposes. This memo 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="Eronen"/>
            <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 standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) anchor tags. Please review 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 3rd"/>
            <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 let us know if any further updates are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t>
              <t>Choosing random quantities
needed.

a) {#key-derivations} appears to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need broken citation to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions 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 data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</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 Authentication 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 (EAP) based Flexible Section 6.1 (TEAP
Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server. This memo provides 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 for X.509 (PKIX) certificate profile both provide frameworks that must be profiled for use in a given application. This document provides a profile of IKE and PKIX 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 materials, but which do not address PKI issues explicitly. This document addresses those issues. The intended audience is implementers of PKI for IPsec. [STANDARDS-TRACK]</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 (AAA) Phase 1: 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 Derivations).

Original:
 Implementations also useful need to designers of systems and solutions that include AAA key management protocols. Given the complexity and difficulty in designing secure, long-lasting key management algorithms and protocols by experts in implement the field, it is almost certainly inappropriate for IETF working groups without deep expertise inner method ordering
 described in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization, and Accounting (AAA) protocols. The guidelines {#key-derivations}, below, in this document apply to documents requesting publication as IETF RFCs. Further, these guidelines will be useful order to other standards development organizations (SDOs) that specify AAA key management. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions 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 Framework</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 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP authentication algorithms, known as "methods". It fully prevent on-
 path attacks.

Current:
 Implementations also provides a detailed system-level security analysis, describing 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 Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:</t>
              <t>1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and</t>
              <t>2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.</t>
              <t>CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. [STANDARDS-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 Certificate 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 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding implement the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is inner method ordering
 described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [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 Security Authenticated Protocol Version 0 (EAP-TTLSv0)</title>
            <author fullname="P. Funk" initials="P." surname="Funk"/>
            <author fullname="S. Blake-Wilson" initials="S." surname="Blake-Wilson"/>
            <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 handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated Section 6.1 in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols fully prevent
 on-path attacks

b) {#cert-provisioning} appears to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary 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 via 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 Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) broken citation to establish a mutually authenticated tunnel. Section 3.11.1
(Certificate Provisioning Within this tunnel, a basic password exchange, based on the Generic Token Card method (EAP-GTC), may be executed to authenticate the peer. This memo provides information for Tunnel).

Original:
 When 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 Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. EAP- FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use of EAP-FAST for dynamic provisioning. This memo provides information for the Internet 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 arbitrary 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 cannot be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack, and dictionary attack. This document is not an Internet Standards Track specification; it is published for informational 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 Definitions</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <date month="January" year="2011"/>
            <abstract>
              <t>This document provides specifications for existing TLS extensions. 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_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [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 Exchange (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 framework that allows the use of multiple authentication mechanisms. This document defines 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 authentication 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 purposes.</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 Protocol (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="Salowey"/>
            <date month="July" year="2012"/>
            <abstract>
              <t>This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This tunnel method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication, and the transport of additional data for other purposes. This document is not an Internet Standards Track specification; 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 Status 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 current status of a digital certificate without requiring Certificate Revocation Lists (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 Status 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) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of authenticated, the Certificate Status extension is commonly referred to peer MUST NOT
 request any services such as "OCSP stapling".) Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status 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 peers rely increasingly on information received provisioning ({#cert-
 provisioning}) from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. Cryptographic binding is a facility described in RFC 3748 that protects tunnel methods against man-in-the-middle attacks. However, cryptographic binding focuses on protecting it.

Current:
 When the server rather than the peer. This memo explores attacks possible when cannot be authenticated, the peer is not protected MUST NOT
 request any services such as certificate provisioning (Section 3.11.1)
 from man-in-the-middle attacks and recommends cryptographic binding 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</title>
            <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 Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) 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

c) {#separation-p1-p2} appears to have a standardized method that domains can use broken citation to identify each other'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 Section 8.3
(Separation of RFC 4282. It addresses issues with international character sets Phase 1 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 Phase 2 Servers).

Original:
 Note that using 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 MSK of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and all zeroes opens up TEAP to promote interoperability, their allocations 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 describing the conditions under which new values should be assigned, as well on-path attacks,
 as when 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, discussed below in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues {#separation-p1-p2}.

Current:
 Note that are likely in the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes RFC 5226.</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 using an MSK of Transport Layer Security (TLS) 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 Security (DTLS) are used all zeroes opens up TEAP 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, including on-path
 attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations as discussed in Section 8.3.

-->
<!-- [rfced] Abbreviations

a) FYI: Expansions appear for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of abbreviations upon first use cases.</t>
              <t>RFC 7525, an earlier version per
Section 3.6 of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition 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, this 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 (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <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, 7322 ("RFC Style Guide") and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow 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, dictionary sense; (c) use terms that abbreviations are already well-established used
after introduction. Please review each expansion 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 defined in RFC 4226, carefully to support the time-based moving factor. The HOTP algorithm specifies an event-based OTP algorithm, where the moving factor is an event counter. The present work bases the moving factor on a time value. A time-based variant 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
ensure correctness.

b) Should instances of network applications, from remote Virtual Private Network (VPN) access "TEAP protocol" and Wi-Fi network logon "EAP protocol" be updated to transaction-oriented Web applications. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial simply
read "TEAP" 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 "EAP" to EAP-pwd</title>
            <author fullname="D. Harkins" initials="D." surname="Harkins"/>
            <date month="April" year="2017"/>
            <abstract>
              <t>EAP-pwd is an avoid redundancy (if expanded, "TEAP protocol" would
read "Tunnel Extensible Authentication Protocol (EAP) method that utilizes a shared password for authentication using a technique that is resistant to dictionary attacks. It includes support for raw keys protocol" and double hashing of a password in the style of Microsoft Challenge Handshake "EAP protocol"
would read "Extensible Authentication Protocol version 2 (MSCHAPv2), but it does not include support for salted passwords. There Protocol"). Please review and let us
know if any updates are many existing databases needed.
-->

<!-- [rfced] Please review the "Inclusive Language" portion of salted passwords, the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and it let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is desirable to allow 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 helpful for readers. For example, please consider if "master" or "deficiency" should be updated. -->

<!-- [rfced] Terminology

a) Please review 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 Group was chartered, an object identifier arc was allocated by IANA following terms and let us know how we should
update for use by that working group. This document describes the object identifiers that were assigned consistency.

 Compound MAC vs. Compound-MAC vs. compound MAC
 crypto-binding vs. crypto binding
 Inner Method vs. inner method

b) Per usage in that arc, returns control RFC 7170, may we update all instances of that arc "outer TLV" to IANA, and establishes IANA allocation policies
"Outer TLV" 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 Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)</title>
            <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 (EAP) extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). This document obsoletes RFC 3770. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4334"/>
          <seriesInfo name="DOI" value="10.17487/RFC4334"/>
        </reference>
      </references>
    </references> consistency?
-->
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false"> toc="include">
      <name>Contributors</name>
      <contact initials="H." surname="Zhou" fullname="Han Zhou">
        <organization/>
        <address>
      </address>
      </contact>
      <contact initials="J." surname="Salowey" fullname="Joseph Salowey">
        <organization/>
        <address>
          <email>joe@salowey.net</email>
        </address>
      </contact>
      <contact initials="N." surname="Cam-Winget" fullname="Nancy Cam-Winget">
        <organization/>
        <address>
          <email>ncamwing@cisco.com</email>
        </address>
      </contact>
      <contact initials="S." surname="Hanna" fullname="Steve Hanna">
        <organization/>
        <address>
          <email>steve.hanna@infineon.com</email>
        </address>
      </contact>
    </section>
  </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>