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

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

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="o-*+"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>

<rfc ipr="trust200902" docName="draft-sheffer-cfrg-pake-review-00" category="info">

  <front>
    <title abbrev="Sheffer PAKE Review">Review of the CFRG PAKE Proposals</title>

    <author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
      <organization>Intuit</organization>
      <address>
        <email>yaronf.ietf@gmail.com</email>
      </address>
    </author>

    <date year="2019" month="October" day="31"/>

    <area>Security</area>
    <workgroup>Crypto Forum Research Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This draft consists of the author’s review of the password-authenticated key exchange (PAKE) protocols, as submitted to the IRTF’s CFRG. All opinions here are the author’s alone.</t>



    </abstract>


  </front>

  <middle>


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

<t>The CFRG took upon itself to review multiple proposed PAKE algorithms and select zero or more of them as suitable for general use in IETF protocols. Eight protocols were submitted for consideration, and they are listed on the CFRG GitHub repository: https://github.com/cfrg/pake-selection.</t>

<t>Over the last few months multiple reviews were submitted to the CFRG, evaluating the protocols’ cryptographic quality as well as their engineering properties. As the last stage of this process, members of the CFRG Crypto Review Panel were asked to provide summary reviews, and this document is the author’s contribution as a Panel member.</t>

<section anchor="disclaimer" title="Disclaimer">

<t>The author is not a cryptographer. Specifically, I do not have the skills to prove security of such protocols, nor even to evaluate the quality of such proofs. I do, however, possess a reasonable amount of experience in integrating cryptography into protocols, including PAKE-based algorithms <xref target="RFC6124"/> <xref target="RFC6631"/>.</t>

</section>
<section anchor="conventions-used-in-this-document" title="Conventions used in this document">

<t>This is essentially an opinion piece and does not employ any normative language.</t>

</section>
</section>
<section anchor="preliminaries" title="Preliminaries">

<t>Before diving into the individual protocols, I would like to get two important points out of the way.</t>

<section anchor="protocol-completeness-and-clarity" title="Protocol Completeness and Clarity">

<t>CFRG has published in the past some protocols in enough detail that they can be implemented by a non-expert developer. A good example is <xref target="RFC7748"/>. Of the eight PAKE submissions, in my opinion only one  comes close to this level of rigor. Whatever protocols are selected, CFRG must make it clear that such selection is conditional on the algorithms being republished in a detailed format. CFRG must not leave this task to the IETF working groups, because that would both duplicate work and introduce a major risk of inadvertent errors that invariably manifest themselves as vulnerabilities.</t>

<t>Ironically, I can quote the abstract of one of the submissions to support this position: “We observe that the original SPEKE specification is subtly different from those defined in the ISO/IEC 11770-4 and IEEE 1363.2 standards. We show that those differences have critical security implications by presenting two new attacks on SPEKE: an impersonation attack and a key-malleability attack.” In other words, an under-specified protocol resulted in two different standards, both of them vulnerable. This is ironic because the paper from which this is quoted is not itself a rigorous description of the protocol that it attempts to fix.</t>

<t>I would propose that each of the selected protocols be published as an RFC, containing:</t>

<t><list style="symbols">
  <t>A detailed description of the protocol, to a level that can be implemented by developers who are not security experts.</t>
  <t>Test vectors to ensure interoperability.</t>
  <t>Recommendations on integrating with higher-level protocols: supported identity fields and recommendations on how they should be protected, session ID and “exporter” integration, secure capability and parameter negotiation, conditions on whether and how “optional” protocol exchanges can be eliminated.</t>
  <t>Mandated auxiliary primitives, such as hash-to-curve and memory-hard iterated hashing.</t>
</list></t>

</section>
<section anchor="integration-into-existing-protocols" title="Integration into Existing Protocols">

<t>The IPsec/IKE community has always been interested in PAKE as a component, both for remote access and for peer-to-peer VPN deployments. This to me justifies the selection of both a balanced and an augmented PAKE, assuming good candidates exist. It also means that the integration of such protocols into IKEv2 is relatively straightforward.</t>

<t>On the other hand, the TLS community has been less receptive to PAKE solutions, and as a result, the properties required from the protocol for proper integration are not as clear. It is possible that the most common deployment will be a combination of TLS, PAKE and OAuth. Arguably we should take the combination into account when defining the PAKE portion of the protocol, and resist the temptation to only consider the narrow integration of a PAKE protocol into TLS 1.3.</t>

</section>
</section>
<section anchor="detailed-review" title="Detailed Review">

<t>As mentioned above, I believe we should select one balanced and one augmented PAKE protocol.</t>

<section anchor="balanced-algorithms" title="Balanced Algorithms">

<section anchor="spake2" title="SPAKE2">

<t>This protocol is the best documented of all the candidates. On the down side, it relies on a set of parameters that present a high value target for factorization once a quantum computer is available to an adversary, and that would break all instances of this protocol.</t>

</section>
<section anchor="j-pake" title="J-PAKE">

<t>This algorithm is an outlier in its complexity, which also implies a significant performance penalty. For this reason I don’t think it would be a realistic selection.</t>

</section>
<section anchor="speke" title="SPEKE">

<t>SPEKE has been around for a long time, which is an advantage. But the quoted paper describes several attacks on concrete specifications/implementations, and Karthik’s review casts doubts about the validity of the security proof presented for this protocol. As far as I can tell, the mailing list discussion has not fully clarified which exact version of the protocol is proposed and which published security proof applies to it. Specifically, does <xref target="Hao2018"/> apply?</t>

</section>
<section anchor="cpace" title="CPace">
<t>CPace is not specified as a stand-alone protocol, but rather needs to be extracted out of the AuCPace specification. Moreover, it adds a mandatory (though trivial) message round to establish a session ID. This extra round may or may not be subsumed by the higher-level protocol. Having said that, it comes with an actual security proof and no magic parameters.</t>

</section>
</section>
<section anchor="augmented-algorithms" title="Augmented Algorithms">

<section anchor="opaque" title="OPAQUE">

<t>OPAQUE is described as a generic framework, with two instantiations, and will have to be narrowed down when standardized. The protocol is secure against pre-computation attacks. This is a good thing of course, however I am not sure how serious this attack is in practice: while servers are often breached with attackers gaining bulk access to hashed passwords, I don’t think it is common for attackers to record multiple salt exchanges and use them in a follow-on attack. OPAQUE comes with a security proof. OPAQUE is well documented, with a separate draft <xref target="I-D.sullivan-tls-opaque"/> on its integration into TLS.</t>

</section>
<section anchor="aucpace" title="AuCPace">

<t>The protocol has two versions, the main paper and Appendix C (“Strong AuCPace”), which is resistant to pre-computation attacks. It is unclear which one is nominated.</t>

</section>
<section anchor="vtbpeke" title="VTBPEKE">

<t>This 2017 paper extends SPEKE into a balanced PEKE that can be proven even for elliptic curves, and then again into a verifier-based (i.e., augmented) PAKE named VTBPEKE. It has a few “magic” constants which are potentially of concern - I didn’t see any mention of how they should be generated.</t>

</section>
<section anchor="bspake" title="BSPAKE">

<t>This protocol is somewhat loosely specified, with no security proof (or even security justification/intuition) provided. So it is hard to be convinced of its fit for purpose.</t>

</section>
</section>
</section>
<section anchor="conclusions" title="Conclusions">

<t>As noted, I think the Research Group should recommend one balanced and one augmented algorithm.</t>

<t>Before presenting my conclusions, I would like to clarify my view about quantum resistance in this context. Steve Thomas defines “quantum annoying” as: an attacker with a quantum computer needs to solve a DLP per password guess. IMO this is too high of a bar, and once we get to the point where this is a real risk we will need to migrate to PQC for these protocols. However I think that even now, a protocol where a single DLP solve would break <spanx style="emph">all</spanx> instances of the protocol, is too risky to adopt.</t>

<t>Of the balanced algorithms, I would recommend CPace. I think the extra round trip is a reasonable price to pay for a formally proven protocol. To me the potential quantum vulnerability of the SPAKE2 parameters is a showstopper.</t>

<t>Of the augmented algorithms, I will follow the Mozilla report and recommend OPAQUE, which appears to be the best fit into TLS, and is also a good fit into IKEv2.</t>

</section>


  </middle>

  <back>


    <references title='Informative References'>



<reference anchor="Hao2018" >
  <front>
    <title>Analyzing and Patching SPEKE in ISO/IEC</title>
    <author initials="F." surname="Hao" fullname="Feng Hao">
      <organization></organization>
    </author>
    <author initials="R." surname="Metere" fullname="Roberto Metere">
      <organization></organization>
    </author>
    <author initials="S." surname="Shahandashti" fullname="Siamak F. Shahandashti">
      <organization></organization>
    </author>
    <author initials="C." surname="Dong" fullname="Changyu Dong">
      <organization></organization>
    </author>
    <date year="2018" month="November"/>
  </front>
  <seriesInfo name="IEEE Transactions on Information Forensics and Security" value="Vol. 13, pp. 2844-2855"/>
  <seriesInfo name="DOI" value="10.1109/tifs.2018.2832984"/>
</reference>



<reference  anchor="RFC6124" target='https://www.rfc-editor.org/info/rfc6124'>
<front>
<title>An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol</title>
<author initials='Y.' surname='Sheffer' fullname='Y. Sheffer'><organization /></author>
<author initials='G.' surname='Zorn' fullname='G. Zorn'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<author initials='S.' surname='Fluhrer' fullname='S. Fluhrer'><organization /></author>
<date year='2011' month='February' />
<abstract><t>The Extensible Authentication Protocol (EAP) describes a framework that allows the use of multiple authentication mechanisms.  This document defines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted Key Exchange (EKE) protocol.  This method provides mutual authentication through the use of a short, easy to remember password.  Compared with other common authentication methods, EAP-EKE is not susceptible to dictionary attacks.  Neither does it require the availability of public-key certificates.   This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='6124'/>
<seriesInfo name='DOI' value='10.17487/RFC6124'/>
</reference>



<reference  anchor="RFC6631" target='https://www.rfc-editor.org/info/rfc6631'>
<front>
<title>Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2)</title>
<author initials='D.' surname='Kuegler' fullname='D. Kuegler'><organization /></author>
<author initials='Y.' surname='Sheffer' fullname='Y. Sheffer'><organization /></author>
<date year='2012' month='June' />
<abstract><t>The Internet Key Exchange protocol version 2 (IKEv2) does not allow secure peer authentication when using short credential strings, i.e., passwords.  Several proposals have been made to integrate password-authentication protocols into IKE.  This document provides an adaptation of Password Authenticated Connection Establishment (PACE) to the setting of IKEv2 and demonstrates the advantages of this integration.  This document defines an Experimental Protocol for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='6631'/>
<seriesInfo name='DOI' value='10.17487/RFC6631'/>
</reference>



<reference  anchor="RFC7748" target='https://www.rfc-editor.org/info/rfc7748'>
<front>
<title>Elliptic Curves for Security</title>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></author>
<author initials='M.' surname='Hamburg' fullname='M. Hamburg'><organization /></author>
<author initials='S.' surname='Turner' fullname='S. Turner'><organization /></author>
<date year='2016' month='January' />
<abstract><t>This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS).  These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t></abstract>
</front>
<seriesInfo name='RFC' value='7748'/>
<seriesInfo name='DOI' value='10.17487/RFC7748'/>
</reference>



<reference anchor="I-D.sullivan-tls-opaque">
<front>
<title>Usage of OPAQUE with TLS 1.3</title>

<author initials='N' surname='Sullivan' fullname='Nick Sullivan'>
    <organization />
</author>

<author initials='H' surname='Krawczyk' fullname='Hugo Krawczyk'>
    <organization />
</author>

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

<author initials='R' surname='Barnes' fullname='Richard Barnes'>
    <organization />
</author>

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

<abstract><t>This document describes two mechanisms for enabling the use of the OPAQUE password-authenticated key exchange in TLS 1.3.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-sullivan-tls-opaque-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-sullivan-tls-opaque-00.txt' />
</reference>




    </references>


<section anchor="document-history" title="Document History">

<section anchor="draft-sheffer-cfrg-pake-review-00" title="draft-sheffer-cfrg-pake-review-00">

<t><list style="symbols">
  <t>Initial version.</t>
</list></t>

</section>
</section>


  </back>

<!-- ##markdown-source:
H4sIAJElu10AA4Va0XLbRrJ951dMyQ+xvSRlyak40UuuLMuxdjfXWtt3t/bp
1hAYkrMCMMgMQJpx5d/vOd0DEJS9d6vsyAIHMz3dp0+fbmaxWMw631Xuynxw
O+/2JqxNt3Xm5u2HX8z99V9uzX0MbUi2SrOZXa2i212Zj1u3Xruon+t7szIU
ja2xTxntulskXbIo1nGzaO2DW0RZt3jxYlbYzm1CPFwZ36zDbObbeGW62Kfu
8sWLn15czmx0Fqe4oo++O8z2IT5sYujbK3MTD20XzNsQ+xonJ2djsTW/8MPZ
gztgZXll7prOxcZ1izc0ZTZLnW3K/7VVaGDewaVZ669mxsR14crUHar81Jgu
FJN/+qZ0TTc8SCF20a3T+PuhPvm1i74YFxehrvHu+KlvKt8cj3Gfu0XlE7x0
qFehwrKweP4nfa+1x21Svzp5MrN9tw0Rxi/wKbfFq/9cDvGQZxqEf9oYmpPn
IW5s43+3nQ+NuKj3nXzgausr7M831kvvuvV/bfhoiaNnDFCs8dLOXc1k+Tsb
Ll9c/Hhl3ry/W168WF5cvPjpvPPrtOTj5eWPLy9/+vH72WyxWBi7gltg/Wz2
aeuTIgN3bBLungak6Z2+SyaeALC1KTGcC34OX3qipjQIsnGfi61tNs48JQCf
mTYGhAt+nBub6LTad1wLoHCnuw+f3mJ7InpprqvKhNY38EIyWxdxPv6e2CFA
WeoNal+WlZvNntBjMZR9Qf/xPjlFuhAeTN/C2b5Lrlrz0HyRuq8631aO9iGD
YJDki62Afd9ta5zUlAYvuaIzv7sYECNTB5ijLqj1Nr6zK2yCOJiNa1y0lemT
Q+zN3e2nt8fLL82t32y74wOz5/WO7uAO4vwSm/AaczEAJx3ECUQkluEqIwH8
4rt3/QoXgv2+k5Tddl2brs7PN7hCvyJIzpnj55LjehlsDfe934EhuFNlU2fW
dEhoum06+kX99JWdOWw0YG7czlY9rG02iorhct+ZQqhgE2279YX5rbcVuIIu
2zvEGD+x3kfjmg1Sz0XuwEC42HkHZ12no3EgiE32OmCKVYVLAFPt6pWL6YQS
MwFlsry3javUfpse1Ha8voOLcaG6tvEw3HJwNvMgFD3pwfh0ijxEBzSy6ulB
3sDmA9QQ+PTJE/PGp6KyvkZaCwr1ZW7VhA5vTNyCV8zH1hV+jeSpqsPc3OFs
Wbe1O0V9evAVoJLtxu+ZdHnp1INbJ8nV4By3cw1X57joJoPzJ+8EEIIcNzfb
sMdbcW4AogTHwkjwewqN4NrWoYcr8Kr7jOB41xQCbg8S30SN/OROB34Qplb5
pqj6ksuYXouVZaZNkuzLl58/vL354eLy+z/+GH754eXFH3+oP29CsyO9kA96
vuqb0yhl8sIf2M6VdCWCOdCIab2DyYxuGZyGwdVtFbjoQKcpfwJqzaYH0Hgu
qqqrfO0bixuD2F+7NRO/9DteRK5Ix6IE4UkJ905vfGf2oa9KJOyDYyw2rjPd
PhhftyhSFt5sA7YAcPtuAO/eHvS+93kfXBxGug6UkpSJbior5XYmQN8Cf22/
AilsB6cIKSNbQj1JRH7kmtBvtqZ0HeoGFtpOWaWAl1aOdlWOrsRGK3gFPmkW
Eu0O7+xcxaxERppNCCVgYLmeDtdovXr1/Y+IlnmvN3HCckKlwhkpMXbEgakP
Y1BCgyCBx6WmIipFBQZWasHGFU+la6IHTpbmHzCZGJ1ci4yodObKueZ+DYVi
avAcuB4bQnvoXQXzI/XRcCRy6fkLApf5dILIlWOQQapT99rsPiVqQGY5OZSY
wnmSsyQNkM1Y3VgEqJC4p6gk+GLlCssiIeYpWFahQ4T6tpJCKm9I1H2ua7AQ
d/sXUjx67A7fAJwlfNKRqVyMISbdzzc7AAXJe8ALjV+7JOGu4YEdPA3c7PqK
hWrlwQok29nsDuLiSELExW99yOwxqASeyYhlxE6Cy7umviW6M0WzHImQOfsH
XlglF3duBB7qqAfpw/cf728Jk4EDh/Bg6w7Wl57qiNdbx1DjTUKkdGvUixHx
dx/fn9/d3piLi1evXiy+F5fd3d7emouXP7xcXhrRljaWYDtYksB1gxmyWT4B
9UQptwAE6IcjzzI5smmJ2dFGJyzDgoecblBlbNfZ4iERSXKhK7IP3kNtAsK0
WMgSsc5SIy1q+NppBA750+UZRIwBDIBzKispSaaHyo2L7CLce8gA4DOhUGdP
wJKjt8Y7zxVVg1wZwl65pRk400vgJ4AkicBydfkepXurIcUfgUQ5lLKsp6zm
aOjByC7Bf61ceFCJg7WKzI5XBfl2Apm1/0zo5QTIKkxXOltsR6DlLJ8kP0jr
mJwsxI0BEc2lQFsQTLOBGn4Oxhpz9v+xbU5bbOYcOf3bvDhSISTMNggB0Q8j
UpQxkU3PzSfm3A5WS1KiGjepj05qpkicHHgu/eC0GSkzxMJpad2DkswWlAoQ
qIWjF66GnGNM2ArRCGCkKrVexK93VviD+ZEIQjrqhUyiLP70z90bef8MF+Lu
8exoEUWpXBipYtsRv1jd2ojOBquREpuAKqyLR6aV8/dbJ/DmC7TlLLTKwmdH
pAzdQxrCkAsxTKS/fiW2eWXbf8bpVHBtxAKWcABeuN4ym9N20YUFTN1p8YdI
g0BebJEYACIlNjbhMrhZS+/d8ZZa4m8/Q3KLchl8rpru7h4+OL8DddHDfUMf
sB7bCmWc6HQaRKRoTlDtLCit2DCCRZsuJydVf4RpIFtbFEOt59MWqphX4E/z
9/v/BgCpWqRxzQkMG1Hr/4USRHJIk3TJOJcjrFlZiJuCTiMBgY76TcY1DWNb
BjUsBYoVHn4vPZ0MSUUPQCgicavEw2yTjjw+gcXXelRdCCftLkkZ0FMis8Dr
LCcUCbjkHtFgL6JkrtyH6AOM/P3TXz8+8rC4tqKXgG7Xim7DKao2QiXKPEt5
q0KWJDkf8j13F3j8W+8jS7kWlglRiedl5cn1hmy3SZWF+EQrXfLUyaNT6pA6
sRpvHSOGREbXs3KKgJVvRq/hkvOMD1j9/hr9ArRWhBRlBd+7IVc7ChseMH1f
fAzciEZHdjVaH4d2TLZlEn+T9pQk2OzLB0LMui02FYE2tKPyObRwRM4+CrrN
hwz+E4sYuIvlS1HSbwYKzoOoGTq7WhU9AblCV0PNsUKag98mF86dNyXHCX75
4BTA4+max6+H1dejpuPzJ6jOWHyZG4ajxZo3K3L20FSwz8bdqko9PiYEVK5C
tQz7xtA3c1Y1NgtOGM7CbFFKIx/mfMm6AQvI5obtGVxuI5sDYm5tWS3yAAg7
ieBD49Z0fS2k0ZNbYavdwZ3SmjH0OJEiMIEHhw72KCnRxj3IJXxDTUCVM2mi
jx57Yv68oGuyZ0YpLMc1bFNwvShdX5fEmArE0OFEFQjCDSKUqC/hlk0jeo6d
josil3mf1oHpUfU4HlQrtM+UPrT5TrRj80B/7ofqJK0oBx/QKNPhhUbzliar
hhzJwUKKZAJFTQ9MBDTjg6V6IbgMtrHVM6/7LrfIom1U+6hYACBw5k4mOhOJ
h5woIgJ7KlvT+agW7ISE/mIjLvVwnJ4VlqO1MkDhJoI/Hw84+DK36EriWVRI
qz6AJw+JTgPISckarQ4coMq9c1WljMcxIamADoQ+TEWvBZ7OIpmte7bKBftK
0ZbqIzR4BdVLTN8Scnq0zst4Q33nqMYeWW5bRQWw6rvH4w7px798ySNLtP9c
ffhZw3tzbws3k/8OkvOogoXcRecuZBw4YbUVXAp62ooScaUcTRXxWZoYJvax
677udf+TUC7Nr+j1g4xEqFhL6im2UmAAKAjzFL0D2+kuove31TOwWUocUCny
KPcSZ4Lwh9DBIKpyzRZD8traHmSoaA9yv5V0VSjFKjhp4Tel39K8szKISNZr
xoul2kmLYiTIi66fNjI5Hji1QSG3G2TUkaOUOK9HVn3MnO/vr//2P0g2/cl4
DDmSYyGjT2y55o5sXudqiMw9hH2yJMyJIeVQp1wSHi0uFOokVqlkQxvjf4fy
M58egTCrULux3J4ZslCWnDZc6djoWNU2pJgNw4+SGZMbp1/IHVsryLgtxSma
Vs+2RtItN3Be5iktkeQLd0X0V8zWyHQRkRDWaMiFegumg0ZDXuaKjXYnAGn1
MOg9OIAyVNhHZ+pp/jUlytRCRIVQ27ijzLMLvHSc2yaw7ERG0925t6t1krEO
VRX2i9FNyxzfEwQ9Qs64xucJ7rFUzo9vEFGgRv0m4cuXn+8Wb5ZQYJUH4S66
Ki1Ca3/rHVJdJ/InamKQDpnfc3Kq5B5DT+4iqDI/pZHpmkzevO51i1pT+s/m
xjw9+9hFloG83dmzSS1Q9cM6JTPLfwMhVXp9oyMlfZmcI6w0tiZi898/vdaq
JLADq73KViHrYVHKEw+VbUdZIw+nracMexud5jLecDib18JIPzMOq1nvCKlh
QziF/BjzlPWpX7rl/CiWnqla4ldQ5WCqXE+aF/kO4EyY4UyUHx2ThhIPaLeh
G+erkkGwPTZmQbD6kmhNzslQNes7rvpGy6lfkxyd9vrjRHyc5DjguKdXqoB6
w85hKAAZcmCyR/z2dJiBj89zd6Tcfu7lizX869nwRQC45WPIGSbNoRISbgeK
LVQIEqlrr0Kt7SOrn2jbm8DhtuBQdG0TJB3uctoSmadfgg5eGHvz/yRvRy22
HIfQkwlULRJ9MOHrybOW9gPXifpQwTGoygH9OtAXmuMABVCFSzhvBXmG2qY8
c0vmbHjTNk04wIAzkL9MuwY+GpjgK+E6lmJ0aWzIzZu/3lMcjpxnNj3IEGj8
9f04cOpCULUsfcbKxnn2UCF9gszVdcoqA3WWjejGt1U76rgUq6Xi0Azpmv1G
iIq9499usqqCW6df170bK8MQTQ6miK0m7GHJEap6LoVvswH/8mp6zakOf468
ef5YiU+FS74w7T2Iti9D27E51oVHkIy1+RjwI56E5JYnEJwqDoiWdnTO8B1P
i8otvmghRFQ5i2hnomcmOkqPTzJzUKdnPhjDPR0sj1pWu65pQyTncxabutC2
8s3Z++HL5q+Ar7dk8LRsybpfw+94YuWbz9idjrtyoRqbE5xg4yADx06P6TwU
HIWVdD4pDEphXCAjjPx98wool6Z2+IrwHTIIolDk03/+Pytm4MrGi8ty/VrO
/g/WdoSC4yEAAA==

-->

</rfc>

