enrollment-roadmap.xml

<?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.3.6 -->

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

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

<rfc ipr="trust200902" docName="draft-richardson-enrollment-roadmap-03" category="info">

  <front>
    <title abbrev="device enrollment">Device Enrollment in IETF protocols -- A Roadmap</title>

    <author initials="M." surname="Richardson" fullname="Michael Richardson">
      <organization>Sandelman Software Works</organization>
      <address>
        <email>mcr+ietf@sandelman.ca</email>
      </address>
    </author>

    <date year="2020" month="October" day="07"/>

    <area>Internet</area>
    <workgroup>ANIMA Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document provides an overview of enrollment or imprinting mechanisms
in current IETF protocols.</t>

<t>This document is being worked on in the ANIMA-WG, and on github at:
https://github.com/anima-wg/enrollment-roadmap</t>



    </abstract>


  </front>

  <middle>


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

<t>There are numerous mechanisms being proposed to solve the problem
of securely introducing a new devices into an existing managed network.</t>

<t>This document provides an overview of the different mechanisms showing what
technologies are common.</t>

<t>The document starts with a diagram showing the various components and how they go together to form five enrollment scenarios.</t>

</section>
<section anchor="components-of-enrollment-solutions" title="Components of enrollment solutions">

<t>This diagram is taken from <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>, which
is where this work started.</t>

<t><figure>
<artwork><![CDATA[
                                           +------------------------+
   +--------------Drop Ship--------------->| Vendor Service         |
   |                                       +------------------------+
   |                                       | M anufacturer|         |
   |                                       | A uthorized  |Ownership|
   |                                       | S igning     |Tracker  |
   |                                       | A uthority   |         |
   |                                       +--------------+---------+
   |                                                      ^
   |                                                      |  BRSKI-
   V                                                      |   MASA
+-------+     ............................................|...
|       |     .                                           |  .
|       |     .  +------------+       +-----------+       |  .
|       |     .  |            |       |           |       |  .
|Pledge |     .  |   Circuit  |       | Domain    <-------+  .
|       |     .  |   Proxy    |       | Registrar |          .
|       <-------->............<-------> (PKI RA)  |          .
|       |        |        BRSKI-EST   |           |          .
|       |     .  |            |       +-----+-----+          .
|IDevID |     .  +------------+             | EST RFC7030    .
|       |     .           +-----------------+----------+     .
|       |     .           | Key Infrastructure         |     .
|       |     .           | (e.g. PKI Certificate      |     .
+-------+     .           |       Authority)           |     .
              .           +----------------------------+     .
              .                                              .
              ................................................
                            "Domain" components
]]></artwork>
</figure></t>

<t>Five major components are described:</t>

<t><list style="numbers">
  <t>pledge: The node that is attempting to enroll.</t>
  <t>proxy: A node that is within one layer-2 hop of the pledge that is helping.</t>
  <t>domain registrar: the Join Registrar/Coordinator (JRC) that will determine
eligibility of the pledge.</t>
  <t>MASA: the representative of the manufacturer that has a pre-established
trust relationship with the pledge.</t>
  <t>the domain PKI (if any)</t>
</list></t>

</section>
<section anchor="map-of-enrollment-solution" title="Map of Enrollment solution">

<t><figure>
<artwork><![CDATA[




                                              .-------------------.
                                              .   generic (YANG)  .
                             .----------------. voucher semantics .
                             |                '-------------------'
                             |                       .---
                             |                       |
  6tisch      6tisch     Tran|ition to               |
  minimal      zero       Con|trained                |
  security    touch        Bo|tstrap      BRSKI      | Netconf
.----------..-----------..---|-------..------------. |-------------.
|          ||           ||   v       ||            | v             |
|          ||..................................................... |
|          ||. constrained voucher      .  JSON format voucher   . |
|          ||.      (anima)             .       (RFC8366)        . |
|          ||..................................................... |
|          ||           ||           ||            | |             |
|          |.............|  ...................................... |
|          |. COSE      .|  . standard signature (CMS - RFC5652) . |
|          |. rfc8152   .|  ...................................... |
|          |.............|           ||            | |             |
|          ||          ............................| |             |
|          |.........  .  EST-COAPS  .. EST-HTTPS .| |             |
|          |. EDHOC .  . w/DTLS sec. .. TLS sec.  .| |             |
|..................................................| |             |
|. constrained object . ||           ||            | |             |
|. security (OSCORE)  . ||           ||            | |.............|
|...................... ||           ||............| |. call-home .|
|          ||           ||.........  ||. circuit  .| |.  ssh/tls  .|
|........................|. DTLS  .  ||.  proxy   .| |.  .usbkey  .|
|. CoAP proxy,stateless .|. proxy .  ||. stateful .| |.............|
|..................................................| |             |
|          ||.     IPIP proxy,stateless           .| |             |
|          ||......................................| |             |
'----------''-----------''-----------''------------' '-------------'
                  ^            ^             ^              ^
                  |             \            |              |
                  |              '.          .--------------'
                  |               |          |
                  |               |          |
                  |               |  .--------------.
                  |               |  . manufacturer .
                  |               |  . authorized   .
                  '---------------|--. signing      .
                                     . authority    .
                                     . (MASA)       .
                                     '--------------'
]]></artwork>
</figure></t>

</section>
<section anchor="components" title="Components">

<section anchor="generic-voucher-semantics" title="generic voucher semantics">

<t>The abstract semantics of the voucher, described in YANG, are in <xref target="RFC8366"/>.</t>

</section>
<section anchor="constrained-voucher" title="constrained voucher">

<t>The semantics of the constrained voucher, represented in CBOR,
are described in <xref target="I-D.ietf-anima-constrained-voucher"/>.</t>

</section>
<section anchor="json-format-voucher" title="JSON format voucher">

<t>The semantics of the basic voucher, represented in JSON, are described in <xref target="RFC8366"/>.</t>

</section>
<section anchor="cose-8152" title="COSE-8152">

<t>In constrained systems the voucher is signed using the COSE mechanism described in <xref target="RFC8152"/>.
This is to be replaced with <xref target="I-D.ietf-cose-rfc8152bis-algs"/> (now in RFC-EDITOR Q) and
<xref target="I-D.ietf-cose-rfc8152bis-struct"/> (in WGLC, being revised to remove countersignatures).</t>

</section>
<section anchor="standard-signature-cms" title="standard signature (CMS)">

<t>In un-constrained systems the voucher is signed using the Cryptographic
Message Syntax (CMS) described in <xref target="RFC5652"/>.</t>

</section>
<section anchor="edhoc" title="EDHOC">

<t>On constrained and challenged networks, the session key management can be
formed by <xref target="I-D.ietf-lake-edhoc"/>.</t>

<t>This document has a WG called LAKE.</t>

<t>The CoAP-EST layer on top is described by <xref target="I-D.ietf-ace-coap-est"/></t>

</section>
<section anchor="est-coaps-2dtls-security" title="EST-COAPS 2/DTLS sec(urity)">

<t>On unconstrained networks, the session key management is provided by <xref target="RFC6347"/>.
The CoAP-EST layer on top is described by <xref target="I-D.ietf-ace-coap-est"/>, which is in the RFC-EDITOR Q, waiting for DTLS 1.3.</t>

<t>The ACE WG adopted this document, and published it.</t>

</section>
<section anchor="est-https-tls-security" title="EST-HTTPS TLS sec(urity)">

<t>On unconstrained networks with unconstrained nodes, the EST layer and
session key management is described by <xref target="RFC7030"/> as modified by
<xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> (BRSKI).</t>

<t>BRSKI is in the RFC-EDITOR Q, waiting for <xref target="I-D.ietf-anima-autonomic-control-plane"/>, which is awaiting IESG go-ahead.</t>

</section>
<section anchor="constrained-object-security-oscore" title="constrained object security (OSCORE)">

<t>On constained networks with constrained nodes, the CoAP transactions
are secured by <xref target="I-D.ietf-core-object-security"/> using symmetric keys.
The symmetric key may be pre-shared (for 6tisch minimal security), or
MAY be derived using EDHOC.</t>

</section>
<section anchor="ultra-constrained-enrollment" title="ultra-constrained enrollment">

<t>The document <xref target="I-D.selander-ace-ake-authz"/>. Version -01 expired in September 2020, but is expected to be reposted for discussion in the ACE WG.</t>

</section>
<section anchor="pledge-traffic-proxy-mechanisms" title="Pledge traffic proxy mechanisms">

<t>Traffic between the Pledge and the JRC does not flow directly as the pledge
does not typically have a globally reachable address, nor does it have any
network access keys (whether WEP, WPA, 802.1x, or 802.15.4 keys).</t>

<t>Communication between the pledge and JRC is mediated by a proxy.
This is primarily to protect the network against attacks.
The proxy mechanism is provided by as many nodes as can afford to as a benefit to the network, and therefore MUST be as light weight as possible.</t>

<t>There are therefore stateless mechanisms and stateful mechanisms.
The costs of the various methods is analysized in <xref target="I-D.richardson-anima-state-for-joinrouter"/>.</t>

<section anchor="coap-proxystateless" title="COAP proxy,stateless">

<t>The CoAP proxy mechanism uses the OSCORE Context Hint to statelessly store
the address of the proxy within the CoAP structure.
It is described in <xref target="I-D.ietf-6tisch-minimal-security"/>.</t>

</section>
</section>
<section anchor="dtls-proxy" title="DTLS proxy">

<t>A DTLS specific mechanism for COAPS, is described in <xref target="I-D.vanderstok-anima-constrained-join-proxy"/>.</t>

</section>
<section anchor="ipip-proxystateless" title="IPIP proxy,stateless">

<t>An IPIP proxy mechanism uses a layer of IP-in-IP header (protocol 98) to
encapsulate the traffic between Join Proxy and JRC.
It has some complexities to implement on typical POSIX platforms.</t>

<t>At one point, it was described in <xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join"/>, in an Appendix.
Another home for the text is desired.</t>

</section>
<section anchor="circuit-proxy-stateful" title="circuit proxy stateful">

<t>The circuit proxy method utilitizes either an application layer gateway
(which in canonical 1990-era implementation requires a process per
connection), or the use of NAT66.
It maintains some state for each connection whether TCP or UDP.</t>

<t>It is this most expensive and most easily abused, but also the most widely available, code-wise.</t>

</section>
</section>
<section anchor="call-home-sshtlsusbkey" title="call-home ssh/tls/usbkey">

<t>The NETCONF call-home mechanism assumes that the device can get basic
connectivity, enough for an out “outgoing” TCP connection to the
manufacturer.</t>

</section>
<section anchor="manufacturer-authorized-signing-authority-masa" title="manufacturer authorized signing authority (MASA)">

<t>The MASA is the manufacturers anchor of the manufacturer/pledge trust
relationship that is established at the factory where the pledge is built.</t>

</section>
<section anchor="enrollment-mechanisms" title="Enrollment Mechanisms">

<section anchor="netconf" title="NETCONF">

<t>The NETCONF WG is describing this in <xref target="I-D.ietf-netconf-zerotouch"/> document.</t>

<t>The NETCONF Zerotouch mechanism provides configuration and ownership
information by having the pledge “call home” to a location determined by
a mix of local hints (DHCPv4, DHCPv6, and mDNS), as well as built-in
anchors.  Additionally, ownership vouchers can be alternatively distributed
by portable storage such as USB key.</t>

<t>Upon reaching a validated call-home server, Zerotouch typically “reverses”
the connection providing either an SSH or TLS connection <spanx style="emph">to</spanx> the pledge
device such that it can be configured automatically.</t>

<t>Zerotouch relies upon either open or very easy access to network
connectivity, along with the ability to make an outgoing TCP connection to
the Internet, or to the provided local configuration agent.</t>

<t>Zerotouch is seen as an updated version of TR-69 by some, appropriate for
configuration of residential appliances which are drop-shiped by ISPs or
other service providers to homes.  That is not the only targetted use.</t>

</section>
<section anchor="brski" title="BRSKI">

<t>The ANIMA WG is describing BRSKI in <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/>
document.</t>

<t>The ANIMA WG does enrollment with the aim of creating a secure channel with
a public-key infrastructure (PKI) Registrar.
The secured channel is used to perform Enrollment over Secure Transport (EST, RFC7030).
The real goal is the enrollment a new device which was probably been drop-shipped into ANIMA’s Autonomic Control Plane.</t>

<t>That is, after the pledge has been assigned a certificate within the (autonomic) domain, the device (no longer a pledge) will then form secure channels (typically using IKEv2 to key an IPsec channel).
On top of that channel a routing protocol (RPL) is run to form the Autonomic Control Plane (ACP).
The ACP is then used as a management network with which to configure the new device.</t>

<t>BRSKI is therefore step one of a number of steps, the ultimate goal of which is to bring the pledge into the ACP as a new device.</t>

<t>BRSKI itself does not provide for any direct keying of the network (802.11 WEP/WPA, or 802.15.4 security).
The provision of a domain certificate at each node can, however, be used to do that kind of keying: for
instance 802.15.9 provides for use of HIP and IKEv2 to key 802.15.4 networks.</t>

</section>
<section anchor="transition-to-constrained-bootstrap" title="Transition to Constrained Bootstrap">

<t>It is distinguished from BRSKI in that it uses DTLS (rather than TLS) and constrained (CBOR) vouchers.
It is distinguished from 6tisch Zero Touch in that uses CMS to sign rather than COSE.</t>

<t>The ACE WG has adopted <xref target="I-D.ietf-ace-coap-est"/>, but this is not a sufficient.</t>

<t>The constrained version of BRSKI is current described as part of <xref target="I-D.ietf-anima-constrained-voucher"/>.</t>

<t>The use of this technology slice is attractive to IoT deployments where the devices are not battery powered (lighting for instance, AMI for electric meters).
In such situations, the processors in each device have significantly more resources, and in particular far more code space available.
The use of DTLS to secure application traffic (as described in the ACE documents) is already common, and so reuse of DTLS is desireable from a code point of view.</t>

<t>However, the network capacity is still limited so TCP and CBOR are still important.
The network may also contain extremely constrained devices (kinetically powered light switches for n instance).</t>

</section>
<section anchor="cloud-based-registrars" title="Cloud-based Registrars">

<t>BRSKI depends upon a local join proxy to direct the pledge device to the location of the Registrar.
Not only does this require that a join proxy be widely available, but it also assumes that the owner is able to operate a Registrar.</t>

<t><xref target="I-D.friel-anima-brski-cloud"/> deals with two use cases:</t>

<t><list style="numbers">
  <t>where there is a Registrar, but no join proxy.  A redirection through a manufacturer or VAR operated register points the device to a Registrar located on the Internet.</t>
  <t>where there is no Registrar (yet), but the network operator does have an RFC7030 EST server.  The cloud registrar provides a voucher connecting the pledge to the appropriate EST server.</t>
</list></t>

</section>
<section anchor="brsky-asynchronous-enrollment" title="BRSKY Asynchronous Enrollment">

<t>BRSKI depends the join proxy being available in the location where the devices are installed, and for that proxy to also be able to communicate to the Registrar (possibly over the Internet).</t>

<t>In a number of environments, such as new construction, a number of devices need to go through an onboarding process, but there is no connectivity available. (Possibly not even LTE/3G due to metal walls, lack of towers, etc.).</t>

<t>The <xref target="I-D.ietf-anima-brski-async-enroll"/> proposes two amendments to BRSKI:</t>

<t><list style="numbers">
  <t>the use of CMP rather than EST for enrollment, which eliminates the need to keep a live TLS connection between pledge and Registrar.</t>
  <t>a discovery, store-and-forward mechanism for moving voucher requests and vouchers between the Registrar and Pledge, including a batch mechanism that aims to reduce the amount of walking that an installer might have to do.</t>
</list></t>

</section>
<section anchor="tisch-zero-touch" title="6tisch Zero Touch">

<t>The 6tisch WG is describing this in
<xref target="I-D.ietf-6tisch-dtsecurity-zerotouch-join"/> document.</t>

<t>The 6tisch use case consists of very constrained devices with very
constrained networks.  Code space in the devices is larger than typical class
2, but the devices are typically battery powered and wish to sleep
significantly.</t>

<t>The use of CBOR for vouchers, COSE to sign the vouchers saves significant
network bandwidth and code space.  Both CBOR, COSE and OSCORE are typically
already in use for the application support.  The addition of EDHOC to provide
asymmetric bootstrap of OSCORE completes the suite of constrained security
protocols.</t>

</section>
<section anchor="tisch-minimal-security" title="6tisch minimal security">

<t>The 6tisch WG is describing this in <xref target="I-D.ietf-6tisch-minimal-security"/> document.
This mechanism does enrollment in a single request/response message, but requires at least one “touch” to  pre-share symmetric keys.</t>

<t>The 6tisch WG felt that the number of round trips required to do EDHOC, and the size of the vouchers required an even simpler protocol.
As existing 6tisch-type technology is typically deployed with network keys built-in at manufacturer time  (no “drop-ship”), the switch from a static network key to a PSK for authenticaiton is considered an incremental improvement.</t>

<t>All other methods are considered zero “touch”.</t>

<t><xref target="I-D.ietf-6tisch-minimal-security"/> is in the RFC-EDITOR Q, waiting for core-stateless on which is depends to leave the WG.</t>

</section>
</section>
<section anchor="discussion" title="Discussion">

<t>A goal of this document is to provide some guidance in selecting which
enrollment profile to use for a given scenario.
This section tries to provide some constrasting comments between the various mechanisms.</t>

<t>(BUT, it does not yet do that..)</t>

</section>
<section anchor="open-issue" title="OPEN ISSUE">

<t><list style="numbers">
  <t>insufficient guidance if there is no internet connection.</t>
  <t>classes of devices where the manufacturer will never have an HSM/PKI. so, it will only be a self-signed key.</t>
  <t>how does a supply-chain manage BRSKI?</t>
</list></t>

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

<t>This document includes a tradeoff of the security attributes of the different
protocols, and so the entire document contains security advice.</t>

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

<t>This document does not define any new protocols, and therefore does not
have any IANA Considerations.</t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>TBD</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor="RFC7049" target='https://www.rfc-editor.org/info/rfc7049'>
<front>
<title>Concise Binary Object Representation (CBOR)</title>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author>
<date year='2013' month='October' />
<abstract><t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.  These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t></abstract>
</front>
<seriesInfo name='RFC' value='7049'/>
<seriesInfo name='DOI' value='10.17487/RFC7049'/>
</reference>



<reference  anchor="RFC7250" target='https://www.rfc-editor.org/info/rfc7250'>
<front>
<title>Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
<author initials='P.' surname='Wouters' fullname='P. Wouters' role='editor'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig' role='editor'><organization /></author>
<author initials='J.' surname='Gilmore' fullname='J. Gilmore'><organization /></author>
<author initials='S.' surname='Weiler' fullname='S. Weiler'><organization /></author>
<author initials='T.' surname='Kivinen' fullname='T. Kivinen'><organization /></author>
<date year='2014' month='June' />
<abstract><t>This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS).  The new certificate type allows raw public keys to be used for authentication.</t></abstract>
</front>
<seriesInfo name='RFC' value='7250'/>
<seriesInfo name='DOI' value='10.17487/RFC7250'/>
</reference>



<reference  anchor="RFC5652" target='https://www.rfc-editor.org/info/rfc5652'>
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<date year='2009' month='September' />
<abstract><t>This document describes the Cryptographic Message Syntax (CMS).  This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='70'/>
<seriesInfo name='RFC' value='5652'/>
<seriesInfo name='DOI' value='10.17487/RFC5652'/>
</reference>



<reference  anchor="RFC8366" target='https://www.rfc-editor.org/info/rfc8366'>
<front>
<title>A Voucher Artifact for Bootstrapping Protocols</title>
<author initials='K.' surname='Watsen' fullname='K. Watsen'><organization /></author>
<author initials='M.' surname='Richardson' fullname='M. Richardson'><organization /></author>
<author initials='M.' surname='Pritikin' fullname='M. Pritikin'><organization /></author>
<author initials='T.' surname='Eckert' fullname='T. Eckert'><organization /></author>
<date year='2018' month='May' />
<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>



<reference anchor="I-D.ietf-anima-bootstrapping-keyinfra">
<front>
<title>Bootstrapping Remote Secure Key Infrastructures (BRSKI)</title>

<author initials='M' surname='Pritikin' fullname='Max Pritikin'>
    <organization />
</author>

<author initials='M' surname='Richardson' fullname='Michael Richardson'>
    <organization />
</author>

<author initials='T' surname='Eckert' fullname='Toerless Eckert'>
    <organization />
</author>

<author initials='M' surname='Behringer' fullname='Michael Behringer'>
    <organization />
</author>

<author initials='K' surname='Watsen' fullname='Kent Watsen'>
    <organization />
</author>

<date month='September' day='21' 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'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 using a routable address and a cloud service, or using only link-local connectivity, or on 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-44' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-anima-bootstrapping-keyinfra-44.txt' />
</reference>



<reference anchor="I-D.ietf-anima-constrained-voucher">
<front>
<title>Constrained Voucher Artifacts for Bootstrapping Protocols</title>

<author initials='M' surname='Richardson' fullname='Michael Richardson'>
    <organization />
</author>

<author initials='P' surname='Stok' fullname='Peter van der Stok'>
    <organization />
</author>

<author initials='P' surname='Kampanakis' fullname='Panos Kampanakis'>
    <organization />
</author>

<date month='July' day='13' year='2020' />

<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 "voucher".  This document builds upon the work in [RFC8366], encoding the resulting artifact in CBOR.  Use with two signature technologies are described.  Additionally, this document explains how constrained vouchers may be transported as an extension to the [I-D.ietf-ace-coap-est] protocol.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-anima-constrained-voucher-08' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-anima-constrained-voucher-08.txt' />
</reference>



<reference  anchor="RFC8152" target='https://www.rfc-editor.org/info/rfc8152'>
<front>
<title>CBOR Object Signing and Encryption (COSE)</title>
<author initials='J.' surname='Schaad' fullname='J. Schaad'><organization /></author>
<date year='2017' month='July' />
<abstract><t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size.  There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol.  This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization.  This specification additionally describes how to represent cryptographic keys using CBOR.</t></abstract>
</front>
<seriesInfo name='RFC' value='8152'/>
<seriesInfo name='DOI' value='10.17487/RFC8152'/>
</reference>



<reference  anchor="RFC6347" target='https://www.rfc-editor.org/info/rfc6347'>
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<author initials='N.' surname='Modadugu' fullname='N. Modadugu'><organization /></author>
<date year='2012' month='January' />
<abstract><t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6347'/>
<seriesInfo name='DOI' value='10.17487/RFC6347'/>
</reference>



<reference  anchor="RFC7030" target='https://www.rfc-editor.org/info/rfc7030'>
<front>
<title>Enrollment over Secure Transport</title>
<author initials='M.' surname='Pritikin' fullname='M. Pritikin' role='editor'><organization /></author>
<author initials='P.' surname='Yee' fullname='P. Yee' role='editor'><organization /></author>
<author initials='D.' surname='Harkins' fullname='D. Harkins' role='editor'><organization /></author>
<date year='2013' month='October' />
<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="I-D.ietf-core-object-security">
<front>
<title>Object Security for Constrained RESTful Environments (OSCORE)</title>

<author initials='G' surname='Selander' fullname='Goeran Selander'>
    <organization />
</author>

<author initials='J' surname='Mattsson' fullname='John Mattsson'>
    <organization />
</author>

<author initials='F' surname='Palombini' fullname='Francesca Palombini'>
    <organization />
</author>

<author initials='L' surname='Seitz' fullname='Ludwig Seitz'>
    <organization />
</author>

<date month='March' day='6' year='2019' />

<abstract><t>This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE).  OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.  Although being an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration.  Therefore, this document updates [RFC7252].</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-core-object-security-16' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-object-security-16.txt' />
</reference>



<reference anchor="I-D.selander-ace-cose-ecdhe">
<front>
<title>Ephemeral Diffie-Hellman Over COSE (EDHOC)</title>

<author initials='G' surname='Selander' fullname='Goeran Selander'>
    <organization />
</author>

<author initials='J' surname='Mattsson' fullname='John Mattsson'>
    <organization />
</author>

<author initials='F' surname='Palombini' fullname='Francesca Palombini'>
    <organization />
</author>

<date month='September' day='11' year='2019' />

<abstract><t>This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact, and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys.  EDHOC provides mutual authentication, perfect forward secrecy, and identity protection.  EDHOC is intended for usage in constrained scenarios and a main use case is to establish an OSCORE security context.  By reusing COSE for cryptography, CBOR for encoding, and CoAP for transport, the additional code footprint can be kept very low.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-selander-ace-cose-ecdhe-14' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-selander-ace-cose-ecdhe-14.txt' />
</reference>



<reference anchor="I-D.ietf-ace-coap-est">
<front>
<title>EST over secure CoAP (EST-coaps)</title>

<author initials='P' surname='Stok' fullname='Peter van der Stok'>
    <organization />
</author>

<author initials='P' surname='Kampanakis' fullname='Panos Kampanakis'>
    <organization />
</author>

<author initials='M' surname='Richardson' fullname='Michael Richardson'>
    <organization />
</author>

<author initials='S' surname='Raza' fullname='Shahid Raza'>
    <organization />
</author>

<date month='January' day='6' year='2020' />

<abstract><t>Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS.  Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges.  This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-ace-coap-est-18' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-ace-coap-est-18.txt' />
</reference>



<reference anchor="I-D.ietf-netconf-zerotouch">
<front>
<title>Secure Zero Touch Provisioning (SZTP)</title>

<author initials='K' surname='Watsen' fullname='Kent Watsen'>
    <organization />
</author>

<author initials='M' surname='Abrahamsson' fullname='Mikael Abrahamsson'>
    <organization />
</author>

<author initials='I' surname='Farrer' fullname='Ian Farrer'>
    <organization />
</author>

<date month='January' day='15' year='2019' />

<abstract><t>This draft presents a technique to securely provision a networking device when it is booting in a factory-default state.  Variations in the solution enables it to be used on both public and private networks.  The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs.  The updated device is subsequently able to establish secure connections with other systems.  For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-netconf-zerotouch-29' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-netconf-zerotouch-29.txt' />
</reference>



<reference anchor="I-D.ietf-6tisch-minimal-security">
<front>
<title>Constrained Join Protocol (CoJP) for 6TiSCH</title>

<author initials='M' surname='Vucinic' fullname='Malisa Vucinic'>
    <organization />
</author>

<author initials='J' surname='Simon' fullname='Jonathan Simon'>
    <organization />
</author>

<author initials='K' surname='Pister' fullname='Kris Pister'>
    <organization />
</author>

<author initials='M' surname='Richardson' fullname='Michael Richardson'>
    <organization />
</author>

<date month='December' day='10' year='2019' />

<abstract><t>This document describes the minimal framework required for a new device, called "pledge", to securely join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e) network.  The framework requires that the pledge and the JRC (join registrar/coordinator, a central entity), share a symmetric key.  How this key is provisioned is out of scope of this document.  Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network and the JRC configures it with link-layer keying material and other parameters.  The JRC may at any time update the parameters through another request-response exchange secured by OSCORE.  This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner.  Additional security mechanisms may be added on top of this minimal framework.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-6tisch-minimal-security-15' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-6tisch-minimal-security-15.txt' />
</reference>



<reference anchor="I-D.ietf-6tisch-dtsecurity-zerotouch-join">
<front>
<title>6tisch Zero-Touch Secure Join protocol</title>

<author initials='M' surname='Richardson' fullname='Michael Richardson'>
    <organization />
</author>

<date month='July' day='8' year='2019' />

<abstract><t>This document describes a Zero-touch Secure Join (ZSJ) mechanism to enroll a new device (the "pledge") into a IEEE802.15.4 TSCH network using the 6tisch signaling mechanisms.  The resulting device will obtain a domain specific credential that can be used with either 802.15.9 per-host pair keying protocols, or to obtain the network- wide key from a coordinator.  The mechanism describe here is an augmentation to the one-touch mechanism described in [I-D.ietf-6tisch-minimal-security], and is a profile of the constrained voucher mechanism [I-D.ietf-anima-constrained-voucher].</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-6tisch-dtsecurity-zerotouch-join-04' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-6tisch-dtsecurity-zerotouch-join-04.txt' />
</reference>


<reference anchor="ieee802-1AR" target="http://standards.ieee.org/findstds/standard/802.1AR-2009.html">
  <front>
    <title>IEEE 802.1AR Secure Device Identifier</title>
    <author initials="." surname="IEEE Standard">
      <organization></organization>
    </author>
    <date year="2009"/>
  </front>
</reference>


    </references>

    <references title='Informative References'>





<reference anchor="I-D.richardson-anima-state-for-joinrouter">
<front>
<title>Considerations for stateful vs stateless join router in ANIMA bootstrap</title>

<author initials='M' surname='Richardson' fullname='Michael Richardson'>
    <organization />
</author>

<date month='September' day='22' year='2020' />

<abstract><t>This document explores a number of issues affecting the decision to use a stateful or stateless forwarding mechanism by the join router (aka join assistant) during the bootstrap process for ANIMA.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-richardson-anima-state-for-joinrouter-03' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-richardson-anima-state-for-joinrouter-03.txt' />
</reference>


<reference anchor="pledge" target="http://dictionary.reference.com/browse/pledge">
  <front>
    <title>Dictionary.com Unabridged</title>
    <author initials="." surname="Dictionary.com" fullname="Dictionary.com">
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>




<reference anchor="I-D.ietf-cose-rfc8152bis-algs">
<front>
<title>CBOR Object Signing and Encryption (COSE): Initial Algorithms</title>

<author initials='J' surname='Schaad' fullname='Jim Schaad'>
    <organization />
</author>

<date month='September' day='24' year='2020' />

<abstract><t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size.  There is a need for the ability to have basic security services defined for this data format. THis document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol RFC XXXX.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-cose-rfc8152bis-algs-12' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-cose-rfc8152bis-algs-12.txt' />
</reference>



<reference anchor="I-D.ietf-cose-rfc8152bis-struct">
<front>
<title>CBOR Object Signing and Encryption (COSE): Structures and Process</title>

<author initials='J' surname='Schaad' fullname='Jim Schaad'>
    <organization />
</author>

<date month='September' day='24' year='2020' />

<abstract><t>Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size.  There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol.  This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization.  This specification additionally describes how to represent cryptographic keys using CBOR.  This document along with [I-D.ietf-cose-rfc8152bis-algs] obsoletes RFC8152.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-cose-rfc8152bis-struct-14' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-cose-rfc8152bis-struct-14.txt' />
</reference>



<reference anchor="I-D.ietf-lake-edhoc">
<front>
<title>Ephemeral Diffie-Hellman Over COSE (EDHOC)</title>

<author initials='G' surname='Selander' fullname='Goeran Selander'>
    <organization />
</author>

<author initials='J' surname='Mattsson' fullname='John Mattsson'>
    <organization />
</author>

<author initials='F' surname='Palombini' fullname='Francesca Palombini'>
    <organization />
</author>

<date month='August' day='2' year='2020' />

<abstract><t>This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact, and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys.  EDHOC provides mutual authentication, perfect forward secrecy, and identity protection.  EDHOC is intended for usage in constrained scenarios and a main use case is to establish an OSCORE security context.  By reusing COSE for cryptography, CBOR for encoding, and CoAP for transport, the additional code footprint can be kept very low.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-lake-edhoc-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-lake-edhoc-01.txt' />
</reference>



<reference anchor="I-D.ietf-anima-autonomic-control-plane">
<front>
<title>An Autonomic Control Plane (ACP)</title>

<author initials='T' surname='Eckert' fullname='Toerless Eckert'>
    <organization />
</author>

<author initials='M' surname='Behringer' fullname='Michael Behringer'>
    <organization />
</author>

<author initials='S' surname='Bjarnason' fullname='Steinthor Bjarnason'>
    <organization />
</author>

<date month='September' day='11' year='2020' />

<abstract><t>Autonomic functions need a control plane to communicate, which depends on some addressing and routing.  This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration.  This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions.  It also serves as a "virtual out-of-band channel" for Operations, Administration and Management (OAM) communications over a network that provides automatically configured hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured, or misconfigured.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-anima-autonomic-control-plane-29' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-anima-autonomic-control-plane-29.txt' />
</reference>



<reference anchor="I-D.selander-ace-ake-authz">
<front>
<title>Lightweight Authorization for Authenticated Key Exchange.</title>

<author initials='G' surname='Selander' fullname='Goeran Selander'>
    <organization />
</author>

<author initials='J' surname='Mattsson' fullname='John Mattsson'>
    <organization />
</author>

<author initials='M' surname='Vucinic' fullname='Malisa Vucinic'>
    <organization />
</author>

<author initials='M' surname='Richardson' fullname='Michael Richardson'>
    <organization />
</author>

<author initials='A' surname='Schellenbaum' fullname='Aurelio Schellenbaum'>
    <organization />
</author>

<date month='March' day='9' year='2020' />

<abstract><t>This document describes a procedure for augmenting an authenticated Diffie-Hellman key exchange with third party assisted authorization targeting constrained IoT deployments (RFC 7228).  Note to Readers  Source for this draft and an issue tracker can be found at https://github.com/EricssonResearch/ace-ake-authz (https://github.com/EricssonResearch/ace-ake-authz).</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-selander-ace-ake-authz-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-selander-ace-ake-authz-01.txt' />
</reference>



<reference anchor="I-D.vanderstok-anima-constrained-join-proxy">
<front>
<title>Constrained Join Proxy for Bootstrapping Protocols</title>

<author initials='M' surname='Richardson' fullname='Michael Richardson'>
    <organization />
</author>

<author initials='P' surname='Stok' fullname='Peter van der Stok'>
    <organization />
</author>

<author initials='P' surname='Kampanakis' fullname='Panos Kampanakis'>
    <organization />
</author>

<date month='September' day='22' year='2020' />

<abstract><t>This document defines a protocol to securely assign a pledge to an owner, using an intermediary node between pledge and owner.  This intermediary node is known as a "constrained Join Proxy".  This document extends the work of [I-D.ietf-anima-bootstrapping-keyinfra] by replacing the Circuit- proxy by a stateless constrained (CoAP) Join Proxy.  It transports join traffic from the pledge to the Registrar without requiring per- client state.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-vanderstok-anima-constrained-join-proxy-04' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-vanderstok-anima-constrained-join-proxy-04.txt' />
</reference>



<reference anchor="I-D.friel-anima-brski-cloud">
<front>
<title>BRSKI Cloud Registrar</title>

<author initials='O' surname='Friel' fullname='Owen Friel'>
    <organization />
</author>

<author initials='R' surname='Shekh-Yusef' fullname='Rifaat Shekh-Yusef'>
    <organization />
</author>

<author initials='M' surname='Richardson' fullname='Michael Richardson'>
    <organization />
</author>

<date month='September' day='24' year='2020' />

<abstract><t>This document specifies the behaviour of a BRSKI Cloud Registrar, and how a pledge can interact with a BRSKI Cloud Registrar when bootstrapping.  RFCED REMOVE: It is being actively worked on at https://github.com/ anima-wg/brski-cloud</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-friel-anima-brski-cloud-03' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-friel-anima-brski-cloud-03.txt' />
</reference>



<reference anchor="I-D.ietf-anima-brski-async-enroll">
<front>
<title>Support of asynchronous Enrollment in BRSKI (BRSKI-AE)</title>

<author initials='S' surname='Fries' fullname='Steffen Fries'>
    <organization />
</author>

<author initials='H' surname='Brockhaus' fullname='Hendrik Brockhaus'>
    <organization />
</author>

<author initials='E' surname='Lear' fullname='Eliot Lear'>
    <organization />
</author>

<date month='July' day='10' year='2020' />

<abstract><t>This document describes enhancements of bootstrapping a remote secure key infrastructure (BRSKI) to also operate in domains featuring no or only timely limited connectivity between involved components.  It addresses connectivity to backend services supporting enrollment like a Public Key Infrastructure (PKI) and also to the connectivity between pledge and registrar.  For this it enhances the use of authenticated self-contained objects in BRSKI also for request and distribution of deployment domain specific device certificates.  The defined approach is agnostic regarding the utilized enrollment protocol allowing the application of existing and potentially new certificate management protocols.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-anima-brski-async-enroll-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-anima-brski-async-enroll-00.txt' />
</reference>




    </references>




  </back>

<!-- ##markdown-source:
H4sIAER7fl8AA6VbW3fbRpJ+x6/oozwsNUtQshx7Yp05O0tTtM3YuqxIjyf7
ktMEmmRHIMBBA5IZH//3/aqqGxdKTry7fohIotGXunz1VVUnjuOoslVmztWF
ubeJUdO8LLJsa/JK2VzNpos3alcWVZEUmVNxrMbqttDpVu8ivVyW5v5cpfKi
aV6M0iLJ9RZzpqVeVXFpk40uU1fkcTsoLmWa+PR5FLlK5+mvOityvFSVtYki
uyv5o6vOTk9fnZ5FujT6XM3yypS5qaKH9bkaX80ux+pTUd7ZfK3elkW9i+4e
2kHxBa0fJbo6x2FWRRTt7LnCvx9UonNVO6N0Weq9GtiV0lmm9sYdq6JUG+02
amNKEymFo5/TA3x0RVmVZuXOeYrUrHSdVQ4jwvP9Vh7T10jX1aYozyPF/2L/
V2EnGHE5UreNWJpHIrVLemCypwYUJY49h7BMtsUJ5sWqeoBgWAauGWW22mbn
apuU/25NtfpPF14YJTqK8qLc6sreG9ra7ZvJ2bNnr/zHv57+2Hw8e3HqP754
+eLMf/zp+cuX9HEWX4xo6ljndqvjZVFUrir1bgdFxHdmD2mX+omBSZHTOJub
NL4v6gQyDjM/axbprPfy+Y9/bfb2/LQ3Y1KUJi6Wv5mkip1J6tJW+zDAmYzO
XMY6MRjoTGySdGP6O+JHsEDjqt4DWA72uYp/N2T42GTv6cvKumQTby0dKHu0
cndMWoWn7Vzxb4XNabA1xvx0ehY/G9+KjVS6XBtY6tGmqnbnJyfsFKT/EQ0d
QfUnK5unrkpd8+wEM4wwQ0xOMtpU2+xI5hKfPppNp1Plx6g5bcYER5+l8EK7
sqaUV/rmykYqr8/9WjIs1RUmpuXgo/Cpji3R8Tu+LhrHTisTYxwfHC5aicp3
mUnX5ry32wubVLbIdbkfJcVWfcz1srQY5Zc+FFDaDofbwVvzxNCLJ8uyeHDm
RJZ46nTxgcf1F+6d89mLKIqBe3pJhptUUbTYWKcAcTWDJMDx3qbGKbhjcW/K
e2seVLHqwCEBit3uSgtxA6a2BhLKrds6yE9BIyWN6QPt6HAVfF4aevsBjm5S
VeSEztXGCAbGn94OsQH+fW2rTb1UwLyI5OQgKPmJRSNKeVifPEZiOefWpmkG
/P2BULQs0polQ/uBgBVhTY4tQY+ucxK/Oex/B19LCRFdkd0b3iF+XWZmG0Eo
7A4m22PzMje9pVUOkUkUcfSkIFmaz9aJvHSuYQIYVNHhH4nmWwqgpVO7Yruo
unt1m+KBRbnRVVTh97zIirWlGXA6CGlb5LyKaReBFZdA+gcIEvtNrV6XetvM
REvd69KSUPD+DmEsrxwrBCPo8V6tC0gF5gsxknjIcdQKjtM1FJeYnKYh/f+g
Ju1MfXuCaGtSigui8NvBx0rfmVytSnjPly/fBdJfvw4hCXhthNcfWMkVTUqy
lmObFNv528quobr/iGZX8+nt4tfF9J+LX9/cXl/++mb2YdqeOvabGVWfKzW9
uoj+dhLejN7Qcbf6N/hDV0pYEepLSrs06XkUPRsFbFCkgrxIaUeafUBXldnu
2CwgQxHJKDobkRF83oMQ9IeTuuAmWEhleo9ocAZ97IJxyCrN4I3JSDCj6PkI
ekcEzVVp1pYkRkwEL/wMAFO34beTSVGUqc11hfMMfr6dHMtUDxZEIjWAOYQI
E5nMru3SZggC/YVH0Y8jdTmej2Xy0uxK4yARhtMwFMZfr4A6EGAp04OawAIx
lsKWXmbWbUwaMVHCHJlmw9jYndhqd7kXI/EJOdvN+5nQnnx/TNZ2qVkw08dm
9qfKX9Y2S8mmllmR3P2RBXSNGt9+UGuTG4QM5bkAAAInrmzixP8C6La/B8H4
F4at6RAg/jK+IiCEReHLly+esHz9OuLFOuQjvC/LPJr9iZHDVkOy1uT19e0w
6lmvrPrnlCds6Of59ZWSEPonG1pq10rp0VZonqF6YisHAphcz6cxEa0omuW9
Q7q9g2e5rmjJJ5xd09PaBZSjGVosfWo5zE7LMTBZ5sZLNu4MdCsVo/zy5e8d
EgduVq4Sem9pXayztfv6VQ1y4CZ525tJPL2YLa5v1X8dE6BGf/QyjoNwRa/j
1U9vP0yGPjAhT7E+LpVmiyiBw9eUJNABNXmXO4aISEaBWanmkRpMLufHLLI6
j/9PUiv3O4A/oBdAG10a5xDR1HwPZ/8ssz8hSWLBQXHTi3fXkyi67iuN4gs0
kWUm7wRIN+Q1HVaB8yrgvA+h7NSU9yxNREaHV5b7njIyRI/YpJsi4YX7cVaA
59NbTIEVU/Vh/H7qw+SkGN/E0/lCUJZISAWYpZebU/FKT1Lvr1/liPNFPLke
38zV2cnF4sOcuMKAufMxH7zOu0f/rrNiA54c+PV9QiH2+f/eto+b9ILnYl1r
xVNtOVJB1opP9Gz03AtsPJmSJHVa7MiFq66ghcjtag/tylajRkDvFgsI6Lul
I+528AwB0outPTo51reFeCAOn4vBzWAR2yKlHIIeRd/NONTg9e38/Yxcjj98
lwi7hirTg9MXebG1CTkl+GQWA2Vy09OMDlPMpvO3IGGx3hidPo4HkkeqkK+p
wfV8cn07PW6d7inRfkOwZFgKv+dOJ0LUCJuF/B7a1FNZLCQk4OH2262pKEBC
eE6stvcbNLUngCU+4JB4YfoBCUsSUOWT1OZYx0MkI9Hl+Bd6B+kxmEbAKYYY
kUudYe89oOvUdvq82Cull24TiFC69Tv8TP2DMBZWFZ8+A6Xf2VIQbm5g+Nsl
TO/s9OwUMF2zpWEE5CBALWGjcPSVjpTiRLWYaEh92ItkzzeezJV6tYJomA92
U61o4Z8soUBjZAL/Evkb87vbCU6GPCAvKrXKEIFS7DepkK9o16FSUTOo2u8s
weEe6IigotU6K5b8vTQaayPvgZOnCC+wjJwOQW/ayg/P95G3J6UTJD+O1awG
oOGcJ3ya3gzVp5vxUFL4z6Q9+fhi9COPJRcCpdrWOfZBptY73649H53NUsoG
dlaJEWqRUhurkaJukX5g9xA/5aLkETRPs8k1zAE8EzRcJ3feHg9EfYi6hBE4
qLgHfaMIBFWAO9MyHFSWYIErSAXfO8sNg2KQ3MNJ1OVH4BWsAq+AU2/AtA3/
wXeYibMQ9qibp7Zvcg0iI/l20kCanB+s6qzzuxwKzKJquaZP7eB2myJlUQEf
s72zv3c533eVPnxEJy4GjGDZDZvttdH0kVRrwDNvRnAJg0BfQLDfIV/mdDvM
Ae05ZCQmosHe9prEgyf1WVEDVMKaAE2jaHaA930++43KVyApHON4iSgayzcH
d7bkde1ByJU5zg+fWIrB5J6hBIe4e4JBkyRjXiQsO7uZPSHIcd55cChHHSL+
CoNiTIiBFBbw0yDUYNSrn5DQFZHJE71zNRIrqWZUBzjCSeENr+L9jMVIbMkV
W64nwA0/IwgZZsOWvkpZKA/4oW6u57N/wl11RcSM0v9xxWnrDrODEcA3HvSf
Kuab5UaKiHgDjjfe7Uye2s8jCKhgjNnQJkkpfDgyKVELIbUPk7ZMalt5UQaX
EVvtPxMHUcgake7COQDolhchl9/tsoBRIv01JnrQ+2jgg3VO0FDkLJBnr16d
xqbUrbjkzdL8q8bOJAUuGDJ3SJpgIbnhUMsRjs9C1X0o+Gq8ePmSVUJpL0Vx
rxg+CJ+coFq1U6gAv4vJDU328eIGghDXYKa2BThwqMqdvRd4lZ+QpFGsWGLp
VGKazpxgGg94ACjSgHttM4oNQ6yamvgBuQlXfCiUxKwQ5zYnVeZOarcEzIus
r6aLyfXVm86o1qy1cwjITkoEnOVLkZfAdm0qyR8bMd3DRIYI6kW93rAEqHSG
3R7hP2vYy/qIz94RiSBz1C1H8I579QmpsTIoUgrEtT35iQgVlTqO5ST0UaTZ
r3AQriYY/1T14ySUa6jSEfUqHaGC0ymIKC8Gerso901hq4mJVFCtbcbculv0
uOxQBti+l3lfAWDuLXRJjicEtuOSj3oI4HSBNY360/13GNLRZ1PUpEmoeiLm
zyXehxySwrnb8juFfaYgIeH0hzwiU2EPP+JYq7LCe2BTn2LirkEUP5PQ6Tle
sFSXG1y8m9zc/zhU/PelROPtxdUcLgYsejCYWnspAkMjUZ0bKTVOU8vldBCh
YbvfkCI7n4TCOahNx/UueEVKZTULpzFphNPsirJi/kTRjNJlRxLCgh/nr4n6
QIgfd4wI8F4pI9/rzKbMbjqOZMp7qpi0Qm4521Fp8AwB4SjyRZ9g7iJ+mrUF
sPn8HaEBhbXOyL9UxV961FD8jjcrdhly7kaVZJ3IXEhxvA+cpN0dDJsCRU1H
82sXABpaGXvdE8bsA1mESj1VOvBsaqSu2wKg9uVHjN+CnHtvZ0d/7OcsitBA
FTAtAnkQUidGcmCYa7Hr9iBUB6H4qLkwX+9EMfc+HYCtLW7jl6/IbgmNhxQf
ygIM1INy1J8f44H6lltWWJyDCQzOOJ/pce0L78dkaEI8Z/MbR9mOhDmyA1KM
P0XJ0iMLIYNdeABhSo+jFjlxYO42VZwgGYmEnKz6DF5az4dI4NPZJ8qA38qF
owNUaCbmVKFT9W/VabckjwSWX4nhS2ZJtSAoMuOR8GkuISS0lOK1Gp6nBjdI
vttKts8rfXoaZsHBal8zQ4jlfkUHJ6nTEhqKC8p0yV/VYDpfDEOz9ljmxTYz
JN46C4jfOVO39eM1STyHOkbwfcpsYUGNXndMfLAfltG/OTUOBQCmw5gVGZ3O
JQtgjcKsVpUpu5hIxGwphunrdFolpqROaEK212HHg6bAcOyr5sNubB3khSJH
I3jwsx9L9R+Dcunw9DUDUG3RR9Lu2fvp/RnJmNSkibTilTAeEryWohQHRBwp
KEcrSid8z0346uD25sMxybis86bDxGny01JSg/HkxusIn7x2clE6p2WdKlDI
ANkIRVFYokE0n7YFVXbrOt0szOyY1OIwmrqIS6Hg9LsvnNRZBV+BFthe8Kyp
41BBoDwIb2wLld8+7/ipLYAUZ6s2r/cA4GnP3qf4ih1yHYhHOO6Ak+1nlIif
cB7ezb+bokqTB9/bAG46tFm6pqUroZrco0JQGFJ30HB4WprG2dJCVH1nKdiv
/M7OGRQp+ybYC5t41RIFOo+nvO+QzlCw7tlWs+1QwRJIY9+1geNNOjWf1wGw
AvdNpSFbC8HiHmMDdyHUcXrFqd8AyL2RplVOQfNYytWdBQbUQTluWMHo28v4
ahYFF7WQ6OKX5PUml3NOgeHOqrsqNSv6BVeuYfui6x/UdYm5V74oQjYDhK0p
6bMtTPc6RG1Qa8w+9PXblI1wTQMjMeq7e0SLNo/h/TTdakTNjDBIeqLUIqNM
BEKYFQusucuK/Za7qy3xDQ12buEXlBIguJVEtB4M1w25qBKqrcHShmp8OZMs
KYOflJzLU+MEVj/LhefAfmph48PAFIifgAySntjkPWRy2YtzA3KJnCprW4IG
xPaiLhOqn5KV4C0SlU2Qdpfg8KWMomRJuR201aZQo66M2PDIEgR1uylnSNsH
h2l0KCSGMOwYQ3WGsJXu/W0A2ZWj5lF3pSZRZp7Klqplk5y20zi6jAA9vgt+
3gWXROMoxMuIKlUUNzK7tWSaWIl4GS1KPsIqkxFIh4kXkxkuOlNRFZhTTSqE
E+wgjy+B3Nm+Z6jBBAbAFuPZZ6N/qak5IDzMT/Akb8zg2DcQs6JOYySTGN/Q
BxegFnZn8tSTV+15ItUffHmAwE3QtgPi3jI8kjcJigfiDke5KiohZgzl7A6+
GiBQoLtLLc0TyTYXmX1O/ihh5jSFVU/KxHZAu0tG7e4mQvtxVVqTBWZXujsb
JyQaSvJAd3x3ALphy0wgLyc3Gxp3LMV327lle6AU7SkolcIZRWZsxJuSU3bd
z7uhqX+Mb8OGU39tAQ/YDF2Xs3AW2Kwp4pbrRF3aj3OePdortta+ONib6jgA
ZWuHsoVQ5/ZF7sAHud8k+RhzbgiGZNbesuhc5WnaqSE36Ud+by3dnKEzecPV
f1Fjt0daWoL/1K5DXw8tlibrWQ/z6mA5ASYa43waVNlXqDUqcCE1NV21xs+G
R3mvt7CkKdw3J+pI2Ne090K1u+ohZ5zlPQ5l8nuLUzKADZtUmeiQ+L/c4hr2
3gl7z40QD7qhFAyMLs0sC12mnmIm3MHw6m7soZt1diAZ+UXYOwUaIF+uPiym
J8+R1NR8VIQQQMMDpIVZM53csb8TEOG7qZLRsQ9+j5t+4m2a9OpvE8Pp/MUz
xy6nIYVUoh+WYkWL83WqgpPLmx5VIOvhINeYSOghGgLlHCpy3tJFWHcGZBYY
R2H3oCQQKsOd7ksXQeBZmptZpFck61ytx+FS6hQ80M2DfrF8W3BZJzgEYZ5x
/nZZU1Hpdn1aG6Ih0uOi+m+S1ankiwj9vWqT4KfdOrkgkdaJWLfe0i0J5uE6
uxMfpJF5Y+vYHocNdnUmr+J9jxibqNP//K0CWvS/qmkf1tP85AFx2fKtb+Nw
7eSpUMhATU+jpxrowKlJSzo8DDQ3FR1Mt1wHEwq1/CRDbInOWnDsYkSb/h3S
L9LVAzgv85cM1hX1eFKfDDIrIOMIBjCUmzmBBXcupIBbQDeuy7qapuMSiyJM
0p1G5ubhpDj26wK/8hUnmZkG+NZT7xxRYEpW7tOHTkKXe7l6R6zFg7721UG+
bUZNZ99tJOSPdNvdbgomNNAvLc2U4IuuBlviUkj3To43l6h7mbZjkoct8e8y
zO/qgnXskTuqnWtSB6Uc6sUoSv8zE/z5BBQYtMlRUZ+vB4n9tP2OSmVGO+kK
HbEbcE237fw/uixwcLCVyaqW7rRhAIhPbdbS7hpCFfJQVk/ThlXU7zy4f9d5
he7sEtI7btmUTWFiFI1de5vXSw/2Y7rZDOU2jWtI/hJuiwVj5dZ4qDaTPPp3
I+3WKC7JHDX1oqNjfz2IOW0g6NT3gYw60worupm/l6JATWUQYse2orsGToAk
9V5KQFpKR4rpOAzXeBAag6BLtTF0iuVCcfM2IVhQHnPJ7zCq77kaw3dI2iY3
MxRfN2kYTkH2429ky6UJddHcqKCGbSi5VIcXz1v3lMYZUvOUixDYl+OsUG5T
0x3ijpHjnZUVohOAQau1ZRPx95y9o7hAb0vfI+0t551bzIcoE0f2bsBr+/Nt
Ez8avP644MZpU/kBZQ3FldGI77xe30yv1Gw+/zhlfoCg1qT5nVOuepzHehLW
ifgS1Bn3jesyq5Yn9myVa4Q5JYQNRX43vzy5eT8b4cjS7aUhnO0QXyQxr2Jf
rpTex/MRXy3nw2lG2Gwf4/jQiZTthPj8nY45D5eaJt4Ude/2eKNqZgg8H+Sd
mmK1Ct7eXIuiYgP3aJo7Bc0V+xZwm3RZqr0VpWjNKj5DdZ05U1+w+0HNxlfj
P9llo87UrAD4XMMjnnuwelt2DC9E4c7NU6vw6uPkLi8emC9t5Yby4vWF/F8R
S3DUKPofcVwPNS43AAA=

-->

</rfc>