[OpenAFS] OpenAFS access at login time on MacOS
Jeffrey E Altman
jaltman@auristor.com
Sat, 13 May 2023 12:21:45 -0400
This is a cryptographically signed message in MIME format.
--------------ms090400060802040604030109
Content-Type: multipart/alternative;
boundary="------------1902mjX8mLpHkialJTFJlxse"
--------------1902mjX8mLpHkialJTFJlxse
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
On 5/13/2023 11:44 AM, Jeffrey E Altman (jaltman@auristor.com) wrote:
> On 5/11/2023 6:20 AM, Richard Feltstykket (richard@unixboxen.net) wrote:
>> Hello Everyone,
>>
>> Perhaps it is widely known already, but I just wanted to share a
>> process that I have worked out to get a kerberos ticket and an afs
>> token at login time on MacOS. It seems to work fine for MacOS
>> Ventura and Monterey; I have not tested on other versions.
> Thanks for posting.
>>
>> My cell takes FOREVER to log in for some reason, but after aklog
>> completes in the background, I have a token and can access volumes in
>> the cell.
>
> Negative DNS lookups impose an unnecessary time delay.
>
> Assuming the name of your domain example.net is also the name of your
> cell and Kerberos realm (in upper case), and assuming the following
> hostnames for your kdc and afsdb servers
>
> kdc1.example.net
>
> afsdb1.example.net
>
> create the following DNS entries
>
> _kerberos.example.net. IN TXT "EXAMPLE.NET"
>
> _kerberos._afs.example.net. IN TXT "EXAMPLE.NET"
>
> _kerberos._tcp.example.net. IN SRV 10 0 88 kdc1.example.net.
>
> _kerberos._udp.example.net. IN SRV 10 0 88 kdc1.example.net.
>
> _kerberos._http.example.net. IN SRV 0 0 0 .
>
> _kerberos._kkdcp.example.net. IN SRV 0 0 0 .
>
> _afs3-vlserver._udp.example.net. IN SRV 10 0 7003 afsdb1.example.net.
>
> _afs3-prserver._udp.example.net. IN SRV 10 0 7002 afsdb1.example.net.
>
> If you are using the AFS backup service:
>
> _afs3-budbserver._udp.example.net. IN SRV 10 0 7021
> afsdb1.example.net.
>
> If you are not using the AFS backup service:
>
> _afs3-budbserver._udp.example.net. IN SRV 0 0 0 .
>
> If there are more than one KDC or AFSDB server, then create one
> _kerberos* SRV record for each KDC and one _afs3-* entry for each
> AFSDB server.
>
> Note that the hostname specified in a SRV record must not be a CNAME;
> it must be A or AAAA records. For the _afs3-* SRV records for an
> OpenAFS cell which does not support IPv6 the specified hostname should
> not have a AAAA record. The AuriStorFS cache managers and Linux
> kernel afs (kafs) clients will attempt to contact the location servers
> via IPv6 if there is a AAAA record specified.
>
> A SRV record whose hostname is "." indicates that the service is
> unavailable.
>
> The AuriStorFS aklog will attempt to acquire both yfs-rxgk tokens and
> rxkad_k5 tokens. An OpenAFS cell does not support yfs-rxgk but aklog
> doesn't know that until it is explicitly told by the Kerberos realm
> that there is no yfs-rxgk/_afs.unixboxen.net@UNIXBOXEN.NET service
> principal. This requires that GSS-KRB5 be able to quickly resolve
> the Kerberos realm for the name "_afs.unixboxen.net". The SRV record
> specified above for _kerberos._afs.unixboxen.net is intended to speed
> up the resolution of the hostname to realm mapping if the client is
> configured to do so.
>
One thing I forgot to mention.
The service principal for yfs-rxgk is
yfs-rxgk/_afs.example.net@EXAMPLE.NET instead of
afs/example.net@EXAMPLE.NET as is used for rxkad_k5. The reason that
_afs.example.net is used is because of how GSS-API Kerberos v5
implementations resolve the Kerberos realm of a service where the second
component is a hostname. GSS-API will fallback to using the DNS domain
of the hostname as the realm if there is no other information
available. However, many implementations including macOS and MIT will
try to validate the second component as a valid DNS hostname as part of
the lookup process. Therefore it issues a DNS A and AAAA query for
"_afs.example.net" even though a DNS hostname is not permitted to begin
with an underscore. In hindsight specifying the service principal in
https://datatracker.ietf.org/doc/html/draft-wilkinson-afs3-rxgk-afs with
an underscore based hostname was a poor idea. That said, DNS resolvers
and most Kerberos libraries do not perform validation on the query
string and most DNS servers will happily respond to the out of
specification request if there is an entry present. I therefore suggest
creating DNS A and AAAA records for _afs.example.net to avoid the
negative lookup. The address doesn't matter since the DNS response
will not be used to contact any host. Specifying one of the location
servers is reasonable.
> For rxkad_k5 tokens the resolution of which Kerberos realm to use is
> performed by enumerating the hostnames of the location servers,
> performing an A/AAAA DNS query to obtain the IP addresses, then
> performing a PTR record lookup on the IP addresses. For example
>
> afsdb1.example.net A -> 192.0.2.23
>
> 129.0.2.23 PTR -> host.example.net
>
> _kerberos.host.example.net TXT -> "EXAMPLE.NET"
>
> _kerberos.example.net TXT -> "EXAMPLE.NET" (queried if the
> _kerberos.host.example.net entry is not present)
>
> If there are more than one location service address, then the one that
> is used for resolution of the Kerberos realm can appear to be random
> because whichever is first in the list will be used.
>
> Issuing a "kinit user@EXAMPLE.NET" against your realm took a little
> more than six seconds to perform the DNS lookups for the kdc on a
> macOS Ventura 13.4 system. It then took approximately 180ms to
> receive the expected principal unknown response to the AS-REQ. I
> cannot measure the time to perform the aklog operations because I
> cannot obtain a TGT to test with.
>
> The time for the AuriStorFS v2021.05-28 cache manager on macOS 13.4 to
> "ls -l /afs/example.net" anonymously was
>
> * 470ms to resolve the location service via DNS (3 RPCs)
> * 330ms to resolve the location of the "root.cell" volume (2 RPCs +
> reachability test)
> * 850ms for the fileserver response to the first RPC including the
> fileserver->client callback service TellMeAboutYourself queries (3
> RPCs + reachability tests)
> * 600ms to read the contents of the root directory and obtain status
> info for each entry (3 RPCs)
>
> The ICMP ping rtt from my test system to the location server averages
> 115ms.
>
> If the vlserver and fileserver connections were authenticated using
> rxkad or yfs-rxgk the PING|PING_RESPONSE reachability test for each RX
> connection would be replaced by a CHALLENGE|RESPONSE exchange. If
> the cache manage to fileserver connection was authenticated using
> yfs-rxgk, then the fileserver TellMeAboutYourself query to the cache
> manager would not be performed.
>
> I suspect you can reduce some of the time by adding the DNS records
> that are not present in your domain. You can observe the DNS,
> Kerberos and AFS queries using wireshark
> https://www.wireshark.org/download.html. Start a capture and set a
> filter rule of "dns or rx or kerberos or icmp or icmpv6".
>
> Feel free to reply privately if you wish to discuss details of your
> actual network configuration.
>
> Jeffrey Altman
>
--------------1902mjX8mLpHkialJTFJlxse
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 5/13/2023 11:44 AM, Jeffrey E Altman
(<a class="moz-txt-link-abbreviated" href="mailto:jaltman@auristor.com">jaltman@auristor.com</a>) wrote:<br>
</div>
<blockquote type="cite"
cite="mid:ca525faa-e8db-14bb-d2ca-0b04fdae6dda@auristor.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">On 5/11/2023 6:20 AM, Richard
Feltstykket (<a class="moz-txt-link-abbreviated
moz-txt-link-freetext" href="mailto:richard@unixboxen.net"
moz-do-not-send="true">richard@unixboxen.net</a>) wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20230511102048.ogkb7wpgwpwtabbc@tilt.unixboxen.net">Hello
Everyone, <br>
<br>
Perhaps it is widely known already, but I just wanted to share a
process that I have worked out to get a kerberos ticket and an
afs token at login time on MacOS. It seems to work fine for
MacOS Ventura and Monterey; I have not tested on other
versions. <br>
</blockquote>
Thanks for posting.<br>
<blockquote type="cite"
cite="mid:20230511102048.ogkb7wpgwpwtabbc@tilt.unixboxen.net"> <br>
My cell takes FOREVER to log in for some reason, but after aklog
completes in the background, I have a token and can access
volumes in the cell. <br>
</blockquote>
<p>Negative DNS lookups impose an unnecessary time delay.</p>
<p>Assuming the name of your domain example.net is also the name
of your cell and Kerberos realm (in upper case), and assuming
the following hostnames for your kdc and afsdb servers</p>
<blockquote>
<p>kdc1.example.net</p>
<p>afsdb1.example.net<br>
</p>
</blockquote>
<p>create the following DNS entries</p>
<blockquote>
<p>_kerberos.example.net. IN TXT "EXAMPLE.NET"</p>
<p>_kerberos._afs.example.net. IN TXT "EXAMPLE.NET"<br>
</p>
<p>_kerberos._tcp.example.net. IN SRV 10 0 88 kdc1.example.net.</p>
<p>_kerberos._udp.example.net. IN SRV 10 0 88 kdc1.example.net.</p>
<p>_kerberos._http.example.net. IN SRV 0 0 0 .</p>
<p>_kerberos._kkdcp.example.net. IN SRV 0 0 0 .</p>
<p>_afs3-vlserver._udp.example.net. IN SRV 10 0 7003
afsdb1.example.net.</p>
<p>_afs3-prserver._udp.example.net. IN SRV 10 0 7002
afsdb1.example.net.</p>
</blockquote>
<p>If you are using the AFS backup service:<br>
</p>
<blockquote>
<p>_afs3-budbserver._udp.example.net. IN SRV 10 0 7021
afsdb1.example.net.</p>
</blockquote>
<p>If you are not using the AFS backup service:</p>
<blockquote>
<p>_afs3-budbserver._udp.example.net. IN SRV 0 0 0 .</p>
</blockquote>
<p>If there are more than one KDC or AFSDB server, then create one
_kerberos* SRV record for each KDC and one _afs3-* entry for
each AFSDB server.</p>
<p>Note that the hostname specified in a SRV record must not be a
CNAME; it must be A or AAAA records. For the _afs3-* SRV
records for an OpenAFS cell which does not support IPv6 the
specified hostname should not have a AAAA record. The
AuriStorFS cache managers and Linux kernel afs (kafs) clients
will attempt to contact the location servers via IPv6 if there
is a AAAA record specified.</p>
<p>A SRV record whose hostname is "." indicates that the service
is unavailable.<br>
</p>
<p>The AuriStorFS aklog will attempt to acquire both yfs-rxgk
tokens and rxkad_k5 tokens. An OpenAFS cell does not support
yfs-rxgk but aklog doesn't know that until it is explicitly told
by the Kerberos realm that there is no <a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:yfs-rxgk/_afs.unixboxen.net@UNIXBOXEN.NET"
moz-do-not-send="true">yfs-rxgk/_afs.unixboxen.net@UNIXBOXEN.NET</a>
service principal. This requires that GSS-KRB5 be able to
quickly resolve the Kerberos realm for the name
"_afs.unixboxen.net". The SRV record specified above for
_kerberos._afs.unixboxen.net is intended to speed up the
resolution of the hostname to realm mapping if the client is
configured to do so. <br>
</p>
</blockquote>
<p>One thing I forgot to mention. <br>
</p>
<p>The service principal for yfs-rxgk is
<a class="moz-txt-link-abbreviated" href="mailto:yfs-rxgk/_afs.example.net@EXAMPLE.NET">yfs-rxgk/_afs.example.net@EXAMPLE.NET</a> instead of
<a class="moz-txt-link-abbreviated" href="mailto:afs/example.net@EXAMPLE.NET">afs/example.net@EXAMPLE.NET</a> as is used for rxkad_k5. The reason
that _afs.example.net is used is because of how GSS-API Kerberos
v5 implementations resolve the Kerberos realm of a service where
the second component is a hostname. GSS-API will fallback to
using the DNS domain of the hostname as the realm if there is no
other information available. However, many implementations
including macOS and MIT will try to validate the second component
as a valid DNS hostname as part of the lookup process. Therefore
it issues a DNS A and AAAA query for "_afs.example.net" even
though a DNS hostname is not permitted to begin with an
underscore. In hindsight specifying the service principal in
<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/html/draft-wilkinson-afs3-rxgk-afs">https://datatracker.ietf.org/doc/html/draft-wilkinson-afs3-rxgk-afs</a>
with an underscore based hostname was a poor idea. That said,
DNS resolvers and most Kerberos libraries do not perform
validation on the query string and most DNS servers will happily
respond to the out of specification request if there is an entry
present. I therefore suggest creating DNS A and AAAA records for
_afs.example.net to avoid the negative lookup. The address
doesn't matter since the DNS response will not be used to contact
any host. Specifying one of the location servers is reasonable.<br>
</p>
<blockquote type="cite"
cite="mid:ca525faa-e8db-14bb-d2ca-0b04fdae6dda@auristor.com">
<p> </p>
<p>For rxkad_k5 tokens the resolution of which Kerberos realm to
use is performed by enumerating the hostnames of the location
servers, performing an A/AAAA DNS query to obtain the IP
addresses, then performing a PTR record lookup on the IP
addresses. For example </p>
<blockquote>
<p>afsdb1.example.net A -> 192.0.2.23</p>
<p>129.0.2.23 PTR -> host.example.net</p>
<p>_kerberos.host.example.net TXT -> "EXAMPLE.NET"<br>
</p>
<p>_kerberos.example.net TXT -> "EXAMPLE.NET" (queried if
the _kerberos.host.example.net entry is not present)</p>
</blockquote>
<p>If there are more than one location service address, then the
one that is used for resolution of the Kerberos realm can appear
to be random because whichever is first in the list will be
used.</p>
<p>Issuing a "kinit <a class="moz-txt-link-abbreviated
moz-txt-link-freetext" href="mailto:user@EXAMPLE.NET"
moz-do-not-send="true">user@EXAMPLE.NET</a>" against your
realm took a little more than six seconds to perform the DNS
lookups for the kdc on a macOS Ventura 13.4 system. It then
took approximately 180ms to receive the expected principal
unknown response to the AS-REQ. I cannot measure the time to
perform the aklog operations because I cannot obtain a TGT to
test with.</p>
<p>The time for the AuriStorFS v2021.05-28 cache manager on macOS
13.4 to "ls -l /afs/example.net" anonymously was</p>
<ul>
<li>470ms to resolve the location service via DNS (3 RPCs)<br>
</li>
<li>330ms to resolve the location of the "root.cell" volume (2
RPCs + reachability test)<br>
</li>
<li>850ms for the fileserver response to the first RPC including
the fileserver->client callback service TellMeAboutYourself
queries (3 RPCs + reachability tests)<br>
</li>
<li>600ms to read the contents of the root directory and obtain
status info for each entry (3 RPCs)<br>
</li>
</ul>
<p>The ICMP ping rtt from my test system to the location server
averages 115ms. <br>
</p>
<p>If the vlserver and fileserver connections were authenticated
using rxkad or yfs-rxgk the PING|PING_RESPONSE reachability test
for each RX connection would be replaced by a CHALLENGE|RESPONSE
exchange. If the cache manage to fileserver connection was
authenticated using yfs-rxgk, then the fileserver
TellMeAboutYourself query to the cache manager would not be
performed.<br>
</p>
<p>I suspect you can reduce some of the time by adding the DNS
records that are not present in your domain. You can observe
the DNS, Kerberos and AFS queries using wireshark <a
class="moz-txt-link-freetext"
href="https://www.wireshark.org/download.html"
moz-do-not-send="true">https://www.wireshark.org/download.html</a>.
Start a capture and set a filter rule of "dns or rx or kerberos
or icmp or icmpv6".</p>
<p>Feel free to reply privately if you wish to discuss details of
your actual network configuration.</p>
<p>Jeffrey Altman</p>
</blockquote>
<br>
</body>
</html>
--------------1902mjX8mLpHkialJTFJlxse--
--------------ms090400060802040604030109
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DHEwggXSMIIEuqADAgECAhBAAYJpmi/rPn/F0fJyDlzMMA0GCSqGSIb3DQEBCwUAMDoxCzAJ
BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEz
MB4XDTIyMDgwNDE2MDQ0OFoXDTI1MTAzMTE2MDM0OFowcDEvMC0GCgmSJomT8ixkAQETH0Ew
MTQxMEQwMDAwMDE4MjY5OUEyRkQyMDAwMjMzQ0QxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRt
YW4xFTATBgNVBAoTDEF1cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQCkC7PKBBZnQqDKPtZPMLAy77zo2DPvwtGnd1hNjPvbXrpGxUb3
xHZRtv179LHKAOcsY2jIctzieMxf82OMyhpBziMPsFAG/ukihBMFj3/xEeZVso3K27pSAyyN
fO/wJ0rX7G+ges22Dd7goZul8rPaTJBIxbZDuaykJMGpNq4PQ8VPcnYZx+6b+nJwJJoJ46kI
EEfNh3UKvB/vM0qtxS690iAdgmQIhTl+qfXq4IxWB6b+3NeQxgR6KLU4P7v88/tvJTpxIKkg
9xj89ruzeThyRFd2DSe3vfdnq9+g4qJSHRXyTft6W3Lkp7UWTM4kMqOcc4VSRdufVKBQNXjG
IcnhAgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAwgYQGCCsGAQUFBwEBBHgwdjAwBggr
BgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUF
BzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWEx
My5wN2MwHwYDVR0jBBgwFoAULbfeG1l+KpguzeHUG+PFEBJe6RQwCQYDVR0TBAIwADCCASsG
A1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIBFj5odHRwczov
L3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRt
bDCBugYIKwYBBQUHAgIwga0MgapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4g
aXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj
YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRp
ZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8v
dmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTMuY3JsMB8GA1UdEQQY
MBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBQB+nzqgljLocLTsiUn2yWqEc2s
gjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJwV
eycprp8Ox1npiTyfwc5QaVaqtoe8Dcg2JXZc0h4DmYGW2rRLHp8YL43snEV93rPJVk6B2v4c
WLeQfaMrnyNeEuvHx/2CT44cdLtaEk5zyqo3GYJYlLcRVz6EcSGHv1qPXgDT0xB/25etwGYq
utYF4Chkxu4KzIpq90eDMw5ajkexw+8ARQz4N5+d6NRbmMCovd7wTGi8th/BZvz8hgKUiUJo
Qle4wDxrdXdnIhCP7g87InXKefWgZBF4VX21t2+hkc04qrhIJlHrocPG9mRSnnk2WpsY0MXt
a8ivbVKtfpY7uSNDZSKTDi1izEFH5oeQdYRkgIGb319a7FjslV8wggaXMIIEf6ADAgECAhBA
AXA7OrqBjMk8rp4OuNQSMA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK
EwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAe
Fw0yMDAyMTIyMTA3NDlaFw0zMDAyMTIyMTA3NDlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK
EwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAu6sUO01SDD99PM+QdZkNxKxJNt0NgQE+Zt6ixaNP0JKSjTd+SG5L
wqxBWjnOgI/3dlwgtSNeN77AgSs+rA4bK4GJ75cUZZANUXRKw/et8pf9Qn6iqgB63OdHxBN/
15KbM3HR+PyiHXQoUVIevCKW8nnlWnnZabT1FejOhRRKVUg5HACGOTfnCOONrlxlg+m1Vjgn
o1uNqNuLM/jkD1z6phNZ/G9IfZGI0ppHX5AA/bViWceX248VmefNhSR14ADZJtlAAWOi2un0
3bqrBPHA9nDyXxI8rgWLfUP5rDy8jx2hEItg95+ORF5wfkGUq787HBjspE86CcaduLka/Bk2
VwIDAQABo4IChzCCAoMwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwgYkG
CCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVu
dHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t
L3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C
5yZUyI42djCCASQGA1UdIASCARswggEXMIIBEwYEVR0gADCCAQkwSgYIKwYBBQUHAgEWPmh0
dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRl
eC5odG1sMIG6BggrBgEFBQcCAjCBrQyBqlRoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMg
YmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIElkZW5UcnVzdCdzIFRydXN0SUQgQ2Vy
dGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20v
Y2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEoGA1UdHwRDMEEwP6A9oDuGOWh0
dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL2NvbW1lcmNpYWxyb290Y2ExLmNy
bDAdBgNVHQ4EFgQULbfeG1l+KpguzeHUG+PFEBJe6RQwHQYDVR0lBBYwFAYIKwYBBQUHAwIG
CCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4ICAQB/7BKcygLX6Nl4a03cDHt7TLdPxCzFvDF2
bkVYCFTRX47UfeomF1gBPFDee3H/IPlLRmuTPoNt0qjdpfQzmDWN95jUXLdLPRToNxyaoB5s
0hOhcV6H08u3FHACBif55i0DTDzVSaBv0AZ9h1XeuGx4Fih1Vm3Xxz24GBqqVudvPRLyMJ7u
6hvBqTIKJ53uCs3dyQLZT9DXnp+kJv8y7ZSAY+QVrI/dysT8avtn8d7k7azNBkfnbRq+0e88
QoBnel6u+fpwbd5NLRHywXeH+phbzULCa+bLPRMqJaW2lbhvSWrMHRDy3/d8HvgnLCBFK2s4
Spns4YCN4xVcbqlGWzgolHCKUH39vpcsDo1ymZFrJ8QR6ihIn8FmJ5oKwAnnd/G6ADXFC9bu
db9+532phSAXOZrrecIQn+vtP366PC+aClAPsIIDJDsotS5z4X2JUFsNIuEgXGqhiKE7SuZb
rFG9sdcLprSlJN7TsRDc0W2b9nqwD+rj/5MN0C+eKwha+8ydv0+qzTyxPP90KRgaegGowC4d
UsZyTk2n4Z3MuAHX5nAZL/Vh/SyDj/ajorV44yqZBzQ3ChKhXbfUSwe2xMmygA2Z5DRwMRJn
p/BscizYdNk2WXJMTnH+wVLN8sLEwEtQR4eTLoFmQvrK2AMBS9kW5sBkMzINt/ZbbcZ3F+eA
MDGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUG
A1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwDQYJYIZIAWUDBAIBBQCg
ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIzMDUxMzE2
MjE0NVowLwYJKoZIhvcNAQkEMSIEIMzHUfkCJsZM+TGBUOymWwRB0Jrf7JbRllP2Kiob6QBL
MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX
MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ
AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy
dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI
hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAVLyI
W5F/X1Iei2sLrC/iv6Q1Kcj9LP/KBBbxMnBZZdQzAif/aJ0S/itwAExjyxjMROAZilsAJjcF
ICq0zAjIkgPwxzYyita3q/s5WbcDnirjHVoq/S6OTlsEd3TnN1ZgGo6KBl3xNdgG3jehlWiL
BdFtZxDNAk3cHs3WlBJRM3IFkz2Y6rWXSyVYjbwLjA7XJRNtKHLh2uOo4z9gG8elFlCBRXmX
XzQNJwwykWSPV+GfSvjL9XsNjrEmo6LmGeNGCeUTYL2uQ+mX1RfWcFRPW4UUCUPphbhJ6rD3
JG1pHXjJNtOx8TVmW4phwfrd1c+koz6qT9DkaqfVkKzXCP1BcgAAAAAAAA==
--------------ms090400060802040604030109--