<?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.2.8 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
<!ENTITY RFC7228 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml">
<!ENTITY RFC7049 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7049.xml">
<!ENTITY RFC7252 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml">
<!ENTITY RFC7959 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7959.xml">
<!ENTITY RFC7967 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7967.xml">
<!ENTITY RFC8152 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8152.xml">
<!ENTITY RFC8613 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8613.xml">
<!ENTITY RFC8376 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8376.xml">
<!ENTITY I-D.ietf-6tisch-minimal-security SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6tisch-minimal-security.xml">
<!ENTITY I-D.ietf-lpwan-coap-static-context-hc SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lpwan-coap-static-context-hc.xml">
<!ENTITY I-D.ietf-cose-x509 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-cose-x509.xml">
<!ENTITY I-D.ietf-core-echo-request-tag SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-echo-request-tag.xml">
<!ENTITY I-D.irtf-cfrg-randomness-improvements SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.irtf-cfrg-randomness-improvements.xml">
<!ENTITY I-D.selander-ace-ake-authz SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.selander-ace-ake-authz.xml">
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocdepth="2"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lake-reqs-04" category="info" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 2.22.3 -->
  <front>
    <title abbrev="Reqs-LAKE-for-OSCORE">Requirements for a Lightweight AKE for OSCORE</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-lake-reqs-04"/>
    <author initials="M." surname="Vucinic" fullname="Malisa Vucinic">
      <organization>Inria</organization>
      <address>
        <email>malisa.vucinic@inria.fr</email>
      </address>
    </author>
    <author initials="G." surname="Selander" fullname="Goeran Selander">
      <organization>Ericsson AB</organization>
      <address>
        <email>goran.selander@ericsson.com</email>
      </address>
    </author>
    <author initials="J." surname="Mattsson" fullname="John Preuss Mattsson">
      <organization>Ericsson AB</organization>
      <address>
        <email>john.mattsson@ericsson.com</email>
      </address>
    </author>
    <author initials="D." surname="Garcia" fullname="Dan Garcia-Carrillo">
      <organization>Odin Solutions S.L.</organization>
      <address>
        <email>dgarcia@odins.es</email>
      </address>
    </author>
    <date year="2020" month="June" day="08"/>
    <abstract>
      <t>This document compiles the requirements for a lightweight authenticated key exchange protocol for OSCORE. 
This draft has completed a working group last call (WGLC) in the LAKE working group.
Post-WGLC, the requirements are considered sufficiently stable for the working group to proceed with its work. 
It is not currently planned to publish this draft as an RFC.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>OSCORE <xref target="RFC8613" format="default"/> is a lightweight communication security protocol providing end-to-end security on application layer for constrained IoT settings (cf. <xref target="RFC7228" format="default"/>). OSCORE lacks a matching authenticated key exchange protocol (AKE). The intention with the LAKE WG <xref target="LAKE-WG" format="default"/> is to create a simple yet secure AKE for implementation in embedded devices supporting OSCORE.</t>
      <t>To ensure that the AKE is efficient for the expected applications of OSCORE, we list the relevant public specifications of technologies where OSCORE is included:</t>
      <ul spacing="normal">
        <li>The IETF 6TiSCH WG charter identifies the need to "secur[e] the join process and mak[e] that fit within the constraints of high latency, low throughput and small frame sizes that characterize IEEE802.15.4 TSCH". OSCORE protects the join protocol as described in 6TiSCH Minimal Security <xref target="I-D.ietf-6tisch-minimal-security" format="default"/>.</li>
        <li>The IETF LPWAN WG charter identifies the need to improve the transport capabilities of LPWA networks such as NB-IoT and LoRa whose "common traits include ... frame sizes ... [on] the order of tens of bytes transmitted a few times per day at ultra-low speeds". The application of OSCORE is described in <xref target="I-D.ietf-lpwan-coap-static-context-hc" format="default"/>.</li>
        <li>OMA Specworks LwM2M version 1.1 <xref target="LwM2M" format="default"/> defines bindings to two challenging radio technologies where OSCORE is planned to be deployed: LoRaWAN and NB-IoT.</li>
        <li>Open Connectivity Foundation (OCF) plans to use OSCORE for end-to-end security of unicast messages <xref target="OCF" format="default"/>.</li>
      </ul>
      <t>This document compiles the requirements for the AKE for OSCORE.
It summarizes the security requirements that are expected from such an AKE, as well as the main characteristics of the environments where the solution is envisioned to be deployed.
The solution will presumably be useful in other scenarios as well since a low security overhead improves the overall performance.</t>
    </section>
    <section anchor="prob-desc" numbered="true" toc="default">
      <name>Problem description</name>
      <section anchor="AKE-OSCORE" numbered="true" toc="default">
        <name>AKE for OSCORE</name>
        <t>The rationale for designing this protocol is that OSCORE is lacking a matching AKE. OSCORE was designed for lightweight RESTful operations for example by minimizing the overhead, and applying the protection to the application layer, thereby limiting the data being encrypted and integrity protected for the other endpoint. Moreover, OSCORE was tailored for use with lightweight primitives that are likely to be implemented in the device, specifically CoAP <xref target="RFC7252" format="default"/>, CBOR <xref target="RFC7049" format="default"/> and COSE <xref target="RFC8152" format="default"/>. The same properties should apply to the AKE.</t>
        <t>In order to be suitable for OSCORE, at the end of the AKE protocol run the two parties must agree on (see Section 3.2 of <xref target="RFC8613" format="default"/>):</t>
        <ul spacing="normal">
          <li>A shared secret (OSCORE Master Secret) with Perfect Forward Secrecy (PFS, see <xref target="confidentiality" format="default"/>) and a good amount of randomness. (The term "good amount of randomness" is borrowed from <xref target="HKDF" format="default"/> to signify not necessarily uniformly distributed randomness.)</li>
          <li>
            <t>OSCORE Sender IDs of peer endpoints, arbitrarily short.
            </t>
            <ul spacing="normal">
              <li>Sender IDs are expected to be unique for a given Master Secret, more precisely the quartet (Master Secret, Master Salt, ID Context, Sender ID) must be unique, see Section 3.3. of <xref target="RFC8613" format="default"/>.</li>
            </ul>
          </li>
          <li>COSE algorithms to use with OSCORE</li>
        </ul>
        <t>COSE provides the crypto primitives for OSCORE. The AKE shall specify how it provides COSE algorithms to OSCORE. It is strongly recommended that COSE is reused by the AKE, for identification of credentials and algorithms, as extension point for new schemes, and to avoid duplicated implementation of crypto wrapper.</t>
        <t>The AKE cannot rely on messages being exchanged in both directions after the AKE has completed, because CoAP/OSCORE requests may not have a response <xref target="RFC7967" format="default"/>. Furthermore, there is no assumption of dependence between CoAP client/server and AKE initiator/responder roles, and an OSCORE context may be used with CoAP client and server roles interchanged as is done, for example, in <xref target="LwM2M" format="default"/>.</t>
        <t>Moreover, the AKE must support transport over CoAP.
When transported over CoAP, the AKE must support the traversal of CoAP intermediaries, as required by the 6TiSCH network formation setting <xref target="I-D.ietf-6tisch-minimal-security" format="default"/>.</t>
        <t>Since the AKE messages most commonly will be encapsulated in CoAP, the AKE must not duplicate functionality provided by CoAP, or at least not duplicate functionality in such a way that it adds non-negligible extra costs in terms of code size, code maintenance, etc. It is therefore assumed that the AKE is being transported in a protocol that provides reliable transport, that can preserve packet ordering and handle message duplication <xref target="RFC7252" format="default"/>, that can perform fragmentation <xref target="RFC7959" format="default"/> and protect against denial of service attacks as provided by the CoAP Echo option <xref target="I-D.ietf-core-echo-request-tag" format="default"/>.</t>
        <t>The AKE may use other transport than CoAP. In this case the underlying layers must correspondingly handle message loss, reordering, message duplication, fragmentation, and denial of service protection.</t>
      </section>
      <section anchor="cred" numbered="true" toc="default">
        <name>Credentials</name>
        <t>IoT deployments differ from one another in terms of what credentials can be supported. Currently many systems use pre-shared keys (PSKs) provisioned out of band, for various reasons. PSKs are sometimes used in a first deployment because of their perceived simplicity. The use of PSKs allows for protection of communication without major additional security processing, and also enables the use of symmetric crypto algorithms only, reducing the implementation and computational effort in the endpoints.</t>
        <t>However, PSK-based provisioning has inherent weaknesses. There has been reports of massive breaches of PSK provisioning systems <xref target="massive-breach" format="default"/>, and as many systems use PSKs without Perfect Forward Secrecy (PFS, see <xref target="confidentiality" format="default"/>) they are vulnerable to passive pervasive monitoring. The security of these systems can be improved by adding PFS through an AKE authenticated by the provisioned PSK.</t>
        <t>Shared keys can alternatively be established in the endpoints using an AKE protocol authenticated with asymmetric public keys instead of symmetric secret keys. Raw public keys (RPK) can be provisioned with the same scheme as PSKs, which allows for a more relaxed trust model since RPKs need not be secret. The corresponding private keys are assumed to be provisioned to the party being authenticated beforehand (e.g. in factory or generated on-board).</t>
        <t>As a third option, by using a public key infrastructure and running an asymmetric key AKE with public key certificates instead of RPKs, key provisioning can be omitted, leading to a more automated ("zero-touch") bootstrapping procedure. The root CA keys are assumed to be provisioned beforehand.
Public key certificates are important for several IoT settings, e.g., facility management with a large number of devices from many different manufacturers.</t>
        <t>These steps provide an example of a migration path in limited scoped steps from simple to more robust security bootstrapping and provisioning schemes where each step improves the overall security and/or simplicity of deployment of the IoT system, although not all steps are necessarily feasible for the most constrained settings.</t>
        <t>In order to allow for these different schemes, the AKE must support PSK- (shared between two nodes), RPK- and certificate-based authentication.
These are also the schemes for which CoAP is designed (see Section 9 of <xref target="RFC7252" format="default"/>).</t>
        <t>Multiple public key authentication credential types may need to be supported for RPK and certificate-based authentication. In case of a Diffie-Hellman key exchange both the use of signature based public keys (for compatibility with existing ecosystem) and static DH public keys (for reduced message size) is expected.</t>
        <t>To further minimize the bandwidth consumption it is required to support transporting certificates and raw public keys by reference rather than by value. Considering the wide variety of deployments, the AKE must support different schemes for transporting and identifying credentials. While there are many existing mechanisms for doing so, ranging from PSK to raw public key by reference to x5chain of in-band certificates <xref target="I-D.ietf-cose-x509" format="default"/>, what is appropriate for a given deployment will depend on the nature of that deployment. In order to provide a clear initial effort, <xref target="initial-focus" format="default"/> lists a set of credential types of immediate relevance; the mechanism for  selecting credential scheme is presumed to enable future extensibility if needed.</t>
        <t>The use of RPKs may be appropriate for the authentication of the AKE initiator but not for the AKE responder.
The AKE must support different credentials for authentication in different directions of the AKE run, e.g. certificate-based authentication for the initiating endpoint and RPK-based authentication for the responding endpoint.</t>
        <t>Assuming that both signature public keys and static DH public keys are in use, then also the case of mixed credentials need to be supported with one endpoint using a static DH public key and the other using a signature public key. The AKE shall support negotiation of public key credential mix and that both initiator and responder can verify the variant that was executed.</t>
        <section anchor="initial-focus" numbered="true" toc="default">
          <name>Initial Focus</name>
          <t>As illustrated above, the setting is much more diverse in terms of credentials and trust anchors than that of the unconstrained web. In order to deliver a timely result, there is a need to initially focus on what is considered most important at the time of writing: RPK (by reference and value) and certificate by reference. Information about validity of a certificate may be omitted from the AKE if available over unconstrained links. The case of transporting certificate validation information over the AKE may be specified in the initial phase if there is a lightweight solution that matches existing standards and tools.</t>
          <t>A subsequent extension beyond the initial focus may be inevitable to maintain a homogenous deployment without having to implement a mix of AKE protocols, for example, to support the migration path described above. The AKE needs to make clear the scope of cases analysed in the initial phase, and that a new analysis is required for additional cases.</t>
          <t>The initial scope as described in this subsection does not cover all credentials as detailed previously in <xref target="cred" format="default"/>: an AKE which is extensible but does not include PSK ECDHE would be conformant with the requirements for the initial scope. A solution to the requirements for the initial scope is intended to be a deliverable of the LAKE WG.</t>
        </section>
      </section>
      <section anchor="mutual-auth" numbered="true" toc="default">
        <name>Mutual Authentication</name>
        <t>The AKE must provide mutual authentication during the protocol run. At the end of the AKE protocol, each endpoint shall have freshly authenticated the other's credential. In particular, both endpoints must agree on a fresh session identifier, and the roles and credentials of both endpoints.</t>
        <t>Since the protocol may be initiated by different endpoints, it shall not be necessary to determine beforehand which endpoint takes the role of initiator of the AKE.</t>
        <t>The mutual authentication guarantees of the AKE shall at least guarantee the following properties:</t>
        <ul spacing="normal">
          <li>The AKE shall provide Key Compromise Impersonation (KCI) resistance <xref target="KCI" format="default"/>.</li>
          <li>The AKE shall protect against identity misbinding attacks <xref target="Misbinding" format="default"/>. Note that the identity may be directly related to a public key such as for example the public key itself, a hash of the public key, or data unrelated to a key.</li>
          <li>The AKE shall protect against reflection attacks, but need not protect against attacks when more than two parties legitimately share keys (cf. the Selfie attack on TLS 1.3 <xref target="Selfie" format="default"/>) as that setting is out of scope.</li>
        </ul>
        <t>Replayed messages shall not affect the security of an AKE session.</t>
        <t>As often is the case, it is expected that an AKE fulfilling these goals would have at least three flights of messages (with each flight potentially consisting of one or more messages, depending on the AKE design and the mapping to OSCORE).</t>
      </section>
      <section anchor="confidentiality" numbered="true" toc="default">
        <name>Confidentiality</name>
        <t>The shared secret established by the AKE must be known only to the two authenticated endpoints.</t>
        <t>A passive network attacker should never learn any session keys, even if it knows both endpoints' long-term keys.</t>
        <t>An active attacker who has compromised the initiator or responder credential shall still not be able to compute past session keys (Perfect Forward Secrecy, PFS). These properties can be achieved, e.g., with an ephemeral Diffie-Hellman key exchange.</t>
        <t>PFS may also be achieved in other ways, for example, using hash-based ratcheting or with a nonce exchange followed by appropriately derived new session keys provided that state can be kept in the form of a session counter. Note that OSCORE specifies a method for session key update involving a nonce exchange (see Appendix B in <xref target="RFC8613" format="default"/>).</t>
        <t>The AKE shall provide a mechanism to use the output of one handshake to optimize future handshakes, e.g., by generating keying material which can be used to authenticate a future handshake, thus avoiding the need for public key authentication in that handshake.</t>
        <t>The AKE should give recommendations for frequency of re-keying potentially dependent on the amount of data.</t>
        <t>To mitigate against bad random number generators the AKE shall provide recommendations for randomness, for example to use <xref target="I-D.irtf-cfrg-randomness-improvements" format="default"/>.</t>
      </section>
      <section anchor="crypto-agility" numbered="true" toc="default">
        <name>Cryptographic Agility and Negotiation Integrity</name>
        <t>Motivated by long deployment lifetimes, the AKE is required to support cryptographic agility, including the modularity of COSE crypto algorithms and negotiation of preferred crypto algorithms for OSCORE and the AKE.</t>
        <ul spacing="normal">
          <li>The protocol shall support both pre-shared key and asymmetric key authentication. PAKE, post-quantum and "hybrid" (simultaneously more than one) key exchange is out of scope, but may be supported in a later version.</li>
          <li>The protocol shall allow negotiation of elliptic curves for Diffie-Hellman operations and signature-based authentication.</li>
          <li>The AKE shall support negotiation of all COSE algorithms <xref target="IANA-COSE-Algorithms" format="default"/> to be used in OSCORE. The AKE shall support negotiation of algorithms used in the AKE. It is strongly recommended that the AKE algorithms are identified using <xref target="IANA-COSE-Algorithms" format="default"/> to reduce unnecessary complexity of a combined OSCORE/AKE implementation.</li>
          <li>A successful negotiation shall result in the most preferred algorithms of one of the parties which are supported by the other.</li>
          <li>The AKE may choose different sets of symmetric crypto algorithms (AEAD, MAC, etc.) for AKE and for OSCORE. In particular, the length of the MAC for the AKE may be required to be larger than for OSCORE.</li>
        </ul>
        <t>The AKE negotiation must provide strong integrity guarantees against active attackers. At the end of the AKE protocol, both endpoints must agree on both the crypto algorithms that were proposed and those that were chosen. In particular, the protocol must protect against downgrade attacks.</t>
      </section>
      <section anchor="cryptographic-strength" numbered="true" toc="default">
        <name>Cryptographic Strength</name>
        <t>The AKE shall establish a key with a target security level
<xref target="keylength" format="default"/> of &gt;= 127 bits.  This level was chosen to include
X25519 and applies to the strength of authentication, the established
keys, and the protection for the negotiation of all cryptographic
parameters.</t>
      </section>
      <section anchor="identity-protection" numbered="true" toc="default">
        <name>Identity Protection</name>
        <t>In general, it is necessary to transport identities as part of the AKE run in order to provide authentication of an entity not identified beforehand. In the case of constrained devices, the identity may contain sensitive information on the manufacturer of the device, the batch, default firmware version, etc. Protecting identifying information from passive and active attacks is important from a privacy point of view, but needs to be balanced with the other requirements, including security and lightweightness.</t>
        <t>In the case of public key identities, the AKE is required to protect the identity of one of the peers against active attackers and the identity of the other peer against passive attackers. SIGMA-I and SIGMA-R differ in this respect. SIGMA-I protects the identity of the initiator against active attackers and the identity of the responder against passive attackers. For SIGMA-R, the properties of the roles are reversed at the cost of an additional flight.</t>
        <t>It is not required to protect the PSK identifier, and it may thus be sent in the first flight. Protection of PSK identifier in many cases require extra flights of the AKE.</t>
        <t>Other identifying information may also need to be transported in plain text, for example, identifiers to allow correlation between AKE messages, and cipher suites. Mechanisms to encrypt these kind of parameters, such as using pre-configured public keys typically adds to message overhead.</t>
      </section>
      <section anchor="auxiliary-data" numbered="true" toc="default">
        <name>Auxiliary Data</name>
        <t>In order to reduce round trips and the number of flights, and in some cases also streamline processing, certain security features may be integrated into the AKE by transporting "auxiliary data" together with the AKE messages.</t>
        <t>One example is the transport of third-party authorization information from initiator to responder or vice versa. Such a scheme could enable the party receiving the authorization information to make a decision about whether the party being authenticated is also authorized before the protocol is completed, and if not then discontinue the protocol before it is complete, thereby saving time, message processing and data transmission.</t>
        <t>Another, orthogonal, example is the embedding of a certificate enrolment request or a newly issued certificate in the AKE.</t>
        <t>For example, the auxiliary data in the first two messages of the AKE may transport authorization related information as in <xref target="I-D.selander-ace-ake-authz" format="default"/> followed by a Certificate Signing Request (CSR) in the auxiliary data of the third message.</t>
        <t>The AKE must support the transport of such auxiliary data together with the protocol messages.
The auxiliary data field must not contain data that violates the AKE security properties.
The auxiliary data field must only be used with security analysed protocols.</t>
        <t>The auxiliary data may contain privacy sensitive information. 
The auxiliary data must be protected to the same level as AKE data in the same flight. For example, for a SIGMA-I AKE it is expected that the 3 flights will provide the following protection of the auxiliary data:</t>
        <ul spacing="normal">
          <li>Auxiliary data in the first flight is unprotected</li>
          <li>Auxiliary data in the second flight is confidentiality protected against passive attackers and integrity protected against active attackers</li>
          <li>Auxiliary data in the third flight is confidentiality and integrity protected against active attackers</li>
        </ul>
      </section>
      <section anchor="extensibility" numbered="true" toc="default">
        <name>Extensibility</name>
        <t>It is desirable that the AKE supports some kind of extensibility, in particular, the ability to later include new AKE modes such as PAKE support. COSE provides an extension mechanism for new algorithms, new certificate formats, ways to identify credentials, etc.</t>
        <t>The main objective with this work is to create a simple yet secure AKE.
The AKE should avoid having multiple ways to express the same thing.
If the underlying encodings offered by CBOR offer multiple possibility the
AKE should be strongly opinionated, and clearly specify which one will be used.</t>
        <t>While remaining extensible, the AKE should avoid optional mechanisms which
introduce code paths that are less well tested.</t>
        <t>The AKE should avoid mechanisms where an initiator takes a guess at the policy, and
when it receives a negative response, must guess, based upon what it has
tried, what to do next.</t>
      </section>
      <section anchor="availability" numbered="true" toc="default">
        <name>Availability</name>
        <t>Jamming attacks, cutting cables etc. leading to long term loss of availability may not be possible to mitigate, but an attacker temporarily injecting messages or disturbing the communication shall not have a similar impact.</t>
      </section>
      <section anchor="lw" numbered="true" toc="default">
        <name>Lightweight</name>
        <t>We target an AKE which is efficiently deployable in 6TiSCH multi-hop networks, LoRaWAN networks and NB-IoT networks. (For an overview of low-power wide area networks, see e.g. <xref target="RFC8376" format="default"/>.) The desire is to optimize the AKE to be 'as lightweight as reasonably achievable' in these environments, where 'lightweight' refers to:</t>
        <ul spacing="normal">
          <li>resource consumption, measured by bytes on the wire, wall-clock time and number of round trips to complete, or power consumption</li>
          <li>the amount of new code required on end systems which already have an
OSCORE stack</li>
        </ul>
        <t>These properties need to be considered in the context of the use of an existing CoAP/OSCORE stack in the targeted networks and technologies. Some properties are difficult to evaluate for a given protocol, for example, because they depend on the radio conditions or other simultaneous network traffic.  Additionally, these properties are not independent. Therefore the properties listed here should be taken as input for identifying plausible protocol metrics that can be more easily measured and compared between protocols.</t>
        <t>Per 'bytes on the wire', it is desirable for the AKE messages to fit into the MTU size of these protocols; and if not possible, within as few frames as possible, since using multiple MTUs can have significant costs in terms of time and power. Note that the MTU size depends on radio technology and its characteristics, including data rates, number of hops, etc. Example benchmarks are given further down in this section.</t>
        <t>Per 'time', it is desirable for the AKE message exchange(s) to complete in a reasonable amount of time, both for a single uncongested exchange and when multiple exchanges are running in an interleaved fashion, like e.g. in a "network formation" setting when multiple devices connect for the first time. This latency may not be a linear function depending on congestion and the specific radio technology used. As these are relatively low data rate networks, the latency contribution due to computation is in general not expected to be dominant.</t>
        <t>Per 'round-trips', it is desirable that the number of completed request/response message exchanges required before the initiating endpoint can start sending protected traffic data is as small as possible, since this reduces completion time. See <xref target="disc" format="default"/> for a discussion about the trade-off between message size and number of flights.</t>
        <t>Per 'power', it is desirable for the transmission of AKE messages and crypto to draw as little power as possible. The best mechanism for doing so differs across radio technologies.  For example, NB-IoT uses licensed spectrum and thus can transmit at higher power to improve coverage, making the transmitted byte count relatively more important than for other radio technologies.  In other cases, the radio transmitter will be active for a full MTU frame regardless of how much of the frame is occupied by message content, which makes the byte count less sensitive for the power consumption as long as it fits into the MTU frame. The power consumption thus increases with AKE message size and the largest impact is on average under poor network conditions. Note that listening for messages to receive can in many cases be a large contribution to the power consumption, for which there are separate techniques to handle, e.g., time slots, discontinuous reception, etc. but this is not considered in scope of the AKE design.</t>
        <t>Per 'new code', it is desirable to introduce as little new code as possible onto OSCORE-enabled devices to support this new AKE. These devices have on the order of 10s of kB of memory and 100 kB of storage on which an embedded OS; a COAP stack; CORE and AKE libraries; and target applications would run. It is expected that the majority of this space is available for actual application logic, as opposed to the support libraries. In a typical OSCORE implementation COSE encrypt and signature structures will be available, as will support for COSE algorithms relevant for IoT enabling the same algorithms as is used for OSCORE (e.g. COSE algorithm no. 10 = CCM* used by 6TiSCH). The use of those, or CBOR or CoAP, would not add to the footprint.</t>
        <t>While the large variety of settings and capabilities of the devices and networks makes it challenging to produce exact values of some these dimensions, there are some key benchmarks that are tractable for security protocol engineering and which have a significant impact.</t>
        <section anchor="lorawan" numbered="true" toc="default">
          <name>LoRaWAN</name>
          <t>Reflecting deployment reality as of now, we focus on the European regulation as described in ETSI EN 300 220. LoRaWAN employs unlicensed radio frequency bands in the 868 MHz ISM band. For LoRaWAN the most relevant metric is the Time-on-Air, which determines the period before the next communication can occur and also which can be used as an indicator to calculate energy consumption. LoRaWAN is legally required to use a duty cycle with values such as 0.1%, 1% and 10% depending on the sub-band that is being used, leading to a payload split into fragments interleaved with unavailable times. For Europe, the duty cycle is 1% (or smaller). Although there are exceptions from the use of duty cycle, the use of an AKE for providing end-to-end security on application layer needs to comply with the duty cycle.</t>
          <section anchor="bytes-on-the-wire" numbered="true" toc="default">
            <name>Bytes on the wire</name>
            <t>LoRaWAN has a variable MTU depending on the Spreading Factor (SF). The higher the spreading factor, the higher distances can be achieved and/or better reception. If the coverage and distance allows it, with SF7 - corresponding to higher data rates - the maximum payload is 222 bytes. For a SF12 - and low data rates - the maximum payload is 51 bytes on data link layer.</t>
            <t>The size and number of packets impact the Time-on-Air (ToA). The benchmark used here is based on SF12 and a packet size of 51 bytes <xref target="LoRaWAN" format="default"/>. The use of larger packets depend on good radio conditions which are not always present. Some libraries/providers only support 51-bytes packet size.</t>
          </section>
          <section anchor="lorawan-time" numbered="true" toc="default">
            <name>Time</name>
            <t>The time it takes to send a message over the air in LoRaWAN can be calculated as a function of the different parameters of the communication. These are the Spreading Factor (SF), the message size, the channel, bandwidth, coding rate, etc. An important feature of LoRaWAN is the duty cycle limitation due to the use of the ISM band. 
The duty cycle is evaluated in a 1-hour sliding window. It is legal for a device to transmit a burst for a total of up to 36 seconds ToA on a 1%-duty-cyle sub-band, but the device must then pause the transmission for the rest of the hour <xref target="lorawan-duty-cycle" format="default"/>.
In order to avoid extreme waiting times, the AKE needs to complete before the duty cycle limit is exhausted, also taking into account potential retransmissions and allowing additional air time for lower level MAC frames and application data. As a challenging but realistic example we assume each message is retransmitted 2 times and allow a factor 2-3 for additional air time. With these assumptions it is required with a ToA of 4-6 seconds for the uplink protocol messages to ensure that the entire burst stays within the 36 seconds duty cycle.</t>
            <t>It should be noted that some libraries/providers enforce the duty cycle limitation through a stop-and-wait operation, which restricts the number of bytes to the size of the packets after which duty cycle waiting times are incurred.</t>
          </section>
          <section anchor="round-trips-and-number-of-flights" numbered="true" toc="default">
            <name>Round trips and number of flights</name>
            <t>Considering the duty cycle of LoRaWAN and associated unavailable times, the round trips and number of LoRaWAN packets needs to be reduced as much as possible.</t>
          </section>
          <section anchor="power" numbered="true" toc="default">
            <name>Power</name>
            <t>The calculation of the power consumption in LoRaWAN is dependent on several factors, such as the spreading factor used and the length of the messages sent, both having a clear dependency with the time it takes to transmit the messages. The communication model (inherent to the different LoRaWAN classes of devices) also has an impact on the energy consumption, but overall the Time-on-Air is an important indication of the performance.</t>
          </section>
        </section>
        <section anchor="tisch" numbered="true" toc="default">
          <name>6TiSCH</name>
          <t>6TiSCH operates in the 2.4 GHz unlicensed frequency band and uses hybrid Time Division/Frequency Division multiple access (TDMA/FDMA).
Nodes in a 6TiSCH network form a mesh.
The basic unit of communication, a cell, is uniquely defined by its time and frequency offset in the communication schedule matrix.
Cells can be assigned for communication to a pair of nodes in the mesh and so be collision-free, or shared by multiple nodes, for example during network formation.
In case of shared cells, some collision-resolution scheme such as slotted-Aloha is employed.
Nodes exchange frames which are at most 127-bytes long, including the link-layer headers.
To preserve energy, the schedule is typically computed in such a way that nodes switch on their radio below 1% of the time ("radio duty cycle").
A 6TiSCH mesh can be several hops deep.
In typical use cases considered by the 6TiSCH working group, a network that is 2-4 hops deep is commonplace; a network which is more than 8 hops deep is not common.</t>
          <section anchor="bytes-on-the-wire-1" numbered="true" toc="default">
            <name>Bytes on the wire</name>
            <t>Increasing the number of bytes on the wire in a protocol message has an important effect on the 6TiSCH network in case the fragmentation is triggered.
More fragments contribute to congestion of shared cells (and concomitant error rates) in a non-linear way.</t>
            <t>The available size for key exchange messages depends on the topology of the network, whether the message is traveling uplink or downlink, and other stack parameters.
A key performance indicator for a 6TiSCH network is "network formation", i.e. the time it takes from switching on all devices, until the last device has executed the AKE and securely joined.
As a benchmark, given the size limit on the frames and taking into account the different headers (including link-layer security), for a 6TiSCH network 5 hops deep, the maximum CoAP payload size to avoid fragmentation is 47/45 bytes (uplink/downlink) <xref target="AKE-for-6TiSCH" format="default"/>.</t>
          </section>
          <section anchor="time" numbered="true" toc="default">
            <name>Time</name>
            <t>Given the slotted nature of 6TiSCH, the number of bytes in a frame has insignificant impact on latency, but the number of frames has.
The relevant metric for studying AKE is the network formation time, which implies parallel AKE runs among nodes that are attempting to join the network.
Network formation time directly affects the time installers need to spend on site at deployment time.</t>
          </section>
          <section anchor="sixt-rtt" numbered="true" toc="default">
            <name>Round trips and number of flights</name>
            <t>Given the mesh nature of the 6TiSCH network, and given that each message may travel several hops before reaching its destination, it is highly desirable to minimize the number of round trips to reduce latency.</t>
          </section>
          <section anchor="power-1" numbered="true" toc="default">
            <name>Power</name>
            <t>From the power consumption point of view, it is more favorable to send a small number of large frames than a larger number of short frames.</t>
          </section>
        </section>
        <section anchor="nb-iot" numbered="true" toc="default">
          <name>NB-IoT</name>
          <t>3GPP has specified Narrow-Band IoT (NB-IoT) for support of infrequent data transmission via user plane and via control plane. NB-IoT is built on cellular licensed spectrum at low data rates for the purpose of supporting:</t>
          <ul spacing="normal">
            <li>operations in extreme coverage conditions,</li>
            <li>device battery life of 10 years or more,</li>
            <li>low device complexity and cost, and</li>
            <li>a high system capacity of millions of connected devices per square kilometer.</li>
          </ul>
          <t>NB-IoT achieves these design objectives by:</t>
          <ul spacing="normal">
            <li>Reduced baseband processing, memory and RF enabling low complexity device implementation.</li>
            <li>A lightweight setup minimizing control signaling overhead to optimize power consumption.</li>
            <li>In-band, guard-band, and stand-alone deployment enabling efficient use of spectrum and network infrastructure.</li>
          </ul>
          <section anchor="nbiot-bytes" numbered="true" toc="default">
            <name>Bytes on the wire</name>
            <t>The number of bytes on the wire in a protocol message has a direct effect on the performance for NB-IoT. In contrast to LoRaWAN and 6TiSCH, the NB-IoT radio bearers are not characterized by a fixed sized PDU. Concatenation, segmentation and reassembly are part of the service provided by the NB-IoT radio layer. As a consequence, the byte count has a measurable impact on time and energy consumption for running the AKE.</t>
          </section>
          <section anchor="nbiot-time" numbered="true" toc="default">
            <name>Time</name>
            <t>Coverage significantly impacts the available bit rate and thereby the time for transmitting a message, and there is also a difference between downlink and uplink transmissions (see <xref target="nbiot-power" format="default"/>). The transmission time for a message is essentially proportional to the number of bytes.</t>
            <t>Since NB-IoT is operating in licensed spectrum, in contrast to e.g. LoRaWAN, the packets on the radio interface can be transmitted back-to-back, so the time before sending OSCORE protected data is limited by the number of round trips/flights of the AKE and not by a duty cycle.</t>
          </section>
          <section anchor="nbiot-rtt" numbered="true" toc="default">
            <name>Round trips and number of flights</name>
            <t>As indicated in <xref target="nbiot-time" format="default"/>, the number of frames and round-trips is one limiting factor for protocol completion time.</t>
          </section>
          <section anchor="nbiot-power" numbered="true" toc="default">
            <name>Power</name>
            <t>Since NB-IoT is operating in licensed spectrum, the device is allowed to transmit at a relatively high power, which has a large impact on the energy consumption.</t>
            <t>The benchmark for NB-IoT energy consumption is based on the same computational model as was used by 3GPP in the design of this radio layer <xref target="NB-IoT-battery-life-evaluation" format="default"/>. The device power consumption is assumed to be 500mW for transmission and 80mW for reception. Power consumption for "light sleep" (~ 3mW) and "deep sleep" (~ 0.015mW) are negligible in comparison. The bitrates (uplink/downlink) are assumed to be 28/170 kbps for good coverage and 0,37/2,5 kbps for bad coverage.</t>
            <t>The results <xref target="AKE-for-NB-IoT" format="default"/> show a high per-byte energy consumption for uplink transmissions, in particular in bad coverage. Given that the application decides about the device being initiator or responder in the AKE, the protocol cannot be tailored for a particular message being uplink or downlink. To perform well in both kind of applications the overall number of bytes of the protocol needs to be as low as possible.</t>
          </section>
        </section>
        <section anchor="disc" numbered="true" toc="default">
          <name>Discussion and Summary of Benchmarks</name>
          <t>The difference between uplink and downlink performance must not be engineered into the protocol since it cannot be assumed that a particular protocol message will be sent uplink or downlink.</t>
          <t>For NB-IoT the byte count on the wire has a measurable impact on time and energy consumption for running the AKE, so the number of bytes in the messages needs to be as low as possible.</t>
          <t>While "as small protocol messages as possible" does not lend itself to a sharp boundary threshold, "as few flights as possible" does and is relevant in all settings above.</t>
          <t>The penalty is high for not fitting into the frame sizes of 6TiSCH and LoRaWAN networks. Fragmentation is not defined within these technologies so requires fragmentation scheme on a higher layer in the stack. With fragmentation increases the number of frames per message, each with its associated overhead in terms of power consumption and latency. Additionally the probability for errors increases, which leads to retransmissions of frames or entire messages that in turn increases the power consumption and latency.</t>
          <t>There are trade-offs between "few messages" and "few frames"; if overhead is spread out over more messages such that each message fits into a particular frame this may reduce the overall power consumption. For example, with a frame size of 50 bytes, two 60-byte messages will fragment into 4 frames in total, whereas three 40-byte messages fragment into 3 frames in total. On the other hand, a smaller message has less probability to collide with other messages and incur retransmission.</t>
          <t>While it may be possible to engineer such a solution for a particular radio technology and AKE protocol, optimizing for a specific scenario may not be optimal for other settings. It is expected that specific scenarios are evaluated in the design phase to ensure that the AKE is fit for purpose. But in order to start the design work some general criteria for the AKE performance need to be formulated that takes into account the differences in the expected deployments.</t>
          <t>There are benefits in terms of fewer flights/round trips for NB-IoT (<xref target="nbiot-rtt" format="default"/>) and 6TiSCH (<xref target="sixt-rtt" format="default"/>). An AKE protocol complying with the requirements of this memo is expected to have at least 3 messages. With a 3-message AKE, the initiator is able to derive the OSCORE security context after receiving message 2, rendering the AKE essentially one round trip before traffic data can be exchanged, which is ideal.</t>
          <t>If the AKE has 3 messages then optimal performance for 6TiSCH is when each message fits into as few frames as possible, ideally 1 frame per message.</t>
          <t>For LoRaWAN, optimal performance is determined by the duty cycle which puts a limit to ToA or, for certain libraries/providers, the number of packets (see <xref target="lorawan-time" format="default"/>). If the AKE has 3 messages and each message fits into a 51 byte packet then this is optimal for the latter case. The same assumption incurs a ToA for uplink messages in the interval of 4-6 seconds at SF12 both for a device-initiated and infrastructure-initiated AKE, which complies with the challenging example stated in <xref target="lorawan-time" format="default"/>.</t>
          <t>One avenue to good performance is therefore to target message sizes which avoids fragmentation or with as few fragments as possible. For the LoRaWAN benchmark, the limit for fragmentation is 51 bytes at link layer. For the 6TiSCH benchmark, messages less than or equal to 45 bytes at CoAP payload layer need not be fragmented.</t>
          <t>For the initial focus cases (<xref target="initial-focus" format="default"/>), i.e. RPK (by reference and value) and certificate by reference, it is required that the AKE shall perform optimally with respect to the available criteria for the radio technologies.</t>
          <t>To determine with certainty what are the minimal number of fragments for an AKE under different assumptions requires to design and analyse the AKE, which is clearly beyond the requirements phase. However, by means of an example we have reason to believe that an AKE with 3 messages can be designed to support RPK by reference in 3 fragments. Thus the ideal number of fragments is expected for RPK by reference.</t>
          <t>While such performance may not be possible for the other initial focus cases, it is expected that if one of the peers send RPK by value or certificate by reference, then one additional fragment is sufficient, thus in total a maximum of 5 fragments. Alternatively, for the LoRaWAN challenge (<xref target="lorawan-time" format="default"/>), it is expected that the duty cycle for a burst can be complied with for RPK by value and certificate by reference, assuming that each message only needs to be retransmitted at most once (i.e. good AKE performance for RPK by value and certificate by reference in not too poor radio environments).</t>
        </section>
        <section anchor="ake-frequency" numbered="true" toc="default">
          <name>AKE frequency</name>
          <t>One question that has been asked in the context of lightweightness is: - How often is the AKE executed? While it may be impossible to give a precise answer there are other perspectives to this question.</t>
          <ol spacing="normal" type="1">
            <li>
              <t>For some use cases, already one execution of the AKE is heavy, for example, because
              </t>
              <ul spacing="normal">
                <li>there are a number of parallel executions of the AKE which loads down the network, such as in a network formation setting, or</li>
                <li>the duty cycle makes the completion time long for even one run of the protocol.</li>
              </ul>
            </li>
            <li>If a device reboots it may not be able to recover the security context, e.g. due to lack of persistent storage, and is required to establish a new security context for which an AKE is preferred. Reboot frequency may be difficult to predict in general.</li>
            <li>To limit the impact of a key compromise, BSI, NIST and ANSSI and other organizations recommend in other contexts frequent renewal of keys by means of Diffie-Hellman key exchange. This may be a symmetric key authenticated key exchange, where the symmetric key is obtained from a previous asymmetric key based run of the AKE.</li>
          </ol>
          <t>To summarize, even if it we are unable to give precise numbers for AKE frequency, a lightweight AKE:</t>
          <ul spacing="normal">
            <li>reduces the time for network formation and AKE runs in challenging radio technologies,</li>
            <li>allows devices to quickly re-establish security in case of reboots, and</li>
            <li>enables support for recommendations of frequent key renewal.</li>
          </ul>
        </section>
      </section>
    </section>
    <section anchor="sec-cons" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document compiles the requirements for an AKE and provides some related security considerations.</t>
      <t>The AKE must provide the security properties expected of IETF protocols, e.g., providing mutual authentication, confidentiality, and negotiation integrity as is further detailed in the requirements.</t>
    </section>
    <section anchor="privacy-considerations" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>In the privacy properties for the AKE, the transport over CoAP needs to be considered.</t>
    </section>
    <section anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>None.</t>
    </section>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>The authors want to thank Richard Barnes, Dominique Barthel, Karthik Bhargavan, Stephen Farrell, Ivaylo Petrov, Eric Rescorla, Michael Richardson, Jesus Sanchez-Gomez, Claes Tidestav, Hannes Tschofenig and Christopher Wood for providing valuable input.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Informative References</name>
      <reference anchor="RFC7228" target="https://www.rfc-editor.org/info/rfc7228" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml">
        <front>
          <title>Terminology for Constrained-Node Networks</title>
          <seriesInfo name="DOI" value="10.17487/RFC7228"/>
          <seriesInfo name="RFC" value="7228"/>
          <author initials="C." surname="Bormann" fullname="C. Bormann">
            <organization/>
          </author>
          <author initials="M." surname="Ersue" fullname="M. Ersue">
            <organization/>
          </author>
          <author initials="A." surname="Keranen" fullname="A. Keranen">
            <organization/>
          </author>
          <date year="2014" month="May"/>
          <abstract>
            <t>The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks.  This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC7049" target="https://www.rfc-editor.org/info/rfc7049" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7049.xml">
        <front>
          <title>Concise Binary Object Representation (CBOR)</title>
          <seriesInfo name="DOI" value="10.17487/RFC7049"/>
          <seriesInfo name="RFC" value="7049"/>
          <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>
      </reference>
      <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml">
        <front>
          <title>The Constrained Application Protocol (CoAP)</title>
          <seriesInfo name="DOI" value="10.17487/RFC7252"/>
          <seriesInfo name="RFC" value="7252"/>
          <author initials="Z." surname="Shelby" fullname="Z. Shelby">
            <organization/>
          </author>
          <author initials="K." surname="Hartke" fullname="K. Hartke">
            <organization/>
          </author>
          <author initials="C." surname="Bormann" fullname="C. Bormann">
            <organization/>
          </author>
          <date year="2014" month="June"/>
          <abstract>
            <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t>
            <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC7959" target="https://www.rfc-editor.org/info/rfc7959" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7959.xml">
        <front>
          <title>Block-Wise Transfers in the Constrained Application Protocol (CoAP)</title>
          <seriesInfo name="DOI" value="10.17487/RFC7959"/>
          <seriesInfo name="RFC" value="7959"/>
          <author initials="C." surname="Bormann" fullname="C. Bormann">
            <organization/>
          </author>
          <author initials="Z." surname="Shelby" fullname="Z. Shelby" role="editor">
            <organization/>
          </author>
          <date year="2016" month="August"/>
          <abstract>
            <t>The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks.  Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates.  In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS).  These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.</t>
            <t>Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs.  In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers.  Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.</t>
            <t>A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations.  Therefore, this specification updates RFC 7252.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC7967" target="https://www.rfc-editor.org/info/rfc7967" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7967.xml">
        <front>
          <title>Constrained Application Protocol (CoAP) Option for No Server Response</title>
          <seriesInfo name="DOI" value="10.17487/RFC7967"/>
          <seriesInfo name="RFC" value="7967"/>
          <author initials="A." surname="Bhattacharyya" fullname="A. Bhattacharyya">
            <organization/>
          </author>
          <author initials="S." surname="Bandyopadhyay" fullname="S. Bandyopadhyay">
            <organization/>
          </author>
          <author initials="A." surname="Pal" fullname="A. Pal">
            <organization/>
          </author>
          <author initials="T." surname="Bose" fullname="T. Bose">
            <organization/>
          </author>
          <date year="2016" month="August"/>
          <abstract>
            <t>There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant.  This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient.  However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to       understand and satisfy the request", per RFC 7252.</t>
            <t>This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes.  The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request.  This option may be effective for both unicast and multicast requests.  This document also discusses a few examples of applications that benefit from this option.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC8152" target="https://www.rfc-editor.org/info/rfc8152" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8152.xml">
        <front>
          <title>CBOR Object Signing and Encryption (COSE)</title>
          <seriesInfo name="DOI" value="10.17487/RFC8152"/>
          <seriesInfo name="RFC" value="8152"/>
          <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>
      </reference>
      <reference anchor="RFC8613" target="https://www.rfc-editor.org/info/rfc8613" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8613.xml">
        <front>
          <title>Object Security for Constrained RESTful Environments (OSCORE)</title>
          <seriesInfo name="DOI" value="10.17487/RFC8613"/>
          <seriesInfo name="RFC" value="8613"/>
          <author initials="G." surname="Selander" fullname="G. Selander">
            <organization/>
          </author>
          <author initials="J." surname="Mattsson" fullname="J. Mattsson">
            <organization/>
          </author>
          <author initials="F." surname="Palombini" fullname="F. Palombini">
            <organization/>
          </author>
          <author initials="L." surname="Seitz" fullname="L. Seitz">
            <organization/>
          </author>
          <date year="2019" month="July"/>
          <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.</t>
            <t>Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration.  Therefore, this document updates RFC 7252.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC8376" target="https://www.rfc-editor.org/info/rfc8376" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8376.xml">
        <front>
          <title>Low-Power Wide Area Network (LPWAN) Overview</title>
          <seriesInfo name="DOI" value="10.17487/RFC8376"/>
          <seriesInfo name="RFC" value="8376"/>
          <author initials="S." surname="Farrell" fullname="S. Farrell" role="editor">
            <organization/>
          </author>
          <date year="2018" month="May"/>
          <abstract>
            <t>Low-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation.  This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="I-D.ietf-6tisch-minimal-security" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6tisch-minimal-security.xml" target="http://www.ietf.org/internet-drafts/draft-ietf-6tisch-minimal-security-15.txt">
        <front>
          <title>Constrained Join Protocol (CoJP) for 6TiSCH</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-6tisch-minimal-security-15"/>
          <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>
      </reference>
      <reference anchor="I-D.ietf-lpwan-coap-static-context-hc" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lpwan-coap-static-context-hc.xml" target="http://www.ietf.org/internet-drafts/draft-ietf-lpwan-coap-static-context-hc-14.txt">
        <front>
          <title>LPWAN Static Context Header Compression (SCHC) for CoAP</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lpwan-coap-static-context-hc-14"/>
          <author initials="A" surname="Minaburo" fullname="Ana Minaburo">
            <organization/>
          </author>
          <author initials="L" surname="Toutain" fullname="Laurent Toutain">
            <organization/>
          </author>
          <author initials="R" surname="Andreasen" fullname="Ricardo Andreasen">
            <organization/>
          </author>
          <date month="May" day="26" year="2020"/>
          <abstract>
            <t>This draft defines the way Static Context Header Compression (SCHC) header compression can be applied to the Constrained Application Protocol (CoAP).  SCHC is a header compression mechanism adapted for constrained devices.  SCHC uses a static description of the header to reduce the redundancy and the size of the information in the header. While [rfc8724] describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies the use of SCHC for CoAP headers.  The CoAP header structure differs from IPv6 and UDP since CoAP uses a flexible header with a variable number of options, themselves of variable length.  The CoAP protocol messages format is asymmetric: the request messages have a header format different from the one in the response messages.  This specification gives guidance on how to apply SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="I-D.ietf-cose-x509" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-cose-x509.xml" target="http://www.ietf.org/internet-drafts/draft-ietf-cose-x509-06.txt">
        <front>
          <title>CBOR Object Signing and Encryption (COSE): Header parameters for carrying and referencing X.509 certificates</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-cose-x509-06"/>
          <author initials="J" surname="Schaad" fullname="Jim Schaad">
            <organization/>
          </author>
          <date month="March" day="9" year="2020"/>
          <abstract>
            <t>The CBOR Signing And Encrypted Message (COSE) structure uses references to keys in general.  For some algorithms, additional properties are defined which carry parts of keys as needed.  The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="I-D.ietf-core-echo-request-tag" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-echo-request-tag.xml" target="http://www.ietf.org/internet-drafts/draft-ietf-core-echo-request-tag-09.txt">
        <front>
          <title>CoAP: Echo, Request-Tag, and Token Processing</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-echo-request-tag-09"/>
          <author initials="C" surname="Amsuess" fullname="Christian Amsuess">
            <organization/>
          </author>
          <author initials="J" surname="Mattsson" fullname="John Mattsson">
            <organization/>
          </author>
          <author initials="G" surname="Selander" fullname="Goeran Selander">
            <organization/>
          </author>
          <date month="March" day="9" year="2020"/>
          <abstract>
            <t>This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases.  The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address; it is now the recommeded way to mitigate amplification attacks.  The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. The update to the client Token processing requirements of RFC 7252 forbids non-secure reuse of Tokens to ensure binding of responses to requests when CoAP is used with security.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="I-D.irtf-cfrg-randomness-improvements" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.irtf-cfrg-randomness-improvements.xml" target="http://www.ietf.org/internet-drafts/draft-irtf-cfrg-randomness-improvements-12.txt">
        <front>
          <title>Randomness Improvements for Security Protocols</title>
          <seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-randomness-improvements-12"/>
          <author initials="C" surname="Cremers" fullname="Cas Cremers">
            <organization/>
          </author>
          <author initials="L" surname="Garratt" fullname="Luke Garratt">
            <organization/>
          </author>
          <author initials="S" surname="Smyshlyaev" fullname="Stanislav Smyshlyaev">
            <organization/>
          </author>
          <author initials="N" surname="Sullivan" fullname="Nick Sullivan">
            <organization/>
          </author>
          <author initials="C" surname="Wood" fullname="Christopher Wood">
            <organization/>
          </author>
          <date month="May" day="5" year="2020"/>
          <abstract>
            <t>Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols.  Weak or predictable "cryptographically-strong" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes.  The Dual_EC_DRBG random number backdoor and Debian bugs are relevant examples of this problem.  An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems.  This document describes a way for security protocol participants to augment their CSPRNGs using long-term private keys.  This improves randomness from broken or otherwise subverted CSPRNGs.  This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="I-D.selander-ace-ake-authz" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.selander-ace-ake-authz.xml" target="http://www.ietf.org/internet-drafts/draft-selander-ace-ake-authz-01.txt">
        <front>
          <title>Lightweight Authorization for Authenticated Key Exchange.</title>
          <seriesInfo name="Internet-Draft" value="draft-selander-ace-ake-authz-01"/>
          <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>
      </reference>
      <reference anchor="AKE-for-6TiSCH" target="https://docs.google.com/document/d/1wLoIexMLG3U9iYO5hzGzKjkvi-VDndQBbYRNsMUlh-k">
        <front>
          <title>AKE for 6TiSCH</title>
          <author>
            <organization/>
          </author>
          <date year="2019" month="March"/>
        </front>
      </reference>
      <reference anchor="AKE-for-NB-IoT" target="https://github.com/EricssonResearch/EDHOC/blob/master/docs/NB%20IoT%20power%20consumption.xlsx">
        <front>
          <title>AKE for NB-IoT</title>
          <author>
            <organization/>
          </author>
          <date year="2019" month="March"/>
        </front>
      </reference>
      <reference anchor="NB-IoT-battery-life-evaluation" target="http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_AH/NR_AH_1701/Docs//R1-1701044.zip">
        <front>
          <title>On mMTC, NB-IoT and eMTC battery life evaluation</title>
          <author>
            <organization/>
          </author>
          <date year="2017" month="January"/>
        </front>
      </reference>
      <reference anchor="HKDF" target="https://eprint.iacr.org/2010/264.pdf">
        <front>
          <title>Cryptographic Extraction and Key Derivation: The HKDF Scheme</title>
          <author initials="H." surname="Krawczyk">
            <organization/>
          </author>
          <date year="2010" month="May"/>
        </front>
      </reference>
      <reference anchor="IANA-COSE-Algorithms" target="https://www.iana.org/assignments/cose/cose.xhtml#algorithms">
        <front>
          <title>COSE Algorithms</title>
          <author>
            <organization/>
          </author>
          <date year="2020" month="March"/>
        </front>
      </reference>
      <reference anchor="LwM2M" target="https://www.openmobilealliance.org/release/LightweightM2M/V1_1-20180710-A/OMA-TS-LightweightM2M_Transport-V1_1-20180710-A.pdf">
        <front>
          <title>OMA SpecWorks LwM2M</title>
          <author>
            <organization/>
          </author>
          <date year="2018" month="August"/>
        </front>
      </reference>
      <reference anchor="OCF" target="https://github.com/t2trg/2020-03-ocf-oscore/blob/master/slides/Joint-OCF-IRTF-T2TRG-call-on-OSCORE-20200318.pdf">
        <front>
          <title>OSCORE:OCF Status and Comments</title>
          <author>
            <organization/>
          </author>
          <date year="2020" month="March"/>
        </front>
      </reference>
      <reference anchor="LoRaWAN" target="https://lora-alliance.org/resource-hub/lorawantm-regional-parameters-v102rb">
        <front>
          <title>LoRaWAN Regional Parameters v1.0.2rB</title>
          <author>
            <organization/>
          </author>
          <date year="2017" month="February"/>
        </front>
      </reference>
      <reference anchor="LAKE-WG" target="https://datatracker.ietf.org/wg/lake/about/">
        <front>
          <title>LAKE WG</title>
          <author>
            <organization/>
          </author>
          <date year="2020" month="March"/>
        </front>
      </reference>
      <reference anchor="KCI" target="https://www.usenix.org/system/files/conference/woot15/woot15-paper-hlauschek.pdf">
        <front>
          <title>Prying open Pandoras box:KCI attacks against TLS</title>
          <author initials="C." surname="Hlauschek" fullname="Clemens Hlauschek">
            <organization/>
          </author>
          <author initials="M." surname="Gruber" fullname="Markus Gruber">
            <organization/>
          </author>
          <author initials="F." surname="Fankhauser" fullname="Florian Fankhauser">
            <organization/>
          </author>
          <author initials="C." surname="Schanes" fullname="Christian Schanes">
            <organization/>
          </author>
          <date year="2015" month="August"/>
        </front>
      </reference>
      <reference anchor="Misbinding" target="https://arxiv.org/pdf/1902.07550.pdf">
        <front>
          <title>Misbinding Attacks on Secure Device Pairing and Bootstrapping</title>
          <seriesInfo name="Proceedings of the 2019 ACM Asia Conference on Computer and Communications Security" value=""/>
          <author initials="M." surname="Sethi" fullname="Mohit Sethi">
            <organization/>
          </author>
          <author initials="A." surname="Peltonen" fullname="Aleksi Peltonen">
            <organization/>
          </author>
          <author initials="T." surname="Aura" fullname="Tuomas Aura">
            <organization/>
          </author>
          <date year="2019" month="May"/>
        </front>
      </reference>
      <reference anchor="Selfie" target="https://eprint.iacr.org/2019/347">
        <front>
          <title>Selfie:Reflections on TLS 1.3 with PSK</title>
          <author initials="N." surname="Drucker">
            <organization/>
          </author>
          <author initials="S." surname="Gueron">
            <organization/>
          </author>
          <date year="2019" month="March"/>
        </front>
      </reference>
      <reference anchor="massive-breach" target="https://www.theguardian.com/us-news/2015/feb/19/nsa-gchq-sim-card-billions-cellphones-hacking">
        <front>
          <title>Sim card database hack gave US and UK spies access to billions of cellphones</title>
          <author>
            <organization/>
          </author>
          <date year="2015" month="February"/>
        </front>
      </reference>
      <reference anchor="lorawan-duty-cycle" target="https://jwcn-eurasipjournals.springeropen.com/articles/10.1186/s13638-019-1502-5">
        <front>
          <title>Impact of EU duty cycle and transmission power limitations for sub-GHz LPWAN SRDs an overview and future challenges. EURASIP Journal on Wireless Communications and Networking. 2019. 10.1186/s13638-019-1502-5.</title>
          <author initials="M." surname="Saelens" fullname="Martijn Saelens">
            <organization/>
          </author>
          <author initials="J." surname="Hoebeke" fullname="Jeroen Hoebeke">
            <organization/>
          </author>
          <author initials="A." surname="Shahid" fullname="Adnan Shahid">
            <organization/>
          </author>
          <author initials="E." surname="De Poorter" fullname="Eli De Poorter">
            <organization/>
          </author>
          <date year="2019"/>
        </front>
      </reference>
      <reference anchor="keylength" target="https://infoscience.epfl.ch/record/164539/files/NPDF-32.pdf">
        <front>
          <title>Key Lengths:Contribution to The Handbook of Information Security</title>
          <author initials="A." surname="Lenstra">
            <organization/>
          </author>
          <date year="2018"/>
        </front>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAEQ53l4AA61963Lb2LXmfz4FSq5USymCuvmeykxk2bKVbl9GUsdz6mQq
BYKbJFogwACgaFrlU/Mi83LzJLO+tda+gZTdSU1+pC0S3NiXdfnWdadpOuiK
rjQvkyvzz1XRmIWpujaZ1k2SJb8Us3m3Nvj/5OznN/zpx+vzj1dvBtl43Jg7
/lWb/kJfpvRlql9O6rzKFjTmpMmmXVqYbpqW2a1JGzx99HgwKJbNy6RrVm13
cnT04uhkkGfdy6SopvVgkNeTopq9TFb0q+eDZfEyeZTkWZWsWpNkTZNtkv1i
mmRlmWxMe5DQnOZZO0/mpjGDJOnq/CW+oH+2ddM1Ztq6vzeL8E96cmKW3fxl
cjIYZKtuXjcv6WP8L9X/JjQlev79KPnbKi+qInefy/reZ2XRZltf1g1N/7Jq
isx9ZBZZUb5MFvyD0Z384C8FnhlNm92vfTtKrk2ZVRPT9N77tjYN7cjWt/zi
N02Rt21dJWev+q+f1fSzUas/+4vRJ0d5vdg9hb+OaI1dh4d6U/hrPa+ST41Z
te32Iz+ax2/049FCf/U7pvF6lLzNmjzYT5nEa9oE+SI9J9IoyrKO5/CRSCm5
rstVV9RVm1yPfhn15zKZ8QB/AdW1I6KMwaCqG5pccWde0h8gSv9nklxdnD87
OXn+Uv959PiF/efJkxP7zxdP3Kcvnj7Tfz4/dg88f3p8av95+uwp/nmZvh4x
pzztijafpwuiECKXtDX5qim6TfRMuVxnVZrX2TJtO5pbTv+uOvOlS+d59GBe
tyb98uToRe/TxqQmn9fgyJVpu7TLZu6JBk9Mm1lKxDKpF5Vp27RYLJv6TqSD
fdDSUZrlJgV7g4m+4lvsk5UJT2+K6/N3wlld1swMMfq865bty8NDEhTtaFbX
s9Lg8PH3Cq84nBwer3+pL82X97+8Pf31RfEfH5/Mv779+vNvt3dF+rfX1eR/
vBr/x9WH9v2v5Ty9lbFFjFk5Ja/lbyZZx7za5PPk5Oj4RTi7D6/Sy/pm9+xm
RTdfjXlilpavTGswzuGb1+8+nh+Oy3p8uMjazjS8lsMPr/5wckQD0v8v67Vp
6L90MO1qsQQBjr6U7Zddk5VZPDhZ+TodE8OYZpOWxZRO7y4rVxlG3Z48zX29
Xo9OZ8vliNjgcNotD7t29g86z8PPb4//cfXL8eHN9dur43+cvTv8cEX//4/j
Z0fHh6+xhMOr4xR/HT1+PPpaLMPp7n2sksX7m/Ohziih408MfZDo1BJMLfFT
2wuW9FfiVVrQMyzo3c+vL3bvuVk2RdWNiixveOr0i6PDk6ePR8vJNJrKebNZ
dvWsyZbzIk/efOmaLMcreU4/m03ymsTKnWxQcjM3/M7kOp8TDcu0vivy342S
n5tsnX/d3EbHssEajvgjcMHZh7P0/OP1m/SsJNlK9LJod68L51FkVcaLytq2
mFXMS4dgUP6/0Zd5tygfZW6gcLl4R3IWfxVTysnRADv7y/r9yfuHp1AvTbWo
x0VpSH/SfHLDE2oMfUDzCBQ+DXP4t+N/HKe03udHz46P0rPDj+/P0pvrNH7q
HzdEVu2SdG3ae75/ZvTz5Hpp8s91c9vKTIOFnK1mBAewvc+xkI/nD1BIwJXd
ScckcnKUHp2mdT5N6xaiLeLLtiwmpj38a010ldKo6eXVzUV6c3Jz9TbNaRfS
ulLckmKko9Pj51sT569f0o+Ta5K2q5aJ7Lxe8BHuPgwRgr/UV9nnsw+7V1KS
Nk5759DWq4akKa2QvyYp3y1ISM+IjEkXLLOG9B6tqk3vjo9OmnE4S30XQTJ5
Ovnknk7ujkdHo5PmVTDXCzMWflRaZhD3+e0DgjqjdROH3ZqGNQjPdj07BKo7
zMb1qjuMpgLB9vntQzvD7/v5/PJhOiWsVxVf+C3tho5xcTglmgW3VFPCebRf
h+u67o6f6H9oZ5akiOZltiLdaW7dCX6Xyc9HyTv7ix6yOC+h69qt79NkCxq+
bVbjLYRG670lOom+6739YpRcZNXtnF6w9fMLOnwii+0HtldAIi2rTNuf/7wp
2g5D6Pf26yQ8p0/NhqB2AqlA1ELKvsnaZFx/eUmHk5BIpwMnWp9l9K4uufnl
eie7PrEn+r5ox0XF4H3nwWbNl+KOz5RO5/CYYP/o6NmTJ0d9dvPjJGc6hxpg
l3CQIbF+V+SGZls0eACM+IpIoCXqXC7pkx2nHmxacGzXppsX4Rd6cPW86OIv
t39+Nko+mbKrK1Ntj3BWmtu22Hpge5SbEe1ik22PcLOqSXj5LyPl84I/Iooo
TAtsilOsc2OwX7RR06QjZYfnkrPz98lZW2QkqSzXYCNJbi1XJBWcEFuRKZIp
QFawaY+ULIxpYX63qn5xePr4WXiU+vsrMy1NLq+gGRAlJcej02RNojz5dP3z
jzn1wyh53awgfnZ/f01suDINjb0bROlyFtC8dyYl2zXL5w+LH9rC2SprJsQ/
rGhWbVqZdYslPjmcmjER72HVZuksn/8zbYsFKZJmkpJaLbHENDdluZzT4bfp
nMjXUqXdk2KR4HnMMhuT2k3wUDLL7kzy6zWfyq8/J+2SzjfJ8pzQN5mqiR0c
J+zH35bnjhtVfaSTVbdJ801ePnCMv63zKjVEam2x/I20D2mOdtTibGe0oSQZ
eAeyhowMSODjo9Hx8fOnh+3x6dPT5yltbnr85OgkfZL8+BTBdRlBjaovrd5j
+N+q3rd9WUvG6LvajM2t6duiNFGSYPGXvXcTy17Ps3kx6f32bFJBSIZf9X75
hmiPBE5NCGdLTr8pi+BL+1142peLJQFTnNqbXxOcRcJnwcfcATktCqJJIly2
FwhAL4pOmRGWQbsap2/ffU1++QTVfn31GtgjIUusuSvMmkeZrjoIRhLzJW3e
zLQjetXV2fXlJzLS+TzBc58LgDyipR7HY4QPplsTJqMTHzG7jJIHT3kUUFzI
Wbdmg5d3DzAVBFWbFxBBI7OcliMyoRpDWI0MvaePn5y+UP3+4dPri/T0pK8R
gOd/4eHblyTMuqYYs0UPxmBsT6sY1/UttvnS2utWZ1hx9l3SJPKgF0CLxAt8
LgtM0zTJxi0bGYPBzbxoE2urJsQeS0yeBW+z7UUrAy8a5kBfYffNBJuWmC/Q
zzOTkH3d1XldBl62UaKvghsNXi5+V2nw2yzRI0tmTb1aJiWh3QR4Ntn//PaX
8wNaFk+IoVj06GjwqSaLH08Nt+ecgZSIMAg0N/SadjWdFji4rtwkLckrIl1M
EL+LJ0BHsRRFJHK9oMHwBC3isktoFVVNE1w1jYy1LLOqomfxs9W4LNo5jenW
mjGZX12cj8iqweYvismkNIPBIzrfrqknKzH2kvtHBf7+NhjIliX39+pe+fYN
L423Pw9pP7GeFb/18HEUDDxMNUm7OqX/+MdgXC6Xpf15mW2IYbEZ2C8ijQLr
gVncmq5jbbyfT0cyI7iMvn07GOnJ0o8ZWpFG6vI5A5nfQRn7dJY0BCieVo2n
aRq82e6kP7+l9ymUlx2gDc5J3XUkchJSVUQ+ycZ0sirjPBD8BShA1kbEYxZj
M5nQXCaMuFoihSWsPExWyZM4oaadajFQN886ngZGpNcaSzeOXMwXsv2YdP0m
sjqT0YbJ2tBhtZ3SZGnuyPgR4shJHZq8mIa/6kw+r+qynkFPruH9tXtLby+q
vFzR5F8OBn/k/bp8c3OhPiHsEe0sC2yictrFaaHcWxmhyD3enb//p/n7/+LP
fyPjUai7FYm5yG7tt7TsKSFGHIOynCOHjic6J9Kj86bzyjdDUstreog4ZjYn
FMaDtQuw7RTGGp3QV54LjYo5krghoPcV83/z5jkB5uMno8fJDa1iz5ESyIM2
to1mKgRDbES2b07iktZFX+gGvBfXohOPRDI/8j5++zaKtlL00Y93Uv2G/Fln
HQUkp5YZAZqiw+O0RRiNfsJaCIRGsI2mHjiZYNvSIdcElvbAxBD9tMOdO+lk
NBpFW4i///6fdaUnSJqGJslkI+Qz3nSYqmjgTiTqlDRqVyzoczImSQdsyAZK
ViU9lOLYiAbNpN0TBgwlgaNhkF604cHGfs9lq7trHSRr7yBJSNMzPDgeHYOz
8Rnx9cRMCxh1aicxl9PuORAAJm2ySVF/n00CITw2NOiyrDfENM6VwOCAT0Hm
BzuR9G8FLH8HwrmoV9VENmH/4/nFAY/Is0G0Rl8EAbBTnk4TFsbE8rTnbUbQ
hZZIw/B2/Eta1gqeQHdC67SrxSJrlKWMf3P0e2Y2qD0noKZNvVAqrDDsENS4
JtCN/2KgBTF3wJ9kaOfO9DLVXUGGiIwtG87v1iAEy0Z6BIe6tfOjwU346Jow
PzGzoWWQ4t3gSdrW6aoEadU0KuHD3FS0wrp1UySjMIesZ4p1W01kNDfZxPKj
LAOfQvQQtTNmAjqDiiWDkvT8QkmZXdekaOmH4xQfkbJ99Ki33fQ9lI788W3A
62iYMDJFDPTLYlaBMFnPOxlV6Al4qizFZgq1I43t5N1apBoNhqOqm0jDX725
vsEGkeHSBDDafMlY8403CUu24qtMxLidGTKxg6s39isVrIozux7Ts/pnANWY
8UaAu/0lLDs6LQESOTzVkC/VhNX2zGEOpTalXzlQ4pAlXJWj5H3dGMxuGC68
ywoy7PRX4DFW/+EOkOWGmdyZgLLL4tYQ/QixOVUvIornyyp+6LVsSU+f12ef
LHh5cvLt2zA5f/XxSj85evyCxBB7EOCaFtR1jMdEPLaQxEvYjw0L+XZer0rd
X7ubONTB4LJS4Syza1eFR5kWGSi0gPRQLgP1ORJqVrIMSMBlJi9cwDuVzRrD
Po/9lv57rYd5OjrBMAFSPGCccEazzBj0GkJMHUk02ff37EjGz+nTA/VaEMvQ
cCQAmzVsef4y3yT7ny6uaR/pbff3cFaKWsxKVqEHQmPJrK7pPwuSnWwY+jDb
KNnH5tHbFsneg0/tgUnGddOQxajC6v4e4Q06EdpEZrPphvE2SWpI1qagXSdZ
Cy6nf01IYrEJRT8PXn7AMl7WfG0Q2UsuX7NcI8XnKbOl82jGBWlFHpZOtiFq
JTvpj+GvIoEqR0sT+OfKqFU0Iwqt4q0dJgsibQi8vGiZXmkv/rkCvqDD6D1q
/8xK+uPyNdQSlOnQz+FAaMC9WI7FE8HpqEcFrOOYnH0QxqoyPnRNbxjwM2Ir
qCRlHq9D3gutuBsl2BbaWZlsk8xJQBedH2fHm+0AYkDRodXVrIT6yjn2AHTO
PM4/pScQjqfPxhvLI0MB94rNPFyhPVTCFDzrX8u6jjaSYJJ4JQqF8BWBo5bD
Z63ISppfdlcXZCCsRCqaSd+M4DfxzqzhnjXNSDQDNiMn6EEU2uCg6VGHAFRs
qvHDImpMopGItrEuRLIQjdf5kV08pN/ncJiz+DpUatYoN0mFTPhiDmdbRp8T
Hq1ao0LtxdNnkF8XqwaiGMSo8l3MV9oZG8nFykhp4wigbccEXQ1jIxKZeQmz
57A1zZ06Wdkkqogwsq5uDuWloNGmLu1mEtDQuSoq5KmKwleDOhhczAZ5AQ/C
iqWxW0YbwtCpMsNQ+w0FkSqGpKPwGsbuJXOMGnoBXsdD/P7R4DNZqf4bepn7
7qFRBPkDx8ITNZV18HwXZlJk8GMz0Skoc+SrxoqaBYn36qh5/XutlmsGRG5u
ls4WdSsOgboiCmSoNYaKIdukXZWZascdCwP9OJJPpqsqF5ijWh3MzGuQn0LY
dQnCq9//Jb1LECep+Y1wNQmHbDIB5VVpZWak5AsoRoNYN828ZeuHlYV4heuJ
GD9D+SdAKrExUN0wMV1uxQhT9BSSlunZypDAdhcWDA+Z3pN5fcvPO7lFHFyw
xnY/GKoBm1WMXkGnpJfzWxLjrOpt4IbIdUK/0yNxW8NwM8QdfjQBqjD0Zl7K
KPM+sYhEoZULXBGPFkJ6mAqiRy601UYnhi1g6nyTz2uCkDr699NmmMasUAPT
QvgIlvMMRCsQWqJDqAQA5/D8440ryAJBnYwpFbvQy1RSFCz0e5tV1i2xDfGv
buhw1zYO450SUbO9HR7owu4ibH8eqIf7R1AWBOlhi4uhIrbNpJhO4QAD/iBR
Q2PLqkOaXPPJBaPhFBnlLYWyRsm5cwmSAUJwgsO9Le8iEU+qkOzWbFoCV9c/
twdyZGo/1SsGR2NamMi6O1hDK1Bl1pJoHyG+JGikrRdGrHuWqUzS06JhArGr
ctpDYGbRgORyQxp9Is6zIidmFY2uj8n4JZlbovQDq4GZMvQ4Qo5jxovsN8iF
yaQQARC5IoHY+EBFMbdwsYG/BGnoW9sNAQACcblVsAFwgEADaUyQZSgGSU8v
Y+Scw4BqosFdBzpVe8BBPaKHd4QyWUfQQlOEqyb+ADA81G9RQabQ9q1Ndgss
iSDEDWtOfD2GbmwMTpypQsNwiYThxAVEo8fjWkK4v4+jdhAIvDPtNsHwWdhN
/jchOq1/w/RytyorMiJZssGukDkTPdxl/C9SHAXpc46a3ITeBaEdmo6dmhK9
2t4sanD2tEiaivUGqq+h5whWqRSSPC0SWi3gC4xPONg0FacpiqfAsLe+aOfe
zHPHSpslMji2o+JXM+jIPKGpJ5bfCLkKd0JEiWo24YFRcpWto1/sX336+cDu
RLgc579mk1EQJg4XZzkkAVJAKXr2ysRIIKWTfYHqQg4xfTQx1vNB72nF/Qh1
OzY6LTmjSKgCrt9BE/MEs1Ah1v1ZqskK63Kj+rF3UKxSIaSTfTMikqA9n2Y5
EcgGGGBmQEuMl6p0XBM9HtAhniEEQNqAqFO0zRAHrocTbB8yoxtCEM0q51gf
3kJGb6WHGBwSHuaID3Y1GCCHHc4WgIlOD7s15Cci5tNzqsU1OgR+4R2DoJED
oNXXC17Q/t5X09RpVxN82TsgsB5kY4g8m9CcZf8b+jI5P/s9O+43dDT49MBC
MAJxFcmVTK2U1rBPKwrDEPqhAxniOArGWiQ3SFGyvBciJ8XbkOasVouxeIlt
zIOVG4sZ0Xb4Cf25wsnSoppWdD94vTNLhyZwKNblRKPRlhUzcUcRBSE2Vom/
CFolr5f4D/9cHI8SpKEdEUqvxwynrXSJ91fxTiA2xURTzyMEJo+92/HnBqVh
DrF7TsWpgWPVonpdeFdZqA0hcOYst8BmPBgvAUcSeh2mpIeLMGqouNtHzOwx
9XxBzPP2V7TB/gCcFbrT3oCaSvYVNljDDJ6hioREezAEyaeiAT0pqWILWJrB
kBwt0yn0MEsp3V9MTIST2DOBTzJyNr1wTgZBs2D796uyK3DGAYPGrw4wU9Jt
lkYtV+M4xQEonggt6fetCOiTgSdT5Wva0sKk70xZElHHQUe2uUPAQWvLWPgo
BghluwRBF0TbxVhYjPnKfIFrHNY8WStMNuIBk/hH8vrd9iiMWmh4C2Zhzxyw
z1x9SRJ0nIqJbp25AqQBAtfFhF4c5FzDiioC4xIOsr59yxIvkiuQrz0FNobf
xaZRETMzwAespy+Q8EwS7lzj5hZ1rSEKAEhNn6EeIt4tIhcGCCfKbmRx6LDN
EKDrUfJ5XpRGfRYgWxZd7hgWBodbtAsZdlKzwKiHcAJyyIjlD5AY7VK8/nj5
9PWXJzRWwRi3II3Wo742Npu0BgHQjS0CBOaX8A43BVvCgUcwEDpsk4uXBR4i
DisKCbI4ykLgzpTtZIcTw0lOmqtR54tFuUOanH6STut81ZLdiMAzlHFrutg/
puyHZS7YX9G54HRu/iQSzW4rL4SG4Fy36GgsruHAh3EqT4C9zeBRr5tyUDFl
fheK93zI8EZ9Q/095BBFLEcCd7nzQCXjlfgiwsiZ80qNvDG7mzJDc45PLn4j
0YR/NnDaBTMh6CI6+YcCy01RJ6+pGeKVBM1BmH/3hwHcc6EVAC86A2FTIiOW
dV7AhVz/sLhi7MFVaczLlVcRVsAuCiDUcLt2CnAWlTCg3cIsANz1YnG9unCR
e3TH7Lccz3qUlZnVvJlCHyFK9ARLk9dX2Q3y9MPi0XkxgRUJT8CljXlB3gGN
8Q/X7EwmlCGS+9Ej5O8IL16A8zh/J+RExsTE9yvAA46ajQmsDDV8K36/Ah4S
UrwMjyYFPIsm9oT1vNtiJBDDzuumFaHNs1OSXFUhHFmbcSxMyLQo2JPLuQHs
fm9XZRe4hjOf7iCLAe7h5cHmV4EXJFUxBPK4VZ1vGJ19Jg0HEl+yVt+P5C4W
w7rmoK/uI/k8ipLgOD0fPysmCuyy6JcqTBTriw5wMoMevsuKksUUe3rjzSqL
6rZV00qp/iGtKjOwMsJPj0d1ylDmonFIb7laAb6c4y3FNNz7MPjpQud8vhw+
Nq1XgMRQ1YRsLyWLui6BOs+QZdnCo0eH4UMfY7Opldfs6+VQdZK0AXcaqwRW
h7c1Y6fSvF7UZO/BCxVpM3FLzLM7taScU4YNhC/YvNAcb3vO+xC5QOvEJoVP
O2GO8bwP0mxlhrdG9aEAWTI8mFtoS7EhWblpH9jxoRcFGQeC5OmijaDVNPZp
8bijRLSXHU7e2s9LYocoH4KA5kltNF+QqQPCK+Jp/ByRcPZF0SnQVpcbiW6w
s/LbS+vbEIheuJAWTgvqz73B5g8B9bw5f/0OyZKIVI85j0vSIjrvpNiZeRIt
boQ4siPD+nf+SpLWOo3psYbIrOQR5puGSX4sS5P3hBtogLNY890/WvDnXI75
bRCrc4uM5JG+0iRDPUx+sMF1WtJ3A/BDsTOd/hJ1wzG2KQnLebnpOUuc/vqp
DQ6WxS7H7/MVGeRDUTveaRWH9DMZm7SC5E+7BLRm6HSkxMZYVAbkA39xNDKI
1EeJ3Modn7PeE2echzZBOLywS1aPk7V/N6I+oJdIWIQuIiFLt2EdsWbrZiyY
2ipbv98KBHcfHeoViFKNiZCWTMsFoNxD/MC0homtXhpN1HAJk/7XlmSQhI3a
EdIPBQnhywX9pK0rzf76+fzyAJqxgIzN4VulT4KswWi8KDwjBwe3jK/7sQGa
+3tfDITQ7Af6qQ9X+V/KSQnaZA0tATx2VwX4xmYWhilBfOSBp60j/D4dQoyj
q4DupX+AI3qc37OqotcAcP14sY2rhLFrHAoctw7L/g/sTqwBMRnxCH4JUl1K
MyNigTOO0zEATMWgRvYxZi9VODpUWIBzfy9fcWqK5gsFKEuDKyLWBoMrUmbZ
xhvnbUD12ZR97V3PD65SWHlUPJ71lMScBiJZSQzVRvfpIqxo5KfTFU2wLFUs
Ed3NavCwCGkJ41vq7uYQDVPGAxJnsPPcF3cEhJR8nSzrTsQBbRkjMwEI9CMg
cTpi3mo7wFDNUH6kctwlHh8nbRbqk3OJGwcips/jIAMiar2wgzB2nH0U+u99
QofLabmt6nXFoR6rZEASsZgNwzhnLoJhA+pCDsghlNysCq5TbGWDJW2cYAUt
kYSHcU7Ai44Kr257IvSnpKyrWcqZSxwAoDfSMMgTNf5N63nt0jVEjIT4iqVd
E1oWgf0sFkxXeClrkZcEsuCbZzepn3Sy/0AIaIi4iyTSt1GWmrq9iU4KWu/E
Oo7FSVwlZgkjHu7l73jOoEwQ1oFMYpMwGNDnba6zTR/fiSkHqaMWbcPwVeiy
sZ7qqoZ0dW46keEaU/LuACR5of4dQgV5O+GuuIi3sHsHbK4LvzVLFwPkQDsb
C/bXOVLRTBNKYc1ZsXidKxoM4dyJOuPda5PVEjU1NPhdXd6JzdpbCrtNz5bM
Z1+SVwLnfIqeRZLbiikLPDCarsUAY9UtRYCBpaF26We3TDIItrDbUD0v7ksX
K6Dt1JAN5koLYP9ZhmxfOn5R37ppHE3uYt4DOukNDXsRleNImbIgi6U+B40f
dAQXasu4cUbhNjDjwnHmc8KCrNcppylUOYvixqS6jFD22SSmzso1n3AIJceb
TqYDseeMl6VaaZzZzEEbNNHdEgN71yntmqBPPhzGOllOUX2IP+pHwiiDsxbC
lhBnM/GjSYGb93hcuhRcZDbgF2kmj35DRlTHIUHmJ0i00IJDcwtOIPDO2wc8
y3k0Ex1+qLaGPfxFPQHMVU3JKXzbsXzMvu+vYTu/YddS//EgIdtqJQGOgksc
tI0dQizK42QLDbFHccV+LOETJxguUUz2zxXBytWCf7U334ybYrJHDF0sViXB
QSP2mUcvxJAHcbihhzYEFFlvgHOVsXkNzNXYuojR7pVJ8Ki3cSSskcyeowrN
pmj2BHmQNs6eP+tVeyA+1Ed7D3jY8FU/u5Noe0fzEMngtUKlqB5KIX3oPW74
VWDKc/L8j1JILUWHtNcYb1VNVD99b94SvCFg7A0gScz84h1P9WLMniNZ2CEz
UZScgl2FCb3i0mfk8oerlPWLB86uj91pnivCTBiFc1MXvJcqGM4paELKUoTF
yjk8V5BgPq/rOABpBF9+Lwln/+zN2eth8v7sXJLvDpjceIerSZQd3DN6MQ0p
pbXzpjEiV72yRSh46E8OYWtIKiyDcdoi3MbIFyBEEdQmBLakM0NiJNf+2CXw
XePdRRe3N078xqYRYFa3WjnRcfGX/zLH39XO3fMGvK4yzgYk3EySeeKyAHcp
j+uu4SPoQw4HysXgs6BMyp295VMS2CsH9/euKpr4gzbpv/05OT55lowLuBwS
rm/iJ9lNLgsSJzK7pAb/8+TJk+MXri6FS+s0CK3TY56KZJLsQGA7DAS+W20Q
ZKdZktohrCL9NfBdZ2SrLq3Z/ckNxqF7gQClNeciL4hPhVSjncFiy2fXCw0x
SN6K5G2FtYDHZRrsxvNyKkgckWRL75sOXdea4jHc9iQgAxue3BYOQyb7yF+t
QifIArELsGU0Eowm8A67cZpBVE2LZrHmrDLRW5qRa3cQ7BfEdMP3sT/e2m5M
CyErsgc2SIHBw5kkNhHsE+8SzQ7NAryjoVWRMc5K+GqCHCwxTkJ3ZYhawnSR
0O0upStMA+Fuh14Vd+gPYifLp9Fx9AS4QXbsQyLJ0Xj4a78ormGxv3X76eXZ
9eXb92fpJY8i/76yKa7WQw3LlKbon41Kb/uvDeJl/+qMvQn8nQmTUWsn6uSe
NWTtOOL/5Hw5DpNNbLAJ6ePKRYHLXpwjSMRxFfsPHRH85X2XayGQje0cTryr
vDXJibY6fiA4bOqnHwq/4LQFiUvo+zXrPXDueGz7kc/3If5xdngQfO2lti/L
jMOHKB+K6yXcrFqfksQ5hKUMbvOLwsoC2Yu8WHJ95qroEAV571MvOO7PElY9
WreF6FAvZ4fOUymgC9icfUazVdPLvek2S63X41oBxHk0dcZWNmpO99nqC5kh
EMevybCLc60UuDWo5qXNKZaeNH1OnO69HnXF+dQ2eIT9hVLKFiU83WEWM0KA
Ik1VeEwNQ+ogjgbcoQUXvjSQIVkYS9zL3Apgmu7RxEnpsjPFiq/wGEAYCKqr
San+xqCmBSRUNJNUcjqlO0jxdTtAyTLVMzNvl2VPJJwjg56rW0guSAWHJnvk
bJ1rjocFoAy9TXFnrcCH32tDdogD5Zzfp6Hc9VyW7YfclZBa6LHYFzjNGGOk
Iiqe4qOdMuNjLFQKQhsW1ar3Mx2q6MIBfDVsq0FOspZ9YYKnCqlDgBM9bIED
FXImRQTwstO0Z5BKw/4ZSmcKddfGsWxTkchjY10rNLj+Bj4wxAfbdmXiqHlg
IQ0GF1G0lc8mJLhYlMHb6vzLAYBhAeiILD5dGy8IT5mz59XTsbuhKmHHyMuX
nAcLuNaa6itd7v759ZXr/dKbv85S8o117qPB7nSfLV4RgRQPuM2AHno7LrzZ
nggJVGIMV0xl8ZaMCYR/V9QlZ5E5V1JQH6E67kcjs2s8KqAL4IvGul2oXbeh
N1oIBi2k2gkKuVHP9s/VVe9LvS18R6a7IH+0eUMkIaAv/tZqyogmJU/Ogg/G
UDsCJxjj1GlK7SEgKHor6hdo4W2C4VhgoDe2mUCDKTSFVeVW+fCP6ACQUeF/
1YuDBDv1IO55sIz+IZD18HSEER6ezb/8Jtazb8IsPoukECnSUpLQ2aLc1oou
tTggygPkos2+hZtpjiDRk3jDbBYDnP3My8h1diDiU/CuURJXL3Omuk15iTMZ
OdEjKAzG36HwFPJHkUa2YeRhIVgYbRdDRyPXnDA6/s3IxqnUKKRP1O/qVTTq
+76lAllzahY2r9pOiBij4f55lq3Qo2c2GlzaxC9XeUeIrLYdFKdGq1C53wH/
7Yde1q1L0aQxBsFcxsb71+olIQYEx61W5cQbxGe1+lucUDBubOkpBBVtlKTw
NuhOXkkltE1c8aZTtHipHEHKnseYPPqg0FZZRgpCkScUNoXAznDLEJK0ncsz
3Ro/GpYTi6sQDnHqQpbMVtwbSWh7WRM+3fDCBxy4LjqFPUay5WZcqOTqr4ci
K3mMoSaYr5YueY57nw0Il2Iz+SPkVQDRf+nEJXEmSWrKc3/NFosgi4Aw6Epi
2rnU0bHpHZS0sKOfQ5eoqmRUEYznisbH9vQ140uDImJXZ5UPc3YGBrnUPxTV
b2rge7TQcAeGVTO2ILDXl8xF1bVMnViBZsNNukjmAM9jzeHtDPePyvU3oh1j
XVFb6U9BGzcJabA08j2hmMDTeb10fZiGrg2Q68zk+wG5z0bJ/gWnhPqmhLR/
pGFSaWjIOfBEblkwLgJ9nP4r8b3TZ0+/fRsdsM+VBaVRWeDCdJbuxXr7iURa
1FTPVntykxyJtWJ1P6mgb+OmPEMl45+CMX6S5Em8lbWebcQcVhIAyGbtSmWD
9I9SZ9C6QKuANbpJ52Wd30ouJ8dunPkUGlcatRbMjPAfb1XwLppCHIxj2VtP
Aq9vXbHv1dYY2kI52onJRgmnsk3xWhDmwJYqBX6CwCYO8lN9HzPuRGDTZLVs
pPL5lGGPBX6HU61MhRx9Dkgn7EVFxlIdt4jJGvGxQ9Exh2sf+bg+wDuYI0vd
1u12qN6MawakDxaQR6GZ6I1tnhTEp1xaBKFezGFEqME5RlBP2/X3jiudOIPQ
BVG16DW0suzTKDCg/WDK8/oC0lNtAMSqg2YdEqlF92mWNwGwRsDBtoiTCDQH
1lBnhSCbpVFb4xvVQYWA9xPtwE9bZPyTdd96yBLFHqwQo/NB2ztnsb+/+ZWL
dXz1q3vXn0Kz0krQoe2Yh3QsIm7u3SYuYfeEFHSKC8QpYHqRJGowjUuzG5Kc
3CKs3xLBsSEzWD99zE1Zzo+3odc0TUFg1/a7fYVuUcaUcGAAIzl+J1Gq4Icg
oXafIpQxX2TMDnRiQtC2lAlxCZ8L68rx+ZSwjt93MC6iut8ehGJGQqdOTIai
RYx0jsgIo2G/S02LnzE08HFaSV5EKpo9D/uV+hm1KhWvq6TLByla5KFMs3bO
UhTNqBJbIpsle1sNPvZcDlr8JluUmUsHOrd8NchpGSMNqkizxVBxI028Quqz
7boRZ3TpSm1tPONF7YW1TRIM1JKzVuk803JkLb2Gi9BRRKD0OK6nE8vDHraT
VZDGlNkecYWLp/ASeq2UJjUBnIxLWZhAWLmkrFx20ImjeE+dvpGsOkoOXS+c
PiWFnVm8aNtVkAOuJDXQALHbCmtn+opYVQOMGV36Xu7geHW2A7k65xJ7xPiI
r7lyH54p9oyAYvHHqg1cZOq+mJiU4LuTfmFRYU87q7ls95PlxXc4LurcrHn7
TjRKvjHHNYFTUUjHiKXr2H6Aqg8WLbH9seEuiKH5ZcvzNAqBZuAN4Ol2X0fS
VZGfQCHaqmW9k5P5gLRCEFCjORrsosdx2QaYQO5oVGosGAl6d3ISPq1sCH+k
haxh50woEckOCxmBtZIPTbnAtMaYdq3i0qbHsVt5GKhv/7rGGUxqfwsJTFf0
ISS6NAFtyMRoJmzisCxeS8mQQhl5Bjkneb5aFoLoLHUw7Kk623tg4XKzg2Xy
wN4VZMliC8fxwcO6gIrnRrFtrDJ5JkIC2z/mUyKOgNg20tgikvWOjkW2NBBh
aiTw4uj1cnJi6dIb2KoXcesBUagXGaawBMeaQm2v9htTTRyiEfHKFfR5rzn3
zk0ZBsXTnStVbQ3iH5gHaAIN2/i10vbGpuWxQm/LGije+6al30tudHTWuWOW
AlKhok7GAN664herPiWV17K/Rdu7ZCni89as9mzt8HnA2XQALhU4lTCA76Yc
VfNwtHwtiTqC0e1jDHIUnrketsdHTNW3ryTJeYEeEyCD46Mj/bAl05xjQJU1
DIKGzh+v/wQv8sezTwLa/5S4hDFsRVmMG+7KJbjNGpRh02bJvubKkMsHPJDc
4saFNAFpiCylYssVlDHn5lLNEHbWJHGQc0uweikJINZvqhvmZsgB/szGwFwL
0bjZDfu7bMQtyupKXEeN1gsVOztp+loE2VaYbj+Ny/WpxpcQunzOVkiyzynM
qGJyZI90kKkn/ULikYlm0YU/+XNyfv7+j4lt6yfG+kHUgIgzY9iMFH+V7cYm
h8TJ+RO3hdO67uTeDutpcrIjrFR3HcxZl/W6NftUB5ufqDaeiMqii9oQS9yY
2YUUVN5JAaPkT9XskpPuDgvxQbbDUCawWxTV5x45O/8VN+N3dLTdzJ3fb3y3
MWEE51LxdoN3q6A+VZ0eKHeY2kLuIAmUZLE4h3kFVb3mvuWu2hN782YFsy9D
vGe2Kl2YJ6p4e3NzfZm8+ZCcEsuenByNnK/FLPAqONSd5hYN6JN5UWzfWkv7
+dPnyft3X5PL6/f8hYQM7GidTY9zdKoJaxpKu6FtxwVYZ0Vj9Z2rV2o156Ip
6gj5wevW81hBJ0CVNr5n1XaKtPT0Ry1PbgOpxLQ599pLAHVnm1BL+C3hNKkZ
x7jDbAS+DzS8UoP1o1KXdX0fjY7/MEyO/6Dy8Q/bhRy4YWPsyhtd9ztMudf3
ZpltyjoDkiqt5Wvbq7WRqcMTWVVe0HHWsJyMEIdAm2Du9F6a5D4IGajYNMTj
Z7bDimcIwuSi5Vpfp6tiwA827LlrbKfmf+N2A5ctxCh84wN9/m1S1v0oedX3
JAwG9gBR8pFJYfhYLPjtY7heNrrXF9w1Kdm/vlA5p7hUjDL7lPRWkqXqAxOt
Pduq47DtbcgO6Di9STeR1MdUPV2KkzgubUvYtOtU0WkFyPXFsyRNez2kAFH0
9c4NgKdEB34pFquFIxw65JOTE3EdCjVkNOjxCZ7nlKrQdPzeKE+Ovf+Rf4A6
bDky9eLvMHGkA2NrAWKP/ZP9m/rswBojKm2FcW2ptfjlca0K5iytjLWto/X8
uInd3+vh24bQSo6apWrn4j113O14y1XnU3WlyxAHdrinJJxt7EF0YOBQY1qN
dMBzavvJcSpzCuaKVAMhW2wB3Od6WxI4VcuxGGsWrjizZqOWi018fo14aQtO
WrLUrsTnZJtIPu94sBrUpRP7vB/7XSRdLSTMVP7u5BRhhNAwkE9gUFYG6bi2
OQ53B5X7ATrbGPSsCnMIjWuyEkjgnrzy9xRZ/0Ugc/BPr494M2NRZz27mtF/
nJKcI8lXinRak46o1xZasui3dr5c/tbVgd1KSJ9D0fxAV3fS2lIupDl9qjHn
NiHqlqrh4z/YK7FKL/yHai9YYCPxqA7up6X1K8dGf9BfxHnIeRX399s3b6FC
JeptxYE1pLQhT2idaef4uLYklr3w4QVKuH8UAsJxVaBEHLkXiVjrrKiyXAxX
V/tDEw/XY9tAa2pAkBMI6mZW4Fb7ckkVpy5wWrp6bW2Ksq0j59Ih7m4XQkHs
MeMnuFBdVs/adoGTAk1Lw+wCCr0MJ3o3h5somEo44CQ97XcfsNMeJZ9VZ7Um
aODc9vtCaSY3k8k0eZx6yrEnjbaqJGW3UlwkoS++BAd7jFZZTJqkTjZteEFM
QJaRHsWNFS40QALP1eg9JOcMUlDy3RShSWS2uSRMwmVKe5eC3Hyhi4V9oGMC
hprL6rWG3pOiBph38DsRLs24FTsGYCwkam2Ww7c/aT4iid6rXrrhljduMOh3
1ApeEIgnqVVq61zK9LeQlzqSHnydHccuKcyRtg3JMm06E3ru7EI+gStEaVip
Hwj6bb9OoCyKNi7Bs/0LhbCDRNBd6EdxtXUARUUjvkabfVns3tc0CdsVyzUw
D3DdltJzgjYc1DbTDG0A6cG571rBKsl4Nef0Y5mhQWzQZvFA5NVcLQS9Mc/2
LO0bBiKrbQvDPowp7BiqzdTeCM8juu2EbT69LHygsXBhDuNsrJPR4wSX8AU2
WWyN8Rmwu1Vq3wRVvC6kLePhhXvYfuSDGnrD4/7N6/dnhxf0fwejwQfO3mHV
uKMJukCQuaTCECYjUUqn0KlX35/IkHMjS9RjtHoFAgf/p1z+MOZWBz5CFtaK
TtEFzQWBo9SEfE78gDbUGTHSl9HgnF7g8XYb3MoS/1ANqKIRq3niNxdrEbeM
hqHLkrcopRmJW8P2ctz4XeMR4ppR7V2yFU1izWtLEnQobAt4izOY3QsR9Ne+
LZrBa5kPHkeSLOlZWc85eiFWOmSZnJWvxxaF6HEr2hDBAD8+eaYwFP7gfi0o
NEsqJhdStrnU5qb23dOFC7QNlj2DIsz+1ir4ya5G8rLfLTE5pxxhlMJ64McG
mpRsT5sdCoLY35MvvbjdI7I8c7kiODLbyVsFFsKdRFxmyfttPXKATuIkDvyv
cX//6BbBYZL5QLza4yfpYz+6phsv6mpZZmjA5593uS6+zvR5/EPxA+PH3zFa
L8Xf7kq0e5oweLbXFd8CFy/GVAQZ6Y2hv+xxdFH5TvBxW3scb1PMZoZ1Ju5q
CNwNztGusUMXvuwRebIveQBVjv5ePJum4crrDnKXV4D7BTQ6SiRjU2GdCmWl
D06LCnadfgmC50w/9VKipEpPus5hlLUeYDy+GoIdpoqvagmF49+SOae5Gpxe
EpainUnbYi/NA9+SWAP9rW53BZuJFUdmtEP5STNeZhr1U2Tcj1LLxghNF6V6
T7mHPNsN86DhnUPymfWzQADjhj4cKKNjZ2kPNRvAoSxB9bqpAczeBepjPasC
BKrYiphAvFh/z8Fw9yY98SwzjNwP3ObWucA4K8saMlt0+/jZ4eMnyjD7cq6H
9lAPyELCVWH09lTeDRdBYI0PBm/9VojgDfp+yk+GO3lTWvpzbE+60m97eRN2
beldjNbmC4CnbDT9WtRr323KnuZuNeHsHC1iC6g8uKREsipUJi2kehPUS8ZQ
aSsdW2RhQGfVk/C2rqxDAmGn3iW+0TF4B6mcnS/z3Y+kF08bkHRF3AOnok/4
aq3fpS06VlKBi5vNpt+L0ZP7R23xpUubrvsWnhzriLBda1/yCXNbqqcZRNaf
llHAzow0jJrAfBMA8wE7kZCNpphHzDq45BjsBGG7qFfwg3l5WgqlNDKKEf6F
9bluY/peqaVMgzXRlJjETUJ9SJL64CchARilPlZdmXWV+Yf4pi19yCJXDfXf
P6rGaVHjCE7ffvrE5O+bKH7IcFdY+gobjqf35VcHesP00tZ4oMu8tkHcKs6h
dWVQ5w1f8aitKItMFBGuzsWnIzsfeAtXRcnsBj2E1PVdqQhd3+fpIumrBqE/
qTyx985yambQoqGonA/FeXC983BID6tUHoOlmg138JAAarIhddfaRk94lCci
jwdNC0R7tp3kMv8RbcFwnatkXXJkzHZLX4QXtEuGUhDuxYWiLe4yQ5p/WbMO
ozO0V5yKo9pmFGlfKZcpj+bTvPYrNUbhiR1r63dXaBcEgq8ufBxSShbdgnSJ
2z0XzuJGmqZbLcO7Eu05c/CUB3Z3SoaZuluMgaEvK3WyobHARP+tnXWrSZqV
SIMPBJCbu79E2HYhD5NYPIQKL0dwVvkWtmMuISYRHK5e3n8T36m07WG7EIyA
kvXuVO66jv3jLmV15LcI9ZlSgwXmWcNZP+r8Dq8D1kKwKTcYbvmDT69/5Qbk
qMywsrA1s/jOFwDb1iw4TboxUfF9cBdQdB9SNCeJMKhjD8libDLainefHiNb
JKmokmfubXprcG4b9tISSBMIFTuNen56OUD10p9bpg/0PFLu+WWi/zyMHaMG
gUtLxF/CdYpORbo263A2ipNEz3vof+BrKh3cCi5/swBHnAECZmMX675cOiNr
YE7hvlY3fd+ym1EWImVcq2PbNnFrjEZdnepp6VGyu/nMi2QVnZKeuSWNudIo
JFNOS1BaHUY+vyizmiOfUyR3qEkYpYbRLxBqxH9hcPsdV01uMwXjy6zNxCUK
2osy9LR2Ku7D7bpwkRBI/txEUeLf73101CbQBn2pxb4werVzQIvf+oA0QOxB
bqZkZRl/Waz68ey9USxn+gmPkZfRTUrI518/4yDGUei9VZpgE2QCZmEeHys8
ft3Q5VC0LuPrR946NSd9SNHLxV0iIAwzdjaDJr6qShyNSM7JWpcYw6jH3WYr
6lMTjwLRRYcmr04VEaRABKmGo2h4G63UHdrhum17V9Y8OTpafA7Fh6ah0sE/
t98EAedPWyPigT2pQWxLsrr2kv3/Sk4Xn6XF9//93/+HvRf8Ff2BL49GR8dP
+AG+a8VdDMjsi4T/otWoYcLXtO62wrZv3zl5fnj87Ci5HS8Fh3FINgqNHw1P
nx2eDJ/4Z9AIzj6iRy3NmdrAzJM9//YNCHZtIRTRKSvihxTBLgnaK4bEX9EE
krfenGDpH8akCA1zwaNLELbg0Ai37GxB6QvEe72F9PpSruEIrmTOwulZ4a0Z
JVv+DTqj2t1pyJV49rJTWwoaZd3h/dbtvQVbpvH0whAG56Cud0QuktdB3jTa
nvB16YxmX/mEq/tHnGsth7tD7+m6OHXCqsAQCLk6b75eU3Kywl4PvnUbi7Ki
C/Y2uqEy2tstWGYT+LjryI69lvp+lTw9vBKCvv9/2MXpux1+iihE88PDkky9
PZczvx2DDJ7f883NSyPVK6acigcersElkdgKbfChUNFCuy4Jju/ZOhxVftsD
ciVMkPFYiEPMpwpK33mhkyWB0BK3mIgtLvXENWdAd85/5VxbjGFb797hd/Wr
D0fJRd/PxBeqakDDx1dbE+WV4xQ0zNv2XFXq5ue8AM3iET1hC9bhdNQIcs/J
5bKyd+p9mHsOP7JjgyNsBW+sC1Q6CyqsWdqRQ47UIPVHREVpln3GtlKV4yHw
7wZp41ZpI5VNPRwxKvWzxq8lcO1j2+yEp+mtmv6ivz9RJgPNWnOVGK0TGnug
NfuWPekb6cvA9v6EcjG/Pa2GPqVHJPJuovbMEvDYdiL5dPtIdAjJMTaAm0k9
PqF03bZi4wILTRbwtMu5T0fC3kPuDfL0SLSbmyPLJ0tEMqvHduOxwchc0dJU
DveiU97j/iDx70/7vx8lHzVVnH3mczG0bUphZMFyBUNIOxxGKEuU68qNNDxE
VNTCEfwe/TjpVLh+nWGRtBX4NiblImxbynJn5V3cUlC9DLY6IfM1Wi3hXFz8
GpZ88dOaOqQxBHvT3M6s9a3B9BL7MFcpgJdyFcmO3A91C6M6Ulr7sidrlLxa
dVFrO6mUCkZkZwbHJG3lV94U3HE4qvQLdWtQv4vPNN9MpiLJ2A/FCXKvh9w2
BPeTRfxL4N0oL3k5RdyK239FXRyGXtQA4e9bKwk21LeDwOOBr5zjGFbwWe8y
Usk4lXywXZdvWHgPt1d8mHWvL/xpkLfwWTj3NLW84JCdB4DA+Eq+0kSbv7dl
zjZf1lZHS/6Lb+pkBz7BFbxVkLuC1YU2PAxBv20uuSusk1OD2gbdJkMf5CQ+
Bb8PbC8LjA6+Pg1lt6kcF/RdU3oKhd4s8JDcfLg4lydAyzhWMRioPEwryEIf
7pwEZ75oqrmz7sMEIl4p2X1yxw+noNSSn9VI7Mp2FtuRGdU3x63jQj0wUbYn
iO/hTWS495BS0XRXm1nKG26LjkLxI1FCTj5GsFfvC+bikDbICiLKajUHLbCA
3FTczTwd7iAu+3lqRO+cmBtU8oqFk/obTESKh+7S4EtmBc3brzVk5XgvzOOz
KRfcO16dIfGWavM1YsNKskPZluwdf+dr5WtbZhRmsLo0CgQZ+9DNdcR3FKqR
8ai08kI332LJIN4qaRcLldJbIUyXycxFcS672o2o/BMM6M6plJYzGU+SRJa4
6FxAlAaMYqk+095qLjsZlBkLJ3kBZS+hkqyK/a2bDA80nv1vXx423LoxM+pY
JD3d1WZVGreFAdof0zokve91S4/tqv7kTvP+thweUVkcF4q6sh9YTohLZGWM
u2f+eiUtepCqRx8ZD9M/nUXAUt7d46GtwbwJ5wSubeATXAsW6SPGA6PEXZfO
FaWZ4OvgOuC1Ee0kpfiiu0sEf5Lw1hNefCCFVBG4K2aD6kEcdHTOxI6nfj8g
a1auQekDexaqT+xff0wcjqA8hnGRdb+jOY49ZUFdO+h2940vxY5mrxwv1ekw
8SYq+HeTrqg8SJ6gqanDzDAUbERJr2OwyBkmvyY6AMqH+3cW3qw+dItz6Ywq
GA2YsadYdq+zp+hEVEuqsK0dEPGrWcnBicgWfJ99s+huy0h3cV1EnN0aOutt
rhrfy7HPYoTldh91/ksTwhZzP8m6lgJk4f2wI8+B9UdxpZJNRBQVws0JJJM5
k8DS2HDLlNudjWp6XYlp818mKZgyia4dYiymaTr/PekbMEjd8iYMX6+BOCC6
cGKt7VrSmBQd2/bCDQs/DteyAKRX2cnT+o5FdTC8d1lxQ9ewh+//5AkFmapq
SZANfLfZ3e9mkCTJH4O5ZBHm0WwTN24UH1GvQA2vAPceibK1bOajJIhtJZyo
JYX0TDeFkKZ90XwvmiHV8LyUO2VVtPzuuS9pv04YlLmSj8bwvef2kHpXAOE2
A1uN0wfoetOsVqmUfAPWlI+LS907Wys99A4uX2MY9nuXi3R66N9Xsqvklht+
5SoC0sI87SC51t1UFvQ5oucnRd4FLT9o/afsHFbcO/deyKl2nvdXKA2TV9eX
w+TD5fWN2Mwfrq8vg8y5uplllbYgbf3FD4m7i0jX0iYu+4MY16wFYdq7r50u
++7VRzfWqcI9AR68PsRMot/Zjlx8fNFvgKPHnTRsd73N5cLH/u0kemfSKuQe
yJUbqEr4tbkmKrjGai0ss6qykNEtmwsfte7WBneEw96Vo/SltgyTfiVRSHmb
c6xXg9O/ELEJcPU2KkJiipYhBo0DiD7zW66GTT2BOtIsfLqzco1NXpEeBG1U
0N6/lodxgZIBtlVJgSU07s+Sd9i6DP0RksBMjhbVklYB2460PWtdEGpR6sZs
XYSpXKO5LNKSkmWk7ZUbclzwyn7f2rDD6Y5msV4D0/ou39xchLesSmsJXx27
84LFYb896DDp383je4VKnb/r7GTvKlV1FW4CEsyST9pbNt5V10/fdfP3ywn8
QWLJBL16IQjZwAgVvU+/lpPEJS47TrEg/Esn+IHksjx3luO2N5q8oKHB/Uvl
DDP5815V732zjXM7vlt5ndnKj4xMpqsCSSuT5FXWVFB2r9G1CHUI+IRmXQ6T
n/GP4jZ5RQ/OyGCgfb7ucM9alVxk6LNOz1zewVJKPhGv13fD5A04/sq0ed2U
2TB5j5eQltOXtTiqv5qWBMQ1bnw2X9O3RE9fh8l5mdHO3YDEuozGeYfKSPqg
zef11FSFdAk4n6PDV83N2z/XepGZpw12BkqwdbmSVoxpmnKaA/79/wC4IMnr
ULMAAA==

-->
</rfc>
