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

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

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

<rfc docName="draft-krose-mboned-alta-01" category="exp">

  <front>
    <title abbrev="ALTA">Asymmetric Loss-Tolerant Authentication</title>

    <author initials="K." surname="Rose" fullname="Kyle Rose">
      <organization>Akamai Technologies, Inc.</organization>
      <address>
        <postal>
          <street>150 Broadway</street>
          <city>Cambridge, MA 02144</city>
          <country>United States of America</country>
        </postal>
        <email>krose@krose.org</email>
      </address>
    </author>
    <author initials="J." surname="Holland" fullname="Jake Holland">
      <organization>Akamai Technologies, Inc.</organization>
      <address>
        <postal>
          <street>150 Broadway</street>
          <city>Cambridge, MA 02144</city>
          <country>United States of America</country>
        </postal>
        <email>jakeholland.net@gmail.com</email>
      </address>
    </author>

    <date year="2019" month="July" day="08"/>

    
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>Establishing authenticity of a stream of datagrams in the presence of multiple receivers is naïvely achieved through the use of per-packet asymmetric digital signatures, but at high computational cost for both senders and receivers. Timed Efficient Stream Loss-Tolerant Authentication (TESLA) instead employs relatively cheap symmetric authentication, achieving asymmetry via time-delayed key disclosure, while adding latency to verification and imposing requirements on time synchronization between receivers and the sender to prevent forgery. This document introduces Asymmetric Loss-Tolerant Authentication (ALTA), which employs an acyclic graph of message authentication codes (MACs) transmitted alongside data payloads, with redundancy to enable authentication of all received payloads in the presence of certain patterns of loss, along with regularly paced digital signatures. ALTA requires no time synchronization and enables authentication of payloads as soon as sufficient authentication material has been received.</t>



    </abstract>


  </front>

  <middle>


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

<t>Authenticity of streaming data may be inexpensively established via symmetric message authentication codes (MACs) using keys pre-shared exclusively between two parties, as the receiver knows it did not originate the data and that only one other party has access to the key. In the presence of multiple receivers, however, this is not possible because all receivers must have access to the same key, giving any one of them the ability to forge messages. Consequently, authentication must be made asymmetric, such that only the sender has the ability to produce messages that correct receivers will verify as authentic.</t>

<t>Naïvely, a sender may sign individual datagrams using an asymmetric digital signature algorithm, such as RSA or Ed25519, but this carries high computational cost for both the sender and receivers. In the case of streaming video delivery, while the sender’s computational load may be dominated by CPU-intensive video encoding, the receiver is often a device with hardware dedicated to efficient video decoding and with limited general purpose computing hardware and/or battery available for high-rate digital signature authentication.</t>

<t>Timed Efficient Stream Loss-Tolerant Authentication (TESLA) <xref target="RFC4082"/> addresses this problem through the use of symmetric authentication by delaying the release of keying material to a deadline at which any packets protected by said key that are subsequently received must be discarded by a receiver. While this reintroduces asymmetry between sender and receiver, it requires the sender and each receiver to (loosely) synchronize clocks and imposes authentication latency relative to RTT and to a pre-declared upper bound on clock skew.</t>

<t>Clock synchronization is not as trivial as it appears: internet-connected hosts often have significant clock skew relative to stratum 0 NTP servers <xref target="timeskew"/>, and anyway enterprises serving valuable assets do not regard NTP as a reliable interdomain security protocol. Together with the need to avoid attacks that delay packets required for synchronization, this implies the need for an interactive unicast authenticated clock synchronization protocol, which is complicated by the need to maintain clock synchronization across both the stream publisher and multiple geographically-distributed nodes in a content delivery network (CDN).</t>

<t>This document introduces Asymmetric Loss-Tolerant Authentication (ALTA), which eschews time synchronization for an application of digital signatures to an acyclic graph of symmetric message authentication codes with redundancy sufficient to tolerate certain patterns of loss, and with digital signature authentication load greatly reduced relative to the naïve approach. This algorithm is based on research by Golle and Modadugu, as published in <xref target="STRAUTH"/>. Live multicast streaming over an unreliable transport is the intended application for ALTA: object-based integrity solutions or transport security may be more appropriate for unicast transmission or for static objects pulled on-demand.</t>

</section>
<section anchor="conventions-and-definitions" title="Conventions and Definitions">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t>

</section>
<section anchor="protocol-overview" title="Protocol Overview">

<t>ALTA is intended for streaming datagram use cases in which the receiving application has a deadline for the utility of received data and can tolerate a degree of random packet loss. It combines a segment of application data with a variable-length authentication tag into an ALTA payload to be sent as a unit in a single datagram, with the authentication tags constructed in such a way that a receiver will be able to authenticate nearly all such ALTA payloads received by the deadline under certain patterns of random packet loss.</t>

<t>An authentication tag is a combination of zero or more symmetric message authentication codes (MACs) and either zero or one digital signature. Each MAC is of another ALTA payload in the stream, while the digital signature is of the containing ALTA payload with the signature field itself replaced by all zeroes.</t>

<t>The MACs included in a given authentication tag are determined by a scheme, as defined in section 3 of <xref target="STRAUTH"/>. Conceptually, a scheme is a mostly backward-looking directed acyclic graph of ALTA payloads such that the MAC of a given payload is contained in two or more other payloads in the stream, enabling the loss of one of these to be tolerated without losing the ability to authenticate the given payload.</t>

<t>For purposes of illustration, a simple example scheme is one in which the ith ALTA payload’s authentication tag contains MACs for the (i-1)th and (i-2)th payload:</t>

<figure><artwork type="figure"><![CDATA[
                                              .
                                              .
                                              .
+-------------+------+                        |
| payload i+1 | MACs |                        |
|             |      |                        |
|             |   i <---------------------+   |
|             | i-1 <-----------------+   |   |
+---------+---+------+                |   |   |
          |                    +----------+---------+
          +------------------->| MAC of payload i+1 |
                               +--------------------+
+-------------+------+                |   |
| payload i   | MACs |                |   |
|             |      |                |   |
|             | i-1 <-----------------+   |
|             | i-2 <-------------+   |   |
+---------+---+------+            |   |   |
          |                    +--------+---------+
          +------------------->| MAC of payload i |
                               +------------------+
+-------------+------+            |   |
| payload i-1 | MACs |            |   |
|             |      |            |   |
|             | i-2 <-------------+   |
|             | i-3 <--------+    |   |
+---------+---+------+       |    |   |
          |                  | +----+-+-------------+
          +------------------->| MAC of payload i-1 |
                             | +--------------------+
+-------------+------+       |    |
| payload i-2 | MACs |       |    |
|             |      |       |    |
|             | i-3 <--------+    |
|             | i-4 <----+   |    |
+---------+---+------+   |   |    |
          |              |   | ++-+-----------------+
          +------------------->| MAC of payload i-2 |
                         |   | +--------------------+
                         |   |
                         |   |
                         .   .
                         .   .
                         .   .
]]></artwork></figure>

<t>The recommended scheme is more complex and will be covered in detail in <xref target="scheme-construction"/>.</t>

<t>Encoding a scheme relies on ALTA payloads being addressable deterministically by an index even in the presence of reordering or loss. This index may be deduced from the application data (e.g., making use of an existing sequence number) or by a payload index explicitly encoded in the authentication tag. Two modes are supported:</t>

<t><list style="symbols">
  <t>If the index starts at zero and increments by exactly one for each payload in the stream, and if the scheme is known to both sender and receiver, then indices are not required to be encoded for each MAC in an authentication tag as they can be deduced from a given payload’s index and from the DAG associated with the scheme. Hereafter, this is referred to as <spanx style="emph">implicit offset mode</spanx>.</t>
  <t>If the index increments unpredictably, or if the scheme is not known to the receiver, then each MAC in an authentication tag must be paired with the explicit index of the ALTA payload from which the MAC is computed. For compactness, this index will be encoded as an offset relative to the index of the containing payload. Hereafter this is referred to as <spanx style="emph">explicit offset mode</spanx>.</t>
</list></t>

<t>Authenticity of a payload is established by a chain of MACs rooted in an ALTA payload whose authentication tag contains a digital signature created by a key in which trust has been established out-of-band. Delivery of application data must be delayed until a payload has been authenticated. Note that a given payload may be authenticated by a digital signature as well as by one or more MAC chains; within authentication deadline constraints, receivers should prefer to authenticate by MAC, minimizing the computational load imposed by digital signature authentication.</t>

<t>The variable length of authentication tags in ALTA has implications for application data segmentation when constant-length datagrams are desired (e.g., to maximize data per UDP packet with a given path MTU while avoiding fragmentation).</t>

</section>
<section anchor="protocol-details" title="Protocol Details">

<section anchor="alta-payload" title="ALTA Payload">

<t>An ALTA payload comprises the following elements (defined below) concatenated in-order:</t>

<t><list style="symbols">
  <t>Authentication tag
  <list style="symbols">
      <t>Options octet</t>
      <t>Optional payload index</t>
      <t>Sequence of chained MACs</t>
      <t>Optional digital signature</t>
    </list></t>
  <t>Application data</t>
</list></t>

<section anchor="authentication-tag" title="Authentication Tag">

<t>The authentication tag is the metadata emitted by an ALTA-compliant sender that is required, in combination with other out-of-band metadata, by an ALTA-compliant receiver to authenticate a stream of packets in a manner tolerant to loss and reordering.</t>

<section anchor="options-octet" title="Options Octet">

<figure title="Options Octet" anchor="options-octet-diagram"><artwork type="diagram"><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|MACct|S| rsvd  |
+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>The first octet of the authentication tag contains the count of MACs included (<spanx style="verb">MACct</spanx>) as well as a flag <spanx style="verb">S</spanx> indicating whether the tag also contains a digital signature. It also contains four reserved bits which MUST be set to 0 by senders and ignored by receivers.</t>

</section>
<section anchor="payload-index" title="Payload Index">

<figure title="Payload Index" anchor="payload-index-diagram"><artwork type="diagram"><![CDATA[
 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|          payload index ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork></figure>

<t>If the payload index cannot be deduced from the application data in this payload, it must be specified explicitly in the authentication tag as an unsigned quantity of a fixed length specified by out-of-band metadata.</t>

<t>Whether explicit or deduced, the payload index uniquely identifies a single ALTA stream payload within a rollover window of size <spanx style="verb">2^N</spanx> for some <spanx style="verb">N</spanx> specified in out-of-band metadata. The payload index MUST start at zero and increment by one for each payload transmitted, with rollover to zero on overflow.</t>

</section>
<section anchor="chained-macs" title="Chained MACs">

<figure title="Example MAC with explicit index" anchor="explicit-index-mac"><artwork type="diagram"><![CDATA[
 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|    offset     | MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork></figure>

<t>In explicit offset mode, each MAC encoded in the payload comprises an offset from the payload’s index, expressed as a signed octet in two’s complement, followed by a fixed-length MAC. The length and semantics of the MAC are a function of the MAC algorithm, which is specified by out-of-band metadata. The offset space given in the example in <xref target="explicit-index-mac"/> is one octet, ranging from -128 to 127, but may be of any number of whole octets, as specified by out-of-band metadata.</t>

<t>In implicit offset mode, the receiver knows the scheme being employed and so can deduce the indices of the chained MACs from the current payload’s index. Consequently, the MACs are simply concatenated in ascending order of source index according to the scheme.</t>

</section>
</section>
</section>
<section anchor="digital-signature" title="Digital Signature">

<figure title="Digital Signature" anchor="signature"><artwork type="diagram"><![CDATA[
 0 1 2 3 4 5 6 ...
+-+-+-+-+-+-+-+-+-
|  signature ...
+-+-+-+-+-+-+-+-+-
]]></artwork></figure>

<t>If <spanx style="verb">S=1</spanx> in the options octet, then a digital signature is included in the tag. The length and content of this digital signature are a function of the signature algorithm, which is specified by out-of-band metadata.</t>

<section anchor="application-data" title="Application Data">

<t>The application data is opaque, with the exception of the payload index if not specified explicitly in the authentication tag.</t>

</section>
</section>
<section anchor="scheme-construction" title="Scheme Construction">

<t>In the ALTA context, a scheme describes the directed acyclic graph of payload MACs embedded in other payloads for purposes of chained authentication. The recommended scheme is that described in section 3.2 of <xref target="STRAUTH"/>, with <spanx style="verb">a=3</spanx> and <spanx style="verb">p=5</spanx>.</t>

<t>FIXME: Describe how to construct this scheme in pseudocode.</t>

</section>
</section>
<section anchor="alta-configuration" title="ALTA Configuration">

<section anchor="performance-considerations" title="Performance Considerations">

<section anchor="mac-selection" title="MAC selection">

</section>
<section anchor="digital-signature-selection" title="Digital signature selection">

</section>
</section>
<section anchor="out-of-band-metadata" title="Out-of-band Metadata">

</section>
</section>
<section anchor="operational-considerations" title="Operational Considerations">

<t>As ALTA requires an out-of-band channel for provisioning of metadata, including digital signature keys and cryptographic algorithms, versioning of the protocol to support a future ALTA revision may be performed there and acted upon by the application.</t>

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

<section anchor="parsing-an-ill-formed-or-inconsistent-payload" title="Parsing an ill-formed or inconsistent payload">

</section>
<section anchor="index-overflow" title="Index overflow">

</section>
<section anchor="truncated-macs" title="Truncated MACs">

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

<t>This document has no IANA actions.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>




    </references>

    <references title='Informative References'>





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



<reference  anchor="RFC4082" target='https://www.rfc-editor.org/info/rfc4082'>
<front>
<title>Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction</title>
<author initials='A.' surname='Perrig' fullname='A. Perrig'><organization /></author>
<author initials='D.' surname='Song' fullname='D. Song'><organization /></author>
<author initials='R.' surname='Canetti' fullname='R. Canetti'><organization /></author>
<author initials='J. D.' surname='Tygar' fullname='J. D. Tygar'><organization /></author>
<author initials='B.' surname='Briscoe' fullname='B. Briscoe'><organization /></author>
<date year='2005' month='June' />
<abstract><t>This document introduces Timed Efficient Stream Loss-tolerant Authentication (TESLA).  TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams.  TESLA requires no trust between receivers, uses low-cost operations per packet at both sender and receiver, can tolerate any level of loss without retransmissions, and requires no per-receiver state at the sender.  TESLA can protect receivers against denial of service attacks in certain circumstances.  Each receiver must be loosely time-synchronized with the source in order to verify messages, but otherwise receivers do not have to send any messages.  TESLA alone cannot support non-repudiation of the data source to third parties.</t><t>This informational document is intended to assist in writing standardizable and secure specifications for protocols based on TESLA in different contexts.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='4082'/>
<seriesInfo name='DOI' value='10.17487/RFC4082'/>
</reference>


<reference anchor="timeskew" >
  <front>
    <title>FIXME reference for how bad time sync is</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="STRAUTH" target="https://crypto.stanford.edu/~pgolle/papers/auth.pdf">
  <front>
    <title>Authenticating Streamed Data in the Presence of Random Packet Loss</title>
    <author initials="N." surname="Modadugu" fullname="Nagendra Modadugu">
      <organization></organization>
    </author>
    <date year="2001"/>
  </front>
<annotation>ISOC Network and Distributed System Security Symposium</annotation></reference>


    </references>


<section numbered="false" anchor="acknowledgments" title="Acknowledgments">

<t>The author wishes to acknowledge Eric Rescorla, who introduced the author to the paper describing the loss-tolerant symmetric authentication scheme used as the basis for ALTA.</t>

</section>


  </back>

<!-- ##markdown-source:
H4sIABjUI10AA81b7XIct3L9v0+BUD8sXe6sRFqObSZKXV6StnWvRDIiVU4q
lYTYGewuruZj72CG1FqkXykPkRfL6W5gvnZIUXZSFbrK2g8M0Og+3X26gY2i
aFLZKjUH6tBtssxUpY3Vm8K56LJITanzSh3W1crklY11ZYt8oufz0lxj/JvL
w0lSxLnO8HRS6kUVfSgLZ6JsXuQmiXRa6ejF3gTPmWVRbg6U+bieTJ4ouy4P
VFXWrtp/8eL7F/v4SJdGH6gfTY4lU7y/KcoPy7Ko1wfq8uz4TP2M9zZfqh/p
s8kHs8GA5EC9zitT5qaKjmn5ycRVOk/+U6dY/0BtjJus7YH6t6qIp8oVZVWa
hcOrTUYv/n0y0dhZUR5MVDRR+LO5O1A7f5mpd9jFDn8km9v5yyY1nU+Lcqlz
+wvrA98eftCZturSxKu8SIulNVjldR7PZLTDuqY6UHvfvFB/Kgud3OgNfxHb
Cko50tm8tMnSTNXbQ/Vif+/lS/m2qPOKtPY+t5VJ1EUFPTpVLNRhZmAlzaMM
Vk4PFCv+j/z/GaTr7+jPM/VTkaZQTW9Tf9YfTP+L/3/7+itkXImIM9j5j0v6
eBYX2WSSF2UGSa/NwWRi80X7jh5/98PR/t7e982bly++25c3lc2M+2Bu5J18
wvj/4fW/vD1RQIYpTR4bhRnVqrhRc53wQ8BNHivr+LmLy3eH7y9/6kyiyyUp
Y1VVa3fw/HlcbtZVMSNAYqJkZpL6+a/rJbZinq/12pTuOaFvtk4WQ0G6/gbI
X0DNMFiijnWlYVGFb9V5aRxLCbW9g3KKTJ3r+IOp2HebGRuAd/7E+ucrm9r1
2qgfSaRHPHCqlyaHl6u3RaKTelk3YxLY70DBlffaafK8qDyMXl+cHalTU5FL
4wvswwI5dl6z8TeuMpm6MHFdAjV4n60LZ2vYN4oipecYqmN49gk0OU+tW5FK
dNAQPQINaMaizug1pNHLUmcuqGrdUVVWp5Vdw5dLExuApcQohw3+939dm3Sj
dLyy5hpiVSvEmeWKn68dPwqTRWtRsW4jZWKXttKpcnaZ66ouyUOwM6UrtbKY
AEhd16IJjIoLVzGu5kW1UpAqIQlIJ408M3VpydgniwW2h016+z8Yk9XTy5OL
N4fPyN8rA7yabJ0WG4dpU3YK7C1eGb1WreS6N8PU75216wdt1LXVDP0owTwb
SIXAiy27OC0c9jpVN0CRUTpJ6DksBT1vVFUo7MQugnC0P8tmxaDS/K22pcmw
NHw+bz0LGg+hR82BFmPyjpVoDjKG6IyWgFmvST1Q59KUG+htBVMiH9U0NzRR
lUVSx4gsj0xs6illtGe8qXjVqFBjA/EmTvE0YLVeMYyMc3CHgQ5h3gTLPX17
eOSeIb/p3GW2IpRTQlo6mxhGp1rrTYpwCajcWOCgRGzIE+1VZ3LgfGtqAnma
BoUkzRRjII9NWWl8vtYVZUcOrTAYlmM5wqLLOtUlgAFQY8JtIM84wweDwUuK
cWORaURoNyJ1I6h2SME0HP/WDbgHDyCEAzkQY4Vh8w4EkpkEhMwmCcIVGMJr
b2DmJJPDQUSQeECAY41neoPpoCwwEJM78QgTQgq2T0hvYfIY+9YMZziEI+VH
bgUKA0V8jNPazx9QjMgHNZQVp0/si+wVkK0+5MUNrFjBAAlUXCEHwxIwgeFx
LL2AHyGlyDEtuI1C+MCzNOmGVaVjAN0RfOghCDWDfh4R/aaU4eBH5RSDrQRD
yABfdZZQODexpvjXwR6cMQNzw7LXZrCuQ6KgxadqaSWS5F7cBX2f8SA9R+Kp
GOrsukHZwNtRkTugDRpPMccQGrQobJhpuFEbgUHn6njVUU8nSqy8sjtLriUo
NIvKg3FRYndVZ4s3FjvmKLYhkzWyAIanPltMKe3IQgQvchwALMHOkxoIbvOQ
IIXiyAN5AyoGR4ZnZn5HWPXdxSHgoE6S/W++2fteEgubKdZlCTR9PsV0lDHI
Mh4esZbs1voLxDeFQsCngZsQ4tuJvnKDFcm9g4OBhzB2EzXfqKPz9xHCsPib
nxdQLChZTPteYClIYSRUmiAJwUAcpOBTIJVQTmISwgFlZszRRI8gq8zJW+Tn
UpsxtVxKPaHWdQlIGy84DW1mxjPPSVscK2Hra/BLDsBM/6DfqCRfHLFXD57A
xe/J258+eY56d0fZFD7rGJuWgksBcbIxSnJfMiflc8amnYqeU+MNDfekT5tA
C32SznWSIjgSbZHsR54rbIclqOAdYlSnrdAAdhzSoKvnjde2CSq4K7EF6Foe
1o3FZ+pnjytLLKWTrVv2EeLnCICnFDGbzDRAuQGVaaGFDT5NC1g/3Tzr5C6A
IS3iD65lJ9vpKxCawKJorneXlxKPSW8U+IG+lEN/DTZNbodcTsSGp1dUaQAb
R/JmkDl9tKUoVSJswBqaU4HGTLpE5WZDeRsXeS4mWMG/g7NwCCZEMtcCuto1
ezITh67qTL1Qp5fn0FTJIe7Tp1AK3d1NeU8wOko4+ChWXZeWNEKDOSrotBZe
AmRWxLNYdLAIGJenpShJq1oexpIjGhAPcYHcE5CKuEjB1QoUS5TC2F3JfrkR
59bXBQAGb9RkHAYZQ7lBo7d6wg460GjIYqBu1uOC56WhOhehUE2QWuocKnM9
AoKB8aidgtyBGloJgal/aL7p7YD2zPxrfDIdo0h3nfAsYWJdCxURCDeZemkK
Zp1YKk03UdIpnXJmI5ZiJuBRUcgJURuySLn19Oj49BnFpv9lbuxQTYC2jPJB
r2yAOO3wwG1+ydYeIdePpGFD6twhlURHeB8I3A+Q4ZAtPhfbJcMtYSaJcKS5
pOdgbH6mBbTtskAA8vVIk9UJNHPEYI4NxMl0CUUCOlx/szChsGaSGPCQkIU/
ffL9hru7mXpDizJAGMBt5i6uGT2AduOGXISsi7Ki5UlKzscUjbvmIYuRfQ9U
Mf8rwkwkgtLYJTuuK9KaRjqiI+2cjWP77J8VpVcAogcpnyYOjubrIRBLAkQp
7kskIvar0p6hClIQgmpGHR/i+SCFVOfx6tw9MAubW35PuGbCSe1ClBg7b99f
XO5M5V91esav35388/vX706O6fXFT4dv3jQvwoiLn87ev8H3E/+qffLo7O3b
k9NjeRifqsFHbw//dUeAtHN2fvn67PTwzY5UZNZNGnejJAmQzH1URNLgmhAO
CT+CN4uN/3R0rvZeChOg1hWYwKdPf4c33+19+/LubnIDRMpaTHPlLUy68emC
IwFIa6zXhGYpNRzoPfKEKQ3r8twHMnV2TXHd3KBwohqPYmYAhtilWz0Ri2XK
QWSRI45EgZbBMfnqAIpLkpZV0JRMWyrh4XDBhic0BQ4SWOu19DAcjhlLKe0t
33sh3wV7Jc6ezTG5Yxa+ZEVTkdyRgqdmD9fIXyV7RJSafEmf9D0cmyQNcEBi
jfiy1dvNsRlpKaC5kphLpD41jYKmbSrbnpvyRQ6l1pzCKSUyw1eUbYVHtXyF
K485FS0pw6aboBDXuWQnO/MUXVldq1SfkRoD1MyNxkLhiHKBiXxUP44zDWm9
ieq/mLIgZ2bP/7L6mZmaZRIQZqFScSsYz9QJ8Tk8JFUCHpTqt2cn3wYR4HaL
lu3gLrNw8VNwoib09iZrLNk+tLAmxSoVaCSBd51y02QupiD5jZtJOKLdQZw4
rROxtaZq2IyqVEobGAO+FhgypdbMTCU+LPhz4VD81Nckey8dID7GZl3VxA+m
zfNirQxkkRoRsC6KnSQCD+ZTlMSWwia3km8fUG1pXcnOpNkq+2lU74IiRVRq
dwRIhD5Fv1kVrMRdo1CjEPZo+rZf4ELYDGFBLFPUDNTwXKe477kKfdcTFPb5
AXL5WpDXgqvVTI6lAwp7Z0S6zEfN/7aqJKF6cY8Q0tXVV1vFA9nX68UJKEIY
fGqjvWcUg+ABeL1Pr/00B5PJr7/+CrQtAbpeE/7zf7P/8/G7UffPv9u9b/zt
5LbFyO6euhUt3D40vve+98/jxlv1j9HY3+7oeNhhZPyun+u2s9/dB/Z724zf
kr3/11FfZ+bJ6IDm759ug9/1dPk5241NhbUeZ8FbNbAefzZuvTB2+NmYEsbH
PmCFkbH7g7FfYq0vt9TvstNvstJjbLRln2jcux5rm/vsMqrrkXFft+N22/ke
tMdtO25Ltv70uzLDQCtfbo3os15z+5u8RnbSs8b+0BrNmKHWO5u+Z8yIdkfG
vJQxu+0892r/th1zr+ZlzO5Q679V8/sPaf72Ic0//NRv/nqmHkx/j/oaeVoI
H6hUAeLLxVPLGJj+cJfIfPStBuH1MZXpwpRA/bRNpcCXJ6OmTgCFALubTE7y
0NwOk1Nxb/jstE/W5oaHSfeYq4dALa2rpH/EDJNPKSAUHZ+OHR+WBsW0Kbmj
UPp6i3sZ8ljo9Ps2yKIs/LnOsPJ6ambL2RTjmXL6ljVWNx9JHnwkXWMsmtfZ
3JTPaDmmwC2pZzk/0sSWiCyfHpiG7W8zLkgK9plxnSG96TV1KgwRq0i9Xvge
CE3rKl1WjjreXH5wGziPw8k05AALjCt/3kbUjdvK99Qb/LTM3kKAjvZyprDt
af+gi03y86FR7AWWpqrvcAr7DZtuZOBSKOfe2UhJ4aQpQOX00EwD5v5VMCnJ
1Njx+PBHavIWsW0Yd2dfM/UT0KsXVffIkO/MeIGx/h+4/wqLweALh7KS7PGH
2dAAHW3XOQAIJdB5LIoYbHRLmaSYRqHdsyOvxM9rJpxIrDUrt9lYwJcXy9eG
vYKQldOSf1+LymmSSWaK6gp6B8DkhnqLVesvwe+DGTVfKfCaGTYReyJ0ytNQ
wrTav1f5zXb6yt86IdfdAq57FM4uGK+oU4BhnMfKovCNi2F/5GZF52oPlT56
pASPqZcalqL+XVtblXK27E//u3Kh7ouKRTSnxqA6Dp3usZ5Pc/bkb63UEC3t
bLiZvtf8n6nTgutG7sf0a1wf9PqHBSz9SPPYqRuT8lnO3B9/+2qYcMOKdf/A
8LNbOG06NpIH6CQBaGqPpR2q3zShcL2Qo61eyYvlsARCLkCT2V9ChTxyXCsH
XryFx5xsYpLQQFO+gUZ6H+lzWY8PUrHNGrtI8btlKN+4k0+ooyn71nkV+nTt
Kbr0Shz7rk8tfNjykbYaLtZAKe+Pz0M7y/f+ginx5u3l+3Bnic6ZSEOLUrdC
POu3SY85QTt89kS2dS544BZZzw9Ix3JiRhpfFGla3NDsJvUh7mlo5swNvnpG
GyWbyWG5zSPOuZylDrfUylQkUmdr34OPK1P1PqMj7m7O9F9ehARLl4JW0qAh
fx4+uwUBkmJgK9LBk6Fsl5CN0THeLiRVZFAh28b4u1BCQUh5kRyi0WlTuNZF
vmfbM74p4anbcmSLSlOpEw6aRabjs3fPgnsO0703GM4XuWOX6Tzn8f40DA9y
f0qyd+BHM1bKk8YwZ2wY7uAklmE7US/UntpXX6uX6hv19+rbyW40+G9yC5PE
1e3FrSrddSLcfTiGyOanA/WkkJUihkDkF5F7o692emLs3IllFrZEMOTxIa88
FK0lXtTSTO+3Mp9esaBXz7oRTqtFiuevLq6ExsiVVbgy24hmY1KSuuLBjMAd
/f6oRVGXfFBWckfbwjSSIvhwh5vybJcXfCuhc5UScxalAK297+It5f1XvWYv
GVpq+29vy4DqO/X94LPZbLZtstH/upVbn+R+wRwBC36CiCcYYqG3UcKCp179
VWO+p/s4Ou+PtcIMfAMjJFq3NrFdWL7/1pD1e0m6p0B1TubHM3+r4WINK1nY
j/jMh/92YkqlIx4Pw/7swdYSnzJsZzqy5zq3iIokX0JiLawcIclpDsf0cCLf
OQ3goFBSVJcjmjwpbvismlLP1f5/nF7JuVkBsnqFN63cxKLG5FaXW5IxsLks
Ga9KAp3YKkY6V03DldIgKhxETldyPh5eIPcEXzjqZoTf5QqfA6/A3vNRKc+J
Cn32sYD0YFkP9UzHAeYnvlNP0/HG+2SegZ+rMUo8bSuGQVW5ndJbvt64x6CE
mtIafGtLCL7y0Ja4K4ci/uKcEIKp5wiBRjLqA+mBUIKPcFgJFDg6EYcXNYdX
JDlfYFOLOo/DgVzzTXubsLmz8nln4kX9Vh3dC/bcyWsmnItww2LbKHd34aiE
tz2lw8WlUCxoLdrb/47guLf/rdxk9JyamwIb3wOgdygpUj+FP8R+RBCAlceq
zsE1Q7ls2ykspWciV73JdKTogmtniSChKOP6PJRlHb9pARHXKMLgowNgDC+1
VuGEkLsTJPJmSAWx5RjpTPoviejEIRnGoTzUcYwvmN0X3dKcaeqxT60XDZd7
iI+MuyD5a1sO3DMmOGc70PvklgQ+/VxdvNq7ClAqulzWl/BjxZTtn6V6QrHl
HeECFJuIrjptFzWjrjJ6/fYLHMaz4k6uPGaufDmaQbHdtQYUpt3mAx3ediTq
pwS74MbHl+VXAcKFIPyo01BkN2maG6yzj1XnzDjcR3H+5Py+Q+IgIwPZwG8T
b57Bce9icNwaPGdQYKr7u6j+/l/nmkxzED7bHxyFe61e6VdfXzEortavvrmi
U1/6YdcBijmZhn/UVRXtlQyBTFgUlaIzdVJQTuBqkJUFNfKhrPwEkvR7jmxK
vzmj+oqUDDoh3zoBBUVhh/IvDk+0vtmirjdAnXUg9tZDjCQ4W/up8exwqUM3
+JmG7hMO6BylTCq2KItrS/evOLYsOmWT+JhcDRjKyD9x4Kn4J23+OmLrMAjS
RLHbaaWh7Etoun4qTVh2P57RCyyyhDywFn3yj6+MXMwG8iq+WCtXmge0lI3T
/HBs2wQg+2W4eW/TNPKzU3MxJ9tbV3UCNj/xWtpvnijxR5dlnUu7R3gSBh2e
Hm4t179gSd2PvJCRmu1LFQj/gIXuYjCqYkpGqUm4+eAQSiUDmuTVzgKVkAkF
nPwiD9h2K39nsnnSqBO6bfMOwC7KVFPkKtrLnUkTHooyZAr+5WFwqO7Ni6gp
de+9VO4dpPYch56ca2ixuT44m/wPLfA1Tk48AAA=

-->

</rfc>

