<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.4.13 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-lear-eap-teap-brski-06" category="std" updates="RFC7170">

  <front>
    <title abbrev="TEAP Update and Extensions">TEAP Update and Extensions for Bootstrapping</title>

    <author initials="E." surname="Lear" fullname="Eliot Lear">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>Richtistrasse 7</street>
          <city>Wallisellen</city>
          <code>CH-8304</code>
          <country>Switzerland</country>
        </postal>
        <phone>+41 44 878 9200</phone>
        <email>lear@cisco.com</email>
      </address>
    </author>
    <author initials="O." surname="Friel" fullname="Owen Friel">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>170 W. Tasman Dr.</street>
          <city>San Jose, CA</city>
          <code>95134</code>
          <country>United States</country>
        </postal>
        <email>ofriel@cisco.com</email>
      </address>
    </author>
    <author initials="N." surname="Cam-Winget" fullname="Nancy Cam-Winget">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>170 W. Tasman Dr.</street>
          <city>San Jose, CA</city>
          <code>95134</code>
          <country>United States</country>
        </postal>
        <email>ncamwing@cisco.com</email>
      </address>
    </author>
    <author initials="D." surname="Harkins" fullname="Dan Harkins">
      <organization>HP Enterprise</organization>
      <address>
        <postal>
          <street>3333 Scott Boulevard</street>
          <city>Santa Clara, CA</city>
          <code>95054</code>
          <country>United States</country>
        </postal>
        <email>dharkins@arubanetworks.com</email>
      </address>
    </author>

    <date year="2021" month="August" day="25"/>

    
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>In certain environments, in order for a device to establish any layer
three communications, it is necessary for that device to be properly
credentialed.  This is a relatively easy problem to solve when a
device is associated with a human being and has both input and display
functions.  It is less easy when the human, input, and display
functions are not present.  To address this case, this memo specifies
extensions to the Tunnel Extensible Authentication Protocol (TEAP)
method that leverages Bootstrapping Remote Secure Key Infrastructures
(BRSKI) in order to provide a credential to a device at layer two.
The basis of this work is that a manufacturer will introduce the
device and the local deployment through cryptographic means.  In this
sense the same trust model as BRSKI is used.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t><xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> (BRSKI) specifies a means to
provision credentials to be used as credentials to operationally
access networks.  It was designed as a standalone means where some
limited access to an IP network is already available.  This is not
always the case.  For example, IEEE 802.11 networks generally require
authentication prior to any form of address assignment.  While it is
possible to assign an IP address to a device on some form of an open
network, or to accept some sort of default credential to establish
initial IP connectivity, the steps that would then follow might well
require that the device is placed on a new network, requiring reseting
all layer three parameters.</t>

<t>A more  natural approach  in such  cases is to  more tightly  bind the
provisioning  of credentials with  the authentication  mechanism.  One
such way  to do this is  to make use of  the Extensible Authentication
Protocol (EAP)  <xref target="RFC3748"/> and the  Tunnel Extensible Authentication
Protocol  (TEAP)  method  <xref target="RFC7170"/>.    Thus  we  define  new  TEAP
Type-Length-Value  (TLV) objects  that can  be used  to  transport the
BRSKI protocol messages within the context of a TEAP TLS tunnel.</t>

<t><xref target="RFC7170"/> discusses the notion of provisioning peers.  Several
different mechanisms are available.  Section 3.8 of that document
acknowledges the concept of not initially authenticating the outer TLS
session so that provisioning may occur.  In addition, exchange of
multiple TLV messages between client and EAP server permits multiple
provisioning steps.</t>

<section anchor="terminology" title="Terminology">

<t>The reader is presumed to be familiar with EAP terminology as stated
in <xref target="RFC3748"/>.  In addition, the following terms are commonly used in
this document.</t>

<t><list style="symbols">
  <t>BRSKI: Bootstrapping Remote Secure Key Infrastructures, as defined in
<xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>.  The term is also used
to refer to the flow described in that document.</t>
  <t>EST: Enrollment over Secure Transport, as defined in <xref target="RFC7030"/>.</t>
  <t>Voucher: a signed JSON object as defined in <xref target="RFC8366"/>.</t>
</list></t>

</section>
</section>
<section anchor="arch" title="TEAP BRSKI Architecture">

<t>The TEAP BRSKI architecture is illustrated in
<xref target="brski-architecture"/>. The device talks to the TEAP server via the
Authenticator using any compliant transport such as <xref target="IEEE8021X"></xref>.
The architecture illustrated shows an Authenticator distinct from
the TEAP server. This is a deployment optimization and when so
deployed the communication between Authenticator and TEAP server
is a AAA protocol such as RADIUS or DIAMETER.</t>

<t>The architecture illustrated shows a co-located TEAP server and
BRSKI registrar. Not only are these two functions co-located, they
MUST be the same entity. This ensures that the entity identified in
the device’s voucher request (the TEAP server) is the same entity
that signs the voucher request (the registrar).</t>

<t>The registrar communicates with the BRSKI MASA service for the
purposes of getting signed vouchers.</t>

<t>The registrar also communicates with a Certificate Authority in order
to issue LDevIDs. The architecture shows the registrar and CA as being
two logically separate entities, however the CA may be integrated into
the registrar. The device is not explicitly aware of whether the CA
and registrar functions are integrated.</t>

<figure><artwork><![CDATA[
+--------+     +---------+     +---------+     +------+
|        |     |         |     |  TEAP   |<--->| MASA |
|        |     | Authen- |     | server  |     +------+
| Device |<--->| ticator |<--->|         |
|        |     |         |     |  BRSKI  |     +------+
|        |     |         |     |Registrar|<--->|  CA  |
+--------+     +---------+     +---------+     +------+

]]></artwork></figure>

</section>
<section title="BRSKI Bootstrap and Enroll Operation" anchor="brski-architecture">

<t>This section summarises the current BRSKI operation. The BRSKI flow
assumes the device has an IDevID and has a manufacturer installed
trust anchor that can be used to validate the BRSKI voucher. The BRSKI
flow compromises serveral main steps from the perspective of the
device:</t>

<t><list style="symbols">
  <t>Step 1: Device discovers the registrar</t>
  <t>Step 2: Device establishes provisional TLS connection to registrar</t>
  <t>Step 3: Device sends voucher request message and receives signed voucher response</t>
  <t>Step 4: Device validates voucher and validates provisional TLS connection to registrar</t>
  <t>Step 5: Device downloads additional local domain CA information</t>
  <t>Step 6: Device downloads Certificate Signing Request (CSR) attributes</t>
  <t>Step 7: Device does a certificate enroll to obtain an LDevID</t>
  <t>Step 8: Device periodically reenrolls via EST to refresh its LDevID</t>
</list></t>

<t>Most of the operational steps require the device, and thus its internal state machine, to automatically complete the next step without being explicitly instructed to do so by the registrar. For example, the registrar does not explicitly tell the device to download additional local domain CA information, or to do an EST enroll to obtain an LDevID.</t>

<section anchor="discovery-of-trusted-masa" title="Discovery of Trusted MASA">

<t>BRSKI section 2.8 outlines how the Registrar discovers the correct MASA to connect with. BRSKI section 5.3 outlines how the Registrar can make policy decisions about which devices to trust.</t>

<t>Similar approaches are applicable for TEAP servers executing BRSKI. For example, the TEAP server may be configured with a list of trusted manufacturing CAs. During device bootstrap, only devices with an IDevID signed by a trusted manufacturing CA may be allowed to etablishes a TLS connection with the TEAP server, and the TEAP server could then extract the MASA URI from the device’s IDevID.</t>

</section>
<section anchor="bint" title="Executing BRSKI in a TEAP Tunnel">

<t>This section outlines how the main BRSKI steps outlined above map to TEAP, and how BRSKI and enrollment can be accomplished inside a TEAP TLS tunnel. The following new TEAP TLVs are introduced:</t>

<t><list style="symbols">
  <t>BRSKI-VoucherRequest</t>
  <t>BRSKI-Voucher</t>
  <t>CSR-Attributes</t>
</list></t>

<t>The following steps outline how the above BRSKI flow maps to TEAP.</t>

<t><list style="symbols">
  <t>Step 1: Device discovers the registrar</t>
</list></t>

<t>When BRSKI is executed in a TEAP tunnel, the device exchanges BRSKI TLVs with the TEAP server. The discovery process for devices is therefore the standard wired or wireless LAN EAP server discovery process. The discovery processes outlined in section 4 of <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> are not required for initial discovery of the registrar.</t>

<t><list style="symbols">
  <t>Step 2: Device establishes provisional TLS connection to registrar</t>
</list></t>

<t>The device establishes an outer TEAP tunnel with the TEAP server and
does not validate the server certificate. 
The device presents its LDevID as its identity
certificate if it has a valid LDevID, otherwise it presents its
IDevID. The TEAP server validates the device’s certificate using
its implicit or explicit trust anchor database. If the device
presents an IDevID it is verified against a database of trusted
manufacturer certificates. Server policy may also be used to control
which certificate the device is allowed present, as described in
section {pki-certificate-authority-considerations}.</t>

<t>If the presented credential is sufficient to grant access, the TEAP server can return a TEAP Result TLV indicating success immediately. The device may still send a Request-Action TLV including a BRSKI-VoucherRequest TLV in response to the TEAP Result TLV if it does not have, but requires, provisioning of trust anchors for validating the TEAP server certificate. Note that no inner EAP method is required for this, only an exchange of TEAP TLVs.</t>

<t>[todo] Question: as the device wants the server to reply with a BRSKI-Voucher TLV, does it really send a Request-Action TLV containing a BRSKI-VoucherRequest TLV, or does it send a Request-Action TLV containing a BRSKI-Voucher TLV?? The TEAP draft is a bit ambiguous here. Normally, if one end sends a Request-Action including XXX-TLV, it means it wants the far end ot send an XXX-TLV…</t>

<t>[todo] Question: general TEAP protocol question: does the device have to send a Request-Action w/BRSKI-VoucherRequest or can it send a BRSKI-VoucherRequest on its own? I’m not clear on this.</t>

<t>If the TEAP server requires that the device execute a BRSKI flow, the server sends a Request-Action TLV that includes a BRSKI-VoucherRequest TLV. For example, if the device presented its IDevID but the TEAP server requires an LDevID.</t>

<t>[todo] Question: to nit pick, the server should send a Request-Action TLV including a PKCS#10 TLV to tell the client to enroll. How does the server really know that the client has the correct trust established (as previously received by a BRSKI-Voucher)? If the client sends an IDevID, does server always send a Request-Action including both BRSKI-VoucherRequest and PKCS#10 TLVs? Whats the client behaviour? I assume client can spontaneously send BRSKI-VoucherRequest and/or PCSK#10 without being explicitly instructed to. Just need to get the language correct here.</t>

<t>The TEAP server may also require the device to reenroll, for example, if the device presented a valid LDevID that is very closed to expiration. The server may instruct a device to reenroll by sending a Request-Action TLV that includes a zero byte length PKCS#10 TLV.</t>

<t><list style="symbols">
  <t>Step 3: Device sends voucher request message and receives signed voucher response</t>
</list></t>

<t>The device sends a BRSKI-RequestVoucher TLV to the TEAP server. The
TEAP server forwards the RequestVoucher message to the MASA server,
and the MASA server replies with a signed voucher. The TEAP server
sends a BRSKI-Voucher TLV to the device.</t>

<t>If the MASA server does not issue a signed voucher, the TEAP server
sends an EAP-Error TLV with a suitable error code to the device.</t>

<t>For wireless devices in particular, it is important that the MASA
server only return a voucher for devices known to be associated with a
particular registrar.  In this sense, success indicates that the
device is on the correct network, while failure indicates the device
should try to provision itself within wireless networks (e.g, go to
the next SSID).</t>

<t><list style="symbols">
  <t>Step 4: Device validates voucher and validates provisional TLS connection to registrar</t>
</list></t>

<t>The device validates the signed voucher using its manufacturer
installed trust anchor, and uses the CA information in the voucher to
validate the TLS connection to the TEAP server.</t>

<t>If the device fails to validate the voucher, then it sends a TEAP-Error TLV indicating failiure to the TEAP server.</t>

<t>Similarly, if the device validates the voucher, but fails to validate the provisional TLS connection, then it sends a TEAP-Error TLV indicating failure to the TEAP server. Note that the outer TLS tunnel has already been established, thus allowing the client to send a TEAP-Error TLV to the server inside that tunnel to indicate that it failed to verify the provisionally accepted outer TLS tunnel server identity.</t>

<t><list style="symbols">
  <t>Step 5: Device downloads additional local domain CA information</t>
</list></t>

<t>On completion of the BRSKI flow, the device SHOULD send a
Trusted-Server-Root TLV to the TEAP server in order to discover
additional local domain CAs. This is equivalent to section [todo] from <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>.</t>

<t><list style="symbols">
  <t>Step 6: Device downloads CSR attributes</t>
</list></t>

<t>No later than the completion of step 5, server MUST send a
CSR-Attributes TLV to peer server in order to discover the correct
fields to include when it enrolls to get an LDevID.</t>

<t><list style="symbols">
  <t>Step 7: Device does a certificate enroll to obtain an LDevID</t>
</list></t>

<t>When executing the BRSKI flow inside a TEAP tunnel, the device does
not directly leverage EST when doing its initial enroll. Instead, the
device uses the existing TEAP PKCS#10 and PCKS#7 TEAP mechanisms.</t>

<t>Once the BRSKI flow is complete, the device can now send a PKCS#10 TLV
to enroll and request an LDevID. If the TEAP server instructed the
device to start the BRSKI flow via a Request-Action TLV that includes
a BRSKI-RequestVoucher TLV, then the device MUST send a PKCS#10 in
order to start the enroll process. The TEAP server will handle the
PKCS#10 and ultimately return a PKCS#7 including an LDevID to the
device.</t>

<t>If the TEAP server granted the device access on completion of the
outer TEAP TLS tunnel in step 2 without sending a Request-Action TLV,
the device does not have to send a PKCS#10 to enroll.</t>

<t>At this point, the device is said to be provisioned for local network
access, and may authenticate in the future via 802.1X with its newly
acquired credentials.</t>

<t><list style="symbols">
  <t>Step 8: Device periodically reenrolls to refresh its LDevID</t>
</list></t>

<t>When a device’s LDevID is close to expiration, there are two options
for re-enrollment in order to obtain a fresh LDevID. As outlined in
Step 2 above, the TEAP server may instruct the device to reenroll by
sending a Request-Action TLV including a PKCS#10 TLV. If the TEAP
server explicilty instructs the device to reenroll via these TLV
exchange, then the device MUST send a PKCS#10 to reenroll and request
a fresh LDevID.</t>

<t>However, the device SHOULD reenroll if it determines that its LDevID
is close to expiration without waiting for explicit instruction from
the TEAP server. There are two options to do this.</t>

<t>Option 1: The device reenrolls for a new LDevID directly with the EST
CA outside the context of the 802.1X TEAP flow. The device uses the
registrar discovery mechanisms oulined in
<xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> to discover the registrar
and the device sends the EST reenroll messages to the discovered
registrar endpoint. No new TEAP TLVs are defined to facilitate
discover of the registrar or EST endpoints inside the context of the
TEAP tunnel.</t>

<t>Option 2: When the device is performing a periodic 802.1X
authentication using its current LDevID, it reenrolls for a new LDevID
by sending a PKCS#10 TLV inside the TEAP TLS tunnel.</t>

</section>
</section>
<section anchor="pki-certificate-considerations" title="PKI Certificate Considerations">

<t>There are multiple noteworthy PKI certificate handling considerations. These include:</t>

<t><list style="symbols">
  <t>PKI CA handling when establishing the TEAP tunnel</t>
  <t>PKI CA handling establishing trust using BRSKI</t>
  <t>IDevID and LDevID expiration times</t>
  <t>Specifying LDevID Subject and Subject Alternative Names</t>
  <t>PKCS#10 retry handling</t>
</list></t>

<t>These are described in more detail here.</t>

<section anchor="teap-tunnel-establishment" title="TEAP Tunnel Establishment">

<t>Because this method establishes a client identity, if the peer has not
been previously bootstrapped, or otherwise cannot successfully
authenticate, it will use a generic identity string of teap-bootstrap@TBD1
as its network access identifier (NAI).</t>

<t>BRSKI section 5.3 outlines the policy decisions a Registrar may make when deciding whether to accept connections from clients. Similarly, the TEAP server operator may configure a set of trusted CAs for validating incoming TLS connections from clients. The operator may want to ‘allow any device from a specific vendor’, or from a set of vendors, to access the network. Network operators may do this by restricting network access to clients that have a certificate signed by one of a small set of trusted manufacturer/supplier CAs.</t>

<t>When the client sends its ClientHello to initiate TLS tunnel establishment, it is possible for the TEAP server to restrict the certificates that the client can use for tunnel establishment by including a list of CA distinguished names in the certificate_authorities field in the CertificateRequest message. The client should only continue with the handshake if it has a certificate signed by one of the indicated CAs.</t>

<t>In practice, network operators will likely want to onboard devices from a large number of device manufacturers, with each manufacturer using a different root CA when issuing IDevIDs. If the number of different manufacturer root CAs is large, this could result in very large TLS handshake messages. Therefore, the TEAP server may send a CertificateRequest message and not specify any certificate_authorities, thus allowing the client present a certificate signed by any authority in its Certificate message.</t>

<t>If the client has both an IDevID and an LDevID, the client should present the LDevID in preference to its IDevID, if allowed by server policy.</t>

<t>Once the client has sent its TLS Finished message, the TEAP server can make a policy decision, based on the CA used to sign the client’s certificate, on whether to establish the outer TLS tunnel or not.</t>

<t>The TEAP server may delegate policy decisions to the MASA or CA function. For example, the TEAP server may declare EAP success and grant network access if the client presents a valid LDevID signed by a trusted domain CA. However, if the client presents an IDevID signed by a trusted manufacturer CA, the TEAP server may establish the TLS tunnel but not declare EAP success and grant network access until the client successfully completes a BRSKI Voucher exchange and PKCS#10/PKCS#7 exchange inside that tunnel.</t>

<t>It is recommended that the client validate the certificate presented
by the server in the server’s Certificate message, but this may not be
possible for clients that have not yet provisioned appropriate trust
anchors. If the client is in the provisioning phase and
has not yet completed a BRSKI flow, it will not have trust anchors
installed yet, and thus will not be able to validate the server’s
certificate. The client must however note the certificate presented by
the server for (i) inclusion in the BRSKI-RequestVoucher TLV and for
(ii) validation once the client has discovered the local domain trust
anchors.</t>

<t>If the client does not present a suitable certificate to the server, the server MUST terminate the connection and fail the EAP request. If the TEAP server is unable to validate the client’s certificate using its implicit or explicit trust anchor database it MUST fail the EAP request.</t>

<t>On establishment of the outer TLS tunnel, the TEAP server will make a policy decision on next steps. Possible policy decisions include:</t>

<t><list style="symbols">
  <t>Option 1: Server grants client full network access and returns EAP-Success. This will typically happen when the client presents a valid LDevID. Network policy may grant client network access based on IDevID without requiring the device to enroll to obtain an LDevID.</t>
  <t>Option 2: Server requires that client perform a full BRSKI flow, and then enroll to get an LDevID. This will typically happen when the client presents a valid IDevID and network policy requires all clients to have LDevIDs. The server sends a Request-Action TLV that includes a BRSKI-RequestVoucher TLV to the client to instruct it to start the BRSKI flow.</t>
  <t>Option 3: Server requires that the client reenroll to obtain a new LDevID. This could happen when the client presents a valid LDevID that is very close to expiration time, or the server’s policy requires an LDevID update. The server sends an Action-Request TLV including a PKCS#10 TLV to the client to instruct it to reenroll.</t>
</list></t>

</section>
<section anchor="brski-trust-establishment" title="BRSKI Trust Establishment">

<t>If the server requires that client perform a full BRSKI flow, it sends a Request-Action TLV that includes a zero byte length BRSKI-RequestVoucher TLV to the client. The client sends a new BRSKI-RequestVoucher TLV to the server, which contains all data specified in <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> section 5.2. The client includes the server certificate it received in the server’s Certificate message during outer TLS tunnel establishment in the proximity-registrar-cert field. The client signs the request using its IDevID.</t>

<t>The server includes all additional information as required by <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> section 5.4 and signs the request prior to forwarding to the MASA.</t>

<t>The MASA responds as per <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> section 5.5. The response may indicate failure and the server should react accordingly to failures by sending a failure response to the client, and failing the TEAP method.</t>

<t>If the MASA replies with a signed voucher and a successful result, the server then forwards this response to the client in a BRSKI-Voucher TLV.</t>

<t>When the client receives the signed voucher, it validates the signature using its built in trust anchor list, and extracts the pinned-domain-cert field. The client must use the CA included in the pinned-domain-cert to validate the certificate that was presented by the server when establishing the outer TLS tunnel. If this certificate validation fails, the client must fail the TEAP request and not connect to the network.</t>

<t>[TBD- based on client responses, the registrar sends a status update
to the MASA]</t>

</section>
<section anchor="certificate-expiration-times" title="Certificate Expiration Times">

<t><xref target="IEEE8021AR"></xref> section 7.2.7.2 states:</t>

<t><list style='empty'>
  <t>notAfter: The latest time a DevID is expected to be used. Devices possessing an IDevID are expected to operate indefinitely into the future and should use the value 99991231235959Z. Solutions verifying an IDevID are expected to accept this value indefinitely.</t>
</list></t>

<t>TEAP servers SHOULD follow the 802.1AR standard when validating IDevIDs.</t>

<t>TEAP servers SHOULD reject LDevIDs with expired certificates and SHOULD NOT allow clients to connect with recently expired LDevIDs. If a client presents a recently expired LDevID it SHOULD be forced to authenticate using its IDevID and then reenroll to obtain a valid LDevID.</t>

</section>
<section anchor="ldevid-subject-and-subject-alternative-names" title="LDevID Subject and Subject Alternative Names">

<t>BRSKI section 5.9.2 specifies that the pledge MUST send a CSR Attributes request to the registrar. The registrar MAY use this mechanism to instruct the pledge about the identities it should include in the CSR request it sends as part of enrollment. The registrar may use this mechanism to tell the pledge what Subject or Subject Alternative Name identity information to include in its CSR request. This can be useful if the Subject must have a specific value in order to complete enrollment with the CA.</t>

</section>
<section anchor="pkcs10-retry-handling" title="PKCS#10 Retry Handling">

<t>They will be scenarios where the TEAP server is willing to handle a PKCS#10 request from a client and issue a certificate via a PKCS#7 response, however, the TEAP server is unable to immediately completely the request and needs to instruct the client to retry later after a specified time interval.</t>

<t>A new Retry-After TLV is defined that the TEAP server uses to specify a retry interval in seconds. New error codes are defined to handle these two alternate retry scenarios.</t>

<t><list style="symbols">
  <t>The TEAP tunnel remains up: The client is instructed to resend the PKCS#10 request after a retry interval but inside the same TEAP tunnel. The TEAP server returns a Retry-After TLV to the client, and returns an Error TLV with a new code in the 1000-1999 range.</t>
  <t>The TEAP tunnel is torn down: The client is instructed to establish a new TEAP connection and TEAP tunnel after a retry interval, and resend the PKCS#10 request indside the new tunnel.  The TEAP server returns a Retry-After TLV to the client, and returns an Error TLV with a new code in the 2000-2999 range.</t>
</list></t>

</section>
</section>
<section anchor="peer-identity" title="Peer Identity">

<t>EAP <xref target="RFC3748"/> recommends that “the Identity Response be used primarily for routing purposes and selecting which EAP method to use”. NAI <xref target="RFC7542"/> recommends ommitting the username part of an NAI in order to support username privacy, where appropriate.</t>

<t>A device that has not been bootstrapped at all SHOULD send an identity of
teap-bootstrap@TBD1.  Otherwise, a device SHOULD send its configured NAI.</t>

<t>The TEAP server may specify an NAI that it wishes the device to use. For example, the server may want a bootstrapped device to use an NAI of “abc123@example.com”, or simply an NAI of “@example.com”. This could be desirable in order to facilitate roaming scenarios. The server can do this by sending the device an NAI TLV inside the TEAP tunnel.</t>

<t>If the server specifies an NAI TLV, and the device handles the TLV, the device MAY use the specified NAI in all subsequent EAP authentication flows. If the device is not willing to handle the NAI TLV, it MUST reply with an Error TLV.</t>

<t>Authentication servers implementing this specification MAY reply with
an Error TLV to any unrecognized NAI, or MAY attempt to bootstrap the
device, regardless of the NAI.  A device receving an Error from the
server MAY attempt a new session without the NAI in order to
bootstrap.</t>

</section>
<section anchor="channel-and-crypto-binding" title="Channel and Crypto Binding">

<t>As the TEAP BRSKI flow does not define or require an inner EAP method, there is no explicit need for exchange of Channel-Binding TLVs between the device and the TEAP server.</t>

<t>The TEAP BRSKI TLVs are expected to occur at the beginning of the TEAP Phase 2 and MUST occur before the final Crypto-Binding TLV.  This draft does not exclude the possibility of having other EAP methods occur following the TEAP BRSKI TLVs and as such, the Crypto-Binding TLV process rules as defined in <xref target="RFC7170"/> apply.</t>

</section>
<section anchor="protocol-flows" title="Protocol Flows">

<t>This section outlines protocol flows that map to the three server policy
options described in section <xref target="teap-tunnel-establishment"/>. The
protocol flows illustrate a TLS1.2 exchange. Pertinent notes are
outlined in the protocol flows.</t>

<section anchor="teap-server-grants-access" title="TEAP Server Grants Access">

<t>In this flow, the server grants access as server policy allows the client to access the network based on the identity certificate that the client presented. This means that either (i) the client has previously completed BRSKI and has presented a valid LDevID or (ii) the client presents an IDevID and network policy allows access based purely on IDevID.</t>

<figure title="TEAP Server Grants Access" anchor="flow-1"><artwork><![CDATA[
      ,------.             ,----------.
      |Client|             |TEAPServer|
      `--+---'             `----+-----'
         |     EAP-Request/     |      
         |     Identity         |      
         | <---------------------      
         |                      |      
         |     EAP-Response/    |      
         |     Type=Identity    |      
         | --------------------->      
         |                      |      
         |   EAP-Request/       |      
         |   Type=TEAP,         |      
         |   TEAP Start,        |      
         |   Authority-ID TLV   |      
         | <---------------------      
         |                      |      
         |   EAP-Response/      |      
         |   Type=TEAP,         |      
         |   TLS(ClientHello)   |      
         | --------------------->      
         |                      |      
         |  EAP-Request/        |      
  ,---!. |  Type=TEAP,          |      
  |(1)|_\|  TLS(ServerHello,    |      
  |(2)  ||  ServerKeyExchange,  |      
  `-----'|  ServerHelloDone)    |      
         | <---------------------      
         |                      |      
         |  EAP-Response/       |      
         |  Type=TEAP,          |      
  ,---!. |  ClientKeyExchange,  |      
  |(3)|_\|  CertificateVerify,  |      
  `-----'|  ChangeCipherSpec,   |      
         |  Finished)           |      
         | --------------------->      
         |                      |      
         | EAP-Request/         |      
         | Type=TEAP,           |      
         | TLS(ChangeCipherSpec,|      
         | Finished),           |      
         | {Crypto-Binding TLV, |      
         | Result TLV=Success}  |      
         | <---------------------      
         |                      |      
         | EAP-Response/        |      
         | Type=TEAP,           |      
         | {Crypto-Binding TLV, |      
         | Result TLV=Success}  |      
         | --------------------->      
         |                      |      
         |      EAP-Success     |      
         | <---------------------      
      ,--+---.             ,----+-----.
      |Client|             |TEAPServer|
      `------'             `----------'
]]></artwork></figure>

<t>Notes:</t>

<t>(1) If the client has completed the BRSKI flow and has locally significant trust anchors, it must validate the Certificate received from the server. If the client has not yet completed the BRSKI flow, then it provisionally accepts the server Certificate and must validate it later once BRSKI is complete.</t>

<t>(2) The server may include certificate_authorities field in the CertificateRequest message in order to restrict the identity certificates that the device is allowed present.</t>

<t>(3) The device will present its LDevID, if it has one, in preference to its IDevID, if allowed by server policy.</t>

</section>
<section anchor="teap-server-instructs-client-to-perform-brski-flow" title="TEAP Server Instructs Client to Perform BRSKI Flow">

<t>In this two part flow, the server instructs the client to perform a BRSKI flow by exchanging TLVs once the outer TLS tunnel is established.  After that, enrollment takes place.</t>

<t>In the first part of the flow, the MASA is depicted on the right.</t>

<figure title="TEAP Server Instructs Client to Perform BRSKI Flow" anchor="flow-2a"><artwork><![CDATA[
      ,------.                           ,----------.          ,----.
      |Client|                           |TEAPServer|          |MASA|
      `--+---'                           `----+-----'          `-+--'
         |            EAP-Request/            |                  |   
         |            Type=Identity           |                  |   
         | <-----------------------------------                  |   
         |                                    |                  |   
         |            EAP-Response/           |                  |   
         |            Type=Identity           |                  |   
         | ----------------------------------->                  |   
         |                                    |                  |   
         |          EAP-Request/              |                  |   
  ,---!. |          Type=TEAP,                |                  |   
  |(1)|_\|          TEAP Start,               |                  |   
  `-----'|          Authority-ID TLV          |                  |   
         | <-----------------------------------                  |   
         |                                    |                  |   
         |          EAP-Response/             |                  |   
         |          Type=TEAP,                |                  |   
         |          TLS(ClientHello)          |                  |   
         | ----------------------------------->                  |   
         |                                    |                  |   
         |         EAP-Request/               |                  |   
         |         Type=TEAP,                 |                  |   
         |         TLS(ServerHello,           |                  |   
         |         Certificate,               |                  |   
         |         ServerKeyExchange,         |                  |   
         |         CertificateRequest,        |                  |   
         |         ServerHelloDone)           |                  |   
         | <-----------------------------------                  |   
         |                                    |                  |   
         |         EAP-Response/              |                  |   
         |         Type=TEAP,                 |                  |   
         |         TLS(Certificate            |                  |   
         |         ClientKeyExchange,         |                  |   
         |         CertificateVerify,         |                  |   
         |         ChangeCipherSpec,          |                  |   
         |         Finished)                  |                  |   
         | ----------------------------------->                  |   
         |                                    |                  |   
         |        EAP-Request/                |                  |   
         |        Type=TEAP,                  |                  |   
         |        TLS(ChangeCipherSpec,       |                  |   
         |        Finished),                  |                  |   
         |        {Crypto-Binding TLV,        |                  |   
         |        Result TLV=Success}         |                  |   
         | <-----------------------------------                  |   
         |                                    |                  |   
         |        EAP-Response/               |                  |   
         |        ,Type=TEAP,                 |                  |   
         |        {Crypto-Binding TLV,        |                  |   
         |        Result TLV=Success}         |                  |   
         | ----------------------------------->                  |   
         |                                    |                  |   
  ,-------------------------------------------------!.           |   
  |At this stage the outer TLS tunnel is established|_\          |   
  |The following message exchanges are for BRSKI      |          |   
  `---------------------------------------------------'          |   
         |      EAP-Request/                  |                  |   
         |      Type=TEAP,                    |                  |   
         |      {Request-Action TLV:          |                  |   
         |      Status=Failure,               |                  |   
  ,---!. |      Action=Process-TLV,           |                  |   
  |(2)|_\|      TLV=Request-Voucher,          |                  |   
  `-----'|      TLV=Trusted-Server-Root,      |                  |   
         |      TLV=CSR-Attributes,           |                  |   
         |      TLV=PKCS#10}                  |                  |   
         | <-----------------------------------                  |   
         |                                    |                  |   
         |        EAP-Response/               |                  |   
  ,---!. |        Type=TEAP,                  |                  |   
  |(3)|_\|        {Request-Voucher TLV}       |                  |   
  `-----'| ----------------------------------->                  |   
         |                                    |                  |   
         |                                    |  RequestVoucher  |   
         |                                    | ----------------->   
         |                                    |                  |   
         |                                    |      Voucher     |   
         |                                    | <-----------------   
         |                                    |                  |   
         |            EAP-Request/            |                  |   
  ,---!. |            Type=TEAP,              |                  |   
  |(4)|_\|            {Voucher TLV}           |                  |   
  `-----'| <-----------------------------------                  |   
         |                                    |                  |   
         | EAP-Response/                      |                  |   
         | Type=TEAP,{Trusted-Server-Root TLV}|                  |   
         | ----------------------------------->                  |   
         |                                    |                  |   
         |      EAP-Request/                  |                  |   
  ,---!. |      Type=TEAP,                    |                  |   
  |(5)|_\|      {Trusted-Server-Root TLV}     |                  |   
  `-----'| <-----------------------------------                  |   
         |                                    |                  |   
         |   EAP-Response/                    |                  |   
         |   Type=TEAP,{CSR-Attributes TLV}   |                  |   
         | ----------------------------------->                  |   
         |                                    |                  |   
         |        EAP-Request/                |                  |   
         |        Type=TEAP,                  |                  |   
         |        {CSR-Attributes TLV}        |                  |   
         | <-----------------------------------                  |   
      ,--+---.                           ,----+-----.          ,-+--.
      |Client|                           |TEAPServer|          |MASA|
      `------'                           `----------'          `----'
]]></artwork></figure>

<t>The second part of the flow depicts the CA on the right.</t>

<figure title="Enrollment after BRSKI Flow" anchor="flow-2b"><artwork><![CDATA[
     ,------.            ,----------.          ,--.
     |Client|            |TEAPServer|          |CA|
     `--+---'            `----+-----'          `+-'
        |    EAP-Response/    |                 |  
        |    Type=TEAP        |                 |  
        |    {PKCS#10 TLV}    |                 |  
        | -------------------->                 |  
        |                     |                 |  
        |                     |     PKCS#10     |  
        |                     | ---------------->  
        |                     |                 |  
        |                     |      PKCS#7     |  
        |                     | <----------------  
        |                     |                 |  
        | EAP-Request/        |                 |  
        | Type=TEAP,          |                 |  
        | {PKCS#7 TLV,        |                 |  
        | Result TLV=Success} |                 |  
        | <--------------------                 |  
        |                     |                 |  
        | Eap-Response/       |                 |  
        | Type=TEAP           |                 |  
        | {Result TLV=Success}|                 |  
        | -------------------->                 |  
        |                     |                 |  
        |     EAP-Success     |                 |  
        | <--------------------                 |  
     ,--+---.            ,----+-----.          ,+-.
     |Client|            |TEAPServer|          |CA|
     `------'            `----------'          `--'
]]></artwork></figure>

<t>Notes:</t>

<t>(1) If the client has not yet completed the BRSKI flow, then it provisionally accepts the server certificate and must validate it later once BRSKI is complete. The server validates the client certificate using its trust anchor database.</t>

<t>(2) The server instructs the client to start the BRSKI flow by sending a Request-Action TLV that includes a BRSKI-RequestVoucher TLV. The server also instructs the client to request trust anchors, to request CSR Attrites, and to initiate a PKCS certificate enrolment. As outlined in <xref target="RFC7170"/>, the Request-Action TLV is sent after the Crypto-Binding TLV and Result TLV exchange.</t>

<t>(3) The client includes the certificate it received from the server in the RequestVoucher message.</t>

<t>(4) Once the client receives and validates the voucher signed by the MASA, it must verify the certificate it previously received from the server.</t>

<t>(5) As outlined in <xref target="RFC7170"/>, the Trusted-Server-Root TLV is exchanged after the Crypto-Binding TLV exchange, and after the client has used the Voucher to authenticate the TEAP server identity. This is equivalent to section [todo] from <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>.</t>

<t>(6) There is no need for an additional Crypto-Binding TLV exchange as there is no inner EAP method. All BRSKI exchanges are simply TLVs exchanged inside the outer TLS tunnel.</t>

</section>
<section anchor="teap-server-instructs-client-to-reenroll" title="TEAP Server Instructs Client to Reenroll">

<t>In this flow, the server instructs the client to reenroll and get a new LDevID by exchanging TLVs once the outer TLS tunnel is established.</t>

<figure title="TEAP Server Instructs Client to Reenroll" anchor="flow-3"><artwork><![CDATA[
      ,------.                      ,----------.          ,--.
      |Client|                      |TEAPServer|          |CA|
      `--+---'                      `----+-----'          `+-'
         |          EAP-Request/         |                 |  
         |          Identity             |                 |  
         | <------------------------------                 |  
         |                               |                 |  
         |         EAP-Response/         |                 |  
         |         Type=Identity         |                 |  
         | ------------------------------>                 |  
         |                               |                 |  
         |        EAP-Request/           |                 |  
         |        Type=TEAP,             |                 |  
         |        TEAP Start,            |                 |  
         |        Authority-ID TLV       |                 |  
         | <------------------------------                 |  
         |                               |                 |  
         |        EAP-Response/          |                 |  
         |        Type=TEAP,             |                 |  
         |        TLS(ClientHello)       |                 |  
         | ------------------------------>                 |  
         |                               |                 |  
         |       EAP-Request/            |                 |  
         |       Type=TEAP,              |                 |  
         |       TLS(ServerHello,        |                 |  
         |       ServerKeyExchange,      |                 |  
         |       ServerHelloDone)        |                 |  
         | <------------------------------                 |  
         |                               |                 |  
         |       EAP-Response/           |                 |  
         |       Type=TEAP,              |                 |  
         |       ClientKeyExchange,      |                 |  
         |       CertificateVerify,      |                 |  
         |       ChangeCipherSpec,       |                 |  
         |       Finished)               |                 |  
         | ------------------------------>                 |  
         |                               |                 |  
         |     EAP-Request/              |                 |  
         |     Type=TEAP,                |                 |  
         |     TLS(ChangeCipherSpec,     |                 |  
         |     Finished),                |                 |  
         |     {Crypto-Binding TLV,      |                 |  
         |     Result TLV=Success}       |                 |  
         | <------------------------------                 |  
         |                               |                 |  
         |      EAP-Response/            |                 |  
         |      Type=TEAP,               |                 |  
         |      {Crypto-Binding TLV,     |                 |  
         |      Result TLV=Success}      |                 |  
         | ------------------------------>                 |  
         |                               |                 |  
         | EAP-Request/                  |                 |  
         | Type=TEAP,{Request-Action TLV:|                 |  
  ,---!. | Status=Failure,               |                 |  
  |(1)|_\| Action=Process-TLV,           |                 |  
  `-----'| TLV=PKCS#10}                  |                 |  
         | <------------------------------                 |  
         |                               |                 |  
         |         EAP-Response/         |                 |  
         |         Type=TEAP             |                 |  
         |         {PKCS#10 TLV}         |                 |  
         | ------------------------------>                 |  
         |                               |                 |  
         |                               |     PKCS#10     |  
         |                               | ---------------->  
         |                               |                 |  
         |                               |      PKCS#7     |  
         |                               | <----------------  
         |                               |                 |  
         |      EAP-Request/             |                 |  
         |      Type=TEAP,               |                 |  
         |      {PKCS#7 TLV,             |                 |  
         |      Result TLV=Success}      |                 |  
         | <------------------------------                 |  
         |                               |                 |  
         |      Eap-Response/            |                 |  
         |      Type=TEAP                |                 |  
         |      {Result TLV=Success}     |                 |  
         | ------------------------------>                 |  
         |                               |                 |  
         |          EAP-Success          |                 |  
         | <------------------------------                 |  
         |                               |                 |  
         |          EAP-Success          |                 |  
         | <------------------------------                 |  
      ,--+---.                      ,----+-----.          ,+-.
      |Client|                      |TEAPServer|          |CA|
      `------'                      `----------'          `--'
]]></artwork></figure>

<t>(1) The server instructs the client to reenroll by sending a Request-Action TLV that includes a PKCS#10 TLV.</t>

</section>
<section anchor="out-of-band-reenroll" title="Out of Band Reenroll">

<t>This section shows how the device does a reenroll to refresh its LDEvID directly against the registrar outside the context of the TEAP tunnel.</t>

</section>
</section>
<section anchor="teap-tlv-formats" title="TEAP TLV Formats">

<section anchor="new-tlvs" title="New TLVs">

<t>This document defines 5 new TEAP TLVs. The following table indicates whether
the TLVs can be included in Request messages from TEAP server to
device, or Response messages from device to TEAP server.</t>

<figure><artwork><![CDATA[
+------------------------+----------+
| TLV                    | Message  |
+------------------------+----------+
| BRSKI-VoucherRequest   | Response |
| BRSKI-Voucher          | Request  |
| CSR-Attributes         | Response |
| Retry-After            | Response |
| NAI-Identity           | Request  |
+------------------------+----------+

]]></artwork></figure>

<t>These new TLVs are detailed in this section.</t>

<section anchor="brski-requestvoucher-tlv" title="BRSKI-RequestVoucher TLV">

<t>This TLV is used by the server as part of a Request-Action TLV to
request from the peer that it initiate a voucher request.  When used
in this fashion, the length of this TLV will be set to zero. The Status field of the Request-Action TLV MUST be set to Failure.</t>

<t>It is also used by the peer to initiate the voucher request.  When
used in this fashion, the length of the TLV will be set to that of the
voucher request, as encoded and described in Section 3.3 in
<xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>.</t>

<figure><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=TBD1-VoucherRequest   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Value...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork></figure>

<t>The M and R bits are always expected to be set to 0.</t>

<t>The server is expected to forward the voucher request to the MASA, and
then return a voucher in a BRSKI-Voucher TLV as described below.  If
it is unable to do so, it returns an TEAP Error TLV with one of
the defined errors or the following:</t>

<figure><artwork><![CDATA[
TBD2-MASA-Notavailable  MASA unavailable
TBD3-MASA-Refused       MASA refuses to sign the voucher

]]></artwork></figure>

<t>The peer terminates the TEAP connection, but may retry at some later
point.  The backoff mechanism for such retries should be appropriate
for the device.  Retries MUST occur no more frequently than once
every two (TBD) minutes.</t>

</section>
<section anchor="brski-voucher-tlv" title="BRSKI-Voucher TLV">

<t>This TLV is transmitted from the server to the peer.  It contains a
signed voucher, as describe in <xref target="RFC8366"/>.</t>

<figure><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=TBD4-Voucher          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Value...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork></figure>

<t>Upon receiving this TLV the peer will validate the signature of the
voucher, using its pre-installed manufacturer trust anchor (LDevID).
It MUST also validate the certificate used by the server to establish
the TLS connection.</t>

<t>If successful, it installs the new trust anchor contained in the
voucher.</t>

<t>Otherwise, the peer transmits an TEAP error TLV with one of the
following error messages:</t>

<figure><artwork><![CDATA[
TBD5-Invalid-Signature  The signature on the voucher is invalid
TBD6-Invalid-Voucher    The form or content of the voucher is invalid
TBD7-Invalid-TLS-Signer The certificate used for the TLS connection
                        could not be validated.

]]></artwork></figure>

</section>
<section anchor="csr-attributes-tlv" title="CSR-Attributes TLV">

<t>The server SHALL transmit this TLV to the peer, either along with the
BRSKI-Voucher TLV or at any time earlier in a communication.  The peer
shall include attributes required by the server in any following CSR.
The value of this TLV is the base64 encoding described in Section
4.5.2 of <xref target="RFC7030"/>.</t>

<t>The TEAP server MAY use this TLV to specify the subject identity information to include in Subject or Subjecet Alternate Name fields in any following CSR.</t>

<figure><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=TBD8-CSR-Attributes |         length                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Value...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork></figure>

<t>Again, the M and R values are set to 0.  In the case where the client
is unable to provide the requested attributes, an TEAP-Error is
returned as follows:</t>

<t>TBD9-CSR-Attribute-Fail Unable to supply the requested attributes.</t>

</section>
<section anchor="retry-after-tlv" title="Retry-After TLV">

<t>The server MUST transmit this TLV to the peer when repling to a PKCS#10 TLV request from the peer where the server is willing to fulfill the request and issue a certificate via a PKCS#7 response, but is unable to fulfill the request immediately. This TLV is used to tell the peer the mimimum lenght of time it MUST wait before resending the PKCS#10 request. The value of this TLV is the time in seconds that the peer MUST wait before resending the PKCS#10 request. The peer MUST resend the exact same PKCS#10 request.</t>

<figure><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=TBD10-Retry-After   |         length                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Value...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork></figure>

<t>Again, the M and R values are set to 0.</t>

</section>
<section anchor="nai-tlv" title="NAI TLV">

<t>The server may use this TLV to provision a realm-specific NAI on the device.</t>

<figure><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=TBD10-NAI           |         length                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Value...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork></figure>

<t>Again, the M and R values are set to 0.</t>

</section>
</section>
<section anchor="existing-teap-tlv-specifications" title="Existing TEAP TLV Specifications">

<t>This section documents allowed usage of existing TEAP TLVs. The definition of the TLV is not changed, however clarifications on allowed values for the TLV fields is documented.</t>

<section anchor="pkcs10-tlv" title="PKCS#10 TLV">

<t><xref target="RFC7170"/> defines the PKCS#10 TLV as follows:</t>

<figure><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></figure>

<t><xref target="RFC7170"/> does not explicitly allow a Length value of zero.</t>

<t>A Length value of zero is allowed for this TLV when the TEAP server sends a Request-Action TLV with a child PKCS#10 TLV to the client. In this scenario, there is no PKCS#10 Data included in the TLV. Clients MUST NOT send a zero length PKCS#10 TLV to the server.</t>

</section>
</section>
<section anchor="tlv-rules" title="TLV Rules">

<t>BRSKI TLVs can only be transported inside the TLS tunnel. The following table provides a guide to which TLVs may be encapsulated 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>

<t>The following define the meaning of the table entries in the sections below:</t>

<t>0   This TLV MUST NOT be present in the message.</t>

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

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

<t>1   Exactly one instance of this TLV MUST be present in the
    message.</t>

<t>Request Response Success Failure TLVs
0       0-1      0       0       BRSKI-VoucherRequest
0-1     0        0       0       BRSKI-Voucher
0       0-1      0       0       CSR-Attributes</t>

</section>
</section>
<section anchor="fragmentation" title="Fragmentation">

<t>TEAP is expected to provide fragmentation support. Thus EAP-TEAP-BRSKI
does not specifically provide any, as it is only expected to be used
as an inner method to TEAP.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>The IANA is requested to add entries into the following tables:</t>

<t>The following new TEAP TLVs are defined:</t>

<figure><artwork><![CDATA[
TBD1-VoucherRequest   Described in this document.
TBD4-Voucher          Described in this document.
TBD8-CSR-Attributes   Described in this document.
TBD10-Retry-After Described in this document.

]]></artwork></figure>

<t>The following TEAP Error Codes are defined, with their meanings
listed here and in previous sections:</t>

<figure><artwork><![CDATA[
TBD2-MASA-Notavailable  MASA unavailable
TBD3-MASA-Refused       MASA refuses to sign the voucher
TBD5-Invalid-Signature  The signature on the voucher is invalid
TBD6-Invalid-Voucher    The form or content of the voucher is invalid
TBD7-Invalid-TLS-Signer The certificate used for the TLS connection
                        could not be validated.
TBD9-CSR-Attribute-Fail Unable to supply the requested attributes.
TBD11-Retry-PKCS#10     Retry PKCS#10 Request (1000 range code)
TBD12-Retry-PKCS#10     Retry PKCS#10 Request (2000 range code)
TBD13-NAI-Rejected      The device will not use the indicated
                        NAI (1000 range code)

]]></artwork></figure>

<t>[[ TODO: is there a registry of NAIs that map to TEAP methods? e.g. @eap-teap.net is reserved to indicate the peer wants to use TEAP method ]]</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>BRSKI <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> provides a zero touch
  way for devices to enroll in a certification authority (CA). It assumes
  the device has IP connectivity. For networks that will not grant
  IP connectivitiy before authenticating (with a local credential)
  this poses a Catch-22– can’t get on the network without a credential
  and can’t get a credential without getting on the network.</t>

<t>This protocol provides a way for BRSKI to be in an EAP method
  which allows the BRSKI conversation to happen as part of EAP
  authentication and prior to obtaining IP connectivity.</t>

<t>The  security considerations of <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>
  apply to this protocol. Running BRSKI through EAP introduces some
  additional areas of concern though.</t>

<section anchor="issues-with-provisionally-authenticated-teap" title="Issues with Provisionally Authenticated TEAP">

<t>This protocol establishes an unauthenticated TLS connection and passes
  data through it. Provided that the only messages passed in this state
  are self-protected BRSKI messages this does not present a problem.
  Passing any other messages or TLVs prior to authentication of the
  provisional TLS connection could potentially introduce security issues.</t>

<t>While the TLS connection is unauthenticated, it must still be validated
  to the fullest extent possible. It is critical that the device and the
  TEAP server perform all steps in TLS– checking the validity of the
  presented certificate, validating the signature using the public key
  of the certificate, etc– except ensuring the trust of the presented
  certificate.</t>

</section>
<section anchor="attack-against-discovery" title="Attack Against Discovery">

<t>The device discovery technique specified in this protocol is the standard
  EAP server discovery process. Since it is trivial to set up an 802.11
  wireless access point and advertise any network, an attacker can impersonate
  a legitimate wireless network and attract unprovisioned pledges. Given that
  an unprovisioned device will not know the legitimate network to connect
  to, it will probably attempt the first network it finds, making the attack
  that much easier. This allows for a “rogue registrar” to provision and
  take control of the device.</t>

<t>If the MASA verifies ownership prior to issuance of a voucher, this attack
  can be thwarted. But if the MASA is in reduced security mode and does not
  verify ownership this attack cannot be prevented. Registrars SHOULD use the
  audit log of a MASA when deploying newly purchased equipment in order to
  mitigate this attack.</t>

<t>Another way to mitigate this attack is through normal “rogue AP” detection
  and prevention.</t>

</section>
<section anchor="teap-server-as-registration-authority" title="TEAP Server as Registration Authority">

<t>If the TEAP server is logically separate from the Certification Authority (CA)
  (see <xref target="arch"/>) it will be acting as a Registration Authority (RA) when it
  obtains the PKCS#10 TLV and replies with a PKCS#7 TLV (see <xref target="RFC7170"/>, Sections
  4.2.16 and 4.2.17, respectively). The assurance a RA makes to a CA is that the
  public key in the presented CSR is bound to an authenticated identity in way
  that will assure non-repudiation.</t>

<t>To make such an assurance, the TEAP server MUST authenticate the provisional
  TLS connection with the device by validating the voucher response received
  from the MASA. In addition, it is RECOMMENDED that the TEAP server indicate
  that proof-of-possession (see <xref target="RFC7170"/>, Section 3.8.2) is required by
  including the challengePassword OID in the CSR Attributes TLV.</t>

</section>
<section anchor="trust-of-registrar" title="Trust of Registrar">

<t>The device accepts a trusted server (CA) certificate and installs it
  in its trust anchor database during step 5 (see <xref target="bint"/>). This can
  happen only after the provisional TLS connection has been authenticated
  using the voucher and the Crypto-Binding TLV has been validated.</t>

</section>
</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>The authors would like to thank Brian Weis for his assistance, and
Alan Dakok for improving language consistency.  In addition, with
ruthlessly “borrowed” the concept around NAI handling from Tuomas Aura
and Mohit Sethi.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>

<reference anchor="IEEE8021AR" >
  <front>
    <title>Secure Device Identity</title>
    <author >
      <organization>Institute for Electrical and Electronics Engineers</organization>
    </author>
    <date year="1998"/>
  </front>
</reference>
<reference anchor="IEEE8021X" >
  <front>
    <title>IEEE Standard for Local and metropolitan area networks--Port-Based Network Access Control</title>
    <author >
      <organization>Institute for Electrical and Electronics Engineers</organization>
    </author>
    <date year="2010"/>
  </front>
</reference>



<reference anchor='I-D.ietf-anima-bootstrapping-keyinfra'>
   <front>
      <title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title>
      <author fullname='Max Pritikin'>
	 <organization>Cisco</organization>
      </author>
      <author fullname='Michael C. Richardson'>
	 <organization>Sandelman Software Works</organization>
      </author>
      <author fullname='Toerless Eckert'>
	 <organization>Futurewei Technologies Inc.  USA</organization>
      </author>
      <author fullname='Michael H. Behringer'>
	 </author>
      <author fullname='Kent Watsen'>
	 <organization>Watsen Networks</organization>
      </author>
      <date day='11' month='November' year='2020'/>
      <abstract>
	 <t>This document specifies automated bootstrapping of an Autonomic Control Plane.  To do this, a Secure Key Infrastructure is bootstrapped.  This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer&#39;s authorizing service, both online and offline.  We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.  Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks.  Support for deployment models with less stringent security requirements is included.  Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device.  The established secure connection can be used to deploy a locally issued certificate to the device as well.
	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-anima-bootstrapping-keyinfra-45'/>
   <format target='https://www.ietf.org/archive/id/draft-ietf-anima-bootstrapping-keyinfra-45.txt' type='TXT'/>
</reference>



<reference anchor='RFC3748' target='https://www.rfc-editor.org/info/rfc3748'>
<front>
<title>Extensible Authentication Protocol (EAP)</title>
<author fullname='B. Aboba' initials='B.' surname='Aboba'><organization/></author>
<author fullname='L. Blunk' initials='L.' surname='Blunk'><organization/></author>
<author fullname='J. Vollbrecht' initials='J.' surname='Vollbrecht'><organization/></author>
<author fullname='J. Carlson' initials='J.' surname='Carlson'><organization/></author>
<author fullname='H. Levkowetz' initials='H.' role='editor' surname='Levkowetz'><organization/></author>
<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 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='RFC7170' target='https://www.rfc-editor.org/info/rfc7170'>
<front>
<title>Tunnel Extensible Authentication Protocol (TEAP) Version 1</title>
<author fullname='H. Zhou' initials='H.' surname='Zhou'><organization/></author>
<author fullname='N. Cam-Winget' initials='N.' surname='Cam-Winget'><organization/></author>
<author fullname='J. Salowey' initials='J.' surname='Salowey'><organization/></author>
<author fullname='S. Hanna' initials='S.' surname='Hanna'><organization/></author>
<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='RFC7030' target='https://www.rfc-editor.org/info/rfc7030'>
<front>
<title>Enrollment over Secure Transport</title>
<author fullname='M. Pritikin' initials='M.' role='editor' surname='Pritikin'><organization/></author>
<author fullname='P. Yee' initials='P.' role='editor' surname='Yee'><organization/></author>
<author fullname='D. Harkins' initials='D.' role='editor' surname='Harkins'><organization/></author>
<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='RFC8366' target='https://www.rfc-editor.org/info/rfc8366'>
<front>
<title>A Voucher Artifact for Bootstrapping Protocols</title>
<author fullname='K. Watsen' initials='K.' surname='Watsen'><organization/></author>
<author fullname='M. Richardson' initials='M.' surname='Richardson'><organization/></author>
<author fullname='M. Pritikin' initials='M.' surname='Pritikin'><organization/></author>
<author fullname='T. Eckert' initials='T.' surname='Eckert'><organization/></author>
<date month='May' year='2018'/>
<abstract><t>This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer.  This artifact is known as a &quot;voucher&quot;.</t><t>This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure.  Other YANG-derived formats are possible.  The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)).</t><t>This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it.</t></abstract>
</front>
<seriesInfo name='RFC' value='8366'/>
<seriesInfo name='DOI' value='10.17487/RFC8366'/>
</reference>




    </references>

    <references title='Informative References'>





<reference anchor='RFC7542' target='https://www.rfc-editor.org/info/rfc7542'>
<front>
<title>The Network Access Identifier</title>
<author fullname='A. DeKok' initials='A.' surname='DeKok'><organization/></author>
<date month='May' year='2015'/>
<abstract><t>In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each 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 of RFC 4282.  It addresses issues with international character sets and makes a number of other corrections to RFC 4282.</t></abstract>
</front>
<seriesInfo name='RFC' value='7542'/>
<seriesInfo name='DOI' value='10.17487/RFC7542'/>
</reference>




    </references>


<section anchor="changes-from-earlier-versions" title="Changes from Earlier Versions">

<t>Draft -06:
  * nothing more than version bump</t>

<t>Draft -03:
  * Merge EAP server and Registrar
  * Security considerations
  * References improvements
  * Add Dan Harkins as co-author</t>

<t>Draft -02:
  * Flow corrections</t>

<t>Draft -01:
  * Add packet descriptions, IANA considerations, smooth out language.</t>

<t>Draft -00:</t>

<t><list style="symbols">
  <t>Initial revision</t>
</list></t>

</section>


  </back>

<!-- ##markdown-source:
H4sIAATbJWEAA+V9aXsbx5Hw9/kVHemDxRUAS6Qu61nHoUl6zVjXK9Jy3rX9
bAZAk5gVMIPMDEgjkvLbt67urp4DBCXZkRMkmxWB6Z7u6rqrumo4HCZ1Vs/t
Y3N6tP/CfL+cprU1aT41R7/UNq+yIq/MWVGar4uiruoyXS6z/DxJx+PSXmwa
lEyLSZ4uYOJpmZ7Vw7lNy6FNl8Ma/2dcVq+z4Z0HyQRGnhfl+rGp6mmyopmq
x+blNwcP7z68kyTZsnxs6nJV1bt37nxxZzd5bdeXRTl9bI7z2pa5rYeHOH+S
VDUs4H/SeZHDO9e2SpbZY/NjXUwGpirKurRnFfxrvcB//Jwk6aqeFeXjxAwT
A58sh7cejcwTWCZ9wWs/mmdFHb4syvPH5iCrJoU5WVe1XVT0NcDF2hpWnU1m
dYZQqiprHtJvk2IK8xx8O3y0d+cef5PVsN0f0vk8q+x8bnN5bpXXCIeTy6z+
uy3nsBv6YTmjHd2+d9fcu2cePXxkvgBQ0E92kWbzxwZB+6cJrmo0KRbRjp6P
zDdlZudqS88vba6+vGJLcAjmh5E5TatFmpvDcqQ29cX9u3t6SyfwxJ+Lyg7M
wX68p+/zrLZTc1Lj6eqlF2e4kJ7FPxuZg3Qx/AEQztZqB8/SfLJu/vTP3Uc+
SReXsJienRyOzLdp+Rr+rbZxCK/R39IOzLcvzBFi9rIE7Ii2sAcfczIp6hqI
cTW3F2k5jXZx535jF3VqDuZpmV5jI9MZr+hPabkap0BeQGyvK9pQkhflIq2z
C/sYRxwfHR09urN7d/8l/QkfYSQndrIqrTm0F9nEmuOpzeGHtTzjyU4+sOk0
z/4O0xY50nQFz66AmSDLOZrbSV1mk3TOvIX+LPJsUgGIzrPc2rKSiSoLeFQd
52dFmJqhjMv0X12k8xV8B8sewbrla2Q5gCBffPFIb+svjV3h9wivfApgp+U9
KdzKFhbWtSzmGfxs0tKmxr+RVyJgHA5fACcafp1WAPtn/KXZn0xsVZmDAk6m
mH9yYPpLBKXdO3eBKQ+HQ5OOkc9NgPEe52ZiyzrNcmPziwxevYAjB2YLXwCn
tiWtMjVTRoi6MBZ49Ri43wwWvDbzdG3LpJ4BlgOCLhYrWDptFKeoTVYB/BBE
abmmmepZWqvJxtYsAfrAMdfJpLSEbuncTkfGnM5gMPw3NaWdE+bO18am1RpH
jOd2geOrYn5hzeUMuGKayLQ4pqqKSZYilQBDhpWa2QpZx9gCmROgZ2llxgX8
lOXLVU1fTbNqCdtJzlb5hHYAizimLczxjOnV9KZ6Znm+AY8edA9HZDI5SKBl
aSvYGO6pMOl0WuJ0NW5vkiKjon8u7AK2s7ST7AxOObFBgMM28Y2nqzy3cyek
AQBmH/AMAcYANy/KAgRmMTe3ULDvJIDYs2LKEAeGY8v03FaxKmBewlsBE4Xq
v7NrQM8zkIAgtCc1fFUlt75+efLd8U7AB1gOHMBFNgWlwYQzw+89muAbETEM
UMkoOYXVj9MKNlmc8WaJdrKK15YaAOXqLKUXlnBg8zm8DahgukIkmVl3sAhl
hMScaHdql/NijdgKX5bF6nwGq1kv6+IcNjfLJgDRlM8wp5cmcAYVzWcqoBrW
S8wC2C+QHsAFt4lrWgF9j5hMFtl0OrdJchP1FVoPAjpJ3rz5w/HwcJTZ+mwI
lL1Ih2MN1SGoORmC8d0748DnTxa3iwsDeCUERzxkBcdKyAKXgetq/IK0QscN
Gsg6SZn9eE5PCHsJo6a2ys5zniE1pF2RciXvBjSG466KhU3m2YKkiUyFp5ib
4xduTqKmOXDF6dqkFyBlgPatok7A7ySdX6briiCLCA2/fgOUbn9JF8s5oDcx
X2JHd/1KzbnNYSOwB6Duv62y0pJOp7AZRGhR8nKIcywQeRzxAH3D9hZMVD/M
MiAGYjbJsqiYNnAgPSTb8WSnsBTegiAIs+cI3jyRRQ6MLAAgs6z5UVRG8dGp
PUtX87qB/541JhmIaPwS3jwpgG4BcS5Ajg4Y/Wq7FNy/BF2AkDqHVcznxSXg
3PkMvgfdMhHI8JM4MDA44DQTODTYQQowvTR+yTwGSRuZTk3qPtCTUCOx6SUo
FcAbQLAAmu8DBcArQJAA9aEQWgJSppMZ6j6mWuE/8EzprGGH/HSNa4SjM+OM
STJgMr4ZAaTRllgwbaBxxoCNkxkQULWAY3ye24ReCMhk8F3TgpkF/Bf/XKSv
iSpwdpqslxMmgRMiIzQG6BVskr2H9x4BRTouciVDDdMIR8X1EkuVCdHIefdu
hAL2dLaCVV7CrIAZILUNnQpZWMnpemmHT2x+Xs+Gr1A443xPXu2YYvy/gBi4
OzzgCaCfJ3yCNfCTvFoixiGImUEt3ZoWKFSRoSN0MxZKgGo1CA7CZbbuTp+c
mJr2OSK25VeN4mqyqvBkcSSQMR4IDIxOconqB2zwhMTHPJlmZ2fAOYDl+pNj
MadZw4klNmn2Ro+Y4aPELyYrJFfgWK/z4hIk/Lm8GdZM5AVPoqwUwgHk0rgC
S8FnC9CaStwT8PKK+GZV8PzRqheAQMUEJBozfyD9DBc0AJaEiz5HFEoWQL4Z
8CeY7lUA5hjoyAIxTuYZ7pJUMgAjqF4AAABHCcwSZLWMjdGeyBrAfPOmOcUH
82JenK8TEn/IQGECpFygSwDFVNj8WbrI5llaMpHgu+owFrl3hVr+FBhKhMXN
nSF0mIEQrGAKPhdUyYocoElYleUJUZQ7DVis+Q+WfI+vqxgMDIkZRHaa2BBV
bCkWSYBYWicLGDhHXCHOAnABK58VDdoWckWQZ5MyG9OrYowa4RaOTk7B3M9B
BZ+TQlDgacnaTx0VNVbsiPjOHhIxzvKqAPZjy8coMVl6/vnk+TMh087Bj/Ye
PMDBoCEQuTGN7peTGchUgpN5czOFP98xGqiHUv0Qcrn5fIWgqhmcb96wl0U/
hnA7DWKgTuevg3ao0PQiS4ljKHYGkmxVse67RqRYAs6h4uQ5DHFe2OKP3oT6
mRW3eJ1qkdWsuKxQZsavAb4C9ArwOivB7GwsbaS0eqW/FcsatBA2kIjmSM2u
ioSfsVPhFMq88JQavx0Hq/cl9Kb9/f3AN91GX+4fHn9/giL+8Hj/6dHp0cuR
SbbaMSxkiCoofqXBjj4fPtvSnpMjCfb7DHgaEWBKgtyiBnpZmGAkhMmIitfJ
0+9PTpEzeEWVTXABHYgqpL6gE/CvJiNpCwqmULnDks8qc8FoTaoBaCjmVuNQ
dlgTj96W0PxIBfxT5xx+mzsjx+XkC3VWIqFoFobO0/2TfXo1IjHbhMBJVyXo
bpZMhHNbE8sXIpR3V62XENtovyk1B2DRAizwO8KPoiQQiQWTAMlkVQVy+Mmh
vTg+rJiqomPno67j1wFuHewj7pAZmeA5ApdG2x3Ot7KoV9UCwAwZJMyBcpOm
gYEoluBcwbSx547OwQiIXhIROKvXILWAWicZKlzpJaIRgAgIpJ75qRNcWlho
bIGG9wEA//GPfyTJ7aF8bpNzwP+5+e/byVvnYnir/jf6m7AK/vWf8Pwf3/JJ
v22PY5od+r+FgORv9T5xQ7n5HJW7v/28WyyNca/9is3jXjqg+lfCQcL73heE
fADmzWNzs83f2Vv15Y0eUXLjHcoZ/t4La1ZRSPKZ5842REIB5KlEEQN9Y5Gi
R1I0rlVJKhzP5A1KRj3+EmVuAvYTSNhKWx7oNUF7iujG+1EaBnyWg84yBxUv
YRM7zScz5/mZkBOGtREgw4t0nlH4IXAHoXa1moQ0ABRaIFFoF4wvYK0s0G/F
5hSKG5oG9oPGNjqMWP10/oPHYNSbE3jY3H3sMAu1YFQWGrTun9z1T3rbzlZB
24QloIbtTDyANWkvzVn2/CyVzadtjizqp2EynlhYetXgfmjOLYGkrZ/0np/U
QTFMjBOFb6+73PsBPMVlPi9SWLJTNWEKcb8UBHwgB9Dp2LeMiCdTPOiYQnPl
E9gcq5kiTw5OXu6YtK5ByVuhV9tN9FBNRM6TiZrFMt6jW2RMLkzALubpfvwj
Px7wIiumwq3BDqaxFSlLoD6K2glQnhlU8d00T4uqFjTSvhdBumChOxIZiH0J
5iBOk1Gci57HBS/AsgYNckBuhVVdINR4QaSTWaGEHI04fAMJNLB6xHGpJAES
GariTEdT9ISa8do0hEnkh4mlGYGzIV5qi9BUGmbhj29LBHA+kym5kRCu/WfE
ptKhUOAaoXyKDAO2hIIjEWXKcbFdNCdX9RzgV6FopYW+DPuJKHlSAI8DJZQk
UF04lCd4jkw88f3R3qaJkWWR7wFjBJM1wGaSsWM2HePRXM4y0CgZYqyO4yZg
cyeg085RbxCXihVTeYnwRluZlB+liIF29wvYLKT70BI7DlArnKJQwN7OsnNg
vd7ZDWyKkVbAGdgzTn2wDxrPIf9bDtrbaQNWVt1ueD7P8IUlAZ6lvXO7VaVo
jDJ22sA50yYD8rqh2tjA+2j0bifBVQbkgdELeoRO+PuXx0EAeMX3WKHZUQxZ
VAadi4TdQG9ujoFY3zVEZwsvCOcFf4gFyBNTxIYL/H2JW8aZeRs4UCw++MsG
G1VEYTphcwzAgwphxX71pvOGpGEw8NG5JI+88loeO8ynJObojUMxaIXJtr7H
L4DvDvcV243fE23Rw4B3GjQF3HTldj26jpT9AU/Te94Z+9m+FhDw9geaKTkn
jnPZEwi60Eh0ac9fgArJxY1U5xCcLR9g/IVw8coFCS8zJKiipH9QAOjJ/jPt
DGpN3PM+q3AEtRXBrHtIoG/ebBtHcLEkkTgcxHRe5qnmobEI+FiajDJL9Pg0
d065cFqdh0HWsZc5kd7n6DsIdrDE1fskfFYpuYxGGIlXF5/WWkF2hsEAVkzp
RTIIeBue9SWokPiAnjYRVmFOG6sOSlTEWfTryK+S0GoWLEkNMW35d6QDw1Tp
mEIkx2dqxsSvJfBaDp7CGtioT89TFPnoN5E5FINPIv1bLQ5w8kRclyy8kDmT
2ayU8IkEr1mQ6a3FMQfH0WWx4k4LfrnEofabJRg2ap5h6mzwIbwLORyrURV6
zgQQMilMpEIqyIhXZzAJOWNhqWDHoleWQlVteYgctbQABM8+XtoKozTo4s3y
qXMlVyuOdWWLhZ1ilHi+juxuBFJVYxgS1XWYSxjocJ/3x9NN5qspedQ6ma08
5NX2yE+nl0XI6gljll6AoAde7Agdthk5md2hC0YxNxMsdW7yCCaaqp4VtUST
8gIWl8Pv+KhENbIq5i7oKhZ9IM217zyIHji/n36si2nx08/m/+G2KcMhjWzG
yxQRWxE6MZYlzCraSgQ+nHbA8MgQCOJb6TsGxF0gjM3nQEqpm/J95sKfv/oq
MAdKimMv5himTBdj0L8KUPlRlCCYQRuGdQ/wdDHoiq9ky6/14oBHf/nLX4a0
2KyWKG1WK+CdgSaJ8xRuC7kbMRp1H4OEWHnJ3v/5N/87QSQy7i8ITbshdPl5
J3gLJrsA2O6ncmLXYEt8ZY4/WxCqTzDzDX9BPIMdOE6gsdcRQSsEKqqCex+p
IQONZD3gxnOmuRjupJH2oU1D+840x1b8CjcmPBvptncL2u7pOC0AfI5SKZu8
jjcyI713O0704ruDk5t37/A2i2DPSTgLdXFSQEfmWwyqOATwSyVqwwBdALgM
naWxYcVMKKgCU3MrpeDWRQaEQBY2+THEWohgvPOVE38yuRyWk31C/05x4OyC
bgCEzVMyT+dRot6tAFN9ZX6AzVV6AWMLyA8LL2Flhv1e7ifEbmThoBda3hmt
pO9NnwPKvDg4+Q5ftp3xPjJ/RlDmlqXxuWW4z4HZrtAp5CBOvEWFkZQRSBK9
7YtgTssnPiCWfiUyxxqTkAqpIWsASCEaA2wl005DtRS3tShlzC0CcQGhx8i6
BWn+3Zbo1gBCn1P8XJ/j6FdyrylFwDERPmxZr5IJHcE3AkiiDwjgfgkGRSVu
hWgOtzKZx0dGwAZOnA2sviS5mYU4R7yHlvaaxOvvWDjvM2hh+l1eJ+FYSfNt
LfUr8VQM3w2PyrLgV7m1rrKanB6WfsG019YqvtHmljfRcsxYqbPJap6WLqkQ
VO2irCmE6RgV+Yxk7aS0eFXQnbE2/JDJ5RKDb2ULJuGF2pvmMskMZZINgh7J
qqUSUyoVscgjvukTdS4pa+kszeYUZlRTeKtAWH8NtOeS7ijpASSOnZ+5xA8P
MJ9bdcuOzgfmvDASXSJ34snJ8eHO6Nf0HivCic2mBqlxIJryKJTZkviwQaTg
shNl5WIXsbfRSN6Lmxn2G1mW7eU2qdVjviwcz6NqRSY0yntdpxIjQ6G6sjFw
ooxiOl0vFdegqIh1H+D8e1Gx6F5a/+lcd7U9i1VGQ61TcJyxT3a2JAiOMSCv
dIIBO8JTn5cSqSIi0RurkiUIIYtDjF/PL8TorVCLyAuGjUSU0GBeN0GDJgxl
8aFLp7kD9yrxJYw+Shzkee5c+pJXFSJcQVeVQz/59vn3Tw4FHon4wIdsuA9f
FkXdI2uinFznA0r6V1iF9AvUFQCP/EkwgXi1lHypWzunRpvDPicvo8DOswJ0
m5pi16njjRpQFPe4P3B7pHQIAU3srHRQwSS1TRDR/Dc5y+x8WjESkZrBuSaA
Qy4gJDqYVtc/NBb1AzutnQc6RoWG07fD44lvS1ASTzPcAyCzS+emCAttYFo4
puqcgk7Tx/sGQJ0DLZc8P7W/ULrOOb/baVekMR98d3LzIX8fkv1GiNkT29pC
5QNY0cpReUZrQkhdaW+Jt0VELXMatIO66TAHtd4cNoMIXKecJakXhZG9q7XM
pF+9Ew6q9qOQ0W8myxOPcmEdsrfINay3QlnuANTpnFPcNegxu3BBbqmgw9Dv
D7Wxl3slvVDQGHXa0eQ3kzQql0zPukvRwacS5dJVfFJC7WbXGzabdPlB0sBg
799SvN/tOhimSbJfs5K1BIyuI2xCzSvNXOakZ+/irmJmJ0pQ4nyEdMMnjbJJ
rVMbzlaUdYF4wrdlWP1DIsrtJaXXiztMZTOPtg8t94SUiRukwZksx4g0hBZW
bGANOD7B6WOXBaXK4QVN3HFphyqepFmfY0GG3+5Iaj8KRSQcF+BwTnd00Vtz
3UYlmGbJRnuuxzcREbfT2cU+ntfhtVXfeyXDsaLs3cS5JrejVz2PYj1JA1hJ
8i2nb3WJaj+BuG8tJ+06C0Cddvepegq6TDNWwHTIwG0fH+zLouzACZUzj2ya
vsQgnNLLA27yrS6MIwr6edniozcgWxJQa2CZooNFCeb4p1ANLQ1ZbuRFdzIm
KVsx+rVOHwcbxyHk9uGwpngPZogzmyMTXrYTzs0nfDsTVCazU7VcGEpMCHXg
jpCrywaGKcCIyfACYQ1s2C2rGYpDVyknRPCsVVBum4BNlCYQjnL3sfmhgd/I
Jm2JaifTmGNE7vZf475FsLxcDpiLjJGvvQ83kshto32Magft6wY34dHjKOvn
IIr+kMUoaOyz8UFIWGDg9WxNo7WGRdIS1xAHkQjpMKTHAp3C3/Ti/TCCVCRv
mERxEl5ux5j4cTJJGX6clDbUWXBCQ4rAQYKDbgGSgu59rXGcPHSyknxyGOf+
vT+nNCHKWXuW8kgHZ1ABgGDcsgholRUEVEnxdDEHGBFYQs5VePNmlOFw5DZE
FzGSr+0kXdGFOLp9SCGgKLTrTDVnGHlblRRutPvw8hfZfMrvG0gW7T/ApBB0
BW0QdQBxm5yt6AabksuEhqQY4bpSDmAAMrsF4GVqFwOjOgTuVX86/frwbiIx
YXdxTRQcnxhdmlvP9o/RBbIh/Ye218rzUdlAKBUpG4i1bnhmKghWswfCXRcL
hrjkJjI0MSIbjP+mzOUMs4Jf4/N60Htmo4QesOWagT9A/4K4QOwFaL4cGXT0
lsuUbcDPyEqn+wHOF4IDU3dzcQKmdT4tys/oUN1vvCz+pRq47VdyqYhPYuRv
S7sXV/Rmd79rjDoTHu2k5tyW6PwwQM2LZ9lKGmRseoW0JAy20eWnCgNwTahp
d9Pn1QrzsADmaBeLUtYKSSA+HdAX31oAD5uNaF7VVmvGVlOWc1H6q4iS4h4d
NCkhvGd+q4rZt2IvaEUhRdBEHW/EnWtNy6V/ATfj2xjnKw7R4G3xymm/6pX/
4wL06FsmC9k9pLj3y9ibzqjkoMWeSnK7oijL8pUNigTyrmqGRKNTMzaeIA5z
Xp6pHNEx8hk4PsqyzFsoRYxjnr1Gs8khdZGPC0zmcV5fQVugPrCd89VizHLa
x/0DfgAy0/ot3oWM0ivkHo0Jd+FKdNEAsNmTUFUrfODY3S0QVVe9LVyi0/PK
LOSeoQXKxXDOeys5ZQCOhfQn3gGiYACu02lEPcSUpm6tXhTi/rMl2USsmqUX
3xrqxpcNPj4JK/WeNc6a6usZRG7qUY9q3qhV0UgK+MXJ6N4mHkSkzMjpVoO/
OJOLJBcdBhsYIZZLws5lvJD+o9JotBdErYimxynwXL4BRkFEJ5voTlchUZI2
Rc4Ar8vz9V5xertcHbrRHF4bpyJhsoaWRKFSQ6fnFrgJnHFPSHFq5/Ycz6Al
DXWsqkD26e+bbJGuCtPMUXWhryV8gifHiT1N0X3WgU3NrK7OpFTv8qRAN1tx
fbNtmd1KkqJ7UzGcFYTRbU9+u+vsegXsM4raa33Ju9l8WM/dWgwJOire/bm4
jfxvbX86Mtaac3/wKhWwBjttSaAo5KCJ2UeOE0k+D37Y8NdnnVQ9kHSJjLUB
hNPYJpHUbAt+fGpt68j5Q/nVy5KEMp1bIrlRo0aaQeZlX3zJeYbZdJifKDot
vcEB2ue0iN/eqajBm6XTsVQUCyZRlwH8GIw3SoGCjizIz6okythSMnaBr3FX
yvJi02GgX0YdBoLyVrbDOkKl4ma9cW1cNoxKbmUwzCmZ6B/s4HrBdKZfophD
fBxNLu69gkFQ+ChxlIaoQ0JRcgz5d9j34rEzxPtoF6kQE9KeuHq6fctIeZ0n
08VqlSm9fdYn4g6tuHNRFDOK9Tp376TBudtciLCrW5agTPD3SYAkXjgCazF2
bUAH79GJ8iBX7uSQFzX5FvvS0F1dUQbACbMtiTnRCuv1UpykM7QP81BOZzOP
DxaESmNl5ikDG2vx4lNYu3O3heoYsWNx4yUVD41dD404L80tnj0x6HVF8Gim
IU6pXL0ojjF9EJCUBpTHcArJZzCx56YFM67o9uv7ps31J8WEQK/3Imd1X7BG
g3mvB8xqUu/H077u4LAScLLmfD1UM+2Up4brFj07fM1JC7gWwH14hssidkE5
NwzeoUo63JjOtwmqDiTs95GrEcSFGn4f4X2dGZZXY7JKJ3if/K3tkCa2LeV1
eLxXDXciQlLZOaGXsR+ZsK/C5Eo4bOtuDr6i3WhtfqsKotFVhDrkQW6hEpkp
36JqqeqxWAhKzC9YvGk99D5myrpnCz6Gob/I7wKtQX75W1IKQcMRYpAkJBTo
3JtUpYuD8vde0LxHTKu9Ol/8SZLniGMHu0MWSyYIJ+4hhpAv/P3WcZ+h5ZP1
OfYlSSYuOcZFFuLE3NLiTTS8xUXLnK85HkBDqjjh0U3UvBPAhzTw+krkn2bP
bCNFb2MeIJvCymwQ50GkOdVccsqnJpIB0LUsvozVyiDscJn51Ep6TSNZMKs7
ksJSir8GVByvMvZxROoTurMYOHLvT9y0eIFhOmRNsw/xF+y2t86OFsT21Ngx
SUv9iy7EpFxfTavaGqzdgYYmPYsCmsUqpdKzKdcrcmLQRrzeeKoUR++scXdc
5fic9xWzzU+/PhwGpcifF5931bwa7Dgu3lkG04UFWKLo76efSchoDnYUBOQp
hT6SH0ON0Z89qT0EBgr/x9ehK1A1/4hL3z+rsewOnhumBsGeUMjCCnxkHOSv
dZed5erSSKLv7GnFelCcFeG0odJGo9hRSF5FjNtllF6BBThoV5IKQNyI6doh
DZXTNF/A5+7uHvz3/hf3v/jvkTkp5iv2r3PG2eaXS0yAjpwn1MtAdqZvAUuQ
WQrC1S7Quv9S3U5EPFPef+dt7J6ptBRlEoVPHJt4YJjaoD3PFJPiMc+en7L/
S+uN+ho10XuOEWM31RPl8kw79KyeAcgb5KVjsvsnAjSdstGUV0Gl7tQFI+uB
kPVa0bdWiOgLxFlfwtGro0sqZBalGWC6m8pRc0QqeNYo9BJo7un+/zcqGifR
8UjPUy/km+fkJJ+6ejOkmjHuutQ258SHJbl1BP2torRqtDFDEklzVSgHu1fl
r5bIii4RJA6gwLT7YBuCeVqXUOl4zg0c1uy0eV86BEWaePPca9g5wqGhELAS
Sgt5Mb7Kgsqb8WGKg33GFKd1v6TA67c68LpmEw2WUQEqp6CluFqaHe4EfFQU
F0n0SlVQl49DAhKq3JzLto8kA2WyiS/PsW1fX6jtDoh8GeqWo9//3FWKUBLE
WpcXqfAtmBschubMzfSM/lep08SvqdgFAJ3KSqK6ThAcEndn2yaUUPMkpNfN
KSNFCDvIW93Ecn8a1T10CVyquwStlIyQWyclt1LBRCuT+hMk29P7wEXjLrGk
do7C73Gk8FeNyhvE3VgvbJ6tg1JjD+j1VHkTVHRL53u0UgWdUyVtwbNDf/QP
56Z1BQOPhO5dCF+4e+fOneFdkGymROcwhlnagKC6n2VOCb2bQaEKQ4dsmYY7
Ts/cDR+3jV6wguT0wMPXOLD9dnDbRbjtBrhRqgvmRPhy6Qku482br0LVUe9d
F+lxAydyz+OFYFa93bVsMICwZNOci2aXBScO+yJppKdYrBXOyQdo7aqbvDVV
U7wBNLJ/LMt4eP/ebrwM+P9Z7fOR4fkSw8NeKAAgcLTmnhgyx1qB4dkyu0gn
64HwQOWIJxbg/Gvsva/E/Q0iW+eIYK1otDKjJPg8iIniLOlI9sB6sbXklQzC
XTM9CaU5hdIosJmeUFcIctKO3Z2CS06DiR2FK7y734pyqcko8pzGO4yGu9cA
iG+k4wlolH+SubBO/w3yLFXoU17rJ6NnIvfWmPKAQPdGdq9PK+SkAf6klBoS
WJ72RqFgVbkYzl5VG5eFdGV8hSBS5FZS5a792FDWxV84RhZdSdTsVZRoGfQh
q8SMYCTldqzGFXIEADeuo5Hphs6qqlFlwdXTa8tlfMYv0jnp9R11xRQQs+N3
OWUbD82iSsHQw2xl0UT4OdxSmDSJOE3Nda5XORLoeZ79nTdL2IDj0rq2iyUJ
Yo9auOzEVZ0CnQ3sAroHJlEDRHhj9kPq5wT+wVYKv9cVzHEJuPo9zPRclV3n
PndwUmiW+OUQGzwAiBJvx1qJVI3dfJ0RPgHYqoA2Kk3fR4GkcnLhnZLEBxpV
Clw+NJ1liLfQ7VlOog1lCmQxQ1kBZ266uqERereqDY1a9Vp92mdkVGKVYSOa
zBjU5twXaXCjX1B0cZdeQnjFY8ah5AzsGtQChpZeq6uyztUGVL0uVpRJ+aZg
DpI5lX7BS8z4egSRglkl71QFgrv2llO1eKyPypTYXpEvoVOukG47y+lydWks
coV2rS+h/Q0SZPJl9OmrteRrFRAVM0OWukq4Lq5iHiVkJC4FOkqJ9PVI3pAE
YVY1jHypUlI3abwyVH3lilV3wfxzmDUCWQ+qeU5hp6JmzTPRJX7EOasmVMmY
Etr4L46ncf8Qym0ijtGqYyBxNxdjq+J9s4UeXWXvTMGL80m8bG25ttrxETsV
aSNNC/ApmxGCYUhZDZjF9/9D/DxUv5pFnrNG4IWC1PGUHUkaHUEugUEU+gNN
CY0cHwHE+hJUe5Orew64HufI6M/AF+0cjuS5t5z89zZ67i2eIx/jW3nur8Mh
lvj8LHrur1Tyk+b7LLSU4bkwQCphjM915dHmc15DjL+OnvvPYdene77Wp+e9
vD5WSj/f8BzWtv9SL7Ljuc7l/fFD1teCXs9ztDouxbZxPiZMDEsONj7nawkP
ARORH/5G59E6jQ/d75OTWyqtdaf7uY9+bh3Hpp5D8vvDiKoIt7ehnnt76+7O
2//56S1vg+mQtjFoPrcLG3v71gjL/c6uj/xFIfXcX5lC/XM012GR252efXz0
8+043s7nNsMlwI+Ptm+/b2/tCfyU//4VObF74HJAkxxkS+D6eJ9h0LM+l/K4
s3m/HxuvutCq67ku8HU+h9TR3HLHc367V8z3pq1IDbqeC1XBvpTcmXe/Cf51
od+HwO9j7/fjyw9jdIZS33NbwHnAAr5Dj2C5/x56BBFd9Nxfw8s/Ix0Gq4ej
oji8G1UM79IssWY4FnDAUBvwTdNOow56WpyR4xU2SujDskdYshm5RR6nt3Gj
N3LAR3FTHR30SRC+SKu7ydheUDsBM15YqGvRVeAhSsXQS6CLwNEis1rc2ZTV
6KuQuveCyogSRDlKOCuAra8PvD0ReWqimyBdynm7/lm7HCMud29HX8CkUIVL
rQxXUgfqFkaBtag/IAu+YdQc+3u7B94YeSG5RAxfNAODtYNuefI3tsye+AZw
MG1CZpLC1PHaGWfeyveJqq1UGgwmhwol6CE5k2IUoPypsFCdvrbSZ2skK0ZT
vcTsFHGR0jd+5ZSYQRGOZUb+AbG2SmyWNbrS+og/2hZpfLuRp8QfzWHUt7jS
jZZL/NF2jP72doddI59Okdx8KHzVM0vLuNh+lm7e3cXJt1xL3+d6O+oUtdee
5QPgsgVY/nittfR9rrOjPmzZNEvQdt2nUz25YpZgS/hZ2qbglbMETdl9OgzF
K2fxf32SuNuHudeb5X3OqGOWtvm6/SyfIgX0E8B1ZukH7rVm6TCqrz/Lgb6V
9t5r6TLcP2gtAuSml2f7tcTOge1n+RRpup+k/zlYp7X195uly/HxHrN0uEXe
Y5YOp8n1Z+lyqWw/yyfI6zawumvMsgHprjNLl6Pn2rN0uoGuPUun0+Tas3S6
VLaf5RPkUhuY1DVmGXwULvVJnNEnQNODq5fQ+Pxh1J7lrSv0Btb4+VbGOmjq
7VnQ4REC2869EprEYMgeEwOk/19jZ5EGf73PZ61ZYsBt4nTb48smTrf9LG/a
d7UeX3+WE7oP8OU3fI1le70uttV4CV++4FSCoSaijbNgPCfYakg+blOv3CWT
LWaJbTWcpaPe6uB6cMFZ4tKk76M14yyS6/iue8gVs/zLcO+mbf9+0j7Eufjz
poEuCPB3V87i8WUL4P72npONszSuSb7fLJ2b/GftCD9+O+87S5tM3nstza8+
mje07d3qp4JNFHCv4d0CKujA/s2zeAr4lPjLJsay/SwBpG96qm6/+31oZPED
76t5xFj3vprH21v3Fdb1AvaKWT5JrNss0LafReFdu6T5u+1m+eSw7tOy7XsA
u+0sH4x1nZkB8UfnCehvb/8KMT4ipg2z6ByDxreNnIPdtCvpYLvI7413rsoA
3uFqxVEldOo7ffQFULvip70BUwFlFyR7QHfgANcVG+0Jht5WoVCaqy+BUr9e
oRz96jE/+nbzmDeqRsi7bcZsxyha7+l64j3HuBVvO6Zjtb/a2twly23HtPjE
B69tQ5Jk75gNiYG9Y97ITjc7seIxXa6rq8Z0ctIrxnR9roRbuuxLouwd0yK4
Lca86QDCp0RzPYltvWOueT5dcq1HkN3+QN7b4LEbhFRTRI2diDoK+Tx82zSW
RZsz4z5iItrkgxLRdA5aXETFFQjuLEzX3Xm4ldXWl2rV2VPlug38+go2RXui
9oV9y/AFFOKUQ/WLr7hAjje6zKXKNPO9+XarHi53EHfEiO4wcVZXV1MLqfSa
SuJY500pXIZq8+svD4Usva4SUn21oxppky6/sLubIL7j3o5pVqj15Xni9m5U
40QmCBVQXUKbyu0MjbUaq+xq+tnM84Ql3d+5Gtp9va+oAgxDcLoZ7qEXCN1n
848quuZauvDdK982Lq410iqn4DqD/Wrts2492JGeHnyv0V9nTHNdfmvDfqXp
sp+heW8SUN1XcouDI3LZmNImA5DVPd9W9aKt8j5fSlmWDXfb+kletWehOom6
UcmHZHtun4V5lT1xhWl2lXi7Iu9yCytDC/ZNNyD0onps/45Uwi2GX2Eib/32
zs/Wi+92yGw9vDuV8srhm7e+WbX7aHvvcbdsO7zHz7L18O5EyW2H92RI/j6w
rscL+FtBvjv98XeBtNuHQjqHbx8D6R7ek9u45fC+dMRrDW9nEP4ucH77zPVf
4+D6Evu2Hd6T0bft8K1zxDqH9+Xw/Q4I9jqZ+R3Dr5Pu3TW8Nz9vq+H9iXlb
De/P9tpqeH+a1++B3nvjXNsN7z347Yb3gn674b2g/8Qp7rpx28ZwFVXsSPfq
G+6DvtfN7nor0V65QXPdtK63cZj3utlPnx7JmI9jjDTc0dcY3goFbTf8ny9l
rhreFzDaYnjHdn7jxfdFlLYYvim49FH5fAfL+W34fEcM6hrD35/PfwLsoite
dY3h3bxi6+FdUazthn8i7KIZ5tpu+Cdw7v+MxW9ORrkqfPcRXJ342eTqbD3R
DurtbZt24hzPGODDwN4WoS7Vz/x64S3d05y84s9XlNHyNYd/nAc8KnNXzbBa
2Uwqu0utBqrul0a1zOPW8UdRj+70HIsT13FJ8U2duuNana6PNVYyXaR1sy4f
VuaDvWCBZXSvy/qnxWRFkVSu+VeZ+3FPbA7pqRqDUpF0KiUspDFhItU+fUFv
3ZKhUSVDGnbGjVN9ycuiDHVz4wGh4Gpc0hERKrndR0Dqh9vJ2/jatqaqp3LH
xLzdeq6ofYbbJM7lN/C2+ZR+ox+BTzUS2/RTai5d8tiYvqee7R8POwsJqDdu
t0eG7SlV284FcaQkN7akdoURAx0QvdzsDRAL0knwj0J2cacNVb++m1SLJCqy
TkUZrVT6oBa9IULs4p++4Dw3Wse3Jm7ZZ2k1o9acOJF0MyqkiwfXipbC8JZY
CnY+Yopgu0oKwwg5dqyXaoOG8WKG+e6MFCPXYOC9qEC3DuTGG0lo3JUbsV37
IGhJV/rG7AM8A5tjZewpheqi4psnwu72RnvwZ7J9Wx5Hp4iIdzoI8G7Hd7sd
3+3JDHfh1z1zD9jVA/PQPDJfXOc7nOP28AP/g5O8ffr2JVu5WL66ixWozxM+
lYhwP95KOmClPq+wacJoNPo47/NswTzllAgzRnmGjCGdX6brVmcXQbs7jX5U
8XPSt6gL5XWbKMoBSGpuEoLl3RWpd3c14pK2DovHFjvTGXN8lnBL79BUYVqY
qhhwjoYvHE/CplE9nvtZJyzquVYuNS2oXAc5LzAfO2B9fbg7xOUPnxV1egF8
gF7K9YVgBe4bfHCPH3xpz4jE+SMdos58NwXXM1j2rg6FmYjrn6nqM4ey/dym
FUtfcZ1+YAdVseBGPWWyLDJMoyFGN04nr4uzM9UnBDMYsJ4wDcXqWNKfZBzV
ik9cg3QW2yNDwgsfV/WS88IssGDyWclFv6mDRcodSRNLzfqwmtQtAMqOge2g
bIxETK9sARaUV1gKvyPPRpAJwYR4UKuWckmzw5VCHU5uwbL7j/YePPi3YGn3
uvSWf2GW9j0oUZLu5Mu9s4UgVEVyNO7w6zuexfJ0oHL2lqUdhhbCUffpKJ3v
FifD7IxQPSAyIQWht3FZhwKlO3aIUn6i6J5L+ocmcgPWmWhprrb0ZbwoIQ5f
BNttEFvb1r5ZQ1BehPAC77RdvJNmCmYFP+P0fcU07w+Pc9r/8MQDmo2/APeI
D3IHExqC4x/48QqT2aQpF0a2p7ryds/y0M8C4KSVIM/pOg3H9WKwJ31IzN0e
pIO0O2eX0UR8rn3jJZKhJ9/uP3niga4wNvC4gSvtnc4L7CsinZGStpwsqOo9
tiygzj82LcGYFqmKHUZWuXQ9ENmAsyfVDBs3uAqKadwky/WRjLMc8Q3h7GGH
I9oSd3bS6nfGOIkprg/usVaKI7pU0uTe6P5oF0dLa5Q7e3eIR5828v6inlwC
KtcshJYpzae2aGnV6oxlQ2ssaYxFBkLVs2kvPz5YfHyS0uPRsIG8gaPP24KD
Ph9TevwaAmIfXTRSGVJUX8JaSbp0ai5oFdJEE9tEhF5i7JxKIqWT0szFvyPq
LvXPCVUHhJEOWQnNqoS1U0udHRilkGUCxL+IIT5Ee9N871+FrX7iJmHRm7Cc
PrKcRmOliN9wb/ZN7Ia7GFIvU27HEnc87jbfA4g6O62BpDrLpDWdbm92jbZq
1KBLw71rTtVVTdKCtasiapBnJQV5kcF/VgvC6BmLEeqaJgL8Ms1q1xaE21+5
Th2NDljsVuhlgdKKzTVKC6VjaSHv86owULXlsr9g31vqXtYc9K/Ore7eGcbu
tX8bbiVkL72SInKPWkUKoft7MeTaTueLoe/NSI2tdBeefweswU0rnPj3wRrA
maNfsoo6Y/ngw4nujlU1oiQu2hDqXK/I6Y7tSpszSehBGupSK6Hgz5SmX3Kv
wTfNBAGbluHtiIvuRbKFoJ+/8rpZiIKQ6n1TdQslehCFknsguTiJ5qviYwqi
+F/WL+A+uGMMVnfhvfkN/QLuBA7TOt2WDK56QI4vPvXQp4t7k82lQxHwQNms
F90UJMBOiV0/6BrvjIsu0uD6rmtbxfXs7ogsSBfLySwDA1IjYtQGc2TcPR3X
JTButabh12qjTjf6DqRPNGkK2D5aOiLTZoTFdbzeR+fwUhF8/RJ7i7kOzD5Q
WOQAR7B8SaHELpTxHSXdW70rDCmqM0LofEWDCmmbSW9A4TXGi4GTdFmt0LVJ
W+MnXmc5BW6W6eS1reWKIf0KitXfVqm/G6bCkOTgDnTu42l4pnxuvhStD8jp
35wu6rIE6DdX3E78LBylDh4alQ/Da5QY0obBZxyaCwPFCg7gk6Z8pL/aVHe3
Y8DCiZOrVhBB2HfFvnPgb8jWvHrsMWNsQ2OCXCZ3dxfv3DbmvxFl0M2DGio5
nXJs9K61XTTOW9MQH1RTDe/6qdCZ5Ga6eiI1CTLhI1R2qZ9Y3yQSvdu4nMRh
gT9yd7zupCjc7iQBrt5o0eD+f1c0OXFPezmycdTVL4kN8iT5pkzPUfCRvEya
ffwQaxtBGmetnumBrocsksuqokQYMlhpcYnnnb5xJt6ndhOl+Zq87ByLIYbQ
CB5RwDatQt/I0A8X34Iuzf1n++agIMZRiuLRTH6QzoTW0MNZpSxgtFGnU4X0
wsMa7IZs7OjrKFNCt6pWDsyOqOChdl/VOgtjlHQ73a8Y0XK0XDmiYexsejrE
lcLGVUzsoNmme+A9jFnpuEuVzDMCNXcUZk7rbhh79vLbxcr+fR3LH8FJhOhz
V9BHJ/HSN14XcOh+C/uRc0ttare9Q+N3tx+/2zV+D60umON/mVEYB3zdJAc3
75oNu4SlaS/A0Iprr5UR8qcff/rRnD4/fP5Y3DGIxC5Fi3q0wui4pempatT6
lbGj85H5E7Urhf8Z5bZmDkRaklQ2mIZr6uwSo4ZP0l5aTWd++vmnn0HsnNjJ
Cq9absH4mPmJsNj+CrvWr0jdqxGHYZ7LlDuYM7RpkZLhxqECj7vkJHB3Qs2t
g/2dEcZb06oC5lLBTCpZDi/xH4cY9QWpX9iUWxqDCnz90VIPVZgiHpOtnQtM
944GlnVLFGZqfGUmpSX3fjrfoVXAaUgPdnOQ1pPZcHd3OEQV9bOa7qoLK3A9
Sl3r5FRNBPMgYwtj9I9+BPxAy4knHOHpkELlO8wq2Dtw8/GxUKSAgqoEgKdC
eq3qHcvPA3CwkbWPX8ywfXmuM61gFlx83P8a97IEe4FCisXYaZfNE+KFA+us
HDpOInTkgMyWCIerYOYjjcsdNEZgP3ATZoHBrCxW5zPaP4jrspiuEA8xhQHn
CLUVQC6ltIYJphSUCHQciDoDuo4rllUvokovqhE40CZSXtKXLNfxaZ9kKFVA
OgwIsPgFEUNnuAOBEHlgfRe/2Qz0qxeMFdPg/yWNyVsoNFJl5WGjeIQIOW7m
Z0NcFLNMBqQfKEJfNDWn8Ka4C5ALC7SsX8Dc3Gp8Lc2o/WiO71YBYRrIJPFe
o2vqNDfOEmtZ1Ewx83U42YBc5PCvCOt+AMvXdohE8fJrGId6J1UtiXBeJCL5
i7q3ms9R4thfSG5zF+65JY6FhXuwFxzyjmbXNmk0npjIdPc9zbCrfW2XZEyh
kAe2MrOT1843TwuRTt8ORq6X8kT3W5EVu3FBTeE8A5IbK8CziQGCgmlE74jm
sPUE3m9/wVJGwLIrAKoM5ZC/jPErgGnUeHRq1DXYy2ZfMpUPs2pSYJpOL4U4
/uAyot0AA2g4yzOQ8c4sUGjrSUeCH2iaTdMSl6MgHOaSBuYjc5KhCcemBCgs
F8h5qZQLaAJLJL5Hd3ZHd9EpdpmVdk7Nt9lWo5Qnri4zvcAtV2SaOAZNQbiU
No9eRjRFFnDCVZELgZk5aAM1MLfahrmduKBpQYPC2Moq9zSAbf7AUAcCGpn/
yi7I/5PWJEcajzXVmte5JJqrt7qXwX6FGAi1CfelaWAxBkaEyV61XSwZh7n3
nRsLj4IOP60GoMZ4DOVtk5hE/QYzv4CpZpg8RYxOJA4VtjE3yuJ8pdLXbzQi
BjkRXPqaXRagMzic8/EC44p2kRZPBYrQKisuQTWuZtkyMBlkBs5mT0PKFqGQ
X7Tko9ezy7SkvudfYyBQvYEUclgwMppp4DSLYsqk7ZgizCXVksJS1KvwRaJu
o2EjTdZfOjhU5uTb598/OXQaKQncKdYIK855/bQY8gJO7XJerMXARFN5VU5m
1AAdMyqWC3FFuE6TMNUCkOCctUe/IALlfs6cGlUIgFjXc0xkLGJyTHSYu0Pc
f3EDE729pcEqAe2NU4n0pQ0Qs26zxIV9KZDthKc696hIE3YqPReXQWVBY8HV
+9jxQaRp7keaJkx4q7IWtI8UwPfu3Y4nBExUnBAjTdm52rVsc+vl/g6fR4Zn
zypQh98fgELBbqdM+Ngz/iorUAWxJF0Fpfu9ETCjBzQD/fPhgOLVpFvZ+XqH
vY+oLJeE5rDUfSRM1rhTLKaahUgwSg7P/53DK8gSrKcGT4+LFZdSS3MT6yEq
3wXRxdE7QYzWACymyIew1xWGyBkDgLkXtCTOCMVJ3XIHrcPkjLZmTS6lEiSm
KcudK8FxwPG6KQdDprB431y1MpjM4wnSFrnCnWo4ECHx8ujg+dOnR88Ojw6D
XI8QUOwyBw5YbXE2hP+iegA8HhfZe8hmb/RotLvjvE2SDAVTsafdbWGCGVQW
jE7UsIAPT83z40PfbdbVwfP5X0h4Tlp7/tJHZQ3566oYpizwieHRPpFiWgUN
fWIgUUCW9xcgNFNWJVDTMfcdRMYgU4HwRE4Ag4RZxPwgtTUUctugF6JdOLa2
ga4wU9B7HA6IJtZVUc3PopPskv0JSlKUwRSVbNrO7PZiAxaomxTUefbayhWK
/LX5uswA53+wGcs/4qqAFOxL5kz1/Tk8cZi+Ll7TI6A34F5hWfD9+Uqc9zjE
5pM1Zw4FLEX8T0pYAOoTALEb46IsMXh0gzEHrRqQ5GlJZI0+DFjWlNJm+JLV
qljAzveBJBOEztNiBoh/AiZjBvsH/KD87iQ5kNJxNOhI8v5egZTb5FJwQDos
4SDN8M6Dx3Aq/4GyckZdewpK6YHdX/BEZrxaLOERP2CPBzy1JUBBER3fs3OY
jY+cdFuX9NtL1+W4EuBaPkz8bX86Bdjn5tu0fE0J3liAc8gnmoSV7/JCsIIo
/F6Wjkf7B+4+9tNxwEhyEJf03ICdyvHaBqZagJ07wwt8/qxHYco7jxOa85iu
+swNekMRSsn/AW+bAj0B8AAA

-->

</rfc>

