From nobody Fri Jun 4 02:42:19 2021 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849123A310B for ; Fri, 4 Jun 2021 02:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=meinberg.de 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 XtmOQ9bsaj6H for ; Fri, 4 Jun 2021 02:42:10 -0700 (PDT) Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E45F3A30D8 for ; Fri, 4 Jun 2021 02:42:09 -0700 (PDT) Received: from seppmail.py.meinberg.de (unknown [193.158.22.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id 42F9F71C0C54 for ; Fri, 4 Jun 2021 11:42:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=dkim; t=1622799727; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=kl56IpBVkw8pvs/G2beNSsxQXb3LKcRZ92cxmE/Ul3k=; b=VTgLA5yc1AR/15szSQc4FosZeRNr03z1v1p6TSjAzIf3BSw3PNga7e87ZZ0auvoTDCrZdm 1DxG4LUVP1x8j72VShP2B7by+RC2D3GtFtT6HV0jw63B6cdQK2dz4G4ldbpdg86XtTFPT/ QAanEnkRZgEYSBjVvahe/xw1Tl8NDlcg5VHAZSB4R6lZp4RlRpSvNdVzYe7VtE8wYWUaMS wYEJQjaerYeI+hR46iQwllZD5LFuovlUaXs0U+RVHIoyjlVlDy2D4wd5ptCL1WFHL0xCPQ MlEj22TWLekyqx/2H57uMXnuOhDaUmpoKoYMaXfWCFh8MqZ2yvQ1OlPR5/DV4g== Received: from srv-kerioconnect.py.meinberg.de (srv-kerioconnect.py.meinberg.de [172.16.3.65]) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by seppmail.py.meinberg.de (Postfix) with ESMTPS for ; Fri, 4 Jun 2021 11:42:06 +0200 (CEST) X-Footer: bWVpbmJlcmcuZGU= User-Agent: Microsoft-MacOutlook/16.49.21050901 Date: Fri, 4 Jun 2021 11:42:01 +0200 Message-ID: <8CE53A7F-022C-41F8-92AE-ACBA9BB7A048@meinberg.de> Thread-Topic: NTS4UPTP Rev 03 - Update submitted Importance: Normal X-Priority: 3 Thread-Index: AZ2x3tU+ZTBjZDEwODk2MzE3OTFjNA== From: Heiko Gerstung To: "ntp@ietf.org" X-SM-outgoing: yes MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----3C9460AC6AB291948423F63E6750A49A" Archived-At: Subject: [Ntp] NTS4UPTP Rev 03 - Update submitted X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2021 09:42:17 -0000 This is an S/MIME signed message ------3C9460AC6AB291948423F63E6750A49A Content-Type: multipart/alternative; boundary="=-mV11bASfJVoBoOPUHQ4Z" MIME-version: 1.0 --=-mV11bASfJVoBoOPUHQ4Z Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi everyone, =20 I just submitted rev-03 of the draft. It contains the following changes/add= itions: =20 added a description about the PTP integrated security mechanism in the intr= oduction and explained that PTP assumes that the key management is done out= side of PTP and we chose NTS-KE added a list of objectives resembling the corresponding list in RFC8915, ex= plaining which of the objectives are met and which are not and why changed the text that unnecessarily talked about not sending a cookie to th= e client (section 6) and explain how to force the client to refresh its key= s when they expired changed the name of Section (now 8, previously 7) from =E2=80=9CAttack Scen= arios=E2=80=9D to =E2=80=9CThreat model=E2=80=9D in this section 8, combined the first bullet and second bullet of the previ= ous revision into one bullet point added a section 9 describing delay attacks, mention the fact that this docu= ment cannot protect against them and give some suggestions what can be done= (protect your infrastructure and check delays on the client) =20 =20 The draft and its latest revison are here: https://datatracker.ietf.org/doc/draft-gerstung-nts4uptp/ =20 The diff can be found here: https://www.ietf.org/rfcdiff?url1=3Ddraft-gerstung-nts4uptp-02&url2=3Ddraft= -gerstung-nts4uptp-03 =20 Looking forward to your comments and feedback!=20 =20 Regards, =C2=A0=C2=A0 Heiko =20 =20 =20 --=20 Heiko Gerstung=20 Managing Director=20 =20 MEINBERG=C2=AE Funkuhren GmbH & Co. KG=20 Lange Wand 9=20 D-31812 Bad Pyrmont, Germany=20 Phone: +49 (0)5281 9309-404=20 Fax: +49 (0)5281 9309-9404=20 =20 Amtsgericht Hannover 17HRA 100322=20 Gesch=C3=A4ftsf=C3=BChrer/Management: G=C3=BCnter Meinberg, Werner Meinberg= , Andre Hartmann, Heiko Gerstung=20 =20 Email:=20 heiko.gerstung@meinberg.de Web:=20 Deutsch https://www.meinberg.de English https://www.meinbergglobal.com =20 Do not miss our Time Synchronization Blog:=20 https://blog.meinbergglobal.com =20 Connect via LinkedIn:=20 https://www.linkedin.com/in/heikogerstung =20 =20 =20 Von: Datum: Donnerstag, 3. Juni 2021 um 14:23 An: Heiko Gerstung Betreff: Antwort: Re: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request f= or WG adoption =20 Okay, I've given the draft a closer read now. Section 2.2 still loses me a bit, as I'm completely unfamiliar with this ki= nd of negotiation, but I think I get the gist of it at least. =20 I have a few concerns about the threat model (Section 7.1): - General point of order about all bullet points: I tend to ignore the thre= ats that are of the same effectiveness as cutting the wire (client might dr= op the association, contract might be cancelled...). If you assume a MITM a= ttacker, you won't prevent this overall issue. - First bullet: yes, this is important, and yes, this is fulfilled to a lar= ge degree. The client can verify that the server said everything the ICV co= vers, and that the message belongs to the correct client-server association= . Delay modifications are not really covered (with a small asterisk because= of sequence numbers that we keep in mind), and this should perhaps be ment= ioned. - Second bullet: very similiar deal to the first bullet - except that it se= ems to me that the server doesn't even care about this protection. - Third bullet: Whenever you discuss replay attacks, I kind of miss a consi= deration about what happens if it's a delay attack instead (which is really= a replay attack with an additional deletion of the original message, if yo= u will). It seems dangerous to just ignore this. This is about phase 2, as = well, and I'm generally unsure about the implications. - Fourth bullet: same deal as above - but here I know for a fact that synch= ronization-wise, delay is about as dangerous (or more) as replay. All of th= e considerations about "consuming resources" seems a bit pointless, since a= n attacker would achieve about the same thing with just random messages whe= re the authentication doesn't check out, wouldn't they? - Fifth bullet: sure. The only comment I might have is that you might want = to clarify that this only prevents problems if this authenticated variant i= s used. But this is a good example of something where replay would actually= be harmful whereas delay wouldn't. =20 I'm missing a clear distinction between the one-way transfer aspect of PTP = (Announce and Sync messsages) and the part that enables two-way-transfer-li= ke behavior (Delay_Req and Delay_Resp messages). Section 5, second-to-last paragraph, goes to some lengths to make sure that= the server never sends new cookies to the client. =20 a) Is there a specific reason why you did not go for full-on NTS4NTP behavi= or for Delay_Req/Resp messages? If this subset of behavior were kept stateless on the server side, I believ= e this would be a good candidate for the kind of frankensteined construct I= was talking about in an earlier mail (do only Delay_Req/Resp exchanges, so= mehow force the client to timestamp reception of Delay_Resp, and you have a= ll you need - three timestamps is really about as good as four). This would also allow you to preserve client unlinkability, if I'm not mist= aken. b) Why does the server have an interest to be able to "force the client to = re-start"? I might have missed it, but I see no motivation for this in the = threat model (and you have no section about your Objectives, which brings m= e to my last point...) =20 Between Sections 1 and 2, I would really encourage you to add a section abo= ut the objectives here. This would be nice so that they can be compared with NTS4NTP, and also to j= udge whether or not we actually see that you fulfill them. =20 =20 That's what I have for now, I might come back to this later after I've had = time to contemplate during a walk or slept over this. Last point of order: none of these are showstoppers for me, they don't chan= ge my stance that I think we can adopt this and discuss further changes/add= itions that people would like to see. =20 =20 Best regards, Kristof =20 =20 -----"ntp" schrieb: ----- An: "kristof.teichel@ptb.de" Von: "Heiko Gerstung"=20 Gesendet von: "ntp"=20 Datum: 03.06.2021 12:31 Kopie: "ntp@ietf.org" Betreff: Re: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG ado= ption =20 > Von: > Datum: Donnerstag, 3. Juni 2021 um 09:39 > An: Heiko Gerstung > Cc: "ntp@ietf.org" > Betreff: Antwort: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adopt= ion >=20 >>>At this point I would be open to change the name of the draft so that it= does > not contain "NTS" anymore, if that helps. It seems that quite a number of= the au > thors do not like that we based our proposal on their work and would rath= er like > unicast PTP to use something else as a key exchange protocol. [...] >=20 > As one of the editors, I do feel misrepresented here. > There are five of us, only three of whom have spoken about NTS4UPTP at al= l, with > only one who spoke out in rejection. =20 Apologies for that, I based that assumption on a feeling and not on factual= data (which is never a good thing IMHO but happens quite frequently in rea= l life :). =20 > I will get back to you (after studying the draft in more detail) on what = I think > about how you based your proposal on our work, but I am perfectly happy t= hat yo > u did. Glad to hear that.=20 =20 > @Daniel: would it change your stance if this draft were not named anythin= g with > "NTS" at all? =20 >>> It is pretty hard to try and compare our proposal against a bunch of id= eas th >>> at are thrown into the discussion. Most of the proposed alternatives se= em simple >>> and easy to describe with two or three sentences, but when we drafted o= ur propo >>> sal, we found out (once again) that when you try to describe something = in writte >>> n form, a lot of details and corner cases come up that you have to deal= with. In >>> the end, you often end up with at least 10-20 pages, no matter how simp= le the i >>> dea sounds in the beginning. >=20 > Yes, absolutely agree. > And in those pages, you are pretty likely to stumble over the detail that= will m > ake your draft more controversial than you thought. For sure, but up until now I cannot say that we actually discussed the draf= t so far. =20 > This is why I want to clarify that (unless I ever explicitly say so) none= of my > technical discussion, wishful thinking or even design sketching is to be = taken a > gainst the NTS4UPTP draft (or other drafts). OK, thanks. It sometimes gets confusing if those ideas/new concepts are inc= luded in a response to a message that deals with the draft.=20 =20 Regards, Heiko --=20 Heiko Gerstung=20 Managing Director=20 =20 MEINBERG=C2=AE Funkuhren GmbH & Co. KG=20 Lange Wand 9=20 D-31812 Bad Pyrmont, Germany=20 Phone: +49 (0)5281 9309-404=20 Fax: +49 (0)5281 9309-9404=20 =20 Amtsgericht Hannover 17HRA 100322=20 Gesch=C3=A4ftsf=C3=BChrer/Management: G=C3=BCnter Meinberg, Werner Meinberg= , Andre Hartmann, Heiko Gerstung=20 =20 Email:=20 heiko.gerstung@meinberg.de Web:=20 Deutsch https://www.meinberg.de English https://www.meinbergglobal.com =20 Do not miss our Time Synchronization Blog:=20 https://blog.meinbergglobal.com =20 Connect via LinkedIn:=20 https://www.linkedin.com/in/heikogerstung =20 =20 =20 _______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp = --=-mV11bASfJVoBoOPUHQ4Z Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi everyone,

 

I just submitted rev-03 of the draft. It contains the following = changes/additions:

 

  • added a description about the PTP integrated security = mechanism in the introduction and explained that PTP assumes that the key m= anagement is done outside of PTP and we chose NTS-KE
    • =
  • added a list of= objectives resembling the corresponding list in RFC8915, explaining which = of the objectives are met and which are not and why
    • <= li class=3DMsoListParagraph style=3D'margin-left:0cm;mso-list:l0 level1 lfo= 1'>changed the text= that unnecessarily talked about not sending a cookie to the client (sectio= n 6) and explain how to force the client to refresh its keys when they expi= red
  • changed the name of Section (now 8, previously 7) from =E2=80=9C= Attack Scenarios=E2=80=9D to =E2=80=9CThreat model=E2=80=9D
  • in this = section 8, combined the first bullet and second bullet of the previous revi= sion into one bullet point
  • added a section 9 describing delay attack= s, mention the fact that this document cannot protect against them and give= some suggestions what can be done (protect your infrastructure and check d= elays on the client)

 <= /p>

 

The draft and its latest revison are her= e:

https://datatracker.ietf.org/doc/draft-gerstung-nts4up= tp/

 

The diff can = be found here:

https://www.ietf.org/rfcdiff?url1=3Ddraft-gerstung-nts4uptp-02&url2=3D= draft-gerstung-nts4uptp-03

 

Looking forward to your comments and feedback! <= /p>

 

Regards,

=C2=A0= =C2=A0 Heiko

 

&nbs= p;

 


-- 

Heiko Gerstung 

Managing Director 

 

MEINBERG=C2=AE Funkuhren GmbH & Co. KG 

Lange Wand 9 

D-31812 Bad Pyrmont, Germany 

Phone:= +49 (0)5281 9309-404 

Fax: +49 (0)5281 9309-94= 04 

 

Amtsgericht H= annover 17HRA 100322 

Gesch=C3=A4ftsf=C3=BChrer= /Management: G=C3=BCnter Meinberg, Werner Meinberg, Andre Hartmann, Heiko G= erstung 

 

Email:=  

heiko.gerstung@meinberg.de

Web: 

Deutsch https://www.meinberg= .de

English https://www.meinbergglobal= .com

 

Do not miss our Time Synchronization Blog: 

https://blog.meinbergglobal.com

 

Connect via= LinkedIn: 

https://www.l= inkedin.com/in/heikogerstung

 

 <= /o:p>

 

Von: <kristof= .teichel@ptb.de>
Datum: Donnerstag, 3. Juni 2021 um 14:23
<= b>An: Heiko Gerstung <heiko.gerstung@meinberg.de>
Betreff: = Antwort: Re: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG= adoption

 

Okay, I've given the draft a closer read now.

Section 2.2 still loses me = a bit, as I'm completely unfamiliar with this kind of negotiation, but I th= ink I get the gist of it at least.

 

I have a few concerns about the threa= t model (Section 7.1):

- General point of order about all bullet points: I te= nd to ignore the threats that are of the same effectiveness as cutting the = wire (client might drop the association, contract might be cancelled...). I= f you assume a MITM attacker, you won't prevent this overall issue.

= - First b= ullet: yes, this is important, and yes, this is fulfilled to a large degree= . The client can verify that the server said everything the ICV covers, and= that the message belongs to the correct client-server association. Delay m= odifications are not really covered (with a small asterisk because of seque= nce numbers that we keep in mind), and this should perhaps be mentioned.

- Se= cond bullet: very similiar deal to the first bullet - except that it seems = to me that the server doesn't even care about this protection.

- Third bullet= : Whenever you discuss replay attacks, I kind of miss a consideration about= what happens if it's a delay attack instead (which is really a replay atta= ck with an additional deletion of the original message, if you will). It se= ems dangerous to just ignore this. This is about phase 2, as well, and I'm = generally unsure about the implications.

- Fourth bullet: same deal as above = - but here I know for a fact that synchronization-wise, delay is about as d= angerous (or more) as replay. All of the considerations about "consumi= ng resources" seems a bit pointless, since an attacker would achieve a= bout the same thing with just random messages where the authentication does= n't check out, wouldn't they?

- Fifth bullet: sure. The only comment I might = have is that you might want to clarify that this only prevents problems if = this authenticated variant is used. But this is a good example of something= where replay would actually be harmful whereas delay wouldn't.<= /span>

 

I'm miss= ing a clear distinction between the one-way transfer aspect of PTP (Announc= e and Sync messsages) and the part that enables two-way-transfer-like behav= ior (Delay_Req and Delay_Resp messages).

Section 5, second-to-last paragraph,= goes to some lengths to make sure that the server never sends new cookies = to the client.

 

a) Is there a specific reason why you did not go for fu= ll-on NTS4NTP behavior for Delay_Req/Resp messages?

If this subset of behavio= r were kept stateless on the server side, I believe this would be a good ca= ndidate for the kind of frankensteined construct I was talking about in an = earlier mail (do only Delay_Req/Resp exchanges, somehow force the client to= timestamp reception of Delay_Resp, and you have all you need - three times= tamps is really about as good as four).

This would also allow you to preserve= client unlinkability, if I'm not mistaken.

b) Why does the server have an in= terest to be able to "force the client to re-start"? I might have= missed it, but I see no motivation for this in the threat model (and you h= ave no section about your Objectives, which brings me to my last point...)<= o:p>

 

Between Sections 1 and 2, I would really encourage you to add a section = about the objectives here.

This would be nice so that they can be compared wi= th NTS4NTP, and also to judge whether or not we actually see that you fulfi= ll them.

 

 

That's what I have for now, I might come back to this late= r after I've had time to contemplate during a walk or slept over this.=

Last p= oint of order: none of these are showstoppers for me, they don't change my = stance that I think we can adopt this and discuss further changes/additions= that people would like to see.

 

 

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>Best regards,

=

Kristof

 =

 

-----"nt= p" <ntp-b= ounces@ietf.org> schrieb: -----

An: "kristof.teichel@ptb.de" <= kristof.teichel= @ptb.de>
Von: "Heiko Gerstung"
Gesendet von: "= ntp"
Datum: 03.06.2021 12:31
Kopie: "ntp@ietf.org" <ntp@ietf.org>
Betreff: Re: [Ntp] A= ntwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption


 

=

> Von: <kristof.teichel@ptb.de>

> Datum: D= onnerstag, 3. Juni 2021 um 09:39

> An: Heiko Gerstung <heiko.gerstung@meinberg.de>=

> Cc: "= ;ntp@ietf.org" &= lt;ntp@ietf.org>

= > Betreff: Antwort: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG ad= option

>

>>>At this point I would be open to change the name= of the draft so that it does

= > not contain "NTS" anymore, if= that helps. It seems that quite a number of the au

> thors do not like= that we based our proposal on their work and would rather like

> unica= st PTP to use something else as a key exchange protocol. [...]

>

>= As one of the editors, I do feel misrepresented here.

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto;margin-left:35.4pt'>> There are five= of us, only three of whom have spoken about NTS4UPTP at all, with=

> on= ly one who spoke out in rejection.

 

Apologies for that, I based that assumption on a feeling and no= t on factual data (which is never a good thing IMHO but happens quite frequ= ently in real life :).

<= span style=3D'font-size:10.0pt;font-family:"Verdana",sans-serif'> 

= > I will get back to you (after studying the draft in more detail) on wh= at I think

> about how you based your proposal on our work, but I am pe= rfectly happy that yo

> u did.

Glad to hear that.

 

> @Daniel: would it change your stanc= e if this draft were not named anything with

> "NTS" at all?<= /span>

 

>>> It is pret= ty hard to try and compare our proposal against a bunch of ideas th<= span style=3D'font-size:10.0pt;font-family:"Verdana",sans-serif'>

>&g= t;> at are thrown into the discussion. Most of the proposed alternatives= seem simple

>>> and easy to describe with two or three sentences= , but when we drafted our propo

>>> sal, we found out (once again= ) that when you try to describe something in writte

>>> n form, a= lot of details and corner cases come up that you have to deal with. In<= /o:p>

&g= t;>> the end, you often end up with at least 10-20 pages, no matter h= ow simple the i

>>> dea sounds in the beginning.<= /p>

> <= /span>

> Yes= , absolutely agree.

> And in those pages, you are pretty likely to stum= ble over the detail that will m

> ake your draft more controversial tha= n you thought.

For sure, but up until now I cannot say that we actually di= scussed the draft so far.

 <= o:p>

> This is why I want to clarify that (unless I ever explicitly say so= ) none of my

> technical discussion, wishful thinking or even design sk= etching is to be taken a

> gainst the NTS4UPTP draft (or other drafts).=

 

Regards,

   Heiko=


-- <= span style=3D'font-size:10.0pt;font-family:"Verdana",sans-serif'>

Heiko Gerstung 

Managing Director 

 

MEINBERG=C2=AE Funkuhren GmbH & Co. KG =

Lange Wand 9 =

D-31812 Bad Pyrmont, = Germany 

Phone: +49 (0)5281= 9309-404 

Fax: +49 (0)5281= 9309-9404 

&n= bsp;

Amtsgericht Hannover 17HRA = 100322 

Gesch=C3=A4ftsf=C3= =BChrer/Management: G=C3=BCnter Meinberg, Werner Meinberg, Andre Hartmann, = Heiko Gerstung 

 

Email: 

heiko.gerstung@meinberg.de<= /o:p>

Web: 

Deutsch https://www.meinberg.de

English https://www.meinbergglobal.com<= /a>

 =

Do not miss our Time Synchr= onization Blog: 

https://blo= g.meinbergglobal.com

 

Connect via LinkedIn: 

= https://www.linkedin.com/in/heikogerstung=

 

 

 

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>_________________= ______________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp

= --=-mV11bASfJVoBoOPUHQ4Z-- ------3C9460AC6AB291948423F63E6750A49A Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIXiwYJKoZIhvcNAQcCoIIXfDCCF3gCAQExDTALBglghkgBZQMEAgEwCwYJKoZI hvcNAQcBoIIT1TCCBbowggOioAMCAQICCQC7QBxD9V5PsDANBgkqhkiG9w0BAQUF ADBFMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMR8wHQYDVQQD ExZTd2lzc1NpZ24gR29sZCBDQSAtIEcyMB4XDTA2MTAyNTA4MzAzNVoXDTM2MTAy NTA4MzAzNVowRTELMAkGA1UEBhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEf MB0GA1UEAxMWU3dpc3NTaWduIEdvbGQgQ0EgLSBHMjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBAK/k7n6LJA4SbqlQLRZEO5KSXMq4XYSSQhMqvGVXgkA+ VyTNUIslKrdv/O+i0MAfAiRKE5aPIxPmKFgAo0fHBqeEIyu7vZYrf1XMi8FXHw5i ZQ/dPVaKc9qufm26gRx+QowgNdlDTYT6hNtSLPMOJ3cLa78RL3J4ny7YPuYYN1oq cvnaYpCSlcofnOmzPCvL8wETv1rPwbUKYL3dtZlkU7iglrNv4iZ3kYzgYhACnzQP pNWSM1Hevo26hHpgPGrbnyvs3t4BP25N5VCGy7Sv7URAxcpajNrSK3yo7r6m5Qqq DqXfBVK3VcciXTJql5djE9vJ23k2e4U6SsVSifkk5513qYL/VRylcWkr0QIk8rMm 1GvaBFXlwQrHbTA3kCrknhQzXhYXVcVbtcs0iZLxnSaPoQfUxrJ4UNsMDAt8C4xB 17np3YyI96NNsjLM2BfazbfOZp3U/V7/vZc+KXXnfqdiWK8lNKVBxz28DVDKAwMP CFoflXN4Yr+vchRpDqXlAw54jiYoQvAHC2IgEGc5RvqpA8wEOHpm7yCDtYxKVo6R APyOXILeiKDD4mhufY3vPN1l9F2sUe8kgK6qVpdv+a192mE/mHc8pZG2HIwm2mWi CW3B4lTjucpMTICPd3tgmh7ftvJIHg66TlRtmODhohqid1DPxGOS7EcZnevma87B AgMBAAGjgawwgakwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFFsle5akZVF+uDnzwHhmXug65/DuMB8GA1UdIwQYMBaAFFsle5akZVF+ uDnzwHhmXug65/DuMEYGA1UdIAQ/MD0wOwYJYIV0AVkBAgEBMC4wLAYIKwYBBQUH AgEWIGh0dHA6Ly9yZXBvc2l0b3J5LnN3aXNzc2lnbi5jb20vMA0GCSqGSIb3DQEB BQUAA4ICAQAnuuOUfPGuwN4X5uXY1fVUsIP0u81eBXtPn3VmrzzoVn78cng4A9kr YhsAufjpYM3MzlGKx1AxbuFKfhgvaVm2PWSBK+ODhOYih4594O4CmWG4HvS4K4gS FoTCMZM4ljGmuTtTP8Mkk1ZbaZLsxcG7OADj7BepuNzHfAGDnzJHulIiNB0yeglW p3wlNqk9S9rAgm8KuxLIh0snEfkeLceTP57bXyZrUtkuivEUxkSNFam3v73ephru ri37SHcX/rvsrxj1KlHwOYSXlWxuG8MrxHRgeSWwCiff317SOc9FfUJL37MsHsXG XcpVOqCcaZqP2u+ysDyfh2wSK2VwFVIxGiTPbzEjUB+MT48jw3RBYxxVqBTdPuBR UM/xGzBWDpKwgoXYg8siZLwtuCXVVKK4BuqtkqQkoMGGtUoTakfPLgtWlVTLzprb arSmsttBCIYnd/dqoEJsCzjO13VQMpLC3yswIkjQ1UE4JV2k6V2fxpR10EX9MJdD j5CrCseGc2BKaS3epXjXBtpqnks+dzogEyIB0L9onmNgazVNC226oT3Ak+B/I7NV rXIlTkb50hbvsGTBAZ7pyqBqmA7P2GDyL0m45ELhODUW9MhuT/eBVui6o74jr679 bwPgAjswdvobbUHPAbHpuMlm9Nsm8zqkdPJJJFvJsNBXwfo+euGXyTCCBrgwggSg oAMCAQICDxkXldwidBsSHdtUTFzL3DANBgkqhkiG9w0BAQsFADBFMQswCQYDVQQG EwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMR8wHQYDVQQDExZTd2lzc1NpZ24g R29sZCBDQSAtIEcyMB4XDTE0MDkxOTE0MTAyNVoXDTI5MDkxNTE0MTAyNVowVDEL MAkGA1UEBhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEuMCwGA1UEAxMlU3dp c3NTaWduIFBlcnNvbmFsIEdvbGQgQ0EgMjAxNCAtIEcyMjCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAJ639E9iRbMeDT2/k1ASJz4L/Z1MhfXTCYe7EC+u h8m6wdnXr6jXNfhqvnxU+LXwWvYWyPsakUagjtC6EDid791zJTs0N80y/m98IA77 P3fLWey1hjkmBePNP6y9WmgSEBZaxOthg0L3JpB/wvEMbEkvk/oGthUIQvwa/27b 3jXD+nM/O1srIRfCFP+7DimKod6OZm8SOuNUdbt/s2ohqvAPettKUqFt2/T9TH+b eM+dYn6m/v0LGLQ7etHcPplREurJPHJfVUS3o3LolxclSWo+2MiE4qK9927s4Xh7 82XcWkEoHqtJiK75l6raZWaKl0Ndoq0e8Ybn/8PVLRQW6gsCAwEAAaOCApQwggKQ MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTa MvlJ+FHMmHFmDNnOttuSPwlL7zAfBgNVHSMEGDAWgBRbJXuWpGVRfrg588B4Zl7o Oufw7jCB/wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNzc2lnbi5u ZXQvNUIyNTdCOTZBNDY1NTE3RUI4MzlGM0MwNzg2NjVFRTgzQUU3RjBFRTCBqKCB paCBooaBn2xkYXA6Ly9kaXJlY3Rvcnkuc3dpc3NzaWduLm5ldC9DTj01QjI1N0I5 NkE0NjU1MTdFQjgzOUYzQzA3ODY2NUVFODNBRTdGMEVFJTJDTz1Td2lzc1NpZ24l MkNDPUNIP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFz cz1jUkxEaXN0cmlidXRpb25Qb2ludDBfBgNVHSAEWDBWMFQGCWCFdAFZAQIBBjBH MEUGCCsGAQUFBwIBFjlodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tL1N3 aXNzU2lnbi1Hb2xkLUNQLUNQUy5wZGYwgcYGCCsGAQUFBwEBBIG5MIG2MGQGCCsG AQUFBzAChlhodHRwOi8vc3dpc3NzaWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9k b3dubG9hZC81QjI1N0I5NkE0NjU1MTdFQjgzOUYzQzA3ODY2NUVFODNBRTdGMEVF ME4GCCsGAQUFBzABhkJodHRwOi8vb2NzcC5zd2lzc3NpZ24ubmV0LzVCMjU3Qjk2 QTQ2NTUxN0VCODM5RjNDMDc4NjY1RUU4M0FFN0YwRUUwDQYJKoZIhvcNAQELBQAD ggIBAK3r26gjjx+r2tMeKBG+FL4slycyKJJeTI0QA5RjAxV2ipudplPiGZSfT43K gYhF4Y4w9aEfLleWlUVlx/mriOiYEGc+S/rtmt9PWw7t23Ip3j+Ob2fpwLqA77pZ sdp6o5aAjrbq2pLO9u8P5xwqM+9t3mB+On4P/6v2uUJzqAXvliImVk+9U3MnF+IY lXD8Faged7S/SDNqntm2pZwqWSqK2VlR0F2FkjuTCAWsP4jDsAgqX5Q0VO+U67hz 43xOAbuFPTZtzQbd83HOcpHEPGWyc5Fi50oti2PK+9VJXN48asljmUG4EteMfwc1 UI+EZPfl/CqLxqaKABVSAUf23VP89iHWZRDYKDzaSaJLhB+TkulGUsjZoYV4yNkB l5/dRvkFePvpK3lc+oXlToQz4DqDn0Vy2BvTv/cKjzLYZlEIHE68pqee2z6TNMyG KR8XCn8YaGKa0HTty7lNRdsZGRNrxS1lQfboB813dQAyCq6xoCVz3zJbl0/cCvAc 03COXDqoREreAMKuavX5oltzlAETi9AmtGf7EUHL7yf3sJWby3bMpnH41eibTe/y AYCCeA/ybOA0VgsAL9Y4QYhBrEQJYYiZnqf/1NRxGk/aK3nbfT2EtYim5HDLgxLT 7mF60PvDkJjBMDGzhW6GTDEzlTTnpyx/hIhugVJ6ME8Kqo7QMIIHVzCCBj+gAwIB AgIURfGn+wJFDWTcXTutjzb6layJR3kwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UE BhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEuMCwGA1UEAxMlU3dpc3NTaWdu IFBlcnNvbmFsIEdvbGQgQ0EgMjAxNCAtIEcyMjAeFw0yMTAxMTQwODUzMzdaFw0y MjAxMTQwODUzMzdaMIGJMQswCQYDVQQGEwJERTELMAkGA1UECBMCTkkxKTAnBgNV BAoMIE1laW5iZXJnIEZ1bmt1aHJlbiBHbWJIICYgQ28uS0cuMSkwJwYJKoZIhvcN AQkBFhpoZWlrby5nZXJzdHVuZ0BtZWluYmVyZy5kZTEXMBUGA1UEAxMOSGVpa28g R2Vyc3R1bmcwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDhgl2MLGl5 kBr8X+M9+CWhC4J4M02UhsI8sKEhrd1/9oP3Taq8F8El+icvADn3kMajKV5yJlMw C0KYx6U/jLe8DasQRZlfBPa63e8iGp6dIqgB0ajcAjpqzN2qWiRY7v6zYCEmOWff asAeABbIWYatq8LAEKyglDtdSYsKNeQPiscuWkOqaThzZWUNeJ7C4MCZdP4H8/jg pZEQCqyFbPp0YFGD67gIp6h8Zkwi3oHJleASHzx28xDqrCyzZpbfRom2iXi5LmtR 9/ZNgWYZAbpdR4BkBikdkW0a3ct/9QssdI7KKXP8filFqrtKvdremEGEnpctK15Q dNrNkIw2jTE7CH7HIDNpybLHFwhy4Lj9Q/n+SKQsIrE4wAMy60C2caoFzZ/M3AmG h6U0TiffOImSEl3QnTW54APvlTlvH0gK/ZGxt5L3YWZWJzdgpHoH0Xlww8YvxDwC ruzG6MZes9juGSW8Xzdh8rKywRA1HcPpQldt5bTyDX1cI1mXUCuQHSTUbt5Q2trm oxeQwnOLo13pBASeStLzlfMcBBtImsqBphBb3cx9YQfhCwoNGVWh11fPP7oiT9+u G4+ny8CJobVe9dXRn8JTgyxoU63IiaSH8zG1pQ7ElPzqrVeOPekLJMmMdE50JGHL gB0UUqMDqhwTDNxO+9lcCBGEW7MgAG+zcwIDAQABo4IC6TCCAuUwJQYDVR0RBB4w HIEaaGVpa28uZ2Vyc3R1bmdAbWVpbmJlcmcuZGUwDgYDVR0PAQH/BAQDAgP4MDUG A1UdJQQuMCwGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoDBAYKKwYBBAGC NxQCAjAdBgNVHQ4EFgQUy5QGsfokKQ25YA+E94Vx0Ep7rmMwHwYDVR0jBBgwFoAU 2jL5SfhRzJhxZgzZzrbbkj8JS+8wgf8GA1UdHwSB9zCB9DBHoEWgQ4ZBaHR0cDov L2NybC5zd2lzc3NpZ24ubmV0L0RBMzJGOTQ5Rjg1MUNDOTg3MTY2MENEOUNFQjZE QjkyM0YwOTRCRUYwgaiggaWggaKGgZ9sZGFwOi8vZGlyZWN0b3J5LnN3aXNzc2ln bi5uZXQvQ049REEzMkY5NDlGODUxQ0M5ODcxNjYwQ0Q5Q0VCNkRCOTIzRjA5NEJF RiUyQ089U3dpc3NTaWduJTJDQz1DSD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0 P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwagYDVR0gBGMw YTBVBglghXQBWQECAQ4wSDBGBggrBgEFBQcCARY6aHR0cHM6Ly9yZXBvc2l0b3J5 LnN3aXNzc2lnbi5jb20vU3dpc3NTaWduLUdvbGQtQ1AtQ1BTLnBkZjAIBgYEAI96 AQEwgcYGCCsGAQUFBwEBBIG5MIG2MGQGCCsGAQUFBzAChlhodHRwOi8vc3dpc3Nz aWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC9EQTMyRjk0OUY4NTFD Qzk4NzE2NjBDRDlDRUI2REI5MjNGMDk0QkVGME4GCCsGAQUFBzABhkJodHRwOi8v b2NzcC5zd2lzc3NpZ24ubmV0L0RBMzJGOTQ5Rjg1MUNDOTg3MTY2MENEOUNFQjZE QjkyM0YwOTRCRUYwDQYJKoZIhvcNAQELBQADggEBAEh8pTMT9D2Fv+NfI31d+1mJ 2MulE0VZyCTapYpOnpd9QPganWt096mYMR7wK3ogNwoQWeOi65Mq5LIr3TXA78ga mWuPUbankBpFRk8+1aNR2P6+PNFxJuXobJk4REFsSGoQD3jc7dlYyFvER1PX/ipV byKRGS2KZn0BCaXpXxHdANfHdrq1MWymLxRr7QSKELdUOc9+4BQo+bLR3Bpq3Jbe rzCYqTnLLHFwd+IC8Q7fqnVCche1+3kA2P+vUoVRuHpdaSyflm0NwcasvkvF3UV6 /+FjARDzvOfjWcyNzvXzBywpZoeDGZrXZH1BiwEqQh6aWEMugRs+7mVEBJdkSpYx ggN8MIIDeAIBATBsMFQxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24g QUcxLjAsBgNVBAMTJVN3aXNzU2lnbiBQZXJzb25hbCBHb2xkIENBIDIwMTQgLSBH MjICFEXxp/sCRQ1k3F07rY82+pWsiUd5MAsGCWCGSAFlAwQCAaCB5DAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA2MDQwOTQyMDda MC8GCSqGSIb3DQEJBDEiBCDp4M880TLfLf9hv4q7bipy32l0KlX1c7K3in9IM97v yTB5BgkqhkiG9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJ YIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAgA1 9jYXyEe7mKgftvCRIraQztHFO5/GS/tPLLcVSSNAu2LINoWjRYJMoX/6VNs/fkha SHr+NrhZvnsLnYygqzEaRBg65H0cmZ95ukuan1dTB9yhMtMo8gB+UDtn0wy/KCMz uvnVkTgANHd/rVh8x9v7tA9/XTzZ+r5oue+KIj5UHtvuuWZ77nngUqklsvCDEt52 MRQKPHdBbkH5vsoh3WI33BiFsEkCCoqW9BqQ5jnld0QaL07ShgXqNGABwq+p/Eby qzUfA/q1jkPaoyLiL7KVIWLOUylhcMgYppExVEawzFXOYAUPAXSwVpRRDAuUgcME Iwt+hkuQRNROre3rocIPMkd540AelKhhaMlAx2xGiEHhxP04pzBc2vJR61B6FLjh XvzRl/5lG9N1vUoJ0we2VCWtFrfILnv1HT4a3ctJK4G3UyklJHs0PrrKkl6yaiSc XkvrwCH33sNQHNmwhAl2E4o4w6AntxTUdfyt+rBn4jlSpQUb+hvliBVttYkMkbqS lwRvXxWVfh42plD4QiRYkrbGcG506AuPPlsyyyp3f/gZ/OX+McdunPMNgjlKycxE gByfJ/nzHyYtgMORZkZOjT3upXpfPeo4ME8yd5aQsL5SW+XvchUgVYMHECQaps94 eNQLQ2aOn3nHJ0pC5SaNCZ2ib5Ba4m6L9Jq43/T/bQ== ------3C9460AC6AB291948423F63E6750A49A--