Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87DD12B26C for ; Mon, 26 Sep 2016 06:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYUNmovz5ZT7 for ; Mon, 26 Sep 2016 06:46:43 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF82512B239 for ; Mon, 26 Sep 2016 06:46:42 -0700 (PDT) X-AuditID: c1b4fb3a-ab7ff7000000099a-05-57e926bfdcc4 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 88.98.02458.FB629E75; Mon, 26 Sep 2016 15:46:40 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.301.0; Mon, 26 Sep 2016 15:46:37 +0200 To: =?UTF-8?Q?Ren=c3=a9_Hummen?= References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> <5756C81D.3080601@ericsson.com> From: Miika Komu Organization: Ericsson AB Message-ID: <1ade65d6-187e-20e0-fb9b-c3d5b73f42df@ericsson.com> Date: Mon, 26 Sep 2016 16:46:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060407030206030908000109" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2K7q+4BtZfhBpduSVlMXTSZ2WLxuW9s DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfGrfknGAsmTmSsaL13h62B8UF2FyMnh4SA icTno8vYuxi5OIQE1jNKPFz8lgnCWc0o0fT6DCNIlbCAtcTUDzfZQWwRAQuJCWvXMEIUTWSS aP7awNrFyMHBLCAqsX1WFUgNm4CWxKo715lBbH4BSYkNDbvBbF4Be4n2Ww9YQWwWAVWJ/n+z wWxRgQiJWw87WCBqBCVOznwCZnMKBEpcObSZDWQXs0A3o8ScHVMZQXYJCahIXDwWPIFRYBaS llnIykASzAJmEvM2P2SGsLUlli18DWVbS8z4dZANwlaUmNL9kB3CNpV4ffQjVK+xxLJ1f9kW MHKsYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMioNbflvtYDz43PEQowAHoxIPb8KN5+FC rIllxZW5hxhVgOY82rD6AqMUS15+XqqSCO8FlZfhQrwpiZVVqUX58UWlOanFhxilOViUxHnN Vt4PFxJITyxJzU5NLUgtgskycXBKNTCu3lG8rclhq/c6j1UmS/yK/kSkHL/3WvzsPcXWLytO XVm2/coaESUdx4lCj7OasycUvo7U4JOePlXmgsDt8DOLcvMPXRf8Jsz5a/7/96/mV9u67pgp tNDr5vytf6auE+1NjngQs83hy88bKzv2a2w0/uumV7PoycU/8rP2qBsbmjMt8tCUf539VYml OCPRUIu5qDgRAL2r4NWSAgAA Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 13:46:57 -0000 --------------ms060407030206030908000109 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Ren=C3=A9, On 09/11/2016 11:06 PM, Ren=C3=A9 Hummen wrote: > Hello Miika, > > going through your email again, I saw a total of four suggestions. > > Three of them refer to imprecisions in the text of RFC 7401 (which I > copy/pasted for HIP DEX). There, I understood that consistency with RFC= > 7401 has a higher priority than only fixing your comments for HIP DEX, > but keeping the text as is for RFC 7401. This means, I will not modify > the text in the HIP DEX draft. Is this also your intention? yes, 7401 takes precedence over my comments. > The last remaining issue is related to the UPDATE message and the > rekeying procedure (Section 6.10.). Here, I added the following > paragraph for clarification purposes: > > [RFC7402] specifies the rekeying of an existing HIP SA using the > UPDATE message. This rekeying procedure can also be used with HIP > DEX. However, where rekeying involves a new Diffie-Hellman key > exchange, HIP DEX peers MUST establish a new connection in order to > create a new Pair-wise Key SA due to the use of static ECDH key-pair= s > with HIP DEX. > > Does this fix your issue? Yes. I assume you mean a new HIP association with connection. > BR > Ren=C3=A9 > > > > On Tue, Jun 7, 2016 at 3:11 PM, Miika Komu > wrote: > > Hi, > > On 06/03/2016 02:20 PM, Ren=C3=A9 Hummen wrote: > > This is part 3 of 3. > > > I am fine with your fixes. Some comments below. > > On Mon, Mar 28, 2016 at 10:05 PM, Miika Komu > > >> wrote: > > > [...] > > > 6.2.1. CMAC Calculation > > > > [...] > > > > > > 5. Set Checksum and Header Length fields in the HIP > header to > > original values. Note that the Checksum and Length fiel= ds > > contain incorrect values after this step. > > I guess also the values following HIP_MAC should be restore= d > since > they were wiped in the step 2. > > > I also found this description a bit imprecise, but it is taken = from > RFC7401. Step 2 already hints at the fact that parameters follo= wing > HIP_MAC may still be of interest: > "Remove the HIP_MAC parameter, as well as all other parameters > that follow it with greater Type value, saving the > contents if > they will be needed later." > > The question is whether we want to fix the description for HIP > DEX or to > keep things as they are for consistency reasons. In the former > case, I > would prefer to completely rewrite the verification procedure t= o > work on > the received packet without removing any parameters. However, w= e > should > then probably also post an errata to RFC7401. If there are no s= tong > opinions about that, I would go for the latter option. > > > Latter option works for me too. > > > The CKDF-Extract function is the following operation: > > > > CKDF-Extract(I, IKM, info) -> PRK > > What does the arrow operator signify? I thought that it > produces PRK, > but PRK is actually defined below. > > > The arrow is part of a basic mathematical function definition. > So yes, > PRK is the output (domain), but we still need to give it a > proper name. > I changed the artwork to clearly point out the inputs and outpu= ts. > > > Thanks, it is now better. > > Please check this section again in the updated version and get > back to > me if the above changes do not sufficiently help your understan= ding. > > > It is good now, thanks! > > > L length of output keying material in octets > > (<=3D 255*RHASH_len/8) > > | denotes the concatenation > > > > The output keying material OKM is calculated as follows:= > > > > N =3D ceil(L/RHASH_len/8) > > T =3D T(1) | T(2) | T(3) | ... | T(N) > > OKM =3D first L octets of T > > > > where > > > > T(0) =3D empty string (zero length) > > T(1) =3D CMAC(PRK, T(0) | info | 0x01) > > T(2) =3D CMAC(PRK, T(1) | info | 0x02) > > T(3) =3D CMAC(PRK, T(2) | info | 0x03) > > ... > > The Expand was a bit more clear, but still didn't understan= d > how to > get to the > Expanded key material due the arrow notation. > > > Ok, let's clarify this as several comments are related to the a= rrow > notation. For the function definition we use the mathematical a= rrow > notation (same as RFC 5869) and for the actual opertation we us= e the > equals sign (same as RFC 5869). In the end, they denote the sam= e > thing: > "assign X to Y". > > > Ok, this is what I guessed too. > > > (where the constant concatenated to the end of each T(n)= is a > > single octet.) > > Is there a max value? > > > I am not sure what you mean here. If you refer to the N in T(N)= > then it > is defined above as N =3D ceil(L/RHASH_len/8). > > > Yes, I asked about the maximum value for N (which depends on L), bu= t > never mind. > > > 8. The R1 packet may have the A-bit set - in this case= , > the system > > MAY choose to refuse it by dropping the R1 packet and > returning > > to state UNASSOCIATED. The system SHOULD consider > dropping the > > R1 packet only if it used a NULL HIT in the I1 packet. > > I didn't understand the logic in the last sentence. > > > Someone must have had a reason for this recommendation, but tha= t > someone > wasn't me. This is text from RFC7401. Any suggestions how to > proceed? > > > Fix similarly as the other RFC7401 issue in the beginning of this e= mail. > > > 6.7. Processing Incoming I2 Packets > > > > [...] > > > > 5. If the system's state machine is in the I2-SENT > state, the > > system MUST make a comparison between its local and send= er's > > HITs (similarly as in Section 6.3). If the local HIT is= > smaller > > than the sender's HIT, it should drop the I2 packet, use= the > > peer Diffie-Hellman key, ENCRYPTED_KEY keying material > and nonce > > #I from the R1 packet received earlier, and get the loca= l > > Diffie-Hellman key, ENCRYPTED_KEY keying material, and > nonce #J > > from the I2 packet sent to the peer earlier. Otherwise,= the > > system should process the received I2 packet and drop an= y > > previously derived Diffie-Hellman keying material Kij an= d > > ENCRYPTED_KEY keying material it might have generated up= on > > sending the I2 packet previously. The peer > Diffie-Hellman key, > > ENCRYPTED_KEY, and the nonce #J are taken from the just > arrived > > I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY > keying > > material, and the nonce #I are the ones that were sent > earlier > > in the R1 packet. > > Please replace "sender" with "peer" (or remote host) in thi= s > section > for more symmetric terminology. > > get -> obtain > > > I can make these changes if you insist, but I was going for a > minimal > diff to RFC 7401. > > > Not insisting. > > > > 11. The implementation SHOULD also verify that the > Initiator's HIT > > in the I2 packet corresponds to the Host Identity sent i= n > the I2 > > packet. (Note: some middleboxes may not be able to make= this > > verification.) > > Why SHOULD? Why not MUST? I think we're talking about > end-hosts here > anyway. > > > It is defined this way in RFC 7401. Do you really want to chang= e the > packet processing behavior for HIP DEX only? > > > Fix similarly as the first RFC7401 issue in this email. > > > 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets > > > UPDATE, CLOSE, and CLOSE_ACK packets are handled > similarly in HIP DEX > > as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 o= f > [RFC7401]). > > The only difference is the that the HIP_SIGNATURE is > never present > > and, therefore, is not required to be processed by the > receiving > > party. > > How does rekeying work with the extract and expand function= s? > > > Rekeying is not defined in this document, same as for RFC 7401.= That > being said, the rekeying procedure with reuse of the KEYMAT fro= m RFC > 7402 directly translates to HIP DEX. For new KEYMAT, the peers > need to > establish a new connection due to the use of static DH keys. > > > Maybe this should be explicitly stated in the draft. > > > > > 7. HIP Policies > > > There are a number of variables that will influence the > HIP exchanges > > that each host must support. All HIP DEX implementation= s > SHOULD > > provide for an ACL of Initiator's HI to Responder's HI. > This ACL > > SHOULD also include preferred transform and local lifeti= mes. > > Wildcards SHOULD also be supported for this ACL. > > Why ACLs are mandatory? > > > It is not a MUST and considering that HIP DEX is primarly > targeted at > things, there is the need to do basic device authorizations > (based on > their identities) without a human in the loop. Of course you ar= e > also > allowed to use more suffisticated authorization mechanisms. > > > Ok. > > ACL -> ACL consisting of > > > Changed to the following text that is closer to RFC 7401: > " All HIP DEX implementations SHOULD provide for an Access > Control List > (ACL), representing for which hosts they accept HIP diet > exchanges, > and the preferred transport format and local lifetimes. > Wildcarding > SHOULD be supported for such ACLs." > > > 8. Security Considerations > > > o The HIP DEX HIT generation may present new attack > opportunities. > > They cannot be used in ACLs. Maybe this could be mentioned.= > Can this > be mitigated by always using full HIs? > > > I changed the bullet-point as follows: > "The HIP DEX HIT generation may present new attack opportunitie= s. > Hence, HIP DEX HITs should not be use as the only means = to > identify a peer in an ACL. Instead, the use of the > peer's HI is > recommended." > > > Ok. > > Note that I added a new Section 8 "Interoperability between HIP= > DEX and > HIPv2" to satisfy your comment on HIP DEX and HIPv2 compatibili= ty. > > > Thanks! > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > > --------------ms060407030206030908000109 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 DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwOTI2MTM0NjM4 WjAvBgkqhkiG9w0BCQQxIgQg7B0V16sQ2vJb8zFpTGnSzNtCpl2EHujPWe0xHvzfWpQwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBRtWEQBgwY DvGnv2TYzDCeZBsyVgQbEas/BZdw+Qv15y/cFfYg8uTefI/qvKNcPbd3icmE3nKx2beO4jp8 quefqREs2YehwEX/NlVKPHUPjVdJma4vuRZlqeOPX2kZE9r22TwmYhELdBIHqmA/3US8S3fd Hbi+EEji5xGlGEuESYz13I7LiC140EDTLuAvzVksjoOyHaaHYIIjjqFKUmSlX0dLR3MTveWp pjWcqGPPjy1DSEnyQMU4thaLMUk3bwHE/noug6h857PvSuW2yuQJWMbE1tqDrEVbX8+QR4h7 WeFJKVmUnP1Jk2LNnQGMTCQLr4FVQfFnm28NMDjxMCLyAAAAAAAA --------------ms060407030206030908000109--