From nobody Thu Aug 1 00:00:19 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22762120058 for ; Thu, 1 Aug 2019 00:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=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=gmail.com 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 oMdoSGUNZcsB for ; Thu, 1 Aug 2019 00:00:14 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C5E12000F for ; Thu, 1 Aug 2019 00:00:14 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id i21so68253385ljj.3 for ; Thu, 01 Aug 2019 00:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=9AWarMx8PL+3ahxk0KAKHiklD3RGG0o08JetRZdzIu4=; b=hxMcCHWrxSsb8jV7Nx80ppSDMuTqNKB7G9oZ9xxjPf//QJAw17hptf6ovwZH51JwlP Vf+icKBvVT/11SWdba9uokehiITeyCV6NqbrVZ9ruH4gfCCm2rNjQm9H5oRdDHYyFl/O ah3CXwuCibZi+3AL3tKv8mUF5xYcqDjwdEQBzJvQax6hXfG7GYf3yLqvm1oWf29xOIOl 3ZjYdFgRbrYjNBIibk6iKDYWHI9ktPqqDRlwsj+FMT+HIPu4RStrUgldl5zonjehIKGo zWxHXMTi4id7DJI1zhdI+5eLDY5RxXNI3xDG8fnvgSM8X17ASryatxOlUCI1y8uuu8Wo bKCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=9AWarMx8PL+3ahxk0KAKHiklD3RGG0o08JetRZdzIu4=; b=L641rxMFmBHdKOBQ1UFT4WIGweaHROrH9zYDmXA3HTXKAp+cmd953B8UF0oNCY3kJN EeTcgs/sC01sS6xGH4sAAikuhfdxJBzLpL2v3E2/XC00db0Of50Fb6TjJvNJt5o1FQNx k2r+YL4V17X0UvbaZ41h9Mv9RT744RccX0pRCj/5gaMynBO0aaRriRHn9o/4wASuHPJG RFo++90t23HXnw1hUJ2cqQu+00mJe117NEZBCaVs5oHvQk0ldB+ocjWsKF3MQk5CKogu hWzz54Av/KW6y8/AEV3zbb0TwEWq49q00ohPCYYam2vhDMwl6ez1lFZ2NSImyWzCPyj/ OySw== X-Gm-Message-State: APjAAAW6bfLyP34ZT1np8xpDr+n/Gj6fNYERIX375b54uLHOg6DzkP2D tdzNxBeWjDmFwSBO8J6dY+PW+DhqnRLFYmqfhWkh5Rfe X-Google-Smtp-Source: APXvYqz668JxUluYeRswV7F42HHVICBQNKlHGYrjVxx/ehRiTv2WSKMSv+FqyljaUPzjKtguLK+nEnZWapeguW+mcTw= X-Received: by 2002:a2e:834e:: with SMTP id l14mr20717732ljh.158.1564642812124; Thu, 01 Aug 2019 00:00:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shubham mamodiya Date: Thu, 1 Aug 2019 12:30:00 +0530 Message-ID: To: ipsec@ietf.org Content-Type: multipart/alternative; boundary="00000000000004637c058f08cbac" Archived-At: Subject: Re: [IPsec] IPsec Digest, Vol 181, Issue 4 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 07:00:18 -0000 --00000000000004637c058f08cbac Content-Type: text/plain; charset="UTF-8" 3.2.3. Rekeying IKE SAs When Responder's Cryptographic Suites Changed At the time of or before rekeying IKE SAs, the responder's cryptographic suites may be changed while there is no change of initiator's cryptographic suites. New cryptographic suites may be added to the responder, or some outdated cryptographic suites may be deleted from the responder. In this situation, the initiator sends the SA_UNCHANGED notification payload instead of the SA payloads in the CREATE_CHILD_SA request message at the time of rekeying IKE SAs. Kampati, et al. Expires November 22, 2019 [Page 5]Internet-Draft IKEv2 Optional Child SA&TS Payloads May 2019 If the responder decides to continue using the previously negotiated cryptographic suite to rekey the IKE SA, it MAY send the SA_UNCHANGED notification payload in the CREATE_CHILD_SA response message, then the rekeying is conducted like Section 3.2.1. If the responder decides to re-negotiate the cryptographic suite, it MUST send NO_PROPOSAL_CHOSEN notification payload in the CREATE_CHILD_SA response message. After receiving this error notification, the initiator MUST retry the CREATE_CHILD_SA exchange with the SA payloads. Then the rekeying is conducted in the original way defined in [RFC7296]. The CREATE_CHILD_SA message exchange in this case is shown below: Initiator Responder -------------------------------------------------------------------- HDR, SK {N(SA_UNCHANGED), Ni, KEi} --> <-- HDR, SK {N(NO_PROPOSAL_CHOSEN), Nr, KEr} HDR, SK {SA, Ni, KEi} --> <-- HDR, SK {SA, *Ni, KEi*} Comment : 1. If the responder decides to continue using the previously negotiated cryptographic suite to rekey the IKE SA, it MAY send the SA_UNCHANGED notification payload in the CREATE_CHILD_SA response message, then the rekeying is conducted like Section 3.2.1. >> Better to put exchange diagram for this case also. 2. Nonce and KE notations are not correct in the response message If the responder decides to re-negotiate the cryptographic suite, it MUST send NO_PROPOSAL_CHOSEN notification payload in the CREATE_CHILD_SA response message. After receiving this error notification, the initiator MUST retry the CREATE_CHILD_SA exchange with the SA payloads. Then the rekeying is conducted in the original way defined in [RFC7296]. The CREATE_CHILD_SA message exchange in this case is shown below: Initiator Responder -------------------------------------------------------------------- HDR, SK {N(SA_UNCHANGED), Ni, KEi} --> <-- HDR, SK {N(NO_PROPOSAL_CHOSEN), Nr, KEr} HDR, SK {SA, Ni, KEi} --> <-- HDR, SK {SA, *Ni, KEi*} >> In CREATE_CHILD_SA response message, responder MUST not send the same Nonce and KE received from initiator (Ni, KEi). It MUST be Nr and KEr in the response message. On Thu, May 23, 2019 at 12:30 AM wrote: > Send IPsec mailing list submissions to > ipsec@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/ipsec > or, via email, send a message with subject or body 'help' to > ipsec-request@ietf.org > > You can reach the person managing the list at > ipsec-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of IPsec digest..." > > > Today's Topics: > > 1. Fwd: New Version Notification for > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt > (Panwei (William)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 22 May 2019 07:37:17 +0000 > From: "Panwei (William)" > To: Paul Wouters , Y Sowji , > "ipsec@ietf.org" > Cc: Sandeep Kampati , "Meduri S S Bharath > (A)" > Subject: [IPsec] Fwd: New Version Notification for > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt > Message-ID: > < > 30E95A901DB42F44BA42D69DB20DFA6A69F68ABE@nkgeml513-mbx.china.huawei.com> > > Content-Type: text/plain; charset="utf-8" > > Hi Paul, Sowjanya and folks, > > > > Thanks a lot for Paul and Sowjanya?s reviews, we have modified our draft > based on your comments. > > > > The new version draft includes the following main changes: > > 1. Redesign the sections to make the structure more reasonable and the > draft more readable. > > 2. Change the negotiation of support to the IKE_AUTH phase, and change the > support notification?s name. > > 3. Detail the optimization for rekeying IKE SAs, and use SA_UNCHANGED > notification payload to replace SA payloads. > > 4. Detail the optimization for rekeying Child SAs, and use SA_TS_UNCHANGED > notification payload to replace SA and TS payload. > > 5. For rekeying Child SAs, we currently remove the consideration that only > omitting TS payloads, because we think this kind omitting will introduce > more complexities. Initiator SA payload, Initiator TS payload, Responder SA > payload and Responder TS payload, if either of these four payloads can be > omitted, there will be up to 16 circumstances, that will be too complex. > > > > Comments and reviews for the new version draft are very welcome. > > > > Best Regards > > Wei Pan > > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, May 22, 2019 2:17 PM > To: Meduri S S Bharath (A) ; Meduri S S > Bharath (A) ; Panwei (William) < > william.panwei@huawei.com>; Sandeep Kampati > Subject: New Version Notification for > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt > > > > > > A new version of I-D, draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt > > has been successfully submitted by Wei Pan and posted to the IETF > repository. > > > > Name: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt > > Revision: 01 > > Title: IKEv2 Optional SA&TS Payloads in Child Exchange > > Document date: 2019-05-21 > > Group: Individual Submission > > Pages: 11 > > URL: > https://www.ietf.org/internet-drafts/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt > > Status: > https://datatracker.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt/ > > Htmlized: > https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01 > > > > Abstract: > > This document describes a method for reducing the size of the > > Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying > > IKE SAs and Child SAs by removing or making optional of SA & TS > > payloads. Reducing size of IKEv2 exchanges is desirable for low > > power consumption battery powered devices. It also helps to avoid IP > > fragmentation of IKEv2 messages. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > The IETF Secretariat > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/ipsec/attachments/20190522/fa389580/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > ------------------------------ > > End of IPsec Digest, Vol 181, Issue 4 > ************************************* > --00000000000004637c058f08cbac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
3.2.3.  Rekeying IKE SAs When R=
esponder's Cryptographic Suites Changed

   At the time of or before rekeying IKE SAs, the responder's
   cryptographic suites may be changed while there is no change of
   initiator's cryptographic suites.  New cryptographic suites may be
   added to the responder, or some outdated cryptographic suites may be
   deleted from the responder.

   In this situation, the initiator sends the SA_UNCHANGED notification
   payload instead of the SA payloads in the CREATE_CHILD_SA request
   message at the time of rekeying IKE SAs.

Kampati, et al.=
         Expires November 22, 2019               [Page 5]
Internet-Draft =
    IKEv2 Optional Child SA&TS Payloads          May 2019

   If the responder decides to continue using the previously negotiated
   cryptographic suite to rekey the IKE SA, it MAY send the SA_UNCHANGED
   notification payload in the CREATE_CHILD_SA response message, then
   the rekeying is conducted like Section 3.2.1.

   If the responder decides to re-negotiate the cryptographic suite, it
   MUST send NO_PROPOSAL_CHOSEN notification payload in the
   CREATE_CHILD_SA response message.  After receiving this error
   notification, the initiator MUST retry the CREATE_CHILD_SA exchange
   with the SA payloads.  Then the rekeying is conducted in the original
   way defined in [RFC7296].  The CREATE_CHILD_SA message exchange in
   this case is shown below:

   Initiator                         Responder
   --------------------------------------------------------------------
   HDR, SK {N(SA_UNCHANGED), Ni, KEi} -->
                                 <-- HDR, SK {N(NO_PROPOSAL_CHOSEN),
                                         Nr, KEr}
   HDR, SK {SA, Ni, KEi} -->
                                 <-- HDR, SK {SA, Ni, KEi}
<= pre style=3D"box-sizing:border-box;overflow:auto;font-family:"PT Mono&= quot;,Monaco,monospace;font-size:14px;padding:10px;margin-top:0px;margin-bo= ttom:10.5px;line-height:1.214;color:rgb(0,0,0);word-break:break-all;word-wr= ap:break-word;background-color:rgb(255,253,245);border:1px solid rgb(204,20= 4,204);border-radius:4px">Comment : 
1. If =
the responder decides to continue using the previously negotiated
cryptographic suite to rekey the IKE SA, it MAY s= end the SA_UNCHANGED notification payload in the CREATE_CHILD_SA response message, then the rekeying is conducted like Section 3.2.1.
>> Better to put exchange diagram for this case also.

2. Nonce and KE=
 notations are not correct in the response message
 If the responder decides to re=
-negotiate the cryptographic suite, it
   MUST send NO_PROPOSAL_CHOSEN notification payload in the
   CREATE_CHILD_SA response message.  After receiving this error
   notification, the initiator MUST retry the CREATE_CHILD_SA exchange
   with the SA payloads.  Then the rekeying is conducted in the original
   way defined in [RFC7296].  The CREATE_CHILD_SA message exchange in
   this case is shown below:

   Initiator                         Responder
   --------------------------------------------------------------------
   HDR, SK {N(SA_UNCHANGED), Ni, KEi} -->
                                 <-- HDR, SK {N(NO_PROPOSAL_CHOSEN),
                                         Nr, KEr}
   HDR, SK {SA, Ni, KEi} -->
                                 <-- HDR, SK {SA, Ni, KEi}
<=
pre style=3D"box-sizing:border-box;overflow:auto;font-family:"PT Mono&=
quot;,Monaco,monospace;padding:10px;margin-top:0px;margin-bottom:10.5px;lin=
e-height:1.214;word-break:break-all;word-wrap:break-word;border:1px solid r=
gb(204,204,204);border-radius:4px">>> In CREATE_CHILD_SA response mes=
sage, responder MUST not send the same Nonce and KE received from initiator=
 (Ni, KEi).
It MUST be Nr and KEr =
in the response message.

On Thu, May 23, 2019 at 12:30 AM <ipsec-request@ietf.org> wrot= e:
Send IPsec ma= iling list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ipsec@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/= listinfo/ipsec
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ipsec-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ipsec-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of IPsec digest..."


Today's Topics:

=C2=A0 =C2=A01. Fwd: New Version Notification for
=C2=A0 =C2=A0 =C2=A0 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt<= br> =C2=A0 =C2=A0 =C2=A0 (Panwei (William))


----------------------------------------------------------------------

Message: 1
Date: Wed, 22 May 2019 07:37:17 +0000
From: "Panwei (William)" <william.panwei@huawei.com>
To: Paul Wouters <pa= ul@nohats.ca>, Y Sowji <sowji_eluri@yahoo.com>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "ipsec@ietf.org" <ipsec@ietf.org>
Cc: Sandeep Kampati <sandeepkampati@huawei.com>, "Meduri S S Bharath
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (A)" <MeduriS.Bharath@huawei.com>
Subject: [IPsec] Fwd: New Version Notification for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-= 01.txt
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <30E95A901= DB42F44BA42D69DB20DFA6A69F68ABE@nkgeml513-mbx.china.huawei.com>

Content-Type: text/plain; charset=3D"utf-8"

Hi Paul, Sowjanya and folks,



Thanks a lot for Paul and Sowjanya?s reviews, we have modified our draft ba= sed on your comments.



The new version draft includes the following main changes:

1. Redesign the sections to make the structure more reasonable and the draf= t more readable.

2. Change the negotiation of support to the IKE_AUTH phase, and change the = support notification?s name.

3. Detail the optimization for rekeying IKE SAs, and use SA_UNCHANGED notif= ication payload to replace SA payloads.

4. Detail the optimization for rekeying Child SAs, and use SA_TS_UNCHANGED = notification payload to replace SA and TS payload.

5. For rekeying Child SAs, we currently remove the consideration that only = omitting TS payloads, because we think this kind omitting will introduce mo= re complexities. Initiator SA payload, Initiator TS payload, Responder SA p= ayload and Responder TS payload, if either of these four payloads can be om= itted, there will be up to 16 circumstances, that will be too complex.



Comments and reviews for the new version draft are very welcome.



Best Regards

Wei Pan



-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, May 22, 2019 2:17 PM
To: Meduri S S Bharath (A) <MeduriS.Bharath@huawei.com>; Meduri S S Bharath = (A) <Med= uriS.Bharath@huawei.com>; Panwei (William) <william.panwei@huawei.com>= ; Sandeep Kampati <sandeepkampati@huawei.com>
Subject: New Version Notification for draft-kampati-ipsecme-ikev2-sa-ts-pay= loads-opt-01.txt





A new version of I-D, draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt=

has been successfully submitted by Wei Pan and posted to the IETF repositor= y.



Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-kampati-ipsecme-= ikev2-sa-ts-payloads-opt

Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A001

Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IKEv2 Optiona= l SA&TS Payloads in Child Exchange

Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02019-05-21

Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission=

Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/dr= aft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt

Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-kampati-ipsecme= -ikev2-sa-ts-payloads-opt/

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-= payloads-opt-01

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-kampati-ips= ecme-ikev2-sa-ts-payloads-opt

Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ka= mpati-ipsecme-ikev2-sa-ts-payloads-opt-01



Abstract:

=C2=A0 =C2=A0This document describes a method for reducing the size of the<= br>
=C2=A0 =C2=A0Internet Key Exchange version 2 (IKEv2) exchanges at time of r= ekeying

=C2=A0 =C2=A0IKE SAs and Child SAs by removing or making optional of SA &am= p; TS

=C2=A0 =C2=A0payloads.=C2=A0 Reducing size of IKEv2 exchanges is desirable = for low

=C2=A0 =C2=A0power consumption battery powered devices.=C2=A0 It also helps= to avoid IP

=C2=A0 =C2=A0fragmentation of IKEv2 messages.









Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/ipsec/attachments/20190522/fa3895= 80/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


------------------------------

End of IPsec Digest, Vol 181, Issue 4
*************************************
--00000000000004637c058f08cbac-- From nobody Thu Aug 1 00:04:41 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF89120058 for ; Thu, 1 Aug 2019 00:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=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=gmail.com 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 qVcvp2UHsU5G for ; Thu, 1 Aug 2019 00:04:37 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B60120026 for ; Thu, 1 Aug 2019 00:04:36 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id s19so49395602lfb.9 for ; Thu, 01 Aug 2019 00:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=VpROG0VyGG2VQfiKGF6jnYuEs6N7Jk6DbSNCJ/Xp378=; b=JImTVKO2+AH+dhTG5HVNFnjBeevOEBnhe1CXWQTBH/3rxd40vhN5BljRJOWVP+695C EdnZbKnqGJf47EYeTUOc4KUEm7mtDSE4huPur/Mte9PyzzZjpIWQfdx68lzMyvOkQ9yC jI+eUfqqalbY7FX5mI6+/CpTgPYNszDfnp5agvteSqsCOE3aJ2qoy9ypCsgw4/7hQmMX v391Phrx3TRFmOZePlElbsJgvFRD+j7M2elhHOdw1D3b3bQDTSmNIRBQ74U3AJ7eh99C f8XFcYRchnHkTyhmPffppEC4n2pCB6AY9YZEMVIf+gtBBg6EYlct4599BMUgUQEzbtcT q5EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=VpROG0VyGG2VQfiKGF6jnYuEs6N7Jk6DbSNCJ/Xp378=; b=jzEZOBpyDM5AKwOLmiHUdhUsaigf70O9IqlqdX7XiSuaudglyVcBL8zHMiIm1Tvx7R vjHIB5NsWDOV3FYGmE1s2Ni1fL/KxwUIsEkI0y6uFR2chiTC9icoKDZJmaUlLbVMnYvY VsbTLcMXTvBGu+xDwVXgRQKSammTi1D73q9vV6iRIHGKuzHPSfArYSoneGMvVhngC47f c//yEQiCdYNxtFSGWlrD95i/8U2635YDVJA8I+522OhLUbM62tzrD+AzljOjMZqmxDzA 4JybW7gCoPV/inm/gVUP3uzdPleooEXn1Thm4aaV0PTSUprXBFVe8tLtllcD+KE6gV1P KT3w== X-Gm-Message-State: APjAAAXm6fhAoq2eU9m2B15q9wJTfWtTGQj5BLrbyf5nYdVx+CHdweEt CAZ/qXZq0sLskiARr7RwHvyuARWFgrNhmo2dmbbvyql3 X-Google-Smtp-Source: APXvYqzmdnslpkobf70ZhmrGpt3oEBsLpwHJh/aygodjrKtmpM0/WWat1zFmiEbSgbyoUwXOIf0UG05VZ9RhjWwZGV4= X-Received: by 2002:ac2:44ce:: with SMTP id d14mr1391451lfm.143.1564643074578; Thu, 01 Aug 2019 00:04:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shubham mamodiya Date: Thu, 1 Aug 2019 12:34:22 +0530 Message-ID: To: ipsec@ietf.org, william.panwei@huawei.com, sandeepkampati@huawei.com, MeduriS.Bharath@huawei.com Content-Type: multipart/alternative; boundary="000000000000a91c81058f08dab9" Archived-At: Subject: [IPsec] Fwd: IPsec Digest, Vol 181, Issue 4 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 07:04:40 -0000 --000000000000a91c81058f08dab9 Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message --------- From: shubham mamodiya Date: Thu, Aug 1, 2019 at 12:30 PM Subject: Re: IPsec Digest, Vol 181, Issue 4 To: Some comments for draft "draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt". 3.2.3. Rekeying IKE SAs When Responder's Cryptographic Suites Changed At the time of or before rekeying IKE SAs, the responder's cryptographic suites may be changed while there is no change of initiator's cryptographic suites. New cryptographic suites may be added to the responder, or some outdated cryptographic suites may be deleted from the responder. In this situation, the initiator sends the SA_UNCHANGED notification payload instead of the SA payloads in the CREATE_CHILD_SA request message at the time of rekeying IKE SAs. Kampati, et al. Expires November 22, 2019 [Page 5]Internet-Draft IKEv2 Optional Child SA&TS Payloads May 2019 If the responder decides to continue using the previously negotiated cryptographic suite to rekey the IKE SA, it MAY send the SA_UNCHANGED notification payload in the CREATE_CHILD_SA response message, then the rekeying is conducted like Section 3.2.1. If the responder decides to re-negotiate the cryptographic suite, it MUST send NO_PROPOSAL_CHOSEN notification payload in the CREATE_CHILD_SA response message. After receiving this error notification, the initiator MUST retry the CREATE_CHILD_SA exchange with the SA payloads. Then the rekeying is conducted in the original way defined in [RFC7296]. The CREATE_CHILD_SA message exchange in this case is shown below: Initiator Responder -------------------------------------------------------------------- HDR, SK {N(SA_UNCHANGED), Ni, KEi} --> <-- HDR, SK {N(NO_PROPOSAL_CHOSEN), Nr, KEr} HDR, SK {SA, Ni, KEi} --> <-- HDR, SK {SA, *Ni, KEi*} Comment : 1. If the responder decides to continue using the previously negotiated cryptographic suite to rekey the IKE SA, it MAY send the SA_UNCHANGED notification payload in the CREATE_CHILD_SA response message, then the rekeying is conducted like Section 3.2.1. >> Better to put exchange diagram for this case also. 2. Nonce and KE notations are not correct in the response message If the responder decides to re-negotiate the cryptographic suite, it MUST send NO_PROPOSAL_CHOSEN notification payload in the CREATE_CHILD_SA response message. After receiving this error notification, the initiator MUST retry the CREATE_CHILD_SA exchange with the SA payloads. Then the rekeying is conducted in the original way defined in [RFC7296]. The CREATE_CHILD_SA message exchange in this case is shown below: Initiator Responder -------------------------------------------------------------------- HDR, SK {N(SA_UNCHANGED), Ni, KEi} --> <-- HDR, SK {N(NO_PROPOSAL_CHOSEN), Nr, KEr} HDR, SK {SA, Ni, KEi} --> <-- HDR, SK {SA, *Ni, KEi*} >> In CREATE_CHILD_SA response message, responder MUST not send the same Nonce and KE received from initiator (Ni, KEi). It MUST be Nr and KEr in the response message. On Thu, May 23, 2019 at 12:30 AM wrote: > Send IPsec mailing list submissions to > ipsec@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/ipsec > or, via email, send a message with subject or body 'help' to > ipsec-request@ietf.org > > You can reach the person managing the list at > ipsec-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of IPsec digest..." > > > Today's Topics: > > 1. Fwd: New Version Notification for > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt > (Panwei (William)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 22 May 2019 07:37:17 +0000 > From: "Panwei (William)" > To: Paul Wouters , Y Sowji , > "ipsec@ietf.org" > Cc: Sandeep Kampati , "Meduri S S Bharath > (A)" > Subject: [IPsec] Fwd: New Version Notification for > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt > Message-ID: > < > 30E95A901DB42F44BA42D69DB20DFA6A69F68ABE@nkgeml513-mbx.china.huawei.com> > > Content-Type: text/plain; charset="utf-8" > > Hi Paul, Sowjanya and folks, > > > > Thanks a lot for Paul and Sowjanya?s reviews, we have modified our draft > based on your comments. > > > > The new version draft includes the following main changes: > > 1. Redesign the sections to make the structure more reasonable and the > draft more readable. > > 2. Change the negotiation of support to the IKE_AUTH phase, and change the > support notification?s name. > > 3. Detail the optimization for rekeying IKE SAs, and use SA_UNCHANGED > notification payload to replace SA payloads. > > 4. Detail the optimization for rekeying Child SAs, and use SA_TS_UNCHANGED > notification payload to replace SA and TS payload. > > 5. For rekeying Child SAs, we currently remove the consideration that only > omitting TS payloads, because we think this kind omitting will introduce > more complexities. Initiator SA payload, Initiator TS payload, Responder SA > payload and Responder TS payload, if either of these four payloads can be > omitted, there will be up to 16 circumstances, that will be too complex. > > > > Comments and reviews for the new version draft are very welcome. > > > > Best Regards > > Wei Pan > > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, May 22, 2019 2:17 PM > To: Meduri S S Bharath (A) ; Meduri S S > Bharath (A) ; Panwei (William) < > william.panwei@huawei.com>; Sandeep Kampati > Subject: New Version Notification for > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt > > > > > > A new version of I-D, draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt > > has been successfully submitted by Wei Pan and posted to the IETF > repository. > > > > Name: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt > > Revision: 01 > > Title: IKEv2 Optional SA&TS Payloads in Child Exchange > > Document date: 2019-05-21 > > Group: Individual Submission > > Pages: 11 > > URL: > https://www.ietf.org/internet-drafts/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt > > Status: > https://datatracker.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt/ > > Htmlized: > https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01 > > > > Abstract: > > This document describes a method for reducing the size of the > > Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying > > IKE SAs and Child SAs by removing or making optional of SA & TS > > payloads. Reducing size of IKEv2 exchanges is desirable for low > > power consumption battery powered devices. It also helps to avoid IP > > fragmentation of IKEv2 messages. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > The IETF Secretariat > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/ipsec/attachments/20190522/fa389580/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > ------------------------------ > > End of IPsec Digest, Vol 181, Issue 4 > ************************************* > --000000000000a91c81058f08dab9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


---------- Forwarded message ---------
From: shubham mamodiya <shubhammamodiya@gma= il.com>
Date: Thu, Aug 1, 2019 at 12:30 PM
Subject: Re:= IPsec Digest, Vol 181, Issue 4
To: <ipsec@ietf.org>

Some comments for draft "draft-= kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt".

3.2.3.  Rekeyin=
g IKE SAs When Responder's Cryptographic Suites Changed

   At the time of or before rekeying IKE SAs, the responder's
   cryptographic suites may be changed while there is no change of
   initiator's cryptographic suites.  New cryptographic suites may be
   added to the responder, or some outdated cryptographic suites may be
   deleted from the responder.

   In this situation, the initiator sends the SA_UNCHANGED notification
   payload instead of the SA payloads in the CREATE_CHILD_SA request
   message at the time of rekeying IKE SAs.

Kampati, et al.         Expires November 22, 2019               [Pag=
e 5]
Internet-Draft     IKEv2 Optional Child SA&TS Payloads          =
May 2019

   If the responder decides to continue using the previously negotiated
   cryptographic suite to rekey the IKE SA, it MAY send the SA_UNCHANGED
   notification payload in the CREATE_CHILD_SA response message, then
   the rekeying is conducted like Section 3.2.1.

   If the responder decides to re-negotiate the cryptographic suite, it
   MUST send NO_PROPOSAL_CHOSEN notification payload in the
   CREATE_CHILD_SA response message.  After receiving this error
   notification, the initiator MUST retry the CREATE_CHILD_SA exchange
   with the SA payloads.  Then the rekeying is conducted in the original
   way defined in [RFC7296].  The CREATE_CHILD_SA message exchange in
   this case is shown below:

   Initiator                         Responder
   --------------------------------------------------------------------
   HDR, SK {N(SA_UNCHANGED), Ni, KEi} -->
                                 <-- HDR, SK {N(NO_PROPOSAL_CHOSEN),
                                         Nr, KEr}
   HDR, SK {SA, Ni, KEi} -->
                                 <-- HDR, SK {SA, Ni, KEi}
<= pre style=3D"box-sizing:border-box;overflow:auto;font-family:"PT Mono&= quot;,Monaco,monospace;font-size:14px;padding:10px;margin-top:0px;margin-bo= ttom:10.5px;line-height:1.214;color:rgb(0,0,0);word-break:break-all;word-wr= ap:break-word;background-color:rgb(255,253,245);border:1px solid rgb(204,20= 4,204);border-radius:4px">Comment : 
1. If =
the responder decides to continue using the previously negotiated
cryptographic suite to rekey the IKE SA, it MAY s= end the SA_UNCHANGED notification payload in the CREATE_CHILD_SA response message, then the rekeying is conducted like Section 3.2.1.
>> Better to put exchange diagram for this case also.

2. Nonce and KE=
 notations are not correct in the response message
 If the responder decides to re=
-negotiate the cryptographic suite, it
   MUST send NO_PROPOSAL_CHOSEN notification payload in the
   CREATE_CHILD_SA response message.  After receiving this error
   notification, the initiator MUST retry the CREATE_CHILD_SA exchange
   with the SA payloads.  Then the rekeying is conducted in the original
   way defined in [RFC7296].  The CREATE_CHILD_SA message exchange in
   this case is shown below:

   Initiator                         Responder
   --------------------------------------------------------------------
   HDR, SK {N(SA_UNCHANGED), Ni, KEi} -->
                                 <-- HDR, SK {N(NO_PROPOSAL_CHOSEN),
                                         Nr, KEr}
   HDR, SK {SA, Ni, KEi} -->
                                 <-- HDR, SK {SA, Ni, KEi}
<=
pre style=3D"box-sizing:border-box;overflow:auto;font-family:"PT Mono&=
quot;,Monaco,monospace;padding:10px;margin-top:0px;margin-bottom:10.5px;lin=
e-height:1.214;word-break:break-all;word-wrap:break-word;border:1px solid r=
gb(204,204,204);border-radius:4px">>> In CREATE_CHILD_SA response mes=
sage, responder MUST not send the same Nonce and KE received from initiator=
 (Ni, KEi).
It MUST be Nr and KEr =
in the response message.

On Thu, May 23, 2019 at 12:30 AM <ipsec-request@iet= f.org> wrote:
Send IPsec mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ipsec@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/= listinfo/ipsec
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ipsec-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ipsec-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of IPsec digest..."


Today's Topics:

=C2=A0 =C2=A01. Fwd: New Version Notification for
=C2=A0 =C2=A0 =C2=A0 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt<= br> =C2=A0 =C2=A0 =C2=A0 (Panwei (William))


----------------------------------------------------------------------

Message: 1
Date: Wed, 22 May 2019 07:37:17 +0000
From: "Panwei (William)" <william.panwei@huawei.com>
To: Paul Wouters <pa= ul@nohats.ca>, Y Sowji <sowji_eluri@yahoo.com>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "ipsec@ietf.org" <ipsec@ietf.org>
Cc: Sandeep Kampati <sandeepkampati@huawei.com>, "Meduri S S Bharath
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (A)" <MeduriS.Bharath@huawei.com>
Subject: [IPsec] Fwd: New Version Notification for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-= 01.txt
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <30E95A901= DB42F44BA42D69DB20DFA6A69F68ABE@nkgeml513-mbx.china.huawei.com>

Content-Type: text/plain; charset=3D"utf-8"

Hi Paul, Sowjanya and folks,



Thanks a lot for Paul and Sowjanya?s reviews, we have modified our draft ba= sed on your comments.



The new version draft includes the following main changes:

1. Redesign the sections to make the structure more reasonable and the draf= t more readable.

2. Change the negotiation of support to the IKE_AUTH phase, and change the = support notification?s name.

3. Detail the optimization for rekeying IKE SAs, and use SA_UNCHANGED notif= ication payload to replace SA payloads.

4. Detail the optimization for rekeying Child SAs, and use SA_TS_UNCHANGED = notification payload to replace SA and TS payload.

5. For rekeying Child SAs, we currently remove the consideration that only = omitting TS payloads, because we think this kind omitting will introduce mo= re complexities. Initiator SA payload, Initiator TS payload, Responder SA p= ayload and Responder TS payload, if either of these four payloads can be om= itted, there will be up to 16 circumstances, that will be too complex.



Comments and reviews for the new version draft are very welcome.



Best Regards

Wei Pan



-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, May 22, 2019 2:17 PM
To: Meduri S S Bharath (A) <MeduriS.Bharath@huawei.com>; Meduri S S Bharath = (A) <Med= uriS.Bharath@huawei.com>; Panwei (William) <william.panwei@huawei.com>= ; Sandeep Kampati <sandeepkampati@huawei.com>
Subject: New Version Notification for draft-kampati-ipsecme-ikev2-sa-ts-pay= loads-opt-01.txt





A new version of I-D, draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt=

has been successfully submitted by Wei Pan and posted to the IETF repositor= y.



Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-kampati-ipsecme-= ikev2-sa-ts-payloads-opt

Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A001

Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IKEv2 Optiona= l SA&TS Payloads in Child Exchange

Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02019-05-21

Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission=

Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/dr= aft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt

Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-kampati-ipsecme= -ikev2-sa-ts-payloads-opt/

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-= payloads-opt-01

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-kampati-ips= ecme-ikev2-sa-ts-payloads-opt

Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ka= mpati-ipsecme-ikev2-sa-ts-payloads-opt-01



Abstract:

=C2=A0 =C2=A0This document describes a method for reducing the size of the<= br>
=C2=A0 =C2=A0Internet Key Exchange version 2 (IKEv2) exchanges at time of r= ekeying

=C2=A0 =C2=A0IKE SAs and Child SAs by removing or making optional of SA &am= p; TS

=C2=A0 =C2=A0payloads.=C2=A0 Reducing size of IKEv2 exchanges is desirable = for low

=C2=A0 =C2=A0power consumption battery powered devices.=C2=A0 It also helps= to avoid IP

=C2=A0 =C2=A0fragmentation of IKEv2 messages.









Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/ipsec/attachments/20190522/fa3895= 80/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


------------------------------

End of IPsec Digest, Vol 181, Issue 4
*************************************
--000000000000a91c81058f08dab9-- From nobody Thu Aug 1 01:13:04 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C91120075 for ; Thu, 1 Aug 2019 01:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=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 JU0e8YEDwwMm for ; Thu, 1 Aug 2019 01:12:58 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 081A512006E for ; Thu, 1 Aug 2019 01:12:58 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 732E26F51B2E41EC887F; Thu, 1 Aug 2019 09:12:55 +0100 (IST) Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 1 Aug 2019 09:12:55 +0100 Received: from lhreml713-chm.china.huawei.com (10.201.108.64) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 1 Aug 2019 09:12:53 +0100 Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 1 Aug 2019 09:12:52 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.136]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0439.000; Thu, 1 Aug 2019 16:12:48 +0800 From: "Panwei (William)" To: shubham mamodiya CC: "ipsec@ietf.org" Thread-Topic: [IPsec] IPsec Digest, Vol 181, Issue 4 Thread-Index: AQHVSDbWMKNqODm8FUSYFkgXS7z0Aqbl5f6w Date: Thu, 1 Aug 2019 08:12:47 +0000 Message-ID: <30E95A901DB42F44BA42D69DB20DFA6A6DE200B0@nkgeml513-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.37.117] Content-Type: multipart/alternative; boundary="_000_30E95A901DB42F44BA42D69DB20DFA6A6DE200B0nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [IPsec] IPsec Digest, Vol 181, Issue 4 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 08:13:02 -0000 --_000_30E95A901DB42F44BA42D69DB20DFA6A6DE200B0nkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2h1YmhhbSwNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgY29tbWVudHMuIFdl4oCZ bGwgZml4IHRoZW0gaW4gbmV4dCB2ZXJzaW9uLg0KDQpSZWdhcmRzICYgVGhhbmtzIQ0K5r2Y5Lyf IFdlaSBQYW4NCuWNjuS4uuaKgOacr+aciemZkOWFrOWPuCBIdWF3ZWkgVGVjaG5vbG9naWVzIENv LiwgTHRkLg0KDQpGcm9tOiBJUHNlYyBbbWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBzaHViaGFtIG1hbW9kaXlhDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDAxLCAy MDE5IDM6MDAgUE0NClRvOiBpcHNlY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJUHNlY10gSVBz ZWMgRGlnZXN0LCBWb2wgMTgxLCBJc3N1ZSA0DQoNCg0KMy4yLjMuICBSZWtleWluZyBJS0UgU0Fz IFdoZW4gUmVzcG9uZGVyJ3MgQ3J5cHRvZ3JhcGhpYyBTdWl0ZXMgQ2hhbmdlZA0KDQoNCg0KICAg QXQgdGhlIHRpbWUgb2Ygb3IgYmVmb3JlIHJla2V5aW5nIElLRSBTQXMsIHRoZSByZXNwb25kZXIn cw0KDQogICBjcnlwdG9ncmFwaGljIHN1aXRlcyBtYXkgYmUgY2hhbmdlZCB3aGlsZSB0aGVyZSBp cyBubyBjaGFuZ2Ugb2YNCg0KICAgaW5pdGlhdG9yJ3MgY3J5cHRvZ3JhcGhpYyBzdWl0ZXMuICBO ZXcgY3J5cHRvZ3JhcGhpYyBzdWl0ZXMgbWF5IGJlDQoNCiAgIGFkZGVkIHRvIHRoZSByZXNwb25k ZXIsIG9yIHNvbWUgb3V0ZGF0ZWQgY3J5cHRvZ3JhcGhpYyBzdWl0ZXMgbWF5IGJlDQoNCiAgIGRl bGV0ZWQgZnJvbSB0aGUgcmVzcG9uZGVyLg0KDQoNCg0KICAgSW4gdGhpcyBzaXR1YXRpb24sIHRo ZSBpbml0aWF0b3Igc2VuZHMgdGhlIFNBX1VOQ0hBTkdFRCBub3RpZmljYXRpb24NCg0KICAgcGF5 bG9hZCBpbnN0ZWFkIG9mIHRoZSBTQSBwYXlsb2FkcyBpbiB0aGUgQ1JFQVRFX0NISUxEX1NBIHJl cXVlc3QNCg0KICAgbWVzc2FnZSBhdCB0aGUgdGltZSBvZiByZWtleWluZyBJS0UgU0FzLg0KDQoN Cg0KS2FtcGF0aSwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMiwgMjAxOSAgICAg ICAgICAgICAgIFtQYWdlIDVdDQoNCkludGVybmV0LURyYWZ0ICAgICBJS0V2MiBPcHRpb25hbCBD aGlsZCBTQSZUUyBQYXlsb2FkcyAgICAgICAgICBNYXkgMjAxOQ0KDQoNCg0KICAgSWYgdGhlIHJl c3BvbmRlciBkZWNpZGVzIHRvIGNvbnRpbnVlIHVzaW5nIHRoZSBwcmV2aW91c2x5IG5lZ290aWF0 ZWQNCg0KICAgY3J5cHRvZ3JhcGhpYyBzdWl0ZSB0byByZWtleSB0aGUgSUtFIFNBLCBpdCBNQVkg c2VuZCB0aGUgU0FfVU5DSEFOR0VEDQoNCiAgIG5vdGlmaWNhdGlvbiBwYXlsb2FkIGluIHRoZSBD UkVBVEVfQ0hJTERfU0EgcmVzcG9uc2UgbWVzc2FnZSwgdGhlbg0KDQogICB0aGUgcmVrZXlpbmcg aXMgY29uZHVjdGVkIGxpa2UgU2VjdGlvbiAzLjIuMS4NCg0KDQoNCiAgIElmIHRoZSByZXNwb25k ZXIgZGVjaWRlcyB0byByZS1uZWdvdGlhdGUgdGhlIGNyeXB0b2dyYXBoaWMgc3VpdGUsIGl0DQoN CiAgIE1VU1Qgc2VuZCBOT19QUk9QT1NBTF9DSE9TRU4gbm90aWZpY2F0aW9uIHBheWxvYWQgaW4g dGhlDQoNCiAgIENSRUFURV9DSElMRF9TQSByZXNwb25zZSBtZXNzYWdlLiAgQWZ0ZXIgcmVjZWl2 aW5nIHRoaXMgZXJyb3INCg0KICAgbm90aWZpY2F0aW9uLCB0aGUgaW5pdGlhdG9yIE1VU1QgcmV0 cnkgdGhlIENSRUFURV9DSElMRF9TQSBleGNoYW5nZQ0KDQogICB3aXRoIHRoZSBTQSBwYXlsb2Fk cy4gIFRoZW4gdGhlIHJla2V5aW5nIGlzIGNvbmR1Y3RlZCBpbiB0aGUgb3JpZ2luYWwNCg0KICAg d2F5IGRlZmluZWQgaW4gW1JGQzcyOTZdLiAgVGhlIENSRUFURV9DSElMRF9TQSBtZXNzYWdlIGV4 Y2hhbmdlIGluDQoNCiAgIHRoaXMgY2FzZSBpcyBzaG93biBiZWxvdzoNCg0KDQoNCiAgIEluaXRp YXRvciAgICAgICAgICAgICAgICAgICAgICAgICBSZXNwb25kZXINCg0KICAgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KICAgSERSLCBTSyB7TihTQV9VTkNIQU5HRUQpLCBOaSwgS0VpfSAtLT4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPC0tIEhEUiwgU0sge04oTk9fUFJPUE9TQUxfQ0hPU0VO KSwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOciwgS0VyfQ0K DQogICBIRFIsIFNLIHtTQSwgTmksIEtFaX0gLS0+DQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwtLSBIRFIsIFNLIHtTQSwgTmksIEtFaX0NCg0KQ29tbWVudCA6DQoNCjEuIElm IHRoZSByZXNwb25kZXIgZGVjaWRlcyB0byBjb250aW51ZSB1c2luZyB0aGUgcHJldmlvdXNseSBu ZWdvdGlhdGVkDQoNCiAgIGNyeXB0b2dyYXBoaWMgc3VpdGUgdG8gcmVrZXkgdGhlIElLRSBTQSwg aXQgTUFZIHNlbmQgdGhlIFNBX1VOQ0hBTkdFRA0KDQogICBub3RpZmljYXRpb24gcGF5bG9hZCBp biB0aGUgQ1JFQVRFX0NISUxEX1NBIHJlc3BvbnNlIG1lc3NhZ2UsIHRoZW4NCg0KICAgdGhlIHJl a2V5aW5nIGlzIGNvbmR1Y3RlZCBsaWtlIFNlY3Rpb24gMy4yLjEuDQoNCj4+IEJldHRlciB0byBw dXQgZXhjaGFuZ2UgZGlhZ3JhbSBmb3IgdGhpcyBjYXNlIGFsc28uDQoNCg0KDQoyLiBOb25jZSBh bmQgS0Ugbm90YXRpb25zIGFyZSBub3QgY29ycmVjdCBpbiB0aGUgcmVzcG9uc2UgbWVzc2FnZQ0K DQogSWYgdGhlIHJlc3BvbmRlciBkZWNpZGVzIHRvIHJlLW5lZ290aWF0ZSB0aGUgY3J5cHRvZ3Jh cGhpYyBzdWl0ZSwgaXQNCg0KICAgTVVTVCBzZW5kIE5PX1BST1BPU0FMX0NIT1NFTiBub3RpZmlj YXRpb24gcGF5bG9hZCBpbiB0aGUNCg0KICAgQ1JFQVRFX0NISUxEX1NBIHJlc3BvbnNlIG1lc3Nh Z2UuICBBZnRlciByZWNlaXZpbmcgdGhpcyBlcnJvcg0KDQogICBub3RpZmljYXRpb24sIHRoZSBp bml0aWF0b3IgTVVTVCByZXRyeSB0aGUgQ1JFQVRFX0NISUxEX1NBIGV4Y2hhbmdlDQoNCiAgIHdp dGggdGhlIFNBIHBheWxvYWRzLiAgVGhlbiB0aGUgcmVrZXlpbmcgaXMgY29uZHVjdGVkIGluIHRo ZSBvcmlnaW5hbA0KDQogICB3YXkgZGVmaW5lZCBpbiBbUkZDNzI5Nl0uICBUaGUgQ1JFQVRFX0NI SUxEX1NBIG1lc3NhZ2UgZXhjaGFuZ2UgaW4NCg0KICAgdGhpcyBjYXNlIGlzIHNob3duIGJlbG93 Og0KDQoNCg0KICAgSW5pdGlhdG9yICAgICAgICAgICAgICAgICAgICAgICAgIFJlc3BvbmRlcg0K DQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQogICBIRFIsIFNLIHtOKFNBX1VOQ0hBTkdFRCksIE5pLCBLRWl9 IC0tPg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0gSERSLCBTSyB7TihO T19QUk9QT1NBTF9DSE9TRU4pLA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIE5yLCBLRXJ9DQoNCiAgIEhEUiwgU0sge1NBLCBOaSwgS0VpfSAtLT4NCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tIEhEUiwgU0sge1NBLCBOaSwgS0VpfQ0KDQo+ PiBJbiBDUkVBVEVfQ0hJTERfU0EgcmVzcG9uc2UgbWVzc2FnZSwgcmVzcG9uZGVyIE1VU1Qgbm90 IHNlbmQgdGhlIHNhbWUgTm9uY2UgYW5kIEtFIHJlY2VpdmVkIGZyb20gaW5pdGlhdG9yIChOaSwg S0VpKS4NCg0KSXQgTVVTVCBiZSBOciBhbmQgS0VyIGluIHRoZSByZXNwb25zZSBtZXNzYWdlLg0K DQpPbiBUaHUsIE1heSAyMywgMjAxOSBhdCAxMjozMCBBTSA8aXBzZWMtcmVxdWVzdEBpZXRmLm9y ZzxtYWlsdG86aXBzZWMtcmVxdWVzdEBpZXRmLm9yZz4+IHdyb3RlOg0KU2VuZCBJUHNlYyBtYWls aW5nIGxpc3Qgc3VibWlzc2lvbnMgdG8NCiAgICAgICAgaXBzZWNAaWV0Zi5vcmc8bWFpbHRvOmlw c2VjQGlldGYub3JnPg0KDQpUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3Js ZCBXaWRlIFdlYiwgdmlzaXQNCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pcHNlYw0Kb3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0 IG9yIGJvZHkgJ2hlbHAnIHRvDQogICAgICAgIGlwc2VjLXJlcXVlc3RAaWV0Zi5vcmc8bWFpbHRv Omlwc2VjLXJlcXVlc3RAaWV0Zi5vcmc+DQoNCllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5h Z2luZyB0aGUgbGlzdCBhdA0KICAgICAgICBpcHNlYy1vd25lckBpZXRmLm9yZzxtYWlsdG86aXBz ZWMtb3duZXJAaWV0Zi5vcmc+DQoNCldoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3Vi amVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWMNCnRoYW4gIlJlOiBDb250ZW50cyBvZiBJ UHNlYyBkaWdlc3QuLi4iDQoNCg0KVG9kYXkncyBUb3BpY3M6DQoNCiAgIDEuIEZ3ZDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvcg0KICAgICAgZHJhZnQta2FtcGF0aS1pcHNlY21lLWlrZXYy LXNhLXRzLXBheWxvYWRzLW9wdC0wMS50eHQNCiAgICAgIChQYW53ZWkgKFdpbGxpYW0pKQ0KDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KTWVzc2FnZTogMQ0KRGF0ZTogV2VkLCAyMiBNYXkgMjAxOSAwNzoz NzoxNyArMDAwMA0KRnJvbTogIlBhbndlaSAoV2lsbGlhbSkiIDx3aWxsaWFtLnBhbndlaUBodWF3 ZWkuY29tPG1haWx0bzp3aWxsaWFtLnBhbndlaUBodWF3ZWkuY29tPj4NClRvOiBQYXVsIFdvdXRl cnMgPHBhdWxAbm9oYXRzLmNhPG1haWx0bzpwYXVsQG5vaGF0cy5jYT4+LCBZIFNvd2ppIDxzb3dq aV9lbHVyaUB5YWhvby5jb208bWFpbHRvOnNvd2ppX2VsdXJpQHlhaG9vLmNvbT4+LA0KICAgICAg ICAiaXBzZWNAaWV0Zi5vcmc8bWFpbHRvOmlwc2VjQGlldGYub3JnPiIgPGlwc2VjQGlldGYub3Jn PG1haWx0bzppcHNlY0BpZXRmLm9yZz4+DQpDYzogU2FuZGVlcCBLYW1wYXRpIDxzYW5kZWVwa2Ft cGF0aUBodWF3ZWkuY29tPG1haWx0bzpzYW5kZWVwa2FtcGF0aUBodWF3ZWkuY29tPj4sICJNZWR1 cmkgUyBTIEJoYXJhdGgNCiAgICAgICAgKEEpIiA8TWVkdXJpUy5CaGFyYXRoQGh1YXdlaS5jb208 bWFpbHRvOk1lZHVyaVMuQmhhcmF0aEBodWF3ZWkuY29tPj4NClN1YmplY3Q6IFtJUHNlY10gRndk OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQogICAgICAgIGRyYWZ0LWthbXBhdGktaXBz ZWNtZS1pa2V2Mi1zYS10cy1wYXlsb2Fkcy1vcHQtMDEudHh0DQpNZXNzYWdlLUlEOg0KICAgICAg ICA8MzBFOTVBOTAxREI0MkY0NEJBNDJENjlEQjIwREZBNkE2OUY2OEFCRUBua2dlbWw1MTMtbWJ4 LmNoaW5hLmh1YXdlaS5jb208bWFpbHRvOjMwRTk1QTkwMURCNDJGNDRCQTQyRDY5REIyMERGQTZB NjlGNjhBQkVAbmtnZW1sNTEzLW1ieC5jaGluYS5odWF3ZWkuY29tPj4NCg0KQ29udGVudC1UeXBl OiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1dGYtOCINCg0KSGkgUGF1bCwgU293amFueWEgYW5kIGZv bGtzLA0KDQoNCg0KVGhhbmtzIGEgbG90IGZvciBQYXVsIGFuZCBTb3dqYW55YT9zIHJldmlld3Ms IHdlIGhhdmUgbW9kaWZpZWQgb3VyIGRyYWZ0IGJhc2VkIG9uIHlvdXIgY29tbWVudHMuDQoNCg0K DQpUaGUgbmV3IHZlcnNpb24gZHJhZnQgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBtYWluIGNoYW5n ZXM6DQoNCjEuIFJlZGVzaWduIHRoZSBzZWN0aW9ucyB0byBtYWtlIHRoZSBzdHJ1Y3R1cmUgbW9y ZSByZWFzb25hYmxlIGFuZCB0aGUgZHJhZnQgbW9yZSByZWFkYWJsZS4NCg0KMi4gQ2hhbmdlIHRo ZSBuZWdvdGlhdGlvbiBvZiBzdXBwb3J0IHRvIHRoZSBJS0VfQVVUSCBwaGFzZSwgYW5kIGNoYW5n ZSB0aGUgc3VwcG9ydCBub3RpZmljYXRpb24/cyBuYW1lLg0KDQozLiBEZXRhaWwgdGhlIG9wdGlt aXphdGlvbiBmb3IgcmVrZXlpbmcgSUtFIFNBcywgYW5kIHVzZSBTQV9VTkNIQU5HRUQgbm90aWZp Y2F0aW9uIHBheWxvYWQgdG8gcmVwbGFjZSBTQSBwYXlsb2Fkcy4NCg0KNC4gRGV0YWlsIHRoZSBv cHRpbWl6YXRpb24gZm9yIHJla2V5aW5nIENoaWxkIFNBcywgYW5kIHVzZSBTQV9UU19VTkNIQU5H RUQgbm90aWZpY2F0aW9uIHBheWxvYWQgdG8gcmVwbGFjZSBTQSBhbmQgVFMgcGF5bG9hZC4NCg0K NS4gRm9yIHJla2V5aW5nIENoaWxkIFNBcywgd2UgY3VycmVudGx5IHJlbW92ZSB0aGUgY29uc2lk ZXJhdGlvbiB0aGF0IG9ubHkgb21pdHRpbmcgVFMgcGF5bG9hZHMsIGJlY2F1c2Ugd2UgdGhpbmsg dGhpcyBraW5kIG9taXR0aW5nIHdpbGwgaW50cm9kdWNlIG1vcmUgY29tcGxleGl0aWVzLiBJbml0 aWF0b3IgU0EgcGF5bG9hZCwgSW5pdGlhdG9yIFRTIHBheWxvYWQsIFJlc3BvbmRlciBTQSBwYXls b2FkIGFuZCBSZXNwb25kZXIgVFMgcGF5bG9hZCwgaWYgZWl0aGVyIG9mIHRoZXNlIGZvdXIgcGF5 bG9hZHMgY2FuIGJlIG9taXR0ZWQsIHRoZXJlIHdpbGwgYmUgdXAgdG8gMTYgY2lyY3Vtc3RhbmNl cywgdGhhdCB3aWxsIGJlIHRvbyBjb21wbGV4Lg0KDQoNCg0KQ29tbWVudHMgYW5kIHJldmlld3Mg Zm9yIHRoZSBuZXcgdmVyc2lvbiBkcmFmdCBhcmUgdmVyeSB3ZWxjb21lLg0KDQoNCg0KQmVzdCBS ZWdhcmRzDQoNCldlaSBQYW4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zz4gW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZz5dDQpTZW50OiBXZWRuZXNkYXksIE1heSAyMiwgMjAxOSAyOjE3IFBNDQpUbzog TWVkdXJpIFMgUyBCaGFyYXRoIChBKSA8TWVkdXJpUy5CaGFyYXRoQGh1YXdlaS5jb208bWFpbHRv Ok1lZHVyaVMuQmhhcmF0aEBodWF3ZWkuY29tPj47IE1lZHVyaSBTIFMgQmhhcmF0aCAoQSkgPE1l ZHVyaVMuQmhhcmF0aEBodWF3ZWkuY29tPG1haWx0bzpNZWR1cmlTLkJoYXJhdGhAaHVhd2VpLmNv bT4+OyBQYW53ZWkgKFdpbGxpYW0pIDx3aWxsaWFtLnBhbndlaUBodWF3ZWkuY29tPG1haWx0bzp3 aWxsaWFtLnBhbndlaUBodWF3ZWkuY29tPj47IFNhbmRlZXAgS2FtcGF0aSA8c2FuZGVlcGthbXBh dGlAaHVhd2VpLmNvbTxtYWlsdG86c2FuZGVlcGthbXBhdGlAaHVhd2VpLmNvbT4+DQpTdWJqZWN0 OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWthbXBhdGktaXBzZWNtZS1pa2V2 Mi1zYS10cy1wYXlsb2Fkcy1vcHQtMDEudHh0DQoNCg0KDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWthbXBhdGktaXBzZWNtZS1pa2V2Mi1zYS10cy1wYXlsb2Fkcy1vcHQtMDEudHh0 DQoNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgV2VpIFBhbiBhbmQgcG9zdGVk IHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCg0KDQpOYW1lOiAgICAgICAgICAgICBkcmFmdC1r YW1wYXRpLWlwc2VjbWUtaWtldjItc2EtdHMtcGF5bG9hZHMtb3B0DQoNClJldmlzaW9uOiAgICAg ICAgIDAxDQoNClRpdGxlOiAgICAgICAgICAgICAgICBJS0V2MiBPcHRpb25hbCBTQSZUUyBQYXls b2FkcyBpbiBDaGlsZCBFeGNoYW5nZQ0KDQpEb2N1bWVudCBkYXRlOiAgICAgICAgIDIwMTktMDUt MjENCg0KR3JvdXA6ICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KDQpQYWdlczog ICAgICAgICAgICAgIDExDQoNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQta2FtcGF0aS1pcHNlY21lLWlrZXYyLXNhLXRzLXBheWxvYWRz LW9wdC0wMS50eHQNCg0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWthbXBhdGktaXBzZWNtZS1pa2V2Mi1zYS10cy1wYXlsb2Fkcy1vcHQvDQoN Ckh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta2FtcGF0 aS1pcHNlY21lLWlrZXYyLXNhLXRzLXBheWxvYWRzLW9wdC0wMQ0KDQpIdG1saXplZDogICAgICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1rYW1wYXRpLWlwc2Vj bWUtaWtldjItc2EtdHMtcGF5bG9hZHMtb3B0DQoNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQta2FtcGF0aS1pcHNlY21lLWlrZXYyLXNhLXRz LXBheWxvYWRzLW9wdC0wMQ0KDQoNCg0KQWJzdHJhY3Q6DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzIGEgbWV0aG9kIGZvciByZWR1Y2luZyB0aGUgc2l6ZSBvZiB0aGUNCg0KICAgSW50ZXJu ZXQgS2V5IEV4Y2hhbmdlIHZlcnNpb24gMiAoSUtFdjIpIGV4Y2hhbmdlcyBhdCB0aW1lIG9mIHJl a2V5aW5nDQoNCiAgIElLRSBTQXMgYW5kIENoaWxkIFNBcyBieSByZW1vdmluZyBvciBtYWtpbmcg b3B0aW9uYWwgb2YgU0EgJiBUUw0KDQogICBwYXlsb2Fkcy4gIFJlZHVjaW5nIHNpemUgb2YgSUtF djIgZXhjaGFuZ2VzIGlzIGRlc2lyYWJsZSBmb3IgbG93DQoNCiAgIHBvd2VyIGNvbnN1bXB0aW9u IGJhdHRlcnkgcG93ZXJlZCBkZXZpY2VzLiAgSXQgYWxzbyBoZWxwcyB0byBhdm9pZCBJUA0KDQog ICBmcmFnbWVudGF0aW9uIG9mIElLRXYyIG1lc3NhZ2VzLg0KDQoNCg0KDQoNCg0KDQoNCg0KUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNCg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCi0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAtLS0t LS0tLS0tLS0tLQ0KQW4gSFRNTCBhdHRhY2htZW50IHdhcyBzY3J1YmJlZC4uLg0KVVJMOiA8aHR0 cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9pcHNlYy9hdHRhY2htZW50cy8y MDE5MDUyMi9mYTM4OTU4MC9hdHRhY2htZW50Lmh0bWw+DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KDQpTdWJqZWN0OiBEaWdlc3QgRm9vdGVyDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJUHNlYyBtYWlsaW5nIGxpc3QNCklQc2Vj QGlldGYub3JnPG1haWx0bzpJUHNlY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXBzZWMNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KRW5kIG9mIElQc2VjIERpZ2VzdCwgVm9sIDE4MSwgSXNzdWUgNA0KKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0K --_000_30E95A901DB42F44BA42D69DB20DFA6A6DE200B0nkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuWNjuaWh+e7hum7kTsNCglwYW5vc2UtMToyIDEgNiAwIDQgMSAxIDEgMSAxO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IlxA5Y2O5paH57uG6buRIjsNCglwYW5vc2UtMToyIDEgNiAwIDQg MSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0KCXBhbm9zZS0x OjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29s YXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiUFQgTW9ubyI7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuag vOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9u dC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5nbWFpbC1tZnRyDQoJe21zby1zdHlsZS1uYW1lOmdt YWlsLW1fZnRyO30NCnNwYW4uZ21haWwtbWhkcg0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tX2hk cjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiR2FkdWdpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29QYXBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCW1hcmdpbi10b3A6MS41cHQ7DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJn aW4tYm90dG9tOjEuNXB0Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCgltc28tcGFyYS1tYXJnaW4tdG9w Oi4zZ2Q7DQoJbXNvLXBhcmEtbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tcGFyYS1tYXJnaW4tYm90 dG9tOi4zZ2Q7DQoJbXNvLXBhcmEtbWFyZ2luLWxlZnQ6MGNtO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQg OTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0dhZHVnaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5IaSBTaHViaGFtLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0dhZHVnaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtHYWR1Z2kmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+VGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgY29tbWVudHMuIFdl4oCZbGwgZml4 IHRoZW0gaW4gbmV4dCB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0dhZHVnaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTIwJSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7bGluZS1oZWlnaHQ6MTIwJTtmb250LWZhbWls eTomcXVvdDtHYWR1Z2kmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UmVnYXJkcyAmYW1w OyBUaGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjEyMCUiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtsaW5lLWhlaWdodDoxMjAlO2ZvbnQtZmFtaWx5OuWNjuaWh+e7hum7kTtjb2xvcjpi bGFjayI+5r2Y5LyfPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2xpbmUtaGVp Z2h0OjEyMCU7Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiBXZWkgUGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ni4wcHQiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrljY7mlofnu4bpu5E7Y29sb3I6YmxhY2siPuWN juS4uuaKgOacr+aciemZkOWFrOWPuDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtHYWR1Z2kmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ IEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSVBzZWMgW21haWx0bzppcHNl Yy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5zaHViaGFtIG1hbW9kaXlh PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBdWd1c3QgMDEsIDIwMTkgMzowMCBQTTxicj4N CjxiPlRvOjwvYj4gaXBzZWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJUHNl Y10gSVBzZWMgRGlnZXN0LCBWb2wgMTgxLCBJc3N1ZSA0PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0O2JhY2tn cm91bmQ6I0ZGRkRGNSI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91 bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZx dW90Oztjb2xvcjpibGFjayI+My4yLjMuJm5ic3A7IFJla2V5aW5nIElLRSBTQXMgV2hlbiBSZXNw b25kZXIncyBDcnlwdG9ncmFwaGljIFN1aXRlcyBDaGFuZ2VkPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3 b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3Jk ZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEF0IHRo ZSB0aW1lIG9mIG9yIGJlZm9yZSByZWtleWluZyBJS0UgU0FzLCB0aGUgcmVzcG9uZGVyJ3M8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFj a2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6 MGNtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBN b25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY3J5cHRvZ3JhcGhpYyBzdWl0ZXMg bWF5IGJlIGNoYW5nZWQgd2hpbGUgdGhlcmUgaXMgbm8gY2hhbmdlIG9mPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZG RkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGluaXRpYXRvcidzIGNyeXB0b2dyYXBoaWMgc3VpdGVz LiZuYnNwOyBOZXcgY3J5cHRvZ3JhcGhpYyBzdWl0ZXMgbWF5IGJlPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRG NTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFkZGVkIHRvIHRoZSByZXNwb25kZXIsIG9yIHNvbWUgb3V0 ZGF0ZWQgY3J5cHRvZ3JhcGhpYyBzdWl0ZXMgbWF5IGJlPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3Jk LWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IGRlbGV0ZWQgZnJvbSB0aGUgcmVzcG9uZGVyLjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNG RkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1h bGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBJbiB0aGlzIHNpdHVhdGlvbiwgdGhlIGluaXRpYXRvciBzZW5kcyB0aGUgU0FfVU5DSEFOR0VE IG5vdGlmaWNhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9y ZGVyOm5vbmU7cGFkZGluZzowY20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwYXls b2FkIGluc3RlYWQgb2YgdGhlIFNBIHBheWxvYWRzIGluIHRoZSBDUkVBVEVfQ0hJTERfU0EgcmVx dWVzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3 LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7 cGFkZGluZzowY20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBtZXNzYWdlIGF0IHRo ZSB0aW1lIG9mIHJla2V5aW5nIElLRSBTQXMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFr OmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcu OXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtw YWRkaW5nOjBjbSI+PHNwYW4gY2xhc3M9ImdtYWlsLW1mdHIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPkth bXBhdGksIGV0IGFsLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBFeHBpcmVzIE5vdmVtYmVyIDIyLCAyMDE5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFtQYWdlIDVdPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZG REY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48c3BhbiBj bGFzcz0iZ21haWwtbWhkciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+SW50ZXJuZXQtRHJhZnQmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgSUtFdjIgT3B0aW9uYWwgQ2hpbGQgU0EmYW1wO1RTIFBheWxvYWRz Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1h eSAyMDE5PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1 O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2Jv cmRlcjpub25lO3BhZGRpbmc6MGNtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgSWYg dGhlIHJlc3BvbmRlciBkZWNpZGVzIHRvIGNvbnRpbnVlIHVzaW5nIHRoZSBwcmV2aW91c2x5IG5l Z290aWF0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0 b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpu b25lO3BhZGRpbmc6MGNtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY3J5cHRvZ3Jh cGhpYyBzdWl0ZSB0byByZWtleSB0aGUgSUtFIFNBLCBpdCBNQVkgc2VuZCB0aGUgU0FfVU5DSEFO R0VEPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcu OXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtw YWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG5vdGlmaWNhdGlvbiBw YXlsb2FkIGluIHRoZSBDUkVBVEVfQ0hJTERfU0EgcmVzcG9uc2UgbWVzc2FnZSwgdGhlbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNr Z3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzow Y20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1v bm8mcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0aGUgcmVrZXlpbmcgaXMgY29uZHVj dGVkIGxpa2UgU2VjdGlvbiAzLjIuMS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJl YWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7 YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRp bmc6MGNtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQ VCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgSWYgdGhlIHJlc3BvbmRlciBk ZWNpZGVzIHRvIHJlLW5lZ290aWF0ZSB0aGUgY3J5cHRvZ3JhcGhpYyBzdWl0ZSwgaXQ8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dy b3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNt Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25v JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgTVVTVCBzZW5kIE5PX1BST1BPU0FMX0NI T1NFTiBub3RpZmljYXRpb24gcGF5bG9hZCBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQt YnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgQ1JFQVRFX0NISUxEX1NBIHJlc3BvbnNlIG1lc3NhZ2UuJm5ic3A7IEFm dGVyIHJlY2VpdmluZyB0aGlzIGVycm9yPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy ZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IG5vdGlmaWNhdGlvbiwgdGhlIGluaXRpYXRvciBNVVNUIHJldHJ5IHRoZSBDUkVBVEVf Q0hJTERfU0EgZXhjaGFuZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxs O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg d2l0aCB0aGUgU0EgcGF5bG9hZHMuJm5ic3A7IFRoZW4gdGhlIHJla2V5aW5nIGlzIGNvbmR1Y3Rl ZCBpbiB0aGUgb3JpZ2luYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxs O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg d2F5IGRlZmluZWQgaW4gW1JGQzcyOTZdLiZuYnNwOyBUaGUgQ1JFQVRFX0NISUxEX1NBIG1lc3Nh Z2UgZXhjaGFuZ2UgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2Jv cmRlcjpub25lO3BhZGRpbmc6MGNtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdGhp cyBjYXNlIGlzIHNob3duIGJlbG93OjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVh ay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDti YWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGlu ZzowY20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BU IE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBJbml0aWF0b3ImbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVzcG9uZGVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJy ZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy ZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IEhEUiwgU0sge04oU0FfVU5DSEFOR0VEKSwgTmksIEtFaX0gLS0mZ3Q7PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91 bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDstLSBIRFIsIFNLIHtO KE5PX1BST1BPU0FMX0NIT1NFTiksPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFr LWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IE5yLCBLRXJ9PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3Jk ZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEhEUiwg U0sge1NBLCBOaSwgS0VpfSAtLSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJl YWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmx0Oy0tIEhEUiwgU0sge1NBLCA8Yj5OaSwgS0VpPC9iPn08bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dy b3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNt O2JveC1zaXppbmc6Ym9yZGVyLWJveDt3b3JkLXdyYXA6YnJlYWstd29yZDtib3JkZXItcmFkaXVz OjRweDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj5Db21tZW50IDogPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91 bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbTti b3gtc2l6aW5nOmJvcmRlci1ib3g7d29yZC13cmFwOmJyZWFrLXdvcmQ7Ym9yZGVyLXJhZGl1czo0 cHg7b3ZlcmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+MS4gSWYgdGhlIHJlc3BvbmRlciBk ZWNpZGVzIHRvIGNvbnRpbnVlIHVzaW5nIHRoZSBwcmV2aW91c2x5IG5lZ290aWF0ZWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dy b3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNt O2JveC1zaXppbmc6Ym9yZGVyLWJveDt3b3JkLXdyYXA6YnJlYWstd29yZDtib3JkZXItcmFkaXVz OjRweDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY3J5cHRv Z3JhcGhpYyBzdWl0ZSB0byByZWtleSB0aGUgSUtFIFNBLCBpdCBNQVkgc2VuZCB0aGUgU0FfVU5D SEFOR0VEPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9t OjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9u ZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG5vdGlmaWNhdGlv biBwYXlsb2FkIGluIHRoZSBDUkVBVEVfQ0hJTERfU0EgcmVzcG9uc2UgbWVzc2FnZSwgdGhlbjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDti YWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGlu ZzowY20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1BU IE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0aGUgcmVrZXlpbmcgaXMgY29u ZHVjdGVkIGxpa2UgU2VjdGlvbiAzLjIuMS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6 YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtO2JveC1zaXppbmc6Ym9yZGVyLWJveDt3 b3JkLXdyYXA6YnJlYWstd29yZDtib3JkZXItcmFkaXVzOjRweDtvdmVyZmxvdzphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7 O2NvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyBCZXR0ZXIgdG8gcHV0IGV4Y2hhbmdlIGRpYWdyYW0gZm9y IHRoaXMgY2FzZSBhbHNvLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZG REY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxs O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtO2JveC1zaXppbmc6Ym9yZGVyLWJveDt3b3JkLXdyYXA6 YnJlYWstd29yZDtib3JkZXItcmFkaXVzOjRweDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJs YWNrIj4yLiBOb25jZSBhbmQgS0Ugbm90YXRpb25zIGFyZSBub3QgY29ycmVjdCBpbiB0aGUgcmVz cG9uc2UgbWVzc2FnZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9y ZGVyOm5vbmU7cGFkZGluZzowY207Ym94LXNpemluZzpib3JkZXItYm94O3dvcmQtd3JhcDpicmVh ay13b3JkO2JvcmRlci1yYWRpdXM6NHB4O292ZXJmbG93OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4gSWYgdGhlIHJlc3BvbmRl ciBkZWNpZGVzIHRvIHJlLW5lZ290aWF0ZSB0aGUgY3J5cHRvZ3JhcGhpYyBzdWl0ZSwgaXQ8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFj a2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6 MGNtIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IE1VU1Qgc2VuZCBOT19QUk9QT1NBTF9DSE9TRU4gbm90aWZpY2F0 aW9uIHBheWxvYWQgaW4gdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFs bDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBDUkVBVEVfQ0hJTERfU0Eg cmVzcG9uc2UgbWVzc2FnZS4mbmJzcDsgQWZ0ZXIgcmVjZWl2aW5nIHRoaXMgZXJyb3I8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dy b3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNt Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IG5vdGlmaWNhdGlvbiwgdGhlIGluaXRpYXRvciBNVVNUIHJldHJ5IHRo ZSBDUkVBVEVfQ0hJTERfU0EgZXhjaGFuZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6 YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHdpdGggdGhl IFNBIHBheWxvYWRzLiZuYnNwOyBUaGVuIHRoZSByZWtleWluZyBpcyBjb25kdWN0ZWQgaW4gdGhl IG9yaWdpbmFsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6 bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8m cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB3YXkgZGVmaW5lZCBpbiBbUkZDNzI5Nl0u ICZuYnNwO1RoZSBDUkVBVEVfQ0hJTERfU0EgbWVzc2FnZSBleGNoYW5nZSBpbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5k OiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgdGhpcyBjYXNlIGlzIHNob3duIGJlbG93OjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7 d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFj a2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6 MGNtIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IEluaXRpYXRvciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBSZXNwb25kZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1i b3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRl cjpub25lO3BhZGRpbmc6MGNtIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9u byZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6 I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBIRFIsIFNLIHtOKFNBX1VOQ0hBTkdFRCksIE5pLCBLRWl9IC0tJmd0OzxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNr Z3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzow Y20iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0Oy0tIEhEUiwgU0sge04oTk9fUFJPUE9TQUxf Q0hPU0VOKSw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0 b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpu b25lO3BhZGRpbmc6MGNtIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5yLCBLRXJ9PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRG NTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBIRFIsIFNLIHtTQSwgTmksIEtFaX0gLS0mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3Jk LWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1BUIE1vbm8mcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmbHQ7LS0gSERSLCBTSyB7U0EsIDxiPk5pLCBLRWk8L2I+fTxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNG RkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY207Ym94LXNp emluZzpib3JkZXItYm94O3dvcmQtd3JhcDpicmVhay13b3JkO2JvcmRlci1yYWRpdXM6NHB4O292 ZXJmbG93OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtQVCBNb25vJnF1b3Q7 O2NvbG9yOmJsYWNrIj4mZ3Q7Jmd0OyBJbiBDUkVBVEVfQ0hJTERfU0EgcmVzcG9uc2UgbWVzc2Fn ZSwgcmVzcG9uZGVyIE1VU1Qgbm90IHNlbmQgdGhlIHNhbWUgTm9uY2UgYW5kIEtFIHJlY2VpdmVk IGZyb20gaW5pdGlhdG9yIChOaSwgS0VpKS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6 YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtO2JveC1zaXppbmc6Ym9yZGVyLWJveDt3 b3JkLXdyYXA6YnJlYWstd29yZDtib3JkZXItcmFkaXVzOjRweDtvdmVyZmxvdzphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7UFQgTW9ubyZxdW90Oztjb2xvcjpibGFjayI+SXQg TVVTVCBiZSBOciBhbmQgS0VyIGluIHRoZSByZXNwb25zZSBtZXNzYWdlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUs IE1heSAyMywgMjAxOSBhdCAxMjozMCBBTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwc2VjLXJlcXVl c3RAaWV0Zi5vcmciPmlwc2VjLXJlcXVlc3RAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luOjAuLjhleCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TZW5kIElQc2VjIG1haWxpbmcgbGlzdCBzdWJtaXNzaW9ucyB0bzxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86aXBzZWNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5pcHNlY0BpZXRmLm9yZzwvYT48YnI+DQo8YnI+DQpUbyBzdWJzY3Jp YmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlzaXQ8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHNlYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXBzZWM8L2E+PGJyPg0Kb3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1l c3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0bzppcHNlYy1yZXF1ZXN0QGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+aXBzZWMtcmVxdWVzdEBpZXRmLm9yZzwvYT48YnI+DQo8YnI+DQpZb3UgY2Fu IHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQ8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOmlwc2VjLW93bmVyQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+aXBzZWMtb3duZXJAaWV0Zi5vcmc8L2E+PGJyPg0KPGJyPg0KV2hlbiByZXBs eWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZp Yzxicj4NCnRoYW4gJnF1b3Q7UmU6IENvbnRlbnRzIG9mIElQc2VjIGRpZ2VzdC4uLiZxdW90Ozxi cj4NCjxicj4NCjxicj4NClRvZGF5J3MgVG9waWNzOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsx LiBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3I8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyBkcmFmdC1rYW1wYXRpLWlwc2VjbWUtaWtldjItc2EtdHMtcGF5bG9hZHMtb3B0LTAxLnR4 dDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IChQYW53ZWkgKFdpbGxpYW0pKTxicj4NCjxicj4N Cjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpNZXNzYWdlOiAxPGJyPg0KRGF0ZTogV2Vk LCAyMiBNYXkgMjAxOSAwNzozNzoxNyAmIzQzOzAwMDA8YnI+DQpGcm9tOiAmcXVvdDtQYW53ZWkg KFdpbGxpYW0pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86d2lsbGlhbS5wYW53ZWlAaHVhd2Vp LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndpbGxpYW0ucGFud2VpQGh1YXdlaS5jb208L2E+Jmd0Ozxi cj4NClRvOiBQYXVsIFdvdXRlcnMgJmx0OzxhIGhyZWY9Im1haWx0bzpwYXVsQG5vaGF0cy5jYSIg dGFyZ2V0PSJfYmxhbmsiPnBhdWxAbm9oYXRzLmNhPC9hPiZndDssIFkgU293amkgJmx0OzxhIGhy ZWY9Im1haWx0bzpzb3dqaV9lbHVyaUB5YWhvby5jb20iIHRhcmdldD0iX2JsYW5rIj5zb3dqaV9l bHVyaUB5YWhvby5jb208L2E+Jmd0Oyw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmlwc2VjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXBz ZWNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aXBzZWNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5pcHNlY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KQ2M6IFNhbmRlZXAg S2FtcGF0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhbmRlZXBrYW1wYXRpQGh1YXdlaS5jb20iIHRh cmdldD0iX2JsYW5rIj5zYW5kZWVwa2FtcGF0aUBodWF3ZWkuY29tPC9hPiZndDssICZxdW90O01l ZHVyaSBTIFMgQmhhcmF0aDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAoQSkmcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpNZWR1cmlTLkJoYXJhdGhAaHVhd2VpLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPk1lZHVyaVMuQmhhcmF0aEBodWF3ZWkuY29tPC9hPiZndDs8YnI+DQpTdWJqZWN0 OiBbSVBzZWNdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBkcmFmdC1rYW1wYXRpLWlwc2VjbWUtaWtldjItc2EtdHMtcGF5 bG9hZHMtb3B0LTAxLnR4dDxicj4NCk1lc3NhZ2UtSUQ6PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZsdDs8YSBocmVmPSJtYWlsdG86MzBFOTVBOTAxREI0MkY0NEJBNDJENjlEQjIw REZBNkE2OUY2OEFCRUBua2dlbWw1MTMtbWJ4LmNoaW5hLmh1YXdlaS5jb20iIHRhcmdldD0iX2Js YW5rIj4zMEU5NUE5MDFEQjQyRjQ0QkE0MkQ2OURCMjBERkE2QTY5RjY4QUJFQG5rZ2VtbDUxMy1t YnguY2hpbmEuaHVhd2VpLmNvbTwvYT4mZ3Q7PGJyPg0KPGJyPg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluOyBjaGFyc2V0PSZxdW90O3V0Zi04JnF1b3Q7PGJyPg0KPGJyPg0KSGkgUGF1bCwgU293 amFueWEgYW5kIGZvbGtzLDxicj4NCjxicj4NCjxicj4NCjxicj4NClRoYW5rcyBhIGxvdCBmb3Ig UGF1bCBhbmQgU293amFueWE/cyByZXZpZXdzLCB3ZSBoYXZlIG1vZGlmaWVkIG91ciBkcmFmdCBi YXNlZCBvbiB5b3VyIGNvbW1lbnRzLjxicj4NCjxicj4NCjxicj4NCjxicj4NClRoZSBuZXcgdmVy c2lvbiBkcmFmdCBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIG1haW4gY2hhbmdlczo8YnI+DQo8YnI+ DQoxLiBSZWRlc2lnbiB0aGUgc2VjdGlvbnMgdG8gbWFrZSB0aGUgc3RydWN0dXJlIG1vcmUgcmVh c29uYWJsZSBhbmQgdGhlIGRyYWZ0IG1vcmUgcmVhZGFibGUuPGJyPg0KPGJyPg0KMi4gQ2hhbmdl IHRoZSBuZWdvdGlhdGlvbiBvZiBzdXBwb3J0IHRvIHRoZSBJS0VfQVVUSCBwaGFzZSwgYW5kIGNo YW5nZSB0aGUgc3VwcG9ydCBub3RpZmljYXRpb24/cyBuYW1lLjxicj4NCjxicj4NCjMuIERldGFp bCB0aGUgb3B0aW1pemF0aW9uIGZvciByZWtleWluZyBJS0UgU0FzLCBhbmQgdXNlIFNBX1VOQ0hB TkdFRCBub3RpZmljYXRpb24gcGF5bG9hZCB0byByZXBsYWNlIFNBIHBheWxvYWRzLjxicj4NCjxi cj4NCjQuIERldGFpbCB0aGUgb3B0aW1pemF0aW9uIGZvciByZWtleWluZyBDaGlsZCBTQXMsIGFu ZCB1c2UgU0FfVFNfVU5DSEFOR0VEIG5vdGlmaWNhdGlvbiBwYXlsb2FkIHRvIHJlcGxhY2UgU0Eg YW5kIFRTIHBheWxvYWQuPGJyPg0KPGJyPg0KNS4gRm9yIHJla2V5aW5nIENoaWxkIFNBcywgd2Ug Y3VycmVudGx5IHJlbW92ZSB0aGUgY29uc2lkZXJhdGlvbiB0aGF0IG9ubHkgb21pdHRpbmcgVFMg cGF5bG9hZHMsIGJlY2F1c2Ugd2UgdGhpbmsgdGhpcyBraW5kIG9taXR0aW5nIHdpbGwgaW50cm9k dWNlIG1vcmUgY29tcGxleGl0aWVzLiBJbml0aWF0b3IgU0EgcGF5bG9hZCwgSW5pdGlhdG9yIFRT IHBheWxvYWQsIFJlc3BvbmRlciBTQSBwYXlsb2FkIGFuZCBSZXNwb25kZXIgVFMgcGF5bG9hZCwN CiBpZiBlaXRoZXIgb2YgdGhlc2UgZm91ciBwYXlsb2FkcyBjYW4gYmUgb21pdHRlZCwgdGhlcmUg d2lsbCBiZSB1cCB0byAxNiBjaXJjdW1zdGFuY2VzLCB0aGF0IHdpbGwgYmUgdG9vIGNvbXBsZXgu PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQ29tbWVudHMgYW5kIHJldmlld3MgZm9yIHRoZSBuZXcg dmVyc2lvbiBkcmFmdCBhcmUgdmVyeSB3ZWxjb21lLjxicj4NCjxicj4NCjxicj4NCjxicj4NCkJl c3QgUmVnYXJkczxicj4NCjxicj4NCldlaSBQYW48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IDxhIGhyZWY9Im1haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT5dPGJyPg0KU2VudDog V2VkbmVzZGF5LCBNYXkgMjIsIDIwMTkgMjoxNyBQTTxicj4NClRvOiBNZWR1cmkgUyBTIEJoYXJh dGggKEEpICZsdDs8YSBocmVmPSJtYWlsdG86TWVkdXJpUy5CaGFyYXRoQGh1YXdlaS5jb20iIHRh cmdldD0iX2JsYW5rIj5NZWR1cmlTLkJoYXJhdGhAaHVhd2VpLmNvbTwvYT4mZ3Q7OyBNZWR1cmkg UyBTIEJoYXJhdGggKEEpICZsdDs8YSBocmVmPSJtYWlsdG86TWVkdXJpUy5CaGFyYXRoQGh1YXdl aS5jb20iIHRhcmdldD0iX2JsYW5rIj5NZWR1cmlTLkJoYXJhdGhAaHVhd2VpLmNvbTwvYT4mZ3Q7 OyBQYW53ZWkgKFdpbGxpYW0pICZsdDs8YSBocmVmPSJtYWlsdG86d2lsbGlhbS5wYW53ZWlAaHVh d2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndpbGxpYW0ucGFud2VpQGh1YXdlaS5jb208L2E+Jmd0 OzsNCiBTYW5kZWVwIEthbXBhdGkgJmx0OzxhIGhyZWY9Im1haWx0bzpzYW5kZWVwa2FtcGF0aUBo dWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FuZGVlcGthbXBhdGlAaHVhd2VpLmNvbTwvYT4m Z3Q7PGJyPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1rYW1w YXRpLWlwc2VjbWUtaWtldjItc2EtdHMtcGF5bG9hZHMtb3B0LTAxLnR4dDxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1rYW1wYXRp LWlwc2VjbWUtaWtldjItc2EtdHMtcGF5bG9hZHMtb3B0LTAxLnR4dDxicj4NCjxicj4NCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgV2VpIFBhbiBhbmQgcG9zdGVkIHRvIHRoZSBJ RVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KTmFtZTombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1rYW1wYXRpLWlwc2VjbWUt aWtldjItc2EtdHMtcGF5bG9hZHMtb3B0PGJyPg0KPGJyPg0KUmV2aXNpb246Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAxPGJyPg0KPGJyPg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJS0V2MiBPcHRpb25hbCBT QSZhbXA7VFMgUGF5bG9hZHMgaW4gQ2hpbGQgRXhjaGFuZ2U8YnI+DQo8YnI+DQpEb2N1bWVudCBk YXRlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsyMDE5LTA1LTIxPGJyPg0KPGJy Pg0KR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KPGJyPg0KUGFnZXM6Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDExPGJyPg0KPGJyPg0KVVJMOiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rYW1wYXRpLWlwc2VjbWUtaWtldjItc2EtdHMt cGF5bG9hZHMtb3B0LTAxLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWthbXBhdGktaXBzZWNtZS1pa2V2Mi1zYS10cy1wYXls b2Fkcy1vcHQtMDEudHh0PC9hPjxicj4NCjxicj4NClN0YXR1czombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQta2FtcGF0aS1pcHNlY21lLWlrZXYyLXNhLXRzLXBheWxvYWRzLW9wdC8iIHRhcmdldD0i X2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rYW1wYXRpLWlw c2VjbWUtaWtldjItc2EtdHMtcGF5bG9hZHMtb3B0LzwvYT48YnI+DQo8YnI+DQpIdG1saXplZDom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQta2FtcGF0aS1pcHNlY21lLWlrZXYyLXNhLXRzLXBheWxvYWRzLW9wdC0wMSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rYW1wYXRp LWlwc2VjbWUtaWtldjItc2EtdHMtcGF5bG9hZHMtb3B0LTAxPC9hPjxicj4NCjxicj4NCkh0bWxp emVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQta2FtcGF0aS1pcHNlY21lLWlrZXYyLXNhLXRzLXBh eWxvYWRzLW9wdCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQta2FtcGF0aS1pcHNlY21lLWlrZXYyLXNhLXRzLXBheWxvYWRzLW9wdDwv YT48YnI+DQo8YnI+DQpEaWZmOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWthbXBh dGktaXBzZWNtZS1pa2V2Mi1zYS10cy1wYXlsb2Fkcy1vcHQtMDEiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQta2FtcGF0aS1pcHNlY21lLWlr ZXYyLXNhLXRzLXBheWxvYWRzLW9wdC0wMTwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpBYnN0 cmFjdDo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBt ZXRob2QgZm9yIHJlZHVjaW5nIHRoZSBzaXplIG9mIHRoZTxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDtJbnRlcm5ldCBLZXkgRXhjaGFuZ2UgdmVyc2lvbiAyIChJS0V2MikgZXhjaGFuZ2VzIGF0IHRp bWUgb2YgcmVrZXlpbmc8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7SUtFIFNBcyBhbmQgQ2hpbGQg U0FzIGJ5IHJlbW92aW5nIG9yIG1ha2luZyBvcHRpb25hbCBvZiBTQSAmYW1wOyBUUzxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDtwYXlsb2Fkcy4mbmJzcDsgUmVkdWNpbmcgc2l6ZSBvZiBJS0V2MiBl eGNoYW5nZXMgaXMgZGVzaXJhYmxlIGZvciBsb3c8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7cG93 ZXIgY29uc3VtcHRpb24gYmF0dGVyeSBwb3dlcmVkIGRldmljZXMuJm5ic3A7IEl0IGFsc28gaGVs cHMgdG8gYXZvaWQgSVA8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ZnJhZ21lbnRhdGlvbiBvZiBJ S0V2MiBtZXNzYWdlcy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0t LS0tLS0tIG5leHQgcGFydCAtLS0tLS0tLS0tLS0tLTxicj4NCkFuIEhUTUwgYXR0YWNobWVudCB3 YXMgc2NydWJiZWQuLi48YnI+DQpVUkw6ICZsdDs8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZl LmlldGYub3JnL2FyY2gvYnJvd3NlL2lwc2VjL2F0dGFjaG1lbnRzLzIwMTkwNTIyL2ZhMzg5NTgw L2F0dGFjaG1lbnQuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9icm93c2UvaXBzZWMvYXR0YWNobWVudHMvMjAxOTA1MjIvZmEzODk1ODAvYXR0 YWNobWVudC5odG1sPC9hPiZndDs8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+DQo8YnI+DQpTdWJqZWN0OiBEaWdlc3QgRm9vdGVyPGJyPg0KPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJUHNlYyBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SVBzZWNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5JUHNlY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYzwvYT48YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpFbmQgb2YgSVBzZWMgRGlnZXN0LCBW b2wgMTgxLCBJc3N1ZSA0PGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_30E95A901DB42F44BA42D69DB20DFA6A6DE200B0nkgeml513mbxchi_-- From nobody Mon Aug 5 15:47:18 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94EA120025 for ; Mon, 5 Aug 2019 15:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 u-aXIlJcQr1i for ; Mon, 5 Aug 2019 15:47:14 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 74FDB12000E for ; Mon, 5 Aug 2019 15:47:14 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 462Xvg0tZTzFDB; Tue, 6 Aug 2019 00:47:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1565045231; bh=pr2qZa8uXeTkYbVvwVhfq4RAz7rLr9Gd3WlGms4DFLQ=; h=Date:From:To:cc:Subject; b=hU1Xhk3AT4A21J1lNh9BuhdqveHnjI/OIq+uIj+VwSxkzMMTgVG7o90oNOM6zB8MG /OI6w+F0VeEjom1z9CfGD/mGaRLOlZDyibv/nAY0u3SBBMGFbs6xj/qwN6uf2ou+uv fUOb87iyJMQzqJrfqH57qkefjIayJ8aJOM8tDax8= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id mLK6YvooE9HI; Tue, 6 Aug 2019 00:47:08 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 6 Aug 2019 00:47:07 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 457945C853; Mon, 5 Aug 2019 18:47:06 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 457945C853 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3D6EE40A7022; Mon, 5 Aug 2019 18:47:06 -0400 (EDT) Date: Mon, 5 Aug 2019 18:47:06 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" cc: tristan.ninet@inria.fr Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] FYI: A Novel Denial-of-Service Attack Against IKEv2 - HAL-Inria X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 22:47:17 -0000 https://hal.inria.fr/hal-01980276/document "A Novel Denial-of-Service Attack Against IKEv2 - HAL-Inria" (I've CC:ed the first author of the paper on this email) I've read through the paper, and I believe is very much misrepresents what it deems is a DoS attack against the IKEv2 protocol. The DoS attack described seems to think it can change the IP address and cause Initiator to be authenticated by a different peer than intended (ignoring all of IDi / IDr payloads it is relaying). Then the different peer is happy, but the last IKE_AUTH reply to the initiator would signify a failure. Then when the initiator sends an Informational message with a Delete payload and AUTHENTICATION_FAILED notify, the attacker drops the message. Now the different peer has "lost resources" since its IKE SA (and possibly IPsec SA) is up. A proper implementation would send a Liveness probe if its IPsec SA counters remain zero. It would also put an idle limit on an childless SA that resulted from a TS_UNAVAILABLE (as opposed to a by design childless IKE SA) It makes more wrong assumptions like "(TS negotiation will fail in most cases)" which I guess they think would fail because the different peer's have different IPsec SA configurations, but really if they are that different, they will also have different IDi/IDr payloads because a peer's configuration with many other peers for specific subnets would be configured with local/remote IDs as to not tie these to hardcoded IP addresses. Without explicit ID, the ID used is normally the ID_IPvx, and if that is used, using an IP address X with ID_IPv4 Y will also cause an IKE failure of the victim peer because for IP address X it would then expect ID_IPv4 X. It then "proves" this by using the strongswan/libreswan option uniqueids=no, which is an non-standard override used to allow multiple IDs to establish more than one connection. Obviously, such connections MUST use liveness/dpd to kick out idle connections, because you cannot detect a reconnect from behind NAT from a different user behind the same NAT, and you would accumulate a lot of connections from restarting clients that you wouldn't be able to cleanup otherwise. Assuming all peers are on dynamic IPs, so no ACL's kick in between the peers (which would really only happen on a mesh cloud encryption, where an attacker would be extremely unlikely able to selectively NAT or DROP packets), the DoS attack would still fail. If peer A tries to talk to peer B and ends up talking to peer C, then the attack would fail if peer A sends the IDr payload. If it does not send an IDr payload, then it likely expects the ID_IPv4 later which wouldn't match when it got redirected to a different peer, using a different ID_IPv4. But even we assume all of this is true, and the attacker can block the packets from peer A's delete request to peer C, then yes peer C uses one connection resource. If peer A attempts a new connection because its connection failed, the attacker can try this again, but peer C will replace the existing IKE/IPsec SA in the normal case. So doing the attack twice from the same peer (who is still trying to connect) will still only lead to one extra unused connection of peer C. So you would need many peers to get any real amount of memory wasted on peer C. But if peer C is expecting to be part of a mesh with _many_ peers, it will have the resources to setup connections with a large number of peers. Deflecting a few peers through other peers isn't going to present a different scale level. In the case where repeated attempts would not replace the existing connection (which they emulate using the strongswan/libreswan uniqueids=no option on peer C), peer C would indeed end up using another one connection of memory. Peer A would do some kind of back-off on the failures, so maybe you get a one connection per minute rate. You would still need a lot of peers to DoS peer C, which again means that peer C is already expected to talk to a lot of peers. At best you could double the load by sending each peer configured through another peer. And all this assumes peer C does not remove idle IKE/IPsec SA's, and does not use liveness/DPD. Which in a mesh peer to peer enterprise network encryption you would use. In a remote access VPN scenario, there is no "redirect to a different peer" as all peers only connect to the one security gateway (or a set of gateways with identical credentials) so 'redirecting' a peer is not possible. It goes on to say the attack is not possible with PSKs, which I don't understand. They also then mumbled about asymmetric authentication, which I don't understand, but regardless is basically only employed with EAPTLS and Remote Access VPNs, so it does not apply to this attack. When using PSK with a Group-ID, this "attack" is in fact the actual normal deployment that implementations already handle. A groupID plus PSK, at least on libreswan, implies uniqueids=no for free because otherwise each client would kick of the next client. Now imagine a client on flaky wifi that keeps dropping and reconnecting. It would actually set up duplicate connections faster than this entire peer redirection attack. Those configurations better better use liveness/dpd already to ensure an often reconnecting client is not generating hundreds of new IKE/IPsec SA's without cleaning up the old ones. (initial contact cannot be used when using groupID with PSK as all different clients identify the same). They link to proof of concept code at gitlab.com/deviation/demo but I cannot access this - it is a private repository. But from the description in the paper, they only show 3 VMs and one of these connection tricks - and don't show any of this at scale using containers to see how the target would respond when this happens at a scale of which this becomes an actual attack. In conclusion, I wish the authors of the paper would have contacted the IPsec community at IETF or the opensource vendors of strongswan or libreswan before publication. It also shows the limitations of formal proofs in the absence of understanding operational deployments and implementation details. And that one should never describe one's own inventions as "novel". Leave that praise to others. Paul From nobody Wed Aug 7 03:38:28 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF50120148; Wed, 7 Aug 2019 03:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 icG2jk5Dmz3q; Wed, 7 Aug 2019 03:38:25 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 10D9112002F; Wed, 7 Aug 2019 03:38:25 -0700 (PDT) Received: from stubbs.home (172-222-100-236.dhcp.chtrptr.net [172.222.100.236]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 74FDC601E9; Wed, 7 Aug 2019 06:38:24 -0400 (EDT) From: Christian Hopps Content-Type: multipart/signed; boundary="Apple-Mail=_5ABB3CA9-E66C-4F68-9DDA-4C9B80FCC47E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Wed, 7 Aug 2019 06:38:23 -0400 Cc: Christian Hopps , ipsecme-chairs@ietf.org To: "ipsec@ietf.org WG" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [IPsec] Possible new charter text to cover iptfs. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 10:38:27 -0000 --Apple-Mail=_5ABB3CA9-E66C-4F68-9DDA-4C9B80FCC47E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi ipsecme and chairs, As discussed @IETF105 we need to update the charter in order to adopt = the IPTFS draft, how does this look for addition to the charter? " The demand for Traffic Flow Confidentiality has been increasing in the = user community; however, the current method defined in RFC4303 (i.e., add = null padding to each ESP payload) is very inefficient in it's use of network resources. The working group will develop an alternative TFC solution = that provides for efficient use of network resources. " Thanks, Chris. --Apple-Mail=_5ABB3CA9-E66C-4F68-9DDA-4C9B80FCC47E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl1Kqh8ACgkQLh2DDte4 MCVLsg//SoWv1qZnZEsw6y5tafrXeiVm/8/l64J//fxpQ0Gd4YjILAqtMe8laDhv V2syysc5h4Q4RTNECUTkrf8UZIbABVzqrVm7dTNAztNNJpJjsnFa3WktCN4GuUip olFESAA9OJXq0GO9AmchBDTO0Zs+4MsuPMlUKTbSJHBaVzo7Gdn1BSmfCJbhKwaZ t3/IJOX+fUYs+B4aB1ySThrX9V7SedL19dLwXPDqRzNCID/vEtaU1Nkw5yrJrs37 qYSf5W217f/W0YY281u6iMZMNYK2FstNC8SrAxPTOmSSefMHC00t9nVRmFY6a4zX f+q9zz3efGiarTCl6kGIwJbUUl1eNjVuFTrxmQJSKqio9Lp0ALl77a5GGf1p8/dc wfzRC8GItKHYY42Sz5vPI1AHofuudUSpWwtgX/I77THGRetfrRyFnsiA30hVSHF5 CzEW6IbXJFr+xgOfssvnboDW8bYMcFDpff8Qx2/IoRBsWLcjlP910eWPf6pRTHg3 ynbvbE6kdow4cAUTGtTi1SQLxV1QEB+CSLCnRsZmzxmd/SgIYyHkkuASgqKO9QRq H0jwo7vkZuvg1+SDD0VnvkYYpe5dT/ORRXk6yAgjS8RFh9FQDiXbMQruSZDL/7Rt 0OWZn/tkia1z6BHAr28ANgpVKuOoeOzSm/5XmX6GUsYELffR0ok= =boc7 -----END PGP SIGNATURE----- --Apple-Mail=_5ABB3CA9-E66C-4F68-9DDA-4C9B80FCC47E-- From nobody Wed Aug 7 09:50:56 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2013312069F; Wed, 7 Aug 2019 09:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 PgHqq-JqsW-v; Wed, 7 Aug 2019 09:50:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03AB512069B; Wed, 7 Aug 2019 09:50:42 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0E732380BE; Wed, 7 Aug 2019 12:50:05 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C5E823F; Wed, 7 Aug 2019 12:50:41 -0400 (EDT) From: Michael Richardson To: Christian Hopps cc: "ipsec@ietf.org WG" , ipsecme-chairs@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Wed, 07 Aug 2019 12:50:41 -0400 Message-ID: <6115.1565196641@localhost> Archived-At: Subject: Re: [IPsec] Possible new charter text to cover iptfs. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 16:50:53 -0000 Christian Hopps wrote: > Hi ipsecme and chairs, > As discussed @IETF105 we need to update the charter in order to adopt > the IPTFS draft, how does this look for addition to the charter? Works for me. > " The demand for Traffic Flow Confidentiality has been increasing in > the user community; however, the current method defined in RFC4303 > (i.e., add null padding to each ESP payload) is very inefficient in > it's use of network resources. The working group will develop an > alternative TFC solution that provides for efficient use of network > resources. " > Thanks, Chris. _______________________________________________ IPsec > mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Aug 7 16:04:29 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D07120047; Wed, 7 Aug 2019 16:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 z_7wtlC91IQI; Wed, 7 Aug 2019 16:04:24 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 B9B34120033; Wed, 7 Aug 2019 16:04:24 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 463nBZ20rkzL2S; Thu, 8 Aug 2019 01:04:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1565219062; bh=BhP2iHQVVto4W75UXo+YbhuQfTGWOXniALa8R+DtVGU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=IVim0Y38quaceDzfCc5XLr5TsKznc+kMjIEupIkdxTUP02rZXbH0eA8mvZDmWGH4Q d4r1/Bwc9x6k13d3vTnYs21aWflb1MFN+K2+eg6PZkV6+WA5Jn1nIdmTNvYgI8Ls7+ ZzD2cGs75Wxq5SzsbGrYNjwVTPLTC6+tQdLqzZI4= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id GzTm0sNCsy-h; Thu, 8 Aug 2019 01:04:19 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 8 Aug 2019 01:04:18 +0200 (CEST) Received: from [10.163.87.139] (199-7-157-56.eng.wind.ca [199.7.157.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 94348353F92; Wed, 7 Aug 2019 19:04:17 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 94348353F92 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Wed, 7 Aug 2019 19:04:15 -0400 Cc: "ipsec@ietf.org WG" , ipsecme-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <90A18DDA-F20B-4B0C-8FB6-EF5969F7B121@nohats.ca> References: To: Christian Hopps Archived-At: Subject: Re: [IPsec] Possible new charter text to cover iptfs. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 23:04:27 -0000 Seems broad enough - works for me Sent from mobile device > On Aug 7, 2019, at 06:38, Christian Hopps wrote: >=20 > Hi ipsecme and chairs, >=20 > As discussed @IETF105 we need to update the charter in order to adopt the I= PTFS draft, how does this look for addition to the charter? >=20 > " > The demand for Traffic Flow Confidentiality has been increasing in the use= r > community; however, the current method defined in RFC4303 (i.e., add null > padding to each ESP payload) is very inefficient in it's use of network > resources. The working group will develop an alternative TFC solution that= > provides for efficient use of network resources. > " >=20 > Thanks, > Chris. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Aug 8 00:30:20 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60057120105; Thu, 8 Aug 2019 00:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JWDfgWdm0f7g; Thu, 8 Aug 2019 00:30:16 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7B61200E3; Thu, 8 Aug 2019 00:30:15 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id v18so87854794ljh.6; Thu, 08 Aug 2019 00:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=hLh/LUHBBP0gox3c8Fgd21iL6yVSu5tH63QXDGOWeyQ=; b=ikKY5iKH2Z9gWMJi/PMqUghf9MCs2FCBpfn1i53COawAG6ndQwfqN3pMJpcVt3oQJh HU90bzjuprp3As2weDzUg7eyavnDfivHZSRaEMxIDyipXRZ3BS71VpayGrMs8UD0Viv4 vcPDLGFYiKqAT1R/zgU49q2kMAlFoN81Kq35rPdtDj6dHgu7Z03xbcAyyUrfnTPr2J5U x0hAnMKaI6VN4ZUIDsgDf8e2ST19TGrxwZXZjuWSYCDSxWycXAqVX/BES1Z5pxhocYNs dWQnFdExZnUkEYiL1CekhF9ElWYx1k66qFl0hk6e4WSX0kUdGjh3XNShxJFinivLtzmC CDhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=hLh/LUHBBP0gox3c8Fgd21iL6yVSu5tH63QXDGOWeyQ=; b=QtTGlwVcJtYrBAlguyWAVp+5E1LS25LOE25XC1HdrG3bXe3LpEf+BaaLMTym9gKgeg 9JM8uF3lw+F1s5pWUfnPImPjFD7U7Ah0ykx0JDQmVT+vp+x9bSjtMJh26/4BmtD624zJ DNktVq1fDcyR+O0aN0aleJ+A8J+lsroWVinpSm3f2MKG7j6YTbfwcCzis7TbebEIWlOs /0bziOGU6asGybAS1vrOE1JYl95Cok7BLNoM3GWOyxu6HXU1kz2c6ltakcxgCaNxR+lB 1fNt9P6zsHdV0/FDaiLtYLk1D6/RdO7yT7mH96LD5oPnHpcl59yHYi6xIxWATjZZIAI4 KNGQ== X-Gm-Message-State: APjAAAX5zfpRvuOlnpbp+GL0nv9Q+uYQnBVoYM7s1hJDTQNxee/J9f99 LkpoJtnArKopQPz2/dbIzzSz/wTBdmRDBesQ4OR+alF24pY= X-Google-Smtp-Source: APXvYqzMErtMdUCX+2tlyeNOdlLh2KqkvgHywK6QRTXfjk8ZvtCN/xphJCbmLJpUtd5dkkiPDnw7H0w+kXSi1QrwDkY= X-Received: by 2002:a2e:8ed2:: with SMTP id e18mr7277539ljl.235.1565249413759; Thu, 08 Aug 2019 00:30:13 -0700 (PDT) MIME-Version: 1.0 From: "Stanislav V. Smyshlyaev" Date: Thu, 8 Aug 2019 10:30:39 +0300 Message-ID: To: ipsec@ietf.org Cc: cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000004ac6b5058f96073d" Archived-At: Subject: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 07:30:18 -0000 --0000000000004ac6b5058f96073d Content-Type: text/plain; charset="UTF-8" Dear ipsecme, I am writing this message on behalf of the CFRG chairs. Currently there is an ongoing PAKE selection process in the CFRG. According to the plan of the PAKE selection process, the CFRG chairs have selected a number of PAKE-related topics that require independent reviews from experts deeply involved in several particular areas of IETF work: TLS and IPsec protocols, constrained environments and privacy. The chairs would like to announce the call for reviewers, who will be asked to prepare their reviews regarding one or more of the following topics about the nominated PAKEs: - Convenience for usage within/together with TLS 1.3 Handshake. *- Convenience for usage within/together with IKEv2.* - Convenience for usage in M2M/IoT protocols (i.e., with corresponding constrains on hardware). - Privacy considerations (e.g., recommendations to prevent user enumeration). The experts who would like to volunteer to do such a review are kindly asked to choose: 1) which topics from the provided list will be considered by them; 2) whether they could prepare their reviews for - all four balanced PAKEs, - all four augmented PAKEs or - all eight candidate PAKEs. We ask each of the expert to prepare reviews for all PAKEs (or at least all balanced/all augmented ones) to be sure that each of the PAKEs will be studied from the same points of view. *The call for reviewers will last until the 15th of August. Please send a message to cfrg@irtf.org or cfrg-chairs@ietf.org , if you could help. * Deadline for the reviews is 15th of September. The reviews will later be provided to Crypto Review Panel experts, who will prepare their overall reviews during Stage 5. Best regards, Stanislav Smyshlyaev, CFRG Secretary --0000000000004ac6b5058f96073d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear=C2=A0ipsecme,

I am writing t= his message on behalf of the CFRG chairs.

Currently ther= e is an ongoing PAKE selection process in the CFRG.
According to = the plan of the PAKE selection process, the CFRG chairs have selected a num= ber of PAKE-related topics that require independent reviews from experts de= eply involved in several particular areas of IETF work: TLS and IPsec proto= cols, constrained environments and privacy.=C2=A0

The chairs would l= ike to announce the call for reviewers, who will be asked to prepare their = reviews regarding one or more of the following topics about the nominated P= AKEs:
- Convenience for usage within/together with TLS 1.3 Handshake.- Convenience for usage within/together with IKEv2.
- Convenienc= e for usage in M2M/IoT protocols (i.e., with corresponding constrains on=C2= =A0hardware).
- Privacy considerations (e.g., recommendations to prevent= user enumeration).

The experts who would like to volunteer to do su= ch a review are kindly asked to choose:
1) which topics from the provide= d list will be considered by them;
2) whether they could prepare their r= eviews for=C2=A0
- all four balanced PAKEs,
- all four augmented PAKE= s or
- all eight candidate PAKEs.

We ask each of the expert to pr= epare reviews for all PAKEs (or at least all balanced/all augmented ones) t= o be sure that each of the PAKEs will be studied from the same points of vi= ew.

The call for reviewers will last until the 15th of August. Pl= ease send a message to=C2=A0cfrg@irtf.org=C2=A0or=C2=A0cfrg-chairs@ietf.org, if you could help.=C2=A0
Deadline for the reviews is 15th of September.

The reviews w= ill later be provided to Crypto Review Panel experts, who will prepare thei= r overall reviews during Stage 5.

Best regards,
Stanislav Smyshlyaev,
CFRG Secretary
--0000000000004ac6b5058f96073d-- From nobody Thu Aug 29 15:48:22 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832E2120059 for ; Thu, 29 Aug 2019 15:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 yUPo1LdGUCib for ; Thu, 29 Aug 2019 15:48:11 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 47A1D120089 for ; Thu, 29 Aug 2019 15:48:11 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0PX0002C0SOA02@wwwlocal.goatley.com> for ipsec@ietf.org; Thu, 29 Aug 2019 17:48:10 -0500 (CDT) Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PX000L3SSKZAX@trixy.bergandi.net> for ipsec@ietf.org; Thu, 29 Aug 2019 15:46:12 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Thu, 29 Aug 2019 15:46:12 -0700 Date: Thu, 29 Aug 2019 15:48:08 -0700 From: Dan Harkins In-reply-to: To: ipsec@ietf.org Cc: "cfrg@irtf.org" Message-id: <7538495e-258d-1927-cbba-eb783675c83f@lounge.org> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Uu8RA29dFL+5pz0Oniw0GQ)" Content-language: en-US User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local) References: X-PMAS-Software: PreciseMail V3.3 [190828c] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 22:48:15 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Uu8RA29dFL+5pz0Oniw0GQ) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 8BIT   Hello,   I had some discussions with several people in Montreal on the subject of using a PAKE in IKE without using the RFC 6467 "PAKE framework", which is quite cumbersome. I was told I should bring it up on the IPsec list so here goes (copying CFRG since that's where the PAKE work is being done).   First of all this suggestion is for a particular PAKE and I'm not suggesting that any of the other candidates would slide in so effortlessly. In fact an augmented PAKE is, IMHO, not suitable for a protocol like IKE where either side can initiate. The PAKE I'm describing here is SPEKE, a balance PAKE.   SPEKE does a simple Diffie-Hellman but uses a secret generator that is deterministically obtained from the password. This technique is basically one of the hash-to-curve functions from the CFRG's hash-to-curve I-D or a simple hashing and exponentiation for MODP groups. All this happens at password provisioning time prior to IKE being run.   Then when IKE is run the secret generator for the negotiated group is used to do the D-H, the IKE_SA_INIT exchange is basically SPEKE. The result is, if they both have the same generator (which means they had the same password), an authenticated shared secret. This secret is verified in the IKE_AUTH exchange.   This would require a new Auth Method defined for SPEKE/PAKE to indicate that the SPEKE shared secret is used. And that should be all that's needed. It should be that simple. The protocol shouldn't have to change, no new messages, no new payloads, no new nuthin. If I'm missing something please let me know.   regards,   Dan. On 8/8/19 12:30 AM, Stanislav V. Smyshlyaev wrote: > Dear ipsecme, > > I am writing this message on behalf of the CFRG chairs. > > Currently there is an ongoing PAKE selection process in the CFRG. > According to the plan of the PAKE selection process, the CFRG chairs > have selected a number of PAKE-related topics that require independent > reviews from experts deeply involved in several particular areas of > IETF work: TLS and IPsec protocols, constrained environments and privacy. > > The chairs would like to announce the call for reviewers, who will be > asked to prepare their reviews regarding one or more of the following > topics about the nominated PAKEs: > - Convenience for usage within/together with TLS 1.3 Handshake. > *- Convenience for usage within/together with IKEv2.* > - Convenience for usage in M2M/IoT protocols (i.e., with corresponding > constrains on hardware). > - Privacy considerations (e.g., recommendations to prevent user > enumeration). > > The experts who would like to volunteer to do such a review are kindly > asked to choose: > 1) which topics from the provided list will be considered by them; > 2) whether they could prepare their reviews for > - all four balanced PAKEs, > - all four augmented PAKEs or > - all eight candidate PAKEs. > > We ask each of the expert to prepare reviews for all PAKEs (or at > least all balanced/all augmented ones) to be sure that each of the > PAKEs will be studied from the same points of view. > > *The call for reviewers will last until the 15th of August. Please > send a message to cfrg@irtf.org  or > cfrg-chairs@ietf.org , if you could help. * > Deadline for the reviews is 15th of September. > > The reviews will later be provided to Crypto Review Panel experts, who > will prepare their overall reviews during Stage 5. > > Best regards, > Stanislav Smyshlyaev, > CFRG Secretary > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_Uu8RA29dFL+5pz0Oniw0GQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: 8BIT
  Hello,

  I had some discussions with several people in Montreal on the subject of
using a PAKE in IKE without using the RFC 6467 "PAKE framework", which is
quite cumbersome. I was told I should bring it up on the IPsec list so
here goes (copying CFRG since that's where the PAKE work is being done).

  First of all this suggestion is for a particular PAKE and I'm not
suggesting that any of the other candidates would slide in so effortlessly.
In fact an augmented PAKE is, IMHO, not suitable for a protocol like IKE
where either side can initiate. The PAKE I'm describing here is SPEKE,
a balance PAKE.

  SPEKE does a simple Diffie-Hellman but uses a secret generator that is
deterministically obtained from the password. This technique is basically
one of the hash-to-curve functions from the CFRG's hash-to-curve I-D
or a simple hashing and exponentiation for MODP groups. All this happens
at password provisioning time prior to IKE being run.

  Then when IKE is run the secret generator for the negotiated group is
used to do the D-H, the IKE_SA_INIT exchange is basically SPEKE. The
result is, if they both have the same generator (which means they had the
same password), an authenticated shared secret. This secret is verified in
the IKE_AUTH exchange.

  This would require a new Auth Method defined for SPEKE/PAKE to indicate
that the SPEKE shared secret is used. And that should be all that's needed.
It should be that simple. The protocol shouldn't have to change, no new
messages, no new payloads, no new nuthin. If I'm missing something please
let me know.

  regards,

  Dan.

On 8/8/19 12:30 AM, Stanislav V. Smyshlyaev wrote:
Dear ipsecme,

I am writing this message on behalf of the CFRG chairs.

Currently there is an ongoing PAKE selection process in the CFRG.
According to the plan of the PAKE selection process, the CFRG chairs have selected a number of PAKE-related topics that require independent reviews from experts deeply involved in several particular areas of IETF work: TLS and IPsec protocols, constrained environments and privacy. 

The chairs would like to announce the call for reviewers, who will be asked to prepare their reviews regarding one or more of the following topics about the nominated PAKEs:
- Convenience for usage within/together with TLS 1.3 Handshake.
- Convenience for usage within/together with IKEv2.
- Convenience for usage in M2M/IoT protocols (i.e., with corresponding constrains on hardware).
- Privacy considerations (e.g., recommendations to prevent user enumeration).

The experts who would like to volunteer to do such a review are kindly asked to choose:
1) which topics from the provided list will be considered by them;
2) whether they could prepare their reviews for 
- all four balanced PAKEs,
- all four augmented PAKEs or
- all eight candidate PAKEs.

We ask each of the expert to prepare reviews for all PAKEs (or at least all balanced/all augmented ones) to be sure that each of the PAKEs will be studied from the same points of view.

The call for reviewers will last until the 15th of August. Please send a message to cfrg@irtf.org or cfrg-chairs@ietf.org, if you could help. 
Deadline for the reviews is 15th of September.

The reviews will later be provided to Crypto Review Panel experts, who will prepare their overall reviews during Stage 5.

Best regards,
Stanislav Smyshlyaev,
CFRG Secretary

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--Boundary_(ID_Uu8RA29dFL+5pz0Oniw0GQ)-- From nobody Thu Aug 29 17:11:33 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28831200B2 for ; Thu, 29 Aug 2019 17:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 AZMB4VWCdbfd for ; Thu, 29 Aug 2019 17:11:30 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 EC32F1200F8 for ; Thu, 29 Aug 2019 17:11:29 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x7U0BRE5028040 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Aug 2019 03:11:27 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x7U0BQ8A014560; Fri, 30 Aug 2019 03:11:26 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <23912.27054.796487.391930@fireball.acr.fi> Date: Fri, 30 Aug 2019 03:11:26 +0300 From: Tero Kivinen To: Dan Harkins Cc: ipsec@ietf.org In-Reply-To: <7538495e-258d-1927-cbba-eb783675c83f@lounge.org> References: <7538495e-258d-1927-cbba-eb783675c83f@lounge.org> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 8 min Archived-At: Subject: Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 00:11:32 -0000 [removed cfrg from CC, as I do not think this issue really belongs there as we are discussing IKE signaling here]. Dan Harkins writes: > =A0 First of all this suggestion is for a particular PAKE and I'm not= > suggesting that any of the other candidates would slide in so effortl= essly. > In fact an augmented PAKE is, IMHO, not suitable for a protocol like = IKE > where either side can initiate. The PAKE I'm describing here is SPEKE= , > a balance PAKE. >=20 > =A0 SPEKE does a simple Diffie-Hellman but uses a secret generator th= at is > deterministically obtained from the password. This technique is basic= ally > one of the hash-to-curve functions from the CFRG's hash-to-curve I-D > or a simple hashing and exponentiation for MODP groups. All this happ= ens > at password provisioning time prior to IKE being run. >=20 > =A0 Then when IKE is run the secret generator for the negotiated grou= p is > used to do the D-H, the IKE=5FSA=5FINIT exchange is basically SPEKE. = The > result is, if they both have the same generator (which means they had= the > same password), an authenticated shared secret. This secret is verifi= ed in > the IKE=5FAUTH exchange. How does the responder know which of the one million username password pairs to pick to generate the generator when calculating D-H in the IKE=5FSA=5FINIT=3F The actual identity of the user is only sent in the encrypted IKE=5FAUTH message.=20 I.e., I think this has exactly same problem than IKEv1 has with pre-shared keys for main mode. You must know the initiator identity based on the IP-addresses, thus makes this completely unusable for non static VPN cases. > =A0 This would require a new Auth Method defined for SPEKE/PAKE to in= dicate > that the SPEKE shared secret is used. And that should be all that's n= eeded. > It should be that simple. The protocol shouldn't have to change, no n= ew > messages, no new payloads, no new nuthin. If I'm missing something pl= ease > let me know. --=20 kivinen@iki.fi From nobody Thu Aug 29 19:55:15 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39563120888 for ; Thu, 29 Aug 2019 19:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 KUHdDyatnuO4 for ; Thu, 29 Aug 2019 19:55:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2061C12021D for ; Thu, 29 Aug 2019 19:55:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F18403808A; Thu, 29 Aug 2019 22:53:57 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5D8BFD8C; Thu, 29 Aug 2019 22:55:09 -0400 (EDT) From: Michael Richardson To: Dan Harkins cc: ipsec@ietf.org, "cfrg\@irtf.org" In-Reply-To: <7538495e-258d-1927-cbba-eb783675c83f@lounge.org> References: <7538495e-258d-1927-cbba-eb783675c83f@lounge.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 02:55:13 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dan Harkins wrote: > =C2=A0 I had some discussions with several people in Montreal on the = subject of > using a PAKE in IKE without using the RFC 6467 "PAKE framework", whic= h is > quite cumbersome. I was told I should bring it up on the IPsec list so Understood, but could you say, despite that, why it's worth it for SPEKE? Afterall, we adopted EAP, which could also be said to be quite cumbersome rather than build all sorts of username/password and 3GPP/SIM integrations.. > In fact an augmented PAKE is, IMHO, not suitable for a protocol like = IKE > where either side can initiate. The PAKE I'm describing here is SPEKE, > a balance PAKE. Got it. > =C2=A0 This would require a new Auth Method defined for SPEKE/PAKE to= indicate > that the SPEKE shared secret is used. And that should be all that's n= eeded. > It should be that simple. The protocol shouldn't have to change, no n= ew > messages, no new payloads, no new nuthin. If I'm missing something pl= ease > let me know. As I understand you, it's basically PSK authentication, but the PSK is no longer directly shared. Would the QM "augmentation" of PSK have any val= ue here? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1okA0ACgkQgItw+93Q 3WUoZwf/U9Toy+7z6hURlL6LwHA413/Ouq8nWGGqNt2sgpt0D6uN6ZIuWugh0QpX a4yeI4wZesG8R93n5OhaY0iturx6YqsHGoYVSRbNd3ZktU59VWEItOI7C1O9Mq/e 0PjRU9HSmtunml0qtfXpJOb8j7T4u8s1gVk/D7506dd325v69g/d1pN89nkCCQ9o iLkezjr5H13UVVdBLlQdfmoXszedvdoVOdcAGZf9912W9TI3g7He4jpaApy8CXxa mrfIYFXFwZpMMsAQcRMOXOJWna6m5i3gTKk1d6j/ZdGifCRMcngmvPcrXiKfGEVJ nloP0MPCSsQOao2VMDeQcKucccJydg== =/x15 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 30 00:11:33 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63BA1201E5 for ; Fri, 30 Aug 2019 00:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 9Nm5GeslXj4t for ; Fri, 30 Aug 2019 00:11:30 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 84D2F120113 for ; Fri, 30 Aug 2019 00:11:30 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0PX100610FZ6TX@wwwlocal.goatley.com> for ipsec@ietf.org; Fri, 30 Aug 2019 02:11:30 -0500 (CDT) Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PX100N1GFZ4JV@trixy.bergandi.net> for ipsec@ietf.org; Fri, 30 Aug 2019 00:11:29 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Fri, 30 Aug 2019 00:11:29 -0700 Date: Fri, 30 Aug 2019 00:11:28 -0700 From: Dan Harkins In-reply-to: <23912.27054.796487.391930@fireball.acr.fi> To: ipsec@ietf.org Message-id: <58d82a8c-d789-17ee-12b0-f935d7d2037e@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local) References: <7538495e-258d-1927-cbba-eb783675c83f@lounge.org> <23912.27054.796487.391930@fireball.acr.fi> X-PMAS-Software: PreciseMail V3.3 [190828c] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 07:11:32 -0000 On 8/29/19 5:11 PM, Tero Kivinen wrote: > [removed cfrg from CC, as I do not think this issue really belongs > there as we are discussing IKE signaling here]. > > Dan Harkins writes: >>   First of all this suggestion is for a particular PAKE and I'm not >> suggesting that any of the other candidates would slide in so effortlessly. >> In fact an augmented PAKE is, IMHO, not suitable for a protocol like IKE >> where either side can initiate. The PAKE I'm describing here is SPEKE, >> a balance PAKE. >> >>   SPEKE does a simple Diffie-Hellman but uses a secret generator that is >> deterministically obtained from the password. This technique is basically >> one of the hash-to-curve functions from the CFRG's hash-to-curve I-D >> or a simple hashing and exponentiation for MODP groups. All this happens >> at password provisioning time prior to IKE being run. >> >>   Then when IKE is run the secret generator for the negotiated group is >> used to do the D-H, the IKE_SA_INIT exchange is basically SPEKE. The >> result is, if they both have the same generator (which means they had the >> same password), an authenticated shared secret. This secret is verified in >> the IKE_AUTH exchange. > How does the responder know which of the one million username password > pairs to pick to generate the generator when calculating D-H in the > IKE_SA_INIT? The actual identity of the user is only sent in the > encrypted IKE_AUTH message. > > I.e., I think this has exactly same problem than IKEv1 has with > pre-shared keys for main mode. You must know the initiator identity > based on the IP-addresses, thus makes this completely unusable for > non static VPN cases.   HA! I did miss something :-)   Yes, I guess a new payload is needed to express the username. This can be added to the IKE_SA_INIT message. Or maybe it can be a special type of NOTIFY, that's a six-of-one-and-a-half-dozen-of-the-other issue. But this should not involve an extra Auth exchange (as the framework PAKEs do) since SPEKE is just a Diffie-Hellman exchange which is exactly what IKE is.   regards,   Dan. >>   This would require a new Auth Method defined for SPEKE/PAKE to indicate >> that the SPEKE shared secret is used. And that should be all that's needed. >> It should be that simple. The protocol shouldn't have to change, no new >> messages, no new payloads, no new nuthin. If I'm missing something please >> let me know. From nobody Fri Aug 30 01:13:42 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9901C1202A0 for ; Fri, 30 Aug 2019 01:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1PXegSnjLOkV for ; Fri, 30 Aug 2019 01:13:39 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 F2FB5120113 for ; Fri, 30 Aug 2019 01:13:38 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0PX100637IUQTX@wwwlocal.goatley.com> for ipsec@ietf.org; Fri, 30 Aug 2019 03:13:38 -0500 (CDT) Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PX100N2OIUOJV@trixy.bergandi.net> for ipsec@ietf.org; Fri, 30 Aug 2019 01:13:37 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Fri, 30 Aug 2019 01:13:37 -0700 Date: Fri, 30 Aug 2019 01:13:33 -0700 From: Dan Harkins In-reply-to: <9537.1567133709@localhost> To: Michael Richardson Cc: ipsec@ietf.org Message-id: <7f6a806a-ac96-dc20-ce6b-12499c04c271@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local) References: <7538495e-258d-1927-cbba-eb783675c83f@lounge.org> <9537.1567133709@localhost> X-PMAS-Software: PreciseMail V3.3 [190828c] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 08:13:41 -0000 On 8/29/19 7:55 PM, Michael Richardson wrote: > Dan Harkins wrote: > >   I had some discussions with several people in Montreal on the subject of > > using a PAKE in IKE without using the RFC 6467 "PAKE framework", which is > > quite cumbersome. I was told I should bring it up on the IPsec list so > > Understood, but could you say, despite that, why it's worth it for SPEKE? > Afterall, we adopted EAP, which could also be said to be quite cumbersome > rather than build all sorts of username/password and 3GPP/SIM integrations..   The "PAKE framework" is complicated and unnecessary. Around the time that I was proposing a PAKE for IKE, "EAP-only" IKE was also being proposed. As it turns out the only reason to use EAP-only IKE was with a PAKE-- server-side cert was taken care of by normal EAP-IKE and if both sides have a cert then just do plain jane IKE. But the chairs at the time had a vested interest in doing EAP-only and in making PAKE, the alternative to EAP-only, be as cumbersome as possible. And so we got this mess that no one implements.   SPEKE can just fall straight into the IKE_SA_INIT exchange (with a username indicator as Tero pointed out) and it is authenticated with the IKE_AUTH exchange. There is no additional framework messaging and there is no EAP messaging and overhead. It's clean. > > In fact an augmented PAKE is, IMHO, not suitable for a protocol like IKE > > where either side can initiate. The PAKE I'm describing here is SPEKE, > > a balance PAKE. > > Got it. > > >   This would require a new Auth Method defined for SPEKE/PAKE to indicate > > that the SPEKE shared secret is used. And that should be all that's needed. > > It should be that simple. The protocol shouldn't have to change, no new > > messages, no new payloads, no new nuthin. If I'm missing something please > > let me know. > > As I understand you, it's basically PSK authentication, but the PSK is > no longer directly shared. Would the QM "augmentation" of PSK have any value > here?   Yes, that's a way of thinking of it. The PSK is not shared and no PSK-derived data is shared. Both sides prove they know the secret without exposing it.   regards,   Dan. From nobody Fri Aug 30 02:28:01 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD60120C74 for ; Fri, 30 Aug 2019 02:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 8D361NxVtCQ2 for ; Fri, 30 Aug 2019 02:27:56 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 C0C7612004F for ; Fri, 30 Aug 2019 02:27:54 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x7U9Rp23029256 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Aug 2019 12:27:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x7U9Roc1014214; Fri, 30 Aug 2019 12:27:50 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <23912.60438.716153.761077@fireball.acr.fi> Date: Fri, 30 Aug 2019 12:27:50 +0300 From: Tero Kivinen To: Dan Harkins Cc: ipsec@ietf.org In-Reply-To: <58d82a8c-d789-17ee-12b0-f935d7d2037e@lounge.org> References: <7538495e-258d-1927-cbba-eb783675c83f@lounge.org> <23912.27054.796487.391930@fireball.acr.fi> <58d82a8c-d789-17ee-12b0-f935d7d2037e@lounge.org> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 13 min Archived-At: Subject: Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 09:28:00 -0000 Dan Harkins writes: > > How does the responder know which of the one million username passw= ord > > pairs to pick to generate the generator when calculating D-H in the= > > IKE=5FSA=5FINIT=3F The actual identity of the user is only sent in = the > > encrypted IKE=5FAUTH message. > > > > I.e., I think this has exactly same problem than IKEv1 has with > > pre-shared keys for main mode. You must know the initiator identity= > > based on the IP-addresses, thus makes this completely unusable for > > non static VPN cases. >=20 > =A0 HA! I did miss something :-) >=20 > =A0 Yes, I guess a new payload is needed to express the username. Th= is can > be added to the IKE=5FSA=5FINIT message. Or maybe it can be a special= type of > NOTIFY, that's a six-of-one-and-a-half-dozen-of-the-other issue. But = this > should not involve an extra Auth exchange (as the framework PAKEs do)= > since SPEKE is just a Diffie-Hellman exchange which is exactly what I= KE > is. We had similar discussion in the postquantum preshared keys case, i.e., we needed to know the identity of the other end to pick the PPK, but the identity is only transmitted in the IKE=5FAUTH, and IKE=5FAUTH = is encrypted with the key which is generated in IKE=5FSA=5FINIT. We solved= this issue in qr-ikev2 by making so that encryption of the IKE=5FAUTH does not need the PPK, but uses only normal Diffie-Hellman and PPK is only added to the actual IPsec trafic keys. The problem is that if we add the identity to the IKE=5FSA=5FINIT, then= we loose the identity protection part of the IKEv2, as we then cannot encrypt the identity. Current solutions have been trying to keep the identity protection part as good as it is without those extensions, i.e., qr-ikev2 still provides same identity protection than what normal IKEv2 does, and then provides extended protection for the actual trafic keys. Attacker who can break Diffie-Hellman can see the identities, but will not see the actual trafic protected by PPK. With PAKEs, I think it is important to do the same, i.e., keep the identity protection parts of the IKEv2 at least as good as they are now, and that usually needs we need to do normal IKEv2 Diffie-Hellman first to protect identities, and then inside that when we know identities do the actual authentication using PAKE. Hybrid qske does things bit differently as it adds IKE=5FINTERMEDIATE exchanges between IKE=5FSA=5FINIT and IKE=5FAUTH but all of those IKE=5FINTERMEDIATE exchanges are anonymous, i.e., the identity of the other end is not yet known, the authentication is done in the end with IKE=5FAUTH, and only then the identity of the other end is known, and w= e can use per user information like shared keys or password etc. --=20 kivinen@iki.fi From nobody Fri Aug 30 07:40:52 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56A51208FF for ; Fri, 30 Aug 2019 07:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 Bi-0cBnnNT9U for ; Fri, 30 Aug 2019 07:40:48 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 0064B1208EE for ; Fri, 30 Aug 2019 07:40:47 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46Khws38R3zFTY; Fri, 30 Aug 2019 16:40:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1567176045; bh=qdg1WWl+BULOZ7ybj1Hm1RI7w/jOqRB8Fv7x9jMcek8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ldVrEwDAoBoMcGp5Ry/gmi+CYlA/PcolDZlpiWHuvE0VS/vKf4d3etVxr9HlxusN4 Vs06FHYQgUplMafkBclTkJdOWHgfl6HmozwQdSmR3X1gblfhVxFVWnA86mFt0XHvjj F+f5Ml3J3zKV86VQwQ4bpLPRCrpPUF8+DqTdIxWI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id koU6k815MaZZ; Fri, 30 Aug 2019 16:40:43 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 30 Aug 2019 16:40:43 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 31AA5322DE3; Fri, 30 Aug 2019 10:40:42 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 31AA5322DE3 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 21980406A927; Fri, 30 Aug 2019 10:40:42 -0400 (EDT) Date: Fri, 30 Aug 2019 10:40:42 -0400 (EDT) From: Paul Wouters To: Tero Kivinen cc: Dan Harkins , ipsec@ietf.org In-Reply-To: <23912.60438.716153.761077@fireball.acr.fi> Message-ID: References: <7538495e-258d-1927-cbba-eb783675c83f@lounge.org> <23912.27054.796487.391930@fireball.acr.fi> <58d82a8c-d789-17ee-12b0-f935d7d2037e@lounge.org> <23912.60438.716153.761077@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 14:40:50 -0000 On Fri, 30 Aug 2019, Tero Kivinen wrote: > Current solutions have been trying to keep the identity protection > part as good as it is without those extensions, i.e., qr-ikev2 still > provides same identity protection than what normal IKEv2 does, and > then provides extended protection for the actual trafic keys. Attacker > who can break Diffie-Hellman can see the identities, but will not see > the actual trafic protected by PPK. And libreswan added a method where you can migrate from "no PPK" to "PPK" by sending two AUTH payloads in the IKE_AUTH. The other end can then pick which they want to use. Perhaps with PAKE's, it too could send another AUTH payload in a notify so it does not have to be sent in IKE_SA_INIT, yet does not incur another round trip if both parties support the same PAKE. Paul From nobody Fri Aug 30 08:35:50 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B055D120AB8 for ; Fri, 30 Aug 2019 08:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 L4QPHC-U_s4O for ; Fri, 30 Aug 2019 08:35:46 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 E0E02120AB0 for ; Fri, 30 Aug 2019 08:35:46 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0PX2008DU3BM8Y@wwwlocal.goatley.com> for ipsec@ietf.org; Fri, 30 Aug 2019 10:35:46 -0500 (CDT) Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PX20047O3BJ39@trixy.bergandi.net> for ipsec@ietf.org; Fri, 30 Aug 2019 08:35:43 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Fri, 30 Aug 2019 08:35:43 -0700 Date: Fri, 30 Aug 2019 08:35:45 -0700 From: Dan Harkins In-reply-to: <23912.60438.716153.761077@fireball.acr.fi> To: Tero Kivinen Cc: ipsec@ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local) References: <7538495e-258d-1927-cbba-eb783675c83f@lounge.org> <23912.27054.796487.391930@fireball.acr.fi> <58d82a8c-d789-17ee-12b0-f935d7d2037e@lounge.org> <23912.60438.716153.761077@fireball.acr.fi> X-PMAS-Software: PreciseMail V3.3 [190828c] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 15:35:49 -0000 On 8/30/19 2:27 AM, Tero Kivinen wrote: > Dan Harkins writes: >>> How does the responder know which of the one million username password >>> pairs to pick to generate the generator when calculating D-H in the >>> IKE_SA_INIT? The actual identity of the user is only sent in the >>> encrypted IKE_AUTH message. >>> >>> I.e., I think this has exactly same problem than IKEv1 has with >>> pre-shared keys for main mode. You must know the initiator identity >>> based on the IP-addresses, thus makes this completely unusable for >>> non static VPN cases. >>   HA! I did miss something :-) >> >>   Yes, I guess a new payload is needed to express the username. This can >> be added to the IKE_SA_INIT message. Or maybe it can be a special type of >> NOTIFY, that's a six-of-one-and-a-half-dozen-of-the-other issue. But this >> should not involve an extra Auth exchange (as the framework PAKEs do) >> since SPEKE is just a Diffie-Hellman exchange which is exactly what IKE >> is. > We had similar discussion in the postquantum preshared keys case, > i.e., we needed to know the identity of the other end to pick the PPK, > but the identity is only transmitted in the IKE_AUTH, and IKE_AUTH is > encrypted with the key which is generated in IKE_SA_INIT. We solved > this issue in qr-ikev2 by making so that encryption of the IKE_AUTH > does not need the PPK, but uses only normal Diffie-Hellman and PPK is > only added to the actual IPsec trafic keys. > > The problem is that if we add the identity to the IKE_SA_INIT, then we > loose the identity protection part of the IKEv2, as we then cannot > encrypt the identity.   Sure we can. We could do the thing that was done in TLS-pwd. When the client registers his username and password she gets a static DH public key of the server (TLS-pwd made this be a p256 curve for its compact representation and adequate strength for the purpose of identity protection). The scheme then is if the client wants to protect its identity it uses the server's DH public key and does a static-ephemeral exchange, gets a secret, encrypts its identity and sends its ephemeral DH key (in compact representation, it's 33 octets) plus the encrypted identity in one "identity payload". If it doesn't care about identity protection it just sends its identity. > Current solutions have been trying to keep the identity protection > part as good as it is without those extensions, i.e., qr-ikev2 still > provides same identity protection than what normal IKEv2 does, and > then provides extended protection for the actual trafic keys. Attacker > who can break Diffie-Hellman can see the identities, but will not see > the actual trafic protected by PPK. > > With PAKEs, I think it is important to do the same, i.e., keep the > identity protection parts of the IKEv2 at least as good as they are > now, and that usually needs we need to do normal IKEv2 Diffie-Hellman > first to protect identities, and then inside that when we know > identities do the actual authentication using PAKE. > > Hybrid qske does things bit differently as it adds IKE_INTERMEDIATE > exchanges between IKE_SA_INIT and IKE_AUTH but all of those > IKE_INTERMEDIATE exchanges are anonymous, i.e., the identity of the > other end is not yet known, the authentication is done in the end with > IKE_AUTH, and only then the identity of the other end is known, and we > can use per user information like shared keys or password etc. Yes, we can do a PAKE exchange after IKE_SA_INIT and use that to do identity protection. It just does add another round trip and I was trying to point out how we can get a PAKE mode of IKE without any additional round trips or things like that. SPEKE is just a Diffie-Hellman and IKE already does a Diffie-Hellman. With the identity protection scheme I described above we're doing a 2nd Diffie-Hellman so work-wise it's a wash but from a protocol standpoint I think it's cleaner. The qr-ikev2 stuff is done that way but that's because we want to augment the qr exchange with a traditional D-H. That's the design. There is no reason to force PAKEs to do the same thing, which isn't to say we can't just that we don't have to.   regards,   Dan. From nobody Fri Aug 30 09:16:54 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4A41208C8 for ; Fri, 30 Aug 2019 09:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 gCiEu414OoRZ for ; Fri, 30 Aug 2019 09:16:53 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 040AE12001E for ; Fri, 30 Aug 2019 09:16:53 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46Kl3j4MMqzFd8; Fri, 30 Aug 2019 18:16:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1567181809; bh=jmp7P+Yzy/mOT8yYzGWbwR6MCJ7wHZFyxK3lrwc3FMw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=TuWCNFJOUbjb3vq5SgC9HoRc6WSWR6+SYEhQgMtwSH+DcgcWVUsvV3oL8Rnco0p+6 w2NU/f76FG4zPVeH3UMTBq6+kAddVlb6zurVcZgY+JMDpqFkXo4oMpwyZg21W+Y4xx vII+P6EWv65nb/Ms1ei4RePsp15JQQA6TfSRBDcY= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ccAcgGK2fBSc; Fri, 30 Aug 2019 18:16:48 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 30 Aug 2019 18:16:47 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 42C9B322DE3; Fri, 30 Aug 2019 12:16:46 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 42C9B322DE3 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3684E401AFAF; Fri, 30 Aug 2019 12:16:46 -0400 (EDT) Date: Fri, 30 Aug 2019 12:16:46 -0400 (EDT) From: Paul Wouters To: Dan Harkins cc: Tero Kivinen , ipsec@ietf.org In-Reply-To: Message-ID: References: <7538495e-258d-1927-cbba-eb783675c83f@lounge.org> <23912.27054.796487.391930@fireball.acr.fi> <58d82a8c-d789-17ee-12b0-f935d7d2037e@lounge.org> <23912.60438.716153.761077@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 16:16:54 -0000 On Fri, 30 Aug 2019, Dan Harkins wrote: >   Sure we can. We could do the thing that was done in TLS-pwd. When the > client registers his username and password she gets a static DH public > key of the server (TLS-pwd made this be a p256 curve for its compact > representation and adequate strength for the purpose of identity > protection). The scheme then is if the client wants to protect its > identity it uses the server's DH public key and does a static-ephemeral > exchange, gets a secret, encrypts its identity and sends its ephemeral > DH key (in compact representation, it's 33 octets) plus the encrypted > identity in one "identity payload". If it doesn't care about identity > protection it just sends its identity. EAPTLS already uses like 8 round trips. So anything that has PAKE using less than 8 seems like a win already :P So I am fine adding a few roundtrips for whatever PAKE we come up with if that avoids all of this extra complexity. Especially if this complexity is something that is added to the client provisioning. Remember this PAKE stuff is meant for those scenarios where we have an enduser with _only_ a username/password. If this requires installing additional client configuration, those clients might as well go to X.509/EAPTLS or even something weird like PSK/EAPTLS, or an EAP method supporting OTPs. Administrators doing site-to-site VPNs are better of using a true random strong PSK instead of a weaker PAKE. Paul From nobody Fri Aug 30 09:48:21 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C3812098D for ; Fri, 30 Aug 2019 09:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 jGtNIZawWVD6 for ; Fri, 30 Aug 2019 09:48:17 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 A44AE12093E for ; Fri, 30 Aug 2019 09:48:17 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0PX2007FZ6OGD8@wwwlocal.goatley.com> for ipsec@ietf.org; Fri, 30 Aug 2019 11:48:17 -0500 (CDT) Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PX200NA56ODJV@trixy.bergandi.net> for ipsec@ietf.org; Fri, 30 Aug 2019 09:48:13 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Fri, 30 Aug 2019 09:48:13 -0700 Date: Fri, 30 Aug 2019 09:48:14 -0700 From: Dan Harkins In-reply-to: To: Paul Wouters Cc: Tero Kivinen , ipsec@ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local) References: <7538495e-258d-1927-cbba-eb783675c83f@lounge.org> <23912.27054.796487.391930@fireball.acr.fi> <58d82a8c-d789-17ee-12b0-f935d7d2037e@lounge.org> <23912.60438.716153.761077@fireball.acr.fi> X-PMAS-Software: PreciseMail V3.3 [190828c] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 16:48:20 -0000 On 8/30/19 9:16 AM, Paul Wouters wrote: > On Fri, 30 Aug 2019, Dan Harkins wrote: > >>   Sure we can. We could do the thing that was done in TLS-pwd. When the >> client registers his username and password she gets a static DH public >> key of the server (TLS-pwd made this be a p256 curve for its compact >> representation and adequate strength for the purpose of identity >> protection). The scheme then is if the client wants to protect its >> identity it uses the server's DH public key and does a static-ephemeral >> exchange, gets a secret, encrypts its identity and sends its ephemeral >> DH key (in compact representation, it's 33 octets) plus the encrypted >> identity in one "identity payload". If it doesn't care about identity >> protection it just sends its identity. > > EAPTLS already uses like 8 round trips. So anything that has PAKE using > less than 8 seems like a win already :P So I am fine adding a few > roundtrips for whatever PAKE we come up with if that avoids all of this > extra complexity. Especially if this complexity is something that is > added > to the client provisioning. > > Remember this PAKE stuff is meant for those scenarios where we have an > enduser with _only_ a username/password. If this requires installing > additional client configuration, those clients might as well go to > X.509/EAPTLS or even something weird like PSK/EAPTLS, or an EAP method > supporting OTPs.   Doing EAPTLS seems pointless. If your "additional client configuration" involved a new trust anchor and an EST exchange and an X.509 certificate then why not just use IKE?   EAP is an abomination. It includes an identity request/response roundtrip that generates an identity that the EAP RFC says is unsuitable for any authentication purpose. Imagine that, an "authentication" protocol that wastes a roundtrip getting a useless identity and then punts off the job of getting a usable identity to another authentication protocol that has to wrap itself in an EAP encapsulation. Putting EAP into IKE was a bad idea and it seems doubly bad to put a PAKE (or PSK or OTP) into EAP inside IKE. > Administrators doing site-to-site VPNs are better of using a true random > strong PSK instead of a weaker PAKE.   Well how many administrators generate a nice string of 256-bits of "true random strong PSK"? Seriously, if administrators followed such advice then we would not continually adding another "die" on the "die die die IKEv1" routine we seem to do every 9 months. How many "dies" are we up to now?   Management of such "true random strong PSKs" is a pain which is why administrators use PSKs that are shorter, easier to remember, and easier to enter with a high probability of being correct. So a PAKE is just a robust solution for administrators that will do what we know they're gonna do anyway. They're not weak.   For a site-to-site VPN something like "identity protection" might not be that big of a deal so there need not be any client provisioning. A simple phone call between the 2 parties could suffice. If identity protection is needed, then there's a provisioning step or we do an additional roundtrip.   regards,   Dan. From nobody Fri Aug 30 10:51:19 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8BD120944 for ; Fri, 30 Aug 2019 10:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 2xpaFE34zn9q for ; Fri, 30 Aug 2019 10:51:14 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 7C6271200F6 for ; Fri, 30 Aug 2019 10:51:14 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46Kn8c5ZXNzFfy; Fri, 30 Aug 2019 19:51:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1567187472; bh=CcNByTbftGALBGhuaIsRFdJ+bEfh9A1JteWJLARvvjw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=eT20EeuZGmeHf+7rRfp9myvHCAdRWAonc2rkO4VytrMaJfPRCBdA61KRRXGgJuMOr 465pckOAhPypTeB1YDK0RypwVeZ69+Tkz6361+ICrvVuOPz/Xtk0A58amCu10tbc6k hL88ynnPXh5pFbJ+HeWhUSTmDCXTNP/9dzeVGPkQ= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id K-sT7urLKEnZ; Fri, 30 Aug 2019 19:51:11 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 30 Aug 2019 19:51:11 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 14C1D322DE3; Fri, 30 Aug 2019 13:51:10 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 14C1D322DE3 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0D46B401AFAF; Fri, 30 Aug 2019 13:51:10 -0400 (EDT) Date: Fri, 30 Aug 2019 13:51:10 -0400 (EDT) From: Paul Wouters To: Dan Harkins cc: ipsec@ietf.org, Tero Kivinen In-Reply-To: Message-ID: References: <7538495e-258d-1927-cbba-eb783675c83f@lounge.org> <23912.27054.796487.391930@fireball.acr.fi> <58d82a8c-d789-17ee-12b0-f935d7d2037e@lounge.org> <23912.60438.716153.761077@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 17:51:17 -0000 On Fri, 30 Aug 2019, Dan Harkins wrote: >   Doing EAPTLS seems pointless. If your "additional client configuration" > involved a new trust anchor and an EST exchange and an X.509 certificate > then why not just use IKE? Because "just use IKE" with Machine Certificates on Windows requires Administrator priviledge, while using the exact same certificates for EAPTLS only requires the user priviledges. Is that worth 8 roundtrips? Our opinion does not matter, but Microsoft thinks it does :( >   EAP is an abomination. I'll drink to that! >> Administrators doing site-to-site VPNs are better of using a true random >> strong PSK instead of a weaker PAKE. > >   Well how many administrators generate a nice string of 256-bits of "true > random strong PSK"? Seriously, if administrators followed such advice then > we would not continually adding another "die" on the "die die die IKEv1" > routine we seem to do every 9 months. How many "dies" are we up to now? I did not add killing PSKs to that draft, precisely because some objected because strong PSK's are stronger than PAKEs. >   Management of such "true random strong PSKs" is a pain which is why > administrators use PSKs that are shorter, easier to remember, and easier to > enter with a high probability of being correct. So a PAKE is just a robust > solution for administrators that will do what we know they're gonna do > anyway. Fair enough. Although people configuring Cisco's will use PSK for the next 20 years even if we got an RFC tomorrow. I still regularly see modp1024 flying by - in fact more so now because libreswan stopped supporting it so people upgrading are finally finding out they have a 15+ year old weak configuration. >   For a site-to-site VPN something like "identity protection" might not be > that big of a deal so there need not be any client provisioning. A simple > phone call between the 2 parties could suffice. If identity protection is > needed, then there's a provisioning step or we do an additional roundtrip. True as well, Paul From nobody Fri Aug 30 13:02:07 2019 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C235120922 for ; Fri, 30 Aug 2019 13:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 BSjFLhURrw3b for ; Fri, 30 Aug 2019 13:02:02 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 86AB4120879 for ; Fri, 30 Aug 2019 13:02:02 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0PX2006KVFNCTX@wwwlocal.goatley.com> for ipsec@ietf.org; Fri, 30 Aug 2019 15:02:00 -0500 (CDT) Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PX2004BTFN839@trixy.bergandi.net> for ipsec@ietf.org; Fri, 30 Aug 2019 13:01:57 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Fri, 30 Aug 2019 13:01:57 -0700 Date: Fri, 30 Aug 2019 13:01:58 -0700 From: Dan Harkins In-reply-to: To: Paul Wouters Cc: ipsec@ietf.org, Tero Kivinen Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local) References: <7538495e-258d-1927-cbba-eb783675c83f@lounge.org> <23912.27054.796487.391930@fireball.acr.fi> <58d82a8c-d789-17ee-12b0-f935d7d2037e@lounge.org> <23912.60438.716153.761077@fireball.acr.fi> X-PMAS-Software: PreciseMail V3.3 [190830] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 20:02:05 -0000 On 8/30/19 10:51 AM, Paul Wouters wrote: > On Fri, 30 Aug 2019, Dan Harkins wrote: > >>>  Administrators doing site-to-site VPNs are better of using a true >>> random >>>  strong PSK instead of a weaker PAKE. >> >>   Well how many administrators generate a nice string of 256-bits of >> "true >> random strong PSK"? Seriously, if administrators followed such advice >> then >> we would not continually adding another "die" on the "die die die IKEv1" >> routine we seem to do every 9 months. How many "dies" are we up to now? > > I did not add killing PSKs to that draft, precisely because some > objected because strong PSK's are stronger than PAKEs.   Strong PSKs are not stronger than PAKEs. A PAKE will offer you the added protection of resistance to dictionary attack against the symmetric credential (which could, in fact, be a PSK).   The definition of dictionary attack is one in which the adversary gains an advantage through computation and not interaction. So even with a strong PSK you are still susceptible to a dictionary attack since it is the protocol that is susceptible to attack and not the credential. With a strong PSK it just makes the dictionary attack use much more time to be successful (and yes the "true random strong PSK" that's 256 bits could make the attack computationally infeasible but then managing such a credential is similarly infeasible).   Think of it this way, if your strong PSK has 64 bits of good randomness it will take around 2^32 offline computations after A SINGLE ACTIVE ATTACK to get a probability of 0.5 of success while if you used that same thing with a PAKE it would take around 2^32 ACTIVE ATTACKS to get a probability of 0.5.   What a PAKE allows you to do is retain security even in the presence of a not-so strong PSK. It does not mean the PAKE is weak. We should not be standardizing a weak PAKE and I don't think any of the candidates that CFRG is considering are weak.   If you can manage a "strong PSK" then using it with a PAKE makes it stronger. If you can't manage a "strong PSK" then a PAKE still increases security. There's really no reason to use a PSK exchange susceptible to dictionary attack when something like SPEKE is available.   regards,   Dan.