draft-camwinget-tls-use-cases.xml

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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5246 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC8446 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
<!ENTITY I-D.green-tls-static-dh-in-tls13 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.green-tls-static-dh-in-tls13.xml">
<!ENTITY I-D.ietf-tls-sni-encryption SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-sni-encryption.xml">
<!ENTITY RFC5077 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5077.xml">
]>


<rfc ipr="trust200902" docName="draft-camwinget-tls-use-cases-03" category="info">

  <front>
    <title abbrev="I-D">TLS 1.3 Impact on Network-Based Security</title>

    <author initials="F." surname="Andreasen" fullname="Flemming Andreasen">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>111 Wood Avenue South</street>
          <city>Iselin</city>
          <region>NJ</region>
          <code>08830</code>
          <country>USA</country>
        </postal>
        <email>fandreas@cisco.com</email>
      </address>
    </author>
    <author initials="N." surname="Cam-Winget" fullname="Nancy Cam-Winget">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>3550 Cisco Way</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95134</code>
          <country>USA</country>
        </postal>
        <email>ncamwing@cisco.com</email>
      </address>
    </author>
    <author initials="E." surname="Wang" fullname="Eric Wang">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>3550 Cisco Way</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95134</code>
          <country>USA</country>
        </postal>
        <email>ejwang@cisco.com</email>
      </address>
    </author>

    <date year="2018" month="December"/>

    
    
    

    <abstract>


<t>Network-based security solutions are used by enterprises, public sector, and cloud service providers today in order to both complement and augment host-based security solutions. TLS 1.3 introduces several changes to TLS 1.2 with a goal to improve the overall security and privacy provided by TLS. However some of these changes have a negative impact on network-based security solutions. While this may be viewed as a feature, there are several real-life use case scenarios that are not easily solved without such network-based security solutions. In this document, we identify the TLS 1.3 changes that may impact network-based security solutions and provide a set of use case scenarios that are not easily solved without such solutions.</t>



    </abstract>


  </front>

  <middle>


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

<t>Enterprises, public sector, and cloud service providers need to defend their information systems from attacks originating from both inside and outside their networks. Protection and detection are typically done both on end hosts and in the network. Host agents have deep visibility on the devices where they are installed, whereas the network has broader visibility and provides homogenous security controls across heterogenous endpoints, covering devices for which no host monitoring is available (which is common today and is increasingly so in the Internet of Things). This helps protect against unauthorized devices installed by insiders, and provides a fallback in case the infection of a host disables its security agent. Because of these advantages, network-based security mechanisms are widely used. In fact, regulatory standards such as NERC CIP <xref target="NERCCIP"/> place strong requirements about network perimeter security and its ability to have visibility to provide security information to the security management and control systems. At the same time, the privacy of employees, customers, and other users must be respected by minimizing the collection of personal data and controlling access to what data is collected. These imperatives hold for both end host and network based security monitoring.</t>

<t>Network-based security solutions such as Firewalls (FW) and Intrusion Prevention Systems (IPS) rely on network traffic inspection to implement perimeter-based security policies. Depending on the security functions required, these middleboxes can either be deployed as traffic monitoring devices or active in-line devices. A traffic monitoring middlebox may for example perform vulnerability detection, intrusion detection, crypto audit, compliance monitoring, etc. An active in-line middlebox may for example prevent malware download, block known malicious URLs, enforce use of strong ciphers, stop data exfiltration, etc. A significant portion of such security policies require clear-text traffic inspection above Layer 4, which becomes problematic when traffic is encrypted with Transport Layer Security (TLS) <xref target="RFC5246"/>. Today, network-based security solutions typically address this problem by becoming a man-in-the-middle (MITM) for the TLS session according to one of the following two scenarios:</t>

<t><list style="numbers">
  <t>Outbound Session, where the TLS session originates from a client inside the perimeter towards an entity on the outside</t>
  <t>Inbound Session, where the TLS session originates from a client outside the perimeter towards an entity on the inside</t>
</list></t>

<t>For the outbound session scenario, MITM is enabled by generating a local root certificate and an accompanying (local) public/private key pair. The local root certificate is installed on the inside entities for which TLS traffic is to be inspected, and the network security device(s) store a copy of the private key. During the TLS handshake, the network security device (hereafter referred to as a middlebox) makes a policy decision on the current TLS session. The policy decision could be pass-through, decrypt, deny, etc. On a “decrypt” policy action, the middlebox becomes a TLS proxy for this TLS session. It modifies the certificate provided by the (outside) server and (re)signs it with the private key from the local root certificate. From here on, the middlebox has visibility into further exchanges between the client and server which enables it to decrypt and inspect subsequent network traffic. Alternatively, based on policy, the middlebox may allow the current session to pass through if the session starts in monitoring mode, and then decrypt the next session from the same client.</t>

<t>For the inbound session scenario, the TLS proxy on the middlebox is configured with a copy of the local servers’ certificate(s) and corresponding private key(s). Based on the server certificate presented, the TLS proxy determines the corresponding private key, which again enables the middlebox to gain visibility into further exchanges between the client and server and hence decrypt subsequent network traffic.</t>

<t>To date, there are a number of use case scenarios that rely on the above capabilities when used with TLS 1.2 <xref target="RFC5246"/> or earlier. TLS 1.3 <xref target="RFC8446"/> introduces several changes which prevent a number of these use case scenarios from being satisfied with the types of TLS proxy based capabilities that exist today.</t>

<t>It has been noted, that currently deployed TLS proxies on middleboxes may reduce the security of the TLS connection itself due to a combination of poor implementation and configuration, and they may compromise privacy when decrypting a TLS session. As such, it has been argued that preventing TLS proxies from working should be viewed as a feature of TLS 1.3 and that the proper way of solving these issues is to rely on endpoint (client and server) based solutions instead. We believe this is an overly constrained view of the problem that ignores a number of important real-life use case scenarios that improve the overall security posture. We also note that current endpoint-based TLS proxies suffer from many of the same security issues as the network-based TLS proxies do <xref target="HTTPSintercept"/>.</t>

<t>The purpose of this document is to provide a representative set of <spanx style="emph">network based security</spanx> use case scenarios that are impacted by TLS 1.3. For each use case scenario, we highlight the specific aspect(s) of TLS 1.3 that may make the use case problematic with a TLS proxy based solution.</t>

<t>It should be noted that this document addresses only <spanx style="emph">security</spanx> use cases with a focus on identifying the problematic ones. The document does not offer specific solutions to these as the goal is to stimulate further discussion and explore possible solutions subsequently.</t>

<section anchor="requirements-notation" title="Requirements notation">

<t>In this document, the key words “MUST”, “MUST NOT”, “REQUIRED”,
“SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”,
and “OPTIONAL” are to be interpreted as described in BCP 14, RFC 2119
<xref target="RFC2119"/>.</t>

</section>
</section>
<section anchor="tls-13-change-impact-overview" title="TLS 1.3 Change Impact Overview">


<t>To improve its overall security and privacy, TLS 1.3 introduces several changes to TLS 1.2; in doing so, some of the changes present a negative impact on network based security. In this section, we describe those TLS 1.3 changes and briefly outline some scenario impacts. We divide the changes into two groups; those that impact inbound sessions and those that impact outbound sessions.</t>

<section anchor="inbound-session-change-impacts" title="Inbound Session Change Impacts">

<section anchor="removal-of-static-rsa-and-diffie-hellman-cipher-suites" title="Removal of Static RSA and Diffie-Hellman Cipher Suites">
<t>TLS 1.2 supports static RSA and Diffie-Hellman cipher suites, which enables the server’s private key to be shared with server-side middleboxes. TLS 1.3 has removed support for these cipher suites in favor of ephemeral mode Diffie-Hellman in order to provide perfect forward secrecy (PFS). As a result of this, it is no longer possible for a server to share a key with the middlebox a priori, which in turn implies that the middlebox cannot gain access to the TLS session data.</t>

<t>Example scenarios that are impacted by this include network monitoring, troubleshooting, compliance, etc.</t>

<t>For further details (and a suggested solution), please refer to <xref target="I-D.green-tls-static-dh-in-tls13"/>.</t>

</section>
</section>
<section anchor="outbound-session-change-impacts" title="Outbound Session Change Impacts">

<section anchor="encrypted-server-certificate" title="Encrypted Server Certificate">
<t>In TLS, the ClientHello message is sent to the server’s transport address (IP and port). The ClientHello message may include the Server Name Indication (SNI) to specify the hostname the client wishes to contact. This is useful when multiple “virtual servers” are hosted on a given transport address (IP and port). It also provides information about the domain the client is attempting to reach.</t>

<t>The server replies with a ServerHello message, which contains the selected connection parameters, followed by a Certificate message, which contains the server’s certificate and hence its identity.</t>

<t>Note that even <spanx style="emph">if</spanx> the SNI is provided by the client, there is no guarantee that the actual server responding is the one indicated in the SNI from the client. SNI alone does not provide reliable information about the server that the client attempts to reach.</t>

<t>In TLS 1.2, the ClientHello, ServerHello and Certificate messages are all sent in clear-text, however in TLS 1.3, the Certificate message is encrypted thereby hiding the server identity from any intermediary.</t>

<t>Example scenarios that are impacted by this involve selective network security policies on the server, such as whitelists or blacklists based on security intelligence, regulatory requirements, categories (e.g. financial services), etc. An added challenge is that some of these scenarios require the middlebox to perform decryption and inspection, whereas other scenarios require the middlebox to <spanx style="emph">not</spanx> perform decryption or inspection. The middlebox is not able to make the policy decisions without actively engaging in the TLS session from the beginning of the handshake.</t>

<t>While conformant clients can generate the SNI and check that the server certificate contains a name matching the SNI; some enterprises also require a level of validation.  Thus, from a network infrastructure perspective,  policies to validate SNI against the Server Certificate can not be validated in TLS 1.3 as the Server certificate is now obscured to the middlebox.  This is an example where the network infrastructure is using one measure to protect the enterprise from non-conformant (e.g. evasive) clients and a conformant server.  As a general practice, security functions conduct cross checks and consistency checks wherever possible to mitigate imperfect or malicious implementations; even if they are deemed redundant with fully conformant implementations.</t>


</section>
<section anchor="resumption-and-pre-shared-key" title="Resumption and Pre-Shared Key">
<t>In TLS 1.2 and below, session resumption is provided by “session IDs” and “session tickets” <xref target="RFC5077"/>. If the server does not want to honor a ticket, then it can simply initiate a full TLS handshake with the client as usual.</t>

<t>In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys (PSK), which can be negotiated as part of an initial handshake and then used in a subsequent handshake to perform resumption using the PSK. TLS 1.3 states that the client SHOULD include a “key_share” extension to enable the server to decline resumption and fall back to a full handshake, however it is not an absolute requirement.</t>

<t>Example scenarios that are impacted by this are middleboxes that were not part of the initial handshake, and hence do not know the PSK. If the client does not include the “key_share” extension, the middlebox cannot force a fallback to the full handshake. If the middlebox policy requires it to inspect the session, it will have to fail the connection instead.</t>

<t>Note that in practice though, it is unlikely that clients using session resumption will not allow for fallback to a full handshake since the server may treat a ticket as valid for a shorter period of time that what is stated in the ticket_lifetime <xref target="RFC8446"/>. As long as the client advertises a supported DH group, the server (or middlebox) can always send a HelloRetryRequest to force the client to send a key_share and hence a full handshake.</t>

<t>Clients that truly only support PSK mode of operation (provisioned out of band) will of course not negotiate a new key, however that is not a change in TLS 1.3.</t>

</section>
<section anchor="version-negotiation-and-downgrade-protection" title="Version Negotiation and Downgrade Protection">
<t>In TLS, the ClientHello message includes a list of supported protocol versions. The server will select the highest supported version and indicate its choice in the ServerHello message.</t>

<t>TLS 1.3 changes the way in which version negotiation is performed. The ClientHello message will indicate TLS version 1.3 in the new “supported_versions” extension, however for backwards compatibility with TLS 1.2, the ClientHello message will indicate TLS version 1.2 in the “legacy_version” field. A TLS 1.3 server will recognize that TLS 1.3 is being negotiated, whereas a TLS 1.2 server will simply see a TLS 1.2 ClientHello and proceed with TLS 1.2 negotiation.</t>

<t>In TLS 1.3, the random value in the ServerHello message includes a special value in the last eight bytes when the server negotiates either TLS 1.2 or TLS 1.1 and below. The special value(s) enable a TLS 1.3 client to detect an active attacker launching a downgrade attack when the client did indeed reach a TLS 1.3 server, provided ephemeral ciphers are being used.</t>

<t>From a network security point of view, the primary impact is that TLS 1.3 requires the TLS proxy to be an active man-in-the-middle from the start of the handshake. It is also required that a TLS 1.2 and below middlebox implementation must handle unsupported extensions gracefully, which is a requirement for a conformant middlebox.</t>


</section>
<section anchor="sni-encryption-in-tls-through-tunneling" title="SNI Encryption in TLS Through Tunneling">
<t>As noted above, with server certificates encrypted, the Server Name Indication (SNI) in the ClientHello message is the only information available in cleartext to indicate the client’s targeted server, and the actual server reached may differ.</t>

<t><xref target="I-D.ietf-tls-sni-encryption"/> proposes to hide the SNI in the ClientHello from middleboxes.</t>

<t>Example scenarios that are impacted by this involve selective network security, such as whitelists or blacklists based on security intelligence, regulatory requirements, categories (e.g. financial services), etc. An added challenge is that some of these scenarios require the middlebox to perform inspection, whereas other scenarios require the middlebox to not perform inspection, however without the SNI, the middlebox may not have the information required to determine the actual scenario before it is too late.</t>

</section>
</section>
</section>
<section anchor="inbound-session-use-cases" title="Inbound Session Use Cases">
<t>In this section we explain how a set of inbound real-life inbound use case scenarios are affected by some of the TLS 1.3 changes.</t>

<section anchor="use-case-i1-data-center-protection" title="Use Case I1 - Data Center Protection">
<t>Services deployed in the data center may be offered for access by external and untrusted hosts. Network security functions such as IPS and Web Application Firewall (WAF) are deployed to monitor and control the transactions to these services. While an Application level load balancer is not a security function strictly speaking, it is also an important function that resides in front of these services</t>

<t>These network security functions are usually deployed in two modes: monitoring and inline.  In either case, they need to access the L7 and application data such as HTTP transactions which could be protected by TLS encryption. They may monitor the TLS handshakes for additional visibility and control.</t>

<t>The TLS handshake monitoring function will be impacted by TLS 1.3.</t>

<t>For additional considerations on this scenario, see also <xref target="I-D.green-tls-static-dh-in-tls13"/>.</t>

</section>
<section anchor="use-case-i2-application-operation-over-nat" title="Use Case I2 - Application Operation over NAT">
<t>The Network Address Translation (NAT) function translates L3 and L4 addresses and ports as the packet traverses the network device.  Sophisticated NAT devices may also implement application inspection engines to correct L3/L4 data embedded in the control messages (e.g., FTP control message, SIP signaling messages) so that they are consistent with the outer L3/L4 headers.</t>

<t>Without the correction, the secondary data (FTP) or media (SIP) connections will likely reach a wrong destination.</t>

<t>The embedded address and port correction operation requires access to the L7 payload which could be protected by encryption.</t>

</section>
<section anchor="InboundCompliance" title="Use Case I3 - Compliance">
<t>Many regulations exist today that include cyber security requirements requiring close inspection of the information traversing through the network.  For example, organizations that require PCI-DSS <xref target="PCI-DSS"/>
compliance must provide the ability to regularly monitor the network to prevent, detect and minimize impact of a data compromise.  <xref target="PCI-DSS"/> Requirement #2 (and Appendix A2 as it concerns TLS) describes the need to be able to detect protocol and protocol usage correctness. Further, <xref target="PCI-DSS"/> Requirement #10 detailing monitoring capabilities also describe the need to provide network-based audit to ensure that the protocols and configurations are properly used.</t>

<t>Deployments today still use factory or default credentials and settings that must be observed, and to meet regulatory compliance, must be audited, logged and reported.  As the server (certificate) credential is now encrypted in TLS 1.3, the ability to verify the appropriate (or compliant) use of these credentials are lost, unless the middlebox always becomes an active MITM.</t>

</section>
<section anchor="InboundCryptoSecurityAudit" title="Use Case I4 - Crypto Security Audit">
<t>Organizations may have policies around acceptable ciphers and certificates on their servers. Examples include no use of self-signed certificates, black or white-list Certificate Authority, etc. In TLS 1.2, the Certificate message was sent in clear-text, however in TLS 1.3 the message is encrypted thereby preventing either a network-based audit or policy enforcement around acceptable server certificates.</t>

<t>While the audits and policy enforcements could in theory be done on the servers themselves, the premise of the use case is that not all servers are configured correctly and hence such an approach is unlikely to work in practice. A common example where this occurs includes lab servers.</t>

</section>
</section>
<section anchor="outbound-session-use-cases" title="Outbound Session Use Cases">
<t>In this section we explain a set of real-life outbound session use case scenarios. These scenarios remain functional with TLS 1.3 though the TLS proxy’s performance is impacted by participating in the DHE key exchange from the beginning of the handshake.</t>

<section anchor="use-case-o1-acceptable-use-policy-aup" title="Use Case O1 - Acceptable Use Policy (AUP)">
<t>Enterprises deploy security devices to enforce Acceptable Use Policy (AUP) according to the IT and workplace policies. The security devices, such as firewall/next-gen firewall, web proxy and an application on the endpoints, act as middleboxes to scan traffic in the enterprise network for policy enforcement.</t>

<t>Sample AUP policies are:</t>

<t><list style="symbols">
  <t>“Employees are not allowed to access ‘gaming’ websites from enterprise network”</t>
  <t>“Temporary workers are not allowed to use enterprise network to upload video clips to Internet, but are allowed to watch video clips”</t>
</list></t>

<t>Such enforcements are accomplished by controlling the DNS transactions and HTTP transactions.  A coarse control is achieved by controlling the DNS response (which itself may be protected by TLS), however, in many cases, granular control is required at HTTP URL or Method levels, to distinguish a specific web page on a hosting site, or to differentiate between uploading and downloading operations.</t>

<t>The security device requires access to plain text HTTP header for granular AUP control.</t>



</section>
<section anchor="use-case-o2-malware-and-threat-protection" title="Use Case O2 - Malware and Threat Protection">
<t>Enterprises adopt a multi-technology approach when it comes to malware and threat protection for the network assets. This includes solutions deployed on the endpoint, network and cloud.</t>

<t>While an endpoint application based solution may be effective in protecting from malware and virus attacks, enterprises prefer to deploy multiple technologies for a multi-layer protection. Network based solutions provide such additional protection with the benefit of rapid and centralized updates.</t>

<t>The network based solutions comprise security devices and applications that scan network traffic for the purpose from malware signatures to 0-day analysis.</t>

<t>The security functions require access to clear text HTTP or other application level streams on a needed basis.</t>



</section>
<section anchor="use-case-o3-iot-endpoints" title="Use Case O3 - IoT Endpoints">
<t>As the Internet of Everything continues to evolve, more and more endpoints become connected to the Internet. From a security point of view, some of the challenges presented by these are:</t>

<t><list style="symbols">
  <t>Constrained devices with limited resources (CPU, memory, etc.)</t>
  <t>Lack of ability to install and update endpoint protection software.</t>
  <t>Lack of software updates as new vulnerabilities are discovered.</t>
</list></t>

<t>In short, the security posture of such devices is expected to be weak, especially as they get older, and the only way to improve this posture is to supplement them with a network-based solution. This in turn requires a MITM.</t>

</section>
<section anchor="use-case-o4-unpatched-endpoints" title="Use Case O4 - Unpatched Endpoints">
<t>New vulnerabilities appear constantly and in spite of many advances in recent years in terms of automated software updates, especially in reaction to security vulnerabilities, the reality is that a very large number of endpoints continue to run versions of software with known vulnerabilities.</t>

<t>In theory, these endpoints should of course be patched, but in practice, it is often not done which leaves the endpoint open to the vulnerability in question. A network-based security solution can look for attempted exploits of such vulnerabilities and stop them before they reach the unpatched endpoint.</t>

</section>
<section anchor="use-case-o5-rapid-containment-of-new-vulnerability-and-campaigns" title="Use Case O5 - Rapid Containment of New Vulnerability and Campaigns">
<t>When a new vulnerability is discovered or an attack campaign is launched, it is important to patch the vulnerability or contain the campaign as quickly as possible. Patches however are not always available immediately, and even when they are, most endpoints are in practice not patched immediately, which leaves them open to the attack.</t>

<t>A network-based security solution can look for attempted exploits of such new vulnerabilities or recognize an attack being launched based on security intelligence related to the campaign and stop them before they reach the vulnerable endpoint.</t>

</section>
<section anchor="use-case-o6-end-of-life-endpoint" title="Use Case O6 - End-of-Life Endpoint">
<t>Older endpoints (and in some cases even new ones) will not receive any software updates. As new vulnerabilities inevitably are discovered, these endpoints will be vulnerable to exploits.</t>

<t>A network-based security solution can help prevent such exploits with the MITM functions.</t>

</section>
<section anchor="use-case-o7-compliance" title="Use Case O7 - Compliance">
<t>This use case is similar to the inbound compliance use case described in <xref target="InboundCompliance"/>, except its from the client point of view.</t>

</section>
<section anchor="use-case-o8-crypto-security-audit" title="Use Case O8 - Crypto Security Audit">
<t>This is a variation of the use case in <xref target="InboundCryptoSecurityAudit"/>.</t>

<t>Organizations may have policies around acceptable ciphers and certificates for client sessions, possibly based on the destination. Examples include no use of self-signed certificates, black or white-list Certificate Authority, etc. In TLS 1.2, the Certificate message was sent in clear-text, however in TLS 1.3 the message is encrypted thereby preventing either a network-based audit or policy enforcement around acceptable server certificates.</t>

<t>While the audits and policy enforcements could in theory be done on the clients themselves, not all clients are configured correctly and may not even be directly under configuration control of the organization in question (e.g. due to Bring Your Own Device).</t>

</section>
</section>
<section anchor="iana-considerations" title="IANA considerations">
<t>This document does not include IANA considerations.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">
<t>This document describes existing functionality and use case scenarios and as such does not introduce any new security considerations.</t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>The authors thank Eric Rescorla who provided several comments on technical accuracy and middlebox security implications.</t>

</section>
<section anchor="change-log" title="Change Log">

<section anchor="version-01" title="Version -01">
<t>Updates based on comments from Eric Rescorla.</t>

</section>
<section anchor="version-03" title="Version -03">
<t>Updates based on EKR’s comments</t>


</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC2119;
&RFC5246;
&RFC8446;


    </references>

    <references title='Informative References'>

&I-D.green-tls-static-dh-in-tls13;
&I-D.ietf-tls-sni-encryption;
&RFC5077;
<reference anchor="HTTPSintercept" target="https://jhalderm.com/pub/papers/interception-ndss17.pdf">
  <front>
    <title>The Security Impact of HTTPS Interception</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="PCI-DSS" target="https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf">
  <front>
    <title>Payment Card Industry (PCI): Data Security Standard</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="NERCCIP" target="http://www.nerc.com/pa/stand/Pages/ReliabilityStandardsUnitedStates.aspx?jurisdiction=United%20States">
  <front>
    <title>North American Electric Reliability Corporation, (CIP) Critical Infrastructure Protection</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>


    </references>




  </back>

<!-- ##markdown-source:
H4sIAAUGKFwAA+19+28bSXbu7/wrChoElgxSfs1kZrW4uFcjyxhlbVmx5AyC
i8Wg2F0ke93sYrq6RXMH/t/znXPq1U1K9mYXN0BwFwlWZnfX4zy/86ja2Ww2
6aquNmfq7u2tenH6Sl2tN7rolG3Utem2tv00+1k7U6pbU/Rt1e0mej5vzf2Z
upq9npS2aPQaX5etXnSzQq+3VbM03ayr3ax3Br8442bPX01K3eG116Yw67lp
1cs/TNXL5y9+mhT4fWnb3ZmqmoWdVJv2THVt77qXz5//4fnLyUT33cq2Z5PZ
ROE/VePO1JtTdd6UrcHYDf8qa3hTm/Ua048e2nZ5pi4qV1h1u3OdWTv+2ax1
VZ+phZaX/09Bb5wWds1PXdca052pFy9eqF+tLdX5vWl6o24tlsNvFLbEnE+e
//TTq+dP5BdQB2Rxpq5k5tYsK9ucqet/8V/0TUc7/Xh7Psn3c32qLvR69iuT
LtvQtW6K3fgRtqOb6q+646Ef3FfjefHAvl798MNz//Gvepdv6A8/vHj1fb6h
W92of7HODLZ0cf74li5PMW6zzDZz2VZF+u1xppi/bPX/26VPGtuuQdN7c8ZP
P7y5ePnixR/iP354+f0/x3/89D39Y0ICGz/iZ1CJ0yVW2bD8uw7Pilm5mlX8
w4tXZ/GtynQLeampZqYp2t2GGRrne/7jj/KPX+7ubm6rpjNtYTad/Eb/6XS7
JHKsum7jzp49+8tK16Vp10SvZ5t+/myjN6Z1z+KnGH7WlM69+PF0Uy7SOF79
VyaqeLQBC5ldXWVj8Ic3F9jE7e3ZeJSjG71bm6aD0LYlPiuhyO1OHeP9E2i/
7nSa5LaD6uG1owe3tN1uTzcQAv+F8x+4U0jPM5ienqZyzzD4b1jMb/evZi/j
1q4vP1xcXN3sr/Datt1Kna8N5BHicVmboiPR/AC11fOqpqVd2HZjW1axqTrG
MCfqAivABzU2tWg1dtUXXd8addPaDiPgzcP78NtoQD/hjH7G+3h2o5fGPctm
DfRwH5uqMyX+2Rl3qt3m8//+C/bvyoqn+V/y+J9ePpc3ILuT2Wym9ByLAtcm
k2C352y3A/WUs3VPAzilse6ens13yhBrNxjeuKmC2NQgBT7pbDtVWI8qatvT
IO19VRi1ae19BSlzqrOl3kHXocn4N/6p5hZ0xRY3MMMkAvS17pf898q67sH1
nEbfA1ltbdkXxuG1e9OC3MUKlsDQfP6tl2pbYSKtlhaP8XO1plUZ1UGCLX9U
p0loEdjdvYYh9YvnbWOsU/WL3dIsWMnakLBjBGfijCuNQbVqzJJVnObxjrH5
CoFh+1ZVTSuqnFqDTHOj7iuzxcsa1FcLo0l2pjQhWEHsCNuFK6pndbVgBiny
nsoVptFtZUGDle747cZ2Cj6rqnnSe4xLNIFrUq4vVt+wvqtGFheUaKq22GCJ
v6rFjikZWBLpT3PTXjwZvjaHpzxTHFt2hs3J37GptHov8OuqLGszmXxH5onF
hs3T5PK/KNGNwZSQp9IsDF4DEapWRRsPtjtxVGrR2rXSXaeLTw7iXy2rBi8A
d/ADVgP4QN43xsEG+G8Zz5MNLEiGg18rTfwXaNHtNmRsQIrSNkbGxCNaF6mS
ULdqmFN+SBJnB0ouySaK8JbGbCB4rvJmzcoHpaGdO7Vl6cMvO54Ta+4wpSmn
8kS7fHiM6NS8tZq0PRszYzNmtWuL+W3vkkQUlrhTY8lFax3ewUbb8BY2tLHQ
enCqIN0lKoblgfBYSEXybHnXam1h+iy/BNnV98AKeg49O5bX8BvMz5p2ycaJ
aeSwr4I2g69YsgLZ2Kc1IpZ3Kzx1J6f0B62w3jjaFHEEBNVEGdU3gkSrv5oy
rjHSjGyKML110yFRoO94ZQ5poalZ+ml+SJZnOBagZYNl5WhDGLfLKMgsPVU/
m0KT/kRDpct73XTkRqYPqePakP5Wbi1Gf4sFgQhk+9kGLKDJUwJGfa1BWJAn
+CDRObCc/KiCB1S//+5d6pcvalNrqA78jQUrWvMffdWyzccsc1LYIDMAINWa
+D00yBW/KPIDhWNZzUQKPwXDET/L9RDPiYBpk7oBEaLP8QIX1BWxQifvA4YC
BazF7kavAHIa+Cy7M0THAoAF3iAw0ZKFJnrBPqzxiCx5a9wGnBOeI96o1tVf
SSRp0MLWdeIq4S/bwKqXBHyytdX0vi4gQezYtmQC+R0WYR6COHTHbIbBNS27
IFKwumTFYIsQzAEPHWg+loCoM6ffgAwC19+AoVtIrVPHb3494fHJyPaOdnaD
8I88Bf702F0dX93cnoAy9S7zj4jj9GIB6wvF2HiqiL/2CCGKx3hBGwujXQH9
IGDcYJdELm+84juLvilk0V4Ay6nXC3EMc/sZBCOIZyrm4pwsHzOa3XBYXGZU
glaDvlAM9vkNnHETTSZk6dB3cUJ2kMQe81nTLmmHJLfqvq+BAIPMR1s/ZcQj
VM1+5GjAAjyVVTcVSFUhFDTZnFNluoLC4PFKH1mLsA2/11syBqXdNjXs+VTN
awvj9KnBD/QUpCfb/PHDW2iBIcUrBI5ApL3OF9VmxUoCbdmI6JrPi6ruAmiW
1SlXLZtqQUAb3Abw9oohDn3M7cBIeGij21lnPneHRAgmBvt9q3fg6fdT7yLm
BmQybLVhQMlQFOTFmjQAORsmrAcW6q7VGBSL8mPFwOQY2OcE9s6HfV++QBPJ
oTxoZZP+JL+ty7Jl9SaP4ldFBoMXyupPdosjw5WZCdfU8buru3cnzLWAwYBi
WDxgLYC02c5YRZhA3ADerWu75d+3NsEqBKQvTtX7voM9bih5w6NMk88fDB5A
jAngBiyoSFY8jmF7GW15Z7fsIki1YAYSsPBQZ/KSnMvfN3GGmr5lZlnnZPLG
U86GjYeJAmGmikgs0kCulo04/CtbWOYKdIFwuAUaLQwklqS3EyinhQ0AwM2O
Xj7md088yHzGHgWvfgKg2uiqZQP+0HhVDh4Gu5CtVQMERDTLJJmiLRN0ggyf
FsAaLW8UTTFcx+6ENJViDZiTzS4IT7ZimNq+DW6MpgNuKN1Kf/Lu8oGR1TFD
xQVxpwVwblsB0RznRFt0Aln/xFCIdZ0+RljPAiA7x5gtsT2TDaHe+P3C9vCA
2PxGOwfVaW2/XE3pOak2/dHsvPV5D26pI//kKIykvY2lWZOtDOZD8wqgrp93
XgtB7cGirgiGluCiEXic8zQPMOnZsZfiE442QCFi03FrTsgsEsgTQzTihGhC
96DonKo39ALr0/5OCKZnWAr+xcJVtuwBzecQzc3BTWM87UXjdFOGZYrMiYLw
MjkqYjr6wIMFD2Z87mCy6euRy4ftrwleM2ypwRGxmGCgsGG8avJVmgzZQBqC
8hIg1GxLmd2qWngo4HW7021H6jTwybY0US+auHwR5c9p7EhshodCi9NkSKrm
ITsS9ESExctx2hEjuWZRLfs2OJyh7glzheLuSc5g0lYBiy1hTSv4J5OQYwpV
fg4UFVIw44bCCCzUdB4WZUsloNHCBQUBfmiW4Fo5AIrSMNwlOMNP/16Joz/B
psJERj0iW5PJnSXMMUigaNX0XFl4JMsQ8CmtQVBEoTcCyiqJhxvJiwk+8Omm
DAgQMgQ0wfLblLTi55QSxvNHElhCzADC8uUKaj2waMknGOKLgyY5GJ0ymQxg
DcKqi4y1omWDTfHGzefKdRIVg3owYRzMEzsa6yUEb3m1o6RDwMlhaBoJhMuR
NaksRBt7HeJyL970JRSg8aANIZ+pF6rsDXsHArVzTpv4SMmCsjEw0DErElTI
o0qvzjuenBwxCFS5FMttM1UXbz6w3ecS4EzJpEUK6HbZk88iCnju0Kf5zpkP
JILMiVVwQQdSeoEdJBeyWN15+243ZFk1E4jyW97XUoDnXE92lv16kNGQGVHH
e9pyEmK8CDsJSRiNiPFXg4Xh/XuffKwYK1FmpeZMDKWIofklrz2hAEGnvFh4
JuAENxBQMAYwmTD819OTj2ZjNwhWQSVep66dZfEbCF/ct8fYORtcvwDAEG4A
O0dRY8udMgVCzWH26sBopYXmDosrQPqwLUSRvsVSPcbO0qSeRymt2RpvZiVF
7LOcTw/H4k8fTX9KXjVmp0mE4OnZ4MBu7H3JGdtVtVzV+H+f4IBTJuuPvZN7
JjeSiWNM4BIU4/fjmIOgSTzV2KYEWRPzkXSA7UcQ85xSPv5huwHZe7pPBBfm
WuAbNi8hAR1gaL4uhDxOIGGcorQYg7LGluUibj8Lx2xIlYk0cMlAeOi6ak1Z
LxN9VVk5rMMF02M+wwa2hEDxG2UZ8yxJ8E012dPvvlMf8hwYlqQlFb2fZqdV
EMaDeCCOOXr38fbuaCr/ra7f898fLv/149WHy9dH08nR7S/nb9/Sj/xHeOP2
l/cf375Of6UvL96/e3d5/fqSH747/3eMQXs5en9zd/X++vztkWSXffjAeXLT
iQ0rjSvaam44r/zzxY16geAank1RHXTCTo7+Yh35LkrVBXu3UDB8f09ZdbOd
TH4/O6NcLPb8ZfL0/16WBMueOHVtqQvgJuoPCbCqYa5qNhbBKg1kNgo5pb+2
FEOIXHrIDiwOpvd1d/rnp5j2WZyWUEKwRpRxfKw2NP3bSlB/JBqVlt0BNDGr
H8WXvV14tIA0sg+pLONCJmhrIl/whEzSuC5Dm5i3lVmQ2+g7zgHxeoKh8NM6
NrpldR+i6jAA4zXKHSwBrjfuj36eYMxpxSMQ7LxrG782Drod68YoEzCUGEdv
fPfBrO09CA0S3nLNXH24PedJXhNzzewXU9ew+OqC007qtq+o8BkAmus35J+c
co9+LDkrvE0fT0dBTgLRT9wgGBNdQSAcYby8NuNQPQNECRAStGhpS8RbWVtI
6ZDpy5dBcrTQ95bdrMGDNUscBS/j5eel1uCAKL1IgRhGp8QIyU1rCqq3v7k9
YbxDLspBOYIrY+xTkY1CAAI+tMm+0RJ1AORkIVeCq9lcBdCZoD/pYYVYK1CS
yip92zCKi8Bz+EmhGzLXHDGk7Pc4J0TZREjOpU9bfsVVCsxpirovU5Iiz5NC
nXti8QphNP+Q8qmSKJBgL3oB0+mK8t6c8AGbllCSLvOAJ1OFZZHb5HwH7eD3
37/W+MFWk2R9nJHbUwfSh8uYqLwVblykuI58CqglnuSCoSFJiFWwhU4vObHE
hidWSbxQdzHdGVKTx1c3YgPx44n41kMDctHXE7jjLhFe0zWhritEjYXA9ePb
66sTlhv2w5IBoepEw3WXFPZtK7cSa0rVEOzal93wf4AGi74WGA/v3FUkAEf3
Vdv1KVYWH0YjS/yr1RLWtfn6BgFcGHTGylxeVJLCFZdH7VpXg0CVUHTXmbUE
FQzSgck8VvQKAyTIYu8xjRBpQMigKLzrqgk2R4o9eay00a3mfCe0VdK7Iuo6
l4OvjOqZPs5gSoxN3lCwVkf45TqCcIp+1NNq8VQYfX2lJHk9yGoJUULsLbZk
2WPNwBMmqT0Ym5imshRDJWukHHYl4mNiLZumjBkZn4zhH3VN70fEFwxgy+0z
tXmAlcGYhTWFUEqY6XJWilqRP9lTremAm0TGA3yQAqvgC06cZ1WMKQEX7jSp
wiyv/Cz7Aw0rFUxkEH5VlQEV+00FBvrEebMTQLc2ZaVbYIm/1YLeU8+Fl0dC
K3sJ31imGeScprFmCDnswA7qTqACZa2LT/KvmPvLqrl4E5jOsBHO6s95LRmW
WnpDac5jc7o8VYuqgd2uvFhRRe4kK4SVJKSANXVtGqEj73fY3ZOIEapNexmt
ULQLiQQfEKQSVGqQkPrwN4z5FFL79NDIlPeIA4sRHiQRSdpZwjFIjNxGWXEX
O2WkGFhTW9dSL1nbmj0HGxVsbvBKw8VVAa8x5w+FkBYmSsCQYkGkRXmkpOor
JiYqLSdrVqb4lJTtQE4yGinNTaHYUFesglxjmD8Ks7KeNLHYgaw6xAoLBbxY
lVqIBqr1ZCulghQEtxo26lExfiOyPVVJmEFWP5TfiG/3yDxdrqS0eWIJpX/8
Z2Wm1SHQvN3fO/MS0c0cUaYvkgykhLcRUzahaJvKZg9si72m1MfJhGjXS4AX
2lfo00RPoVFjm1nGWNEtc68daHMS+SwAKHtPGIp1Mq4UEagxEQkd6fGB0jy+
pr4sJa0/LCAuJPYcjIOhBmf/M2/1PkekJPJVVy2ZfOsAdqExqUg9zBkiemEX
JgUCaWsqDZ6XnKpsSt34mgtghmTEwuZGA2GXBNjyMFa6MaLgLC2tL0tmMKdy
0Y1S68AUwpsJFFdtbDagNXpmYZlj/nCIKbjndBjdctzk+nUyUDetmd1KoPIn
s8s8mgSJBkBiGo1Am74d+fij8MrVa8JalD6IhZiq+GQ6/Co58ec//kjF8atF
ru/RR2+1oNCVbTiykI+nUo9BFEKq5Ijs5A/AZsYozJhh/TEFH8F9k8gDW+Re
2/tTyerHrifaGgEzXcjWhhSCV7m5/dNJRFBYD2W04HJ4MZwVARbj2IkDMFpk
nS0sVpe4aEBBTV62SO9lPiUju6gtrRqrSNGj467ePcziMz0BiGt1hLjsN47R
jmAtoEmhVCYh7QD/cPmOUwPtUGSoM01xaxpn5Zn4WeE3wpYuuiKCVxwKmdxZ
/43xGv2Y1xL4za3xTaCB5lJ/GxF9mteKOIHMjSuJjl4aPdmiNOYRzEHSjUuS
PliV7pesh8/b7SGp4rTpe++jPZFCGTWUTrP65VQKwTzcPQvLAhGor82lAopP
8U9yvA6RC+aX8jFcChde9U1dfSIgIMl1b9JF5A6YAJ6e+ctFWEoF5BseSwb0
tikGIkZBYgdI1EVFJ+1hFxkSCytEYWTdDYSjZP5Wa78PboCrJIGTggEZ5zcq
N/CrWaGNcxuUwAgON5iG8p5cLgOHkHvBgK9/kezWNF/yMTmS1KFA6k+dUTuO
n8n1Md7/YLp2R+ldwxU0Lw/ZlBTxyvtRqjIRHVMO/LvwzBANb3uu91Brqk8V
QYolAQQSWWn9o/CaTTTxzXBPMT2dY9QT4R3+Vdi+daJB0YYxHNpKNTcoc+eJ
zez2acAMwpxKDuLf4HEqPgQmQwWL8dpum2Wry/zkw9dzEqJ8xBQKCaQFLDCH
nJ8tbK3uZUqf5g+9CBWHVHVQGsoGEyvS9/4zj9FLj7YIqK4sKUYILfcjcorg
99rcDRfp8JF4hTB6k9GBHKbYc9+leXDTvPK4IJoojCV5Zo/qtnCvYS+/BRIM
7FJgHPd9QiOlB4r7kLpQdc8r1g/z4bElvQxLOqrNUhe7sJYjRF2mLqmbL7qo
jDWtKeyyqf7qNTmm0Z0vXCd3mqImHYHJgMmCBZwx2Qv5LnxXdWHGFfqMNwcw
AaBXCVAFW9Q/Jgy5kHIKC15n8E0N1K0MV9vmuy70C2QGJW7VhZbTsEAb/nyR
oJiX8nwmqth5761Toj+aGekQlS40DtHlDALmqTUQ90oq3mVUUHmclhlcYsV6
YhgUU21Rjxg7TXAwpaR9xye7buEsd5FPJm+GUVeWLqDqNUVqldnGluu1buMR
khCgh9mjqxz2q0gGPu16v20y9fB0GXTInbPk8LJQ0tcs9T5EzsPvYUMCN4DT
qJiyb5IBiqqKoADe2HBsEdPikoOPSMl7wyzySBHg5MG6WcN1s6sna7baEuOF
9BvV5KnhtNmxNcmzBw7SS69N1bzn4i8IeYU3nJR016Yjofnz08n+XCScR0Lx
I3X0FQofDXbIdNYbXwaw8L6XCKcuHSXGKl6rYBRNmaGq2KNOZD0tDK7oxezD
3Z36JUx2aK0SN5tsCtb8BHBiNYwNB7nYY/7L8mPI9+P47kTNQLjSNk+6rMEi
9h5RLwIrvG8+oCd+8c958XTy8QA/Hx0x1rNHHJXhsaCqe+KEhHHH3ArB5adR
mIEdj8ujvDxKeVzG46cBBtz5Rru7HviTDitMzp0v9XOENc0rYXmWI0tdTr9e
LPCG9YEqhiSJ6+HZj3ToJ2RYpU3cJreWTB1VPfgopimjaQudsuP0NAwh3iIY
SwVl00IZpazzwEldOgXTWuoSYRlfhbIqJ8339yVNK1m18B+dnv0fnIf9uxKv
HFAeGCiAqpA59bw71JhKQ0hothoWGpIvsamrciBdwerMzYJ6SSrfQWQVdZ5I
SXDcKq8+gjoXlFKK7SO+HYC6AagrhapT0gnh+41CfT51Z4VfDjQcsXlZLOIJ
prx5YYSGpbclrEddvYDR4TPcF5zmyiOAWy8HqXXQKwGfDSnkfX8Ultt1jI8L
pQxMB5E/c8NwzRra87EYWiEfdzwNd1EcyjEGub+6ueVvfzVzdU7ex9uacJZJ
Hf96/ubE5wT9IinDKLXiwdExjj6pnKiLUSNRkPdwxBewJJ9L0tN0qgbaVlPO
r02h1t7a6TRNVVDDJeRSf+LqdJWgim6yzrv4je9kdb6CSZal6TK98guc+Hzl
Hi5LhJNj4L0cM83ZtrUcgLqzvKFawitKIsGZX8VTVSRdU8m2hgO0obQPIr79
UdLIGYlYIALPqP9uSOlQzQxt/jEz6tvikgVmAC2toIGHQYaj35YzFLBIlXfz
o5OrnuG+lDtMO2Z7j8TnQGV+uFlP+giyuTjHXfoA3pfNSJtjBx+HOsTpb2wg
GCjjSyhjLnrvY6rAssc9v+M9BcU59zVxPvVUey+Ml04yyfKPQLW30r769vus
jy9U0mNv5UZzngefUahohseFJb0NUbm1G+y683VezBgz39L07/ITgbmgZEe+
4EekX91KuzqCh7evnmF1cvJsPTfsc0LV3mtxrMyy05qqN5C10bOpur264VNq
ms9khk9O6KBwSMFKHSFWLLJTG3AcILUsZWXoaDTZzF8zl+KXG/OLUENLJ2x3
svRjrOmEKxpUtgUsoqsmUtbPicD5VF6I1rZ8BA/62fkOai++kQ6h/yFwLFtF
llGK4dawFQcqu9E7NmGP6WKmhyPBfAXBvEhnFn8PHWDpty+TdwRwPd7gfWYd
6iG1KfnaYjfPjw8PDhvLP4hvRU3NaJnExPRxdmxY5FSS7oJvM4GFpL5JhyWn
g2t24vEBwRj+8hNorf/ry5dJfkiTwsTQoCBFiXiuWbZMzdi5yYoHHGzoQJ+m
YL8MZ4xTAyGdFxe/GlvgsfxsOXk/qvrupTQzwVjQUdrP6vwlaTBVYCw5qIZP
OJ3ERsOgx2LMKfT2tTi/pJiv8/kY+UfPsN0LGnQVHvKNtFRNH17Zi+e+30pO
7ER7OzjBwCYi64JMawtEHjZ587FZKYT4QDn14PNaYwUyHS2IZbgNd8r71MZr
dooiayKaULm6ZlRFR+cJKVuq5C00tdgVADUSfzrfrd9Rw1C4O8MfH7dzjjnC
oT0KeUyXY++8Py18xHuib2q7XNIeGe1J/kEKsnliOwvITrJVhRJ06i4Zt6Nk
kkqXMfgmLhhlEKblfDIlzcMCuxM1uI9gsP+WTjg5CHLf1AENZM2DkmiPx+5i
codOZ0oGOrMo35NFkTPR8ZDuOXM5sy78PDzmp18m7wdKTP6GcXys4eqWUTIZ
wE3HYh7TXCQheVwrTS9VG6uxysdvWfehjaekTb2YkVcxw1GmEo4pOdfZmRln
w/P+gnO5Y6ILhxj32pIONAxttfvGpiPhwmN9RtkJGA/w9EH1sm0ocPkD4uK+
9+h5IEUQe0tYtmi04KnG4znve8Svk27QGX4+/JwnXlm41qD5PVFYNN3wuSDv
BWIUFEJRX+mK33v/Hk7reStW77JCjiDWRpRBS2IvFdms8r0ZsR5H+XJ/G8m4
lwNf2gJy6lLKudbzVOanoHCvT/SbosIYEaZIcO8k9H5IGC6ayKNpboEMyBCm
I8u3v/KlxmGa9kmsibATrNwAI1NJFyq3kUPWHqe9/uWSm4vDIcFvakxSQ9vw
nmLS8yRv9OBGBOn4/OPNSX4bkA9yxkeYnfgKKew9MtTwCD6t6uqOBYRYLzei
pHsrpII1nCelaBY+JH1GR1FnS9PEX6jlf+4T3+HIeYaJvdxn1+YQIMCIg2o6
3QOgs6sPwkexCygAjsVBNYYE3orEYtu5saRr7p6qo8twXUq8tkn7JtUU/D1Z
aupdeULbcVU837+/hiMa8c5QnEuomH4KGjkamQT3wB7oyYbhKmEBS6m/DdMg
XPAjyW/fnRkG21LnWf7FETbd84GAzPzwR4X4O7cSUc6vcGEpvr4dRrDEtr24
lpw0PtVUoQ0xCMX5xYoyvw8OLG2zLl1xJMcofSJlHByfRJs/5dPQBLK5OWlK
hYmGkGc+eUxfwSLygj9+eEuG/Z2BgpeSyyCDauloFCluDyKE6hgJFosquRLu
wqZMDbcXVB3jZ/mQcz2NFKPDGWDhV0gqhHtIWN1DdOJid/XwuoEDQYuYPk4D
8y4kEGPZjrsmQU6x/rDIEq4NpXw81UM+kUUNELPA14SDtqud2tmeugSedOov
BMtK65tZuoFOhk6Ncbp9VNlpq+KMgnKfB4saTcmVLqS/5Ux6yKTuHXAaWkJK
CLzzd7sQXe9W3I+RJelyW6hLS6f5pc0egKFYNRbgcpcc3Db0aTFE4/bTNHgn
g2/SJWaLUTCjHXyRC739wdGlQ3Qx4zSyadM0QrisLSIGnZ2Lzc3i8IxiUA/D
WU65HCeuNFzTlm/mvmp7F250mw56+DbxkId3HvFYQiRZuKkj0LLm22QSZVLy
cnxsN95yxW4hJY4yqsZUw9w0ZlGJc9ebqvQIFSKta76SrN+UHl3dZVwYT8kR
Y+X2ndM4TxeS9tzwOrrPKbA6HJMdEJSTKdSayjLzfCY3sel656o9pd67wylT
a0aymVrTGSkBpHv5VroZVq+dmCHSXLKIWuZ7UNnPqdF3GnWei2n+wFeAU6T0
W5PrvNeaZnxMOR6PjeNJJwWscZvfT1bARh5xpxNsKCc/7s2fT7/BUnwAl5zg
dOmSYket1D6vo/6mqzhjuSSIwd6UA0NCCZwre6cug02a+PgyvzLvEl5mx+Vj
NqxV03sgxYUqRK7WKxf/Ec2bD/lCjiv1QYex/e0mWbZ81EgwOmwppjGet4zH
VJyJgOUiO/ce7z4kvaqrNUXV5GVt39LPxxc3H7F2g0X7COwEA7zlmG2Rh8f+
7h4pVrDmJcuUqa+zi4604jQbJfwWNJbgGxXu8zvCPN7iM8mUzuV0BIA/N9HF
TOLgUH28VyveTUhZtU0kMgzi1uhP2JXvOaHwxkl+c0k8pduDU32UK6/UCTW4
YZU6n/x0/hh1vwm5WwrCwvGn0UVZUTu8M5CTgsmXHwz731PY/7HZEFLDIEka
rw8Ra7Mxgm7oCsMQumEmtwGLiTaMhvjKRLm4kTqXaNk7fCdrMu2a79PQfWfX
Ws78DVk1IB4PoeO1dpEfo6X5JiQEZHI7QWg8If1B3NcCPqWbFpKeBKXirGHf
xOa4gQQxteXettGsp/7wuWFBFn1Ig/vz+6lpkC9UYjoLWs4C2VCSwpxyX4hE
4IJHYaPvfcIwij8wXLyjcXjvHUblPkoWhfOv3abGHZm1tRKm+DNbxh/M5wPd
XuD3ZIGiXbqXjiXSl15ZziWDzimBKFdh3aM09vsfIH0f2NNeyKkVFnLMSeL3
b4N98ZEwREyarnUCVDGN77scbd9l+syXDDahR6vwX9M70sxFnBDCpxog34PU
+R0Mx7ZtOFwjhjGMBw2HkhWfRNnDyYpTdcO7dzFHlOItTsxlbRZrLk10fIsT
34tAByxCTxmXRsjYuy4TL7lNNrUmS1O3kHsw3liI1gPhEdqAL/84UTlkZ22b
NTEmlkiTW2DGV5on6CCizrxZov83yGJYUG0eFMZ/hjDCAM7sYvaWsjrBGE7e
k9XOSH8czB47WT6YwgyjjdMVGiep1ZvsH3cRUq/RyNBxf/UhYsGJ3leUH9mN
/NO+kQm10mx7HlsRS76ZrXQbb7w2iZkYuRrBMd/pF8HkmHg/DgpSE/ZBeUrQ
AQZQkOh5F3onspJOfHtwScbvv+9Xtr5MKZ1lABJpgaOjrEMoM17mTw9luSfx
XJi6120VL00apjbz9RzIhVP9+B+YDic985sKtz1Mg3nZJWXhDpCsUPn/k+b/
/UnzIp4/SEnzkBCPZ/8eS4iHnig2LDR45R9iG6YdFtZivsnLa15WzfGAbyzz
94P9zFXAfwc2Ue+BbV4zoj2RzLi6Or8+H/VWiIbsXwwUhOzAJ3yLTVK0i0fH
i5VRLlPnHSE6AoBDrVYNnyETVJ7W5C+YiR27+VXpwxXSEs8LAni1KSWEdBxB
y1XkjCURa17K/34FTHFbayiJTQ3c8Q4bCfWkjkWZC/7fstBUhqCL06TMHKpz
ycWtUz5ACOavq3hrl2y9wimR2fMXk48+nInKH+dkMzhY5Ono61f7X1/+6cMT
F8cYRsXfMSYDS4DUWzcMZel/GoAaeSeT/wT7nRpF3WgAAA==

-->

</rfc>