From nobody Tue Jul 1 09:11:18 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7621B282A; Tue, 1 Jul 2014 09:11:13 -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] autolearn=ham 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 d1z8FS-UsIDM; Tue, 1 Jul 2014 09:11:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9F01A052E; Tue, 1 Jul 2014 09:11:12 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140701161112.18036.94027.idtracker@ietfa.amsl.com> Date: Tue, 01 Jul 2014 09:11:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Y1oRCzy58X30Y5pGLcio-3UZhFQ Cc: ipsec@ietf.org Subject: [IPsec] Last Call: (Signature Authentication in IKEv2) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 16:11:14 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Signature Authentication in IKEv2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-07-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by the PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism, and is not limited to ECDSA, but can also be used with other signature algorithms. The file can be obtained via http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth/ballot/ No IPR declarations have been submitted directly on this I-D. This draft updates RFC5996, however RFC5996 is in process of being updated in RFC5996-bis and will likely be published before this draft. Each mention of RFC5996 should be replaced with the new RFC number for RFC5996-bis once a number has been assigned. From nobody Wed Jul 2 09:05:15 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECF31A059F; Wed, 2 Jul 2014 09:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 EDggNloUXCV3; Wed, 2 Jul 2014 09:05:09 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8BC1A032C; Wed, 2 Jul 2014 09:05:08 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so9895408wib.12 for ; Wed, 02 Jul 2014 09:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=h0QFYUWDI7K6bADr2eTqyI6zgnSR78LqYaSZqPOt12Y=; b=fpAP8aG+MITYP/Wo+N5LFA0+RW1+2IUts2lznWesG3p9V11md/ysO1YQdQK93n87nd RgGJXFGbs6a3E+JgfyRqB9FbE4FPOjO3a1ms6kiD8dso+JPdEVY5H7hJlNbxSq1ibS6H ggCDOFPns4of+aQXi4PPwNlOkwnVhsc5fXf9OO0eYlTCRl91qThRrejCrHMm8gaqYzK5 8ziLR6HjRUAF2VUWyJVqYpE7jqvU+R7f7K4epzRmNsDZeXifyB2hdEOVae0kF+VprhXE zFO/Bi4ejRMsZETZv7U2vSQalLJhmroR+nTw5QSvRoYkRARFahll4Z+J9ZHhs0HbMYR4 XVMg== MIME-Version: 1.0 X-Received: by 10.180.90.233 with SMTP id bz9mr5229895wib.42.1404317104496; Wed, 02 Jul 2014 09:05:04 -0700 (PDT) Received: by 10.194.51.131 with HTTP; Wed, 2 Jul 2014 09:05:04 -0700 (PDT) Date: Wed, 2 Jul 2014 18:05:04 +0200 Message-ID: From: Daniel Migault To: lwip@ietf.org Content-Type: multipart/alternative; boundary=f46d043be2722a687f04fd380e51 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/QdnFfeikSCBnrP9CKjxyGeov0-8 Cc: "ipsec@ietf.org" Subject: [IPsec] draft-mglt-lwig-minimal-esp-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 16:05:11 -0000 --f46d043be2722a687f04fd380e51 Content-Type: text/plain; charset=UTF-8 Hi, Please fin the new version of our Minimal ESP . [1] We considered the remarks addressed during the lwig and ipsecme presentation: - Document of to use time for the Sequence Number - Anti-replay MUST be activated by senders even though it knows the receiver does not use anti replay protection. - clarification / rewording - Padding section Feel free to make comments! [1] http://www.ietf.org/internet-drafts/draft-mglt-lwig-minimal-esp-01.txt BR Daniel -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --f46d043be2722a687f04fd380e51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please fin the new ve= rsion of our Minimal ESP.=C2=A0 [1]

We considered the remarks a= ddressed during the lwig and ipsecme presentation:
=C2=A0=C2=A0=C2=A0 - Document of to use time for the Sequence Number<= br>
=C2=A0=C2=A0=C2=A0 - Anti-replay MUST be activated by senders even= though it knows the receiver does not use anti replay protection.
=C2=A0 =C2=A0 - clarification / rewording=C2=A0
=C2=A0=C2=A0=C2=A0 - Padding section
=

Feel free to make comments!


[1] <= a class=3D"" href=3D"http://www.ietf.org/internet-drafts/draft-mglt-lwig-mi= nimal-esp-01.txt">http://www.ietf.org/internet-drafts/draft-mglt-lwig-minim= al-esp-01.txt
BR
Daniel

--
Daniel Migault
Ora= nge Labs -- Security
+33 6 70 72 69 58
--f46d043be2722a687f04fd380e51-- From nobody Fri Jul 4 07:29:32 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D08B1B2CF1 for ; Fri, 4 Jul 2014 07:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 zT0cQX-cGAa1 for ; Fri, 4 Jul 2014 07:29:27 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E791B2D34 for ; Fri, 4 Jul 2014 07:29:26 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 4A6891A0091 for ; Fri, 4 Jul 2014 16:29:23 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RJLS0vWaddyU for ; Fri, 4 Jul 2014 16:29:18 +0200 (CEST) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id E71631A008F for ; Fri, 4 Jul 2014 16:29:18 +0200 (CEST) Received: from [10.53.40.204] (port=13919 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1X34UK-0002Hv-23 for ; Fri, 04 Jul 2014 16:29:20 +0200 Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 4 Jul 2014 16:29:19 +0200 Message-ID: <53B6BA3F.40509@secunet.com> Date: Fri, 4 Jul 2014 16:29:19 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: References: <20140701161112.18036.94027.idtracker@ietfa.amsl.com> In-Reply-To: <20140701161112.18036.94027.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.208.1.76] Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Pa-qjcrJR8YHGUqtsXWbS7_hBiU Subject: Re: [IPsec] Last Call: (Signature Authentication in IKEv2) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 14:29:30 -0000 Nice work, the wording is really improved. However, I still have two comments: 1. The wording in A.4 is confusing. With RSASSA-PSS, the algorithm object identifier is always id-RSASSA- PSS, but the hash function is taken from the optional parameters, and is required. It is not the hash function or the optional parameters that are required but the OID id-RSASSA-PSS. Secondly, the "but" in the second part of the sentence indicates some contrast but I don't see one. Furthermore, not only the hash function is determined from the parameters but also the other options for the padding. Why not changing the text to With RSASSA-PSS, the algorithm object identifier must always be id-RSASSA-PSS, and the hash function and padding parameters are conveyed in the optional parameters. 2. The wording in A.4.1 is also not unambiguous: Parameters are empty, but the ASN.1 part of the sequence must be there. This means default parameters are used (same as the next example). Here "next example" does not refer to the example following immediately after this paragraph but to the example in the next section. A reference to A.4.2 should be included. -- Johannes The IESG wrote on 01.07.2014 18:11: > > The IESG has received a request from the IP Security Maintenance and > Extensions WG (ipsecme) to consider the following document: > - 'Signature Authentication in IKEv2' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-07-15. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > The Internet Key Exchange Version 2 (IKEv2) protocol has limited > support for the Elliptic Curve Digital Signature Algorithm (ECDSA). > The current version only includes support for three Elliptic Curve > groups, and there is a fixed hash algorithm tied to each group. This > document generalizes IKEv2 signature support to allow any signature > method supported by the PKIX and also adds signature hash algorithm > negotiation. This is a generic mechanism, and is not limited to > ECDSA, but can also be used with other signature algorithms. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > This draft updates RFC5996, however RFC5996 is in process of being updated in RFC5996-bis and will likely be published before this draft. Each mention of RFC5996 should be replaced with the new RFC number for RFC5996-bis once a number has been assigned. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > -- Mit freundlichen Gren, Dr. Johannes Merkle Principal Beratung, Elektronische Identitten Public Sector secunet Security Networks AG Mergenthaler Allee 77 65760 Eschborn Germany Telefon +49 201 54 54-3091 Telefax +49 201 54 54-1325 Mobil +49 175 2224439 johannes.merkle@secunet.com www.secunet.com From nobody Fri Jul 4 13:16:21 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09CA1B2F4C; Fri, 4 Jul 2014 13:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 hj8AH9CY-BCm; Fri, 4 Jul 2014 13:16:16 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2401B2F4A; Fri, 4 Jul 2014 13:16:16 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id n15so13484480wiw.10 for ; Fri, 04 Jul 2014 13:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GenD7SMxAY7EtlDAzopeWOe63KC+445mVtlXIqjuucI=; b=AeMfc6V44rIsJ0t57fJTVoz3AAfImtJ0XghGcXvaRdI1LuDrE2D8+B2WYp936wWeAB ljsrMFs87cE4k7EFl++t9ryrIRIdtGP2fB2tNZrePejPkUWfewJFi/TbVDtWzIdVyZ2Y 1bxwH3pGWSyecO40cfKoYExF3Q05gnc43e6Pqyzi3mAAth8qjBuv/rG3/duUh8iPbzIc 5tGusNlXkQWbuGbxR9GViQdcwrDsr6GoEqsvszycM/AhZ7ZzFpvLuswh44rmr9E//HXz nZKZD53u97PelynqC2r5dcSME8cIKm147adwTCfQp2EHGjkq0j2yc4MGIsByDkXF5h7Y hXSw== MIME-Version: 1.0 X-Received: by 10.180.106.66 with SMTP id gs2mr20512644wib.5.1404504975014; Fri, 04 Jul 2014 13:16:15 -0700 (PDT) Received: by 10.194.51.131 with HTTP; Fri, 4 Jul 2014 13:16:14 -0700 (PDT) Date: Fri, 4 Jul 2014 22:16:14 +0200 Message-ID: From: Daniel Migault To: 6lo@ietf.org, "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=f46d04451a0d1f011904fd63cca8 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-PekVpGuwZENXjqOXSKbZp_i5ZM Subject: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 20:16:18 -0000 --f46d04451a0d1f011904fd63cca8 Content-Type: text/plain; charset=UTF-8 Hi, Here are the drafts we wrote on Diet-ESP which designs ESP for constrain environment. [1] draft-mglt-ipsecme-diet-esp-requirements-00.txt provides the requirements we considered for the design of Diet-ESP [2] draft-mglt-ipsecme-diet-esp-01.txt describes Diet-ESP. According to feed backs we received during the last presentation. Diet-ESP does not modify ESP. Instead, we consider compression / decompression of the payload sent on the wire. [3] draft-mglt-ipsecme-diet-esp-iv-generation-00.txt describes a way to compress th IV field in ESP encrypted payloads. [4] draft-mglt-ipsecme-diet-esp-payload-compression-00.txt describes how IPsec parameters negotiated with IKEv2 can be used to compress the clear text payload. More specifically, it is expected to compress up to the transport layer of the encrypted packet. Feel free to make comments! We have specific question regardin the IV compression. The general idea is that a speudo random function is used on bth side to generate the IV. This makes possible to send only some LSB. - 1) The pseudo random function uses as input the encryption key an dthe authentication key. I do not see major security flaws, but it may be better if a dedicated K could be used. Any ideas? - 2) By default we use PRF_AES128_XCBC. Another way would consist in chosing the PRF based on the ICV function. When NULL authentication is used the IV would not be compressed. Any opinion on that too? [1] http://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp-requirements/ [2] http://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/ [3] http://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp-iv-generation/ [4] http://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp-payload-compression/ -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --f46d04451a0d1f011904fd63cca8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Here are the drafts we wr= ote on Diet-ESP which designs ESP for constrain environment.

[1] draft-mglt-ipsecme-diet-esp-requirements-00.txt provides t=
he requirements we considered for the design of Diet-ESP

[2=
] draft-mglt-ipsecme-diet-esp-01.txt
describes Diet-ESP. According to feed backs we received during the last pre=
sentation. Diet-ESP does not modify ESP. Instead, we consider compression /=
 decompression of the payload sent on the wire. 
[3] draft-m=
glt-ipsecme-diet-esp-iv-generation-00.txt describes a way to compress t=
h IV field in ESP encrypted payloads.

[4] draft-mglt-ipsecme-diet-esp-payload-compression-00.tx=
t describes how IPsec parameters negotiated with IKEv2 can be used to c=
ompress the clear text payload. More specifically, it is expected to compre=
ss up to the transport layer of the encrypted packet.
Feel free to make comments!

We have specific question re= gardin the IV compression. The general idea is that a speudo random functio= n is used on bth side to generate the IV. This makes possible to send only = some LSB.
=C2=A0=C2=A0=C2=A0 - 1) The pseudo random function uses as input= the encryption key an dthe authentication key. I do not see major security= flaws, but it may be better if a dedicated K could be used. Any ideas?
=
=C2=A0=C2=A0=C2=A0 - 2) By default we use PRF_AES128_XCBC. Another way woul= d consist in chosing the PRF based on the ICV function. When NULL authentic= ation is used the IV would not be compressed. Any opinion on that too?
<= br>
--f46d04451a0d1f011904fd63cca8-- From nobody Tue Jul 8 12:12:55 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89911A0425 for ; Tue, 8 Jul 2014 12:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 sy66hN2hd8np for ; Tue, 8 Jul 2014 12:12:46 -0700 (PDT) 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 ietfa.amsl.com (Postfix) with ESMTPS id 39BD31A049C for ; Tue, 8 Jul 2014 12:12:46 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3E9F48008E for ; Tue, 8 Jul 2014 15:12:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1404846765; bh=pKW7u7j+CNf91AM1s2AFJtrpQ2Mzz0B5f+ZoScaRp0w=; h=Date:From:To:Subject; b=m0q5rl55OOmjKpC9o/dKxNqVTcr2YagGf6/xhpvmU44/FOy80+CyOggk/tBpuYyOs i+iobQSandmteaZKH7yKNzP814Ah2zhldIO5ILURkKT8bsF8viASV6v5PEs3lHUxE0 3wNHDJXK4bJ5qDoo7CaC9NdHKXm9DIsUaFB3iZRk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s68JCiHt022026 for ; Tue, 8 Jul 2014 15:12:44 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 8 Jul 2014 15:12:44 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/OBXKg6Hf25wYp3YppZDSerlKRww Subject: [IPsec] interoperability issue with modp transform mismatch for child sa X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 19:12:51 -0000 Hi, RFC 5996 states: Although ESP and AH do not directly include a Diffie-Hellman exchange, a Diffie-Hellman group MAY be negotiated for the Child SA. This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA exchange, providing perfect forward secrecy for the generated Child SA keys. software tends to configure the modp group as part of the phase2alg= or esp= option, inherited from IKEv1's strict separation. With IKEv2, we have a child sa negotiation in the initial exchange and one in the create_child_sa. For the initial exchange, you would never do a new DiffieHellman. But a configuration does not know whether it will be initiated via the initial exchange or via the create_child_sa. It can depend on which happens to be the first tunnel with the peer. I see an interop issue where a transform for a child sa is rejected in the initial exchange because of a mismatch in the modp transform. My questions: Should we accept an initial exchange child transform that does not specify a modp transform if we are configured to need one for the child sa? Should we leave out the modp group transform for the child sa in the initial exchange, if we are configured to need one for the child sa? Paul From nobody Wed Jul 9 04:15:10 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046DB1A03F2 for ; Wed, 9 Jul 2014 04:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 bU3G0AQrS-Aa for ; Wed, 9 Jul 2014 04:15:05 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B8A1A037F for ; Wed, 9 Jul 2014 04:15:04 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id s18so4846462lam.6 for ; Wed, 09 Jul 2014 04:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=ZJHeyT3SYGN1eOU4oy+ha5THEgGqTS2igo/zSpEEuq4=; b=VCm0pf+laBSBg39OkvzilNnFXOtWhIv0aJAYTJX1jZxLX307ZU2WRdPQHLDH5TjsnO AdK3up2BXMhZ1adBmIdChzZJ8Pan2DvABd6Ka1HzTYbjrz1YSpLU9mn5Re3SZAGcHmDs wFUD2rx8uoT1vp37yNrsXAAzLymGB5ibBEqhQRqMVhXJjhOu/5aIbWjYZMCbXkOETh9O FG/dy0yFugcBWxbu4UKjiVh6Nm9GSFc2kpmm6aDi2H7v4B41SsQa7rGOLp2bwC7f9EZs qK3d08hh5MmBsl56svml/huSC1qUCI5q1pHKRzuVtojseYMEQYNmuo6GLv/BzCG/Fa9r hLVQ== X-Received: by 10.152.179.165 with SMTP id dh5mr16256858lac.51.1404904503239; Wed, 09 Jul 2014 04:15:03 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id h12sm60288972lbo.8.2014.07.09.04.15.01 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 09 Jul 2014 04:15:02 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" , References: Date: Wed, 9 Jul 2014 15:14:43 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/TKgqLUTtu_CI10T9X7bKKz6WoIA Subject: Re: [IPsec] interoperability issue with modp transform mismatch forchild sa X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 11:15:08 -0000 Hi Paul, > RFC 5996 states: > > Although ESP and AH do not directly include a Diffie-Hellman > exchange, a Diffie-Hellman group MAY be negotiated for the Child SA. > This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA > exchange, providing perfect forward secrecy for the generated Child > SA keys. > > software tends to configure the modp group as part of the phase2alg= > or esp= option, inherited from IKEv1's strict separation. With IKEv2, > we have a child sa negotiation in the initial exchange and one in the > create_child_sa. For the initial exchange, you would never do a new > DiffieHellman. > > But a configuration does not know whether it will be initiated via > the initial exchange or via the create_child_sa. It can depend on > which happens to be the first tunnel with the peer. > > I see an interop issue where a transform for a child sa is rejected in > the initial exchange because of a mismatch in the modp transform. Our implementation requires that the list of DH groups for IKE and IPsec be the same in case of IKEv2. > My questions: > > Should we accept an initial exchange child transform that does not specify > a modp transform if we are configured to need one for the child sa? I think we should as it is a special case. But we must ensure that the group, negotiated in IKE_SA_INIT is also acceptable for the Child SA. > Should we leave out the modp group transform for the child sa in the > initial > exchange, if we are configured to need one for the child sa? Not only we should, we must leave it out. RFC5996, page 12: Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange cannot contain Transform Type 4 (Diffie-Hellman group) with any value other than NONE. Implementations SHOULD omit the whole transform substructure instead of sending value NONE. Again, it is a special case. And while proposing DH group for the IKE SA we must ensure that it is also acceptable for the child SA. Regards, Valery. > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Jul 10 04:00:13 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BDF1B2882 for ; Thu, 10 Jul 2014 04:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham 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 eBFssa1ru5a6 for ; Thu, 10 Jul 2014 03:59:53 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 663781B2881 for ; Thu, 10 Jul 2014 03:59:52 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s6AAxlgf015985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 Jul 2014 13:59:47 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s6AAxkO0016372; Thu, 10 Jul 2014 13:59:46 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21438.29218.632794.972426@fireball.kivinen.iki.fi> Date: Thu, 10 Jul 2014 13:59:46 +0300 From: Tero Kivinen To: Steve Baillargeon In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 13 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/kvW6M28ZdqLU7ob1LHr5cvaYJXc Cc: "ipsec@ietf.org" Subject: [IPsec] [ipsec] TS Negotiation and Static Route Install X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 11:00:01 -0000 Steve Baillargeon writes: > - in the section 2.9 on Traffic Selector Negotiation, I think it > will be good to have a few sentences about the relation (or lack of) > between traffic selector and static routing especially when dealing > with AH/ESP tunnel mode. As far as I know many implementers will > automatically add a static route after the traffic selectors are > negotiated. That will depend on the implementations and I do not think there is any need to add text about that in the IKEv2 document. There is no one universal way of doing that, especially when considering all different types of places where IPsec can be implemented (see section 3.3. of RFC4301). > - how should the initiator behaves if the responder did not return > valid TSi and TSr during Child SA establishment? For instance, the > responder has a "bug" and returns a TSr that is not within the > original requested TSr. Should the initiator sends an INFORMATIONAL > request with error notification TS_UNACCEPTABLE to the responder? The returned traffic selecters are supposed to be subset of the proposed traffic selectors, and if other end violated that rule, then initiator can do whatever it likes. It can consider this like any other fatal implementation error or an attack, i.e. tear down the IKEv2 SA, or it can send error notification to the other end. It cannot accept the wider traffic selector sent by the other end, as that would be violating his policy, and that would break the security of the device. If it is doing proper exit tunnel checks (like it should if it implements IPsec properly), then it might use its own original traffic selectors it proposed to the other end instead of the wider returned one, but that would cause some packets to be dropped silently, as the responder thinks he has wider SA than what the initiator has. I myself would suggest the first option, i.e. consider it as an attack agains the system, and tear down the IKEv2 SA immediately. -- kivinen@iki.fi From nobody Thu Jul 10 04:53:04 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A711B2897 for ; Thu, 10 Jul 2014 04:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham 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 ZzR0zByDRZNu for ; Thu, 10 Jul 2014 04:53:00 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 E243D1A03FF for ; Thu, 10 Jul 2014 04:52:59 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s6ABqsTq022622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 Jul 2014 14:52:54 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s6ABqsll021042; Thu, 10 Jul 2014 14:52:54 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21438.32406.355453.277991@fireball.kivinen.iki.fi> Date: Thu, 10 Jul 2014 14:52:54 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 32 min X-Total-Time: 37 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/GxqTk3GeSJpxuO8PVAfS0Q8wNo4 Cc: ipsec@ietf.org, Paul Wouters Subject: Re: [IPsec] interoperability issue with modp transform mismatch forchild sa X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 11:53:02 -0000 Valery Smyslov writes: > > I see an interop issue where a transform for a child sa is rejected in > > the initial exchange because of a mismatch in the modp transform. > > Our implementation requires that the list of DH groups for > IKE and IPsec be the same in case of IKEv2. Or you could remove rules set for the obsoleted IKEv1 protocol, and move the configuration to work on the IKEv2 terms. In that case you could define Diffie-Hellman groups for IKEv2 SA and another Diffie-Hellman groups for PFS (i.e. for later create child sa exchanges). > > My questions: > > > > Should we accept an initial exchange child transform that does not specify > > a modp transform if we are configured to need one for the child sa? > I think we should as it is a special case. But we must ensure that > the group, negotiated in IKE_SA_INIT is also acceptable for the > Child SA. In the IKE_SA_INIT we have SA payloads specifying the policy for the IKE SA and that include mandatory Diffie-Hellman group. This group protects the whole authentication and the IKE SA and also provides the upper bound for security of the Child SAs created using that IKE SA. If this group is too weak, then the attacker can break the IKE SA protection, thus it can modify the later CREATE_CHILD_SA exchanges at will, and act as man in the middle for them too, thus breaking whatever Diffie-Hellman is used later. Thus there is no point of having more secure Diffie-Hellman group in the CREATE_CHILD_SAs for PFS than what was used in the IKE SA creation. So if you want to check policy for the initial group and PFS group, just check the policy at the load time, and make sure the groups allowed in the IKE SA creation are stronger than the one used in the PFS. So in IKE_SA_INIT and IKE_AUTH there is exactly one group that is specified in the IKE_SA_INIT SA payload and that protects the whole IKE SA and the first Child SA. That group is by definition good enough for the first Child SA, as security of all future Child SAs are also limited to that one group. > > Should we leave out the modp group transform for the child sa in > > the initial exchange, if we are configured to need one for the > > child sa? > > Not only we should, we must leave it out. RFC5996, page 12: Yes. > Again, it is a special case. And while proposing DH group > for the IKE SA we must ensure that it is also acceptable > for the child SA. Not really, as the DH group used in the IKE SA is by definition the upper bound of the security for all Child SAs created inside it. Doing another PFS later does not add anything if the original Diffie-Hellman is already broken at that time and there is active attacker there. I.e if you use weak Diffie-Hellman group in the IKE SA and there is passive attacker who records the whole IKE SA exchange and starts breaking the Diffie-Hellman you did. After the attacker manages to break the Diffie-Hellman for the IKE SA it can now calculate the SKEYSEED, an from there it can calculate the SK_d, SK_a* etc. It can use the SK_a* and SK_e* and get in the middle of the IKE SA, thus it can take exchange from the IKE SA decrypt them, modify them, reencrypt and reauthenticate them and send them forward. This means that if you do CREATE_CHILD_SA with much stronger PFS group after attacker can act as man-in-the-middle, the attacker can get that CREATE_CHILD_SA request, replace the KE payload in there, send it forward and do the same in the CREATE_CHILD_SA response. Now you have new Child SA between the peers, but there is attacker in the middle of that SA too, even when you used so strong Diffie-Hellman that attacker could not break it. I.e the security of the IKE SA lies in the IKE SA Diffie-Hellman exchange. If that is broken everything is lost. You might even go so far that limit the security of the CREATE_CHILD_SA Diffie-Hellman groups to the security of the IKE SA DH Group. I.e. if the IKE SA used 1024-bit MODP group, there is no point of proposing 2048-bit MODP group for PFS. You might simply propose the same group you used in the IKE SA, as that is the security limit anyways. -- kivinen@iki.fi From nobody Thu Jul 10 23:21:59 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAD21B2799 for ; Thu, 10 Jul 2014 23:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=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 1ZbVMxd5X8Kx for ; Thu, 10 Jul 2014 23:21:57 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA471A8BB5 for ; Thu, 10 Jul 2014 23:21:56 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id mc6so469591lab.38 for ; Thu, 10 Jul 2014 23:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=L2D/naXXN9ZeFTGMd2jX1QTiahuKNsBSRZuTluBYVT4=; b=zuv2CyvPAYfrOKOObVglMVAgwj50iRmT/GC7oRFxGqWnyOZF2kGD26G+Jhh2GxSLDr aJ/vrJWuHZJcERWIGZPcb3adoZ+DinHydGY2PJs2Phz08gLzavPoEVZSSQ2AW14dyB7F hRwP5G06xTHOo94/YaxePtJjHpcg8UEWBGtr6vrCikY8OSJK9yrVX9cScYpqARxS6VnY M3bAdJQ9et4xTKpvdHE/8z9YQJ0W/7oTvBZ2IP/y1glM0NbJgplkDtzarTWo1gBMhn34 9AoucovJYZEulM9fsL00npZB/bKFUmM1bM7ycrzhBd16JZH3HGmQCpYhd0SwTgSd43Qo JroA== X-Received: by 10.112.88.202 with SMTP id bi10mr43113940lbb.4.1405059715355; Thu, 10 Jul 2014 23:21:55 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id uo5sm1987226lbb.6.2014.07.10.23.21.53 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 10 Jul 2014 23:21:54 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Yoav Nir" References: Date: Fri, 11 Jul 2014 10:21:43 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/mAiml__oMA5GQpmnG9idtXwbnv4 Cc: ipsec@ietf.org Subject: [IPsec] draft-nir-ipsecme-puzzles-00 comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 06:21:58 -0000 Hi Yoav, did you consider the following initial exchange: Initiator Responder ------------------------------------------------------------------- HDR(A,0), SAi1, KEi, Ni --> <-- HDR(A,0), N(COOKIE), N(PUZZLE) (supported initiator) HDR(A,0), N(SOLVED_PUZZLE), SAi1, KEi, Ni --> -- or -- (unsupported or unwilling initiator) HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> The idea is that responder sends both the COOKIE and the PUZZLE notifications (of course, the cookie for PUZZLE must be generated differently from the cookie for COOKIE, probably using different secret or different algorithm). In this case if the initiator doesn't support puzzles, it would ignore the PUZZLE notification as unknown status notification and return the COOKIE. On the other hand, if initiator supports puzzles, then it have a choice - whether to return COOKIE and have lower chance to establish SA or make some work and return SOLVED_PUZZLE (that is identical to COOKIE apart from the type of notification) and have a better chance. The responder in this case would give more priority to the SOLVED_PUZZLE requests and leave the remaining resources to the COOKIE and initial IKE_SA_INIT requests. I think this approach would: 1) increase interoperability 2) give more flexibility to initiator depending on the CPU resources it has 3) allows responder to separate solved puzzles from COOKIEs and to give them more priority Regards, Valery Smyslov. From nobody Sun Jul 13 11:43:49 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61FEC1A00C5 for ; Sun, 13 Jul 2014 11:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553] autolearn=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 cEXZwRia8bcc for ; Sun, 13 Jul 2014 11:43:46 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE491A00D1 for ; Sun, 13 Jul 2014 11:43:46 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s6DIgtEk035090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 13 Jul 2014 11:43:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <668F219B-0E5F-4C82-8EC1-39972AF83AF8@vpnc.org> Date: Sun, 13 Jul 2014 11:43:43 -0700 To: IPsec ME WG List Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/X3UJ4jv5HISBb4p94KNLOmvyQJg Subject: [IPsec] Agenda for Toronto meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 18:43:47 -0000 Now posted: http://www.ietf.org/proceedings/90/agenda/agenda-90-ipsecme --Paul Hoffman From nobody Tue Jul 15 00:24:03 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2D41B2824 for ; Tue, 15 Jul 2014 00:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.896 X-Spam-Level: ** X-Spam-Status: No, score=2.896 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, STOX_REPLY_TYPE_WITHOUT_QUOTES=1.757] autolearn=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 vKb8ih501l2A for ; Tue, 15 Jul 2014 00:23:57 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C15A1A031C for ; Tue, 15 Jul 2014 00:23:57 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id gl10so1612737lab.40 for ; Tue, 15 Jul 2014 00:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=FjjcSp5WLuPdkM+0pm/JCDDim5Wg7E51767xjayvABY=; b=YNdR6fdfl4GwmdaXD/0hUl80le3E21AWNP2HQPj7nbA2Q0g+mTTBuZGT4wWD35gh4r wrbgz3cg5OWaa/UYjCvZrfr/bj1FmYtbMZMEUmjxiYDa0eJlAe+YRzIfdhCNwO9oBhOF a/bhz9T5ODsEAz8gMwQRtDsvEieV8p5ZTvSFQiyK7nOWdBoQoOtPyrJaTuu2xqegaame ZNYLoSe1tqO3IAnwpvr5GR6hVe5l7yfaEjX1VQyz71PO8DS8ku4FDC491VFAYSWWga5+ Pcluatdej4b4IFSIKZdLVAENgdOOlL6tWUuV7E7jCYWpGoVeSPQPF1veNKeyRY2DSHne mjpg== X-Received: by 10.112.136.164 with SMTP id qb4mr5731388lbb.61.1405409035517; Tue, 15 Jul 2014 00:23:55 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id j13sm6505526lab.39.2014.07.15.00.23.53 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 15 Jul 2014 00:23:54 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Daniel Migault" References: Date: Tue, 15 Jul 2014 11:23:55 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/cRP2TjRaWEP0m8uD5RmSZ3QTQDs Cc: ipsec@ietf.org Subject: [IPsec] draft-mglt-ipsecme-diet-esp-iv-generation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 07:23:58 -0000 Hi, I have some comments regarding the draft. First, it is not absolutely clear from the draft how the IV is generated for each packet. I presume that the IVs are taken sequentially for every new ESP packet to send from the bit string generated by prf+. But then it is not clear for me how the receiver would regenerate the same IV in case of packets loss and reordering. Sending LSB of IV would help here a bit, but then receiver would do quite a lot of work to guess the right IV, the overall process is not deterministic and opens a possibility for simple DoS attack. The receiver would also look at the sequence number to deal with packets loss and reordering, but as far as I understnad the SN is optional in Diet-ESP. Then, I'm not a crypto expert, but using the same key for both encryption and IV generation looks like a bit unsound. Finally, I would prefer defining new transorms (for example AES-CBC with implicit IV) instead of negotiating IV compression separately. Regards, Valery Smyslov. From nobody Tue Jul 15 00:50:03 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905121B2834 for ; Tue, 15 Jul 2014 00:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 qFDvHyh4wQ4Q for ; Tue, 15 Jul 2014 00:49:57 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087361A0327 for ; Tue, 15 Jul 2014 00:49:56 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hi2so3796420wib.17 for ; Tue, 15 Jul 2014 00:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uOr4x2WHCXzyitUUkFyy28OcHCBIZJVCMaLJq5z45nQ=; b=oVXAT9cDHq3jYAKn6qQLcJzEYFTDvF/CoZ3Y/fIGbi3iLCuXNt0o+HDMAkQ3/HNdmC ToMYwPZfhIvj8eXSy3FmsUdKAYDQkYiBEYLK7v5mtJFXMUGmktqe5HjmTOnOJazxtF4Y 5hsSxunB+A3BZz5WF5Jdrpl+J5VnYPYtxRpG7o84kYN6n3v93qgnBVzgsRBDYIjWmtm+ +RkDVoUXGQbPNm8w5paufQEqWpWexO6CsVi6tL2uA0WYiIDBAfT87hkpe3uUhG57EoGq ObuSrZ1F2vMbIaJlZuoFzR3y4WZEjXrFGI3ERt9Bdzv4edtxR9Kc/vgfBbCCV174Mtlf 5FAA== MIME-Version: 1.0 X-Received: by 10.180.14.162 with SMTP id q2mr3598012wic.54.1405410595719; Tue, 15 Jul 2014 00:49:55 -0700 (PDT) Received: by 10.194.137.67 with HTTP; Tue, 15 Jul 2014 00:49:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Jul 2014 09:49:55 +0200 Message-ID: From: Daniel Migault To: Valery Smyslov Content-Type: multipart/alternative; boundary=f46d04138d31524efe04fe36a7ae Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/wZXVTWVqiU4TrRG-q9nbCfeRiZQ Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-mglt-ipsecme-diet-esp-iv-generation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 07:49:59 -0000 --f46d04138d31524efe04fe36a7ae Content-Type: text/plain; charset=UTF-8 Hi Valery and thank you for your feed backs. Instead of negotiating the IV compression in a separate way, Valery suggests to have a specific mode like AES-CBC_WITH_IV_COMPRESSION for example. To me its sounds better than what is being described in the draft. Please let us know what you think about this alternative, and which function would you use to generate the pseudo random IVs in each packets. See inline for more comments. BR, Daniel On Tue, Jul 15, 2014 at 9:23 AM, Valery Smyslov wrote: > Hi, > > I have some comments regarding the draft. > > First, it is not absolutely clear from the draft how the IV is generated > for each packet. I presume > that the IVs are taken sequentially for every new > ESP packet to send from the bit string generated > by prf+. But then it is not clear for me how the receiver > would regenerate the same IV in case of packets loss > and reordering. Sending LSB of IV would help here a bit, but then receiver > would do quite a lot of work to guess > the right IV, the overall process is not deterministic > and opens a possibility for simple DoS attack. > This is true, and we should have added more text on that. The initial idea is to rely on the Sequence Number, and their should be a deterministic way to bind SN and IV for bot peers. However you are right, to avoid simple DoS, there should also be a deterministic way to decompress the SN. > The receiver would also look at the sequence number to deal with packets > loss and reordering, but as far as I understnad the SN is optional in > Diet-ESP. > It depends what optional means. Diet-ESP packets MUST have a complete Sequence Number to enable anti-replay and to compute the ICV. On the other hand, Diet-ESP provides the option to send only the LSB of the SN on the wire. In order to avoid simple DoS attacks, the decompression of the SN should be "almost" deterministic. > Then, I'm not a crypto expert, but using the same > key for both encryption and IV generation looks > like a bit unsound. > This sounds bad to me too. Actually this is my main concern. > Finally, I would prefer defining new transorms > (for example AES-CBC with implicit IV) instead of negotiating IV > compression separately. > That is maybe the way to do. Thanks for your feed back. > > Regards, > Valery Smyslov. > > > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --f46d04138d31524efe04fe36a7ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Valery and thank you for your feed = backs.

Instead of negotiating the IV compression in a separate= way, Valery suggests to have a specific mode like AES-CBC_WITH_IV_COMPRESS= ION for example.

To me its sounds better than what is being described in the draft= .

Please let us know what you think about this alternative, and whi= ch function would you use to generate the pseudo random IVs in each packets= .

See inline for more comments.

BR,
Dan= iel


On Tue, Jul 15, 2014 at 9:23 AM, Valery Smyslov <sv= anru@gmail.com> wrote:
Hi,

I have some comments regarding the draft.

First, it is not absolutely clear from the draft how the IV is generated fo= r each packet. I presume
that the IVs are taken sequentially for every new
ESP packet to send from the bit string generated
by prf+. But then it is not clear for me how the receiver
would regenerate the same IV in case of packets loss
and reordering. Sending LSB of IV would help here a bit, but then receiver = would do quite a lot of work to guess
the right IV, the overall process is not deterministic
and opens a possibility for simple DoS attack.

Thi= s is true, and we should have added more text on that. The initial idea is = to rely on the Sequence Number, and their should be a deterministic way to = bind SN and IV for bot peers. However you are right, to avoid simple DoS, t= here should also be a deterministic way to decompress the SN.
=C2=A0=C2=A0
The receiver would also look at the sequence number to deal with packets lo= ss and reordering, but as far as I understnad the SN is optional in Diet-ES= P.

It depends what optional means. Diet-ESP packet= s MUST have a complete Sequence Number to enable anti-replay and to compute= the ICV. On the other hand, Diet-ESP provides the option to send only the = LSB of the SN on the wire. In order to avoid simple DoS attacks, the decomp= ression of the SN should be "almost" deterministic.
=C2=A0
Then, I'm not a crypto expert, but using the same
key for both encryption and IV generation looks
like a bit unsound.

This sounds bad to= me too. Actually this is my main concern.
=C2=A0
Finally, I would prefer defining new transorms
(for example AES-CBC with implicit IV) instead of negotiating IV compressio= n separately.

That is maybe the way to = do. Thanks for your feed back.

Regards,
Valery Smyslov.





--
Daniel Migault
Orang= e Labs -- Security
+33 6 70 72 69 58
--f46d04138d31524efe04fe36a7ae-- From nobody Tue Jul 15 01:13:59 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CB61B283C for ; Tue, 15 Jul 2014 01:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=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 pbu49UWO-vBS for ; Tue, 15 Jul 2014 01:13:56 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB0A1B2836 for ; Tue, 15 Jul 2014 01:13:56 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so243804wes.0 for ; Tue, 15 Jul 2014 01:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nU2q5GXQ3fOTKfJGJNZPOwAmpiZaqQIKv9ykde4u3OY=; b=r6NTPRNGZyOCt9rbf/JVfsbnBAjmDQOHfe4k6EtNP+izxlkomBSJQZkRKyrX0QJhKA FKrnhen4AjSiGUGGzZUn/wBKxrXwVpi9P10KxZJ/31FFq7EFCkdMMKShb9lr9qBtTQCa RTCV1T54OlkVw7sLch/sxoGBBdEs2tfs5lcgHnr8pGvMfshZDxxAeb0dr18zL26jXVXx 7Zf4KJ6xeI4VfRwH/2HnX7FJJsv5bfMIcEhJ4e01Mvf4TG6zgdhNW25M+OF1CfyGAMFS +BpkikgcFXk73WFGpu+r0ayxzeD2PYa6hHUbfBlWIM3sF9c8ykYHs1QXw1gEXvR9/1ua 26VA== X-Received: by 10.194.11.74 with SMTP id o10mr25648229wjb.82.1405412034628; Tue, 15 Jul 2014 01:13:54 -0700 (PDT) Received: from [172.24.251.205] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id m3sm40887436wik.7.2014.07.15.01.13.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 01:13:54 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Yoav Nir X-Priority: 3 In-Reply-To: Date: Tue, 15 Jul 2014 11:13:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Valery Smyslov X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Ik7zLqR5k-OCQWvQQUWNedFabpI Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-nir-ipsecme-puzzles-00 comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 08:13:57 -0000 I think doing this would cause clients to calculate the puzzle solution, = when in fact they don=92t have to, and sending back the COOKIE would be = enough. What I envision is for the IKE gateway to measure its load (probably = based on amount of half-open IKE SAs). As long as the load level is low, = the gateway sends neither COOKIE nor PUZZLE. If the load gets higher, = the gateway begins sending COOKIEs, and every implementation of RFC 5996 = works. If the load gets even higher (to the extent that it jeopardizes = the gateway=92s ability to provide its services), then it sends PUZZLEs = instead of COOKIEs, and initiators that don=92t support this = specification are left out. Yoav On Jul 11, 2014, at 9:21 AM, Valery Smyslov wrote: > Hi Yoav, >=20 > did you consider the following initial exchange: >=20 > Initiator Responder > ------------------------------------------------------------------- > HDR(A,0), SAi1, KEi, Ni --> > <-- HDR(A,0), N(COOKIE), N(PUZZLE) >=20 > (supported initiator) > HDR(A,0), N(SOLVED_PUZZLE), SAi1, > KEi, Ni --> >=20 > -- or -- >=20 > (unsupported or unwilling initiator) > HDR(A,0), N(COOKIE), SAi1, > KEi, Ni --> >=20 > The idea is that responder sends both the COOKIE and the PUZZLE = notifications (of course, the cookie for PUZZLE must be generated > differently from the cookie for COOKIE, probably using different = secret > or different algorithm). >=20 > In this case if the initiator doesn't support puzzles, it would > ignore the PUZZLE notification as unknown status notification > and return the COOKIE. On the other hand, if initiator supports > puzzles, then it have a choice - whether to return COOKIE > and have lower chance to establish SA or make some work > and return SOLVED_PUZZLE (that is identical to COOKIE apart from the = type of notification) and have a better chance. > The responder in this case would give more priority to the = SOLVED_PUZZLE requests and leave the remaining resources > to the COOKIE and initial IKE_SA_INIT requests. >=20 > I think this approach would: > 1) increase interoperability > 2) give more flexibility to initiator depending on > the CPU resources it has > 3) allows responder to separate solved puzzles from COOKIEs = and to give them more priority >=20 > Regards, > Valery Smyslov. >=20 From nobody Tue Jul 15 05:06:34 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B131B287A for ; Tue, 15 Jul 2014 05:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 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, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, TVD_FINGER_02=1.215] autolearn=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 V8gi_-UhIEmN for ; Tue, 15 Jul 2014 05:06:29 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FD41B286C for ; Tue, 15 Jul 2014 05:06:28 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id gf5so3878555lab.8 for ; Tue, 15 Jul 2014 05:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=GJkJKalmNCY3LQT+4rqlnXdNrGWHCCuPdAvh+4MxIB4=; b=Oom56JnLvoGhRCVfgUwPcnz1aNUTPwmfffIDEYdllw2yAjU1s2Inu5Tb3SXHM6hFP0 ubTniUDrxUUENXs7apMXAdmH/mdX6eVtiiai/gMNcHkJ50pz5masv8HshjLKIZvdOdYa ho/KArJ7ySPwYx0xzhtF00kRG84OQSEnR9u3l1uHpG5txbOys3ZkkBJtjzoyJyRYj1cy TXHI4qqSInBiEGRbchAjVIwGMYg3plQaX8jiwT3ShCDOf9WcxjkdFtGkTSHPtuP1Nv8z BcTh7RFv0nBWUGLsuSH3c/nPth/oMIAxny8mxALM9NRfkr7rGflkkPKQvaLl7cWuO/q8 sccw== X-Received: by 10.152.8.82 with SMTP id p18mr1780907laa.83.1405425987189; Tue, 15 Jul 2014 05:06:27 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id s15sm19899356lbp.42.2014.07.15.05.06.25 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 15 Jul 2014 05:06:26 -0700 (PDT) Message-ID: <738967C817344F3BAA4532973310DC52@buildpc> From: "Valery Smyslov" To: "Yoav Nir" References: Date: Tue, 15 Jul 2014 16:06:27 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Ghv8N5UzKUoJiDAnLVofcnULls0 Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-nir-ipsecme-puzzles-00 comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 12:06:30 -0000 > I think doing this would cause clients to calculate the puzzle solution, > when in fact they dont have to, and sending back the COOKIE would be > enough. > > What I envision is for the IKE gateway to measure its load (probably based > on amount of half-open IKE SAs). As long as the load level is low, the > gateway > sends neither COOKIE nor PUZZLE. If the load gets higher, the gateway > begins sending COOKIEs, and every implementation of RFC 5996 works. > If the load gets even higher (to the extent that it jeopardizes the > gateways > ability to provide its services), then it sends PUZZLEs instead of > COOKIEs, > and initiators that dont support this specification are left out. I understand the idea. I only suggest a small modification, that would make the overall process more flexible and interoperable. The modification is: instead of sending only PUZZLE in case of high load, the SG would send both COOKIE and PUZZLE, calculated with different secrets. Those initiators, that don't support puzzles, would ignore it and return COOKIE. The others would have a choice - whether to spend some CPU power, solve the puzzle and return it or just ignore puzzle and send COOKIE (as unsupported initiators). The SG would give more priority to requests containing SOLVED_PUZZLE than to requests containing COOKIE or initial IKE_SA_INIT. I can see the following benefits with this modification: 1. Old initiators that don't support puzzles would still have a chance to establish SA (although their chances will be lower comparing to initiators, supported puzzles) 2. Every single initiator supported puzzles will have a choice - try to solve puzzle or try to continue with COOKIE. This is important, as SG sets an equal level of difficulty for all initiators, but, as you have mentioned in the draft, CPU power may differ drastically between small mobile devices and high-end desktops. For the former it is sometimes easier to ignore puzzles and hope that resending COOKIE would eventually work. 3. SG would be able to separate requests with solved puzzles from those with just returned cookies and would give the former higher priority. I don't see any drawback with this modification, do you? Regards, Valery. > Yoav > > On Jul 11, 2014, at 9:21 AM, Valery Smyslov wrote: > > > Hi Yoav, > > > > did you consider the following initial exchange: > > > > Initiator Responder > > ------------------------------------------------------------------- > > HDR(A,0), SAi1, KEi, Ni --> > > <-- HDR(A,0), N(COOKIE), N(PUZZLE) > > > > (supported initiator) > > HDR(A,0), N(SOLVED_PUZZLE), SAi1, > > KEi, Ni --> > > > > -- or -- > > > > (unsupported or unwilling initiator) > > HDR(A,0), N(COOKIE), SAi1, > > KEi, Ni --> > > > > The idea is that responder sends both the COOKIE and the PUZZLE > > notifications (of course, the cookie for PUZZLE must be generated > > differently from the cookie for COOKIE, probably using different secret > > or different algorithm). > > > > In this case if the initiator doesn't support puzzles, it would > > ignore the PUZZLE notification as unknown status notification > > and return the COOKIE. On the other hand, if initiator supports > > puzzles, then it have a choice - whether to return COOKIE > > and have lower chance to establish SA or make some work > > and return SOLVED_PUZZLE (that is identical to COOKIE apart from the > > type of notification) and have a better chance. > > The responder in this case would give more priority to the SOLVED_PUZZLE > > requests and leave the remaining resources > > to the COOKIE and initial IKE_SA_INIT requests. > > > > I think this approach would: > > 1) increase interoperability > > 2) give more flexibility to initiator depending on > > the CPU resources it has > > 3) allows responder to separate solved puzzles from COOKIEs and > > to give them more priority > > > > Regards, > > Valery Smyslov. > > From nobody Sat Jul 19 09:48:20 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911FA1B28F7 for ; Sat, 19 Jul 2014 09:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 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, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=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 3CmHgVVFeNsJ for ; Sat, 19 Jul 2014 09:48:17 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A56D1A0167 for ; Sat, 19 Jul 2014 09:48:16 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q58so5927767wes.32 for ; Sat, 19 Jul 2014 09:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=xZLUc2w2pnz6G33mSQGGaLITyvDbzJA5ndiGoBfpnZQ=; b=eIBSrLImuDFKvZrhuZeCoUyDZuUA80bmqJ/TotIKTUak0e2XS8w9Z5SAe5beWttRyl NbGM3qvRhhnb4h+iZ7f/wsBijkquM5ZbhM2iKwRDPoyX2wYX7wM3DIt/6TtwJ7VF02JM yYqnAODnCZe22hyeknQ2WYpklG5nj2+MNeOGm0WyQzYp0j1KbcbREiN3FirKG6GCMEkw ZImbjPFh/F6i1JEKT23fpisUpsKWXukqiXCjSOcJ4EZNZq0nmX4ffTKMh0HGdk7vIVe2 Fp8S5JF6SfbDPa0E9TsuLpotZOCypXD+O2GNdxQETWp76AWzRb8/Se1LxVcXMzpAh/3+ NGSw== X-Received: by 10.180.10.166 with SMTP id j6mr12074338wib.73.1405788495321; Sat, 19 Jul 2014 09:48:15 -0700 (PDT) Received: from [10.0.0.1] ([109.67.0.77]) by mx.google.com with ESMTPSA id wi9sm23078362wjc.23.2014.07.19.09.48.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Jul 2014 09:48:14 -0700 (PDT) Message-ID: <53CAA14C.80301@gmail.com> Date: Sat, 19 Jul 2014 19:48:12 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: IPsecME WG Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/cHVti55YV4tR8JQfeK7LQxwLZpA Subject: [IPsec] Charter update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 16:48:18 -0000 IPsec folks,

Our existing charter (http://tools.ietf.org/wg/ipsecme/charters) is badly out of date. Below is a proposed charter revision. Please review and comment on the list. We might also discuss the new charter in the face-to-face next week.

Thanks,
    Paul and Yaron


IP Security Maintenance and Extensions (ipsecme)
------------------------------------------------

 Charter

 Current Status: Active

 Chairs:
     Paul E. Hoffman <paul.hoffman@vpnc.org>
     Yaron Sheffer <yaronf.ietf@gmail.com>

 Security Area Directors:
     Stephen Farrell <stephen.farrell@cs.tcd.ie>
     Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>

 Security Area Advisor:
     Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>

 Mailing Lists:
     General Discussion: ipsec@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/ipsec
     Archive:            http://www.ietf.org/mail-archive/web/ipsec/

Description of Working Group:

   The IPsec suite of protocols includes IKEv1 (RFC 2409
   and associated RFCs), IKEv2 (RFC 5996), and the IPsec
   security architecture (RFC 4301). IPsec is widely
   deployed in VPN gateways, VPN remote access clients,
   and as a substrate for host-to-host, host-to-network,
   and network-to-network security.
 
   The IPsec Maintenance and Extensions Working Group
   continues the work of the earlier IPsec Working Group
   which was concluded in 2005. Its purpose is to maintain
   the IPsec standard and to facilitate discussion of
   clarifications, improvements, and extensions to IPsec,
   mostly to IKEv2. The working group also serves as a
   focus point for other IETF Working Groups who use IPsec
   in their own protocols.
 
   The current work items include:
 
   Recently discovered incorrect behavior of ISPs poses a
   challenge to IKE, whose UDP messages (especially #3 and #4)
   sometimes get fragmented at the IP level and then dropped
   by these ISPs. There is interest in solving this issue by
   allowing transport of IKE over TCP; this is currently
   implemented by some vendors. The group will standardize such
   a solution.
 
   The WG will review and revise the list of mandatory-to-
   implement algorithms for ESP and AH based on five years of experience
   with newer algorithms and cryptographic modes.
 
   The WG will revise the IKEv2 specification with a small number
   of mandatory tests required for the secure operation of IKEv2
   when using elliptic curve cryptography. This work will be based
   on draft-sheffer-ipsecme-dh-checks.

   IKEv2 has had many interoperable implementations and can now be considered
   a mature protocol. The WG will republish the protocol as an Internet Standard.

   At the time of writing, all the above are in late stages of the IETF process.
   Therefore, the WG will go into low-power mode: it will remain active as a focal point
   for the IPsec community. But it will only take on new work items if a strong community
   interest can be seen.

   This charter will expire in July 2015 (12 months from approval).
   If the charter is not updated before that time, the WG will be
   closed and any remaining documents revert back to individual
   Internet-Drafts.
 

Goals and Milestones:

  Done - IETF Last Call on large scale VPN use cases and requirements
  Done - IETF last call on IKE fragmentation solution
  Done - IETF last call on new mandatory-to-implement algorithms

  [No current milestones]
From nobody Sat Jul 19 12:51:05 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DD11B2A0F for ; Sat, 19 Jul 2014 12:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 n9iBp7YEYzP1 for ; Sat, 19 Jul 2014 12:51:02 -0700 (PDT) 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 ietfa.amsl.com (Postfix) with ESMTPS id 7DC671B2A0D for ; Sat, 19 Jul 2014 12:51:02 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E84038008E; Sat, 19 Jul 2014 15:51:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1405799460; bh=oSDYFgSjli5CQv8e5gfcyh95WhK2u94a8c6z1o+huvM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=dMiDAkafVIVq3gfUADn+ZCKAike+u00q8cc6pxsAKp9LrLtOMQbXJGuthZ6hGBqA2 FFesUKkhnUx8qZIqqZKQlUQGv9UoxPtyhapEvE5RcG7TxfKs91Al5M0IDemX7qwosx /oMEd9owoPtKlOTPOv5ZXs/nHf8Kq1POiGVGQH7k= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s6JJp0WK023314; Sat, 19 Jul 2014 15:51:00 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sat, 19 Jul 2014 15:51:00 -0400 (EDT) From: Paul Wouters To: Yaron Sheffer In-Reply-To: <53CAA14C.80301@gmail.com> Message-ID: References: <53CAA14C.80301@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/1n6OvUMVOesdExF-qPGFQocqLG8 Cc: IPsecME WG Subject: Re: [IPsec] Charter update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 19:51:04 -0000 On Sat, 19 Jul 2014, Yaron Sheffer wrote: > Recently discovered incorrect behavior of ISPs poses a > challenge to IKE, whose UDP messages (especially #3 and #4) > sometimes get fragmented at the IP level and then dropped > by these ISPs. There is interest in solving this issue by > allowing transport of IKE over TCP; this is currently > implemented by some vendors. The group will standardize such > a solution. The working group had already reached consensus not to support two different fragmentation solutions and to only support draft-smyslov-ipsecme-ikev2-fragmentation, after Yoav's IKE TCP presentation, I believe in London? So I don't think this item belongs on the agenda, unless we are looking at revising that earlier decision. > Goals and Milestones: > > Done - IETF Last Call on large scale VPN use cases and requirements > Done - IETF last call on IKE fragmentation solution > Done - IETF last call on new mandatory-to-implement algorithms > > [No current milestones] Could we add something about assisting Opportunistic Encryption, or whatever term will be used? There is the auth_none draft, and there will be an OE draft by the libreswan team soon. Those will end up in ipsecme. Paul From nobody Sat Jul 19 12:58:21 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A411A00DB for ; Sat, 19 Jul 2014 12:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 Vep6fj-u-Rgt for ; Sat, 19 Jul 2014 12:58:18 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A2B51A00D5 for ; Sat, 19 Jul 2014 12:58:18 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so4784922wgh.3 for ; Sat, 19 Jul 2014 12:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+7UKrdX7JTDEgkjTXZgyjHLjcPDRH8A7/jw/rpUAw9s=; b=K/8Bkqy4rcIIAYbjoCT/MFm+j0DvUOeYbcnU9Qrpc4p+cq2vM7T/mjWILprPN010ol vIuww/Ll30unzqbG38Sn1cE79eSNmVtXsp8CbB/RaIlXM0YcCQNcG3cDAn4I//tFkLjh CZgou44l7Pl6aAMjKsITsktO1ueB9X0O8glfiI9Tv3oOpkWm6R5UMy8+Z0UuvpBUyMJ1 SkhSd5ifxSdt24lybbsKlKWBDQ9jaPoyC5YWAQw+yQviKxqo3YexppPQdLYfSiB4dWpu d+SxJT0Qe9dpaCNVqw+NY8OgBb2r0+fNx/emdvKzvgKzB6d6u4F8FQba8gma6Gy0CsRh gflA== X-Received: by 10.194.187.101 with SMTP id fr5mr7630815wjc.125.1405799897078; Sat, 19 Jul 2014 12:58:17 -0700 (PDT) Received: from [10.0.0.1] ([109.67.0.77]) by mx.google.com with ESMTPSA id x3sm21603260wia.11.2014.07.19.12.58.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Jul 2014 12:58:16 -0700 (PDT) Message-ID: <53CACDD6.1090707@gmail.com> Date: Sat, 19 Jul 2014 22:58:14 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Wouters References: <53CAA14C.80301@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Yfs6_bemxCiJYZYZ8rn_0C3fEvQ Cc: IPsecME WG Subject: Re: [IPsec] Charter update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 19:58:20 -0000 >> Recently discovered incorrect behavior of ISPs poses a >> challenge to IKE, whose UDP messages (especially #3 and #4) >> sometimes get fragmented at the IP level and then dropped >> by these ISPs. There is interest in solving this issue by >> allowing transport of IKE over TCP; this is currently >> implemented by some vendors. The group will standardize such >> a solution. > > The working group had already reached consensus not to support two > different fragmentation solutions and to only support > draft-smyslov-ipsecme-ikev2-fragmentation, after Yoav's IKE TCP > presentation, I believe in London? So I don't think this item belongs > on the agenda, unless we are looking at revising that earlier decision. We have a fragmentation draft (almost) past IESG review. So we're not revising any decision. "The group will standardize such a solution" is still correct, until we actually publish the document. > >> Goals and Milestones: >> >> Done - IETF Last Call on large scale VPN use cases and requirements >> Done - IETF last call on IKE fragmentation solution >> Done - IETF last call on new mandatory-to-implement algorithms >> >> [No current milestones] > > Could we add something about assisting Opportunistic Encryption, or > whatever term will be used? There is the auth_none draft, and there > will be an OE draft by the libreswan team soon. Those will end up in > ipsecme. Quoting the new text, the group "will only take on new work items if a strong community interest can be seen." Do we have other people supporting such an addition to the charter? > > Paul From nobody Sat Jul 19 13:10:45 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356B61A029D for ; Sat, 19 Jul 2014 13:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 jpO3v5nAa2TB for ; Sat, 19 Jul 2014 13:10:42 -0700 (PDT) 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 ietfa.amsl.com (Postfix) with ESMTPS id DACF21A00AD for ; Sat, 19 Jul 2014 13:10:41 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 141458008E; Sat, 19 Jul 2014 16:10:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1405800641; bh=Ftel/S3efDlJz2wK1Krc+MiWX6csqvc/j1voVBfjW/g=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=iLz8OQSPffukVQplR+KAPi/a9YwbPRnJu1n1vjDhlEpcO3ljaYLojf6Xm4UYTQmDp NwRBzEeIJS9Y7Q4XqDVBH/2GDJXAv9Wyr4w3a5fLDwrp3tuHLACt2UgWURAAe+VbG5 7tnvIhjpx7cu/IpnoEd1PsmkRUM0EMh+yAdLkTzY= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s6JKAei1024593; Sat, 19 Jul 2014 16:10:40 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sat, 19 Jul 2014 16:10:40 -0400 (EDT) From: Paul Wouters To: Yaron Sheffer In-Reply-To: <53CACDD6.1090707@gmail.com> Message-ID: References: <53CAA14C.80301@gmail.com> <53CACDD6.1090707@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/cPgcYLU3JeSZAahH0Jn_79vxT7I Cc: IPsecME WG Subject: Re: [IPsec] Charter update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 20:10:43 -0000 On Sat, 19 Jul 2014, Yaron Sheffer wrote: >>> Recently discovered incorrect behavior of ISPs poses a >>> challenge to IKE, whose UDP messages (especially #3 and #4) >>> sometimes get fragmented at the IP level and then dropped >>> by these ISPs. There is interest in solving this issue by >>> allowing transport of IKE over TCP; this is currently >>> implemented by some vendors. The group will standardize such >>> a solution. >> >> The working group had already reached consensus not to support two >> different fragmentation solutions and to only support >> draft-smyslov-ipsecme-ikev2-fragmentation, after Yoav's IKE TCP >> presentation, I believe in London? So I don't think this item belongs >> on the agenda, unless we are looking at revising that earlier decision. > > We have a fragmentation draft (almost) past IESG review. So we're not > revising any decision. "The group will standardize such a solution" is still > correct, until we actually publish the document. You are revising the decision NOT to have IKE TCP: "There is interest in solving this issue by allowing transport of IKE over TCP; this is currently implemented by some vendors. The group will standardize such a solution." If you remove the first sentence, then it only talks about UDP and how we are working on standarising fragmentation support using UDP. Paul From nobody Sat Jul 19 13:19:39 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038D31B27B5 for ; Sat, 19 Jul 2014 13:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 Xm4H_NHpShmr for ; Sat, 19 Jul 2014 13:19:36 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C81EA1A00AD for ; Sat, 19 Jul 2014 13:19:35 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id x13so4743535wgg.31 for ; Sat, 19 Jul 2014 13:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cOVFdU9f8DZ5XgPHcxfk7CLvDkbd7FOdwaQs/uLGYzI=; b=p1aM+v96+RFxaDEbKyBDpuXU1K6dezI+WoUyR6DMXpd7kireBUNO/ZnsvNxIqOq40P dlV+vq3wVi1OFBmb4ckW53Db8eo/wm41O9AdWcldpFwO6fO0qn1jBvpoXDkAr9VJ9WqJ B6XMwW+Jod9KNYpvffpYBQv6u6J+MyZyl365UlsBpK20A5IqDbeo97wGIbrSICz4yLl9 LkUpn/SgAGQG5jH0Tfkq9yf7sCxV9Tg0r6KpWBVM2OLnXP/v921q+UFz8uMC1JN6j7ba UyxbIkLaC20jE5+fCLyGyU9Nyj8LgyNeZbZeIZPLu7jpxruWW45Wryr/oJlwEY0s6Hbz B+XQ== X-Received: by 10.180.211.101 with SMTP id nb5mr44072355wic.53.1405801174501; Sat, 19 Jul 2014 13:19:34 -0700 (PDT) Received: from [10.0.0.6] (bzq-79-177-145-172.red.bezeqint.net. [79.177.145.172]) by mx.google.com with ESMTPSA id ed15sm21781073wic.9.2014.07.19.13.19.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Jul 2014 13:19:34 -0700 (PDT) Message-ID: <53CAD2D5.6070907@gmail.com> Date: Sat, 19 Jul 2014 23:19:33 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Wouters References: <53CAA14C.80301@gmail.com> <53CACDD6.1090707@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/IY0VY5bItlihrYzqAB9e-Ja48RA Cc: IPsecME WG Subject: Re: [IPsec] Charter update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 20:19:37 -0000 > > You are revising the decision NOT to have IKE TCP: > > "There is interest in solving this issue by > allowing transport of IKE over TCP; this is currently > implemented by some vendors. The group will standardize such > a solution." > > If you remove the first sentence, then it only talks about UDP and how > we are working on standarising fragmentation support using UDP. > > Paul OK, makes sense. We need to remove that sentence. Thanks, Yaron From nobody Sun Jul 20 12:03:14 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C72E1B2CD7 for ; Sun, 20 Jul 2014 12:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=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 9O4mI2BkLpNA for ; Sun, 20 Jul 2014 12:03:03 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 378971B2CC0 for ; Sun, 20 Jul 2014 12:03:03 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s6KJ30dH012493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 20 Jul 2014 22:03:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s6KJ2xLx006190; Sun, 20 Jul 2014 22:02:59 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21452.4707.784185.458764@fireball.kivinen.iki.fi> Date: Sun, 20 Jul 2014 22:02:59 +0300 From: Tero Kivinen To: Johannes Merkle In-Reply-To: <53B6BA3F.40509@secunet.com> References: <20140701161112.18036.94027.idtracker@ietfa.amsl.com> <53B6BA3F.40509@secunet.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/3iBryhuN0qnHz0Wootu4tksUMfE Cc: ipsec@ietf.org Subject: Re: [IPsec] Last Call: (Signature Authentication in IKEv2) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 19:03:06 -0000 Johannes Merkle writes: > Nice work, the wording is really improved. However, I still have two > comments: > > 1. The wording in A.4 is confusing. > > With RSASSA-PSS, the algorithm object identifier is always id-RSASSA- > PSS, but the hash function is taken from the optional parameters, and > is required. > > It is not the hash function or the optional parameters that are > required but the OID id-RSASSA-PSS. Secondly, the "but" in the > second part of the sentence indicates some contrast but I don't see > one. Furthermore, not only the hash function is determined from the > parameters but also the other options for the padding. > > Why not changing the text to > > With RSASSA-PSS, the algorithm object identifier must always be > id-RSASSA-PSS, and the hash function and padding parameters are > conveyed in the optional parameters. Changed to: With RSASSA-PSS, the algorithm object identifier must always be id-RSASSA-PSS, and the hash function and padding parameters are conveyed in the parameters (which are not optional in this case). See for more information. In the RSASSA-PSS the parameters are required, but they can be empty, so they are not optional in this case. > 2. The wording in A.4.1 is also not unambiguous: > > Parameters are empty, but the ASN.1 part of the sequence must be > there. This means default parameters are used (same as the next > example). > > Here "next example" does not refer to the example following > immediately after this paragraph but to the example in the next > section. A reference to A.4.2 should be included. Changed to: Parameters are empty, but the ASN.1 part of the sequence must be present. This means default parameters are used. I.e removed the reference to next example. -- kivinen@iki.fi From nobody Mon Jul 21 08:18:28 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0E91A02CB; Mon, 21 Jul 2014 08:18: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] autolearn=ham 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 ERKpMpU-_aym; Mon, 21 Jul 2014 08:18:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8D91A0252; Mon, 21 Jul 2014 08:17:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721151752.7306.65634.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 08:17:52 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/figGfZ8weJkjaahpY-qv6X-Dv3k Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-kivinen-ipsecme-signature-auth-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:18:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Signature Authentication in IKEv2 Authors : Tero Kivinen Joel Snyder Filename : draft-kivinen-ipsecme-signature-auth-07.txt Pages : 18 Date : 2014-07-21 Abstract: The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by the PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism, and is not limited to ECDSA, but can also be used with other signature algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-kivinen-ipsecme-signature-auth-07 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 21 11:31:58 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D8D1A006C for ; Mon, 21 Jul 2014 11:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 eDLHQ39nxYnn for ; Mon, 21 Jul 2014 11:31:54 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE091A004B for ; Mon, 21 Jul 2014 11:31:54 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id n3so4706404wiv.2 for ; Mon, 21 Jul 2014 11:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uct7MGiMeMJUTQfZf43LuMj9D6Kiu1Lrb6LavlfMt2k=; b=koymfKNyPjPZHaJrW8s3POUlXzHNwrf/N9BvD4yDUJuEPWx4/H0/FG0OPd6aYGPPZL 0l3grR30s7VcgIy594Xc7lXo0zD6FOJu3VH/xFjvrNTSDNgqMIQeiRtCZQhmGSfLONvK qi3IgLPUpOfxkpYmm+fmiVy69J37/2PwhcLxzKhviWtUP1QiiUed53zKkP8q7fwqSHO/ fvvWfTnT5xZsWfnnWoNKmy6LLOClkMzYX3f7/5G81J3IL7bA0eIxjkowYTUrvd6xIonK fPjOY6QcPn/ISY4WYhnres58hyJ4WoggoeLfzc84nKifYiesN0QMnKMAOx1lntFZxyaV k38w== MIME-Version: 1.0 X-Received: by 10.194.63.77 with SMTP id e13mr25166771wjs.104.1405967512856; Mon, 21 Jul 2014 11:31:52 -0700 (PDT) Received: by 10.194.137.67 with HTTP; Mon, 21 Jul 2014 11:31:52 -0700 (PDT) In-Reply-To: <53CAD2D5.6070907@gmail.com> References: <53CAA14C.80301@gmail.com> <53CACDD6.1090707@gmail.com> <53CAD2D5.6070907@gmail.com> Date: Mon, 21 Jul 2014 20:31:52 +0200 Message-ID: From: Daniel Migault To: Yaron Sheffer Content-Type: multipart/alternative; boundary=047d7b86d9622b70d604feb85208 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/yrNdzIxoVeKwkt1ohiR2skFygHw Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] Charter update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 18:31:56 -0000 --047d7b86d9622b70d604feb85208 Content-Type: text/plain; charset=UTF-8 Hi, If that is appropriated I would like to see the following items on the charter: - 1) multiple interfaces that is describing how to optimize the IPsec settings between two hosts when at least one of the host has more than one interface. - 2) beet mode that defining a new mode so the overhead of IPsec Payload can be reduced, - 3) IPsec contexts that is documenting the parameters that are exchanged between two Security Gateways in order to manage clusters of VPN Security Gateways. - 4) Extending MOBIKE to transport mode. - 5) Finally, I think there might be some work in order to enable IPsec for IoT, especially designing IKEv2 extensions or looking at defining a mode or a way to send ESP payload without carrying the IV. BR, Daniel On Sat, Jul 19, 2014 at 10:19 PM, Yaron Sheffer wrote: > >> You are revising the decision NOT to have IKE TCP: >> >> "There is interest in solving this issue by >> allowing transport of IKE over TCP; this is currently >> implemented by some vendors. The group will standardize such >> a solution." >> >> If you remove the first sentence, then it only talks about UDP and how >> we are working on standarising fragmentation support using UDP. >> >> Paul >> > > OK, makes sense. We need to remove that sentence. > > Thanks, > Yaron > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7b86d9622b70d604feb85208 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

If that is appropriated I= would like to see the following items on the charter:
=C2=A0=C2=A0=C2= =A0 - 1) multiple interfaces that is describing how to optimize the IPsec s= ettings between two hosts when at least one of the host has more than one i= nterface.
=C2=A0=C2=A0=C2=A0 - 2) beet mode that defining a new mode so the overhead = of IPsec Payload can be reduced,
=C2=A0=C2=A0=C2=A0 - 3) IPsec contexts= that is documenting the parameters that are exchanged between two Security= Gateways in order to manage clusters of VPN Security Gateways.
=C2=A0=C2=A0=C2=A0 - 4) Extending MOBIKE to transport mode.=C2= =A0
=C2=A0=C2=A0=C2=A0 - 5) Finally, I think there might be = some work in order to enable IPsec for IoT, especially designing IKEv2 exte= nsions or looking at defining a mode or a way to send ESP payload without c= arrying the IV.


BR,
Daniel



O= n Sat, Jul 19, 2014 at 10:19 PM, Yaron Sheffer <yaronf.ietf@gmail.com<= /a>> wrote:

You are revising the decision NOT to have IKE TCP:

=C2=A0 =C2=A0 =C2=A0"There is interest in solving this issue by
=C2=A0 =C2=A0 =C2=A0 allowing transport of IKE over TCP; this is currently<= br> =C2=A0 =C2=A0 =C2=A0 implemented by some vendors. The group will standardiz= e such
=C2=A0 =C2=A0 =C2=A0 a solution."

If you remove the first sentence, then it only talks about UDP and how
we are working on standarising fragmentation support using UDP.

Paul

OK, makes sense. We need to remove that sentence.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec



--
Daniel Miga= ult
Orange Labs -- Security
+33 6 70 72 69 58
--047d7b86d9622b70d604feb85208-- From nobody Tue Jul 22 07:15:08 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25A81B28B1; Tue, 22 Jul 2014 07:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 kbIgHyihXA6o; Tue, 22 Jul 2014 07:14:58 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 23DB11B28B0; Tue, 22 Jul 2014 07:14:58 -0700 (PDT) Received: by mx2.eict.de (Postfix, from userid 481) id EF9821FF54; Tue, 22 Jul 2014 16:14:56 +0200 (CEST) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id E9DE11FF46; Tue, 22 Jul 2014 16:14:55 +0200 (CEST) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 9CF74378277; Tue, 22 Jul 2014 16:14:55 +0200 (CEST) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Tue, 22 Jul 2014 16:14:55 +0200 From: Kostas Pentikousis To: Steve Baillargeon Date: Tue, 22 Jul 2014 16:14:53 +0200 Thread-Topic: [ippm] WGLC on draft-ietf-ippm-ipsec-03 Thread-Index: AQHPj75vWlG8gyCu9kGHnYCBaKiwrJuCA6fggB3gDuCACvBY4IABbnAw Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1674@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619BC6@SBS2008.eict.local> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/qwyb8G1oqoZkmHLCyp7KYRKn340 Cc: "ipsec@ietf.org" , Brian Trammell , "draft-ietf-ippm-ipsec@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [IPsec] [ippm] WGLC on draft-ietf-ippm-ipsec-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:15:03 -0000 Hi Steve, Many thanks once again for the feedback and text suggestion! (adding ipsec folks in CC) | I am happy if the tittle changes to "IKEv2-based Shared Secret Key for | O/TWAMP". Already changed in my local copy, and I will update the slides for this aft= ernoon accordingly. | I suggest the following text: | In many cases, protecting unauthenticated O/TWAMP traffic using IPsec | security services is sufficient and provides the easiest solution to | secure sensitive traffic including O/TWAMP control and/or test traffic | and hide the O/TWAMP endpoint services from the external network with | IPsec tunnel mode for instance. This new mode is intended for the | following cases: | 1) when O/TWAMP traffic is bypassing IPsec protection and is running | over an external network exactly between two IKEv2 systems (maybe we | should elaborate on why this might be needed) | 2) when double protection is needed (should we drop this case and | recommend to avoid it?) How about the following, instead: We note that protecting unauthenticated O/TWAMP traffic using IPsec securit= y services is sufficient in many cases. That said, protecting unauthenticat= ed O/TWAMP control and/or test traffic via AH or ESP cannot provide various= security modes and cannot authenticate part of a O/TWAMP packet as mention= ed in . In real-world deployments this may hinder= timestamp accuracy. This document describes how to derive the shared secre= t key from the IKEv2 SA and employ the security service at the O/TWAMP laye= r. This method SHOULD be used when O/TWAMP traffic is bypassing IPsec prote= ction and is running over an external network exactly between two IKEv2 sys= tems. If this is ok, I can update the draft on the datatracker before lunch, and = then we discuss the two points below during the meeting in the afternoon. | IMO this mode should use the same "rekeying behavior" as defined in | IKEv2 i.e. if a new IKE SA is established to carry the IKE traffic | before the keys expires and the old SA is then deleted, then I suggest | a new TWAMP test session is established and the old test session is | closed before the keys expires. We had a short chat with Emma and it seems that although the (O/TWAMP) shar= ed secret key is derived from IKEv2 SA it is in fact a _separate key at the= O/TWAMP layer_. That would mean that it's not necessary to update the shar= ed secret key before it expires, even though a new IKEv2 SA is established.= Doing so will disrupt the ongoing test session. So we do not see much bene= fit from a measurements pov. | I still think one mode is sufficient. I guess we still think that backwards compatibility is a good thing :) Best regards, Kostas |=20 | Regards | Steve B |=20 | -----Original Message----- | From: Kostas Pentikousis [mailto:k.pentikousis@eict.de] | Sent: July-14-14 1:18 PM | To: Steve Baillargeon; Brian Trammell; ippm@ietf.org | Cc: draft-ietf-ippm-ipsec@tools.ietf.org | Subject: AW: [ippm] WGLC on draft-ietf-ippm-ipsec-03 |=20 | Hi Steve, all, |=20 | | I support with the following comments: |=20 | Many thanks for the support, much appreciated. |=20 |=20 | | - The tile of the draft is misleading. It should say something like | | O/TWAMP Shared Secret Key Feature |=20 | I think we discussed the title some time ago. Personally I would take a | bit of an issue with changing the title so late in the process, but I | have to agree that as the draft evolved since Orlando, the title didn't | do so accordingly. We're open to suggestions, although I am not excited | about the word "Feature" in an IETF RFC title :) Would something like | "IKEv2-based Shared Secret Key for O/TWAMP", for example, be ok with | you? |=20 |=20 | | - The use case in section 1 is not clear. It should indicate this | mode | | is intended for protecting and exchanging OWAMP/TWAMP test protocol | | between two IKEv2 systems when OWAMP/TWAMP control/test traffic is | not | | protected by IPSec |=20 | The document does focus on how to derive O/TWAMP Shared Secret Key from | IKEv2 SA. As per earlier discussions in Berlin and Vancouver, I think | we already agreed that this is orthogonal to whether the O/TWAMP | control/test traffic is transferred inside the IPsec tunnel or not. The | admin or operator policy could play a role, for example. Of course, one | should avoid a so-to-speak "double security protection". |=20 |=20 | | - I personally think the most common case is to protect OWAMP/TWAMP | | control/test traffic with IPsec. It is important to highlight the | | benefits associated with this new mode versus the common | | unauthenticated O/TWAMP mode protected via AH or ESP. |=20 | I think we mostly agree on this. Would you be so kind to propose some | text to add? I guess a few of sentences would suffice at this stage |=20 |=20 | | - in section 4.1 first sentence, the requirement level is ambiguous. | I | | think it should say...the shared secret MUST be derived ...(as | opposed | | to can). Same comment for the second paragraph, the word if should be | | replaced by when. |=20 | Sounds good; we will update the draft before the meeting. Thanks for | this point. |=20 |=20 | | - end of section 4.1, the expected behavior when the IKEv2 SA is | | rekeyed is not clear. Same is true when the IKEv2 SA is deleted for | | whatever reasons. What should the O/TWAMP part of the IKE system do | | when the IKE SA is rekeyed or deleted? Should it close its test | | sessions and setup new test sessions using the key associated with | the | | newly established IKEv2 SA? Waiting for the lifetime to expire does | | not make sense. And if you do, what happens next? |=20 |=20 | I'm not sure about this, although we would be happy to integrate | proposed text from your end. The shared secret key generated from the | SA could continue to be used until the lifetime expiration. Do you see | a need to rekey the shared secret key immediately after the IKEv2 SA is | rekeyed? |=20 | | - section 4.2. Three (3) new TWAMP modes are not needed. One TWAMP | | mode called Shared Secret Key should be sufficient. This mode can | then | | be used on conjunction with the authenticated, encrypted and mixed | modes. | | Please do not use the X mode over IKEv2. The text "over" is always | | misleading. |=20 |=20 | I need to go back to my notes wrt the discussion we had earlier. If I | recall correctly, extending the Modes values is advantageous if one | considers backwards compatibility with existing O/TWAMP clients. The | Set-Up-Response Message contains a mode value which indicates | unauthenticated, authenticated or encrypted. In this case, the O/TWAMP | server cannot obtain the information whether to derive shared secret | key from an IKEv2 SA or not, if the modes value is not extended. The | Set-Up-Response Message must signal this in conjunction with the mode. | Since there is no unused field in the Set-Up-Response Message, isn't | it better to extend Modes? |=20 |=20 | Best regards, |=20 | Kostas and Emma From nobody Tue Jul 22 07:42:18 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376D01A0060; Tue, 22 Jul 2014 07:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 FYaiXLdSwouU; Tue, 22 Jul 2014 07:42:14 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637F41AC0D2; Tue, 22 Jul 2014 07:42:12 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-cc-53ce255682cc Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 26.11.05330.6552EC35; Tue, 22 Jul 2014 10:48:22 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 10:42:08 -0400 From: Steve Baillargeon To: Kostas Pentikousis Thread-Topic: [ippm] WGLC on draft-ietf-ippm-ipsec-03 Thread-Index: AQHPj75vWlG8gyCu9kGHnYCBaKiwrJuCA6fggB3gDuCACvBY4IABbnAwgAAOCRA= Date: Tue, 22 Jul 2014 14:42:08 +0000 Message-ID: References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1674@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619BC6@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXSPt26Y6rlggxdz1C0W3p3PZLGx5R2b Rc+Dd8wW+7e8YLPYc2A/qwOrx5f/TUweS5b8ZPL4cvkzm8eT/TNZAliiuGxSUnMyy1KL9O0S uDKO/6kp2OtZ0fL+FEsD4z+rLkZODgkBE4mNbzazQ9hiEhfurWfrYuTiEBI4yihx4OxZKGc5 o8S3N9OYQarYBCwk1s9dBmaLCOhJ7Fl7jhWkiFlgD6PE1519YKOEgcZ+nHufBaLIVGLvgcns ELafxNtX78CaWQRUJVbd+AsW5xXwlXh4tocdYlsPs8SHjZvBmjkFfCT2PH7KCGIzCshK7D57 nQnEZhYQl7j1ZD4TxN0CEkv2nGeGsEUlXj7+xwphK0lMWnqOFaJeR2LB7k9sELa2xLKFr5kh FgtKnJz5hGUCo9gsJGNnIWmZhaRlFpKWBYwsqxg5SotTy3LTjQw2MQJj65gEm+4Oxj0vLQ8x CnAwKvHwLnhyJliINbGsuDL3EKM0B4uSOO+s2nnBQgLpiSWp2ampBalF8UWlOanFhxiZODil GhgnbK+Se8y+ycJDdLrHLfl9jiZnXyp4rTGw+NV1xvSTX0ZkquLHWCbOJzyG+r32amop3tdW 3X8tsq4j/3NA7PO67TcPKM+9v1v+157dRauUS+35bqyaM3/Fsa9bdYSMFCzzdsY2t/vVW9kk TuP8/ir8RX6/YrTS3YvcC9asW7RUJUxeKGLLyV4lluKMREMt5qLiRADDTLl+jgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/vE32aiUYz-tUXsjG6NaDNYzPTtA Cc: "ipsec@ietf.org" , Brian Trammell , "draft-ietf-ippm-ipsec@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [IPsec] [ippm] WGLC on draft-ietf-ippm-ipsec-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:42:16 -0000 Hi Kostas Some quick comments. The changes looks good but I think we need a couple of simple network diagr= ams to clarify the case when this mode is not needed and the case when it n= eeded. Here are two examples. 1) Case when new mode is not used/needed: Inner TWAMP Controller -- Internal Network ---IKE System 1 ---External Netw= ork ---IKE System 2 ---Internal Network ---Inner TWAMP Responder In this case #1, IPsec is protecting the TWAMP traffic (running in TWAMP un= authenticated mode for instance) and any other inner traffic over the exter= nal network but the TWAMP traffic is transmitted in cleartext and is not (f= ully) authenticated by the TWAMP endpoints=20 Note 1: the controller and responder can also perform basic "ACL-like check= ing" based on the IP addresses and port numbers in TWAMP unauthenticated mo= de. Not sure what you mean by "In real-world deployments this may hinder timest= amp accuracy". I don't see any problem with this case if the internal netwo= rks are considered "trustable" and both TWAMP endpoints are managed by the = same "entity". Note 2: The Inner TWAMP responder and/or controller can be standalone or em= bedded within the IKE system. 2) Case when new mode is used/needed: IKE System 1 acting an Outer TWAMP Controller---External Network ---IKE Sys= tem 2 acting as Outer TWAMP Responder In this case #1, IPsec is not protecting the TWAMP traffic. The TWAMP traff= ic is directly running over the external network in authenticated mode (etc= ...) in conjunction with the new mode. Note 3: The outer TWAMP responder and/or controller are embedded within eac= h IKE system. Is this what you have in mind for the use case? Is there more to it? Regards Steve B -----Original Message----- From: Kostas Pentikousis [mailto:k.pentikousis@eict.de]=20 Sent: July-22-14 10:15 AM To: Steve Baillargeon Cc: draft-ietf-ippm-ipsec@tools.ietf.org; Brian Trammell; ippm@ietf.org; ip= sec@ietf.org Subject: AW: [ippm] WGLC on draft-ietf-ippm-ipsec-03 Hi Steve, Many thanks once again for the feedback and text suggestion! (adding ipsec folks in CC) | I am happy if the tittle changes to "IKEv2-based Shared Secret Key for=20 | O/TWAMP". Already changed in my local copy, and I will update the slides for this aft= ernoon accordingly. | I suggest the following text: | In many cases, protecting unauthenticated O/TWAMP traffic using IPsec=20 | security services is sufficient and provides the easiest solution to=20 | secure sensitive traffic including O/TWAMP control and/or test traffic=20 | and hide the O/TWAMP endpoint services from the external network with=20 | IPsec tunnel mode for instance. This new mode is intended for the=20 | following cases: | 1) when O/TWAMP traffic is bypassing IPsec protection and is running=20 | over an external network exactly between two IKEv2 systems (maybe we=20 | should elaborate on why this might be needed) | 2) when double protection is needed (should we drop this case and=20 | recommend to avoid it?) How about the following, instead: We note that protecting unauthenticated O/TWAMP traffic using IPsec securit= y services is sufficient in many cases. That said, protecting unauthenticat= ed O/TWAMP control and/or test traffic via AH or ESP cannot provide various= security modes and cannot authenticate part of a O/TWAMP packet as mention= ed in . In real-world deployments this may hinder= timestamp accuracy. This document describes how to derive the shared secre= t key from the IKEv2 SA and employ the security service at the O/TWAMP laye= r. This method SHOULD be used when O/TWAMP traffic is bypassing IPsec prote= ction and is running over an external network exactly between two IKEv2 sys= tems. If this is ok, I can update the draft on the datatracker before lunch, and = then we discuss the two points below during the meeting in the afternoon. | IMO this mode should use the same "rekeying behavior" as defined in | IKEv2 i.e. if a new IKE SA is established to carry the IKE traffic=20 | before the keys expires and the old SA is then deleted, then I suggest=20 | a new TWAMP test session is established and the old test session is=20 | closed before the keys expires. We had a short chat with Emma and it seems that although the (O/TWAMP) shar= ed secret key is derived from IKEv2 SA it is in fact a _separate key at the= O/TWAMP layer_. That would mean that it's not necessary to update the shar= ed secret key before it expires, even though a new IKEv2 SA is established.= Doing so will disrupt the ongoing test session. So we do not see much bene= fit from a measurements pov. | I still think one mode is sufficient. I guess we still think that backwards compatibility is a good thing :) Best regards, Kostas |=20 | Regards | Steve B |=20 | -----Original Message----- | From: Kostas Pentikousis [mailto:k.pentikousis@eict.de] | Sent: July-14-14 1:18 PM | To: Steve Baillargeon; Brian Trammell; ippm@ietf.org | Cc: draft-ietf-ippm-ipsec@tools.ietf.org | Subject: AW: [ippm] WGLC on draft-ietf-ippm-ipsec-03 |=20 | Hi Steve, all, |=20 | | I support with the following comments: |=20 | Many thanks for the support, much appreciated. |=20 |=20 | | - The tile of the draft is misleading. It should say something like=20 | | O/TWAMP Shared Secret Key Feature |=20 | I think we discussed the title some time ago. Personally I would take=20 | a bit of an issue with changing the title so late in the process, but=20 | I have to agree that as the draft evolved since Orlando, the title=20 | didn't do so accordingly. We're open to suggestions, although I am not=20 | excited about the word "Feature" in an IETF RFC title :) Would=20 | something like "IKEv2-based Shared Secret Key for O/TWAMP", for=20 | example, be ok with you? |=20 |=20 | | - The use case in section 1 is not clear. It should indicate this | mode | | is intended for protecting and exchanging OWAMP/TWAMP test protocol=20 | | between two IKEv2 systems when OWAMP/TWAMP control/test traffic is | not | | protected by IPSec |=20 | The document does focus on how to derive O/TWAMP Shared Secret Key=20 | from | IKEv2 SA. As per earlier discussions in Berlin and Vancouver, I think=20 | we already agreed that this is orthogonal to whether the O/TWAMP=20 | control/test traffic is transferred inside the IPsec tunnel or not.=20 | The admin or operator policy could play a role, for example. Of=20 | course, one should avoid a so-to-speak "double security protection". |=20 |=20 | | - I personally think the most common case is to protect OWAMP/TWAMP=20 | | control/test traffic with IPsec. It is important to highlight the=20 | | benefits associated with this new mode versus the common=20 | | unauthenticated O/TWAMP mode protected via AH or ESP. |=20 | I think we mostly agree on this. Would you be so kind to propose some=20 | text to add? I guess a few of sentences would suffice at this stage |=20 |=20 | | - in section 4.1 first sentence, the requirement level is ambiguous. | I | | think it should say...the shared secret MUST be derived ...(as | opposed | | to can). Same comment for the second paragraph, the word if should=20 | | be replaced by when. |=20 | Sounds good; we will update the draft before the meeting. Thanks for=20 | this point. |=20 |=20 | | - end of section 4.1, the expected behavior when the IKEv2 SA is=20 | | rekeyed is not clear. Same is true when the IKEv2 SA is deleted for=20 | | whatever reasons. What should the O/TWAMP part of the IKE system do=20 | | when the IKE SA is rekeyed or deleted? Should it close its test=20 | | sessions and setup new test sessions using the key associated with | the | | newly established IKEv2 SA? Waiting for the lifetime to expire does=20 | | not make sense. And if you do, what happens next? |=20 |=20 | I'm not sure about this, although we would be happy to integrate=20 | proposed text from your end. The shared secret key generated from the=20 | SA could continue to be used until the lifetime expiration. Do you see=20 | a need to rekey the shared secret key immediately after the IKEv2 SA=20 | is rekeyed? |=20 | | - section 4.2. Three (3) new TWAMP modes are not needed. One TWAMP=20 | | mode called Shared Secret Key should be sufficient. This mode can | then | | be used on conjunction with the authenticated, encrypted and mixed | modes. | | Please do not use the X mode over IKEv2. The text "over" is always=20 | | misleading. |=20 |=20 | I need to go back to my notes wrt the discussion we had earlier. If I=20 | recall correctly, extending the Modes values is advantageous if one=20 | considers backwards compatibility with existing O/TWAMP clients. The=20 | Set-Up-Response Message contains a mode value which indicates=20 | unauthenticated, authenticated or encrypted. In this case, the O/TWAMP=20 | server cannot obtain the information whether to derive shared secret=20 | key from an IKEv2 SA or not, if the modes value is not extended. The=20 | Set-Up-Response Message must signal this in conjunction with the mode. | Since there is no unused field in the Set-Up-Response Message, isn't=20 | it better to extend Modes? |=20 |=20 | Best regards, |=20 | Kostas and Emma From nobody Tue Jul 22 07:54:09 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E395D1B27F2; Tue, 22 Jul 2014 07:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 J1Nr5JvxV1XF; Tue, 22 Jul 2014 07:54:08 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id DCD7C1B27D8; Tue, 22 Jul 2014 07:54:07 -0700 (PDT) Received: by mx2.eict.de (Postfix, from userid 481) id EDC8F1FF52; Tue, 22 Jul 2014 16:54:06 +0200 (CEST) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id A32811FF46; Tue, 22 Jul 2014 16:54:06 +0200 (CEST) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 3E521378277; Tue, 22 Jul 2014 16:54:06 +0200 (CEST) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Tue, 22 Jul 2014 16:54:05 +0200 From: Kostas Pentikousis To: Steve Baillargeon Date: Tue, 22 Jul 2014 16:54:05 +0200 Thread-Topic: [ippm] WGLC on draft-ietf-ippm-ipsec-03 Thread-Index: AQHPj75vWlG8gyCu9kGHnYCBaKiwrJuCA6fggB3gDuCACvBY4IABbnAwgAAOCRCAAAfbQA== Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FD7@SBS2008.eict.local> References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1674@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619BC6@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/CgjHsNlcDyCGIueKqp9hGt2ed-E Cc: "ipsec@ietf.org" , Brian Trammell , "draft-ietf-ippm-ipsec@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [IPsec] [ippm] WGLC on draft-ietf-ippm-ipsec-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:54:09 -0000 Hi Steve, | The changes looks good but I think we need a couple of simple network | diagrams to clarify the case when this mode is not needed and the case | when it needed. Simple network examples may be a good idea to orient the uninitiated reader= . But adding network diagrams to scope the applicability is not an equally = good idea.=20 | internal networks are considered "trustable" and both TWAMP endpoints I'm not sure whether anyone really thinks that an "internal" network in the= age of virtualization can be "trustable" :) Best regards, Kostas From nobody Tue Jul 22 08:11:58 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1B21B292A; Tue, 22 Jul 2014 08:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 4e8TBEdb8Y3L; Tue, 22 Jul 2014 08:11:45 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A99B1A0073; Tue, 22 Jul 2014 08:11:41 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-1d-53ce29d5d9f7 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 78.52.25146.5D92EC35; Tue, 22 Jul 2014 11:07:33 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 11:11:40 -0400 From: Steve Baillargeon To: Kostas Pentikousis Thread-Topic: [ippm] WGLC on draft-ietf-ippm-ipsec-03 Thread-Index: AQHPj75vWlG8gyCu9kGHnYCBaKiwrJuCA6fggB3gDuCACvBY4IABbnAwgAAOCRCAAAfbQIAAAfRQ Date: Tue, 22 Jul 2014 15:11:39 +0000 Message-ID: References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1674@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619BC6@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FD7@SBS2008.eict.local> In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FD7@SBS2008.eict.local> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyuXRPoO5VzXPBBl/uilksvDufyWJjyzs2 i54H75gt9m95wWax58B+VgdWjy//m5g8liz5yeTx5fJnNo8n+2eyBLBEcdmkpOZklqUW6dsl cGUc2nmRvWApZ8Wx7lVsDYzH2LsYOTkkBEwkft48zwJhi0lcuLeerYuRi0NI4CijxM3rd5kh nOWMEh//N7GBVLEJWEisn7uMGcQWEdCT2LP2HCtIEbPAHkaJrzv7wMYKA439OPc+C0SRqcTe A5PZIewoiV9328DiLAKqEhcuPmUEsXkFfCXuX+tngtg2iUXiwrfprCAJTgEfiabr78GaGQVk JXafvc4EYjMLiEvcejKfCeJuAYkle84zQ9iiEi8f/2OFsJUk5ry+xgxRryOxYPcnNghbW2LZ wtfMEIsFJU7OfMIygVFsFpKxs5C0zELSMgtJywJGllWMHKXFqWW56UaGmxiB0XVMgs1xB+OC T5aHGAU4GJV4eBc8ORMsxJpYVlyZe4hRmoNFSZxXs3pesJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQbG0uo2YU0DZhvzTuYzIlVfk6MWLeKbl/PN7efEx/q5IT6XIua/XBfr9CvmdLKOzSb7 2ElCfLXpB3+XrZ90Xbi3gaH68K3jf/e4b0qwS3RmvZD9NVhV6FuaptCvwrCLxe8vd808d4XB nflVRdiX83u2XI56OK3QXrN0y9QELsXFRpMryr1E+dKUWIozEg21mIuKEwG1Fo9mjwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/UoMBp_rM_4vA50N2lYnm1z5oHVc Cc: "ipsec@ietf.org" , Brian Trammell , "draft-ietf-ippm-ipsec@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [IPsec] [ippm] WGLC on draft-ietf-ippm-ipsec-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:11:56 -0000 Hi Kostas I must disagree here.=20 Stating that unauthenticated mode is no longer applicable is incorrect. I believe that adding network diagrams to scope the applicability is a good= idea as long as the associated text is concise. I am still confused about the new mode applicability :) -Steve -----Original Message----- From: Kostas Pentikousis [mailto:k.pentikousis@eict.de]=20 Sent: July-22-14 10:54 AM To: Steve Baillargeon Cc: draft-ietf-ippm-ipsec@tools.ietf.org; Brian Trammell; ippm@ietf.org; ip= sec@ietf.org Subject: AW: [ippm] WGLC on draft-ietf-ippm-ipsec-03 Hi Steve, | The changes looks good but I think we need a couple of simple network=20 | diagrams to clarify the case when this mode is not needed and the case=20 | when it needed. Simple network examples may be a good idea to orient the uninitiated reader= . But adding network diagrams to scope the applicability is not an equally = good idea.=20 | internal networks are considered "trustable" and both TWAMP endpoints I'm not sure whether anyone really thinks that an "internal" network in the= age of virtualization can be "trustable" :) Best regards, Kostas From nobody Wed Jul 23 11:16:08 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025251B29EC for ; Wed, 23 Jul 2014 11:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 YDE6a5SAXFSl for ; Wed, 23 Jul 2014 11:16:04 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B87261B2B3C for ; Wed, 23 Jul 2014 11:16:04 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49860 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XA15M-000Cu8-QA for ipsec@ietf.org; Wed, 23 Jul 2014 14:16:16 -0400 Message-ID: <53CFFBE2.50602@bbn.com> Date: Wed, 23 Jul 2014 14:16:02 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ipsec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/b_zsa7FnOfJXDbnPhEWm1Kad3kQ Subject: Re: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 18:16:06 -0000 Daniel, I read the very brief IV-generation I-D and I didn't see an explanation of how to perform IV "compression." As someone else already noted on the list, an IV is carried with each packet to enable decryption of packets that may arrive out of order. Thus it's not enough to have each peer use the same PRF and seed to generate IVs which are not explicitly transported, because of this requirement. Also, if the IV is required to be pesudorandom, there is likely no opportunity for compression in the usual sense. Finally, note that the specs for algorithm modes like GCM treat the IV as a security critical piece of info, for good reason. Thus if one tries to re-use a value such as an ESP sequence number as an IV, all of the ESP sequence number generation/management code becomes security critical wrt algorithm mode evaluation. This topic was discussed in London in the TLS WG meeting, when considering use of Cha-Cha. I can forward the relevant messages and my slides if you wish. Steve From nobody Wed Jul 23 12:47:28 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F711B2BBE; Wed, 23 Jul 2014 12:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 s7Edax6jUsn7; Wed, 23 Jul 2014 12:47:18 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6ADF1A014F; Wed, 23 Jul 2014 12:47:17 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id f8so2850464wiw.6 for ; Wed, 23 Jul 2014 12:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=emLoHB1W4BTVs4WGiZAfJD7uu4UL2yUe7z0ATQUehv8=; b=xDsoJ1U+ESXe8za6DhGB0ED/Cbzeza3ZkH8vPQhT+2vz2R44DTr+ExXjAiV0N6SrGo D4O/PRQN6GnMDMxoE5T2P/Szz0X6iIYZbYvT0LpLE3toFpM8kCOghA/GjnROJdJ93W6I JIKlBxSBEhzwVXvTFPVaIa3p7B7IP/IYCZu0TEF0Tf13bWifJJDR2H+e+lfLqSeh23Pa ye59lsh5Knx+NdStqAD2AkwwGf62ZCl+QH4Kme9PLvZ97xXTQvgStbiPOFVT0Wv21YMZ I39CkEcR81L7OtwTgZqoTn0PC3Sd91h+sY5Cag9lFW/CB/tBQ6dDph5z0dLDtFqA+fmn 98Lw== MIME-Version: 1.0 X-Received: by 10.194.60.240 with SMTP id k16mr5330244wjr.0.1406144836484; Wed, 23 Jul 2014 12:47:16 -0700 (PDT) Received: by 10.194.137.67 with HTTP; Wed, 23 Jul 2014 12:47:16 -0700 (PDT) Date: Wed, 23 Jul 2014 21:47:16 +0200 Message-ID: From: Daniel Migault To: "ipsec@ietf.org" , "mif@ietf.org" , "multipathtcp@ietf.org Mailing List" Content-Type: multipart/alternative; boundary=047d7bacc1e47b490c04fee19b90 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/wntm6kHW1fHKlewdOQOCfefUh64 Subject: [IPsec] IP Security for multiple interfaces X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:47:20 -0000 --047d7bacc1e47b490c04fee19b90 Content-Type: text/plain; charset=UTF-8 Hi, We believe our document for multiple interfaces security using IPsec is closed to its final version. To go further we collect interests of various WG concerned by multiple interfaces. So please let us know: - 1) if you think this topic is of interests and should be addressed - 2) if you would like to review the documents Comments on the draft are also welcome! BR, Daniel [1] http://tools.ietf.org/html/draft-mglt-ipsecme-clone-ike-sa-02 -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7bacc1e47b490c04fee19b90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

We believe our document for mul= tiple interfaces security using IPsec is closed to its final version. <= br>
To go further we collect interests of various WG concerned by multiple = interfaces. So please let us know:

=C2=A0 =C2=A0 - 1) if you t= hink this topic is of interests and should be addressed=C2=A0 =C2=A0
=C2=A0=C2=A0=C2=A0 - 2) if you would like to review the documents
--047d7bacc1e47b490c04fee19b90-- From nobody Wed Jul 23 16:08:52 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC6A1A011E; Wed, 23 Jul 2014 16:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=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 Xj6-TmMm21qW; Wed, 23 Jul 2014 16:08:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 470F01A00B5; Wed, 23 Jul 2014 16:08:48 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s6NN7Qaf024892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Jul 2014 02:07:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s6NN7OB1008483; Thu, 24 Jul 2014 02:07:24 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21456.16428.701207.732932@fireball.kivinen.iki.fi> Date: Thu, 24 Jul 2014 02:07:24 +0300 From: Tero Kivinen To: Kostas Pentikousis In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1674@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619BC6@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 14 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Y4Q1C_9gVk5vTUSsKUjm7mhXZpQ Cc: "ipsec@ietf.org" , Brian Trammell , Steve Baillargeon , "draft-ietf-ippm-ipsec@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [IPsec] [ippm] WGLC on draft-ietf-ippm-ipsec-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 23:08:50 -0000 Kostas Pentikousis writes: > (adding ipsec folks in CC) I quickly read this document and I think it needs much broaders review from the IPsec people. This document is using internal IKEv2 keying material outside IKEv2 SA context, meaning it can cause problems with the actual security of the IKEv2 SA. It uses Shared secret key = PRF( SKEYSEED, "IPPM" ) to generate the shared key to be used in the ippm. The SKEYSEED is internal IKEv2 keying material, and should not be exposed outside IKEv2. All IKEv2 keying material to protect the IKEv2 SA is also derived from that value. The generation looks quite safe, so it most likely do not directly cause IKEv2 SA to be broken, but also as SKEYSEED is internal to the IKEv2, it might not be available at all outside the IKEv2 library. For example my IKEv2 code will never store the SKEYSEED, it is temporary calculated and then used to calculate the derived SK_* keys, and then immediately zeroed out. It would be much better to use the SK_d or KEYMAT which is derived from the SK_d for that purposes, as that is what SK_d was meant to be used, (i.e to derive keys for other uses than IKEv2 SA protection or authentication). Also the section 4.1 talks about the lifetime of the shared secret key, but I have no idea what expire time it is refering to. If it refers to the Shared secret key generated above, then where is its expire time defined? IKEv2 does not negotiate lifetimes, and IKEv2 SA rekey is the closest thing we have about lifetime in the IKEv2, but the text explictly says that "shared secret key generated" can continue to be used... Anyways I thing this document needs more reviews especially from the IPsec community, as it is using IKEv2 as KMP for something else than IPsec (which is not a wrong thing to do, but you need to know what you are doing). -- kivinen@iki.fi From nobody Thu Jul 24 05:07:13 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346B01A024C; Thu, 24 Jul 2014 05:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 UEle0djG5OHE; Thu, 24 Jul 2014 05:06:59 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id D0DB91A0250; Thu, 24 Jul 2014 05:06:58 -0700 (PDT) Received: by mx2.eict.de (Postfix, from userid 481) id 80D2D1FF58; Thu, 24 Jul 2014 14:06:57 +0200 (CEST) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 380801FF54; Thu, 24 Jul 2014 14:06:57 +0200 (CEST) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id BC71437825F; Thu, 24 Jul 2014 14:06:56 +0200 (CEST) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Thu, 24 Jul 2014 14:06:56 +0200 From: Kostas Pentikousis To: Tero Kivinen Date: Thu, 24 Jul 2014 14:06:54 +0200 Thread-Topic: [IPsec] [ippm] WGLC on draft-ietf-ippm-ipsec-03 Thread-Index: Ac+mzo7WbZngNQMUSV+XLiReTVehhQAZ/zXg Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C61A112@SBS2008.eict.local> References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1674@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619BC6@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> <21456.16428.701207.732932@fireball.kivinen.iki.fi> In-Reply-To: <21456.16428.701207.732932@fireball.kivinen.iki.fi> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Hsn1ywg6YDbulgMnI2TKjzK9vjg Cc: "ipsec@ietf.org" , Brian Trammell , Steve Baillargeon , "draft-ietf-ippm-ipsec@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [IPsec] [ippm] WGLC on draft-ietf-ippm-ipsec-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 12:07:01 -0000 Hi Tero, all, Many thanks for chimming in, much appreciated! =20 | Anyways I thing this document needs more reviews especially from the | IPsec community, as it is using IKEv2 as KMP for something else than | IPsec (which is not a wrong thing to do, but you need to know what you | are doing). Indeed, and as you may recall I have asked ipsec in the the past for commen= ts/review wrt this draft. I'm very happy to see the comments and I think al= l at ippm will be even happier to see more of it. Best regards, Kostas From nobody Thu Jul 24 10:20:00 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52181A023E; Thu, 24 Jul 2014 05:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 2o_PvxisAHFu; Thu, 24 Jul 2014 05:31:21 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id CF9C21A0280; Thu, 24 Jul 2014 05:31:20 -0700 (PDT) Received: from dhcp-9d17.meeting.ietf.org (dhcp-9d17.meeting.ietf.org [31.133.157.23]) by trammell.ch (Postfix) with ESMTPSA id 724911A0327; Thu, 24 Jul 2014 14:30:47 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Trammell In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C61A112@SBS2008.eict.local> Date: Thu, 24 Jul 2014 08:30:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <36E1DF4F-B178-4346-AC35-78C176B5FB14@trammell.ch> References: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C4F1674@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619BC6@SBS2008.eict.local> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C619FC1@SBS2008.eict.local> <21456.16428.701207.732932@fireball.kivinen.iki.fi> <0C7EDCF89AB9E2478B5D010026CFF4AEA10C61A112@SBS2008.eict.local> To: Kostas Pentikousis , "ipsec@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/vpKpKJYQ7Xu_gof5lAEbv01puI0 X-Mailman-Approved-At: Thu, 24 Jul 2014 10:19:58 -0700 Cc: Steve Baillargeon , "draft-ietf-ippm-ipsec@tools.ietf.org" , Tero Kivinen , "ippm@ietf.org" Subject: Re: [IPsec] [ippm] WGLC on draft-ietf-ippm-ipsec-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 12:31:25 -0000 hi Kostas, Tero, all, Many thanks for the review! For the benefit of the ipsec working group, there are still a few = discussions from the ippm side but we expect these to be resolved soon, = after which we'd like to request publication. One or two more reviews = from ipsec in the meantime would be extremely useful. Thanks again, best regards, Brian (as co-chair, ippm) On 24 Jul 2014, at 8:06, Kostas Pentikousis = wrote: > Hi Tero, all, >=20 > Many thanks for chimming in, much appreciated! >=20 > =20 >=20 > | Anyways I thing this document needs more reviews especially from the > | IPsec community, as it is using IKEv2 as KMP for something else than > | IPsec (which is not a wrong thing to do, but you need to know what = you > | are doing). >=20 > Indeed, and as you may recall I have asked ipsec in the the past for = comments/review wrt this draft. I'm very happy to see the comments and I = think all at ippm will be even happier to see more of it. >=20 > Best regards, >=20 > Kostas >=20 >=20 From nobody Thu Jul 24 11:55:29 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCED1B27A9; Thu, 24 Jul 2014 11:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 qUZoGcz0Z07c; Thu, 24 Jul 2014 11:55:21 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 174E91B27A7; Thu, 24 Jul 2014 11:55:20 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so10170316wiv.17 for ; Thu, 24 Jul 2014 11:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yMpqnwmkkW1Br/VJl+TyJSh/L4bf0LpSKOuPVpYrVHQ=; b=bElmlQtW+PD83dsVrriR6RlLLMKDFAeCIZCcmx3dhO0XEePT3IdM+SL9+0Vn6/TfXX m2zoluhpMmkJv/SA1W5eBEf9tBcecC2OlPINM7Xz9/g1ypwSK6J8ZoYjwDMQEQ6xOyU0 iElbHvDfXJQMJR4aadtV7fDVnJq0PDaq/BDxkwJOHN0roi872hKakD37JdW0fkukEpOW CFkNZtYCNEgrxPu8wCa9wRbYiG8MTlaYEckRcNkr97fLLK3eGqjvx6TTO13DwwwQQTew 2B3ieNSTJKCJJfP0DZcskk5LNxMF+F8PpA7Pvb9KDEqfu2wt+IfjXryBLm6m+bC1iz29 il1Q== MIME-Version: 1.0 X-Received: by 10.194.60.240 with SMTP id k16mr15512961wjr.0.1406228118403; Thu, 24 Jul 2014 11:55:18 -0700 (PDT) Received: by 10.194.137.67 with HTTP; Thu, 24 Jul 2014 11:55:18 -0700 (PDT) In-Reply-To: <53CFFBE2.50602@bbn.com> References: <53CFFBE2.50602@bbn.com> Date: Thu, 24 Jul 2014 20:55:18 +0200 Message-ID: From: Daniel Migault To: Stephen Kent Content-Type: multipart/alternative; boundary=047d7bacc1e47880aa04fef4ffd4 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/oMhQ95Q8jobaJrb61DG3Vl18uYI Cc: "ipsec@ietf.org" , 6lo@ietf.org Subject: Re: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:55:25 -0000 --047d7bacc1e47880aa04fef4ffd4 Content-Type: text/plain; charset=UTF-8 Hi Steve, First of all many thanks for the comments. They will be usefull to design it right. I have copied the 6lo ML since we presented Diet-ESP in 6lo this morning. There has been some discussion on the IV compression too and here is the link to the presentation Steve made at TLS in the IETF 89 in London [1 ] The design we had in mind is as follows: a) On the sender side: - Step 1: Each peer negotiate a key: in the next version we will specify that this key is derived by IKEv2 and leave to future work how IKEv2 generates this key. - Step 2: Use a PRF to generate IV_1, IV_2, ...., IV_n where IV_i is the IV the sender use to encrypt packet i - Step 3: Send your ESP compressed packet (let say here not sending all the bytes of the IV) b) On the receiver side: - Step 1 figuring out which packet is received -- in our case that is packet i - Step 2 find / generate the corresponding IV_i - Step 3 decrypt packet i The goal is to avoid sending IV in each packet that is what we call compression. If you IV is 8 bytes, the compression can be send the least significant last byte, (respectively two last bytes, ... 7 last bytes, the whole IV, or no IV at all). More precisely, we do not consider zipping a random number. The draft does not specify how matching between IV_i and packet i is performed. - 1) you may use the SN as the packet counter. Of course it is easier if the SN increments for each packet. However SN are not part of the IV generation. - 2) you may use the least significant bytes to determine which IV may match. This way of doing so differs in the current way of sending the IV as we do not have the IV from the packet. In our case, the IV is not derived from the packet, we need to generate a few number of IV in advance, and find out which is the one matching a particular packet. Motivation for doing so is that sending a byte in 6lo cost more than doing a few thousand operations. In that sense, we are ready to implement some more complex IV-to-i function. Best Regards, Daniel [1] http://www.ietf.org/proceedings/89/slides/slides-89-tls-2.pdf On Wed, Jul 23, 2014 at 8:16 PM, Stephen Kent wrote: > Daniel, > > I read the very brief IV-generation I-D and I didn't see an explanation of > how > to perform IV "compression." As someone else already noted on the list, an > IV > is carried with each packet to enable decryption of packets that may > arrive out > of order. Thus it's not enough to have each peer use the same PRF and seed > to > generate IVs which are not explicitly transported, because of this > requirement. > Also, if the IV is required to be pesudorandom, there is likely no > opportunity > for compression in the usual sense. Finally, note that the specs for > algorithm > modes like GCM treat the IV as a security critical piece of info, for good > reason. > Thus if one tries to re-use a value such as an ESP sequence number as an > IV, all of > the ESP sequence number generation/management code becomes security > critical wrt > algorithm mode evaluation. This topic was discussed in London in the TLS > WG meeting, > when considering use of Cha-Cha. I can forward the relevant messages and > my slides > if you wish. > > Steve > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7bacc1e47880aa04fef4ffd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The design we had in mind is as follows:
a) On= the sender side:
=C2=A0=C2=A0=C2=A0 - Step 1: Each peer nego= tiate a key:=C2=A0 in the next version we will specify that this key is der= ived by IKEv2 and leave to future work how IKEv2 generates this key.
=C2=A0=C2=A0=C2=A0 - Step 2: Use a PRF to generate IV_1, IV_2, .= ..., IV_n where IV_i is the IV the sender use to encrypt packet i
=C2=A0=C2=A0=C2=A0 - Step 3: Send your ESP compressed packet (le= t say here not sending all the bytes of the IV)

b) On th= e receiver side:
=C2=A0=C2=A0=C2=A0 - Step 1 figuring out whi= ch packet is received -- in our case that is packet i
=C2=A0 =C2=A0 - Step 2 find / generate the corresponding IV_i
=C2=A0=C2=A0=C2=A0 - Step 3 decrypt packet i

The goal is to avoid sending IV in each packet that is what we call compre= ssion. If you IV is 8 bytes, the compression can be send the least signific= ant last byte, (respectively two last bytes, ... 7 last bytes, the whole IV= , or no IV at all). More precisely, we do not consider zipping a random num= ber.

The draft does not specify how matching between IV_i and pac= ket i is performed.=C2=A0
=C2=A0=C2=A0 - 1) you may use the = SN as the packet counter. Of course it is easier if the SN increments for e= ach packet. However SN are not part of the IV generation.
=C2=A0=C2=A0 - 2) you may use the least significant bytes to det= ermine which IV may match.

This way of doing so differs = in the current way of sending the IV as we do not have the IV from the pack= et. In our case, the IV is not derived from the packet, we need to generate= a few number of IV in advance, and find out which is the one matching a pa= rticular packet. Motivation for doing so is that sending a byte in 6lo cost= more than doing a few thousand operations. In that sense, we are ready to = implement some more complex IV-to-i function.
=C2=A0



On Wed, Jul 23, 2014 at 8:16 PM, Stephen Kent <<= a href=3D"mailto:kent@bbn.com" target=3D"_blank">kent@bbn.com> wrote:
Daniel,

I read the very brief IV-generation I-D and I didn't see an explanation= of how
to perform IV "compression." As someone else already noted on the= list, an IV
is carried with each packet to enable decryption of packets that may arrive= out
of order. Thus it's not enough to have each peer use the same PRF and s= eed to
generate IVs which are not explicitly transported, because of this requirem= ent.
Also, if the IV is required to be pesudorandom, there is likely no opportun= ity
for compression in the usual sense. Finally, note that the specs for algori= thm
modes like GCM treat the IV as a security critical piece of info, for good = reason.
Thus if one tries to re-use a value such as an ESP sequence number as an IV= , all of
the ESP sequence number generation/management code becomes security critica= l wrt
algorithm mode evaluation. This topic was discussed in London in the TLS WG= meeting,
when considering use of Cha-Cha. I can forward the relevant messages and my= slides
if you wish.

Steve

_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec



--
Daniel Migault
Orang= e Labs -- Security
+33 6 70 72 69 58
--047d7bacc1e47880aa04fef4ffd4-- From nobody Fri Jul 25 02:39:17 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD46C1B27D3 for ; Fri, 25 Jul 2014 02:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 uLrSEqs0ziqp for ; Fri, 25 Jul 2014 02:39:13 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566661A00FF for ; Fri, 25 Jul 2014 02:39:13 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 51C351A00A3; Fri, 25 Jul 2014 11:39:07 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PegDLiKsdgCF; Fri, 25 Jul 2014 11:38:58 +0200 (CEST) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id C26DF1A00A2; Fri, 25 Jul 2014 11:38:58 +0200 (CEST) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 25 Jul 2014 11:39:00 +0200 Message-ID: <53D225B4.2030508@secunet.com> Date: Fri, 25 Jul 2014 11:39:00 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tero Kivinen References: <20140701161112.18036.94027.idtracker@ietfa.amsl.com> <53B6BA3F.40509@secunet.com> <21452.4707.784185.458764@fireball.kivinen.iki.fi> In-Reply-To: <21452.4707.784185.458764@fireball.kivinen.iki.fi> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/T-74auVrY7FRhmpnYh0ecw9qzaI Cc: ipsec@ietf.org Subject: Re: [IPsec] Last Call: (Signature Authentication in IKEv2) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 09:39:15 -0000 Tero, thanks for updating the document. However, I'm not sure the first issue is solved. Tero Kivinen wrote on 20.07.2014 21:02: > Changed to: > > With RSASSA-PSS, the algorithm object identifier must always > be id-RSASSA-PSS, and the hash function and padding parameters > are conveyed in the parameters (which are not optional in this > case). See for more information. > > In the RSASSA-PSS the parameters are required, but they can be empty, > so they are not optional in this case. > Really? Section 3.1 of RFC 4055 states When RSASSA-PSS is used in an AlgorithmIdentifier, the parameters MUST employ the RSASSA-PSS-params syntax. The parameters may be either absent or present when used as subject public key information. My understanding of this is that the parameters can indeed be absent not just empty. IMHO the semantic is different: If the parameters are empty (empty sequence in RSASSA-PSS-param), the default values apply, and according to Section 3.3, case 3, of RFC 4055, the parameters in a signature MUST be validated against the (default) parameters specified in SPKI. However, if the parameters are absent, then, according to Section 3.3, case 2, of RFC 4055, no parameter validation is needed in a signature validation, i.e. a signature may use any parameters. Maybe, I misinterpret the spec here? -- Johannes From nobody Fri Jul 25 09:26:08 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D141B2925; Fri, 25 Jul 2014 09:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 F3NvwTz_UHfy; Fri, 25 Jul 2014 09:26:03 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A4D1B2962; Fri, 25 Jul 2014 09:26:03 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:51068 helo=dhcp-a77c.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XAiJm-000K2C-Jt; Fri, 25 Jul 2014 12:26:02 -0400 Message-ID: <53D2851A.7020509@bbn.com> Date: Fri, 25 Jul 2014 12:26:02 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniel Migault References: <53CFFBE2.50602@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/UmsfAwnsq83vMlm5Q53L0DYaFY0 Cc: "ipsec@ietf.org" , 6lo@ietf.org Subject: Re: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 16:26:06 -0000 Daniel, Thanks for the explanation. > ... > > The draft does not specify how matching between IV_i and packet i is > performed. > - 1) you may use the SN as the packet counter. Of course it is > easier if the SN increments for each packet. However SN are not part > of the IV generation. which SN? the one from ESP? Doesn't Diet-ESP significantly reduce the sequence number space? if the SN space is small, then there may be ambiguity at the receiver. > - 2) you may use the least significant bytes to determine which IV > may match. > This way of doing so differs in the current way of sending the IV as > we do not have the IV from the packet. In our case, the IV is not > derived from the packet, we need to generate a few number of IV in > advance, and find out which is the one matching a particular packet. This sentence suggests that the least significant bytes above are from the "compressed" IV. Is that right? If the IV is pseudorandom, and it's compressed representation is small, e.g., 2 bytes, what is the likelihood that two IVs will have the same representation, within a receive window of, say 32 packets? (This is a drawing balls from an urn with replacement problem, I think). This might result in a frequency of collision that may be an issue, causing the receiver to have to do crypto processing on colliding packets. > Motivation for doing so is that sending a byte in 6lo cost more than > doing a few thousand operations. In that sense, we are ready to > implement some more complex IV-to-i function. Isn't the "lo" in 6lo, low power? Is it clear that the cycles vs. bandwidth tradeoff is always a win? Steve From nobody Fri Jul 25 09:37:32 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7561B29A5 for ; Fri, 25 Jul 2014 09:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 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, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=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 Vr0j6oqxEW9L for ; Fri, 25 Jul 2014 09:37:25 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6832F1B2989 for ; Fri, 25 Jul 2014 09:37:18 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id u57so4532358wes.24 for ; Fri, 25 Jul 2014 09:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=aqGM0nRHZ9e/A532mLOr0JJauX8v0ziWFoRFcJ9Qsrs=; b=KuS0l45aGsZnz7IVw/SA1kNeSDofQXTA2LigA4/MBkVlUiHOAkRyG3FvUBt8OGMcnY qxAVQMbuxpa8mOI22lteO9RB1Xu0832oYRG0g390KWHb871oCbCRROrM6bzWFm1itC4I 0PyBeHlRrlX0GPcYkgWbOr/6+VkL2F1dJww/anG4iyd5+Teu1XQA1dKkJ9VuJVVgT7KB 7Tw2dwlrzmSy2GRjxufT5pC/9ZLeknF71u5sz8TR5zV5q56l9Ik+AYMbP9XnMYI3XNaB +c8wlPYxKOm2Fa/7dkl9N7TL+S9mT1hPrh9fHVTyUXshiqOtLFvtY7iDm2tw4SO/zAuE ZTLg== X-Received: by 10.194.92.115 with SMTP id cl19mr23495555wjb.29.1406306236294; Fri, 25 Jul 2014 09:37:16 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-182-145-205.red.bezeqint.net. [79.182.145.205]) by mx.google.com with ESMTPSA id ko8sm26588435wjc.11.2014.07.25.09.37.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 09:37:15 -0700 (PDT) Message-ID: <53D287BA.2070104@gmail.com> Date: Fri, 25 Jul 2014 19:37:14 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ipsec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/G0-HeQPlSCyxEq8o0fTi0dARCO4 Subject: [IPsec] Garage door - let's pick a different example X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 16:37:26 -0000 This might sound like a nit, but we have this text in the draft, as a use case for null auth:

"User wants to get some simple action from the remote device. Consider garage door opener: it must authenticate user to open the door, but it is not necessary for the user to authenticate the door opener.  In this case one-way authentication is sufficient."

The problem is, this is an incorrect protocol. Specifically, a MITM (who might be physically located by the kitchen door), could redirect the protocol exchange to a door different from the one I intended to open. Seeing that nothing happens, I will simply press the remote again and open the garage door, too.

This is of course a generic problem, where unauthenticated protocols have unforeseen consequences.

Thanks,
    Yaron
From nobody Fri Jul 25 10:17:05 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCD91A03AC for ; Fri, 25 Jul 2014 10:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 0C7l8bHYOJKG for ; Fri, 25 Jul 2014 10:17:03 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EE431A03A8 for ; Fri, 25 Jul 2014 10:17:02 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id l18so4383701wgh.1 for ; Fri, 25 Jul 2014 10:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=p8y+vNqtVT27Vxp3xGKvarVrDyRCrHyX9tOh7sM75Wc=; b=jH/YO3uKWGW5GTQFYKE9ez21AGIyzlCipJup3y1QUGpqrlWEB0UKgJsjbNhm8U0aoX /Pg/jI7ScRYRc4iwkIKiRfhy20gBoM7qiYIgVyM8JCGs7wmgMiKO/RAU5Q6FuRxue5w2 3s+JJPSgTe0cjQVQF4vWplRZbLJquWRk6FPRapIBWhh9GxfXLA15gpz63Gj8QAgzMys9 QAh37UkSKzN+7xx4ByE/TnCot0ZLd/y/RF/7sTF/j9H36Ly4lZ3eTfTPxgDvDlV3ao3L jUdxEvEHfvlhuHjLqhL1b14lOmEOtF0oImn6vKgCtCCAfufsZaKvRck3J/xbl04HahH8 s/+A== X-Received: by 10.180.221.65 with SMTP id qc1mr3232289wic.28.1406308621296; Fri, 25 Jul 2014 10:17:01 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-177-108-198.red.bezeqint.net. [79.177.108.198]) by mx.google.com with ESMTPSA id ed15sm8165316wic.9.2014.07.25.10.17.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 10:17:00 -0700 (PDT) Message-ID: <53D2910B.4040501@gmail.com> Date: Fri, 25 Jul 2014 20:16:59 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ipsec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/SxOwAnBuFy4d-K1VDiUo5Ne6Mk0 Subject: [IPsec] Puzzles and weak clients X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 17:17:03 -0000 I missed some of the discussion (Meetecho played up again), so maybe there's an easier answer. But I think that mere computational (CPU-hogging) puzzles are not very useful when the attacker (a desktop machine on a botnet) is much more powerful than the legitimate client (a last-year iPhone). And as Mike said, the attacker's resources are cheaper, because he steals them. One way to mitigate this problem is by limiting the competition to "new" clients, those who haven't used the VPN for the last (say) 24 hours. The gateway could hand out time limited, easy to validate, IP-bound cookies to VPN clients. And a VPN client who presents this cookie to the gateway is exempted from the puzzle game (but not from the IKE cookie, because it proves a legitimate source address which is bound to the cookie). And even if we add such a mechanism, we still have the problem of attackers being favored by this proposal, compared to weak legit clients. So maybe puzzles are not a very good idea after all. Thanks, Yaron From nobody Fri Jul 25 12:36:43 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259021A03BE; Fri, 25 Jul 2014 12:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 iG2DKGY82zxg; Fri, 25 Jul 2014 12:36:37 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B911A0195; Fri, 25 Jul 2014 12:36:36 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so1536402wib.16 for ; Fri, 25 Jul 2014 12:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yXKitwRR6yfbiOoeyaXJrHLrC8Q3T9L9Y5f7iHkoOh8=; b=YIqt9L6A9Kkq1fEM8frgkSGB5vpQiJTd1ETvXzX5fKcSJ+bipvpHrI7ikZS6zbpKYf 1a/wKEUpeXJatL4tYfIuqcGJQhDu4gitsDZnP7SEq5ovspMfELfRD1EbRzGcS4Gp1J0v ZRayoPD7LHviZZ+CCB992bcKuITlwAV/kDZmVMDvo+yQ5m/Cr5aZoMg2jdcmeK3GD437 BJkDp0o53b5nyg7oqzWYwFnAG3Kgd6lmuV2Kr0VzhL9OCr+VSkiAvas/qslXKQetR3ud j1e5B7QyASoQfc9uKsselGDY0V3C8FdlP3+ogFe44LGOQG42cpQ5lbzwkrZGKohx5v/r Rm8A== MIME-Version: 1.0 X-Received: by 10.194.60.240 with SMTP id k16mr9615789wjr.0.1406316994902; Fri, 25 Jul 2014 12:36:34 -0700 (PDT) Received: by 10.194.137.67 with HTTP; Fri, 25 Jul 2014 12:36:34 -0700 (PDT) In-Reply-To: <53D2851A.7020509@bbn.com> References: <53CFFBE2.50602@bbn.com> <53D2851A.7020509@bbn.com> Date: Fri, 25 Jul 2014 21:36:34 +0200 Message-ID: From: Daniel Migault To: Stephen Kent Content-Type: multipart/alternative; boundary=047d7bacc1e4ec449a04ff09b090 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY Cc: "ipsec@ietf.org" , 6lo@ietf.org Subject: Re: [IPsec] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 19:36:40 -0000 --047d7bacc1e4ec449a04ff09b090 Content-Type: text/plain; charset=UTF-8 Hi Steve, Thanks for the feed back. Just to clarify the general compression principle: When a field is compressed, it means that the field is not (or partially) sent on the wire. However, the complete field has been used to generate the packet, and the whole field MUST be decompressed by the receiving side to go further. The idea beyond this principle is that we do not want to alterate the security of the (non- compressed) protocol and we want to benefit from the security analyze of the (non- compressed) protocol. In our case the protocol is IPsec/ESP. This means that SN is always the 32 bit Sequence Number of the ESP Packet ( 64 bit if you use Extended Sequence Number). These two sizes are considered for generation of the ICV as well as for the anti replay mechanism as described in RFC4303. The compressed SN is a portion of the SN, that should be enough to help retrieving the whole SN. If your are not able to retrieve the whole SN, then there is little you can do, as the whole SN MUST be retrieve for ICV check/ anti-replay attack. This is the same case for the SPI. The collision has not been documented in the current draft, and you are right we will have to do that. I am not doing the analyze in that mail -- as I want to send the response before the wifi is done-- but I will respond later. Thanks for the suggestion. It is also true that collision involves more computation. However, in the IoT world, computation versus sending is (to some extend of course) always a win. Here is the example I have in mind. - Computing: ranges from 0.5nJ per instruction for extremely energy-efficient microcontrollers (such as CoolRisc or MSP430) to 200 nJ per instruction for high-performance microprocessors (such as ARM9). - Communication: from 100nJ to 1uJ per bit transmitted or received, depending on modulation complexity and transmission power (we only consider "low-power" radios, with transmit powers lower than about 10mW). Roughly speaking, this means that, for the energy cost of exchanging 1 bit, our system can alternatively compute 10-100 instructions. Therefore, there is a high interest in compressing frames before transmitting them Note that if that is not the case in some scenarios, or with some future technologies. As we have the flexibility to define the compression, and as compression does not impact the IPsec processing of the (decompress) packet, one can always redefine the number of bytes to send. BR, Daniel On Fri, Jul 25, 2014 at 6:26 PM, Stephen Kent wrote: > Daniel, > > Thanks for the explanation. > >> ... >> >> >> The draft does not specify how matching between IV_i and packet i is >> performed. >> - 1) you may use the SN as the packet counter. Of course it is easier >> if the SN increments for each packet. However SN are not part of the IV >> generation. >> > which SN? the one from ESP? Doesn't Diet-ESP significantly reduce the > sequence number space? > if the SN space is small, then there may be ambiguity at the receiver. > > - 2) you may use the least significant bytes to determine which IV may >> match. >> This way of doing so differs in the current way of sending the IV as we >> do not have the IV from the packet. In our case, the IV is not derived from >> the packet, we need to generate a few number of IV in advance, and find out >> which is the one matching a particular packet. >> > This sentence suggests that the least significant bytes above are from the > "compressed" > IV. Is that right? If the IV is pseudorandom, and it's compressed > representation is small, > e.g., 2 bytes, what is the likelihood that two IVs will have the same > representation, within > a receive window of, say 32 packets? (This is a drawing balls from an urn > with replacement > problem, I think). This might result in a frequency of collision that may > be an issue, causing > the receiver to have to do crypto processing on colliding packets. > > Motivation for doing so is that sending a byte in 6lo cost more than >> doing a few thousand operations. In that sense, we are ready to implement >> some more complex IV-to-i function. >> > Isn't the "lo" in 6lo, low power? Is it clear that the cycles vs. > bandwidth tradeoff is always > a win? > > Steve > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7bacc1e4ec449a04ff09b090 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Steve,

Thanks fo= r the feed back.

Just to clarify the general compression princ= iple: When a field is compressed, it means that the field is not (or partia= lly) sent on the wire. However, the complete field has been used to generat= e the packet, and the whole field MUST be decompressed by the receiving sid= e to go further. The idea beyond this principle is that we do not want to a= lterate the security of the (non- compressed) protocol and we want to benef= it from the security analyze of the (non- compressed) protocol. In our case= the protocol is IPsec/ESP.

This means that SN is always the 32 bit Sequence Number of the ES= P Packet ( 64 bit if you use Extended Sequence Number). These two sizes are= considered for generation of the ICV as well as for the anti replay mechan= ism as described in RFC4303. The compressed SN is a portion of the SN, that= should be enough to help retrieving the whole SN. If your are not able to = retrieve the whole SN, then there is little you can do, as the whole SN MUS= T be retrieve for ICV check/ anti-replay attack.

This is the same case for the SPI.

The collision has= not been documented in the current draft, and you are right we will have t= o do that. I am not doing the analyze in that mail -- as I want to send the= response before the wifi is done-- but I will respond later. Thanks for th= e suggestion.
=C2=A0
It is also true that = collision involves more computation. However, in the IoT world, computation= versus sending is (to some extend of course) always a win. Here is the exa= mple I have in mind.
=C2=A0=C2=A0=C2=A0 - Computing: ranges from 0.5nJ per instruction for extre= mely energy-efficient microcontrollers (such as CoolRisc or MSP430) to 200 = nJ per instruction for high-performance microprocessors (such as ARM9). =C2=A0=C2=A0=C2=A0 - Communication: from 100nJ to 1uJ per bit transmitted = or received, depending on modulation complexity and transmission power (we = only consider "low-power" radios, with transmit powers lower than= about 10mW).

Roughly speaking, this means that, for the energy cost of exchanging 1 = bit, our system can alternatively compute 10-100 instructions. Therefore, t= here is a high interest in compressing frames before transmitting them

Note that if that is not the case in some sc= enarios, or with some future technologies. As we have the flexibility to de= fine the compression, and as compression does not impact the IPsec processi= ng of the (decompress) packet, one can always redefine the number of bytes = to send.

BR,
Daniel

On Fri, Jul= 25, 2014 at 6:26 PM, Stephen Kent <kent@bbn.com> wrote:
Daniel,

Thanks for the explanation.
...


The draft does not specify how matching between IV_i and packet i is perfor= med.
=C2=A0 =C2=A0- 1) you may use the SN as the packet counter. Of course it is= easier if the SN increments for each packet. However SN are not part of th= e IV generation.
which SN? the one from ESP? Doesn't Diet-ESP significantly reduce the s= equence number space?
if the SN space is small, then there may be ambiguity at the receiver.
=
=C2=A0 =C2=A0- 2) you may use the least significant bytes to determine whic= h IV may match.
This way of doing so differs in the current way of sending the IV as we do = not have the IV from the packet. In our case, the IV is not derived from th= e packet, we need to generate a few number of IV in advance, and find out w= hich is the one matching a particular packet.
This sentence suggests that the least significant bytes above are from the = "compressed"
IV. Is that right? =C2=A0If the IV is pseudorandom, and it's compressed= representation is small,
e.g., 2 bytes, what is the =C2=A0likelihood that two IVs will have the same= representation, within
a receive window of, say 32 packets? (This is a drawing balls from an urn w= ith replacement
problem, I think). This might result in a frequency of collision that may b= e an issue, causing
the receiver to have to do crypto processing on colliding packets.

Motivation for doing so is that sending a byte in 6lo cost more than doing = a few thousand operations. In that sense, we are ready to implement some mo= re complex IV-to-i function.
Isn't the "lo" in 6lo, low power? Is it clear that the cycles= vs. bandwidth tradeoff is always
a win?

Steve



--
Daniel Migault
Orang= e Labs -- Security
+33 6 70 72 69 58
--047d7bacc1e4ec449a04ff09b090-- From nobody Fri Jul 25 13:33:15 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCFC1A03C4 for ; Fri, 25 Jul 2014 13:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 ao42-Fbgfpbi for ; Fri, 25 Jul 2014 13:33:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA801A039C for ; Fri, 25 Jul 2014 13:33:13 -0700 (PDT) Received: from [10.255.247.2] ([207.164.2.187]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s6PKXAJE005615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 25 Jul 2014 13:33:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host [207.164.2.187] claimed to be [10.255.247.2] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <7712BA18-98BB-45F1-8C7C-4A3B255E13CF@vpnc.org> Date: Fri, 25 Jul 2014 16:33:09 -0400 To: IPsec ME WG List Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/uDCmRA1jy-Fkm_di75pZEoGxe6U Subject: [IPsec] Minutes from today's meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 20:33:14 -0000 Posted here: http://www.ietf.org/proceedings/90/minutes/minutes-90-ipsecme Thanks to Jim Schaad for volunteering to be notetaker. --Paul Hoffman From nobody Fri Jul 25 16:07:52 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8411A0402 for ; Fri, 25 Jul 2014 16:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=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 YRIy8Em834Oq for ; Fri, 25 Jul 2014 16:07:47 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 0C13F1A0401 for ; Fri, 25 Jul 2014 16:07:46 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s6PN7gd6004063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 26 Jul 2014 02:07:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s6PN7fEh009376; Sat, 26 Jul 2014 02:07:41 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21458.58173.437081.804657@fireball.kivinen.iki.fi> Date: Sat, 26 Jul 2014 02:07:41 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <53D287BA.2070104@gmail.com> References: <53D287BA.2070104@gmail.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/_huPp7-DGa_f33n6qXYT7a-k5jI Cc: ipsec Subject: [IPsec] Garage door - let's pick a different example X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 23:07:50 -0000 Yaron Sheffer writes: > This might sound like a nit, but we have this text in the draft, as > a use case for null auth: > > "User wants to get some simple action from the remote device. Consider garage > door opener: it must authenticate user to open the door, but it is not > necessary for the user to authenticate the door opener. In this case one-way > authentication is sufficient." > > The problem is, this is an incorrect protocol. Specifically, a MITM (who might > be physically located by the kitchen door), could redirect the protocol > exchange to a door different from the one I intended to open. Seeing that > nothing happens, I will simply press the remote again and open the garage > door, too. > > This is of course a generic problem, where unauthenticated protocols have > unforeseen consequences. No, that is not caused by the unauthenticated protocol, but caused by the same device to be used with two different doors. Even if the device would do full authentication and would verify that the door is in his list of doors which can be opened, attacker could still do the same thing. Only way to get rid of that, would be to either put display on the device telling which door responded, or put multiple buttons to the device and you would have to bind each button to exactly one door (i.e. each button using separate key or shared secret). And, not you do not even need man in the middle in cryptographic sense, just rerouting the packets from the air to the other destination would be enough. So for that kind of uses the devive would need to be tied to exactly one door... -- kivinen@iki.fi From nobody Sat Jul 26 09:58:04 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22231B2864 for ; Sat, 26 Jul 2014 09:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 Jwn-qisuHzYi for ; Sat, 26 Jul 2014 09:58:01 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8210F1B285F for ; Sat, 26 Jul 2014 09:58:01 -0700 (PDT) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s6QGvwbQ047956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 26 Jul 2014 09:58:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <53CAA14C.80301@gmail.com> Date: Sat, 26 Jul 2014 09:57:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53CAA14C.80301@gmail.com> To: IPsecME WG X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/8W8WPXcWQPnap-O8ygwcFimCgq4 Subject: Re: [IPsec] Charter update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 16:58:02 -0000 [[ Another nudge to keep this thread going. If you care about the = charter, please comment. ]] On Jul 19, 2014, at 9:48 AM, Yaron Sheffer = wrote: > IPsec folks, >=20 > Our existing charter (http://tools.ietf.org/wg/ipsecme/charters) is = badly out of date. Below is a proposed charter revision. Please review = and comment on the list. We might also discuss the new charter in the = face-to-face next week. >=20 > Thanks, > Paul and Yaron >=20 >=20 > IP Security Maintenance and Extensions (ipsecme) > ------------------------------------------------ >=20 > Charter >=20 > Current Status: Active >=20 > Chairs: > Paul E. Hoffman > Yaron Sheffer >=20 > Security Area Directors: > Stephen Farrell > Kathleen Moriarty >=20 > Security Area Advisor: > Kathleen Moriarty >=20 > Mailing Lists: > General Discussion: ipsec@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec > Archive: http://www.ietf.org/mail-archive/web/ipsec/ >=20 > Description of Working Group: >=20 > The IPsec suite of protocols includes IKEv1 (RFC 2409 > and associated RFCs), IKEv2 (RFC 5996), and the IPsec > security architecture (RFC 4301). IPsec is widely > deployed in VPN gateways, VPN remote access clients, > and as a substrate for host-to-host, host-to-network, > and network-to-network security. > =20 > The IPsec Maintenance and Extensions Working Group > continues the work of the earlier IPsec Working Group > which was concluded in 2005. Its purpose is to maintain > the IPsec standard and to facilitate discussion of > clarifications, improvements, and extensions to IPsec, > mostly to IKEv2. The working group also serves as a > focus point for other IETF Working Groups who use IPsec > in their own protocols. > =20 > The current work items include: > =20 > Recently discovered incorrect behavior of ISPs poses a > challenge to IKE, whose UDP messages (especially #3 and #4) > sometimes get fragmented at the IP level and then dropped > by these ISPs. There is interest in solving this issue by > allowing transport of IKE over TCP; this is currently > implemented by some vendors. The group will standardize such > a solution. > =20 > The WG will review and revise the list of mandatory-to- > implement algorithms for ESP and AH based on five years of = experience=20 > with newer algorithms and cryptographic modes. > =20 > The WG will revise the IKEv2 specification with a small number > of mandatory tests required for the secure operation of IKEv2 > when using elliptic curve cryptography. This work will be based > on draft-sheffer-ipsecme-dh-checks. >=20 > IKEv2 has had many interoperable implementations and can now be = considered > a mature protocol. The WG will republish the protocol as an = Internet Standard. >=20 > At the time of writing, all the above are in late stages of the = IETF process. > Therefore, the WG will go into low-power mode: it will remain = active as a focal point > for the IPsec community. But it will only take on new work items if = a strong community > interest can be seen. >=20 > This charter will expire in July 2015 (12 months from approval). > If the charter is not updated before that time, the WG will be > closed and any remaining documents revert back to individual > Internet-Drafts. > =20 >=20 > Goals and Milestones: >=20 > Done - IETF Last Call on large scale VPN use cases and requirements > Done - IETF last call on IKE fragmentation solution > Done - IETF last call on new mandatory-to-implement algorithms >=20 > [No current milestones] > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sat Jul 26 10:34:42 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4621A0377 for ; Sat, 26 Jul 2014 10:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 AtnIwF9AA1zX for ; Sat, 26 Jul 2014 10:34:39 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C2A1A031B for ; Sat, 26 Jul 2014 10:34:38 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so2433546wiv.5 for ; Sat, 26 Jul 2014 10:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=oTvhT+bVf6NSZ9X748S9dG/LfeWdFuGk9v4GOs4Vxgo=; b=beEZ7C0xtHRCaJy0BYtJ1z4pV0M7tKl8DiYIkwtAYt2KlgvvcuLvg4vVifT21Fa1Ku wlouKsFYbJr1ruTJhckmkLhUJcQFDThZ1UX2u4ToHTQ/16CNOAX0xn5+v6W5CalMTTHT PMLa/8cz4LMRRUuBTSxuZa8YURjD1/NpDrK4mtVuH0oOCycE2cNxyFMIYtdSXwoOmU9s Hyk58ryndbikROgV0OYet1jesmgPJCxX4ATVz5XQaAMPUt3mqkP1pFPaGXMfNVP1vFbz TGnTf4Gw1lZqnYxLKradAJwhPSy+e2j8wrMji8cM0EGBJw7dpYX/qPGysQsi4x5qQwbq 4bEQ== X-Received: by 10.180.75.17 with SMTP id y17mr14870497wiv.3.1406396077580; Sat, 26 Jul 2014 10:34:37 -0700 (PDT) Received: from [10.0.0.6] (bzq-79-178-15-7.red.bezeqint.net. [79.178.15.7]) by mx.google.com with ESMTPSA id fw4sm9591954wib.19.2014.07.26.10.34.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Jul 2014 10:34:37 -0700 (PDT) Message-ID: <53D3E6AA.9090500@gmail.com> Date: Sat, 26 Jul 2014 20:34:34 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tero Kivinen References: <53D287BA.2070104@gmail.com> <21458.58173.437081.804657@fireball.kivinen.iki.fi> In-Reply-To: <21458.58173.437081.804657@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Pj228t4dG0uVZpqks3i1X8xOBD0 Cc: ipsec Subject: Re: [IPsec] Garage door - let's pick a different example X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 17:34:40 -0000 On 07/26/2014 02:07 AM, Tero Kivinen wrote: > Yaron Sheffer writes: >> This might sound like a nit, but we have this text in the draft, as >> a use case for null auth: >> >> "User wants to get some simple action from the remote device. Consider garage >> door opener: it must authenticate user to open the door, but it is not >> necessary for the user to authenticate the door opener. In this case one-way >> authentication is sufficient." >> >> The problem is, this is an incorrect protocol. Specifically, a MITM (who might >> be physically located by the kitchen door), could redirect the protocol >> exchange to a door different from the one I intended to open. Seeing that >> nothing happens, I will simply press the remote again and open the garage >> door, too. >> >> This is of course a generic problem, where unauthenticated protocols have >> unforeseen consequences. > > No, that is not caused by the unauthenticated protocol, but caused by > the same device to be used with two different doors. Even if the > device would do full authentication and would verify that the door is > in his list of doors which can be opened, attacker could still do the > same thing. > > Only way to get rid of that, would be to either put display on the > device telling which door responded, or put multiple buttons to the > device and you would have to bind each button to exactly one door > (i.e. each button using separate key or shared secret). > > And, not you do not even need man in the middle in cryptographic > sense, just rerouting the packets from the air to the other > destination would be enough. > > So for that kind of uses the device would need to be tied to exactly > one door... > What you're saying is that to secure this system, we need authentication of the device, either at the IKE level or at the application level (plus UI improvements). I agree, and suggest again that this is not a good use case for null or one-way authentication. Thanks, Yaron From nobody Sun Jul 27 11:52:26 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C9B1A03BD; Sat, 26 Jul 2014 13:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 I2pWCRYwuQ25; Sat, 26 Jul 2014 13:28:17 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 E40BA1A03E0; Sat, 26 Jul 2014 13:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s6QKRx5q021403; Sat, 26 Jul 2014 22:27:59 +0200 (CEST) Received: from [10.203.137.29] (unknown [209.226.201.240]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9EA04654; Sat, 26 Jul 2014 22:27:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPad Mail (11D257) In-Reply-To: <53D2851A.7020509@bbn.com> Date: Sat, 26 Jul 2014 16:27:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53CFFBE2.50602@bbn.com> <53D2851A.7020509@bbn.com> To: Stephen Kent Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/3TeiuutGATA3LM0DYgCkslHKtI0 X-Mailman-Approved-At: Sun, 27 Jul 2014 11:52:24 -0700 Cc: "ipsec@ietf.org" , Daniel Migault , "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [IPsec] [6lo] Diet-ESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 20:28:18 -0000 > On 25.07.2014, at 12:26, Stephen Kent wrote: >=20 > Is it clear that the cycles vs. bandwidth tradeoff is always > a win? Practically always. Daniel's numbers were spot on. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 28 02:05:40 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0707D1A032E for ; Mon, 28 Jul 2014 02:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 5fQQg7BI38vg for ; Mon, 28 Jul 2014 02:05:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D6D1A0320 for ; Mon, 28 Jul 2014 02:05:36 -0700 (PDT) Received: from [172.16.254.123] ([80.92.116.212]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MNq4h-1X9CpE0w95-007QTW; Mon, 28 Jul 2014 11:05:31 +0200 Message-ID: <53D6125B.4030509@gmx.net> Date: Mon, 28 Jul 2014 11:05:31 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yaron Sheffer , ipsec References: <53D287BA.2070104@gmail.com> In-Reply-To: <53D287BA.2070104@gmail.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rVcfem09WRdvjjhKu9mSB1et3VHuEIUxw" X-Provags-ID: V03:K0:RY3a0+/+bcdOg8Bi/cB29jMvf36Lh5TpeG1M4kfyRIndKENV+bD 6XTXN8b8APmPys4JHWwYhZeCnRUM4IVsvtxN1phBKAKQgtPdmZIKH8xw0ZhMdyj27LIbFHV Y/xJIkklGG9QGaXfEDhMMN7uk18BX9VrHRWrblwLrIuRZW32QH3t2xwrOvNOAPkcdY2f2EC zyhRRXPqJMY3D5hB/E2UA== Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/NGYi_9FM6ToliaJKyKv7cBdkebk Subject: Re: [IPsec] Garage door - let's pick a different example X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 09:05:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rVcfem09WRdvjjhKu9mSB1et3VHuEIUxw Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yaron, if you further try to implement a prototype for a door opener then you might run into a number of issues, such as * how does the garage opener discover the garage door? * what radio technology are you going to use? * how does the garage door authorize the garage opener? When you then answer all these questions you might realize (as I did) that you neither want to use IPsec there nor even IP. Ciao Hannes PS: I agree with your statement about mutual authentication. On 07/25/2014 06:37 PM, Yaron Sheffer wrote: > This might sound like a nit, but we have this text in the draft, as a > use case for null auth: >=20 > "User wants to get some simple action from the remote device. Consider > garage door opener: it must authenticate user to open the door, but it > is not necessary for the user to authenticate the door opener. In this= > case one-way authentication is sufficient." >=20 > The problem is, this is an incorrect protocol. Specifically, a MITM (wh= o > might be physically located by the kitchen door), could redirect the > protocol exchange to a door different from the one I intended to open. > Seeing that nothing happens, I will simply press the remote again and > open the garage door, too. >=20 > This is of course a generic problem, where unauthenticated protocols > have unforeseen consequences. >=20 > Thanks, > Yaron >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 --rVcfem09WRdvjjhKu9mSB1et3VHuEIUxw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJT1hJbAAoJEGhJURNOOiAti40H/itUeoOP9PYuDNMnleoOYjhy utY8qTPTOb11VXr81+Bar0L2ybrFN+UnVYuLfEUp0SnITCB3SLd1VNi0/+zcVeFo RnL5SKuaUo6WcmhkVO09OYb3EEiMjZuThFtqd1/PTVw4SAVLLF01HKRQUVRqbttr CyOas7UNe8EFlJzI268W1NlgpHUx7su9KXkgP5YHc5gqwzwfux8idO/DfCdDszNN o3A6IdB2yx6mqpFTYrZL93uOrCZq7neeQfjrySAEQ9GUhKPj1v9yll9qKBlCVtFr gkNeswGJe44DSyGuTV1Q3MG6XpKY6TZdj8NWanTQeHQ2NWERReME6jp1kMtEJzM= =TFg5 -----END PGP SIGNATURE----- --rVcfem09WRdvjjhKu9mSB1et3VHuEIUxw-- From nobody Mon Jul 28 03:46:40 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05CA1A0108 for ; Mon, 28 Jul 2014 03:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 oBmH6rXsVFGB for ; Mon, 28 Jul 2014 03:46:36 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC05D1A020A for ; Mon, 28 Jul 2014 03:46:35 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id n3so4047226wiv.2 for ; Mon, 28 Jul 2014 03:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/RmL+al5vqAzlhx+XZN6bmRquoDdcl6fcsitrKqKU9s=; b=vlDvwQxdUmqZlh6hLel13XjGocQCHYivLluzzzYSD+vOyVdgn6DdrpskyCB0pEMM9Y 9V1DEPMxY1crOD1/yND5RFkE7N3wAOEegfIUBqnQmLwRGEnT8dXXv78BrXAAVI4pYVl2 fbflFgcPb8+Aqzz15dZPPMdbUxH/PaX9RyArA5bXcCHeHu/4eVVWeWn+lNK4Z3T+T9s9 qCDv2k838rqHK/p63V2nDyrIXc11luty5ZGUNErH+dtliEyDqZpzd/bnfTXAF8j7y6A6 f4jp0FHB+NBuwj0TTDzLyUkX4+12Jp8QT+vQUz4eBQeqWRyAewq1oyc7lRnGnQl4k/KH n4TA== X-Received: by 10.194.9.1 with SMTP id v1mr10434563wja.128.1406544392794; Mon, 28 Jul 2014 03:46:32 -0700 (PDT) Received: from [172.24.248.227] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id df1sm30049952wib.4.2014.07.28.03.46.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 03:46:32 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <53D6125B.4030509@gmx.net> Date: Mon, 28 Jul 2014 13:46:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <782DD2E2-9691-42A3-8D7F-5EF6268D98EB@gmail.com> References: <53D287BA.2070104@gmail.com> <53D6125B.4030509@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Qx0fQVr6gSZlBOPEokbXnEM-tgs Cc: ipsec Subject: Re: [IPsec] Garage door - let's pick a different example X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 10:46:38 -0000 Hi Hannes I tend to agree. The beauty of IP (with or without =93sec=94) is that I = can open a connection in one place to a server that is located in = another location half-way around the world. The garage door opener is = used from a short distance, so you don=92t really need routing. You = still might want to use IP, if only because IP-supporting equipment is = so ubiquitous. I would have liked it if we could use some zeroconf = protocol for discovering the garage door, but just because the opener is = physically close to the garage door does not mean that it is = topologically close on the Internet. So the best IP-based way is to = register the garage door in DNS (garagedoor.yaronshouse.org), and then = HTTPS works at least as well as HTTP over IPsec. All this underlines Yaron=92s claim that we need a better example for a = use case for NULL auth. Yoav BTW: my local police station has an electrically-operated gate to the = parking lot where the patrol cars are parked. It=92s opened remotely by = calling a particular phone number. The gate answers, immediately hangs = up, and opens. This is pretty bad, because a phone number is a terribly = short shared secret. On Jul 28, 2014, at 12:05 PM, Hannes Tschofenig = wrote: > Hi Yaron, >=20 > if you further try to implement a prototype for a door opener then you > might run into a number of issues, such as >=20 > * how does the garage opener discover the garage door? > * what radio technology are you going to use? > * how does the garage door authorize the garage opener? >=20 > When you then answer all these questions you might realize (as I did) > that you neither want to use IPsec there nor even IP. >=20 > Ciao > Hannes >=20 > PS: I agree with your statement about mutual authentication. >=20 > On 07/25/2014 06:37 PM, Yaron Sheffer wrote: >> This might sound like a nit, but we have this text in the draft, as a >> use case for null auth: >>=20 >> "User wants to get some simple action from the remote device. = Consider >> garage door opener: it must authenticate user to open the door, but = it >> is not necessary for the user to authenticate the door opener. In = this >> case one-way authentication is sufficient." >>=20 >> The problem is, this is an incorrect protocol. Specifically, a MITM = (who >> might be physically located by the kitchen door), could redirect the >> protocol exchange to a door different from the one I intended to = open. >> Seeing that nothing happens, I will simply press the remote again and >> open the garage door, too. >>=20 >> This is of course a generic problem, where unauthenticated protocols >> have unforeseen consequences. >>=20 >> Thanks, >> Yaron >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jul 28 08:16:32 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAC71A0298 for ; Mon, 28 Jul 2014 08:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.433 X-Spam-Level: X-Spam-Status: No, score=0.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=2, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 ggGkxAslgtg2 for ; Mon, 28 Jul 2014 08:16:28 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.59.3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BF21B28A0 for ; Mon, 28 Jul 2014 08:16:27 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id CF001233DFF33; Mon, 28 Jul 2014 10:16:26 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 98C66233DFE18 for ; Mon, 28 Jul 2014 10:16:26 -0500 (CDT) Received: from [96.231.227.95] (port=52159 helo=192.168.1.6) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XBmf3-0003GF-Mk; Mon, 28 Jul 2014 10:16:25 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <53CAA14C.80301@gmail.com> Date: Mon, 28 Jul 2014 11:16:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <004816EB-6342-435E-A9FA-AA0E8FEEA843@ieca.com> References: <53CAA14C.80301@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.227.95 X-Exim-ID: 1XBmf3-0003GF-Mk X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.6) [96.231.227.95]:52159 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/UM3t4ZbHMbTGyuODFs2InHe63ZQ Cc: IPsecME WG Subject: Re: [IPsec] Charter update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 15:16:30 -0000 On Jul 19, 2014, at 12:48, Yaron Sheffer wrote: > IPsec folks, >=20 > Our existing charter (http://tools.ietf.org/wg/ipsecme/charters) is = badly out of date. Below is a proposed charter revision. Please review = and comment on the list. We might also discuss the new charter in the = face-to-face next week. I don=92t think a revised charter is needed to strike the references to = ADVPN as well as extend the window to adopt new wg items by six more = months. There=92s an existing time-out in the charter (January 2015) = and if nothing is adopted by the existing time-out I think the WG should = close - assuming of course all of the existing drafts have been = published as RFCs. =20 Obviously, If the wg is closed the mailing list should remain open to = provide a place for the community to discuss ipsec-related issues and a = place for ADs to ask about AD-sponsored drafts. If a re-charter does proceed, two things: 1) I can see extending the time-out if you=92re adding new work items = during this recharter not if you=92re removing references to work items. = I=92d suggest that January 2015 remain as the time-out date. 2) I=92d tweak the following a bit to lead more with the current state = of affairs: OLD: > The current work items include: > =20 > Recently discovered incorrect behavior of ISPs poses a > challenge to IKE, whose UDP messages (especially #3 and #4) > sometimes get fragmented at the IP level and then dropped > by these ISPs. There is interest in solving this issue by > allowing transport of IKE over TCP; this is currently > implemented by some vendors. The group will standardize such > a solution. > =20 > The WG will review and revise the list of mandatory-to- > implement algorithms for ESP and AH based on five years of = experience=20 > with newer algorithms and cryptographic modes. > =20 > The WG will revise the IKEv2 specification with a small number > of mandatory tests required for the secure operation of IKEv2 > when using elliptic curve cryptography. This work will be based > on draft-sheffer-ipsecme-dh-checks. >=20 > IKEv2 has had many interoperable implementations and can now be = considered > a mature protocol. The WG will republish the protocol as an = Internet Standard. >=20 > At the time of writing, all the above are in late stages of the = IETF process. > Therefore, the WG will go into low-power mode: it will remain = active as a focal point > for the IPsec community. But it will only take on new work items if = a strong community > interest can be seen. >=20 > This charter will expire in July 2015 (12 months from approval). > If the charter is not updated before that time, the WG will be > closed and any remaining documents revert back to individual > Internet-Drafts. NEW: The WG has progressed the following documents to the IESG for = publication and will remain open until these drafts are published as = RFCs or this charter is revised to add new work items: draft-ietf-ipsecme-esp-ah-reqts: Revises the list of mandatory-to-implement algorithms for ESP and AH based on five years of experience with newer algorithms and cryptographic modes. draft-ietf-ipsecme-ikev2-fragmentation: Performs fragmentation of large messages by IKEv2 itself, replacing them by series of smaller messages. draft-kivinen-ipsecme-ikev2-rfc5996bis: Republishes the protocol as an Internet Standard because the protocol is now a mature protocol. draft-kivinen-ipsecme-signature-auth: Revises the IKEv2 specification with a small number of mandatory tests required for the secure operation of IKEv2 when using elliptic curve cryptography. This charter expires in January 2015. If the charter is not updated = before that time to add new WG items, the WG will be closed. New work = items will be adopted only if there if there is strong community support = can be demonstrated. In the event of closure, the WG will request that = the mailing remain open to act a focal point for the IPsec community. spt= From nobody Mon Jul 28 08:49:00 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35761A02EB for ; Mon, 28 Jul 2014 08:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 PsgqOYd8W9MJ for ; Mon, 28 Jul 2014 08:48:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707461B28E0 for ; Mon, 28 Jul 2014 08:48:19 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M8ehf-1WGNHu37aN-00wAWv; Mon, 28 Jul 2014 17:48:17 +0200 Message-ID: <53D670C2.1060203@gmx.net> Date: Mon, 28 Jul 2014 17:48:18 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Yoav Nir References: <53D287BA.2070104@gmail.com> <53D6125B.4030509@gmx.net> <782DD2E2-9691-42A3-8D7F-5EF6268D98EB@gmail.com> In-Reply-To: <782DD2E2-9691-42A3-8D7F-5EF6268D98EB@gmail.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2whF3gH5BcE4D8KgOkjxilxf7LwQup7C5" X-Provags-ID: V03:K0:NR6wZcTDQ8Ibg3MOoqQpM77nXJBLqBF8K0ralE07+PVhxslU33g D2mRFWuolMvhunDLnosjy8NPa9drbEJnwANtIiQDD78qx2Kw8GLlEuIk5YSYia03Knu96gE 4ot1cgGMvUlA7W/IbEqWPAyrOnRaaa/ZpVFBEqn+OryNxG6MBVYGyIWLowB0JoqDvTYpy5G JulhpNLsAG6fj2jheXN4g== Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/KVFLA9XLwnu-xXXrwTd4lbGf6kw Cc: ipsec Subject: Re: [IPsec] Garage door - let's pick a different example X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 15:48:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2whF3gH5BcE4D8KgOkjxilxf7LwQup7C5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Yoav, On 07/28/2014 12:46 PM, Yoav Nir wrote: > Hi Hannes >=20 > I tend to agree. The beauty of IP (with or without =93sec=94) is that I= > can open a connection in one place to a server that is located in > another location half-way around the world. The garage door opener is > used from a short distance, so you don=92t really need routing. Good observation! > You > still might want to use IP, if only because IP-supporting equipment > is so ubiquitous. For the use cases we are talking about it is not ubiquitous at all. We only just see the first products offering IP-based services in that area and they are using IP for an entirely different purpose, namely to connect the garage door to some cloud-based service to allow a owner of the garage to check (via his smart phone) whether it is open (or potentially to open it from remote). > I would have liked it if we could use some zeroconf > protocol for discovering the garage door, but just because the opener > is physically close to the garage door does not mean that it is > topologically close on the Internet. It turns out that there are various ways to discover the garage door and to control it using all sorts of application layer protocols but all this adds is delay and complexity with no additional value in this case. > So the best IP-based way is to > register the garage door in DNS (garagedoor.yaronshouse.org), and > then HTTPS works at least as well as HTTP over IPsec. HTTPS works pretty well. >=20 > All this underlines Yaron=92s claim that we need a better example for a= > use case for NULL auth. All we are doing here is to add new options, don't explain enough to allow others (like developers) to figure out how this stuff is supposed to work. What I am trying to do is to look at design patterns and try to help developers make their life easier. It is already difficult enough because we often leave half-baked building blocks around that do not help to build interoperable solutions. This work on IPsec for constrained devices does not help me at all to get anywhere closer to that goal. Ciao Hannes >=20 > Yoav >=20 > BTW: my local police station has an electrically-operated gate to the > parking lot where the patrol cars are parked. It=92s opened remotely by= > calling a particular phone number. The gate answers, immediately > hangs up, and opens. This is pretty bad, because a phone number is a > terribly short shared secret. The use of cellular radio technology might have impacted their design decisions. I don't know what other design decisions they had to deal with. It is hard to say whether the use of IPsec would be any better or whether they should just use CoAP over DTLS based on the profiles we have been working on in DICE. >=20 > On Jul 28, 2014, at 12:05 PM, Hannes Tschofenig > wrote: >=20 >> Hi Yaron, >>=20 >> if you further try to implement a prototype for a door opener then >> you might run into a number of issues, such as >>=20 >> * how does the garage opener discover the garage door? * what radio >> technology are you going to use? * how does the garage door >> authorize the garage opener? >>=20 >> When you then answer all these questions you might realize (as I >> did) that you neither want to use IPsec there nor even IP. >>=20 >> Ciao Hannes >>=20 >> PS: I agree with your statement about mutual authentication. >>=20 >> On 07/25/2014 06:37 PM, Yaron Sheffer wrote: >>> This might sound like a nit, but we have this text in the draft, >>> as a use case for null auth: >>>=20 >>> "User wants to get some simple action from the remote device. >>> Consider garage door opener: it must authenticate user to open >>> the door, but it is not necessary for the user to authenticate >>> the door opener. In this case one-way authentication is >>> sufficient." >>>=20 >>> The problem is, this is an incorrect protocol. Specifically, a >>> MITM (who might be physically located by the kitchen door), could >>> redirect the protocol exchange to a door different from the one I >>> intended to open. Seeing that nothing happens, I will simply >>> press the remote again and open the garage door, too. >>>=20 >>> This is of course a generic problem, where unauthenticated >>> protocols have unforeseen consequences. >>>=20 >>> Thanks, Yaron >>>=20 >>>=20 >>> _______________________________________________ IPsec mailing >>> list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec >>>=20 >>=20 >> _______________________________________________ IPsec mailing list=20 >> IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec >=20 --2whF3gH5BcE4D8KgOkjxilxf7LwQup7C5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJT1nDDAAoJEGhJURNOOiAtZ0AH/3aJ0aqkHmnWZ1/ZBO5LeDp9 C5CJqnjPdq6QSHYGxlNT/8UiL44UCPipNBc5Cg3FLrMoDAEkvQ6G2MTaqnxQR1M+ lqbvfVdlIuaStTEE97iHt3Djzkw3xsgbv9E2MA+2FuyAbaEw41z/33xcaKE1heYt eGUq4M33Xzo+/kXlsZMFUBWF1ms6WPk2TFsYpofuEboml+xZglCwwHkl0HA7h8/3 rGMDgu4v2q1te8i6eerhPexfz5Lmdisp9dBdjGa2Q2XCOtQ16JCKLUSiJe4tEYfb pbPh6dvNRWChVito2oIwK/+j/VPhB2qhk+vb99O59X05uT4+3EkSBsHGQectPTk= =Q6RZ -----END PGP SIGNATURE----- --2whF3gH5BcE4D8KgOkjxilxf7LwQup7C5-- From nobody Mon Jul 28 10:20:43 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9211A044F for ; Mon, 28 Jul 2014 10:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 5p2kuNdc6cGa for ; Mon, 28 Jul 2014 10:20:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FCFC1A01AA for ; Mon, 28 Jul 2014 10:20:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 05EBE20029 for ; Mon, 28 Jul 2014 13:22:12 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 09F6A63B0E; Mon, 28 Jul 2014 13:20:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E5DB863B09 for ; Mon, 28 Jul 2014 13:20:12 -0400 (EDT) From: Michael Richardson To: IPsecME WG In-Reply-To: References: <53CAA14C.80301@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.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 Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/CXgY4g31EuBLPyBZdZPTW9Wk3PI Subject: Re: [IPsec] Charter update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 17:20:34 -0000 --=-=-= Paul Hoffman wrote: >> Recently discovered incorrect behavior of ISPs poses a challenge to >> IKE, whose UDP messages (especially #3 and #4) sometimes get >> fragmented at the IP level and then dropped by these ISPs. There is >> interest in solving this issue by allowing transport of IKE over TCP; >> this is currently implemented by some vendors. The group will >> standardize such a solution. I think that we gave up over TCP, and have back to fragmentation inside IKE, right? >> The WG will revise the IKEv2 specification with a small number of >> mandatory tests required for the secure operation of IKEv2 when using >> elliptic curve cryptography. This work will be based on >> draft-sheffer-ipsecme-dh-checks. I think we already completed this? >> Goals and Milestones: >> >> Done - IETF Last Call on large scale VPN use cases and requirements >> Done - IETF last call on IKE fragmentation solution Done - IETF last >> call on new mandatory-to-implement algorithms Seems like we should have more milestones listed. I'd like to make the puzzle solving work charter. I imagine that this is a real problem, but I wouldn't mind some data on how often gateways are being DDoSed. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU9aGSoCLcPvd0N1lAQJj3gf+MrHQxRsry2NOPtUHWeaMXBOMRoIF8DQq SGUsHWSMkBqUVbP/yogLOTDDGMCaXbix8ZxDu46SRM3jezEQF7ZwYCk98e9HBy9n BoIT+5DhknePIATjM89xx9G1E1iTUynZHEPiUfTIz4Ckkuuyiz4Kt2u8A9mQujum 87Cl5pPhp4aMtWtfdDKYWeiqSFe/Oo4hcujJdj/7FFdzFrbRS0XHdyXHrs5J3WoW 4kqcCFXjIPUsxt/5rV2Vr2P1QIh5igvpA37+87OiaPeFEfx65au93e4ia8G0919w 2/vXwe2EHfVlpbbm1sFQDFrAWVyJQ7HVpuavnLl3j7D44Xe/DS3pgw== =W867 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 30 07:45:41 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994BE1A014A for ; Wed, 30 Jul 2014 07:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.707 X-Spam-Level: X-Spam-Status: No, score=0.707 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=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 Ah_9a1Tqyq6e for ; Wed, 30 Jul 2014 07:45:38 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA831A00A7 for ; Wed, 30 Jul 2014 07:45:38 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id w62so1320154wes.8 for ; Wed, 30 Jul 2014 07:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=eAEMRG3JXknvVmVO+f6JMOvEm5vbyiwSnXN2lMQHN8s=; b=akQa2+Ah7fKBjCf4R7C3PhWJHJlhHu+Nxo3j3EhSko9nw4E8s+wDvk3MAME1mOSN1L jKQMskhnhJom3Q/oV7NOHBkLCi+Sw2hbwY+wl1alHbfrOGo/3pzEA585HOhqDHNHnWxf u4IdxOQQp2IItIui+rervIHU2gNsEycLabxHlfYZ6EAOl9pikp5I17T7HgGfJOTsa8sk WmcZO2zkBJ++6TPsLL8kLyV6mgvOaiWoXCNGW8MvkX6F8iX6l5Uatf9nbRk0vhFJJbxu 35iPSsedptxhHvjAqbf/KhmoYYR8loSPYynZz0h7OEmBKV/ZUEa885N2Hc5ScFHK9vck iKUg== X-Received: by 10.180.98.196 with SMTP id ek4mr6745357wib.13.1406731536736; Wed, 30 Jul 2014 07:45:36 -0700 (PDT) Received: from [172.24.248.227] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id ge8sm6767079wib.4.2014.07.30.07.45.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 07:45:35 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_94966014-6ED8-4186-A4DD-1D179CEC35B7" Message-Id: Date: Wed, 30 Jul 2014 17:45:34 +0300 To: ipsec Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/3vTrBpFRRvmsTovL_OrjbuFUVDY Subject: [IPsec] Puzzles draft - another idea X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 14:45:39 -0000 --Apple-Mail=_94966014-6ED8-4186-A4DD-1D179CEC35B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi all After the meeting on Friday, I talked to Tero and Brian Weis, and Tero = suggested a different sort of puzzle that could make it easier to = support both strong and weak clients. This is sort of like the = proof-of-work used by BitCoin. Calculate the cookie as before. For an example, let=92s assume the = cookie is fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets). A =93legacy=94 initiator will return this exact cookie. A newer initiator will return the cookie, with some extra bytes.=20 The =93value=94 of a returned cookie is determined by the number of = trailing zero bits in the SHA-256 hash of the transmitted cookie: Cookie || extra data hash # trailing zero bits fdbcfa5a430d7201282358a2a034de0013cfe2ae ec2f327dae577a31152e3de2ac0f2f798e21f02e1afb04d33ff79bdd5d30eede 1 fdbcfa5a430d7201282358a2a034de0013cfe2ae0182 71d3e8c09fbb8db5315e6364dce3ebd56ad35c96e284296e2ffffa256bdfa800 11 fdbcfa5a430d7201282358a2a034de0013cfe2ae022b3d 3b4bdf201105e059e09f65219021738b8f6a148896b2e1be2fdc726aeb6e0000 17 fdbcfa5a430d7201282358a2a034de0013cfe2ae0aa679 c352e914a41615496e3498e5ecb87b992be1ad40620f48af85428996c1f00000 20 fdbcfa5a430d7201282358a2a034de0013cfe2ae5c2880 155319280d687074d0f78511f63c77c568a5418dd44e6467d8fc37723d800000 23 fdbcfa5a430d7201282358a2a034de0013cfe2ae022bffc8 6469faf4455cf9a51b04edeea8195f27771d56b95f2d874764a71e2948000000 27 Initiators are limited (by the construction of the cookie) in the amount = of time they can spend. So powerful clients will manage 23 bits, while = weaker clients will only manage 17. When an Initial request arrives with a cookie, first the first 20 bytes = are validated, and then the result is queued by =93value=94.=20 When the responder can handle a packet (has room in the half-open SA = table) it processes the entry with the highest value in the queue. = Entries expire after some time even if not handled. I think if this algorithm is chosen, an attacker can still expend little = effort, get some 5-6 bits, and use that to push out all legacy clients. = We could counter that by having a minimum threshold at something like = 10-12 bits, some value that all supported platforms can easily manage in = under 0.5 seconds, and consider all values below that to be equal to = zero (not enough effort to matter). This could get some more tweaks. But what do people think of this? Thanks Yoav P.S. This is the first time I tried to send a table pasted into Apple = Mail to a mailing list. I apologize in advance if it comes out looking = horrific. --Apple-Mail=_94966014-6ED8-4186-A4DD-1D179CEC35B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = all

After the meeting on Friday, I talked to Tero and = Brian Weis, and Tero suggested a different sort of puzzle that could = make it easier to support both strong and weak clients. This is sort of = like the proof-of-work used by BitCoin.

  1. Calculate the cookie as before. For an = example, let=92s assume the cookie is fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 = octets).
  2. A =93legacy=94 initiator will return this exact = cookie.
  3. A newer initiator will return the cookie, with some = extra bytes. 
  4. The =93value=94 of a returned cookie is = determined by the number of trailing zero bits in the SHA-256 hash of = the transmitted cookie:

    Cookie || extra data
    hash
    # trailing zero bits
    fdbcfa5a430d7201282358a2a034de0013cfe2ae
    ec2f327dae577a31152e3de2ac0f2f798e21f02e1afb04d33ff79bdd5d30eede
    1
    fdbcfa5a430d7201282358a2a034de0013cfe2ae0182
    71d3e8c09fbb8db5315e6364dce3ebd56ad35c96e284296e2ffffa256bdfa800
    11
    fdbcfa5a430d7201282358a2a034de0013cfe2ae022b3d
    3b4bdf201105e059e09f65219021738b8f6a148896b2e1be2fdc726aeb6e0000
    17
    fdbcfa5a430d7201282358a2a034de0013cfe2ae0aa679
    c352e914a41615496e3498e5ecb87b992be1ad40620f48af85428996c1f00000
    20
    fdbcfa5a430d7201282358a2a034de0013cfe2ae5c2880
    155319280d687074d0f78511f63c77c568a5418dd44e6467d8fc37723d800000
    23
    fdbcfa5a430d7201282358a2a034de0013cfe2ae022bffc8
    6469faf4455cf9a51b04edeea8195f27771d56b95f2d874764a71e2948000000
    27

  5. Initiators are limited (by the construction of = the cookie) in the amount of time they can spend. So powerful clients = will manage 23 bits, while weaker clients will only manage = 17.
  6. When an Initial request arrives with a cookie, first the = first 20 bytes are validated, and then the result is queued by = =93value=94. 
  7. When the responder can handle a packet (has = room in the half-open SA table) it processes the entry with the highest = value in the queue. Entries expire after some time even if not = handled.

I think if this algorithm is = chosen, an attacker can still expend little effort, get some 5-6 bits, = and use that to push out all legacy clients. We could counter that by = having a minimum threshold at something like 10-12 bits, some value that = all supported platforms can easily manage in under 0.5 seconds, and = consider all values below that to be equal to zero (not enough effort to = matter).

This could get some more tweaks. But = what do people think of = this?

Thanks

Yoav
<= div>
P.S. This is the first time I tried to send a table = pasted into Apple Mail to a mailing list. I apologize in advance if it = comes out looking horrific.

= --Apple-Mail=_94966014-6ED8-4186-A4DD-1D179CEC35B7-- From nobody Wed Jul 30 10:14:26 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBCB1A0300 for ; Wed, 30 Jul 2014 10:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 eR4eDJtbWepx for ; Wed, 30 Jul 2014 10:14:17 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C421A02DE for ; Wed, 30 Jul 2014 10:14:17 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lf10so1889976pab.29 for ; Wed, 30 Jul 2014 10:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gk092HNx+nUDVoMSq+33klhnu0T2LBnwxorBiyPqX9o=; b=Md4BMTe1UlZUv8j/yEnGcvkZpYa3HZwIu9dcB9k06SHKxCUkfB8Rab8x258J5IZ1o4 ULveUYEVEKcG2NVEPJ3wvEExAa1P3/rNV1bcpS/4VcsW6VlWLwFFDfdykQZnMbt/IF25 tbRpwf96cHVeeUpDo6sr1z2/tnQ2ORedWgpfbpFwi28+yhCm9ESj9sw6dhzvEP660N29 WGIf4rakQQ2Re7qYJ2qNtUBo0dAMR28r4IuYCTmW4NfZ6s7gPQm4UeKCZWPp+Lt5aNPh 2pTllxPtcImEjWNpTlllPhrX6EnFE2S7WTBbg2vTEnioFoI0hWjU/vrG63/2QwJRdyer aF1g== X-Received: by 10.68.130.38 with SMTP id ob6mr6293934pbb.141.1406740456964; Wed, 30 Jul 2014 10:14:16 -0700 (PDT) Received: from [172.17.55.209] ([12.0.207.18]) by mx.google.com with ESMTPSA id v1sm2915507pbs.1.2014.07.30.10.14.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jul 2014 10:14:15 -0700 (PDT) Message-ID: <53D911DD.1000801@gmail.com> Date: Wed, 30 Jul 2014 08:40:13 -0700 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Yoav Nir , ipsec References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/_6PQUCjMfae8sn3Pha5jJsoKF_o Subject: Re: [IPsec] Puzzles draft - another idea X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 17:14:22 -0000 Hi Yoav, this is a nice idea, but I think it actually performs worse than the baseline. With the previous solution all clients had to expend the same number of cycles, but would be served FCFS so from time to time, the "good" ones would be served. With this proposal the attacker can push out the legitimate weak clients in a *deterministic* way. If I know all Check Point iPhone clients do 10 bits (I assume most implementations will choose a value and stick to it, because they do not have any information about the effort currently needed), I will configure my botnet to always do 11, and push out any legitimate clients. Thanks, Yaron On 07/30/2014 07:45 AM, Yoav Nir wrote: > Hi all > > After the meeting on Friday, I talked to Tero and Brian Weis, and Tero > suggested a different sort of puzzle that could make it easier to > support both strong and weak clients. This is sort of like the > proof-of-work used by BitCoin. > > 1. Calculate the cookie as before. For an example, let’s assume the > cookie is fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets). > 2. A “legacy” initiator will return this exact cookie. > 3. A newer initiator will return the cookie, with some extra bytes. > 4. The “value” of a returned cookie is determined by the number of > trailing zero bits in the SHA-256 hash of the transmitted cookie: > > Cookie || extra data > > hash > > # trailing zero bits > fdbcfa5a430d7201282358a2a034de0013cfe2ae > > ec2f327dae577a31152e3de2ac0f2f798e21f02e1afb04d33ff79bdd5d30eede > > 1 > fdbcfa5a430d7201282358a2a034de0013cfe2ae0182 > > 71d3e8c09fbb8db5315e6364dce3ebd56ad35c96e284296e2ffffa256bdfa800 > > 11 > fdbcfa5a430d7201282358a2a034de0013cfe2ae022b3d > > 3b4bdf201105e059e09f65219021738b8f6a148896b2e1be2fdc726aeb6e0000 > > 17 > fdbcfa5a430d7201282358a2a034de0013cfe2ae0aa679 > > c352e914a41615496e3498e5ecb87b992be1ad40620f48af85428996c1f00000 > > 20 > fdbcfa5a430d7201282358a2a034de0013cfe2ae5c2880 > > 155319280d687074d0f78511f63c77c568a5418dd44e6467d8fc37723d800000 > > 23 > fdbcfa5a430d7201282358a2a034de0013cfe2ae022bffc8 > > 6469faf4455cf9a51b04edeea8195f27771d56b95f2d874764a71e2948000000 > > 27 > > > 5. Initiators are limited (by the construction of the cookie) in the > amount of time they can spend. So powerful clients will manage 23 > bits, while weaker clients will only manage 17. > 6. When an Initial request arrives with a cookie, first the first 20 > bytes are validated, and then the result is queued by “value”. > 7. When the responder can handle a packet (has room in the half-open SA > table) it processes the entry with the highest value in the queue. > Entries expire after some time even if not handled. > > > I think if this algorithm is chosen, an attacker can still expend little > effort, get some 5-6 bits, and use that to push out all legacy clients. > We could counter that by having a minimum threshold at something like > 10-12 bits, some value that all supported platforms can easily manage in > under 0.5 seconds, and consider all values below that to be equal to > zero (not enough effort to matter). > > This could get some more tweaks. But what do people think of this? > > Thanks > > Yoav > > P.S. This is the first time I tried to send a table pasted into Apple > Mail to a mailing list. I apologize in advance if it comes out looking > horrific. > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Wed Jul 30 11:45:25 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1601A0179 for ; Wed, 30 Jul 2014 11:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 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, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=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 4_GpdWl6oMqU for ; Wed, 30 Jul 2014 11:45:19 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2F31A016B for ; Wed, 30 Jul 2014 11:45:18 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id bs8so2860669wib.14 for ; Wed, 30 Jul 2014 11:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=s44csrxFtJfLqSfJfafPeqoJfPXRfJTKvyMLcaPf5Z4=; b=Mgf6ZSAXcv0lpCOl22I5pq0n9TZgXSjnRGUeFbtqhswt4gxCdP5wPAKMw7iu9aFIE+ aacdtBYR7NZ4KXnp2BOKHkQuayZ4DAR1BeHaC95Yc1B6IPlt8Fr8exvsELuxbxgT07Qh VC2IJt6A76au5bmGpy5rpwHjGVmrILOr0cNnclklVp8/16vJ/pKTAYW031FkzxAELVM9 2D+5h7UOGSTU43b+vAV5Do88gCuy1OthBt0YyVGHVUduzr3173Z0TXyu/tytA56XKUvb V/MXz9DyhU5oIXFfx5neC8T9aXk59yfEV0IQy6uuM23RCFbpGxgnL3g6uabtqrXBA688 /hpg== X-Received: by 10.194.92.115 with SMTP id cl19mr8985348wjb.29.1406745917632; Wed, 30 Jul 2014 11:45:17 -0700 (PDT) Received: from [192.168.1.104] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id je3sm12427233wic.11.2014.07.30.11.45.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 11:45:16 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_144C8D5D-97DE-4049-9545-9AFAAEB5620B" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <53D911DD.1000801@gmail.com> Date: Wed, 30 Jul 2014 21:45:13 +0300 Message-Id: <91340EE3-3DF4-4665-B21A-A108D00ADDE6@gmail.com> References: <53D911DD.1000801@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-L-DavLfddzQBdFwtIWXUaeQoqg Cc: ipsec Subject: Re: [IPsec] Puzzles draft - another idea X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 18:45:21 -0000 --Apple-Mail=_144C8D5D-97DE-4049-9545-9AFAAEB5620B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Yaron Suppose our half-open SA table can hold 100,000 entries and we clear = them out after 10 seconds. That allows 10,000 entries per second. More = realistic number are 18 bits for the iPhone and 20 bits for the = attacker, so to block out those iPhones, the attacker would have to = perform 10,000 * 2^20 SHA-256 hashes per second, or about 10 billion = hashes. That=92s about 400 server-class hardware working full-time, or a = 10,000-way botnet. The draft is all about increasing the work for the = attacker, and I believe this is doing it well. The baseline is sending = 20,000 packets per second while only copying the cookie (no PK or hash = operations at all). It is possible to do as in the current draft, and set a single = difficulty level (say, 18 bits). This allows the attacker a nice and = deterministic way to keep the half-open SA table full, which blocks out = all clients, not just the iPhones.=20 Yoav On Jul 30, 2014, at 6:40 PM, Yaron Sheffer = wrote: > Hi Yoav, >=20 > this is a nice idea, but I think it actually performs worse than the = baseline. >=20 > With the previous solution all clients had to expend the same number = of cycles, but would be served FCFS so from time to time, the "good" = ones would be served. With this proposal the attacker can push out the = legitimate weak clients in a *deterministic* way. If I know all Check = Point iPhone clients do 10 bits (I assume most implementations will = choose a value and stick to it, because they do not have any information = about the effort currently needed), I will configure my botnet to always = do 11, and push out any legitimate clients. >=20 > Thanks, > Yaron >=20 > On 07/30/2014 07:45 AM, Yoav Nir wrote: >> Hi all >>=20 >> After the meeting on Friday, I talked to Tero and Brian Weis, and = Tero >> suggested a different sort of puzzle that could make it easier to >> support both strong and weak clients. This is sort of like the >> proof-of-work used by BitCoin. >>=20 >> 1. Calculate the cookie as before. For an example, let=92s assume the >> cookie is fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets). >> 2. A =93legacy=94 initiator will return this exact cookie. >> 3. A newer initiator will return the cookie, with some extra bytes. >> 4. The =93value=94 of a returned cookie is determined by the number = of >> trailing zero bits in the SHA-256 hash of the transmitted cookie: >>=20 >> Cookie || extra data >> =09 >> hash >> =09 >> # trailing zero bits >> fdbcfa5a430d7201282358a2a034de0013cfe2ae >> =09 >> ec2f327dae577a31152e3de2ac0f2f798e21f02e1afb04d33ff79bdd5d30eede >> =09 >> 1 >> fdbcfa5a430d7201282358a2a034de0013cfe2ae0182 >> =09 >> 71d3e8c09fbb8db5315e6364dce3ebd56ad35c96e284296e2ffffa256bdfa800 >> =09 >> 11 >> fdbcfa5a430d7201282358a2a034de0013cfe2ae022b3d >> =09 >> 3b4bdf201105e059e09f65219021738b8f6a148896b2e1be2fdc726aeb6e0000 >> =09 >> 17 >> fdbcfa5a430d7201282358a2a034de0013cfe2ae0aa679 >> =09 >> c352e914a41615496e3498e5ecb87b992be1ad40620f48af85428996c1f00000 >> =09 >> 20 >> fdbcfa5a430d7201282358a2a034de0013cfe2ae5c2880 >> =09 >> 155319280d687074d0f78511f63c77c568a5418dd44e6467d8fc37723d800000 >> =09 >> 23 >> fdbcfa5a430d7201282358a2a034de0013cfe2ae022bffc8 >> =09 >> 6469faf4455cf9a51b04edeea8195f27771d56b95f2d874764a71e2948000000 >> =09 >> 27 >>=20 >>=20 >> 5. Initiators are limited (by the construction of the cookie) in the >> amount of time they can spend. So powerful clients will manage 23 >> bits, while weaker clients will only manage 17. >> 6. When an Initial request arrives with a cookie, first the first 20 >> bytes are validated, and then the result is queued by =93value=94. >> 7. When the responder can handle a packet (has room in the half-open = SA >> table) it processes the entry with the highest value in the queue. >> Entries expire after some time even if not handled. >>=20 >>=20 >> I think if this algorithm is chosen, an attacker can still expend = little >> effort, get some 5-6 bits, and use that to push out all legacy = clients. >> We could counter that by having a minimum threshold at something like >> 10-12 bits, some value that all supported platforms can easily manage = in >> under 0.5 seconds, and consider all values below that to be equal to >> zero (not enough effort to matter). >>=20 >> This could get some more tweaks. But what do people think of this? >>=20 >> Thanks >>=20 >> Yoav >>=20 >> P.S. This is the first time I tried to send a table pasted into Apple >> Mail to a mailing list. I apologize in advance if it comes out = looking >> horrific. >>=20 >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_144C8D5D-97DE-4049-9545-9AFAAEB5620B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi, = Yaron

Suppose our half-open SA table can hold 100,000 = entries and we clear them out after 10 seconds. That allows 10,000 = entries per second. More realistic number are 18 bits for the iPhone and = 20 bits for the attacker, so to block out those iPhones, the attacker = would have to perform 10,000 * 2^20 SHA-256 hashes per second, or about = 10 billion hashes. That=92s about 400 server-class hardware working = full-time, or a 10,000-way botnet. The draft is all about increasing the = work for the attacker, and I believe this is doing it well. The baseline = is sending 20,000 packets per second while only copying the cookie (no = PK or hash operations at all).

It is possible = to do as in the current draft, and set a single difficulty level (say, = 18 bits). This allows the attacker a nice and deterministic way to keep = the half-open SA table full, which blocks out all clients, not just the = iPhones. 

Yoav

On = Jul 30, 2014, at 6:40 PM, Yaron Sheffer <yaronf.ietf@gmail.com> = wrote:

Hi Yoav,

this is a nice = idea, but I think it actually performs worse than the = baseline.

With the previous solution all clients had to expend = the same number of cycles, but would be served FCFS so from time to = time, the "good" ones would be served. With this proposal the attacker = can push out the legitimate weak clients in a *deterministic* way. If I = know all Check Point iPhone clients do 10 bits (I assume most = implementations will choose a value and stick to it, because they do not = have any information about the effort currently needed), I will = configure my botnet to always do 11, and push out any legitimate = clients.

Thanks,
Yaron

On 07/30/2014 07:45 = AM, Yoav Nir wrote:
Hi all

After the = meeting on Friday, I talked to Tero and Brian Weis, and = Tero
suggested a different sort of puzzle that could make it easier = to
support both strong and weak clients. This is sort of like = the
proof-of-work used by BitCoin.

1. Calculate the cookie as = before. For an example, let=92s assume the
   cookie = is fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets).
2. A = =93legacy=94 initiator will return this exact cookie.
3. A newer = initiator will return the cookie, with some extra bytes.
4. The = =93value=94 of a returned cookie is determined by the number = of
   trailing zero bits in the SHA-256 hash of the = transmitted cookie:

   Cookie || extra = data
    =
   hash
    =
   # trailing zero = bits
   fdbcfa5a430d7201282358a2a034de0013cfe2ae
&nbs= p;   =
   ec2f327dae577a31152e3de2ac0f2f798e21f02e1afb0= 4d33ff79bdd5d30eede
    =
   1
   fdbcfa5a430d7201282358= a2a034de0013cfe2ae0182
    =
   71d3e8c09fbb8db5315e6364dce3ebd56ad35c96e2842= 96e2ffffa256bdfa800
    =
   11
   fdbcfa5a430d720128235= 8a2a034de0013cfe2ae022b3d
    =
   3b4bdf201105e059e09f65219021738b8f6a148896b2e= 1be2fdc726aeb6e0000
    =
   17
   fdbcfa5a430d720128235= 8a2a034de0013cfe2ae0aa679
    =
   c352e914a41615496e3498e5ecb87b992be1ad40620f4= 8af85428996c1f00000
    =
   20
   fdbcfa5a430d720128235= 8a2a034de0013cfe2ae5c2880
    =
   155319280d687074d0f78511f63c77c568a5418dd44e6= 467d8fc37723d800000
    =
   23
   fdbcfa5a430d720128235= 8a2a034de0013cfe2ae022bffc8
    =
   6469faf4455cf9a51b04edeea8195f27771d56b95f2d8= 74764a71e2948000000
    =
   27


5. Initiators are limited (by = the construction of the cookie) in the
   amount of = time they can spend. So powerful clients will manage = 23
   bits, while weaker clients will only manage = 17.
6. When an Initial request arrives with a cookie, first the first = 20
   bytes are validated, and then the result is = queued by =93value=94.
7. When the responder can handle a packet (has = room in the half-open SA
   table) it processes the = entry with the highest value in the queue.
   Entries = expire after some time even if not handled.


I think if this = algorithm is chosen, an attacker can still expend little
effort, get = some 5-6 bits, and use that to push out all legacy clients.
We could = counter that by having a minimum threshold at something like
10-12 = bits, some value that all supported platforms can easily manage = in
under 0.5 seconds, and consider all values below that to be equal = to
zero (not enough effort to matter).

This could get some = more tweaks. But what do people think of = this?

Thanks

Yoav

P.S. This is the first time I = tried to send a table pasted into Apple
Mail to a mailing list. I = apologize in advance if it comes out = looking
horrific.



______________________________________= _________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/= mailman/listinfo/ipsec

= = --Apple-Mail=_144C8D5D-97DE-4049-9545-9AFAAEB5620B-- From nobody Wed Jul 30 12:03:05 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403751A0366 for ; Wed, 30 Jul 2014 12:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 cNQnV4-py524 for ; Wed, 30 Jul 2014 12:03:00 -0700 (PDT) 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 ietfa.amsl.com (Postfix) with ESMTPS id A32C11A02F5 for ; Wed, 30 Jul 2014 12:02:59 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3FE4880048; Wed, 30 Jul 2014 15:02:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1406746977; bh=UiqY0R0jxE6o+cVHSeKSfEiZCCL/YOSxD71hIn3inoE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=RIce8c+zDK/GRmNWdy1KBn+7vB5O6L9IufR1A2aJqiePzQySXl39Njm7GsA+hhZEC BNSheifXEhKQwv/hz7olaQqYf/FsQJar69Q0DEreYA+u8KTNzDOZWuEZV5De8zFwkg OJHswJowpJ/QTc0Xa0LY59uMDxZej9g2U0W1RYy8= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s6UJ2uED023212; Wed, 30 Jul 2014 15:02:56 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 30 Jul 2014 15:02:56 -0400 (EDT) From: Paul Wouters To: Yoav Nir In-Reply-To: <91340EE3-3DF4-4665-B21A-A108D00ADDE6@gmail.com> Message-ID: References: <53D911DD.1000801@gmail.com> <91340EE3-3DF4-4665-B21A-A108D00ADDE6@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/JZ5rbjr1F_bUL1KF9xow0iZd2FI Cc: ipsec Subject: Re: [IPsec] Puzzles draft - another idea X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 19:03:03 -0000 On Wed, 30 Jul 2014, Yoav Nir wrote: > Suppose our half-open SA table can hold 100,000 entries and we clear them out after 10 seconds. That allows 10,000 entries per > second. More realistic number are 18 bits for the iPhone and 20 bits for the attacker, so to block out those iPhones, the attacker > would have to perform 10,000 * 2^20 SHA-256 hashes per second, or about 10 billion hashes. Thats about 400 server-class hardware > working full-time, or a 10,000-way botnet. The draft is all about increasing the work for the attacker, and I believe this is doing > it well. The baseline is sending 20,000 packets per second while only copying the cookie (no PK or hash operations at all). > > It is possible to do as in the current draft, and set a single difficulty level (say, 18 bits). This allows the attacker a nice and > deterministic way to keep the half-open SA table full, which blocks out all clients, not just the iPhones. The iphone (which is only rumored to do IKEv2 with iOS8 likely to be released in September this year) currently has a terrible record of continuously re-establishing connections. Like whenever the screen saver hits it will tear down the tunnel. With an always-on profile, that means if I unblanc the screen, it will start a new IKE session. A scheme like this would drain the battery on top of the current re-establishing draining, that already prevents me from using an always-on profile - my iphone won't last for 4 hours. Perhaps we should look at other types of puzzles that do not depend on raw CPU power? Paul From nobody Wed Jul 30 12:12:26 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653CB1A03E9 for ; Wed, 30 Jul 2014 12:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 yE2KzMt8UaVC for ; Wed, 30 Jul 2014 12:12:23 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2DC1A03DE for ; Wed, 30 Jul 2014 12:12:23 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lf10so2054652pab.15 for ; Wed, 30 Jul 2014 12:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6ou1fVQDkc0EOA6KbK23fFZ+j86fdmxAHUY70+OElBo=; b=ZbJpXRGCcYl9Z+b+XcwiGGuHXY9Cej7bJdFhMrCAmDO3MyIkpyvNo7oUpjFy73O+IB TN+D1tNkQ+2bW194tzq/alH57yO0kGOChBr8aExDA+GI+2MFT3OC8qtpKCB+cyp/bTR1 HZkonOy209261dcaBrWtMmgCbTxdL7SjAeg3uIHxsuOcS7omTV8yMd5PQaltv37m1AHG LTJ7Nwxdu/9OzEYGfZOGqhH2wvW/tz+BMjSF+a6gH2NakbEY3ICpt0hLBfuciJP3vSfh msQpY/+GELYzPkVLdOLBwpKSQvYFQVzfYdoGWq82Ib1lvxZ+BVf6KekfszF3eFu8HfhD he7w== X-Received: by 10.68.232.2 with SMTP id tk2mr7088873pbc.65.1406747543072; Wed, 30 Jul 2014 12:12:23 -0700 (PDT) Received: from [172.17.55.209] ([12.0.207.18]) by mx.google.com with ESMTPSA id ph6sm3119595pbc.38.2014.07.30.12.12.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jul 2014 12:12:22 -0700 (PDT) Message-ID: <53D94394.10703@gmail.com> Date: Wed, 30 Jul 2014 12:12:20 -0700 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Yoav Nir References: <53D911DD.1000801@gmail.com> <91340EE3-3DF4-4665-B21A-A108D00ADDE6@gmail.com> In-Reply-To: <91340EE3-3DF4-4665-B21A-A108D00ADDE6@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-ehmuvH7nGBJJnftC8b2GVx3k40 Cc: ipsec Subject: Re: [IPsec] Puzzles draft - another idea X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 19:12:25 -0000 Makes sense to me. Yaron On 07/30/2014 11:45 AM, Yoav Nir wrote: > Hi, Yaron > > Suppose our half-open SA table can hold 100,000 entries and we clear > them out after 10 seconds. That allows 10,000 entries per second. More > realistic number are 18 bits for the iPhone and 20 bits for the > attacker, so to block out those iPhones, the attacker would have to > perform 10,000 * 2^20 SHA-256 hashes per second, or about 10 billion > hashes. That’s about 400 server-class hardware working full-time, or a > 10,000-way botnet. The draft is all about increasing the work for the > attacker, and I believe this is doing it well. The baseline is sending > 20,000 packets per second while only copying the cookie (no PK or hash > operations at all). > > It is possible to do as in the current draft, and set a single > difficulty level (say, 18 bits). This allows the attacker a nice and > deterministic way to keep the half-open SA table full, which blocks out > all clients, not just the iPhones. > > Yoav > > On Jul 30, 2014, at 6:40 PM, Yaron Sheffer > wrote: > >> Hi Yoav, >> >> this is a nice idea, but I think it actually performs worse than the >> baseline. >> >> With the previous solution all clients had to expend the same number >> of cycles, but would be served FCFS so from time to time, the "good" >> ones would be served. With this proposal the attacker can push out the >> legitimate weak clients in a *deterministic* way. If I know all Check >> Point iPhone clients do 10 bits (I assume most implementations will >> choose a value and stick to it, because they do not have any >> information about the effort currently needed), I will configure my >> botnet to always do 11, and push out any legitimate clients. >> >> Thanks, >> Yaron >> >> On 07/30/2014 07:45 AM, Yoav Nir wrote: >>> Hi all >>> >>> After the meeting on Friday, I talked to Tero and Brian Weis, and Tero >>> suggested a different sort of puzzle that could make it easier to >>> support both strong and weak clients. This is sort of like the >>> proof-of-work used by BitCoin. >>> >>> 1. Calculate the cookie as before. For an example, let’s assume the >>> cookie is fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets). >>> 2. A “legacy” initiator will return this exact cookie. >>> 3. A newer initiator will return the cookie, with some extra bytes. >>> 4. The “value” of a returned cookie is determined by the number of >>> trailing zero bits in the SHA-256 hash of the transmitted cookie: >>> >>> Cookie || extra data >>> >>> hash >>> >>> # trailing zero bits >>> fdbcfa5a430d7201282358a2a034de0013cfe2ae >>> >>> ec2f327dae577a31152e3de2ac0f2f798e21f02e1afb04d33ff79bdd5d30eede >>> >>> 1 >>> fdbcfa5a430d7201282358a2a034de0013cfe2ae0182 >>> >>> 71d3e8c09fbb8db5315e6364dce3ebd56ad35c96e284296e2ffffa256bdfa800 >>> >>> 11 >>> fdbcfa5a430d7201282358a2a034de0013cfe2ae022b3d >>> >>> 3b4bdf201105e059e09f65219021738b8f6a148896b2e1be2fdc726aeb6e0000 >>> >>> 17 >>> fdbcfa5a430d7201282358a2a034de0013cfe2ae0aa679 >>> >>> c352e914a41615496e3498e5ecb87b992be1ad40620f48af85428996c1f00000 >>> >>> 20 >>> fdbcfa5a430d7201282358a2a034de0013cfe2ae5c2880 >>> >>> 155319280d687074d0f78511f63c77c568a5418dd44e6467d8fc37723d800000 >>> >>> 23 >>> fdbcfa5a430d7201282358a2a034de0013cfe2ae022bffc8 >>> >>> 6469faf4455cf9a51b04edeea8195f27771d56b95f2d874764a71e2948000000 >>> >>> 27 >>> >>> >>> 5. Initiators are limited (by the construction of the cookie) in the >>> amount of time they can spend. So powerful clients will manage 23 >>> bits, while weaker clients will only manage 17. >>> 6. When an Initial request arrives with a cookie, first the first 20 >>> bytes are validated, and then the result is queued by “value”. >>> 7. When the responder can handle a packet (has room in the half-open SA >>> table) it processes the entry with the highest value in the queue. >>> Entries expire after some time even if not handled. >>> >>> >>> I think if this algorithm is chosen, an attacker can still expend little >>> effort, get some 5-6 bits, and use that to push out all legacy clients. >>> We could counter that by having a minimum threshold at something like >>> 10-12 bits, some value that all supported platforms can easily manage in >>> under 0.5 seconds, and consider all values below that to be equal to >>> zero (not enough effort to matter). >>> >>> This could get some more tweaks. But what do people think of this? >>> >>> Thanks >>> >>> Yoav >>> >>> P.S. This is the first time I tried to send a table pasted into Apple >>> Mail to a mailing list. I apologize in advance if it comes out looking >>> horrific. >>> >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec > From nobody Thu Jul 31 09:19:34 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274271A0180 for ; Thu, 31 Jul 2014 09:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.945 X-Spam-Level: X-Spam-Status: No, score=-3.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 m8pwHptgD_A8 for ; Thu, 31 Jul 2014 09:19:27 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE701A015D for ; Thu, 31 Jul 2014 09:19:26 -0700 (PDT) X-AuditID: c1b4fb2d-f798a6d000000e9b-aa-53da6c8ba6d9 Received: from ESGSCHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 85.41.03739.C8C6AD35; Thu, 31 Jul 2014 18:19:24 +0200 (CEST) Received: from ESGSCMB101.ericsson.se ([169.254.1.70]) by ESGSCHC007.ericsson.se ([146.11.116.86]) with mapi id 14.03.0174.001; Fri, 1 Aug 2014 00:19:22 +0800 From: Zhenjie Huang To: "ipsec@ietf.org" Thread-Topic: Confusion about NAT traversal in RFC5996 Thread-Index: Ac+s2yu8rvTH4Rm0S4qgmIaPdilNmA== Date: Thu, 31 Jul 2014 16:19:22 +0000 Message-ID: <6CCF0B32EEB49742A558E6A2BA50E7B6555C6ADB@ESGSCMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [146.11.116.8] Content-Type: multipart/related; boundary="_005_6CCF0B32EEB49742A558E6A2BA50E7B6555C6ADBESGSCMB101erics_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUyM+JvjW5Pzq1gg3fPVSz2b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ/nEguOXWWqWDd1FnsD45VjTF2MnBwSAiYSpz7vYoSwxSQu 3FvP1sXIxSEkcJRR4lHbByYIZxGjxKr3HewgVWwCBhKXvk8As0UEVCVOLZvOCmILCxhKzNt1 nQUibibx420bI4StJ3Fq4mGwehag+nX7LjOD2LwCvhJT5v4AsxmBNn8/tQbsImYBcYlbT+ZD XSci8fDiaTYIW1Ti5eN/rBC2gsSBRUvAjmMW6GaUmHN4DhPEUEGJkzOfsExgFJqFZNYsZHWz kNRBFOVL3Pw3C8rWkViw+xMbhK0tsWzha2YY+8yBx0yY4joSmy/thOpVlGjrnA21bCmjxIYX N+GG3nj7jhWmaEr3Q3aY+NK2aUDLOMDiXXfKIHqXMUpc+vAMrmbhzHsoehcwCq1iFC1OLS7O TTcy1kstykwuLs7P08tLLdnECEwSB7f81t3BuPq14yFGAQ5GJR7eB1k3g4VYE8uKK3MPMUpz sCiJ8y46Ny9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2OeYU+oUpOK+TXFsJTYLaUCGgr6 J5VvpX2dEbNjv3fxlVVHe/9ye57J2LjGN8LAWiBySce+LZMjayeJzXbsYdoXzbzAdMeSG18W ha/vUAvl5Ndyduo44FDPmcH8zJTzqqOqVWZO36d5oTz+71U3n2aac1t/k+RDLYsH27Y/udMc 6WdoeHWJmhJLcUaioRZzUXEiABUcVY/zAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/T9GeJm7SWxiWWw5LzCOOg8tEibg Subject: [IPsec] Confusion about NAT traversal in RFC5996 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 16:19:30 -0000 --_005_6CCF0B32EEB49742A558E6A2BA50E7B6555C6ADBESGSCMB101erics_ Content-Type: multipart/alternative; boundary="_000_6CCF0B32EEB49742A558E6A2BA50E7B6555C6ADBESGSCMB101erics_" --_000_6CCF0B32EEB49742A558E6A2BA50E7B6555C6ADBESGSCMB101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear IPsec experts, I am a System Engineer from Ericsson. I am currently reading your RFC5996. However, I feel confused with the foll= owing words about NAT traversal: Section 2.23: A host behind a NAT SHOULD NOT do this type of dynamic address update if a = validated packet has different port and/or address values because it opens a possible DoS attack= (such as allowing an attacker to break the connection with a single packet). It is very difficult to understand this case. Could you give me some hint w= hy it opens a possible DoS attack when the host is behind a NAT? Your different opinions are really appreciated for my better understanding.= Thank you very much! Kind regards, Jerry Huang [Ericsson] ZHENJIE HUANG System Engineer CGC/X Ericsson 13/F, ShuGuang Building, Nanshan Shenzhen, China Phone 0755-86925204 Mobile 18576627893 zhenjie.huang@ericsson.com www.ericsson.com [http://www.ericsson.com/current_campaign] Legal entity: N/A, registered office in N/A. This Communication is Confiden= tial. We only send and receive email on the basis of the terms set out at w= ww.ericsson.com/email_disclaimer --_000_6CCF0B32EEB49742A558E6A2BA50E7B6555C6ADBESGSCMB101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Dear IPsec experts,

 

I am a System Engineer from Ericsson.

I am currently reading your RFC5996. However, I feel= confused with the following words about NAT traversal:

 

Section 2.23:

A host behind a NAT SHOULD NOT do this type of d= ynamic address update if a validated packet has
different port and/or address values because it opens a possible DoS attack= (such as allowing an

attacker to break the connection with a single p= acket).

 

It is very difficult to understand this case. Could = you give me some hint why it opens a possible DoS attack when the host is b= ehind a NAT?

Your different opinions are really appreciated for m= y better understanding. Thank you very much!

 

Kind regards,

Jerry Huang

 

 

=

ZHENJIE HUANG
System Engineer
CGC/X


Ericsson
13/F, ShuGuang Building, Nanshan
Shenzhen, China
Phone 0755-86925204
Mobile 18576627893
zhenjie.huang@ericsson.com
www.ericsson.com



3D"http://www.ericsson.com/current_campaign"

 

Legal entity: N/A, registere= d office in N/A. This Communication is Confidential. We only send and recei= ve email on the basis of the terms set out at www.ericsson.com/email_disclaimer

--_000_6CCF0B32EEB49742A558E6A2BA50E7B6555C6ADBESGSCMB101erics_-- --_005_6CCF0B32EEB49742A558E6A2BA50E7B6555C6ADBESGSCMB101erics_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2367; creation-date="Thu, 31 Jul 2014 16:19:19 GMT"; modification-date="Thu, 31 Jul 2014 16:19:19 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhRAA8APcAAAIVTgAWUwAWVAQWTwUWUAcXUQkYUgAbUwAbVAoZUwAcVQEdVgMeVwQeWAYf WQAhWQAiWgggWgAjWwAjXAAkXQAlXgEmXwInYAAoYAQnYQApYQAqYQArYgArYwAsZAAuZg0sYA4t YRAtYREuYgQyZAUyZRMvYwczZhQwZAk0ZxYxZQs1aA42ahE3axI4bBQ5bQY9cBU6bgk+cRc7bxg8 cBo9cRo/bRw/bh1Abx5BcB9CcSFDciJEcyNFdCRGdSVHdiZHdylJeStLeyxMfC1NfS5Ofi9Pfy5Q ejBQgC9RezBSfDhQfDFTfTJUfjNUfzRVgDVWgTZXgjdYgzlZhDpahTtbhjxchz1diD5eiT9fikVe hUZfhkFhjEdgh0hhiEljiUtki0xljE1mjU5njk9oj1BpkFFqkVJrklNsk1VulVZvlk9xl1dwl1hx mF1xlFdzlFh0lV9zlll1lmB0l1p2l2F1mGJ2mV56m2V5nF97nGB8nWF9nmJ+n2N/oGSAoWWBomaC o2eDpGyDoG6CpmiEpW2EoW6Fom+Go3aFo3CHpHGIpXKJpnOKp3SMqHWNqXePrHiQrXmRrnqSr3uT sHyUsX6Ws3+XtISYr4easoibs4mctIqdtYueto2guI6huY+iupCjvJKlvZOmvpSnwJmou5WpwZqp vJuqvZyrvp2sv56twJ+uwaCvwqGww6KxxaOyxqS0x6W1yKa2yai4y6m5zKu6zay7zq28z7C8yq69 0bG9y6++0rK+zLO/zbTAzrXBz7bC0LjD0bnE0rrG07vH1bzI1r3J177K2L/L2cDM2sHN28PP3cfP 18TQ3sjQ2MbS4MrS28fT4cvT3MzV3c3W3s7X38/Y4NDZ4dLa4tPb5NTc5dXd5tbe59fg6Nni6trj 69vk7N/k5t3l7uDl6OHm6eLn6uPo6+Tp7OXq7ebs7uft7+nu8Orv8uvw8+zx9O3y9e7z9u/19/D2 +PL3+fP4+/T5/PX6/fb7/vn7+Pz6/vr8+ff9//v9+vn+//z/+/7//CH+EUNyZWF0ZWQgd2l0aCBH SU1QACwAAAAARAA8AAAI/gD/CRxIsKDBgwgN8tOnb1/ChxAjSjR4792vMyAaBLllb6LHjxDtvau2 SMYBCRYsSHAwSx/IlyD5ufMWCkqDBihTppQghB3MnxDhgbPVhsNJnUhTHigHtCnBeuCMKcpRAGfS qxLMOW1qTpmmKQ+OXr16oIu7rS/fPSOlhsQBB2OxPmiAwxg/tB6xtfLTo4HYuDolHOBQZI4xvBPf XYpiNCfgnQ0e5FDDyRniifUuSbD6OKWDAyPAVArW7rJHcSMcAxYcwUkjW99Mf9xnrMDjzQVw8JGF jR5BcrFMKZP90BmBuBEKcCCTSprPgfhs6VFCw8UOQfCIH0SX4wFSwQ2Y/lxqppWgNEdOaHCQwB7l Jd/aCe7D1fhBgheBjJWDL5AdqCo1iMBeUhLIoE58Bd3TjB9VuCELOfEUpEsaNJCgEmAFMIVgQfPA I49LA1mDSA4krNeZBBycs+FD7ISCxAgcdIbUAXRkt2JB9ghjhoUyJuWAEN7cONA+2zByg2o9pkSE J+/849CN6tDhAJKdZcCBDH5UIyRB8exxQJIpgeACGLR0tCVB3nh3ogQeuLBEJuQQdI+ZQvIzjG1x sZeBC0EEMtxA/LCjVyjGPHejNF8SyF4KQLARC53/vIONLGp8UMABB7wxjpDvQCHWSh70EEYnQQ5k Tze9HLLDAZxZMIAi/vPcyE8yRGxw0g1bOIJMQeQIcwkVglEpwQjobIlNJHksQstZA7mDzCdosFDA lBhqeCZB/FBTyh1A3EQlgSykc+1A5LQSyBMctHrbAZLwJ2Q9vjSiRQsOUHuiAwWQ8EexW5pjSRg7 WKDuaic5QckvTW5JDRMj2HuiXzQAYss29Vz7DhYD53nABmawgg2z41rTgIybHZDEJtio8+S4//Aj TKIasyAIM+tUzHJB3IyMFU5j0MKOuzcT9M4aMKv04ybl2HNX0AmZ4wVOErTQxzT5MD3RPWsFI4/V XHft9ddghy322GSX7dEywQijtjDBxDlN2mofwy87vhyjokDY0GLK/iq9lOPQpHsHc6A+zrRSCivI xPqPOr2ggoovB0aaTDDBiPvP29XwM0YOO8hQgwwvrPKPHTjkUEMNQZiRzD/HvOBELf+0s8kUKTwg QQqb/GPKFCVE1kMw9GxSRGNRxKYMG0dKcMMbu2KTBQ41bFIxHTfwYY8QDYiQRRVURGHLP1oc0AIX UWz2xD++DMACK/9cwgEBOdThhxOVYEMvEIoYQscww3DgQBSM4MMdypEOKEwpDnBYyRTQQY0c+GUH 0vhHFQ4ghnoYwQFGqAc60GGOefDDCwcAAzbScYSU/OMXBXCBLKghgwJQIRjskNQ5VpEBC/xBIOpg hycEMAJR/OMe/kzJBAcisAh1nCMRBxCBJrbhgwgIZhL/6IIDyGDBCMhAE5SQhCa48Q8QXoF/MpAA E05YgBe04hVfCkVBlIGSHNhhFaVhBQEyIIRA3EIgX9iABO7mDfaYoRs94MALOHADcnxhihZ0TNRg 5wUHiEAGNLAAEbpBxhekAhQDeEEuCqIPQfglaleYRjrQgKkNvKAN9mCCBFjwJHfAoAFYwEYg8xAF AnwCChGgohGixgc7zAEQ0+jiA1RghBiNQEUoNGMqBAACWRjkHccgxAxs54Z/rMMWcuhdA4YBhZSY yR0ecAAXACmBVFRCAjt4gQR0+YAx3uMeDtkHCKngDVGs5xJk/lRh/xrABkMRxB7heIEDoECQVdCA AKawAwgcsMl/7GIwg+jGDspJjiRIIAPrTKQLAKEHPcBBGF08QBbaUQ8VWAAI+WyFPNxgGydcYhWH +MQ3xtAJW1BCJWrABhlKYYs0cGAAtaBGCSQAg1UYVAIzkAY2JjqKf0ACBBLIZT2w1x4JFIAT/8gC Aaqwjn+kQQIbUEYw1Ce6bogBJ1ZyAB6SwYG2YvQG1ODFANq6gQR8IU6mWE9bh3WKfzijO2osRxFu UsFWcKITiO3EJYLJikasIlbSmMQkhvENRmRCS/+wxzAKcQYy+MEY6thEHMighkyo6BuRaMMY4rAK kHXDEWY4FUMkKPkPc3giEtEQyC4o4YhX3CMgAAA7 --_005_6CCF0B32EEB49742A558E6A2BA50E7B6555C6ADBESGSCMB101erics_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=22330; creation-date="Thu, 31 Jul 2014 16:19:20 GMT"; modification-date="Thu, 31 Jul 2014 16:19:20 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh9AFRAPcAAFUsfOLi6y9cpzlQm3qGuCtgqjFapfv7/Es4hjNWoUY/jDNYorm61U40g1Mu fjRDky1eqTRVoI2axOvs8j1Kl0g8ioKGtC1DlDdSnkRBjk02haSqzjo7iz9IlEIyhDtNmVExgDJM mkBGk0NDkFAygVYqelEwf5aTvitKmkc9izM7jDole08zgjsyhIR6q5qjyMnK3FRnpt3d6kk6iDpO mnlzqDVUn4OBrqu21DdOmnJsovX1+EFEkjotgaquy/Hy9j8pfdTV4kdaoUJBj97h6zRWoePl79Tb 6mRnpjJYpLCtx0JEkVdYmra0zS44i2pzq6Ku0mVXl5SKt66qxkJUnEo6iD5GlMLF2111st3b5ko2 hTU2iTxMmKyxzS5eqODf6FcoeTBbpT1FkkRLlbvC3Cs/kS9cqDFRnS9bpjFZpFYsezVQnDVIl6ul wjQyhlQufIqSvVUrek41hHFln8fM4FgoeEVAjczR5enp7kMtgEU6iZ+iw0o4h0BHlFAzgjdSnURC j6SdxD5Jlmp5sDtKlzs3iDk/j0xOljRWoi1fqcXC1kw3hUw1hDM+j0FEkThBkSZBlMK91nR+s0FF kjhIljBcpsXI3FFCitnW5jlMmXiMvlcqeVhOlEk7iT5KljpOmcvH3EcxgkpDjUI5iTNSnjlEktHW 5z1CkEE+jVIwf9DO4DpKl56bvixPne7w9TxIlVQtfC1Il9bY5c7N3TdGlDZOnEZAjR88kTxHlE42 hERCkO7u9Kqjx1cpeTdLmDxLl6iozObl7UU2hlA7iCdJmjJPnOXo8tTS4CsuhUA2hy5dqKSgv1tg nypGly9dpzZUnz9YoEtfpDhRnTZTn1Ure1pvrfj4+jRQnkg5hzdPm1gneDJapDVLmVgndzFHlko0 g08+iy9TnzlNmVkod0RPlz47ikZAjlIvfj5JlVQufVA0gjtMmC9cpkg9iz1Klj48jDVSni5dpy1e qG1fn7OuzqeqyEY0hFA/hlIvf0tJkFBGj0RAjOjn8SdElufn7v///yH5BAAAAAAALAAAAAD0AVEA AAj/AAsIHEiwoMGDBRIlVLgwEYRE8hIl8vIQgkUvXpQpi6dRmZd4IJ0JECmAnUk07ARUUlkJTaVK YcIYiClzpoGbBtKkyalTZ5KeQJMITbKgqFGjiBIkWIAIUZEiCZ4+jRChCFWqNrJGyJr1mddpYMNO wzAWg9k/fzD8kbZWmtu3A+LKnTuXRlwaePPq/cCX77q/H9Z94BKYC5dfhn8pVkyBMQUK7tx5cifI k6DL6ASh69BhM+cOfUKLFi2ij4jTpk+LmHR6kutJPFwvke1oyYgluEfo3q0LkK4RvgEByiA8g/Hj djIkt8NcgR0F0J1Hn56iuvXr7bJXyN6ugvfvnTp5/w/faUb5KuXPV+FTZT0f9u8RyJ9PH8Ei+4vy 59ewSIP//xrIIeCAAzYgRwMGNqCOgiyw0ECDELLgBwkSTkgCCSBcqCEIHHbIoQmpmABiKqmcg885 qZx4jokOnOPAiy06AEs6sLwIS4035ojQjjxK1JCPEklkEQTyPOSFPBjFk1FGyjgDkhlmOCMSSSmV ZBJNWMaEU0053QRUUD4NtYBQYx5VFCJFLbXAUlJNJdVVW9kQ5zM2TGODV1+JVZZZamHAllpswSXN AIMSOlc2dMlll16f5PXBJ331RZhhXKxTaWKLLdbYY5BZFhll7qAj6qiflfrZaKilpppqr8Em2xK1 4f+Wm2276fabboAAN1xxxxmXnHLMBQudLcROB10K1F1XHXffbddds+ORF555M8xQhbXtZZttfdzK px9+/fXHn38DBkjguQciiKA6DkoYoYUkwLthhvR2KCIIIIIQYor4kIjPiQCr6CKM6RQ8I405Jszj wgUx1NCPQWKEJEYUT8wRR05mnFI8AqgkgEvshMEOGi7JZDJNNuG0E09fpvGTy2IWRZSZaybV5ptX WYVVnFzVeeczYAEdFlljpaUWWoC+pTRciSqq1wB64fUBDZEG1hdghlmK2GGaQvYLZJ9WFqplmpHq Wamjoarqqqu51varst62G628/SZccMQZt2uvwDL/Z450thgruLIptIOds9qJp7i05VmrnrbZwsdH t97e5y244gL4Xy7oEqiugp+/6weE8ZY+74UeegjiiPv+22+JK6744sAEO2CwA28kDAsADPfeMJBB CgmBxEQeeSSSGjkZD0kcd2zlyCGXHEZLKGupMsst9zSUmDObuZRSUT0VPlU6XyWnnFh1padYZKlV 9NFtLT2oW4kiWpddd+UFKdV8QRqpYIGx1KW4linGfE0ynaKMp8pmKlOJBjRqW9tr3uYq18RmVrSi m61udbcO8q1Xy7FD4KLzHMEpAFknJFx3Cscs8ISnAoyjVnggt572wIdy9qmcfvTjn8wBiHPmEpCB /w6UrgexiwVHjFDp5KUhDNXrQ/i6F4mm6C8UrUhgshtYwWSEMITpzne+C54YIfIQiEzEeB0BiRo5 lrGOUUklVyIZ9WqiJS6pTCfYe5nLwkSmMh0FfAlwClTCZ5Xywel8PfPKnaYhND3xyU9sQUskBdW0 RC3qknuR2qOuJsC/CBAxoNTU10aZQMlUpjKi6oAgOtPAPkAQVWxrDWtaBZvYTEJWuKwVb0agi94E ZwgfVI4wg+W3YI3QhMci3OGgBUMXwrAT10oPNK9Vw/XgsFs7DJe4fOifXHCuQAVCULqO+CAkNsgP o2NBE5vYISemLl8hGhHAYmei2M3uRemAke26qP87AMACjAhx2BiDFBGLOARJ8lBGQpnEkY0ow3nO q1JJWjIymMQEDTfBkk1W5iXshcknMJMZzZiSlDUF8mZVMeRW4jQnoQGtkXt6X1omKT+mVRJ/T4sa Dfz3vwAKplJaUwwBG3PAA0oGVGVj4NlO9UrSmGZtq3IbLS8YN7rRrZe87CAw75Y3X/0qWH97DrGO eaxkprBwyvLOs56luGfG0Dw01JZ8JnfNbIZrXJoTELnQlaDPPaic5ZwQvJiIutRBUUSIDVG/THQi 2NHznvs8mMFmlCMA+JN3AD2IQhiy2SBVxCFHGp48JpaRiz00JB1LiTOgZ5KPhQENr7We9VKGPY// 7pGPfeweUgLJlJu9SaVd4Qqdgkbc9U3DaH6CZPxqWsm75A9qUdtk1QDoSUpRqoBEVUxkLAOZy2hm lQxsIGfS9tTSxFKWr5nNJBwRK7np0la46iAggHmc4SDHDvtgji30W8ISGss6KUyh4QbMnWeNJ1ow hOu0qElD9sinCnW1613xurnOCVGI6loQu47IRCZmCEPu/BBi8bUvEP2Lni7KYotoh6N8viF3/dxd Zg3C2YFCpEjFM97EPLIk1DZPJFUa2fRgO0fZmux6tgWpUGA2s9ymiaRKgYpvyVcV8/WsZ4xkZCP5 BJZHpqUty6WkXOx3v0VBFy88/R/WPhnUAn7t/zHaVeApMYOZzpwtNONtannPS8vXOIKqGZzbEGrV m17Kl2+/6htYRYjMZFnHcIXbzne0Ay3GxTCu2qIrNnOYTQBxc69yCNAQ/Qq6cqojiQ1a5zrrVVgT eCgVH/oXv+pJaxXbzkb5tF3CLrs7f/5zxgTprBjLaJGI6Hi0PPaCMzbCEQFwrHmtNYm0YQLbI88W Jx3dSfaYvL0+jhSQTiFkSg+5UvQNV8uO7LLRjBaoMCutuWWO7qPSzElL/QWoWyMgKRkjGcuQzbuZ YaUD9WxeqLKqzzyYTS6rSmhDZ7U49gVhCInZ6P8CWFkFTgEzoyUta8G1PdiyoVzrirkdai5AoP/2 XDhBtyAkqiOd51Q16grrTlfrS8TyLFGJTqyiGPncRvjE0Y18XVnMzrizEBv28EA7Wop5pKFNAomz 3zgykk3PorCt9smwzbJtZG97LhuTbmnWlCiPz01wSl9Xzp0V45rluH1Ci9zdTT945w8vZ57aTjV5 tQAWBpT6ztRj3PEYfwui35nRjMDFq+enGrzPsFE4LjOYG17ayje6OjRyhplfO5jD8yQ0oTKxE2ln VfqFbm1ctaoFOQTc8Jo5xFwPx5W5AX3zwhdWl8uNGCF1XkhCpyvsYfPFuhQZf+c9T7GKc40wGfXT 1/4E9kKSLqTgEQkiHlHoR0qLMYw5Ox5BLsn/9F57pYuijOtd2raSYzbSmpk0ym2qctrPFwE6nTvL 7BtL0b4895rOjy5kRhc6JTU7VTVW40nVxTWB92ZvdlRyZhmjUjZ3dioRZF6twSro5RqxckuVNyuW x0u+BBy6oDcRB0LAAh0lRFYWd1YY10LN8kIwGEONAznvwR4QtmmXU3L/sR95FUR85VftsmHoFHOq 9mHtBEWwllgiwi/GV2vKl2L4lGtvkA4wtmu9ZlnS5yPUR2yjRVrI1mMf4STMFmTSxg6VcCXRE1sZ dWTpd0dgElJEMXY0A24olXZqlz6KBBZ14nZlIXeBIj9xUSiHIoCY5Cho1hf8EymVMhhZE3hw/9YY hAc2C/RdlJhKrTReoVFwbAN5F8ReHEh573UrhuZLHoRoIeQczVFxLIhxGueCL8hx0wJN08RgNoQA N6hpOChhJ4dycnB7uFdECpJEL1chFCJYRSh8USRiJLI6JLIisDNPtBMjuZYjNAJj0GdZVyh9AzFQ ZXRQXTgx8qAkT3dazhAlU7I804YSr1VtGLWGdtSGLfMT3aZbcvg9RWAzhRQVOXNIibRIbVdcQ/Nl 8BM/bUEodddcOIV3mUQ1fKdm93ZdbmZUXzMZ/3YZnhBwikeBeJY2qRJLE/QqGshesWIblbdBH8hV vCJxxPR5/KUAKuhoKsRCkvaCqEce1TJDM/+Eaa6HizhkciYHIHrlg+BUROb0V70HIehEWIYlYjfH OgHTL1gUjQRDIwVThbpzhb2WWVo4fZ5lfQWlY0zCfVKiPCLBMa11hiehjheVUTPBJT2RZGDSbe33 fvd4j+JmhzuzFfZ3f273SH4iSWD2boI4AAFYF3enP2gGKf4jGIAxGJ/kiI4hiYc3md+lSpeIiRFk cBlIS7jxiR44AkNgN6PYG8G0eRT3HP41OCg0emjlHaXnQosTi+gBTawXObaIDfaQBz0ABLzZm3lg D1pgOXY1e9wUar5IahlWTkg0hKnWREr5RK6mhPGUIlYkMCtGOy6ST1skdJW1O0NnWZZFDUf/t1kN MSRdeUZNl30fwWxtNBIRlVpm6BJaZxN1hH5f4nVBIZd+lADh0Ar++Z8AGqD/eQaHdAbFkEhaBjTw UAwo0KDXUBbHBZiBsgYhEAuxEAL2M5iESZjc4A0e+qEg+qFskAkG6BeA8ReUQAsPsKIs2qIu+gCl QAuvIGeYgQ5W8AiN0Agq0AiGUApWAEEQVBqwFFVvwwOnYAiGwAFIygFMygGo4F7vNV+o8A5DUIqm SUwtOSzQMQot0ALJsJppNQqjYB0bB4vlIQzYgGnWUoN8YA9AMA+qcAD/MKd0igkusAKhoAU6yEMn d3uc01d+pWEMgpTuoiEeJnw2h3NO6S9Q/5lFUHhrUXiV3rlr4EkNRhdG1CdGEYFjRbJQGOFQy7Ns zQNRqXWGKGFRbKhR6AeXS0YmTVYU4VANUDCrtFqrtkqrmoAC6HMGg/ACxEAKd7J2jFQM1UAErkAH a3AGXiYNSSMNzSABEzABL9AM2aChcZEDFwAHULABG7Cts9qt3roBEnABmaCY0xUYmUALkrCt3Nqu 7vqu3DoIpeBdl/EKpdAIY7ABMuAKrmAMljAITvAIVqA2qqEqbvM2jsABSAAMDNuwDLsHFvAOW/AO uvQbQ1AONQAHhaA3HOtVytF5jJaaKdACUuAPE8AAyaAHyKIsyVADLtACeqBWpndg5IENPf9wAlEg DLJIg+0hDEAgBXQ6p7sQABMgp3Q6BSvwDcHZabP3H6F2LkN0IILqIKiWlL4nc6tmL/fCjFQEMNRp T/oUhbjGneB5jWUrnmBkY8LjEGxLEUfiEcijERgjJR0DfhAFPS1BZFnChtfTE/h5WzDDbWaSBMQQ tIZ7uIYrAQRKCtAwpwzQCsI6rI0btP2AXDMVSSGAA0GLA7FwkHJxAbuAuKJLB95ggD9lKasQA6K7 unTKDK+AGbjQCMwwAasLDE4gBgNbXhIkS6vBA4bACqw7p9ZwA1swaJg3X0gwp6zwDiUILF5lTCLE aNDRAjJguLagstcxCi4wp1PQAmXqQtj/AASuMKc9wHq16R72AA47ILRSkAdAkAfuCwQrUAPVO6dR kAdLu4u9iHJABLVAyC7KOYxXq5Qh9k5LmFiu44TYGbbOV41XeVnYeLZaCTxdeREVYTyf2hHKJqo/ lhImcYau1RKoWkd0ZJ/b1qp+ZBQzU7jBK7qaQKBngAVzegS6unZAgwJXkLghwCeS5BZ/0A+H2wyD OAA54A0tvLlscK4DtArRcMSIKwS4ICqvoAI+0MIHMAanQF6b2GcqYA1OLANuMGiF9g4n4Lgc0LxY KiypuaUWcLgB0ALKogc6QKcu8KUbV7M9AAp02gPXEnLu4QFzILxRAATAWR9aEAp5MAwB/zCnUhAK EzYuoRZEPihOgLphp5ZOE6JOo4NOq4aM9sIhIaIvjNqE+BAjYAt025kjVQie33m2l9ojwbaFm1ok S5IkpZUxImEGIzGq0lYy1DafW2KfcBm4ZeJtRhEOC6AJyrzMmvACc2oEBMDMylwNkGsDMTzDKDBc jUQMofsPMvwPRBALZ7EWkhQC33wEpjCnGDqIOSAEczoBkkAA8jzP9EwAT/AAABRAlCJAq0AL0VDP BCAJOfwPVxDP9SwEMooOU2wJQbsBY6ACKuAEkkAEQTsGYmCBBgt5k7AFrYsEHv3RNwAM3fwPAVC8 wUHGjlsIKckciqbGxtIC6/sPJ6AHdP+KvctSAS2gx3PKCaMAm+MxAx5QxnPqAvbAs1VgD4H8D5Gw AvbAk+CiBd/ws3MKBJlTnL5YRMConOa01RTS1QRsWDanhFApaycGhQschVTpRd1ZdJUKAGi7MORp YwZFEQhFMW/7ESGRMai1WukoZFrXjrSFbSujfvkph0YRAeGQ2IrdCudMDGdwBuHw2GcArFlxzf9A w1+BJ9PQDHR6C3TaD0czSX8QCwMtAZr7D5oQAonSzs9cBmzw2rAd22zgCyTad6cLVISwCilKC7xN C42wAXO6AY1QCsRd3LgQKujwCM48p2QQsFbwo33wCCrADEHrBAV7cBrN0XPqBqfQ3af/gAqokKRu UAN0GrG6gtL/wAAba4rL4Rx/o4KjwAl73AKY4LhfCmkVoAc9QLtz6gEx69PCkNT/wAvly7PCAA5z GghAMDlaAL9NbTlPnQdzoOB58A155aedU8kNsmHnpMlYS3Ngnaj70oyNZZ0/x8CRZYVsXbaWpQZv zTAUrKmbSiTI43QOtRHLRhJU4sFo8DFFdn7v2FFe8iV6tD0iNVJJYY/hcM4oYIdaYc1MvodCgwEo MKfGcAv8HQ1r4MPx0wxe/A+xQACOGwur7c7/YAQXoFMl6hecNEBChV0PANz/sAEP0G+RQWe48Ap0 ugEq8KNMdaOnQKdkYAiaOUutwgPa//0PW6AbJEkrQ8ABQm0NWyAcuoDe6m2CwZIB+6VfgtMCqjCn V5CyUbDHaNWK+k2nP9ADMSsez4QNCD6nx1C+fmxDQLC+kbDg8pEH1nAAnJAH+VFyhwwEWfAPQMAI J9eLKpcuUpthDTKo6uR7nIy1T4QvUZRYTKjApwx03CmpvXaFbU0NL65ZcS3Xw0MkxZNQcpskoCp1 zlYSE7US0aN1JxPkg61+rco9cwg+TSFIS47NTt4Vlo3ZeTINxSAJoN4PUDDmkPQW2cDZ/3AA/RAC zyzEdMHaZ57mas4/aXai9nYYHi94vxDnwf0AneJvZPMId/DMTgDdeeZK0Z28c9oIfP/GiYm+BQtn K0PgBnRaCKEJCOUg1JfuvB9LTMeUmj1Ap6Kgsi3w5S4wpoazHSmgB/pAp6rQA80EQzZLpzuwAtiA LX7sAUD7D1zveggABHTKC0nLH7KXB9XbBHmwORpw1eE0TsHIIByGyYTlyakznVO0qLV24rkWdNTo nUTn7eEZnuGuWZnalbTchRkMqszmnm70PGZIbea3hmwp2NiDn93GR0fuPeIDf/1+2a0wfywV8Ciw Ppk7pxKAApP7A83wZW8RAnAwp3QQC0A8p/1Q5s+M8Y4yNSW6ZgOUGB8PZyI/5w9AkQAnCK/gBHRK DmLAVBQoAipgBMFtCBe4GhSUXjX/fxsluRtbwA9zygyoIBw/n9K+0tLNsV+CkwyB8M5wnALJALz/ sAstoB3c0QnJMMcJDhAeOnWqgK1HsH8JPWjpVGVGFYgRgSScYw/BRQQTE/77gSDPIpAhF31DkHAF Iw0a5GjIJcelnAYuYzagWVNdAxbq1LHgyZOEHxYkfgoFQaIoCKRJTYAwkcrE01RRo+LDl4rqOQfn sGJ10DWdV1hgYY2FBaAsWbMA1KqlBoAatTgF5M6lm6hAIrx580KQByGvFwheBMtTJthLPGfxlCmL F0/AYwHOHrNDw64SmkqU0YThbCCMZwOhQ6cRTXp0miRJ0qxO3Tr1giQLZM9OsCBB/wJERXTrDocl 4REUEYTbiGDDuPEzvv8Bn9bceTMiCYWsabax35o/0rRLi3UkIRZuzXYkhJRtwPnzOYQkNHKBxnv4 nz59oE9/XX0uXNbp35+fyy8AKaDgFwoe2CChDR7wRBBB3BEEHQZxQSKhH1R4pQMM+8iwDw77OEWS hCZQQQQSJxFhEhNRnISHSRxxZIuNthhhiRFqtLHGQgJIqAZUABninRMSYqCQDDKw40gkk7RDASab TKGFAxJyYZQUquxhI1H0aKfKdtqpoAIPgkxIBw8qmKEFBjbiRJiHHIoIImGi+GcHIPjAKKONNpIC CC1EWkSOPDD554RQVGpJpZcSrf+JJhYa2IkFoCKFVChKKzXqqKSYekpTqaaqSit8tNIqK1K7MnWs N8ZKhyxW12JrrbbeooYuWvO6S69E/EpEHlwN80IeYAtbrLHEBHAMMcnYEYAdZtkJ47LNOusMtNEM WM3a1bJlDTXUYJvNW9lqwy2323YrorffghNuuOJseCa5dJ9xbhoMmonyn36micWUhDQJIbvt+tmo vH0TqoYb9GgYQL2EjHHvvQ9omI+G+uq7j778+gNwY44BNBDBB9zxxEEIGXzkwH+uaATDDTvs0Aon NhqxRBVrXmKSm2FMSMYlaLyxxi12SeiQIQDJoBwxh0zSSCTNOZLJJZscZZ6Neqj/ssoWVEkIlGRS qMDrL7/sQZGN9BHGAyk2qsEDbN5024NI/uElFATsvEijPP/5Io9Q+lxEg0VCoTqYPBDNBdGXFrWJ 0Z56AopSPyrN9NJMoYrKcquuSuWcq0jlyiuw0nljVVbPSutVV9tyi9Zacd0rV9gD+1UeL4QdVjFn JItM98g0CwOzZ4HfjFrRrC3+NG1dU/5b5hdA5DZEotctgnOVA27d4Y5713oU5p0GHoH/OaAZDEIg IKE7YgFYmlqgabiZAWKBIqEXvEFvAIm9SciUC9jw/38AssEXmfjAOu7DHwP+Ij8d49jH/pGgBTFI guh4xBUSIoFHZKgDLuuDCDgk/wIVyIxEI0wRim6GohfF6Gc3GoIbNuKGogECaUIiUpHswDQlNUmH hZCBkLp2NT1wompf6lLYOqGHHkyganJKCC/Y5jaI8KEKfMiDK/4BDi3cCU9524gOgPCNv2mAEStI CBBaspJEyURxjrpJTvygDqAExVJzpFzlkOKUpkClKVY5x+ZEVSpTfcUBq+pKqkqnFtOlji2yKgHr anWXW+WKL3gBViVpJyzB3E4ZidEd78IggEqEsjKcIaW0PnM80mhLlalBTWxe07xwJaAI5cqNudC1 nOAQxzjPiMAz3AUvXDYHA81Zw3r+QYRYSGMNkNhIM7YjjRDM74GxGEAIlMM//P/djxtY2AAVCPBN cIbzmzFgAwE/4B90dkxABBqQAyEoiAiiA0ONoENCLFCKDeaTgx3sQwgT4oQTnaiEKnJEz5ags3/w bIUttOA/+LGFImUASDTEYdOQpEMmVakQG6HS1bzWgvH8QwrJCFtJC3KlhCAkIaroQdugGBE+aAQI WtwiFxMSiTyg5G9AiJIZXYI4mNAkqDbhiU4c5xM5WipTSwWBVJ6Sx05xLlRb8dyoBhkWB5SuVWU5 nVteJau3xMWRkHSdXiDAF9oFBli1qx1jiBUZxEBGWcuqzGYq8btoTeszp8QWtlS5LdeAC5a3GZe5 pheBW17vOO3y5TSKwT1hDjP/BBIQEgr+UK8fJESZ22mGMTRbiwFkowwJ2cEFEvYeX1zAszblYjVW kTF0/kedGxOQOx8hQUFgSJ6NkEVCBoFPDXFogx3yIAit8c+ACtSEOGPuQWP0Dg5EN7qF2EIhLLER JKAiojP8x5AysA8lHckWS4pakwpBj4TwowUerdIo0vYPepDUpBUgCDYukbcfrMClb5IiROomUy0u Am+srUGhUgIEKwLBUGlM3KKM2rjHkQBSfojcHDGFlE1hOBVNdUpU+hgqEIvqc6bqSulINxazcBVW a1GDV+HylkfOpayx8wtaaddWth6GMQJQxu4e44xmaSZaeZXW8ap1rVVma3mw/4zlAmZZLlnuBpjX Y2y7fgnZYTYnFvX8h78w8IdY4ABBIdBONpiZENOe5wIbSfN53uON6LC2tb4w4DoUuEAFqnNAFHCH OxXEIHQEOre8TcgTShFcDhaXRCo4bkIH2iKbGRShyGAFDCxtaUxkdiP0qGGRuKu08EINoxlF6T/m 0YMWpFrVLVhBIBjQAy3NlyAzEMYc8sS2NkGxvzEtI00HbFMXGFgDQBCaghksk6G2ESeN8wmF6WiU Oi71qXusSrWnOlWqkjgdq+L2iVOMSBSnrsVvAYAa4kCNEsyqLni5VSTx4pe+/MrGmawd7hrj48ks S1loEEBlnHVXUnpGr0f2q/+St9VKJjPvec4jbJSph1ju6fI4u7TBY9MV2Wk0Q2j/KMYapIGBWkSj YclkXzXQR001K/EfOciBwvBHg9EmpAsb2AAUaG5zmtf8CWz4xTnxzEDa8tkTBUJZgiAEoQ7IswP0 TAgBDo3oRHtQBffawqN5YNCCFtS5CZmQnP8RCIgWyWifJpJFxasAW4x6FDrYiCow8Xa4w30WTdAB rI1IX/p2YgY9+EJCTuCBl06xCheRIoC1+Ou8gQIIKDlwT9GI7KEuqqg4eVSzLQztaGN4U52iirVB hY+ubEWQVw2LVlGMFleJO1aMHCu77ZIXXknyrMCCQGHoXRhnKMMMkeld7iD/A0pmZcZZAd+rkZFc cCWrpjXMe6VtnCcb3cgyykVY15Rz6S5fZr/ikBVmxq0DsDWE7x+Q0E4syJAQSYQAPd7gsia4AZ8B ZMKYRiiDN+x/f288wP4PoMQv9rMfjpEtdhIQd+AzPvMzBmEZ3TKE6/oHOMigfRqhEfKnf1CBmrnA JdA6GkGoIWCtA2AAVOCADIghT0uaQkgStBs1jGoBfvA6LpKBHjAigsi7TvAAUJASYRgIN3EbKbqI KvqHS8iiO0G8jXCBxUsJMSKjf/ApyIs8nmCUZbO8yJlCSjmKS4m2pZg2zuMcLhQxEjsVrDI91Es9 WXELsAqrRqoLd9uL2euL/7UijLU6jHpjDLfKnXiYK7qiDD0sJT4kHlRKHtZQvteIDcH6lttwslmq pcMSDuvTHuxzF8fiPgz4slggrWb4g+wAM+/4h2qoBWkQD/LIgdCqJsr6BzLwBoV5D/ljjwugD/mo GC44p/voDzu7MwEMkAEZGQoQBNsqmdxSukfwgYRoAkOAug4aoQ+KmZ1RLhZZLoPqGYRygy04BGqk xnfYgurqEaOJqKMxwRtSAKdRQR2qEhe0qZEaiIGgwRq8wX9wgRx8KbuZIgSAG7kJhUW4CJAgQn4I hVBgPJcQnH8IBiBowsi7CUeJQkixPAsrCqKwI6bgFGr7FGzbihH7im3Lqv9VMSTTSaRFMkMzlJU4 CMk0tAu5eL0ZyxU3NIxLUozayT3J8L3cmStlYRZ/A7hSEjjjM40kYyVBTLjZIBfcgDLqoz7hSCwU kLhnkJfmeAaLW45YoJfmKAYQcUppAJgQgIOEOMVsCB9XaLNsyAGR+weHgQ8aEIf5c4+KqZg6q7M7 A5BbZCd3iEuR8QQEDDSlw5BSmEojaAQOsoJjHKFTYAYKsUAVacaewRmtGwGE2oIhaEzHHAJdEDtA 2MZtJDsUFMcmSYY0+QdMWIEWQLUeCE3RDE1eqJoZVMd1xEF45AO7uQh7kBM6ac2a0pMvCqOUyIVA GZQ8SKM1MkiEbByhiDD/zGNIploKpsAjPtqcaxOxERukQbpI00Ok1FMkalADkHyLEoiDNCxJkjRJ 1+kLvrA9HTsMxIgrx4AMINO3fsuMy7iM39mraSmNVNrJVmolV2o+Q5wl2ygCRTys6WlEX8I+pWRK 64mFL/uDaQgBMfsHKCAzgMmG6vgHa7iAENCEhMAB+0GPHIi5f3gY/PGFs0zLWTwnn6uzt4RLuJxL Xiy620q6u+wAK6BAFRAD4vJLCQShBmQAQ4i0FnlGGtm6hKoRXZhMQBjSDCBSbixBGiKvtCsvjLKS jWACPUiBLamSCugSL0GijZgHYfgSdNS71GxHNokiwWNNX0uIebAIjBgw/1cYhpyyzZX4hlAoI0ZQ FDVysMrjCQqrMCqUnIZ8SM3LIxOwNuVUTooMvS/MKrLwtq7qKnILqxc7t5DUThlbw3fTFUkCDJX0 lcRQDMbgpE6ajDAIPjQgsuKLT/n8q+RLg+YhRNqQDURwMtyYnqHEngiwPsZqrKVsSuYYpnrpoX8Y BDKrSu0AxX9ohmbgl3+ABlFMmAu4lzIQRVUM0fmwGIuBrZ8DOgJ0EJGxLRcNNJbpg0ZQOQZohOJK tEk4BUPYiEM4BQz0UZ9RTBWqESI1mm1MUiOxTHB8GnFMgVG4gYSwhvXyKC8xqWRAr3+QgRb40oGY gRmwQdUUPJgaPC0KBf+A/YcV6BMEELCNCITaREIkZAQg6CGc4k08/U3grLDLqyPjbIqmgopq+7AQ Q9QvhIVtu1mbFcPp7MjrhIsSSLcS2AQ1xJWzih3aU6u2WozbUQzHeMl8K1XKeJY+DDjjQ75AFERW hQ38bJ7nmSWv3Q1bvdWI26WklBd54VUUGCZMtJeEaAaPeybzSwg4OLPxux81MwKD8QX4WMV/aA+1 LCD9AFz/y1YCCboCbBDEPRkEeQRwVUC87Lp/QIJH8MsPGiExcION4wcVYJGe4QFHQEx4ldedKdIh HVIkvVcb6kYaSkHWFccW2LgT+CEqnV2T0oNk2AgP0APUDFN35C//oin/BNACIBiPSACCkMiD4+KE PPAbkBWjPHivL7rTmYDCnNiJndhTPlXZOsq8zTvOPOo8LpyqqqrZEtPZcKNOsDo3dPtZ9l03oi1a vtBUZQiWxRCM8mwMZJErUKKrUOKMzUADgeMrI7Pa+rRPVwWXA4a+rx3KWrVVAMU+5zjbAp1EDACf Zlof7aiFGPgN/fkHU8jQhPGG82NQVJxWVrSYAzKgjAHAE+WYAqSAkYnhXnzR4YrRINiIJ1CBU1C0 STAEJ8DbhBgDd4W0q8vAZ7yRxaxXe61XfLWDT0uGi8JMBdADfaga9gKbgg2bFtAR+BIIhn1Yduxd mKob2bwTLQCHhPBY/0ZYBC3IgzwAI9tMCTlghDyoATQNBTuFiZtoo554lDiSMMj5U6ZaqsuZiqaQ SPGl2UQVi60aQ549wxfLzp8NyZOEHdihnUQYDPtV2sPInU1CjLnSHZq0DFIaHpz0Q51U1atl1a39 Sdvo2ukD24dbF+JoxGmwgWlISkiMxN94yi9bA/f5B1dwpmfSDrotRX+xWxrghvPx4IehARBNCCK4 hQsoA2u+ZmwuA1qwRQYakF+QS5FxBwjpRcfVEAwRAydotOVgAhUwBDFQASd4gTyxAENoRmc0qBmJ 18U0XSOdzCPFVyX9hyZAhhZwAzdItYNetfVSgGRgR1UY2C3Zkvn6Ev9hoJqEaCm9q4KGqAKIbUd7 6C+YKmN81IJQsLV/iIQVsActAJzmRcJvWIH3koI8iIkGg0LKaxw4wt5nuzBpc4o7sgqpYM4/WmTn VNTo3FkX+0iQ1M7sZGrudJ2z0pXAQKv6VdphcUlj0Z07bBaodU8iAw0BLh4kW9XA8pYEdmXp81rh IEpbreWxzeWldA5eVZ/LmqyTe6YB0A5v2MRmMo/TYrmAfeZMyIRyzJMX2OZu5jN3+IUYXpCSUdwH YlwFNOfgemeV2wgLcIKNw2wO+FzDLGJ8jlfRTShdGAEltteIuqEi2YdysIDCTogDaAEFaIGymVIu wdIrNSmDuJcayEH/h23YjnYBeyBTMgbekS7pgI0CIOiblAgjRggFIBgGlZJpmq6JyKOJB2M2PXU2 oqjC4twUy6kK5fwUivwjrviKsMhItGgVMvQqF4NU7VzfTZjvTahkveAVTb49/OWkYzGWZZmM9rQM Z8krsM5JbNkGVeXJV2o+cQmXRJy+WQ7bCCCFsDQFFAjQXE5K51iDDf6HO7CsSYymCxpW7cjrAQi5 PDlFN4O/AVgzNJOY93Dx156AB8gz2lpsAeGzBvEEHoeQUsDKf3iBDJrslukDdJbnjfgByHWoMTCE zz0hg8KZI76RQqA6IjXdf05t1f5GVHjthGgv0pLtKsXSIpovDwiE/4SghxzM6IagR1Mbboo17ju5 x8AZhpDahRsAAj3f8xXQgb5LiCiYaWRbHDZinDxNqqFoyMxTiqfivKt49Kygqs8hpJw9sfVOi7JQ nVhZpEieVPYNWkvdC0v6lcG4sfptjE/t75lkFn0LngE/5QEuDQLuSVcqxNkoAkR8nnIBW7amZeJA ARwgAmggBbhWSu8BdiJ4BuzAxDUoBhmQgVjIhhJ/pmzghhgwBSJ4gWZo1hVXGG6AA1cgADaA8Q/w BSowBSNId3Vf93WPhv7r5gCRywYR59x6BXoyhUawAhoeLpcRAR+GAxn4gSdwAlPYBQY4BB1GkWb8 XA2MV9FGBSTgB/8LeIfTRt0tR5IMGAVmkAF273gj4Ade6Jpk4IVg4ATb9qjcnui9AwVMYJuG2Ogq wAZsyAIGyAMpEmmaComN1YBvAIL32ogJCAB+uJcmWoFQoGnpZaNGQcg4mpRnW3QM05SITE4vPFRt s8irIp2uUrGvegvrtM6QRDemZt9NaCSoLtpdyWR5I3W2qkPF8O/eEdXMKFWpJT6+4qtUIuCr1dqz Zh5a4nVZbuvjaAUUIAUINvbI+oMQQIFrwETwi4Vo3w4TR49qh3xukFaXe7myZANvYANxqFb68AVv uADSL33Tv4BGaIQHeIVaxMUcHzp4in1fRAdceITJTTp9KvK/FIH/R1ABHRYDDmhnMbhAggrtFaqR IQjBd4ihfgboI7GhI0GFQpj+QlBohe4aBUiBZEgG3SXzIspiL807bPAAl58BmH+I8feAm0cAeZRz Ot/YjX1uIJiHWSD6jcAEF1iBnFKUmQAIOQ0GqhvYgAVCFn78KGTohwQJEBAjQgRhEYSJVBhTcczI MdU5fBxFnitZ0gHKlOkcwILFsmVLALBkwpwJ4CZOANRuUusZp2eJEnHiBC2xaVOiAomWMl0qD0Ii eV68SJ2qTJkXZfGcxevqTAA7Ac6chRUQBiy7MGjUhjHQ9q2BuHHT0DVAdxvdNEn05tW7YEGSJH8F //2LKMHfIgkS/xRpHCFCkceRI9ig/LjyMxvPpnGetrkzZwyi/4zG8Eca6tSpBwxAzXpAtmyvZ9Oo bdv2BxofdvPevY7Lh99cuPwa/uv4cQq/lFNo7s6TIEHQowtChy56hw7osnPn3ud7HxEiwosvb34S +vRL0PNwtGTJCPgj4s8focu+fUCAdOnXn+E/gP/ZMaAd5gxoix0KKLgggyko4CCEKUgoYTsVtFNh BRlW0MmGHG7Y4QydVDEiiSPywQeJJ/KBAIsttrgIAovIOKMGi2jwTR5A6LgjEHmE0oAcQQokkEEH FZkQQwmR4NBDFUkU0UUWmYCRRR99JFIq+JgU0jkOdNklSi7Bkv/OmG/UdGZMOe3U001qUPPTm9QU FcdRQfXSFFNQQSAVBFT1SVVX8Vw11lZjiRVPWexUgkYllYTB1lqPPioXpXKlYVdffQU2mGCEFWbY Aocxpphjk0F22WU2qJqZDZ09s9lmoskq6x+12nraaqxJM9trstF2G7Cf6KZbb8Gts46xxh1HXHLH uUOBO896QoEn7lB3rXbZdpcdeN2CZ155k4iQHg/pofceuvLJV199uvDnn38BCpgBgQTaouC9DT7o 4L4T+ltBChdq2GGGHHZycCchhjjiDCWaOCICK7o4MYszWlyjjRporLEcuWggJMhEFqkOQg2o49BE CkHUpJMWQXn/0ZQYeYQPliNtuSVKJ63kQDpkjunzTEGnmRNOa/bkU1BDBXVUL0fhmQgEUCXiRdRT ZYVVVvF4MZYyX4k1VljsiF2J2Io6ypaklV6Kaaaa6hUY3J96+hdiCYg6amSmmkqZqquu+upnoE0z a62mkaaaarPtyivjwNaWG7HF8obsscQNxyxyyUW7ubXWRnddddltt20H3no7Hrjmmlsuuu7Rx267 7/KnC4DxyjsgvQcmeG++DOrrL4UBa4hhwQYjnPAMyTtsYsQmSkwxxTRivDH1uYQ8ZJBAEmSQOiQn pBALK080kUQXvRyllB6ZgKWWIJWET84pyT/mS2fSZJOaahSt/9ObP/0k1NJK0AujlEApTZEH1KAm jwX2SR5XeeBWtKKVeAiAgmBBS1rYgYa0SKotcvGg2tpGl73EDTCb+lRh6iaqwzQmb4954Qv71jfP tGoaNewMrUgzGtTgCnGM+yFrHHebT+zmE0TsDXCOdaxfrCNzTmzOL54Vxc1N53PbEYS2StcHbnVr PN9K3bhU955JpAtdsHOXfdx1n/4AQl4Cwl29BuS7OQJvX+0AHvEGpqHjHU95y1texKD3IovZSEYa yxjHPmY9IQ1EZCL7Hsm8h5Alja8i54tIzGCWEY+AhGY0yxKYwCQ/loTJTDW5n0zURLSeuOl/SSPg 0prmtDwl8P8pU3EgBLB2lalsZStfs6CiBLDBRT0KDZHy4KQqZRe2jTAvJIRbp1CYwgUshjGLQcSp YIiqynBTM6wSXGgwEJrCFY6HiNvV4hjnK2ANgAbtxI3kJgecD3ChiZh7IhSXAy3PCcIdoAtdFr1j uj5Y4TupE1d6wsiecy3BPfBZF37YtcYM2C5AdgBQHG3Ruzn+rl/Bq9CFiOehDvExYVVIXsMAWQVB uoiQhSwk9RJ5PSBlTyAFMQgLJLmyh7CskubTpAmCuslNflJLJjHqSUbJs56NCU34I5pOeAKn/hFl TkVh2iZK0BSoPAVqe7plVqzmBa9QkCtiCZvYBNAoY0oqUsr/DCEz+UJCv8wNhXVDzAJaSCq9wbAy jwHc38AJmtLskIenaY0PgfgrYO2GBkaMnLF2U8/LFcdymGPOs6hVrc5VsTpYJN13tBie0aIOXONS KA/Wo9oyvkei85ndfgAxhP7Ubl5xNJAC7pUgjipIQh6944QEpsfilTRhJl0eipgHPRgxN0YwqtEh Y/oxIS2ypkXaHkIkqaSesqx86JsSR2TWkStlyZNJVapKXFK/oN3kqTlx09Hi5EqiKI1pRmnanZYi tT0t0GpYy5pWxvKVAYdNAGhhFNk6qGAQUmptdWnbXt5WmLri1W571asLU9VXvtnQM+CU1eBIUytp jLiHrkGs/zoXa5t3OraIkqNcEi/3G3wiR1rNqZZ0/GlF0nHxdF08D0JVN4nUlnE+69LFENiln3e1 0Y1vjKMCdstbCHnUXwJLQYby+KHiIuykyK3CiQLJ0oq5FLrS1Vh1Q0ZT7rHgIAhJEkPEV8mWoY9K VZqZSGhmEi956UvyW4lT7ede/h0NTv5LGlGyelUC9iJqUrMl1aiywK5MsFBiufQF0aoWBC84mQ0O YTOfGbe6fgoxh8nrhSXT1256UzOtCpxg/xBiw+HKxOnsFWx+6E4WO9Y2wurNsZB4OctlTjn6xKy0 qngd7WxndD0eKHkOGmQhm9HIEMWPGkcQ29ne7o0Z2IfuFv+00QX5FnjBC5jAhLtHhIEIpSL6I5jH TGbnSk96Mt1YkBbZSO1dF0lx5u74vNuyoIp3vKkwwTk4cjP5+blnPIMJ0E4JVZ5Qw02EBgqiFy3A pc0yKlHxQlT4RJWraC0rYzFDWQ1lYDRkGm3HTBuD45qpwLzthJ46YahCNSpEtDCbqo4h3wDnmczA OjSdKZxpSKz0c94a17pmLBGPOLnJCceexXFicqDIWeiAzjodCN3otrhF0f74POIRVxiXwAPWEdmM 177PfNgIr27DMdy7lTK5e2tuK6v7Q1subhVE5McUgRlF8o4RmTOmeHzLQQPWmy7I+D2QNh9Eu0ya s5Mynz7/9QXVSli62Z7/rN6WRLy9Q3svxeP7plcqrSgbZ1p+9eToBS5wl4HiSlkDZeC0qlWDxOz0 W5eZBrw405nQ7BTOU4gIavIcw9rUpgxtQIpWEIMYzSAGCooBDxyCeBoiTo2tW6Or2fgKiI6Luot9 Q0/gDOdYhKDEA+L/AELoM4q0eEAjHkCJaE3nFaVoRCM8wiNwx3ZYwSMA4CMUlI+Zlrk4AgdwwCm0 B7qQUWsNwTs8YJLVByBoG21xG91BmZRtFL84SDK0QAskA98JT5YNF3GVVOBVATY4zInYQx7kgRZo AQ3a4IsgHr0hkplVTy6kGZGITEF4TyR9T/iEz5I0iXd9/xfMHNxHcFJ54UwooUTPkAkWosn92IRN rMnFuRJVbQKdGEVWDRDsIYVThBxW7FJYCYqgCJgvGdjuCRNYPMrZKJhbqE2DidDxAcaESVM1FQHP LUbeTIZjWAbfRMAznAE0dMEE/MM/WAMdxAAKwIM4jYYOIZ052Ro6KVY78ZoQFQvlIEs9CccqPAAz MEAABEAXkAMtKMcrNIIFyEIAwAAzPMIrPAcuOMEeBEEtnkAj4EIHGCA5dMEq7oETiIEClpZpKRQH 4EEw1MAQsE6RnUINBAMecEC7cCCSNVmTeVsc2QGCRFlu+c4ItsAyrGIboCBwhZSWDYzxlNTggVmK 2MM14v9BHtgjNubBIF0MIf1gyEDevomMyRDEm02SnPVUwNVZ5zXkR5REebkPzvwZKUWc/dDExMWX GvgPfbmenShaL4SkSCqQyEnFA1lFBHWFHFJQ2RjYorBVpyETgz0YhNXcqKEQYZhaNS0GZLjQ3qSK q5ECNLgCJBYlJL4ACgwO4dgK+PlQ0+laEAnR4xhRbqifsBHHA+yBUULiE9BCLMLAVu7BIwgCLpDD D2wlDKiAFZTCE2zlDxyCGHxLtIWLuagAJFrAKTRUkY3AKVgAJG4Bf3Cj3M3WN96O7vDOuOldMixD UTYBCvIdC8ajC3oZIK2IPbgAJAKBPdxAZiaeS9mbTDX/3kytGXblVE4lySQppMDVmRNCIUm4j5bk jJ/xjBW6hEXiz6C1ycXFiZzIiVAoWlaBpEiOZNQgEO1lhTy4YS95je6xA1m8pAZpENokk6ctk6U4 WPH14WBIEwrxnKiUyvMBpaqgAB1AIhz0Qz8MwiP+AzRcg1KKmGgYFtN1omLt2vk9TvqJ4m8IByUw AyT6gBOQgyX8wwGUAS345T9IAjL4ACSSwys8AgP8Ax4wgxNIAiSKpQoEwD9YgggwAR78gw8YAnkY FJCZiyFYgAUcwhCwlnwMwSGg6Dvch7uwkQdalG0dyDhylG89SAsEwT+owgo8ZjtayHB5iGQeV8Ok lAxW/8FlZqYWcMIN3EAoIN5ngqbjiWa+qdm+sdn3OAT4TERPuczLTAmZRuH6rA9SgR56rYTPOIAp wUR7rRL/SJXqKc1Q1AkZ1slwhmQCSRrVVIVWjJUvWRBXeA1YsBynOYpbvQUIXcqDsU2E8QVdJV+p hYpiXJNe9eTzsdqrEAMkbkAzwAM8hEAMfGoImEYIoEAz9EMshMAa4MoahEAsNEMzxAI3lB+v5AA3 xMIF9Ko3iENt5IA3XAAbZEJwsMEFPIAvZII3PAAbIGsZFKvlPEAX/MMElMH7+ec/MEMj+KgPNMIr OMEjdsEDOIF5JqAKXMGGqkBb/sMYlIIhwAEkOgG4iP+BIaiAITiCeDiCIXCAIZzCFmxBvjogBwQs Bi6BBQZsBg5BOQTsFhTCO/zHPrxDIZQDKhSCCRYCKtQLOfZWCZpgC4yChIxCD2TBP7RBD4ishFiI HiSDBwhDCfZACwiDHnhAD9ysByjMDAiDzeJsDJqIzfZID2DmPwCBFoSCjnzDIhxtjuiIj2jB4m2M x0BeTQ3JdVUeEi4EJckZRZDPmEpJR8wMSCgcUvGZ2dbmwwVaTOSm0egEnJSAb8JSUZghfg2nVzXQ Le0SyQmAMhiY13jN2BgTB0knXASfdfKhXG0KqaWQ3QxiCzHGz22qDD2Dp/7DHUBCCGhfK2iCJlQD Kfz/QSwQgI/+wy5IQDO86ho0wwvsAiTKwiDEwg/lwAWILiRaQxdQgS8I6xUEQz2wwSf4giRgY/xd gT88ARywrgWwwX4+gCyA6AP8AiGY6z9YgPRaAC14wgMwaACowCDMqxV0wCPUwz8EgBNUKxGopQhU 7ymIx3cYwhcEwwkYggjwAAcoAu9uATTWAMDugYaSrhLkwxAMwT0WwhCgQj4owQFAYhDcQCFkACrU gD9Ewj6A5T8EgQ6UgxzplgKMgj4gsALfQMheozX8ww9Eox7cUYUkgyL4wxx48C64wAooQe0qQQ9g wwx4QBSAwgwDAYrwARAowQgfQBtwZtHqIz5qQR64/8DoVrAOhAIj+GDjTRfVFomQ3FQRSlKcKSFP YR5DlqmVjAQolW3osekVtsR6nVJu6g+b+ETrvZKiCdBRxPGe9kJV7IkyONADVRrJGQpZ8B5abBrM wUXMOWpNjhDOLS41EaLjjsoL/WSqsEqrkCckTkAXDEI/oED2XQM8oMALQCIeyAAkkkEzZEMzlOc/ yMCH/gMchECusYawdnIkgvI/uALuXoCGdoE30AAbIGgZ2PI/VOtdKu9v0EI9dIEFUMIv0AIBNKi2 OsEreEIpLPMOqAASdEETPAA67OIX/AMDOMGA1oOI9oEKgPIehLN4GAJYBoEKtMcYQCIzbAEk3sAW RP8CJMqALP+AG7wDEW+BARPlKe8AJLICxHJmAEzAAZgsJObDxh6IAqCCPvhzFgD0P7BCC4gwCZtw SFVAC2goWH6BRG+zR0PiMniAPegAJO4AQv8AD/eADkvoNvevZhItEISCFHhySP9DFIQC9TSeEFrX 1d4UEoJPEiqhT52PE27SSOQZl/TZl3TJzozeGcPp6UXVnMIXR1oVo9kJfsFeSNZBA+VSWDkQSk6Q oWJa2fge8Bmug2FKpNacCXEn3bCQ3eANDJmKX931qnCGUBrBVprCC/RDMRRDqf4DAaBnuxJAM0hA JMZAM0ACLFNBDpRfDgz2C/TyBzwiHQwrEfyyN3z/ABss8z/08mYfgCwwQ7SuAnIQwv1RwiqUwhg8 IgyUAYI2QnWUAoKqAC4I4DCqgFZuqwpsc4h+x2+DqPySxykQMTOcgiFo5QQEbDy7wV26wRaY9ERz wD5zAFhOACBsgRuwgjsXAhHDADK4AXUvQzng1r0Ugg5PgC20QA94N04nQ8mebMpmyMq2wDb/wxz0 QAXUbjv0wAp8aBDYLOtOwQr0QCc8ohIkcUCvABBwwggXsUznAUAbOBCswCz8gxKEQsZE8ZVeD0Fu T0F06ZuRQBIWNUNunsE9JOj5mVOrRJg4FVR1oRfG1/9UVQC98QCF5CbMcaOJVVVojRv2bQWJjaGU /w3ZEO7LVSeoMRPchFoJSdNhIMLdKIbPbZh4/k1mkEIzDAIDrCck/gA0oEC1ksEt0Oot4MA/0AEk +KgEQAKa+8M/7IE3zIY3VOu11gYbyGtoX8Bm47Jng7ZoR2IZIPOMOZE7NMITjLArkMMDzHZ02DYk qoB14EIpOEGEzvkBAnc4D3eIhgsPOMEIh6gK+KgSFOxzJ7Aq6IB0S/c76DMkugF0/4MUcIBsuYGC bwERi8LGuoHJKkEhaNRu9QAkSoHIKkAPKHgJbvMUJMMdEalGb3MTtEAnzHcTeEAneMAU/MMXAIFJ /8CB58EKcKY1rECETsAKrEgewHdMZ2Yo3IAL3P+DjmD4P0xBHpwZiJMmEQb1QVLSQzwJRXSxUG3E +iS1nqkpjNMmU6HxVMup6gEFjtMJcJahSPZ4SIJBL4CBn+qSoBbqV1gQBh1YMaUFGrgFoyrT2sic 8WmnNAkiIVoTeBqihkXfDZHCGbRC5qIAMUCDBAzomkOChroCEawiEZxlANwCJAbD0AcAESQwLtu5 hvpALjtWGdxlGfx5Z382JA46AzyAcFDWcVBCGQBzEJADJRzovD5zNE96Nis666pyI1hBI0S9iIrA OBM3uBgCgzZ3O7srwMbzFvQ2JH7B/746EbvB4VNUBhTCtgcA4sf6gBQCswf7gowCEffAgiSD+Ab/ gAkyu5BiCH7XO7aH/hRgu7ZzewxH4hes4hfI+T+swDa3gQewSJNKeGZ+wwrMwRSAQjAUpb1njMeI Zppd1yNlV1BjHhfDzEZAoecp3FEZFUWW8W0KTW4WzcMPhZzYKcfRrcVf/HBWjS5hhaDs7VckCu+Z jXS+XB6+FSFDGDRtJ1zHNcxnmCNz06u4GqsUAxzgAA4ABAp48K4V63fl379bAf65IhIAIsQrtxL6 ewiRiJENbAYMoDHgApF/PrzRoCGuTEILZUR28faBDYGEZUKOfLCOS85fO39RIicrYZcyuDxRcJKQ GS5Bj/b8k9EIVyM4CQMwM2SljyEf/yw16tNH/8WOfzdOiTArYtIpZgmZsPoXRMWSLQlvcNjCxMex hAl1cLiR0M3ff24yAALEYcq/L4EBZ7BT6Mu/KYXsKLA8SnCPFJuTJf7SokXkKcnabW5XoV1oyR46 qZ7C2oPnFUr+WfsS8csXPCtEe0CAIJSLhECCDwcSjOqUNgynhNIg5/lzOdCnV5fTADt2dSwasPCu zo93EuPJlwcBYvx59SBSqTeRKhW+9/jO4aNfn/79cw7480/nIB1YBByQQAAEBADBBBGkhkEAGIyD mjgkjKOEEuLYpMISNumlwl562dDDEEOUh0RlvDgxnhRTFECAeJxhUQB22KmEHTTYCYPGStAII/8M A3g0AMggDUgjSCKBTAPJJNJQcskkkljAyQWknHLKBBJYwMosi9iSywi8jMAGG76M4BkbnjlzmmeK kSChGIqZBgMMYtkgoVsY+AcHSGKJpRlIbumnmQn+gUPPZi645ZYLcuioI2/uPOYCcWjg5omEqKiJ JJhk+qeMB0Ty4aZ1fuFi1F8IKcOIf3Zh5oFXKKDAk0asGbQUQRq5E4ZGShHMBydKwaoPpv6ZwAkR xBgDqbLMmmQSHlSIbI9Z/jnBELnoOsSCG9woxA0d/PlHli0EcyMfvt7JYIgt9GJAXMDseEy0Qiyz LAV9+BplsxbWTca1ZCqoIAXUKnCNtR56myH/NsWAkOKfYFbII48eVpg4jzsVAUILBPJw6x8g7BHu nxWW+ecHBIDIY4UsJMuDEYjzkCMX66pr4LoG1NGuO+909s4PEnouj4Tz0lsPBBPWgw8+fOJTeun7 +jtnv3MCdACWdKwmsEAFtXbQQWoAmLDCCC3UEMNNMPxwQxBFBKOOOkx8Ox4vnFEmHmWciUeAF19k J8YYw7ixkjB2FPzHwoUsEsnEmUwSyiinfPJJLKXMEpHKi0gggiIyHxPML8P8PMw0r4EmoV1iaAb1 GMSCoZlNB4gFBUiAYqCZLv4h4pY9B0gIjlo88oibTZ+4wJsygvgnAOItUayM4pfnFNMHdCr1/xda mnLlASfKaIR7Wh6wnQgnGvFEpVKcOOCfPZBxQoX2Gzk2IUlUcGKrAFSYZFlmJzGkqcgGc8RaYynX WLbAAWQ04S2MGcwWGBIEZBRiCzqgSyHG9S7ISCYZ87JMCxhyjB7waw50GUW/TnOafxGsAgZbTScS 9oUeXCIhLuiBB4BAm130AGRzONkw8DCc4oSMNv54WB4QkJA2nIweygkFdGJmnew80WY780N4WECe n5EHPegJ2nqMlor3IA1pSsuP0/bjgDJS7T/9EdAbCnQgA22tawx6EIUkVCEKZQhDJfCQ2UQkorbJ 423KoFvdVpQ3Z7DjkCzimwB0hAZH/mhwP/8q0pAmmTjFKSlKTspklaSEiARwyUpd2tKYQNe5Mpnp TM9IUyvYlBAZEEEGe3FTM+iQEAb4QCQHoEIIoOGK2vjAB7OShaJ+N4AcXKCWXKmHoP7xBF+woSn/ uIIPGDKT6FGPJ40QyV64aYFSkCMhRKiHWIKhglJYgJvcxEMjDGG7fzQBIWMpC/7oKQJHICshMODA EgKoLeS8sx6KSMgJKAiYd0hwWAHN5xbKUUF4YVCDKRgFQifQBoH+AwYtSAEJ/9VRgnVCha9BmGfy 4AGOKcKifLEHEKrZhDbMyocgWwHIvtAGBCYkCzdYAVWA4MSa1Qw7OxPqFacINPO4p2heNMH/Ur+Y inMsDWpRjVp/+mO1AA3oqgaCBYK2CscFfS1CE6JGhjSUoT12iI8hYlsvwNCLOngBkIJMkd2ccTcX 4e1FfZvR3wAXSR71CHGT3IYll9Qkx1GJSleS3AK41NhRkhJMYvocmmyQJsvCAwUEqOZe6BCDEPxh Df1wZ0LoAI1aSIMbVEhmUIjZkY8Y8wKjRd4TvJGJdVwgEnvZRT0ScoEH9LAJtODJcBuRzm6WghZP 2CwMyIGLUtzUuOu0ggpGewA4qIAHZ9EfszggrWaegp9z+YcFOJAPGHDTuoV4Bzr/sYUMlEMHm/2H EtyAincIpgXvSgZwR6FBBaQgGfHlphI0/5Ma4Pqro//yAHBhw2CEIRAPHuBDHqSAPqroQML2uAQo 9nKAKPhQMCcb2V6OcYKENGGn/8DDy6aTHaAG9Wbb+Q7PrHjFoG2Ri+4B446ZFlWqljGNV6saGrHG 1a12NUFek2NY7zhWPOIxrXpUa9vq4KG2nQhudlNRXWHUN0YKDg2BI5wkfXQ4IxGWsJrUJGLZjCVP OnZzj/WSmEhZJjRNA8+qnAY8ihGLfmiCAIPoBwqKsQZpSGMNIehHDCygp9MOQBq1iAUkBjEISHgj G8X0iEk+UTwLWCAGF2CDOD7xgQ88gAoWGESnaLKKVTygU4TA5k5ewT1b37oUr3hFKVTwBP8LMAMq HejAI+bXPmOr4H19sIIhsGUBJxhCu/TU3xDssgVDAHAJ6drCO4ZA7cDcgBnb7vY7trCFIQAiA+Rm xg20VYh92GEf5QANKsyhAFQUogXyiuh/RxgFdn/QNHoAjQdQY8IKdELgM5xBBbDhAYXPoOEzxEYV +ODwS9zgEnmwBx/4gAAt5OHiOiAOEDCmhVCQ/BsaCMVMXXCJk/kbCN8geR6+0eIW4yyKOWMBFcVD gioaVWg4PtpSlerF+DxVqmY84xlhAaCrpoONWEOygqihBjUsOUJMBtuF8ojWPvaxylT2AtwImTcW JVKRM7qRjXako7++XUhEQtKQ0HzJw0b/DkpuntwnG/vJL2mOc2A65SnxXPjCYwBOfyjG4jHwB2k4 HvKIDkE2Di0NSHckByGYPKMY9VqTnIQb3MhEqT9RalOvgg2+WMfqcZITUk1vJ6+igDvcIXt3CAL3 6BCE7nddClygQ9jC/srwif8VtIihFKfAn3bR0qxJLKFZS8A2P0ewhBFc//pDsC8qRqALXRgG/IVB l33fsQ/HvOtdCkC/f9m/mRToYRT4cn9p2mFwg/+rE/nP/wz0n/8qVGEG/k8AsUELhCFjfgMBOs7j vsEeFuE3FgECIVADJFDlQoERNIARvsECYUYDciEXsOPmaCY71EHGcqZndq6KbAyLhoZo/86DqcCI aZImP8rojPhDQNJI6gbkjbTGa7rGQShEbO7oQsgGbb7OQ9rKrZCQbdzmROaGy/AKRhYpRmakEgJn cMoMSMgMcQYLzTBpkzaJzRLAcrokzgIvsjrHTMJEzwyPDeMkTiKv8irv8jrC8jiv8zrvIz7PJD6A BkiPD03N1NbhAwQxJ0TF9Ugl9ijgFxSR9mav9tzBE9BB9ySREoEv+Dqg+DLxLDaRWZpvu56PB/hJ FKuPFLHv+rwPFcEP3QwjA1rRFdFv/SzDDmyB/SIqBf7L/eav/gouwQ6u/zqB//yP/wSQGKsAAYwR AZNRGSPQASlQAyYQGp8xZp7Rp2gGqP+2w2ZkLDy2keeMKj2EzmiWij3gYz6eSoyiij6UrgabjmrY sWp0sKvikeqwTkLCykLoqELOpqyMUK3Ypq3aRpDoZpBa5OzyZpHQQAAcye0iyUcAy8wQR3Hsbkke JwzdDBFASZQ2Z844Rw3PpLLYEM8QD04a7w3/wCTjECXtUCXzcNP0sA8/4BNowNRMLxABkQtEpfWG iycUkSdp7xF3zx0qcfcu8RL7ABOLTwSIDy2Y7xP1Z/pG0RSxLxVV0RWr8l1a8d3exRa0citrcV5u ERdLIwXEMsHqz+A6oaN+kf9mgC2LkRgTUBnjshmZUQIX4RntkhqnowNlRgRDMKhmDAX/UVAFbyyL coyLkOaLnsqpoIaqGvM/rMYGc5CrJvOrAODq6LEeuy4fNYRD+DFE6mAJl5CQXOQJ8UavplBwaoRH HkmSHPJwtoHuujCTIKfNLgdLruSTtERz5IyUOjINVenODM8NEa/x/qA4Hw8lLa8OByDT7JAlXcsl XxIQp3MQCfH1RgURd3In3CH2aA/3PEEQgpISh5IoidL4+iApN5Epm5JZpA8qSzEqv8/7wG8IWhHd XtExzu9dzMEOzIEWvTIXA3T+BKYX0/IX+y8A2TIAiZEP/i8u5fIBmREaI/AZo8M6pMOJoKg7cgY8 em6KVFA9tihowlEcm4pp7MMcGVNF/xkzyN7RRdvIq5Ks6iAECO2RQrourfoICY8wCansrQayRUwz CtXukdzur8rMNc2s7hZnIu8usRagcjyJ7y7n78zwDNWQDdcQTkZyJOPk0BwvOetwOTuiOZ0zOvWQ JmuyOqtTJ2Av9haxJ2sPPD3h9iLREi2xKDHxKIcvKY1PPfNnu0Lx+bAN+6yvFHVhBABhPlnx3FjR Ku1APyujKyvDv8DyFi91/kyj/gKmF9ES/xB0GDvh/xb0LSnuNxRwGZsRAejSLp1RGiuUOmzO5rJj Z2RMZ3xuPEA0RImmi9rDBJTmV+0jaaQqas5oaqyqHWEh6pBs6hakQeTo6samjriObP/SRm2MEDTD zkcHiW7qCm/uikWqUADADEeu8EgPJ+7qLknWjDbx7jZ1UzcBD/AgC3TS8CPbMCSJ8zjDNA7nUCU5 70w5DSapMxBZ7wMKUVR2IjsXMRHp9PZw7zvHkzyFj2IzkU/RkxMD1SknwREIlRQNVSqvjz5X8T6t Mj8jVQH+s/3oBRcDlP4KNC19US31bxjdkuI47kERkFUp9C4rFFZjlS9HUGdIkAQ91GdsTItuTOjc 4z1AIAZNAD98jDHNqKog86qStchitGsuEwjrkazKSsrS5kN0NDR9tA7GYTRZxEWGVEcSskb8Cu7Q 9UjmTjbV7LAQS7EYa0umdF41cs7/JGuyDC84QxLPjNMNTRJMU3JM/3XTWlIP/3AmqdNgbxL2rlM7 4dQ7wRNiJzH3ytMov2JP0ZNP1bMTP5EHAOj5qK9QTVE+v09RqbJkWxFSI7U/LUNlK1VAc1Esd7FA D/QXiZFUKc5Bb/ZBmTFCJdRnoWMvPZAvX0w7WMBWd24bvZEFWbBoioboyHE+js4+9KMGjdXpoK7I pg7JsG5G5+ge6chsiHCPrvUI/9HKzNau8gZcXYRvwmwhxyxu445/B4tJvZA28y4MreTN9nY3OfJv vWTwBFdLiXMkETdx5XA5F3clTQI691Am/zCDCRYnVk9hdZInHfEnvfP2JFEQyhOF/y32T6XNE50y FENxFEEWUU/xdWsYEM6tKl8RFitjFr2SZVvWNEyjo3jXFw8uLdcyGBc0eI2xQRMQVSGULifQVSvU Ay20GkUwG3VOPGgsBYGuMK+XqYwGe2VQjGZQaqvKPwZkWbM2yZxVyR7EQsKKQb5WH92XrcAAj7O1 bZawDrShDu7qRYRUr3QkR97OcLCwkrpwXZsk7wI4sXBzSzwpc3gTsiLrcyxLz/QsTrq08aShOCO4 XxkXYPOQlD+PYE959QrR9XRyuGoPViAx93avcyURhYMPKTF2hU03dZ/yPaMyUQ3j++xT/PBzdnd4 Xii1Ft3vv+hPiHnx/owYLWl2//+AcYn/r4lzNhkhcFXrEi999mdlxnn/Mnq3cedy9Yq06ItbcIyJ Llihilipdj8e8zGb7qrYmAe5hkHUoB6DcGyI0GxylEfZyq2qjI99VBu2TG8SiUZqJHBuxJB7ZH/l Tl2ZxG4dOQwvpwguckq9pG/p7HMiq0wsC1/19SQxADlBmfMoeJQd1yVNTToLtvVSeXoWdhFd+VUe ETwlMad3D0+L0mIvlhObr4VheAmI+vpUF/sUdVELI/wedXYdQ/3UD5mT+StdVlPtD/9kFlSBEQBt tkGfGJu3eWe9uQPzsnlBMKj+Enq5cYq6+KjUORwRM4yilq6Llaqs6garpp51cAf/t+aNsw5C7AjK ctSO/ahHqawb2kYb7IrL0E5GYsQKH7oh0XXu5taSFsdu26xKCDiSyVDO6MySzWQa7rWBh9MNkZNf Rdk5Gzc6XXpgNxgQO1iVEXFhZe8XfBKWBcETNLcSKTFPjxITzQJjMZaFTdcROJaXfTlkv28EmDqH TRZSYdEWptuHLTV3x9IsCfRTDTRUA1BUGbRBTRVnc1abx7pnYVU6YqaJZvXFuCN6xaOtqRfHljaM YRCM3lnpGhNA8loytVYNLHOOnMxr8/FsQKSwQTN+/1EbFrwOErtF9IZtZQRwxOyhkzQ2Y7OwDItd Icdd9+6TLrKxJtlK6/U3QZJw/xPvk8EUlJVTpe+wlFt7g1mPEFMZO1dZJ7mzpmdv9jbXhHvalik2 dIElPZelhfXndDn2Pa0PZLuvhpf6uaObdtPPh+lFmV3WLEujd6PZd7vaZpHRmslbVetSirs5OnLB rGX1iWqGO7SYZ6RXV5fWBbmI6E7UqbzXru9ayPZaq5q1B591yWi0yfJofT0zoO94oBV7HBD9W01z kWSERir8kB8Sw9Mss6WkwyfHcsaQo/s2gdUwDfGsslLp8PI1xVf80PyVcV+LpT8vJv3wlCm39dyU lW+6Tr8zliexA/DUKG35p9eTPfnpyGN4yU8xUREVmJ37uaN8/W4Xd697M7Q7wf889UCHsS0Z9MsR EKyPV6xbNRrJGmamo4ms0cVoNYqkqGeKCujgnETJsejw4+jqY6ry2+mcjkCi7o2aFZ+95uogZI4D W7DBNh/5kaB5NI/7eMETWxu6AQrNzm2/bEfgdrIp27LVzO4sXYA320qw5HIKmNM9x5QuOdRRqQ2J 0zhL/iRTW5RV3fPQVCZlMk2nk8ZpG4RD+LZhRbdzT/dOmJZzXfg+N3QvFpf1p4Whj1l4IHWhUsml snUZdZidGmXrjdm/0hZ1cSzHEmYNVC3/77uLUQGzfRlXddu53Rn1Epx/SkPTWqh+bjCVVmjUueh+ VQbhA2rS0ccAhKqaLgfhkeoXuCbfvVbAnyytCvsz26qg26YbDh/xAwIAOw== --_005_6CCF0B32EEB49742A558E6A2BA50E7B6555C6ADBESGSCMB101erics_--