<?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-alta-00" 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>
        <email>krose@krose.org</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 the contributions of his colleague, Jake Holland, whose work with interdomain multicast live video delivery drove the need for a robust solution to the streaming authentication problem, and 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:
H4sIANfDI10AA7VbbXcbt3L+zl+Byh9iX5G0pThNotY91ZWU2L22pFrySXt6
2grcBUnUywXvYlcyYyl/qT+if6zPzAD7xpUsJ61yTswXLDCYeWbmmQE4mUxG
pS0zc6AO/Wa1MmVhE/XWeT+5dJkpdF6qw6pcmry0iS6ty0d6NivMNca/vTwc
pS7J9QpPp4Wel5OPhfNmorNST168GOEBs3DF5kCZT+vR6Imy6+JAlUXly/0X
L358sY+PdGH0gfrZ5Fgrw/sbV3xcFK5aH6jLs+Mz9Qve23yhfqbPRh/NBgPS
A/UmL02Rm3JyTOuORr7UefqfOnM5ZNkYP1rbA/VvpUvGyruiLMzc49VmRS/+
fTTS2JIrDkZqMlL4s7k/UDt/mar3EH+HP5Jd7fxlk5nWp65Y6Nz+yorAt4cf
9UpbdWmSZe4yt7AGq7zJk6mMNvgyO1CslH/k/08xwWiUu2KFKa7NwWhk83nz
jh56/9PR/t7ej/Wbly9+2Jc3pV0Z/9HcyDv5hC3305t/eXeisDVTmDwxCjOq
pbtRM53yQ9h4nijr+bmLy/eHHy5ftybRxcKUB2pZlmt/8Px5UmzWpZuSRjFR
OjVp9fy39cJlmXm+1mtT+Oekvuk6nfcFaSMFNruA3qHGVB3rUkPJCt+q88J4
ltLN1XsYza3UuU4+mpJRV89YW6j1JzY5X9rMrtdG/UwiPeKBU70wOfCp3rlU
p9WiqsekAOiBAhb3mmny3JXBvm8uzo7UqSkJk/gC+7Ae/jGrSuzpYuNLs1IX
JqkKW27wfrV23lar0WgymSg9w1CdAJon0OQss35JKtFRQ/QINKCVZyXRa0ij
F4Ve+aiqdUtVqyor7RpgLExiAJYCozw2+D//fW2yjdLJ0ppriFUu4SiLJT9f
eX4UJpusRcW68fHULmypM+XtItdlVRB0sTOlS7W0mCBxq3UlmsCoxPmScTVz
5VJBqpQkIJ3U8kzVpSVjn8zn2B42Gez/YDRRTy9PLt4ePiMXLA3walbrzG08
ps3YKbC3ZGn0WjWS684M47B31m4YtFHXVjP0Jynm2UAqRA5s2SeZ89jrWN0A
RUbpNKXnsBT0vFGlU9iJnUfhaH+WzYpBhflrZQuzwtJe4cvas6DxGBPUDGgx
Jm9ZieYgY4jOaAmY9ZrUA3UuTLGB3pYwJSJpRXNDE2Xh0iox/rEhWT2lWPyM
N5UsaxVqbCDZJBmeBqzWS4aR8R7u0NMhzJtiuafvDo/8MwRonfuVLQnlFFEX
3qaG0anWepM5nQIqNxY4KBAb8lQH1ZkcON+amkCeZVEhaT3FEMgTU5Qan691
SeHd02cwGJZjOeKiiyrTBYABUGPCbSBPOTdFg8FL3LCxyDQitB+QuhZUe+QQ
Go5/qxrcvQcQwoEciLHEsFkLAulUAsLKpinCFVLcm2Bgzqajw15EkHhAgGON
r/QG00FZSKEm9+IRJoYUbJ+Q3sDkMfatGM5wCE/Kn/glcjAU8SnJqjB/RDEi
H9RQlJzXsC+yV0S2+pi7G1ixhAFSqLhEcoQlYALD41h6AT9CissxLZKzQvjA
szTphlWlEwDdE3zoIQg1hX4eEf3GlOHgR8UYg60EQ8gAX/WWUDgziab418Ie
nHEF6oFlr01vXY9EQYuP1cJKJMmDuHP6fsWD9AyJp2Sos+tGZQNvRy73QBs0
nmGOPjRoUdhwpeFGTQQGH6mSZUs9rSixDMpuLbmWoFAvKg8mrsDuytYWbyx2
zFFsQyarZQEMT0O2GFPakYUIXuQ4AFiKnacVENzkIUEKxZEH8gZUDJIHz1yF
HWHV9xeHgIM6Sfe/+27vR0ksbKZEFwXQ9OUU01JGL8sEeCRaslvjLxDfOIWA
TwM3McQ3E33jeyuSe0cHAw9h7KZqtlFH5x8mCMPib2FeQNFRshh3vcBSkMJI
qDRFEoKBOEjBp9Ib+BU+TAkHlJkxRx09oqwyJ2+Rn8ssAi8GL4QQq3VVANIm
CE5D65nxzHPSFsdK2PoaZJMDMNM/6HdSkC8O2KsDT+Dij+Ttz58DR727o2wK
n/WMTUvBxUGc1RAluS+Zk/I5Y9NORc+ZCYaGe9KndaCFPknnOs0QHIm2SPYj
zxW2wxKU8A4xqtdWaAA7DmnQV7Paa5sEFd2V2AJ0LQ/r2uJT9UvAlSWW0srW
DfuI8XMAwGOKmHVm6qHcgMo00MIGn2YO1s82z1q5C2DIXPLRN+xkO31FQhNZ
FM31/vJS4jHpjQI/0Jdx6K/ApsntkMuJ2PD0iioNYONI3vQyZ4i2FKUKhA1Y
Q3Mq0JhJFyimbKzPEpfnYoIl/Ds6C4dgQiRzLaCrWbMjM3HoslqpF+r08hya
KjjEff4cS6G7uzHvCUa/gR8bWnVdWNIIDeaooLNKeAmQWRLPYtHBImBcnpai
JK1qeRhLjmhAPMRHck9AconLwNUciiVKYeyuZL/ciHPraweAwRs1GYdBxlCu
0RisnrKD9jQasxiomw244HlpqM5FKFQTpJYqh8p8h4BgYDJopyh3pIZWQmAW
HpptOjugPTP/Gp5MJyhhfSs8S5hYV0JFBMJ1pl4Yx6wTS2XZZpK2Sqec2Yil
mAl4lBRyYtSGLFJuPT06Pn1Gsen/mBt7VBOgLYN8MCgbIM5aPHCbX7K1B8j1
I2lYnzq3SCXREd4HAvcDZDhmiy/FdslwC5hJIhxpLu04GJufaQFtu3AIQKEe
qbM6gWaGGMyxgTiZLqBIQIfrbxYmFtZMEiMeUrLw58+h33B3N1VvaVEGCAO4
ydzumtEDaNduyEXI2hUlLU9Scj6maNw2D1mM7Hug3Oy/EGYmIiiNXbDjepdV
NNITHWnmrB07ZP+VK4ICED1I+TRxdLRQD4FYEiAKcV8iEUlYlfYMVZCCEFRX
0MiUeD5IIdV5vDp3D8zc5pbfE66ZcFK/CyXGzrsPF5c7Y/lXnZ7x6/cn//zh
zfuTY3p98frw7dv6RRxx8frsw1t8PwqvmiePzt69Ozk9lofxqep99O7wX3cE
SDtn55dvzk4P3+5IRWb9qHY3SpIAySxERSQNrgnhkPAjeLPY+M9H52rvpTAB
al2BCXz+/Dd488Pe9y/v7kY3QKSsxTRX3sKkm5AuOBKAtCZ6TWiWUsOD3iNP
mMKwLs9DIFNn1xTXzQ0KJ6rxKGZGYIhd2tUTsVimHEQWOeJIFGgYHJOvFqC4
JGlYBU3JtKUUHg4XrHlCXeAggTVeSw/D4ZixFNLeCr0X8l2wV+Lsqxkm98zC
F6xoKpJbUvDU7OEa+atgj5hkJl/QJ10PxyZJAxyQWCOhbA1282xGWgpoLiXm
EqnPTK2gcZPKtuemfJFDqRWncEqJzPAVZVvhUQ1f4cpjRkVLxrBpJyjEdS7Z
yc48RVtW3yg1ZKTaABVzo6FQOKBcYCIf1I/nTENar6P6r6Zw5Mzs+V9XPzNT
s0wC4ixUKm4F46k6IT6Hh6RKwINS/XbsFNogAtx20bId3GUWLn4cJ2pCb2ey
2pLNQ3NrMqxSgkYSeNcZN01mYgqS3/iphCPaHcRJsioVW2uqhs2gSqW0gTHg
a5EhU2pdmbHEhzl/LhyKn/qWZO+kA8THxKzLivjBuH5erLUCWaRGBKyLYied
gAfzMUBqC2GTW8m3C6imtC5lZ9Jslf3UqvdRkSIqtTsiJGKfotusilbirlGs
UQh7NH3TL/AxbMawIJZxFQM1Ptcq7juuQt91BIV9foJcoRbkteBqFZNj6YDC
3isiXeaT5n8bVZJQnbhHCGnr6put4oHsG/TiBRQxDD61k71nFIPgAXi9T6/D
NAej0W+//Qa0LQC6ThP+y3/T//fxu5P2X3i3e9/429Ftg5HdPXUrWrh9aHzn
feefx4236u8nQ3+7g+Nhh4Hxu2Gu29Z+dx/Y7209fkv27l9Lfa2ZR4MD6r9/
uI1+19Hll2w3NBXWepwFb1XPevzZsPXi2P5nQ0oYHvuAFQbG7vfGfo21vt5S
f8hOv8tKj7HRln0mw971WNvcZ5dBXQ+M+7YZt9vM96A9bptxW7J1p9+VGXpa
+XprTL7oNbe/y2tkJx1r7PetUY/pa7216XvGDGh3YMxLGbPbzHOv9m+bMfdq
Xsbs9rX+ezW//5Dmbx/S/MNP/e6vp+rB9Peor5GnhfCBSjkQXy6eGsbA9Ie7
ROZTaDUIr0+oTBemBOqnbSYFvjw5qesEUAiwu9HoJI/N7Tg5FfeGz067ZG1m
eJh0j7l6iNTS+lL6R8ww+ZQCQtHx6dDxYWFQTJuCOwpFqLe4lyGPxU5/aIPM
CxfOdfqV11MzXUzHGM+UM7Sssbr5RPLgI+kaY9G8Ws1M8YyWYwrckHqW8xNN
bInI8umBqdn+NuOCpGCfK64zpDe9pk6FIWI1UW/moQdC0/pSF6WnjjeXH9wG
zpN4Mg05wAKTMpy3EXXjtvI99QY/LbM3EKCjvZwpbHPa3+tik/x8aJQEgaWp
Gjqcwn7jpmsZuBTKuXc2UFJ4aQpQOd03U4+5fxNNSjLVdjw+/JmavC6xNeNu
7WuqXgO9el62jwz5zkwQGOv/ifuvsBgMPvcoK8kef5r2DdDSdpUDgFACncei
iMFGt5RJiqkV2j47Ckr8smbiicRas3LrjUV8BbFCbdgpCFk5DfkPtaicJpl0
qqiuoHcATG6ot1g2/hL9PppR85WCoJl+E7EjQqs8jSVMo/17lV9vp6v8rRNy
3S7g2kfh7ILJkjoFGMZ5rHAuNC76/ZGbJZ2rPVT66IESPKFealyK+ndNbVXI
2XI4/W/Lhbpv4uaTGTUG1XHsdA/1fOqzp3BrpYJoWWvD9fSd5v9UnTquG7kf
061xQ9DrHhaw9APNY69uTMZnObNw/B2qYcINK9b/HcPPbuG07thIHqCTBKCp
OZb2qH6zlML1XI62OiUvlsMSCLkAzcr+GivkgeNaOfDiLTzmZBOTxAaaCg00
0vtAn8sGfJCK7aq2ixS/W4YKjTv5hDqasm+dl7FP15yiS6/Es++G1MKHLZ9o
q/FiDZTy4fg8trNC7y+aEm/eXX6Id5bonIk0NC90I8Szbpv0mBO0x2dPZFvn
ggdukXX8gHQsJ2ak8bnLMndDs5sshLinsZkzM/jqGW2UbCaH5TafcM7lLHW4
pVamIhN1tg49+KQ0ZeczOuJu58zw5UVMsHQpaCkNGvLn/rNbECAperYiHTzp
y3YJ2Rgdw+1CUsUKKmTbmHAXSigIKW8ih2h02hSvdZHv2eaMb0x4arcc2aLS
VGqFg3qR8fDs7bPgjsO07w3G80Xu2K10nvP4cBqGB7k/Jdk78qMpK+VJbZgz
Ngx3cFLLsB2pF2pP7atv1Uv1nfpb9f1od9L7b3QLkyTl7cWtKvx1Kty9P4bI
5ucD9cTJShOGwCQsIvdGX+10xNi5E8vMbYFgyONjXnkoWku8qKSZ3m1lPr1i
Qa+etSOcVvMMz19dXAmNkSurcGW2Ec3GpCTz7sGMwB397qi5qwo+KCu4o21h
GkkRfLjDTXm2ywu+ldC6Sok5XSFAa+67BEsF/1Vv2Ev6ltr+29syoPpB/dj7
bDqdbpts8L925dYluV8xR8RCmGDCE/Sx0NkoYSFQr+6qCd/TfRydD8dacQa+
gRETrV+bxM4t33+ryfq9JD1QoCon8+OZv1ZwsZqVzO0nfBbCfzMxpdIBj4dh
fwlga4hPEbczHthzlVtERZIvJbHmVo6Q5DSHY3o8kW+dBnBQKCiqyxFNnrob
Pqum1HO1/x+nV3Ju5kBWr/CmkZtY1JDc6nJLMgY2lyXDVUmkE1vFSOuqabxS
GkWFg8jpSs7Hw3PknugLR+2M8Idc4UvgFdgHPirlOVGhLz4WkR4tG6C+0kmE
+Uno1NN0vPEumWfg52qIEo+biqFXVW6n9Iav1+7RK6HGtAbf2hKCrwK0Je7K
oUi4OCeEYBw4QqSRjPpIeiCU4CMeVgIFnk7E4UX14RVJzhfY1LzKk3ggV3/T
3Cas76x82Zl40bBVT/eCA3cKmonnItyw2DbK3V08KuFtj+lwcSEUC1qb7O3/
QHDc2/9ebjIGTs1NgU3oAdA7lBRZmCIcYj8iCMDKQ1Vn75qhXLZtFZbSM5Gr
3mQ6UrTj2lkiSCzKuD6PZVnLbxpAJBWKMPhoDxj9S61lPCHk7gSJvOlTQWw5
QTqT/ksqOvFIhkksD3WS4Atm965dmjNNPQ6p9aLmcg/xkWEXJH9tyoF7xkTn
bAYGn9ySIKSfq4tXe1cRSq7NZUMJP1RM2e5ZaiAUW94RL0Cxieiq03ZRM+gq
g9dvv8JhAitu5cpj5sqXgxkU211rQGHcbj7Q4W1Lom5KsHNufHxdfhUgXAjC
j1oNRXaTurnBOvtUts6M430UH07O7zskjjIykA38Ng3m6R33znvHrdFzegWm
ur+LGu7/ta7J1Afh0/3eUXjQ6pV+9e0Vg+Jq/eq7Kzr1pR92HaCYk2n4R12l
a65kCGTioqgUvalSRzmBq0FWFtTIh7Ly4z3S7zmyKf3mjOorUjLohHzrBRQU
hT3KvyQ+0fhmg7rOAHXWgti7ADGS4Gwdpsaz/aUOfe9nGrpLOKBzlDKZ2KJw
15buX3FsmbfKJvExuRrQl5F/4sBT8U/awnXExmEQpIliN9NKQzmU0HT9VJqw
7H48YxBYZIl5YC365B9fGbmYDeSVfLFWrjT3aCkbp/7h2LYJQPaLePPeZtkk
zE7NxZxsb33ZCtj8xBtpvwWixB9dFlUu7R7hSRh0eHq4tVz3giV1P3InIzXb
lyoQ/gEL3cVgVCWUjDKTcvPBI5RKBjTpq505KiETCzj5RR6w7ZfhzmT9pKnb
hHwnVALqXPEvBOhWoV5QrPkn/dGo13gPjY5Dw44vh7K7tC/qNpcKs+bGfn2n
NAV6TO9OLYjmjGqAeEGwzkj1BbJeeAq32aVjfkJ3hd7DLV2RaRatuZqa1sHN
FXFW/t1kDAfteyOTulC/90p8cO8qMDR6cqaBgfry43T0vyYgi8HGOwAA

-->

</rfc>

