From internet-drafts@ietf.org Mon Apr 1 14:22:43 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C121821E80AA; Mon, 1 Apr 2013 14:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2woHF9eppuw; Mon, 1 Apr 2013 14:22:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39EAC21E803C; Mon, 1 Apr 2013 14:22:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130401212242.20227.46655.idtracker@ietfa.amsl.com> Date: Mon, 01 Apr 2013 14:22:42 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 21:22:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Additional Diffie-Hellman Tests for IKEv2 Author(s) : Yaron Sheffer Scott Fluhrer Filename : draft-ietf-ipsecme-dh-checks-01.txt Pages : 8 Date : 2013-04-01 Abstract: This document adds a small number of mandatory tests required for the secure operation of IKEv2 with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called DSA groups. This document updates the IKEv2 protocol, RFC 5996. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-dh-checks-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yaronf.ietf@gmail.com Mon Apr 1 14:29:51 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18E221E80A0 for ; Mon, 1 Apr 2013 14:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.537 X-Spam-Level: X-Spam-Status: No, score=-99.537 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, MISSING_HEADERS=1.292, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctuz2QyVVRf9 for ; Mon, 1 Apr 2013 14:29:50 -0700 (PDT) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 41E9811E80E2 for ; Mon, 1 Apr 2013 14:29:50 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id z7so1181430eaf.17 for ; Mon, 01 Apr 2013 14:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Wppg3yHymbllF8wEs0DbdCqgf8RaaQ+iTSJo6NSfwhg=; b=sqpwbwLmq/R/ZBoxcZu1qlxESMUQ4o2kGtKEsYO0fJhgewu3MK3r06RaGBMHiO5iPJ m5KBVs9dnEjl+KcVkDTP8QXeJN3hkXm4Lo+u1tqM4AjhDo35+hDyJImT0i1PTQoSDTsS MvCOjtG5Y2sPHdphr4QawL/Bz9HjTleik7qLYlXgoH3utTzM4Ede14302QkS6KqgjS+A Ey+QWfCtxkoP9muIjU8scblXlzdyS5KYNJbQUAE9JHkCzIoR23qM/rbTP3qPxnAzp5xx 0l5w6y7X/FvCDDec0iSauuLyWTTritO3r6BGFVtZXBq8cCNz28kGq7cmh5tH2Bxf+dhh dTJw== X-Received: by 10.14.223.69 with SMTP id u45mr2579842eep.23.1364851789366; Mon, 01 Apr 2013 14:29:49 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-181-109-111.red.bezeqint.net. [79.181.109.111]) by mx.google.com with ESMTPS id d47sm23394138eem.9.2013.04.01.14.29.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Apr 2013 14:29:48 -0700 (PDT) Message-ID: <5159FC4B.2010202@gmail.com> Date: Tue, 02 Apr 2013 00:29:47 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 CC: ipsec@ietf.org References: <20130401212242.20227.46655.idtracker@ietfa.amsl.com> In-Reply-To: <20130401212242.20227.46655.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 21:29:52 -0000 Hi, we have submitted a new version of the draft. This version clarifies the behavior of IKE peers when the specified tests fail. A subsection of the Security Considerations explains the rationale. Thanks, Yaron On 04/02/2013 12:22 AM, internet-drafts@ietf.org wrote: > > 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 : Additional Diffie-Hellman Tests for IKEv2 > Author(s) : Yaron Sheffer > Scott Fluhrer > Filename : draft-ietf-ipsecme-dh-checks-01.txt > Pages : 8 > Date : 2013-04-01 > > Abstract: > This document adds a small number of mandatory tests required for the > secure operation of IKEv2 with elliptic curve groups. No change is > required to IKE implementations that use modular exponential groups, > other than a few rarely used so-called DSA groups. This document > updates the IKEv2 protocol, RFC 5996. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-dh-checks-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From paul.hoffman@vpnc.org Mon Apr 1 16:17:21 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71F221E8118 for ; Mon, 1 Apr 2013 16:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPVdrzLxfNkP for ; Mon, 1 Apr 2013 16:17:20 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 08AB821E80FB for ; Mon, 1 Apr 2013 16:17:20 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r31NHICd066666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 1 Apr 2013 16:17:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 1 Apr 2013 16:17:18 -0700 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [IPsec] WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 23:17:21 -0000 Greetings. This is the start of the WG Last Call for = draft-ietf-ipsecme-dh-checks; the WG period will end in two weeks, on = April 15. The current draft is available at = http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-01 Given that this will be a Standards Track document, it is important for = it to be reviewed by as many people as possible. Possible results of = individual reviewing the document are: - "Looks fine, please publish" - "Looks fine, here are some comments" - "Has some problems, here they are" - Other things of that sort Many people on this mailing list are IPsec implementers but are mostly = or completely silent on the mailing list. If you are one of those = people, doing a WG Last Call review is a good way to participate = usefully in the WG. Please strongly consider (a) reading the current = draft and (b) sending a message to the list with your short or long = review. If there are too few reviews on this document, we could get = pushback from the IESG about the document. --Paul Hoffman= From kivinen@iki.fi Tue Apr 2 04:45:37 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4650821F97D1 for ; Tue, 2 Apr 2013 04:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, OBSCURED_EMAIL=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcK337X-ArEK for ; Tue, 2 Apr 2013 04:45:36 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7280021F97CF for ; Tue, 2 Apr 2013 04:45:35 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r32BjWcd022927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Apr 2013 14:45:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r32BjWHH026953; Tue, 2 Apr 2013 14:45:32 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20826.50396.636689.934107@fireball.kivinen.iki.fi> Date: Tue, 2 Apr 2013 14:45:32 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 12 min Subject: [IPsec] Draft-ietf-ipsecme-dh-checks-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 11:45:37 -0000 Btw, I have had some discussion about the MODP Diffie-Hellman groups used in the IKE in the IEEE 802.11ai mailing list, and during that discussion I did notice one more pieces of text I had completely forgotten. The RFC2412 which defines the original Diffie-Hellman MODP groups used in the IKE has following text: ---------------------------------------------------------------------- 5. Security Implementation Notes Timing attacks that are capable of recovering the exponent value used in Diffie-Hellman calculations have been described by Paul Kocher [Kocher]. In order to nullify the attack, implementors must take pains to obscure the sequence of operations involved in carrying out modular exponentiations. A "blinding factor" can accomplish this goal. A group element, r, is chosen at random. When an exponent x is chosen, the value r^(-x) is also calculated. Then, when calculating (g^y)^x, the implementation will calculate this sequence: A = (rg^y) B = A^x = (rg^y)^x = (r^x)(g^(xy)) C = B*r^(-x) = (r^x)(r^-(x))(g^(xy)) = g^(xy) The blinding factor is only necessary if the exponent x is used more than 100 times (estimate by Richard Schroeppel). ---------------------------------------------------------------------- This directly relates to the exponent reuse case, and thats why I think it might be good idea to include pointer to that in the dh-checks draft too. Especially to point out that if exponent x is reused too often this kind of blinding factor is needed. Btw, Appendix E in RFC2412 also tells how those MODP groups are generated just in case someone has missed that and is interested in it... -- kivinen@iki.fi From kivinen@iki.fi Tue Apr 2 06:06:35 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A69F21F8E4C for ; Tue, 2 Apr 2013 06:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rTCwe0y9jil for ; Tue, 2 Apr 2013 06:06:34 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEA421F8D94 for ; Tue, 2 Apr 2013 06:06:29 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r32D6Pvp010139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Apr 2013 16:06:25 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r32D6PgL001054; Tue, 2 Apr 2013 16:06:25 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20826.55248.860637.210630@fireball.kivinen.iki.fi> Date: Tue, 2 Apr 2013 16:06:24 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 34 min X-Total-Time: 33 min Subject: [IPsec] Some comments to draft-ietf-ipsecme-dh-checks-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 13:06:35 -0000 The section 2.5 says: ---------------------------------------------------------------------- 2.5. Protocol Behavior The recipient of a DH public key that fails one of the above tests can assume that the sender either is truly malicious or else it has a bug in its implementation. The recipient MAY respond with an unauthenticated INVALID_SYNTAX notification, and MUST immediately drop the IKE SA. ---------------------------------------------------------------------- I think the "MUST immediately drop the IKE SA" is wrong. I.e if initiator sends IKE_SA_INIT request out as follows: Initiator Responder ------------------------------------------------------------------- HDR, SAi1, KEi, Ni --> and the responder gets it and starts to generate proper respond message (i.e. starts to do Diffie-Hellman generate), but while it is doing it attacker M sends faked message back: <-- HDR, SAr1, KEr*, Nr, [CERTREQ] where the KEr* is generated so that it will fail the tests (i.e. sending all 0xffff...fff as KEr, which would fail the 1 < r < p-1 check), then using current text the Initiator deletes the IKE SA. When the Responder is ready with properly generated KEr, it will send its reply: <-- HDR, SAr1, KEr, Nr, [CERTREQ] but it is too late, as Initiator has already "immediately dropped the IKE SA". Also these tests might also fail during the CREATE_CHILD_SA exchange. I think the more appropriate text would be to say: ---------------------------------------------------------------------- 2.5. Protocol Behavior The recipient of a DH public key that fails one of the above tests can assume that the sender either is truly malicious or else it has a bug in its implementation. If this error happens during the IKE_SA_INIT exchange, then the recipient MUST drop the message containing invalid KE payload. If the invalid KE payload was in the IKE_SA_INIT request, then responder receiving it MAY send INVALID_SYNTAX error back, but it MUST NOT start creating any new IKE SA based on such request. If the invalid KE payload was in the IKE_SA_INIT reply, then Initiator receiving that reply, ignores the message, and continues waiting for later messages containing properly formatted KE payload. If the invalid KE payload happen during the CREATE_CHILD_SA exchange (or any other exchange after the IKE SA connection has been authenticated) and the invalid KE payload is in the request message, then responder MUST reply with INVALID_SYNTAX error notify and drop the IKE SA. If the invalid KE payload is in the reply message, then initiator getting this reply message MUST immediately delete the IKE SA by sending IKE SA delete notification (as an new exchange). ---------------------------------------------------------------------- This also requires some changes to the section 3.3, i.e. replace ---------------------------------------------------------------------- The behavior recommended in Section 2.5 is in line with generic error treatment during the IKE_SA_INIT exchange, Sec. 2.21.1 of [RFC5996]. The sender is not required to send back an error notification, and the recipient cannot depend on this notification because it is unauthenticated. Thus, the notification is only useful to debug implementation errors. ... ---------------------------------------------------------------------- with ---------------------------------------------------------------------- The behavior recommended in Section 2.5 is in line with generic error treatment during the IKE_SA_INIT exchange, Sec. 2.21.1 of [RFC5996]. The sender is not required to send back an error notification, and the recipient cannot depend on this notification because it is unauthenticated. Thus, the notification is only useful to debug implementation errors. Also the Initiator getting reply message back with invalid KE payload should simply drop it as it can be from attacker, and wait for the real peer to reply. If the error happens after the peers have been authenticated we do have a trusted channel to send the errors. In that case we want to tear down the IKE SA as this kind of failures indicate there is something seriously wrong with the other peer, and clearing the IKE SA and starting from the beginning might help. If it is the responder failing these tests, it can simply return the fatal error notify (INVALID_SYNTAX, see Section 2.21.3 of RFC5996) and both peers will delete the IKE SA. The Initiator does not have this option, as when he notices this problem the exchange is already done. It needs to start new exchange to delete IKE SA. This IKE SA clearing is mandatory as Initiator cannot create the Child SA based on the invalid KE data, and other end already created it as it sent its reply, thus Child SA state is out of sync. Most compatible way to delete IKE SA is to just send IKE SA delete notification, even though starting new INFORMATIONAL exchange and sending INVALID_SYNTAX notify could also work. ... -- kivinen@iki.fi From sfluhrer@cisco.com Tue Apr 2 06:37:01 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B20B21F8867 for ; Tue, 2 Apr 2013 06:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7CgN5n7zv4s for ; Tue, 2 Apr 2013 06:37:00 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E506E21F883E for ; Tue, 2 Apr 2013 06:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7248; q=dns/txt; s=iport; t=1364909820; x=1366119420; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TqXz1TteJZxevPsYNGIu4qJ3uZ699exg9blwDv3aHrk=; b=jRLs8moGV8z7huwgWmwUC0IX6SXshMrxGrxWOCy+K0LPDthKrFPd1z4h 57WCJa7xHSWikN9/Os4GcbcMKmOv/oQp6QpuIxSIPUrkiRXajsRzxoJAg lHzrXmaOSV4/p4JUX83VXYAjhf843vrh/GOaGNT7mtcI2PaoGWwVYRPwA I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFACfeWlGtJXG//2dsb2JhbABDgzu/Q4EDFnSCHwEBAQMBAQEBJBM0FwQCAQgRBAEBCxQJBycLFAkIAgQBEgiIBgYMsUGQDQSOeSYSBoJZYQOndoMLgWoHNxE X-IronPort-AV: E=Sophos;i="4.87,393,1363132800"; d="scan'208";a="194051640" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 02 Apr 2013 13:36:59 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r32Daxf0001381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Apr 2013 13:36:59 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 2 Apr 2013 08:36:58 -0500 From: "Scott Fluhrer (sfluhrer)" To: Tero Kivinen , "ipsec@ietf.org" Thread-Topic: [IPsec] Some comments to draft-ietf-ipsecme-dh-checks-01 Thread-Index: AQHOL6MLS81K9s92YEqIKsk5DhTTIZjC6Ejw Date: Tue, 2 Apr 2013 13:36:58 +0000 Message-ID: References: <20826.55248.860637.210630@fireball.kivinen.iki.fi> In-Reply-To: <20826.55248.860637.210630@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Some comments to draft-ietf-ipsecme-dh-checks-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 13:37:01 -0000 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Tero Kivinen > Sent: Tuesday, April 02, 2013 9:06 AM > To: ipsec@ietf.org > Subject: [IPsec] Some comments to draft-ietf-ipsecme-dh-checks-01 >=20 > The section 2.5 says: >=20 > ---------------------------------------------------------------------- > 2.5. Protocol Behavior >=20 > The recipient of a DH public key that fails one of the above tests > can assume that the sender either is truly malicious or else it has a > bug in its implementation. The recipient MAY respond with an > unauthenticated INVALID_SYNTAX notification, and MUST immediately > drop the IKE SA. > ---------------------------------------------------------------------- >=20 > I think the "MUST immediately drop the IKE SA" is wrong. >=20 > I.e if initiator sends IKE_SA_INIT request out as follows: >=20 > Initiator Responder > ------------------------------------------------------------------- > HDR, SAi1, KEi, Ni --> >=20 >=20 > and the responder gets it and starts to generate proper respond message > (i.e. starts to do Diffie-Hellman generate), but while it is doing it att= acker M > sends faked message back: >=20 > <-- HDR, SAr1, KEr*, Nr, [CERTREQ] >=20 > where the KEr* is generated so that it will fail the tests (i.e. > sending all 0xffff...fff as KEr, which would fail the 1 < r < p-1 check),= then > using current text the Initiator deletes the IKE SA. When the Responder i= s > ready with properly generated KEr, it will send its > reply: >=20 > <-- HDR, SAr1, KEr, Nr, [CERTREQ] >=20 > but it is too late, as Initiator has already "immediately dropped the IKE= SA". How is that behavior fundamentally different from the behavior we would get= if the attacker inserted a valid, but different KEr* payload? In that cas= e, the tests will pass, and we'll perform the DH, and come up with incorrec= t SKEYSEED. If the real responder will then send the correct "HDR, SAr1, KEr, Nr, [CERT= REQ]", well, the initiator has already received its response and generated = some SKEYSEEDs. I wasn't aware that it was a requirement that the initiato= r create multiple SKEYSEEDs if it happens to receive multiple initial excha= nge 2 messages. For an attacker's point of view, the behavior he gets by sending valid KEr*= payloads is even more advantageous; he has not only prevented the SA from = being created, he also forced the initiator to do more work before doing so= . >=20 > Also these tests might also fail during the CREATE_CHILD_SA exchange. There isn't a real requirement to discard the parent IKE SA; of course, we = can't allow the creation of the child SA. >=20 > I think the more appropriate text would be to say: While I don't think the below text is wrong (except I would point out that = there is no security requirement to discard the parent IKE SA during a test= failure while generating a child SA), I would also point out that these do= n't appear to have any advantage over the current text. >=20 > ---------------------------------------------------------------------- > 2.5. Protocol Behavior >=20 > The recipient of a DH public key that fails one of the above tests > can assume that the sender either is truly malicious or else it has a > bug in its implementation. >=20 > If this error happens during the IKE_SA_INIT exchange, then the > recipient MUST drop the message containing invalid KE payload. If > the invalid KE payload was in the IKE_SA_INIT request, then > responder receiving it MAY send INVALID_SYNTAX error back, but it > MUST NOT start creating any new IKE SA based on such request. If > the invalid KE payload was in the IKE_SA_INIT reply, then Initiator > receiving that reply, ignores the message, and continues waiting > for later messages containing properly formatted KE payload. >=20 > If the invalid KE payload happen during the CREATE_CHILD_SA > exchange (or any other exchange after the IKE SA connection has > been authenticated) and the invalid KE payload is in the request > message, then responder MUST reply with INVALID_SYNTAX error notify > and drop the IKE SA. If the invalid KE payload is in the reply > message, then initiator getting this reply message MUST immediately > delete the IKE SA by sending IKE SA delete notification (as an new > exchange). >=20 > ---------------------------------------------------------------------- >=20 > This also requires some changes to the section 3.3, i.e. replace >=20 > ---------------------------------------------------------------------- > The behavior recommended in Section 2.5 is in line with generic error > treatment during the IKE_SA_INIT exchange, Sec. 2.21.1 of [RFC5996]. > The sender is not required to send back an error notification, and > the recipient cannot depend on this notification because it is > unauthenticated. Thus, the notification is only useful to debug > implementation errors. > ... > ---------------------------------------------------------------------- >=20 > with >=20 > ---------------------------------------------------------------------- > The behavior recommended in Section 2.5 is in line with generic > error treatment during the IKE_SA_INIT exchange, Sec. 2.21.1 of > [RFC5996]. The sender is not required to send back an error > notification, and the recipient cannot depend on this notification > because it is unauthenticated. Thus, the notification is only > useful to debug implementation errors. Also the Initiator getting > reply message back with invalid KE payload should simply drop it as > it can be from attacker, and wait for the real peer to reply. >=20 > If the error happens after the peers have been authenticated we do > have a trusted channel to send the errors. In that case we want to > tear down the IKE SA as this kind of failures indicate there is > something seriously wrong with the other peer, and clearing the IKE > SA and starting from the beginning might help. If it is the > responder failing these tests, it can simply return the fatal error > notify (INVALID_SYNTAX, see Section 2.21.3 of RFC5996) and both > peers will delete the IKE SA. The Initiator does not have this > option, as when he notices this problem the exchange is already > done. It needs to start new exchange to delete IKE SA. This IKE SA > clearing is mandatory as Initiator cannot create the Child SA based > on the invalid KE data, and other end already created it as it sent > its reply, thus Child SA state is out of sync. Most compatible way > to delete IKE SA is to just send IKE SA delete notification, even > though starting new INFORMATIONAL exchange and sending > INVALID_SYNTAX notify could also work. > ... > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Thu Apr 4 03:30:38 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F5221F9408 for ; Thu, 4 Apr 2013 03:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTkRo3Aj9OAz for ; Thu, 4 Apr 2013 03:30:37 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA9B21F9401 for ; Thu, 4 Apr 2013 03:30:36 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r34AUTVE008594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Apr 2013 13:30:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r34AUSIE020120; Thu, 4 Apr 2013 13:30:29 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20829.22084.868314.364667@fireball.kivinen.iki.fi> Date: Thu, 4 Apr 2013 13:30:28 +0300 From: Tero Kivinen To: "Scott Fluhrer (sfluhrer)" In-Reply-To: References: <20826.55248.860637.210630@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 10 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Some comments to draft-ietf-ipsecme-dh-checks-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 10:30:38 -0000 Scott Fluhrer (sfluhrer) writes: > How is that behavior fundamentally different from the behavior we > would get if the attacker inserted a valid, but different KEr* > payload? In that case, the tests will pass, and we'll perform the > DH, and come up with incorrect SKEYSEED. Not that much difference, but for those RFC5996 already has text saying you can process multiple KEr's if you want to: ---------------------------------------------------------------------- 2.4. State Synchronization and Connection Timeouts ... There is a DoS attack on the initiator of an IKE SA that can be avoided if the initiator takes the proper care. Since the first two messages of an SA setup are not cryptographically protected, an attacker could respond to the initiator's message before the genuine responder and poison the connection setup attempt. To prevent this, the initiator MAY be willing to accept multiple responses to its first message, treat each as potentially legitimate, respond to it, and then discard all the invalid half-open connections when it receives a valid cryptographically protected response to any one of its requests. Once a cryptographically valid response is received, all subsequent responses should be ignored whether or not they are cryptographically valid. ---------------------------------------------------------------------- I.e. implementation is allowed to fork the IKE SA creation at that point and process all of the branches and see which one of them leads to the valid authenticated IKE SA. I do not think any of the implementations actually do that, but it is allowed. The current text in the dh-checks would overwrite that and as it says the whole IKE SA MUST be dropped, (not only the offending message), that would open new DoS and prevent using the solution offered for it in the RFC5996. > If the real responder will then send the correct "HDR, SAr1, KEr, > Nr, [CERTREQ]", well, the initiator has already received its > response and generated some SKEYSEEDs. I wasn't aware that it was a > requirement that the initiator create multiple SKEYSEEDs if it > happens to receive multiple initial exchange 2 messages. As you can read from above, there is no REQUIREMENT to do that, but it is allowed. The text in the dh-checks would forbid that... > For an attacker's point of view, the behavior he gets by sending > valid KEr* payloads is even more advantageous; he has not only > prevented the SA from being created, he also forced the initiator to > do more work before doing so. Yep. > > Also these tests might also fail during the CREATE_CHILD_SA exchange. > > There isn't a real requirement to discard the parent IKE SA; of > course, we can't allow the creation of the child SA. The problem is that if this is noticed in the Initiator then the Responder has already created Child SA, but Initiator cannot create it. Thus Child SA state is out of sync, and the general solution for that in the IKEv2 is to restart the IKE SA, i.e. delete IKE SA and start over. As here the other end cannot be unauthenticated, this is most likely caused by a bug in the implementation and restarting might or might not help, but at least that does not cause black hole problems. > While I don't think the below text is wrong (except I would point > out that there is no security requirement to discard the parent IKE > SA during a test failure while generating a child SA), I would also > point out that these don't appear to have any advantage over the > current text. There is no security requirement to discard IKE SA, but there operatinal reasons to do it. I.e. that would be clear indication that something is wrong, thus most likely will cause one of the peers to start investingating the problem, especially if it is persistent problem. On the other hand if the problem is not persistent, and is fixed by starting IKE SA over, then even better... -- kivinen@iki.fi From paul.hoffman@vpnc.org Thu Apr 4 07:56:52 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EF721F93FC for ; Thu, 4 Apr 2013 07:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9I1mev4E4602 for ; Thu, 4 Apr 2013 07:56:52 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 52BF721F93F1 for ; Thu, 4 Apr 2013 07:56:52 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r34EunfN004731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Apr 2013 07:56:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <20829.22084.868314.364667@fireball.kivinen.iki.fi> Date: Thu, 4 Apr 2013 07:56:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20826.55248.860637.210630@fireball.kivinen.iki.fi> <20829.22084.868314.364667@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1503) Cc: "ipsec@ietf.org" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Some comments to draft-ietf-ipsecme-dh-checks-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 14:56:52 -0000 On Apr 4, 2013, at 3:30 AM, Tero Kivinen wrote: > Scott Fluhrer (sfluhrer) writes: >> While I don't think the below text is wrong (except I would point >> out that there is no security requirement to discard the parent IKE >> SA during a test failure while generating a child SA), I would also >> point out that these don't appear to have any advantage over the >> current text.=20 >=20 > There is no security requirement to discard IKE SA, but there > operatinal reasons to do it. I.e. that would be clear indication that > something is wrong, thus most likely will cause one of the peers to > start investingating the problem, especially if it is persistent > problem. On the other hand if the problem is not persistent, and is > fixed by starting IKE SA over, then even better... It would be useful to add one or two sentences to the draft explaining = that the discarding is for operational, not security, reasons. --Paul Hoffman From paul@nohats.ca Fri Apr 5 15:22:33 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973C921F9924 for ; Fri, 5 Apr 2013 15:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqe4MoLASkVe for ; Fri, 5 Apr 2013 15:22:32 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9E31521F9923 for ; Fri, 5 Apr 2013 15:22:32 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZjFrh3ZWLzB0m for ; Fri, 5 Apr 2013 18:22:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id JbxYJdXsQQLX for ; Fri, 5 Apr 2013 18:22:27 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP for ; Fri, 5 Apr 2013 18:22:27 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 1900C80BCA; Fri, 5 Apr 2013 18:22:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0EDEA805AC for ; Fri, 5 Apr 2013 18:22:28 -0400 (EDT) Date: Fri, 5 Apr 2013 18:22:28 -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 Subject: [IPsec] Apple to cripple VPN on demand in iphone due to VPN-via-DNS patent X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 22:22:33 -0000 http://www.macrumors.com/2013/04/05/apple-to-alter-vpn-on-demand-behavior-in-ios-6-1-and-later-due-to-virnetx-lawsuit/ Apple documentation: http://support.apple.com/kb/TS4550 The patent: http://www.google.com/patents/US6502135 The patent is dated 1998, which I'm pretty sure is after the FreeS/WAN and Opportunistic Encryption (and thus the IETF) work had started, which clearly designed and implemented what is described below: (1) generating from the client computer a Domain Name Service (DNS) request that requests an IP address corresponding to a domain name associated with the target computer; (2) determining whether the DNS request transmitted in step (1) is requesting access to a secure web site; and (3) in response to determining that the DNS request in step (2) is requesting access to a secure target web site, automatically initiating the VPN between the client computer and the target computer. From internet-drafts@ietf.org Mon Apr 8 07:19:05 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7684621F93B0; Mon, 8 Apr 2013 07:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CVo+UAbUBAz; Mon, 8 Apr 2013 07:19:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FE021F907E; Mon, 8 Apr 2013 07:19:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p3 Message-ID: <20130408141905.8606.70067.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 07:19:05 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-oob-pubkey-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 14:19:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : More Raw Public Keys for IKEv2 Author(s) : Tero Kivinen Paul Wouters Hannes Tschofenig Filename : draft-ietf-ipsecme-oob-pubkey-00.txt Pages : 8 Date : 2013-04-08 Abstract: The Internet Key Exchange Version 2 (IKEv2) protocol currently only supports raw RSA keys. In some environments it is useful to make use of other types of public keys, such as those based on Elliptic Curve Cryptography. This documents adds support for other types of raw public keys to IKEv2 and obsoletes the old raw RSA key format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-oob-pubkey There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-oob-pubkey-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paul.hoffman@vpnc.org Mon Apr 8 14:43:53 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE32C21F8E9E for ; Mon, 8 Apr 2013 14:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wLqvDDROPnF for ; Mon, 8 Apr 2013 14:43:53 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9EE21F8A84 for ; Mon, 8 Apr 2013 14:43:50 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r38Lhl2T014476 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 8 Apr 2013 14:43:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 8 Apr 2013 14:43:47 -0700 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [IPsec] WG Last Call on draft-ietf-ipsecme-oob-pubkey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 21:43:53 -0000 Greetings again. This begins the WG Last Call on = draft-ietf-ipsecme-oob-pubkey, "More Raw Public Keys for IKEv2". You can = find the current draft at = http://tools.ietf.org/html/draft-ietf-ipsecme-oob-pubkey This document generated a fair amount of interest early, but we have not = had much discussion since. Yaron and I would *really* like to have at = least five WG members review the document and say on the list whether or = not they think it is ready in its current state to move to IETF review. = If you read it and feel it is not ready for any reason, please also say = that in your message to the list. Again, participating in WG Last Calls is a great opportunity for those = who are less active in the WG but who want to contribute to the IETF to = make a difference. The WG Last Call should end in two weeks, on April 22. Please review the = document before then. Thanks in advance! --Paul Hoffman= From paul.hoffman@vpnc.org Mon Apr 8 14:46:02 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B04121F92B2 for ; Mon, 8 Apr 2013 14:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dWsW7-DvFwv for ; Mon, 8 Apr 2013 14:46:01 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E0C1421F928B for ; Mon, 8 Apr 2013 14:46:01 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r38Lk1JY014577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 8 Apr 2013 14:46:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> Date: Mon, 8 Apr 2013 14:46:00 -0700 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 21:46:02 -0000 [[ So far, we have received only *one* review of this document, from = Tero. If we don't receive more reviews, the document might not progress = due to lack of interest. Please review this document within the next = week and contribute your review to the list. ]] Greetings. This is the start of the WG Last Call for = draft-ietf-ipsecme-dh-checks; the WG period will end in two weeks, on = April 15. The current draft is available at = http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-01 Given that this will be a Standards Track document, it is important for = it to be reviewed by as many people as possible. Possible results of = individual reviewing the document are: - "Looks fine, please publish" - "Looks fine, here are some comments" - "Has some problems, here they are" - Other things of that sort Many people on this mailing list are IPsec implementers but are mostly = or completely silent on the mailing list. If you are one of those = people, doing a WG Last Call review is a good way to participate = usefully in the WG. Please strongly consider (a) reading the current = draft and (b) sending a message to the list with your short or long = review. If there are too few reviews on this document, we could get = pushback from the IESG about the document. --Paul Hoffman _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From prvs=18108c943d=dbrown@certicom.com Mon Apr 8 15:02:04 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6BE21F8F6C for ; Mon, 8 Apr 2013 15:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.629 X-Spam-Level: X-Spam-Status: No, score=-4.629 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IofB6ilOZIx3 for ; Mon, 8 Apr 2013 15:02:04 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 362CF21F934D for ; Mon, 8 Apr 2013 15:02:00 -0700 (PDT) X-AuditID: 0a412830-b7f2f6d000007c2a-83-51633e4824a1 Received: from XCT107CNC.rim.net (xct107cnc.rim.net [10.65.161.207]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 1C.0A.31786.84E33615; Mon, 8 Apr 2013 17:01:44 -0500 (CDT) Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT107CNC.rim.net ([fe80::b815:71ef:9f8f:e07c%16]) with mapi id 14.02.0328.009; Mon, 8 Apr 2013 18:01:43 -0400 From: Dan Brown To: "paul.hoffman@vpnc.org" , "ipsec@ietf.org" Thread-Topic: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks Thread-Index: AQHONKJ+NLt7HaOtnk2NvnDv7KiS3JjM4ApA Date: Mon, 8 Apr 2013 22:01:43 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF513DBA3@XMB111CNC.rim.net> In-Reply-To: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsXC5bjwvK6HXXKgwcctKhb7t7xgs7i1/gur A5PHkiU/mTw+z77KHMAU1cBok5RYUhacmZ6nb2eTmJeXX5JYkqqQklqcbKvkk5qemKMQUJRZ lphcqeCSWZyck5iZm1qkpJCZYqtkoqRQkJOYnJqbmldiq5RYUJCal6Jkx6WAAWyAyjLzFFLz kvNTMvPSbZU8g/11LSxMLXUNlex0Ezp5Mn6/bWQuOMdX8XX7DuYGxiaeLkZODgkBE4lJm48x QthiEhfurWfrYuTiEBJoZ5I4NrGXCcLZwigx4ddlNpAqNgFViftHzzGD2CICERKvO84ygdjC Ap4S/e8uM0HEvSS6j3xhhLCNJBavh6hhEVCRWDyngR3E5hVwkzjaepQFxOYUsJHYeXg3K4jN KCArsfvsdbB6ZgFxiVtP5jNBXCcgsWTPeWYIW1Ti5eN/rBC2osSLyedYIOr1JG5MncIGYWtL LFv4mhlil6DEyZlPWCYwisxCMnYWkpZZSFpmIWlZwMiyilEwN6PYwMwwOS9ZrygzVy8vtWQT IzjyNQx2ML5/b3GIUYCDUYmH96BZcqAQa2JZcWXuIUYJDmYlEd5uQ6AQb0piZVVqUX58UWlO avEhRldgSExkluJOzgcmpbySeGMDA9wcJXHe38LRgUIC6cA0k52aWpBaBDOHiYMTZA+XlEgx MFmkFiWWlmTEg1JafDEwqUk1MIqaXjJv7bO/dXrLV7Gax7ozZBouXd/ze2X5u8Ou/Itmnv4b +08vZBrjwj8ztPpn/JUxffzyptmWpstrD5ZqF4Sdv5ZSwHLQdqOLo9W3zxnPdrzPXxsgNvmP +npeX+cjk8Im+73c7rCn5c9KIXsFm+aE54ukWmVWLPN1iPjzNCZhWbvrdaMP0sZKLMUZiYZa zEXFiQDZC/H0PQMAAA== Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 22:02:05 -0000 Looks fine, please publish. ----- Original Message ----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Monday, April 08, 2013 05:46 PM Eastern Standard Time=0A= To: IPsecme WG Subject: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks [[ So far, we have received only *one* review of this document, from Tero. I= f we don't receive more reviews, the document might not progress due to lack= of interest. Please review this document within the next week and contribut= e your review to the list. ]] Greetings. This is the start of the WG Last Call for draft-ietf-ipsecme-dh-c= hecks; the WG period will end in two weeks, on April 15. The current draft i= s available at http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-01 Given that this will be a Standards Track document, it is important for it t= o be reviewed by as many people as possible. Possible results of individual= reviewing the document are: - "Looks fine, please publish" - "Looks fine, here are some comments" - "Has some problems, here they are" - Other things of that sort Many people on this mailing list are IPsec implementers but are mostly or co= mpletely silent on the mailing list. If you are one of those people, doing a= WG Last Call review is a good way to participate usefully in the WG. Please= strongly consider (a) reading the current draft and (b) sending a message t= o the list with your short or long review. If there are too few reviews on t= his document, we could get pushback from the IESG about the document. --Paul Hoffman _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From openpgp@brainhub.org Mon Apr 8 15:48:11 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6BC21F8F4A for ; Mon, 8 Apr 2013 15:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+MCfDdfQqkM for ; Mon, 8 Apr 2013 15:48:11 -0700 (PDT) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:48]) by ietfa.amsl.com (Postfix) with ESMTP id E3ED821F8F44 for ; Mon, 8 Apr 2013 15:48:10 -0700 (PDT) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta05.emeryville.ca.mail.comcast.net with comcast id MahD1l0020b6N64A5aoA4a; Mon, 08 Apr 2013 22:48:10 +0000 Received: from [127.0.0.1] ([69.181.162.123]) by omta03.emeryville.ca.mail.comcast.net with comcast id Mao91l0092g33ZR8Pao9fg; Mon, 08 Apr 2013 22:48:10 +0000 Message-ID: <51634894.1030306@brainhub.org> Date: Mon, 08 Apr 2013 15:45:40 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: ipsec@ietf.org References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> In-Reply-To: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365461290; bh=XLZZuZASOWKnuJtg0PS5pu+4/ZYuZ0HWur3rpGFzcs4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XMfP8ZHqbCXHEM6deny7hT7CXMVV5sOV44ojt38lje1jYZxgtV1TIZQPT5cNdprue 3DnOzLhTKVNj7462hzS+Avyy0O6E63EFTKx/pI4ObLw2caMShWACW0QHT84/7XAVcl 1MF96PGnOnZgzup1ZT6CdEFNlc1jOybnJg3sFNsGGmAviFu3ZVLJncFe3E9r7K6Wli OKS4QDjgREp/DAco6RdoS6ZXud/G85jyh/McbBfuzxF6rU76eMMycgIVjlx64a8TGk iz+U9irzW0wF+5MUVl11q8ZJyOk/vf4a3BPYgXpX4VeBx+hQnKqS+AXNdwkbRGsL8t I9QVYtdtoyONg== Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 22:48:11 -0000 Sec 2.2: > It MUST check both that the peer's public value is in range (1 < r > < p-1) and that r**q = 1 mod p (where q is the size of the > subgroup, as listed in the RFC). Would it make sense to specify a more economical test for strong prime groups? If q is meant to be p = q*2+1, there are only two possibilities for the value < p-1 received from the peer to be in the wrong subgroup. One of them is 1, which is ruled out by the check above. Another one is g^q. It's a fixed quantity for the given modp group. Seems like a memcmp with a fixed quantity g^q is the best way to address the problem. On 04/08/2013 02:46 PM, Paul Hoffman wrote: > [[ So far, we have received only *one* review of this document, from Tero. If we don't receive more reviews, the document might not progress due to lack of interest. Please review this document within the next week and contribute your review to the list. ]] > > Greetings. This is the start of the WG Last Call for draft-ietf-ipsecme-dh-checks; the WG period will end in two weeks, on April 15. The current draft is available at http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-01 > > Given that this will be a Standards Track document, it is important for it to be reviewed by as many people as possible. Possible results of individual reviewing the document are: > > - "Looks fine, please publish" > > - "Looks fine, here are some comments" > > - "Has some problems, here they are" > > - Other things of that sort > > Many people on this mailing list are IPsec implementers but are mostly or completely silent on the mailing list. If you are one of those people, doing a WG Last Call review is a good way to participate usefully in the WG. Please strongly consider (a) reading the current draft and (b) sending a message to the list with your short or long review. If there are too few reviews on this document, we could get pushback from the IESG about the document. > > --Paul Hoffman > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From sfluhrer@cisco.com Mon Apr 8 16:15:04 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AFC21F8E46 for ; Mon, 8 Apr 2013 16:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JH3lUi7Flxkp for ; Mon, 8 Apr 2013 16:15:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE2621F8DBF for ; Mon, 8 Apr 2013 16:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4120; q=dns/txt; s=iport; t=1365462903; x=1366672503; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=40fP6OJePQTHbbTMTcBNxeJVq57MRawZEYhUn5hdc5E=; b=M6UNeiXCiwkL19AxCc/qOYHlRRRGUQX4iol2T2Cq7kuakf0HwK+uhB5l nJgFnyuM+osSPTAjbfBlUXYCaFdl7J9sPZE8S7CdGyIQuYTFgSpNzpBWK dC36+g5NaWlrF5CLhFio/51mrFLud96IWK7MeZYrhnAcoTf+ugtf8GD9M E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFAIJOY1GtJV2Z/2dsb2JhbABRgwY2wTGBDBZ0gh8BAQEDAQEBARodNBcEAgEIDgMEAQEBChQJBycLFAkIAgQBEgiIBgYMvWCOciYSBl2BfWEDknI6hGmPbYJ+DYIo X-IronPort-AV: E=Sophos;i="4.87,434,1363132800"; d="scan'208";a="196215528" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 08 Apr 2013 23:15:03 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r38NF2r0026816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Apr 2013 23:15:02 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.60]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 18:15:02 -0500 From: "Scott Fluhrer (sfluhrer)" To: Andrey Jivsov , "ipsec@ietf.org" Thread-Topic: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks Thread-Index: AQHONKKDikpZdmEiWUOFvhKCnr1P7JjNQCMA//+s6WA= Date: Mon, 8 Apr 2013 23:15:01 +0000 Message-ID: References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> <51634894.1030306@brainhub.org> In-Reply-To: <51634894.1030306@brainhub.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 23:15:04 -0000 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Andrey Jivsov > Sent: Monday, April 08, 2013 6:46 PM > To: ipsec@ietf.org > Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks >=20 > Sec 2.2: > > It MUST check both that the peer's public value is in range (1 < r > > < p-1) and that r**q =3D 1 mod p (where q is the size of the > > subgroup, as listed in the RFC). >=20 > Would it make sense to specify a more economical test for strong prime > groups? "Strong groups", that is, groups with (p-1)/2 prime, are listed in section = 2.1; and yes, the test there is considerably cheaper. >=20 > If q is meant to be p =3D q*2+1, there are only two possibilities for the= value < > p-1 received from the peer to be in the wrong subgroup. One of them is 1, > which is ruled out by the check above. Another one is g^q. > It's a fixed quantity for the given modp group. Seems like a memcmp with = a > fixed quantity g^q is the best way to address the problem. Actually, g^q =3D=3D 1; I don't think that's what you mean. Now, there is certainly the possibility of the value being in the wrong sub= group; but there are far more than two possibilities. Here's the entire li= st for strong groups: 1; that's rejected by the test in section 2.1 p-1; that's also rejected by the test in section 2.1 primitive elements; those are elements r which have order p-1. These are n= ot rejected by the test. (in addition, there are KE values that don't correspond to actual group ele= ments; 0 and values >=3D p; those are rejected too). Now, there are q-1 different primitive elements; that's more than we could = reasonably list. We could specify a test to reject primitive elements; how= ever, that test isn't cheap (it can be done cheaper than the full r**q=3D= =3D1 test, nevertheless, not cheaply. In addition, an attacker injecting a= primitive element could use it to deduce the lsbit of the private exponent= ; however that cannot deduce any more than that. I don't believe that the = expense of the full test is worth protecting one bit of the exponent. >=20 > On 04/08/2013 02:46 PM, Paul Hoffman wrote: > > [[ So far, we have received only *one* review of this document, from > > Tero. If we don't receive more reviews, the document might not > > progress due to lack of interest. Please review this document within > > the next week and contribute your review to the list. ]] > > > > Greetings. This is the start of the WG Last Call for > > draft-ietf-ipsecme-dh-checks; the WG period will end in two weeks, on > > April 15. The current draft is available at > > http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-01 > > > > Given that this will be a Standards Track document, it is important for= it to > be reviewed by as many people as possible. Possible results of individual > reviewing the document are: > > > > - "Looks fine, please publish" > > > > - "Looks fine, here are some comments" > > > > - "Has some problems, here they are" > > > > - Other things of that sort > > > > Many people on this mailing list are IPsec implementers but are mostly = or > completely silent on the mailing list. If you are one of those people, do= ing a > WG Last Call review is a good way to participate usefully in the WG. Plea= se > strongly consider (a) reading the current draft and (b) sending a message= to > the list with your short or long review. If there are too few reviews on = this > document, we could get pushback from the IESG about the document. > > > > --Paul Hoffman > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From openpgp@brainhub.org Mon Apr 8 17:20:14 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D57921F8D2C for ; Mon, 8 Apr 2013 17:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7BE95nw3U7N for ; Mon, 8 Apr 2013 17:20:13 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id A916721F8A85 for ; Mon, 8 Apr 2013 17:20:13 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta12.emeryville.ca.mail.comcast.net with comcast id MZtv1l00B1u4NiLACcLDQt; Tue, 09 Apr 2013 00:20:13 +0000 Received: from [127.0.0.1] ([69.181.162.123]) by omta21.emeryville.ca.mail.comcast.net with comcast id McLC1l0092g33ZR8hcLC9D; Tue, 09 Apr 2013 00:20:13 +0000 Message-ID: <51635E27.9020907@brainhub.org> Date: Mon, 08 Apr 2013 17:17:43 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Scott Fluhrer (sfluhrer)" References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> <51634894.1030306@brainhub.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365466813; bh=bJ9h16yAtKjQvCBABUthKB8q/h165Y256udUehPGvIY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=geryYoswRwsP/1liGsbp5DJELrqxc4HPshj0XzT3b6vJDNJpEZFESLq7pLFn6WQyY FuMrJb6heBPWzAYviE45kA2aNQ5WDXAu1toGE1Gnvs4vAdLuTCZ3gHiYnp+/Xr4inO Wrj4mYCmhkNBr+athnvTFUIhziVIL3O2OaZPJ10CfZRdEPf26SYDEmvt1AolxyRbyL 9FGjzxOl8ybYX2z4cTbBeryW0GoP2EbOUl24Mlj3ZeO3LTIUjWpisY1LKG7aA0GhOS HmaObfC3uueZrUhuzfE8KAbgg5FffWYhcA+y+gEBkjTltwJ3KOUviQRiUHQybGHRuZ Gwxwq4loYVhgw== Cc: "ipsec@ietf.org" Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 00:20:14 -0000 Sorry, I was scanning too quickly. I meant section 2.1 primes, the primes in the form (renaming my earlier definition) p = k*2+1. Wouldn't receiving g^k be as much of a problem as receiving 1 for the public value? No matter what my private exponent is, the shared secret will be either of the two values. On 04/08/2013 04:15 PM, Scott Fluhrer (sfluhrer) wrote: > > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Andrey Jivsov >> Sent: Monday, April 08, 2013 6:46 PM >> To: ipsec@ietf.org >> Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks >> >> Sec 2.2: >>> It MUST check both that the peer's public value is in range (1 < r >>> < p-1) and that r**q = 1 mod p (where q is the size of the >>> subgroup, as listed in the RFC). >> >> Would it make sense to specify a more economical test for strong prime >> groups? > > "Strong groups", that is, groups with (p-1)/2 prime, are listed in section 2.1; and yes, the test there is considerably cheaper. > >> >> If q is meant to be p = q*2+1, there are only two possibilities for the value < >> p-1 received from the peer to be in the wrong subgroup. One of them is 1, >> which is ruled out by the check above. Another one is g^q. >> It's a fixed quantity for the given modp group. Seems like a memcmp with a >> fixed quantity g^q is the best way to address the problem. > > Actually, g^q == 1; I don't think that's what you mean. > > Now, there is certainly the possibility of the value being in the wrong subgroup; but there are far more than two possibilities. Here's the entire list for strong groups: > > 1; that's rejected by the test in section 2.1 > p-1; that's also rejected by the test in section 2.1 > primitive elements; those are elements r which have order p-1. These are not rejected by the test. > > (in addition, there are KE values that don't correspond to actual group elements; 0 and values >= p; those are rejected too). > > Now, there are q-1 different primitive elements; that's more than we could reasonably list. We could specify a test to reject primitive elements; however, that test isn't cheap (it can be done cheaper than the full r**q==1 test, nevertheless, not cheaply. In addition, an attacker injecting a primitive element could use it to deduce the lsbit of the private exponent; however that cannot deduce any more than that. I don't believe that the expense of the full test is worth protecting one bit of the exponent. > >> >> On 04/08/2013 02:46 PM, Paul Hoffman wrote: >>> [[ So far, we have received only *one* review of this document, from >>> Tero. If we don't receive more reviews, the document might not >>> progress due to lack of interest. Please review this document within >>> the next week and contribute your review to the list. ]] >>> >>> Greetings. This is the start of the WG Last Call for >>> draft-ietf-ipsecme-dh-checks; the WG period will end in two weeks, on >>> April 15. The current draft is available at >>> http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-01 >>> >>> Given that this will be a Standards Track document, it is important for it to >> be reviewed by as many people as possible. Possible results of individual >> reviewing the document are: >>> >>> - "Looks fine, please publish" >>> >>> - "Looks fine, here are some comments" >>> >>> - "Has some problems, here they are" >>> >>> - Other things of that sort >>> >>> Many people on this mailing list are IPsec implementers but are mostly or >> completely silent on the mailing list. If you are one of those people, doing a >> WG Last Call review is a good way to participate usefully in the WG. Please >> strongly consider (a) reading the current draft and (b) sending a message to >> the list with your short or long review. If there are too few reviews on this >> document, we could get pushback from the IESG about the document. >>> >>> --Paul Hoffman >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec From mcr@sandelman.ca Mon Apr 8 19:48:16 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E781C21F8EC1 for ; Mon, 8 Apr 2013 19:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOiqH5Ml3ukB for ; Mon, 8 Apr 2013 19:48:16 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 5925221F8EB2 for ; Mon, 8 Apr 2013 19:48:15 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EE2982016F for ; Mon, 8 Apr 2013 22:57:48 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id C5EC8638F7; Mon, 8 Apr 2013 22:47:55 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B79C8638E8 for ; Mon, 8 Apr 2013 22:47:55 -0400 (EDT) From: Michael Richardson To: IPsecme WG In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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 Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-oob-pubkey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 02:48:17 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Paul" =3D=3D Paul Hoffman writes: Paul> http://tools.ietf.org/html/draft-ietf-ipsecme-oob-pubkey=20 I have read this document anew. I found the jump in section 3 to: When the certificate encoding type 'Raw Public Key' is used then the Certificate Data only contains the SubjectPublicKeyInfo part of the PKIX certificate. to be confusing on first read. Perhaps this is because I attempt to be as ignorant of PKCS/PKIX stuff as possible. (I admit that I'm a failure at this). I think that it is telling me that it's not just a raw RSA key, which is really the whole point of this exercise, but rather just the SubjectPublicKeyInfo part. I think that this paragraph could be made clearer to people who are trying to avoid knowing anything about PKIX. I followed the reference to draft-ietf-tls-oob-pubkey-07, which I read. I would like to suggest that section 3 more quickly refers to the tls-oob-pubkey Appendix A, and that it say something like: In order to provide a simple and standard way to indicate the key type when the encoding type is 'Raw Public Key', the=20 SubjectPublicKeyInfo structure of the PKIX certificate is used. This is a a very simple encoding, as most of the ASN.1 part can be included literally, and recognized by block comparison. See=20 [draft-ietf-tls-oob-pubkey] Appendix A for a detailed breakdown. In addition, Appendix A has a few examples. (Yes, add a second example... an RSA example.) =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUWOBW4qHRg3pndX9AQKv4wQAxjpL4vQJE1+idksa9dmyVxItAmIcv/3K RVsM2e/WAQy4pClS5ODnb5VxhT7tkIDnx07R9zQDwuEIT0CDxJSneVpN2ukP54hy CdVBd5JmoH6bK1kK2iAo4CBifREdH35WJp7CEvsZ6KMlHLXTY2dAIYf2pWxSHXfY wOXvVmdC2sM= =JVW6 -----END PGP SIGNATURE----- --=-=-=-- From internet-drafts@ietf.org Mon Apr 8 19:53:47 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1739A21F8F01; Mon, 8 Apr 2013 19:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wiXvpavzhdV; Mon, 8 Apr 2013 19:53:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF5F21F8EB2; Mon, 8 Apr 2013 19:53:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130409025346.7391.95143.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 19:53:46 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ad-vpn-problem-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 02:53:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Auto Discovery VPN Problem Statement and Requirements Author(s) : Steve Hanna Vishwas Manral Filename : draft-ietf-ipsecme-ad-vpn-problem-05.txt Pages : 11 Date : 2013-04-08 Abstract: This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements, for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases the IP address of endpoints change or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto Discovery VPN solution will address these requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ad-vpn-problem-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shanna@juniper.net Mon Apr 8 20:00:51 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBA921F8E96 for ; Mon, 8 Apr 2013 20:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9ZRN2t2+65j for ; Mon, 8 Apr 2013 20:00:51 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 0F63921F8DA4 for ; Mon, 8 Apr 2013 20:00:51 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUWOEYu1uX7VsidKxFQcG0+9DbeJlRbM/@postini.com; Mon, 08 Apr 2013 20:00:51 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Apr 2013 20:00:31 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 8 Apr 2013 20:00:30 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.184) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 8 Apr 2013 20:03:03 -0700 Received: from mail97-co1-R.bigfish.com (10.243.78.254) by CO1EHSOBE040.bigfish.com (10.243.66.105) with Microsoft SMTP Server id 14.1.225.23; Tue, 9 Apr 2013 03:00:29 +0000 Received: from mail97-co1 (localhost [127.0.0.1]) by mail97-co1-R.bigfish.com (Postfix) with ESMTP id C19C24800C8 for ; Tue, 9 Apr 2013 03:00:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -25 X-BigFish: PS-25(zz9371I936eI542I1432I4015Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail97-co1 (localhost.localdomain [127.0.0.1]) by mail97-co1 (MessageSwitch) id 1365476427346847_16280; Tue, 9 Apr 2013 03:00:27 +0000 (UTC) Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.252]) by mail97-co1.bigfish.com (Postfix) with ESMTP id 4934C580049 for ; Tue, 9 Apr 2013 03:00:27 +0000 (UTC) Received: from SN2PRD0510HT001.namprd05.prod.outlook.com (157.56.234.117) by CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Apr 2013 03:00:25 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.67]) by SN2PRD0510HT001.namprd05.prod.outlook.com ([10.255.116.36]) with mapi id 14.16.0287.008; Tue, 9 Apr 2013 03:00:24 +0000 From: Stephen Hanna To: "ipsec@ietf.org" Thread-Topic: Please Review Changes to AD VPN Problem Statement Thread-Index: AQHONM5h3QJpx/aEQU6tLeXKyVrNLQ== Date: Tue, 9 Apr 2013 03:00:23 +0000 Message-ID: References: <20130409025346.7391.95143.idtracker@ietfa.amsl.com> In-Reply-To: <20130409025346.7391.95143.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [IPsec] Please Review Changes to AD VPN Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 03:00:51 -0000 I have posted a new version of the AD VPN Problem Statement that adds clarifying text to requirements 6 and 7, as suggested by Tero. Please review and comment. Is everyone (especially Tero) OK with the new text? The new draft is available at https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem Since the changes are few, it may be easier for you to look at the diff linked to here: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ad-vpn-problem-05 Thanks, Steve > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Monday, April 08, 2013 10:54 PM > To: i-d-announce@ietf.org > Cc: ipsec@ietf.org > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ad-vpn-problem-05.txt >=20 >=20 > 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. >=20 > Title : Auto Discovery VPN Problem Statement and > Requirements > Author(s) : Steve Hanna > Vishwas Manral > Filename : draft-ietf-ipsecme-ad-vpn-problem-05.txt > Pages : 11 > Date : 2013-04-08 >=20 > Abstract: > This document describes the problem of enabling a large number of > systems to communicate directly using IPsec to protect the traffic > between them. It then expands on the requirements, for such a > solution. >=20 > Manual configuration of all possible tunnels is too cumbersome in > many such cases. In other cases the IP address of endpoints change > or the endpoints may be behind NAT gateways, making static > configuration impossible. The Auto Discovery VPN solution will > address these requirements. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ad-vpn-problem-05 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From mcr@sandelman.ca Mon Apr 8 20:01:25 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B371221F8F1A for ; Mon, 8 Apr 2013 20:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq8nEmDE9HmY for ; Mon, 8 Apr 2013 20:01:25 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 3E72221F8F1E for ; Mon, 8 Apr 2013 20:01:25 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 670A22016F for ; Mon, 8 Apr 2013 23:10:59 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A79A9638F7; Mon, 8 Apr 2013 23:01:06 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 98262638E8 for ; Mon, 8 Apr 2013 23:01:06 -0400 (EDT) From: Michael Richardson To: IPsecme WG In-Reply-To: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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 Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 03:01:25 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I read draft-ietf-ipsecme-dh-checks-01. I am not competent to understand if this addresses a real problem. I understood that (1 < r < p-1) is a test that many implementors did not do. I think that most implementations generated r from a PRNG.=20 I have not implemented ECDSA, but the instructions seemed well formatted, but I don't at this point know what they mean. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUWOEcoqHRg3pndX9AQJtcAP9GDxxGNUotecdEMnllyknlaAwmlSsggIu uAk/7oqMv5p4iNQcOXQxwlo0y/X4RA83xhYPzwHEVTF0giRbUJcyIQjQDVhHTLBy 8POcCKI5lklR40O4kh1cIjN0v9dfJ/Ud0zww7hC6JxkLJr3Ez0FLmmmIwcTitReA hxoriIGz6PM= =jMQ/ -----END PGP SIGNATURE----- --=-=-=-- From sfluhrer@cisco.com Mon Apr 8 21:19:22 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6816321F860A for ; Mon, 8 Apr 2013 21:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zCHuvB4dfTj for ; Mon, 8 Apr 2013 21:19:21 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9C17721F853A for ; Mon, 8 Apr 2013 21:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1356; q=dns/txt; s=iport; t=1365481161; x=1366690761; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=YGPzOwZ9tnl9cWqko/SzHEeDpKQwDk8jH+Iqej4LRiU=; b=Pwhd4iToiJK27GJVaiMFZJIQPJHIkX0PLxLV3bqYeENKDyvD6s8aTsnd J4ufOrwoyPu1PI4TJ03ZViHhy/WLfuZDKam+jOiidOWDa3jI3G0H85F8D 2jldU4zYlw/JE3U6r+o1JpwmiW2XWK54huDOh9XM5i/gDzADO7BwsiCYr w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAP2VY1GtJV2Z/2dsb2JhbABRgwbBcYEQFnSCHwEBAQMBHR1LBAIBCBEEAQELFAkHMhQJCAIEARIIiAYGrWGQLI5yJhIGglphA6gCgn4Ngig X-IronPort-AV: E=Sophos;i="4.87,436,1363132800"; d="scan'208";a="196487979" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 09 Apr 2013 04:19:21 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r394JLDI015309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Apr 2013 04:19:21 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.60]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 23:19:20 -0500 From: "Scott Fluhrer (sfluhrer)" To: Michael Richardson , IPsecme WG Thread-Topic: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks Thread-Index: AQHONKKDikpZdmEiWUOFvhKCnr1P7JjNh4EA//+sFAA= Date: Tue, 9 Apr 2013 04:19:20 +0000 Message-ID: References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> <5697.1365476466@sandelman.ca> In-Reply-To: <5697.1365476466@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 04:19:22 -0000 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Michael Richardson > Sent: Monday, April 08, 2013 11:01 PM > To: IPsecme WG > Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks >=20 >=20 > I read draft-ietf-ipsecme-dh-checks-01. > I am not competent to understand if this addresses a real problem. > I understood that (1 < r < p-1) is a test that many implementors did not > do. I think that most implementations generated r from a PRNG. This last statement makes me suspect that you misunderstood what we were do= ing. The tests we suggest in this draft are not run on either the secret exponen= t nor the public value we generate. Instead, it's run on the value r we re= ceive from the peer's KE payload. How the peer selects that value isn't ou= r problem (we certainly hope the peer selects it in a way such that a third= party can't guess its secret exponent; we can't actually test for that); o= ur problem is deciding whether to accept it or not. >=20 > I have not implemented ECDSA, but the instructions seemed well > formatted, but I don't at this point know what they mean. Actually, we're talking about ECDH here, and not ECDSA. >=20 > -- > Michael Richardson , Sandelman Software Works >=20 From kivinen@iki.fi Tue Apr 9 06:07:20 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0417321F9138 for ; Tue, 9 Apr 2013 06:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mK-i1wSlPoHs for ; Tue, 9 Apr 2013 06:07:19 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id D875C21F89CF for ; Tue, 9 Apr 2013 06:07:18 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r39D5sZc019880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Apr 2013 16:05:54 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r39D5rqS025781; Tue, 9 Apr 2013 16:05:53 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20836.4657.322399.281541@fireball.kivinen.iki.fi> Date: Tue, 9 Apr 2013 16:05:53 +0300 From: Tero Kivinen To: "Scott Fluhrer (sfluhrer)" In-Reply-To: References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> <51634894.1030306@brainhub.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: "ipsec@ietf.org" , Andrey Jivsov Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 13:07:20 -0000 Scott Fluhrer (sfluhrer) writes: > Now, there are q-1 different primitive elements; that's more than we > could reasonably list. We could specify a test to reject primitive > elements; however, that test isn't cheap (it can be done cheaper > than the full r**q==1 test, nevertheless, not cheaply. In addition, > an attacker injecting a primitive element could use it to deduce the > lsbit of the private exponent; however that cannot deduce any more > than that. I don't believe that the expense of the full test is > worth protecting one bit of the exponent. Hmm... there is text in the RFC2412 about this I think: ---------------------------------------------------------------------- Because these two primes are congruent to 7 (mod 8), 2 is a quadratic residue of each prime. All powers of 2 will also be quadratic residues. This prevents an opponent from learning the low order bit of the Diffie-Hellman exponent (AKA the subgroup confinement problem). Using 2 as a generator is efficient for some modular exponentiation algorithms. [Note that 2 is technically not a generator in the number theory sense, because it omits half of the possible residues mod P. From a cryptographic viewpoint, this is a virtue.] ---------------------------------------------------------------------- I assume this the same thing you are talking about i.e. opponent learning the low order bit of the DH exponent, and RFC2412 claims that the nature of the primes that attack is not possible. Right? -- kivinen@iki.fi From mcr@sandelman.ca Tue Apr 9 06:27:05 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092E921F9003 for ; Tue, 9 Apr 2013 06:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D52zxgYqUurZ for ; Tue, 9 Apr 2013 06:27:01 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id B625721F8FD6 for ; Tue, 9 Apr 2013 06:27:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D91352016F; Tue, 9 Apr 2013 09:36:36 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 40B65A9946; Tue, 9 Apr 2013 09:26:42 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2A3F3B9396; Tue, 9 Apr 2013 09:26:42 -0400 (EDT) From: Michael Richardson To: "Scott Fluhrer (sfluhrer)" In-Reply-To: References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> <5697.1365476466@sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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 Cc: IPsecme WG Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 13:27:05 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "sfluhrer" =3D=3D sfluhrer writes: >> I read draft-ietf-ipsecme-dh-checks-01. >> I am not competent to understand if this addresses a real problem. >> I understood that (1 < r < p-1) is a test that many implementors did= not >> do. I think that most implementations generated r from a PRNG. sfluhrer> This last statement makes me suspect that you sfluhrer> misunderstood what we were doing.=20 sfluhrer> The tests we suggest in this draft are not run on either sfluhrer> the secret exponent nor the public value we generate. sfluhrer> Instead, it's run on the value r we receive from the sfluhrer> peer's KE payload. How the peer selects that value isn't sfluhrer> our problem (we certainly hope the peer selects it in a sfluhrer> way such that a third party can't guess its secret sfluhrer> exponent; we can't actually test for that); our problem is sfluhrer> deciding whether to accept it or not.=20 Yes, I think that I understood that these tests are for what we receive, and then I must have read something that talked about generation... sec... Aha.... so: o It MUST check both that the peer's public value is in range (1 < r < p-1) and that r**q =3D 1 mod p (where q is the size of the ... o It MUST NOT reuse DH private values (that is, the DH private value for each DH exchange MUST be generated from a fresh output of a So, in section 2.2 we talk both about what we should do with something received, and also place a mandate about generating. Perhaps these things belong in seperate sections. It seems that from the receiver of g^x's point of view, point two repeats point one, since the receiver is not in a position to know if the DH private value was reused. >> I have not implemented ECDSA, but the instructions seemed well >> formatted, but I don't at this point know what they mean. sfluhrer> Actually, we're talking about ECDH here, and not ECDSA. my typo at 11:30pm. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUWQXEoqHRg3pndX9AQIwDwP+OO81B5iYv7HyAhU6jx9eTaSF16CC60Dv sVdsqFeYrYxmwH+YSUph8+2lYKbR6PHzk21+pgTXXumXIDfMEnlcLpbZMHvhm2TC V1h98qET8FZ0yUZztVOBYY4yZnsYU/eYSKykx9U0uWu6LLNRJ2MNxWpCrwO60jQv Eq5GK3xI8Zs= =CbIn -----END PGP SIGNATURE----- --=-=-=-- From prvs=6811d4ab8c=dbrown@certicom.com Tue Apr 9 07:03:39 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BFE21F86C3 for ; Tue, 9 Apr 2013 07:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.772 X-Spam-Level: X-Spam-Status: No, score=-4.772 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1afuO7kXsshs for ; Tue, 9 Apr 2013 07:03:39 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id BE02521F8700 for ; Tue, 9 Apr 2013 07:03:38 -0700 (PDT) X-AuditID: 0a41282f-b7f1a6d0000054a3-5c-51641fa98881 Received: from XCT105CNC.rim.net (xct105cnc.rim.net [10.65.161.205]) by mhs060cnc.rim.net (SBG) with SMTP id 3D.39.21667.9AF14615; Tue, 9 Apr 2013 09:03:21 -0500 (CDT) Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 10:03:20 -0400 From: Dan Brown To: 'Michael Richardson' , "Scott Fluhrer (sfluhrer)" Thread-Topic: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks Thread-Index: AQHONKJ+NLt7HaOtnk2NvnDv7KiS3JjNdr0AgAAV3ACAAJjvAP//xcCg Date: Tue, 9 Apr 2013 14:03:20 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF513E325@XMB111CNC.rim.net> References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> <5697.1365476466@sandelman.ca> <17925.1365514002@sandelman.ca> In-Reply-To: <17925.1365514002@sandelman.ca> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJKsWRmVeSWpSXmKPExsXC5bjwrO5K+ZRAg5mv1Cz2b3nBZtFzqJ/d YmqLnwOzx5TfG1k9liz5yeTRMmcPcwBzVAOjTVJiSVlwZnqevp1NYl5efkliSapCSmpxsq2S T2p6Yo5CQFFmWWJypYJLZnFyTmJmbmqRkkJmiq2SiZJCQU5icmpual6JrVJiQUFqXoqSHZcC BrABKsvMU0jNS85PycxLt1XyDPbXtbAwtdQ1VLLTTejkydi08Q5rwULOikVvFrM3ME5h72Lk 4JAQMJG4e9Ksi5ETyBSTuHBvPRuILSSwilFixUP/LkYuIHsLo8SepueMIAk2AVWJ+0fPMYP0 iggkS5zbqg4SZhaQl9j8ZRdYr7CAp8SkSR1gtoiAl0T3kS+MELabRN/jZWA2i4CKxOdlE5hA bF6g+IIfb9ggdh1klNi+YA0LSIJTQEfiRtdpdhCbUUBWYvfZ60wQy8Qlbj2ZzwRxtIDEkj3n mSFsUYmXj/+xQtiKEs/uLGWHqNeRWLD7ExuErS2xbOFrZojFghInZz5hmcAoNgvJ2FlIWmYh aZmFpGUBI8sqRsHcjGIDM4PkvGS9osxcvbzUkk2M4LShob+D8e17i0OMAhyMSjy8ScIpgUKs iWXFlbmHGCU4mJVEeA9JAYV4UxIrq1KL8uOLSnNSiw8xugKDZSKzFHdyPjCl5ZXEGxsY4OYo ifP+Fo4OFBJIB6ak7NTUgtQimDlMHJwge7ikRIqBiSW1KLG0JCMelP7ii4EJUKqBUepncqbT mxftm+pTthXXLjE+/nLLNdnPF+S3WT8WeP+9UELbwvLyw3dSXTmvmSOYVBa+/crmOEfVsVW9 WDfOsKnk/yvOipqSPfMtu+723u+xi8w8KMHwYpvI+6NyZu4LVjYly5ya1Vu5XrD5d9rWujbW jDvH2W/ZfubfPufCqi/tHaHbJjcnKbEUZyQaajEXFScCAKSteM1cAwAA Cc: IPsecme WG Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 14:03:39 -0000 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Michael Richardson > Aha.... so: > > o It MUST check both that the peer's public value is in range (1 < > r > < p-1) and that r**q =3D 1 mod p (where q is the size of the > > ... > o It MUST NOT reuse DH private values (that is, the DH private > value > for each DH exchange MUST be generated from a fresh output of a > > So, in section 2.2 we talk both about what we should do with something > received, and also place a mandate about generating. > > Perhaps these things belong in seperate sections. > It seems that from the receiver of g^x's point of view, point two > repeats point one, since the receiver is not in a position to know if > the DH private value was reused. > [DB] The concern is that receiver wants to protect her own reused private ke= y from an invalid public key from a malicious peer. To do this, the receive= r checks the received value to make sure it is valid and safe to combine wit= h her reused private key. Another option for the receiver is not reusing th= e private key at all. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From mcr@sandelman.ca Tue Apr 9 07:33:56 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D5121F9299 for ; Tue, 9 Apr 2013 07:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eKPUkXNdp62 for ; Tue, 9 Apr 2013 07:33:55 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 7A29521F8F39 for ; Tue, 9 Apr 2013 07:33:55 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 327192016F; Tue, 9 Apr 2013 10:43:30 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9B238A9946; Tue, 9 Apr 2013 10:33:34 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 84843B9396; Tue, 9 Apr 2013 10:33:34 -0400 (EDT) From: Michael Richardson To: Dan Brown In-Reply-To: <810C31990B57ED40B2062BA10D43FBF513E325@XMB111CNC.rim.net> References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> <5697.1365476466@sandelman.ca> <17925.1365514002@sandelman.ca> <810C31990B57ED40B2062BA10D43FBF513E325@XMB111CNC.rim.net> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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 Cc: IPsecme WG , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 14:33:56 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Dan" =3D=3D Dan Brown writes: >> Perhaps these things belong in seperate sections. >> It seems that from the receiver of g^x's point of view, point two >> repeats point one, since the receiver is not in a position to know if >> the DH private value was reused. Dan> [DB] The concern is that receiver wants to protect her own Dan> reused private key from an invalid public key from a malicious Dan> peer. To do this, the receiver checks the received value to Dan> make sure it is valid and safe to combine with her reused Dan> private key. Another option for the receiver is not reusing Dan> the private key at all.=20=20 okay, that wasn't clear to me at all. When you say "private key", we are talking about the y, not the g^y. I guess I recall that there are some implementations which calculate their g^x/g^y, and cache that for many DH operations.=20=20 Is the the point here is that this is safe if we do these tests. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUWQmvoqHRg3pndX9AQL4gwP/SxX7Ql5RNxWejaILPfHIm/e/tJ6JGNoj 0FGTYjxMoFH6gg8UWobaAosDJbxwM43ggjPljk78RxAW3dorLHWeaYfX8F7BjSWO PGAtTUN6QS+C/cAmytgkxynextxgnZUNSYY2+hbdzqto2orM4N4hxXR7Kl73fADZ foaFO0q2lsI= =kbJr -----END PGP SIGNATURE----- --=-=-=-- From ynir@checkpoint.com Tue Apr 9 07:45:52 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B86521F93B2 for ; Tue, 9 Apr 2013 07:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osV-E6p6kBwT for ; Tue, 9 Apr 2013 07:45:51 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id ED3FD21F938F for ; Tue, 9 Apr 2013 07:45:44 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r39EjcOj024216; Tue, 9 Apr 2013 17:45:38 +0300 X-CheckPoint: {51642970-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Tue, 9 Apr 2013 17:45:38 +0300 From: Yoav Nir To: Paul Hoffman Thread-Topic: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks Thread-Index: AQHONKJ73EdXuj/XRUSHMWVhzjSEwJjNxjoA Date: Tue, 9 Apr 2013 14:45:37 +0000 Message-ID: References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> In-Reply-To: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.203] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 14:45:52 -0000 Hi tl;dr: Looks fine, please publish I am not a cryptographer and not competent to comment on the issues that th= is draft is trying to solve or on the quality of this solution. Speaking strictly as a developer, the text is clear and understandable. Doi= ng the mental exercise of estimating what it would take to implement this i= n my code, it was very easy to add the prescribed tests in the two places t= hey would be needed, with about 5 lines of extra code apiece. (of course it= helps to have access to the OpenSSL library with functions such as ec_GFp_= simple_is_at_infinity() and ec_GFp_simple_is_on_curve() rather than having = to implement them myself) Yoav On Apr 9, 2013, at 12:46 AM, Paul Hoffman wrote: > [[ So far, we have received only *one* review of this document, from Tero= . If we don't receive more reviews, the document might not progress due to = lack of interest. Please review this document within the next week and cont= ribute your review to the list. ]] >=20 > Greetings. This is the start of the WG Last Call for draft-ietf-ipsecme-d= h-checks; the WG period will end in two weeks, on April 15. The current dra= ft is available at http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-= 01 >=20 > Given that this will be a Standards Track document, it is important for i= t to be reviewed by as many people as possible. Possible results of individ= ual reviewing the document are: >=20 > - "Looks fine, please publish" >=20 > - "Looks fine, here are some comments" >=20 > - "Has some problems, here they are" >=20 > - Other things of that sort >=20 > Many people on this mailing list are IPsec implementers but are mostly or= completely silent on the mailing list. If you are one of those people, doi= ng a WG Last Call review is a good way to participate usefully in the WG. P= lease strongly consider (a) reading the current draft and (b) sending a mes= sage to the list with your short or long review. If there are too few revie= ws on this document, we could get pushback from the IESG about the document= . >=20 > --Paul Hoffman From openpgp@brainhub.org Tue Apr 9 09:49:57 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD3D21F9367 for ; Tue, 9 Apr 2013 09:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuvLSayq4RAz for ; Tue, 9 Apr 2013 09:49:56 -0700 (PDT) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:48]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8BD21F9382 for ; Tue, 9 Apr 2013 09:49:56 -0700 (PDT) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta05.emeryville.ca.mail.comcast.net with comcast id Mqyg1l0030EPchoA5spwMg; Tue, 09 Apr 2013 16:49:56 +0000 Received: from [127.0.0.1] ([69.181.162.123]) by omta01.emeryville.ca.mail.comcast.net with comcast id Mspv1l0062g33ZR8MspvpZ; Tue, 09 Apr 2013 16:49:55 +0000 Message-ID: <5164461D.3070701@brainhub.org> Date: Tue, 09 Apr 2013 09:47:25 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Scott Fluhrer (sfluhrer)" References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> <51634894.1030306@brainhub.org> <51635E27.9020907@brainhub.org> In-Reply-To: <51635E27.9020907@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365526196; bh=6wmL7+UoMenwkZN5OjU6/rC6BPWHT2aK6JUuK8s7pyQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pKClkyf7j/RyQQCgAVImLNSSgwRoO9qgowTFSZ6ofV35ijwVtS3d/E2UTDRMbMjd7 83WmIQcp8IQR6znK/baNqgxbBFx8cGOfMPHSXy3qOSumFJBuMmdB+EOsKJzBXZqYmX cKC9yscIGipi8dgY9owSlv+su95H7pzjoONRApA0chhh0SvghvSfAh5WmUT0p3xkvU /wm9DP0541UmtLkqGxk2mDPnYsT9SBiVlBDKLiUDq4hSG5YsOpcOizNocPmDSGtMTj 4Y6H/0vs5XUPTOhYBVOKQOWGPA4TwhB7Y5VBkm9JtAY7dhJQZBuhLS0xsNAH4tfe0k cwL1WDkmNcqMQ== Cc: "ipsec@ietf.org" Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 16:49:57 -0000 At a closer look, the quantity g^k = g^(p-1)/2 is 1 or p-1, the values that are eliminated by the check in section 2.1 for 1 < r < p-1. Given this, the check 1 < r < p-1 is indeed a nice check for the small subgroup of the safe primes. ( This doesn't take care of a peer doing something silly and using small exponents, but that's a generic problem. ) On 04/08/2013 05:17 PM, Andrey Jivsov wrote: > Sorry, I was scanning too quickly. > > I meant section 2.1 primes, the primes in the form (renaming my > earlier definition) p = k*2+1. > > Wouldn't receiving g^k be as much of a problem as receiving 1 for the > public value? No matter what my private exponent is, the shared secret > will be either of the two values. > > On 04/08/2013 04:15 PM, Scott Fluhrer (sfluhrer) wrote: >> >> >>> -----Original Message----- >>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >>> Of Andrey Jivsov >>> Sent: Monday, April 08, 2013 6:46 PM >>> To: ipsec@ietf.org >>> Subject: Re: [IPsec] NUDGE: WG Last Call for >>> draft-ietf-ipsecme-dh-checks >>> >>> Sec 2.2: >>>> It MUST check both that the peer's public value is in range (1 < r >>>> < p-1) and that r**q = 1 mod p (where q is the size of the >>>> subgroup, as listed in the RFC). >>> >>> Would it make sense to specify a more economical test for strong prime >>> groups? >> >> "Strong groups", that is, groups with (p-1)/2 prime, are listed in >> section 2.1; and yes, the test there is considerably cheaper. >> >>> >>> If q is meant to be p = q*2+1, there are only two possibilities for >>> the value < >>> p-1 received from the peer to be in the wrong subgroup. One of them >>> is 1, >>> which is ruled out by the check above. Another one is g^q. >>> It's a fixed quantity for the given modp group. Seems like a memcmp >>> with a >>> fixed quantity g^q is the best way to address the problem. >> >> Actually, g^q == 1; I don't think that's what you mean. >> >> Now, there is certainly the possibility of the value being in the >> wrong subgroup; but there are far more than two possibilities. >> Here's the entire list for strong groups: >> >> 1; that's rejected by the test in section 2.1 >> p-1; that's also rejected by the test in section 2.1 >> primitive elements; those are elements r which have order p-1. These >> are not rejected by the test. >> >> (in addition, there are KE values that don't correspond to actual >> group elements; 0 and values >= p; those are rejected too). >> >> Now, there are q-1 different primitive elements; that's more than we >> could reasonably list. We could specify a test to reject primitive >> elements; however, that test isn't cheap (it can be done cheaper than >> the full r**q==1 test, nevertheless, not cheaply. In addition, an >> attacker injecting a primitive element could use it to deduce the >> lsbit of the private exponent; however that cannot deduce any more >> than that. I don't believe that the expense of the full test is >> worth protecting one bit of the exponent. >> >>> >>> On 04/08/2013 02:46 PM, Paul Hoffman wrote: >>>> [[ So far, we have received only *one* review of this document, from >>>> Tero. If we don't receive more reviews, the document might not >>>> progress due to lack of interest. Please review this document within >>>> the next week and contribute your review to the list. ]] >>>> >>>> Greetings. This is the start of the WG Last Call for >>>> draft-ietf-ipsecme-dh-checks; the WG period will end in two weeks, on >>>> April 15. The current draft is available at >>>> http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-01 >>>> >>>> Given that this will be a Standards Track document, it is important >>>> for it to >>> be reviewed by as many people as possible. Possible results of >>> individual >>> reviewing the document are: >>>> >>>> - "Looks fine, please publish" >>>> >>>> - "Looks fine, here are some comments" >>>> >>>> - "Has some problems, here they are" >>>> >>>> - Other things of that sort >>>> >>>> Many people on this mailing list are IPsec implementers but are >>>> mostly or >>> completely silent on the mailing list. If you are one of those >>> people, doing a >>> WG Last Call review is a good way to participate usefully in the WG. >>> Please >>> strongly consider (a) reading the current draft and (b) sending a >>> message to >>> the list with your short or long review. If there are too few >>> reviews on this >>> document, we could get pushback from the IESG about the document. >>>> >>>> --Paul Hoffman >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>> >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec > From kanaga_k@yahoo.com Tue Apr 9 10:03:12 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F87B21F928B for ; Tue, 9 Apr 2013 10:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYjcDe6PGAKA for ; Tue, 9 Apr 2013 10:03:11 -0700 (PDT) Received: from nm8.bullet.mail.bf1.yahoo.com (nm8.bullet.mail.bf1.yahoo.com [98.139.212.167]) by ietfa.amsl.com (Postfix) with SMTP id 8E21121F923C for ; Tue, 9 Apr 2013 10:03:11 -0700 (PDT) Received: from [98.139.212.153] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 09 Apr 2013 17:03:10 -0000 Received: from [98.139.212.208] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 09 Apr 2013 17:03:10 -0000 Received: from [127.0.0.1] by omp1017.mail.bf1.yahoo.com with NNFMP; 09 Apr 2013 17:03:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 959622.66078.bm@omp1017.mail.bf1.yahoo.com Received: (qmail 23641 invoked by uid 60001); 9 Apr 2013 17:03:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1365526990; bh=w8dLk5BoUjh8cqVtix8WZYXdZDRO+DisGruZqxEPRyg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=vC/02xwYQJn/qwHtwIX8C08TXSrAKLBOB08wqhMGMxxElbjpFBlY19TonCTXvt8xR4Zb26K7+ZAS74Mfviab3nlfOqepEa4RiFe1RW6Z4ETUowH9QF0h4MQwtER3zDxGnzCTxL+H1MFkt7NEoU7c2Bx1qtnvqtWa1EGeInIJyPs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Ti1rpp9mYmg1RGc9Xi6J9QknTKOaQ5182srIZ+33qjEWTqBtUE2JNgG+pXjJ3gB/nFBe6n2TRDRZ3WnW23dKkhG/GmounqoAoKAhpPPykRaBdm1oGFlWEGZYo9Y6SnsfESXy7/pquS5hDRAPUYeJAv3Vovx4m+2w4bdhAu1N9A4=; X-YMail-OSG: LEzvTM0VM1mwfs9CvJYeSpixnPsqqONHz4a.l2l1D5KNZSi a_5AAVhmhwbEHnwb4ocUhe5Mwi9xnH9vvXB0QicpizZGpYX9C8PTOL2sM3z1 .gYM2l1844_YSO4eWVhdy0HcQ8kOtwmJfTAkdLAyUA.DWAmmaKRsKxhT_N4W 4IzvdzkR5AHGRRs9FqRQV3fAwZNIuW.p7hJrTgolKD18oQZHhJRt3EI0lagb AO1Og7ncuEF4YCvD0EjAvMHc7wMSLZPyPjLAkQ3GYirtwqfEfaS2pvLOUeUS XEBN6dG.NBmOSPmF.0zdSFsliLAfvl9WqR98f7FS1hEpPph4KzlmaMFg4QzW R9neUi09H4lwcLiDXxFRkuljqKMyBigiGlPBQulhHLfz77KGjIUlUT_K6JpQ XdqcGpBz1ynjVpRJk1eRgPJ49k8f1qy0QP4omD81WUlsMSX9qgj0U6yPVHgF FGbfeUhHqtRe_lEHXnSWp3dOkqKXJgztTSXA2f7jQQ.8VLn3zJMA9JMg- Received: from [116.197.178.83] by web141003.mail.bf1.yahoo.com via HTTP; Tue, 09 Apr 2013 10:03:10 PDT X-Rocket-MIMEInfo: 002.001, SGkgQWxsLAoKSG93IHRvIGhhbmRsZSAiSW5pdGlhbCBDb250YWN0IE5vdGlmaWNhdGlvbiIgZHVyaW5nIHNpbXVsdGFuZW91cyBJS0V2MiBTQSBuZWdvdGlhdGlvbj8KCkZvcgogZXhhbXBsZTogQSBwYWlyIG9mIGdhdGV3YXlzIGFyZSBpbml0aWF0aW5nIElLRXYyIG5lZ290aWF0aW9uIGFsbW9zdCBhdCAKdGhlIHNhbWUgdGltZSByZXN1bHRpbmcgaW4gMiBzZXRzIG9mIElLRXYyIFNBcy4gSW4gSUtFX0FVVEgsIGJvdGggdGhlIApib3hlcyBhcmUgc2VuZGluZyAiSW5pdGlhbCBDb250YWN0IiBub3RpZmljYXQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.140.532 Message-ID: <1365526990.17344.YahooMailNeo@web141003.mail.bf1.yahoo.com> Date: Tue, 9 Apr 2013 10:03:10 -0700 (PDT) From: Kanaga Kannappan To: "ipsec@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1028315969-1108293149-1365526990=:17344" Subject: [IPsec] IKEv2 initial contact handling? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Kanaga Kannappan List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 17:03:12 -0000 ---1028315969-1108293149-1365526990=:17344 Content-Type: text/plain; charset=us-ascii Hi All, How to handle "Initial Contact Notification" during simultaneous IKEv2 SA negotiation? For example: A pair of gateways are initiating IKEv2 negotiation almost at the same time resulting in 2 sets of IKEv2 SAs. In IKE_AUTH, both the boxes are sending "Initial Contact" notification and IKE_AUTH almost cross each other. On receiving the IC, if both try to delete the other IKE SAs on the box, we end up having different sets of IKE & child SAs on the both sides. Thanks Kanaga. ---1028315969-1108293149-1365526990=:17344 Content-Type: text/html; charset=us-ascii
Hi All,

How to handle "Initial Contact Notification" during simultaneous IKEv2 SA negotiation?

For example: A pair of gateways are initiating IKEv2 negotiation almost at the same time resulting in 2 sets of IKEv2 SAs. In IKE_AUTH, both the boxes are sending "Initial Contact" notification and IKE_AUTH almost cross each other. On receiving the IC, if both try to delete the other IKE SAs on the box, we end up having different sets of IKE & child SAs on the both sides.


Thanks
Kanaga.
---1028315969-1108293149-1365526990=:17344-- From prvs=6811d4ab8c=dbrown@certicom.com Tue Apr 9 10:09:20 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C891B21F91BC for ; Tue, 9 Apr 2013 10:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUouk61d+8eA for ; Tue, 9 Apr 2013 10:09:20 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 051B621F9156 for ; Tue, 9 Apr 2013 10:09:19 -0700 (PDT) X-AuditID: 0a412830-b7f2f6d000007c2a-d3-51644b37765b Received: from XCT107CNC.rim.net (xct107cnc.rim.net [10.65.161.207]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 8C.C0.31786.73B44615; Tue, 9 Apr 2013 12:09:11 -0500 (CDT) Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT107CNC.rim.net ([fe80::b815:71ef:9f8f:e07c%16]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 13:09:11 -0400 From: Dan Brown To: 'Michael Richardson' Thread-Topic: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks Thread-Index: AQHONKJ+NLt7HaOtnk2NvnDv7KiS3JjNdr0AgAAV3ACAAJjvAP//xcCggABM7gD//+NOQA== Date: Tue, 9 Apr 2013 17:09:10 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF513E46D@XMB111CNC.rim.net> References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> <5697.1365476466@sandelman.ca> <17925.1365514002@sandelman.ca> <810C31990B57ED40B2062BA10D43FBF513E325@XMB111CNC.rim.net> <29765.1365518014@sandelman.ca> In-Reply-To: <29765.1365518014@sandelman.ca> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNKsWRmVeSWpSXmKPExsXC5bjwvK65d0qgQcN+I4v9W16wWfQc6me3 mNri58DsMeX3RlaPJUt+Mnm0zNnDHMAc1cBok5RYUhacmZ6nb2eTmJeXX5JYkqqQklqcbKvk k5qemKMQUJRZlphcqeCSWZyck5iZm1qkpJCZYqtkoqRQkJOYnJqbmldiq5RYUJCal6Jkx6WA AWyAyjLzFFLzkvNTMvPSbZU8g/11LSxMLXUNlex0Ezp5MnYevchWsJy7oq3lNWMD432OLkZO DgkBE4lTUz4wQ9hiEhfurWfrYuTiEBJoZ5L4tH0nI4SzhVFi845bbCBVbAKqEvePngPrEBEw kPg36x0jiM0sECRxqH87mC0s4CkxaVIHG0SNl0T3kS+MEHaYxOEZK9lBbBYBFYnJk2+xdDFy cPAKuEmcXVcOsWsBk8SzXevB5nMK6Eg8nnOEFcRmFJCV2H32OhPELnGJW0/mM0FcLSCxZM95 qA9EJV4+/scKYStKPLuzlB2iXkdiwe5PbBC2tsSyha/B6nkFBCVOznzCMoFRbBaSsbOQtMxC 0jILScsCRpZVjIK5GcUGZobJecl6RZm5enmpJZsYwalDw2AH4/v3FocYBTgYlXh4LW1TAoVY E8uKK3MPMUpwMCuJ8CpZAoV4UxIrq1KL8uOLSnNSiw8xugJDZSKzFHdyPjCt5ZXEGxsY4OYo ifP+Fo4OFBJIB6al7NTUgtQimDlMHJwge7ikRIqBySW1KLG0JCMelALji4FJUKqBcXWX6IMr fl8Zec/38DDzveVeLvTVmungobNXmnfeWiToqf0gV+h9UY543oPznPJ/zxnUqcb83XSk58HN aJ9zNlXfzas7F2q8f7Ep8qJdy125t3wlzY5zj07yu7/X7ZilhlvuVRl75hlVKsdtP7WrCBvN O2mXfMZzxfWFfsXrfy2Ze/CQl71qqxJLcUaioRZzUXEiAAswmsReAwAA Cc: IPsecme WG , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 17:09:21 -0000 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Michael Richardson > Sent: Tuesday, April 09, 2013 10:34 AM > > Dan> [DB] The concern is that receiver wants to protect her own > Dan> reused private key from an invalid public key from a malicious > Dan> peer. To do this, the receiver checks the received value to > Dan> make sure it is valid and safe to combine with her reused > Dan> private key. Another option for the receiver is not reusing > Dan> the private key at all. > > okay, that wasn't clear to me at all. > > When you say "private key", we are talking about the y, not the g^y. [DB] Yes (and I'm sorry if I did not use the IPSec terminology, (is it "secr= et value"?)) > > I guess I recall that there are some implementations which calculate > their g^x/g^y, and cache that for many DH operations. [DB] The implementation would also cache its secret value x (or y). > > Is the the point here is that this is safe if we do these tests. > [DB] Yes, that is the point. I gather the document's motivation was unclear to you. Were the document's= specified actions also unclear to you? Could you suggest a specific clarification to the document that would correc= t what made it unclear to you? The document reads clearly to me, but its topic is already quite familiar to= me. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From paul@cypherpunks.ca Tue Apr 9 12:00:19 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6A721F97A9 for ; Tue, 9 Apr 2013 12:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5JRLvCRVCLD for ; Tue, 9 Apr 2013 12:00:18 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 35B8C21F977A for ; Tue, 9 Apr 2013 12:00:18 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3Zld9V65dxz712; Tue, 9 Apr 2013 15:00:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id MlbWtYL2VOar; Tue, 9 Apr 2013 15:00:14 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 9 Apr 2013 15:00:14 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id E4A9E80BD7; Tue, 9 Apr 2013 15:00:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DCA58805AC; Tue, 9 Apr 2013 15:00:14 -0400 (EDT) Date: Tue, 9 Apr 2013 15:00:14 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Kanaga Kannappan In-Reply-To: <1365526990.17344.YahooMailNeo@web141003.mail.bf1.yahoo.com> Message-ID: References: <1365526990.17344.YahooMailNeo@web141003.mail.bf1.yahoo.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org" Subject: Re: [IPsec] IKEv2 initial contact handling? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 19:00:19 -0000 On Tue, 9 Apr 2013, Kanaga Kannappan wrote: > How to handle "Initial Contact Notification" during simultaneous IKEv2 SA negotiation? > > For example: A pair of gateways are initiating IKEv2 negotiation almost at the same time resulting in 2 > sets of IKEv2 SAs. In IKE_AUTH, both the boxes are sending "Initial Contact" notification and IKE_AUTH > almost cross each other. On receiving the IC, if both try to delete the other IKE SAs on the box, we end > up having different sets of IKE & child SAs on the both sides. Initial contact is a bad feature all around. A responder should just leave the old IPsec SA there to expire when its lifetime is reached. Anything else causes issues. For example, with IKEv1 if you delete the IPsec SA when you receive the payload, and then send back an IKE packet to handle things like XAUTH authenticatin, there is a time when you have no valid IPsec SA installed during a rekey, and thus tunnel downtime. Especially if XAUTH requires a human punching in things from a token. The only reason we (libreswan) implemented sending the payload (for IKEv1) is that Cisco can refuse to replace an IPsec SA when it did not receive Initial Contact, despite this new IKE having perfectly authenticated without a problem. Libreswan fully ignores receiving an initial contact payload. When it determines the peer ids match an existing IKE SA, it will replace it, but again leave the IPsec SA to expire of old age, as we cannot be sure when the other end switches from the old to the new IPsec SA. This all seems a remnant from configurations where the IDs are not unique, commercially known as 'Group PSK' configurations, which were always a bad idea as any member could pretend to be gateway and learn all the remaining XAUTH credentials of all other users. You should leave in the old IPsec SA despite the initial contact payload. If your implementation allows you to keep track, you could delete the old IPsec SA once you see traffic on the new IPsec SA. Paul From sfluhrer@cisco.com Tue Apr 9 12:12:45 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C9F21F95EB for ; Tue, 9 Apr 2013 12:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5Y9mAy-9MBk for ; Tue, 9 Apr 2013 12:12:45 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C49E521F9130 for ; Tue, 9 Apr 2013 12:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1156; q=dns/txt; s=iport; t=1365534765; x=1366744365; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YsqoD0jLAMb4IDK/OhPqHmPO2LCxbD9k9IGbCBniiis=; b=JcDeTxKUAe20qjYTH84E8aSJqbGUnYBhABK7RTpTDxwPRcFpcxmv8WlE zlVU5m9dmazerFMfayohcvsJY7E0UmLw6Z1UlPr2g12cv4oLVKoGrmKoM GnEc/hSbb0YtTEIyvnatJZFz9eVxTt7ds7blvFcdNUPmMPvCCSml0cFSO Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAE1nZFGtJXG9/2dsb2JhbABRgwbBbIEXFnSCHwEBAQQdHT8MBAIBCA4DBAEBCxQJBzIUCQgCBAENBQiIDK5ikDaOYzEHBoJaYQOoCIMLgig X-IronPort-AV: E=Sophos;i="4.87,441,1363132800"; d="scan'208";a="196781209" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 09 Apr 2013 19:12:39 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r39JCbew000958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Apr 2013 19:12:37 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.60]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 14:12:37 -0500 From: "Scott Fluhrer (sfluhrer)" To: Dan Brown , "'Michael Richardson'" Thread-Topic: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks Thread-Index: AQHONKKDikpZdmEiWUOFvhKCnr1P7JjNh4EA//+sFACAAQK2AIAACjwAgAAIcwCAACt5AP//zWpg Date: Tue, 9 Apr 2013 19:12:37 +0000 Message-ID: References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> <5697.1365476466@sandelman.ca> <17925.1365514002@sandelman.ca> <810C31990B57ED40B2062BA10D43FBF513E325@XMB111CNC.rim.net> <29765.1365518014@sandelman.ca> <810C31990B57ED40B2062BA10D43FBF513E46D@XMB111CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF513E46D@XMB111CNC.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 19:12:45 -0000 > -----Original Message----- > From: Dan Brown [mailto:dbrown@certicom.com] > Sent: Tuesday, April 09, 2013 1:09 PM > To: 'Michael Richardson' > Cc: IPsecme WG; Scott Fluhrer (sfluhrer) > Subject: RE: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks >=20 > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > > Of Michael Richardson > > Sent: Tuesday, April 09, 2013 10:34 AM > > > > > > Is the the point here is that this is safe if we do these tests. > > > [DB] Yes, that is the point. >=20 > I gather the document's motivation was unclear to you. Were the > document's specified actions also unclear to you? >=20 > Could you suggest a specific clarification to the document that would cor= rect > what made it unclear to you? It would be of great help if you (Michael) could explain what was unclear. The entire point of this draft is to explain how to do some cryptographical= checks to someone who is not familiar with cryptography. Hence, any compla= int of "I didn't understand that" is valid; it shows that we weren't as cle= ar as we hoped. From dharkins@lounge.org Tue Apr 9 13:13:19 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D4221F97EB for ; Tue, 9 Apr 2013 13:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvTMFk3y6Mlc for ; Tue, 9 Apr 2013 13:13:18 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id B774821F93F7 for ; Tue, 9 Apr 2013 13:13:18 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1207610224008 for ; Tue, 9 Apr 2013 13:13:17 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 9 Apr 2013 13:13:17 -0700 (PDT) Message-ID: <08d180a4c7de8488ae2f58370d6b5c8b.squirrel@www.trepanning.net> In-Reply-To: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> Date: Tue, 9 Apr 2013 13:13:17 -0700 (PDT) From: "Dan Harkins" To: "IPsecme WG" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 20:13:19 -0000 Hello, I think it looks fine and I have a nit that the authors can ignore if they like. I don't like the fact that RFC 5903 does not list a specific value for "a" in the parameter set definition and instead just says -3 in the equation for the curve. This draft does the same sort of thing in Section 2.3 by saying, "for groups 19, 20, 21, a=-3, and all other values of a, b and p for the group are listed in the RFC." Which to me sounds like it's the same value: minus three. Note that RFC 5114 also defines these groups but lists the proper (to me) value for "a". It's probably not right to just refer to RFC 5114, especially since RFC 5903 is listed in the repository for those curves, so my nit would be to change it to "for groups 19, 20, and 21, a = -3 mod p, and for all other values...." just to let the reader who might not be so familiar with the topic know that "a" is not the same for each curve. This is a good draft and I'm glad it was written. regards, Dan. On Mon, April 8, 2013 2:46 pm, Paul Hoffman wrote: > [[ So far, we have received only *one* review of this document, from Tero. > If we don't receive more reviews, the document might not progress due to > lack of interest. Please review this document within the next week and > contribute your review to the list. ]] > > Greetings. This is the start of the WG Last Call for > draft-ietf-ipsecme-dh-checks; the WG period will end in two weeks, on > April 15. The current draft is available at > http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-01 > > Given that this will be a Standards Track document, it is important for it > to be reviewed by as many people as possible. Possible results of > individual reviewing the document are: > > - "Looks fine, please publish" > > - "Looks fine, here are some comments" > > - "Has some problems, here they are" > > - Other things of that sort > > Many people on this mailing list are IPsec implementers but are mostly or > completely silent on the mailing list. If you are one of those people, > doing a WG Last Call review is a good way to participate usefully in the > WG. Please strongly consider (a) reading the current draft and (b) sending > a message to the list with your short or long review. If there are too few > reviews on this document, we could get pushback from the IESG about the > document. > > --Paul Hoffman > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From ynir@checkpoint.com Tue Apr 9 22:11:53 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88A121F8D2A for ; Tue, 9 Apr 2013 22:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[AWL=-8.701, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, URIBL_SBL=20] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zwlgGgtx9cS for ; Tue, 9 Apr 2013 22:11:52 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id F071521F8C3C for ; Tue, 9 Apr 2013 22:11:51 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r3A5BoiV008157; Wed, 10 Apr 2013 08:11:50 +0300 X-CheckPoint: {5164F46C-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Wed, 10 Apr 2013 08:11:49 +0300 From: Yoav Nir To: Kanaga Kannappan Thread-Topic: [IPsec] IKEv2 initial contact handling? Thread-Index: AQHONUQjOyZyB07NbE6zMjx8VDexcZjOtwCA Date: Wed, 10 Apr 2013 05:11:49 +0000 Message-ID: <141C986B-330F-41D7-8FF5-7C70DE68BA0B@checkpoint.com> References: <1365526990.17344.YahooMailNeo@web141003.mail.bf1.yahoo.com> In-Reply-To: <1365526990.17344.YahooMailNeo@web141003.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.42] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_141C986B330F41D78FF57C70DE68BA0Bcheckpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] IKEv2 initial contact handling? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 05:11:53 -0000 --_000_141C986B330F41D78FF57C70DE68BA0Bcheckpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 9, 2013, at 8:03 PM, Kanaga Kannappan > wrote: Hi All, How to handle "Initial Contact Notification" during simultaneous IKEv2 SA n= egotiation? The simplest answer is not to handle it. It makes sense that peers will do = a simultaneous negotiation for rekeying an IPsec SA. Most gateways do this = proactively, but only in response to traffic. So if both are configured to = expire SAs after 1 hour, but renegotiate after 55 minutes, then if there's = a packet when the SA is 56 minutes old, it could trigger a simultaneous re-= negotiation. OTOH when initiating the first IKE SA, it's not likely to start from both s= ides at the same time. You could probably reproduce such a case in the lab.= What you're supposed to do when presented with an Initial Contact, is dele= te all "other" IKE SAs.My code only erases established SAs (not things that= are in the middle of the initial exchanges) so if they're simultaneous eit= her both will be set up or only one based on the tie-breaker logic in RFC 5= 996. But suppose your code is different. The worst case is that each side has de= leted the IKE SA that it has initiated, and both gateways end up with one I= KE SA each (different SAs). If your code has a recovery mechanism such as R= FC 6290, that issue gets resolved quickly. I don't think this edge case is something to worry about. Yoav --_000_141C986B330F41D78FF57C70DE68BA0Bcheckpointcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7138B52226F4194B982C772C750EF622@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable
On Apr 9, 2013, at 8:03 PM, Kanaga Kannappan <kanaga_k@yahoo.com> wrote:

Hi All,

How to handle "Initial Contact Notification" during simultaneous = IKEv2 SA negotiation?


The simplest answer is not to handle it. It makes sense that peers wil= l do a simultaneous negotiation for rekeying an IPsec SA. Most gateways do = this proactively, but only in response to traffic. So if both are configure= d to expire SAs after 1 hour, but renegotiate after 55 minutes, then if there's a packet when the SA is 56 m= inutes old, it could trigger a simultaneous re-negotiation. 

OTOH when initiating the first IKE SA, it's not likely to start from b= oth sides at the same time. You could probably reproduce such a case in the= lab. What you're supposed to do when presented with an Initial Contact, is= delete all "other" IKE SAs.My code only erases established SAs (not things that are in the middle of the init= ial exchanges) so if they're simultaneous either both will be set up or onl= y one based on the tie-breaker logic in RFC 5996.

But suppose your code is different. The worst case is that each side h= as deleted the IKE SA that it has initiated, and both gateways end up with = one IKE SA each (different SAs). If your code has a recovery mechanism such= as RFC 6290, that issue gets resolved quickly.

I don't think this edge case is something to worry about.

Yoav


--_000_141C986B330F41D78FF57C70DE68BA0Bcheckpointcom_-- From kanaga_k@yahoo.com Tue Apr 9 22:16:07 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C06F21F918F for ; Tue, 9 Apr 2013 22:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5tklREJHaah for ; Tue, 9 Apr 2013 22:16:06 -0700 (PDT) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) by ietfa.amsl.com (Postfix) with SMTP id 2031821F9184 for ; Tue, 9 Apr 2013 22:16:06 -0700 (PDT) Received: from [98.139.212.151] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 10 Apr 2013 05:16:05 -0000 Received: from [98.139.212.212] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 10 Apr 2013 05:16:05 -0000 Received: from [127.0.0.1] by omp1021.mail.bf1.yahoo.com with NNFMP; 10 Apr 2013 05:16:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 472180.51499.bm@omp1021.mail.bf1.yahoo.com Received: (qmail 89159 invoked by uid 60001); 10 Apr 2013 05:16:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1365570965; bh=3UO2Cab1VP3Li1jXPvhNJbgh9A7ISdn/nWNhtLxgr0M=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=f7J5tCLUnE0RdmkDzR/HiBHgfC29HrBFRKx+Wu0GeYz+dV+DFTUzhEZAEXCKqr452NWZNUQn1HNpL8bE1rWYSjDlWkFGiTQhqBWmv+FZ8Yt4xJGDgFLorqCX7fwSfGRseM+JQ1hOcKFoaSx7UsWr4V5ZmMm3dP5Peo1LKpAMRC8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CAbOD7Auq+N82NqikR8EBgtj4CGt8un60XxTYzyNjJyEl7eDj8Aoc+j00OKTbUoGOWSNFhDlgUM1cnq5V8SORK1ie6M1LPcWNAg4czi6vETL/qrKRLP0PYUzF83+M+t9QNXqdoI4kqZ1HJRDL/b9ChJ6TIa5jLdTT8y0XrAy/ao=; X-YMail-OSG: wKiTg5QVM1mkDICZ1_nMCcjdkQLw74Dv4tYFwQXLkeOGgji ak55ZLs5lGbkjl6kcGLCSPsEuXneoe6oKyns9Mu7aaOnghJ2OivOHCS93GqL EWzxdcUR4kqRQfpQyjdUBV8SHeclNdf_9rBqbG1spM4l920wNmnfWEmMSkle LXg9hYFot1AsHz5vcVE05fKgvO1wKXvloVA4l4TXeOOtA7upSwiAVQaLQDXR ipg.7FKQGsQzVsXuoupHAFtx5XwsCxVoWOPEimZdLEqr6q2ELNjNJW_njGyQ kVyRgcG6OoJIqbmWt6BwdfU6CMZtmZ1G95BKgohU88nD065oKhLFypIJr1_8 58Iz2i5K3DhChKPJAUbPo5.Z8PvhEHEkSlrJhpRoR.JPmugmyNsgQqogmC0m CrkGyCShDGIdRBl47nbJsq2tdr371J9m7K1fMjb4RShk5waUlU5XaTfcIlnt WIdV7rvieH.kRE1GkBQl2RXjMtr1Rbwsiii0iFA3ac5B595ok_YHJtz6cOBP Iw3FamfNyowWxk0gFeg-- Received: from [116.197.178.83] by web141003.mail.bf1.yahoo.com via HTTP; Tue, 09 Apr 2013 22:16:05 PDT X-Rocket-MIMEInfo: 002.001, SGkgUGF1bCwKClRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlLgoKWWVzLCB3ZSBjYW4gcmV0YWluIHRoZSBJUHNlYyBTQXMgb24gcmVzcG9uZGVyIHRvIGF2b2lkIGJsYWNraG9saW5nLgoKQnV0IGluIElLRXYyLCBJS0UgJiBJUHNlYyBTQXMgYXJlIHRpZWQgdG9nZXRoZXIgYW5kLCBpbiB0aGlzIGNhc2Ugd2Ugd291bGQgaGF2ZSB0byBjcmVhdGUgYW4gZXhjZXB0aW9uLCB3aGVyZSBJUHNlYyBTQSB3b3VsZCBsaXZlIHdpdGhvdXQgYSBwYXJlbnQgSUtFIFNBLgoKLWthbmFnYS4KCgoKX19fX19fX19fX19fX19fX18BMAEBAQE- X-Mailer: YahooMailWebService/0.8.140.532 References: <1365526990.17344.YahooMailNeo@web141003.mail.bf1.yahoo.com> Message-ID: <1365570965.81158.YahooMailNeo@web141003.mail.bf1.yahoo.com> Date: Tue, 9 Apr 2013 22:16:05 -0700 (PDT) From: Kanaga Kannappan To: Paul Wouters In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1028315969-546434975-1365570965=:81158" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] IKEv2 initial contact handling? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Kanaga Kannappan List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 05:16:07 -0000 ---1028315969-546434975-1365570965=:81158 Content-Type: text/plain; charset=us-ascii Hi Paul, Thanks for the response. Yes, we can retain the IPsec SAs on responder to avoid blackholing. But in IKEv2, IKE & IPsec SAs are tied together and, in this case we would have to create an exception, where IPsec SA would live without a parent IKE SA. -kanaga. ________________________________ From: Paul Wouters To: Kanaga Kannappan Cc: "ipsec@ietf.org" Sent: Wednesday, April 10, 2013 12:30 AM Subject: Re: [IPsec] IKEv2 initial contact handling? On Tue, 9 Apr 2013, Kanaga Kannappan wrote: > How to handle "Initial Contact Notification" during simultaneous IKEv2 SA negotiation? > > For example: A pair of gateways are initiating IKEv2 negotiation almost at the same time resulting in 2 > sets of IKEv2 SAs. In IKE_AUTH, both the boxes are sending "Initial Contact" notification and IKE_AUTH > almost cross each other. On receiving the IC, if both try to delete the other IKE SAs on the box, we end > up having different sets of IKE & child SAs on the both sides. Initial contact is a bad feature all around. A responder should just leave the old IPsec SA there to expire when its lifetime is reached. Anything else causes issues. For example, with IKEv1 if you delete the IPsec SA when you receive the payload, and then send back an IKE packet to handle things like XAUTH authenticatin, there is a time when you have no valid IPsec SA installed during a rekey, and thus tunnel downtime. Especially if XAUTH requires a human punching in things from a token. The only reason we (libreswan) implemented sending the payload (for IKEv1) is that Cisco can refuse to replace an IPsec SA when it did not receive Initial Contact, despite this new IKE having perfectly authenticated without a problem. Libreswan fully ignores receiving an initial contact payload. When it determines the peer ids match an existing IKE SA, it will replace it, but again leave the IPsec SA to expire of old age, as we cannot be sure when the other end switches from the old to the new IPsec SA. This all seems a remnant from configurations where the IDs are not unique, commercially known as 'Group PSK' configurations, which were always a bad idea as any member could pretend to be gateway and learn all the remaining XAUTH credentials of all other users. You should leave in the old IPsec SA despite the initial contact payload. If your implementation allows you to keep track, you could delete the old IPsec SA once you see traffic on the new IPsec SA. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ---1028315969-546434975-1365570965=:81158 Content-Type: text/html; charset=us-ascii
Hi Paul,

Thanks for the response.

Yes, we can retain the IPsec SAs on responder to avoid blackholing.
But in IKEv2, IKE & IPsec SAs are tied together and, in this case we would have to create an exception, where IPsec SA would live without a parent IKE SA.

-kanaga.

From: Paul Wouters <paul@cypherpunks.ca>
To: Kanaga Kannappan <kanaga_k@yahoo.com>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Sent: Wednesday, April 10, 2013 12:30 AM
Subject: Re: [IPsec] IKEv2 initial contact handling?

On Tue, 9 Apr 2013, Kanaga Kannappan wrote:

> How to handle "Initial Contact Notification" during simultaneous IKEv2 SA negotiation?
>
> For example: A pair of gateways are initiating IKEv2 negotiation almost at the same time resulting in 2
> sets of IKEv2 SAs. In IKE_AUTH, both the boxes are sending "Initial Contact" notification and IKE_AUTH
> almost cross each other. On receiving the IC, if both try to delete the other IKE SAs on the box, we end
> up having different sets of IKE & child SAs on the both sides.

Initial contact is a bad feature all around. A responder should just
leave the old IPsec SA there to expire when its lifetime is reached.

Anything else causes issues. For example, with IKEv1 if you delete the
IPsec SA when you receive the payload, and then send back an IKE packet to
handle things like XAUTH authenticatin, there is a time when you have
no valid IPsec SA installed during a rekey, and thus tunnel downtime.
Especially if XAUTH requires a human punching in things from a token.

The only reason we (libreswan) implemented sending the payload (for IKEv1)
is that Cisco can refuse to replace an IPsec SA when it did not receive
Initial Contact, despite this new IKE having perfectly authenticated
without a problem. Libreswan fully ignores receiving an initial contact
payload. When it determines the peer ids match an existing IKE SA, it
will replace it, but again leave the IPsec SA to expire of old age, as
we cannot be sure when the other end switches from the old to the new
IPsec SA.

This all seems a remnant from configurations where the IDs are not
unique, commercially known as 'Group PSK' configurations, which were
always a bad idea as any member could pretend to be gateway and learn
all the remaining XAUTH credentials of all other users.

You should leave in the old IPsec SA despite the initial contact
payload. If your implementation allows you to keep track, you could
delete the old IPsec SA once you see traffic on the new IPsec SA.

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


---1028315969-546434975-1365570965=:81158-- From Johannes.Merkle@secunet.com Wed Apr 10 05:28:33 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62F021F9612 for ; Wed, 10 Apr 2013 05:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkoLVI2UdAPV for ; Wed, 10 Apr 2013 05:28:32 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5E82121F90B8 for ; Wed, 10 Apr 2013 05:28:32 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 081921A008A for ; Wed, 10 Apr 2013 14:28:31 +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 IoR2MKb70SEV for ; Wed, 10 Apr 2013 14:28:29 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 8222F1A0085 for ; Wed, 10 Apr 2013 14:28:29 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Apr 2013 14:28:29 +0200 Message-ID: <51655AEC.9040203@secunet.com> Date: Wed, 10 Apr 2013 14:28:28 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ipsec@ietf.org References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> In-Reply-To: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2013 12:28:29.0370 (UTC) FILETIME=[E82349A0:01CE35E6] Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 12:28:33 -0000 "Looks fine, please publish" Johannes > [[ So far, we have received only *one* review of this document, from Tero. If we don't receive more reviews, the document might not progress due to lack of interest. Please review this document within the next week and contribute your review to the list. ]] > > Greetings. This is the start of the WG Last Call for draft-ietf-ipsecme-dh-checks; the WG period will end in two weeks, on April 15. The current draft is available at http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-01 > > Given that this will be a Standards Track document, it is important for it to be reviewed by as many people as possible. Possible results of individual reviewing the document are: > > - "Looks fine, please publish" > > - "Looks fine, here are some comments" > > - "Has some problems, here they are" > > - Other things of that sort > > Many people on this mailing list are IPsec implementers but are mostly or completely silent on the mailing list. If you are one of those people, doing a WG Last Call review is a good way to participate usefully in the WG. Please strongly consider (a) reading the current draft and (b) sending a message to the list with your short or long review. If there are too few reviews on this document, we could get pushback from the IESG about the document. > From svanru@gmail.com Wed Apr 10 06:50:20 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFA821F97C3 for ; Wed, 10 Apr 2013 06:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRel-fsi691v for ; Wed, 10 Apr 2013 06:50:19 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id E6CA021F97B9 for ; Wed, 10 Apr 2013 06:50:18 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id s10so544420lbi.19 for ; Wed, 10 Apr 2013 06:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=mB+Ej89nyjOFLQB7G/xKG/8PsJHQ030B4f411SzNoMk=; b=zbJHQW3bvZ4GQnlr0+7qeGh9QTlpv77unSBSFqBUZGJRPP2CTQpzGJGd4mT4TrNu+G LAUelbhMu8hOkOgLxnGwCvW6T2N8Y23gfT09NvM2oP6YYZekj2Eb6jv8jfD02Lo3QNUg U/B7kGwIqZOEbEilMrkJSdKjJfuc31Kv2eGJcSLmXPo2iy17ptAib/WRBpOUr3DJcpDr 0wJ5ZAQ4QyBsjJDRixPcetyXCDLpq5BjI7edT5XXaEi4CW7bW7Km98Uq84jlvS6iEnUh z6Hd/+Fi/3J9GolgU5uHKgXTRaPSO6wb6soNrDKvXFMAFpOrbc52gTprV/am0NMEVdSt do6w== X-Received: by 10.112.155.202 with SMTP id vy10mr1276683lbb.51.1365601817796; Wed, 10 Apr 2013 06:50:17 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id p1sm31353lae.0.2013.04.10.06.50.16 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Apr 2013 06:50:16 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: Date: Wed, 10 Apr 2013 17:50:14 +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 Subject: [IPsec] Fw: New Version Notification fordraft-smyslov-ipsecme-ikev2-fragmentation-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 13:50:20 -0000 Hi, I have posted a new version of IKEv2 Fragmentation draft. It was rewritten to clarify protocol details and to accomodate received comments. Regards, Valery Smyslov. > --------------------------------------------------------- > A new version of I-D, draft-smyslov-ipsecme-ikev2-fragmentation-01.txt > has been successfully submitted by Valery Smyslov and posted to the > IETF repository. > > Filename: draft-smyslov-ipsecme-ikev2-fragmentation > Revision: 01 > Title: IKEv2 Fragmentation > Creation date: 2013-04-10 > Group: Individual Submission > Number of pages: 15 > URL: > http://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-fragmentation-01.txt > Status: > http://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-fragmentation > Htmlized: > http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-fragmentation-01 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-smyslov-ipsecme-ikev2-fragmentation-01 > > Abstract: > This document describes the way to avoid IP fragmentation of large > IKEv2 messages. This allows IKEv2 messages to traverse network > devices that don't allow IP fragments to pass through. > > > > > The IETF Secretariat > From kivinen@iki.fi Thu Apr 11 06:12:16 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F7621F8AC2 for ; Thu, 11 Apr 2013 06:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17Jgp8u77QId for ; Thu, 11 Apr 2013 06:12:15 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B06D21F85BF for ; Thu, 11 Apr 2013 06:12:13 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3BDBpS9015817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Apr 2013 16:11:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3BDBlew007075; Thu, 11 Apr 2013 16:11:47 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20838.46739.562430.596310@fireball.kivinen.iki.fi> Date: Thu, 11 Apr 2013 16:11:47 +0300 From: Tero Kivinen To: Kanaga Kannappan In-Reply-To: <1365570965.81158.YahooMailNeo@web141003.mail.bf1.yahoo.com> References: <1365526990.17344.YahooMailNeo@web141003.mail.bf1.yahoo.com> <1365570965.81158.YahooMailNeo@web141003.mail.bf1.yahoo.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 23 min X-Total-Time: 26 min Cc: "ipsec@ietf.org" , Paul Wouters Subject: Re: [IPsec] IKEv2 initial contact handling? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 13:12:16 -0000 Kanaga Kannappan writes: > Yes, we can retain the IPsec SAs on responder to avoid blackholing. > > But in IKEv2, IKE & IPsec SAs are tied together and, in this case we > would have to create an exception, where IPsec SA would live without > a parent IKE SA. No. First of all INITIAL_CONTACT is never sent rekeying so that is not a problem. It is only sent when the end does not have any IKE or IPsec SAs with the other end. Secondly, you are only supposed to delete IKE SAs you have with the other end, i.e. not the ones you are middle of negotiating with. Also as this notification is included in the IKE_AUTH, it can only happen if the IKE_AUTH payloads really cross each other on the wire. As it might be possible that the first packets did cross on the wire, but one of them got lost, and thats why it looks like the other peer is sending INITIAL_CONTACT notification even after the first IKE SA has already been created, you still need to take care of that situation. I.e. the generic case you need to take care of is: Host A Host B ------ ------ 1) IKE_SA_INIT request --> <-- IKE_SA_INIT request 2) IKE_SA_INIT reply --> <-- IKE_SA_INIT reply 3) IKE_AUTH request --> (the IKE_AUTH of host B got lost) 4) Host B receives IKE_AUTH request, sends reply 5) <-- IKE_AUTH reply 6) Host A gets IKE_AUTH reply, finishes IKE SA 7) <-- IKE_AUTH request retransmission 8) Host A gets IKE_AUTH request with INITIAL_CONCACT notification 9) Host A replies to it 10) IKE_AUTH reply --> 11) Host B gets IKE_AUTH reply and finishes 2nd IKE SA Now the problem would be in the step 8, where the Host A has already finished the IKE SA, and gets INITIAL_CONTACT notification from the other end. There are few ways to solve this, either it can check that as the IKE SA it has was not ready at the point when this IKE SA negotiation started, and detect that this is exchange collision. With this exchange collision, it might simply continue normally and not to delete the IKE SA it already has as this is exchange collision. After this it has two IKE SAs and that is not a problem. Other options the Host A could do is when it detects exchange collision is to remove one of the IKE SAs, but in that case it needs to send IKE SA delete to inform the other end that it has deleted it, as this is not the case of leftover IKE SAs, but it is the case of exchange collision. Other option is to simply not to delete "recently" created IKE SAs, and simply assume all of those are collisions. What it could do for those "recently" created IKE SA is to assume that they might be dead, and it could start dead peer detection for them, or it can simply wait for the normal dead peer detection to kick up when there is no traffic from the other end. The definition of recently could be something like last 30 seconds. Note, that it should not be considered a problem to have multiple IKE SAs between two peers. The INITIAL_CONTACT notification is not supposed to be preventing that, it is supposed to clear out old unused IKE SAs the other end might have. If both ends are configured to automatically initiate connections immediately when the there is on IKE SA (which can cause this setup), then it is best to configure SAs so that they do not send INITIAL_CONTACT notifications. If the IKE SA is kept alive all the time, then normal dead peer detection and other methods will take care of the old SAs. INITIAL_CONTACT was much more important in the IKEv1 world where there was no reliable deletes, or other ways of knowing whether the other end was alive or not. In IKEv2 there is less need for it, so leaving it out does not cause that much problems. -- kivinen@iki.fi From paul@cypherpunks.ca Thu Apr 11 06:48:38 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF88721F8ADC for ; Thu, 11 Apr 2013 06:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmlP8M-CkalV for ; Thu, 11 Apr 2013 06:48:38 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1F28021F8B13 for ; Thu, 11 Apr 2013 06:48:38 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3Zmk8v4nw6z79M; Thu, 11 Apr 2013 09:48:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id FkKmuw9meLpa; Thu, 11 Apr 2013 09:48:30 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 11 Apr 2013 09:48:30 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 3B46080BD7; Thu, 11 Apr 2013 09:48:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2F1EE80862; Thu, 11 Apr 2013 09:48:31 -0400 (EDT) Date: Thu, 11 Apr 2013 09:48:31 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Tero Kivinen In-Reply-To: <20838.46739.562430.596310@fireball.kivinen.iki.fi> Message-ID: References: <1365526990.17344.YahooMailNeo@web141003.mail.bf1.yahoo.com> <1365570965.81158.YahooMailNeo@web141003.mail.bf1.yahoo.com> <20838.46739.562430.596310@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org" , Kanaga Kannappan Subject: Re: [IPsec] IKEv2 initial contact handling? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 13:48:38 -0000 On Thu, 11 Apr 2013, Tero Kivinen wrote: > First of all INITIAL_CONTACT is never sent rekeying so that is not a > problem. It is only sent when the end does not have any IKE or IPsec > SAs with the other end. But this can happen in various scenarios where your IKE's lifetime passed but not the IPsec SA lifetime. Then you might have one or more IPsec SA' open to the other end but without the corresponding IKE SA you might not realise these SA's are to the same peer. > Note, that it should not be considered a problem to have multiple IKE > SAs between two peers. The INITIAL_CONTACT notification is not > supposed to be preventing that, it is supposed to clear out old unused > IKE SAs the other end might have. You mean unused IPsec SA's right? Because clearing out old IKE SA's is easy - if the IDs match and you establish the IKE SA, loop through all existing IKE SA's and if the credentials/IDs match (and this is not some group PSK kind of setup) then delete the old IKE SA. Openswan/libreswan never used initial contact to determine that. > INITIAL_CONTACT was much more important in the IKEv1 world where there > was no reliable deletes, or other ways of knowing whether the other > end was alive or not. In IKEv2 there is less need for it, so leaving > it out does not cause that much problems. I really only see the need for initial contact to interop with Cisco, who can refuse to replace an existing IKE SA without the latest incoming IKE request carrying the INITIAL_CONTACT payload - at least for IKEv1. Paul From kivinen@iki.fi Thu Apr 11 07:13:24 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F4C21F896E for ; Thu, 11 Apr 2013 07:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuBUTWGnYiFc for ; Thu, 11 Apr 2013 07:13:24 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5D521F884A for ; Thu, 11 Apr 2013 07:13:23 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3BEBlRZ008372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Apr 2013 17:11:47 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3BEBltC013996; Thu, 11 Apr 2013 17:11:47 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20838.50339.338198.280192@fireball.kivinen.iki.fi> Date: Thu, 11 Apr 2013 17:11:47 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <1365526990.17344.YahooMailNeo@web141003.mail.bf1.yahoo.com> <1365570965.81158.YahooMailNeo@web141003.mail.bf1.yahoo.com> <20838.46739.562430.596310@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: "ipsec@ietf.org" , Kanaga Kannappan Subject: Re: [IPsec] IKEv2 initial contact handling? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 14:13:24 -0000 Paul Wouters writes: > On Thu, 11 Apr 2013, Tero Kivinen wrote: > > > First of all INITIAL_CONTACT is never sent rekeying so that is not a > > problem. It is only sent when the end does not have any IKE or IPsec > > SAs with the other end. > > But this can happen in various scenarios where your IKE's lifetime > passed but not the IPsec SA lifetime. Then you might have one or more > IPsec SA' open to the other end but without the corresponding IKE SA > you might not realise these SA's are to the same peer. Not with IKEv2. If the IKE SA lifetime is gone, then you REKEY the IKE SA. This cannot cause INITIAL_CONTACT notifications. Also when IKE SA is expired, or deleted all the IPsec SAs are also deleted automatically, so there is also no problem for INITIAL_CONTACT. > > Note, that it should not be considered a problem to have multiple IKE > > SAs between two peers. The INITIAL_CONTACT notification is not > > supposed to be preventing that, it is supposed to clear out old unused > > IKE SAs the other end might have. > > You mean unused IPsec SA's right? Both IKE and IPsec SAs. > Because clearing out old IKE SA's is easy - if the IDs match and you > establish the IKE SA, loop through all existing IKE SA's and if the > credentials/IDs match (and this is not some group PSK kind of setup) > then delete the old IKE SA. Openswan/libreswan never used initial > contact to determine that. There is nothing in the RFC5996 that says you should do or need to do that. Nothing there prevents peer to create multiple IKE SAs with same ID payloads with the peer. In some cases it is even needed. For example in some high availibitity environments the peer is using same ID payload, but different IP addresses, and each node in cluster might create separate IKE SA to the other peer and all of them have identical ID. You implementation will prevent that from working. > > INITIAL_CONTACT was much more important in the IKEv1 world where there > > was no reliable deletes, or other ways of knowing whether the other > > end was alive or not. In IKEv2 there is less need for it, so leaving > > it out does not cause that much problems. > > I really only see the need for initial contact to interop with Cisco, > who can refuse to replace an existing IKE SA without the latest incoming > IKE request carrying the INITIAL_CONTACT payload - at least for IKEv1. We are not talking IKEv1 here. IKEv1 has lots of problems with reliability and state syncronization, so the issues with it are completely different. The subject was about INITIAL_CONTACT in IKEv2. -- kivinen@iki.fi From paul@cypherpunks.ca Thu Apr 11 07:49:02 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB56C21F88A0 for ; Thu, 11 Apr 2013 07:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgBj+GjPjced for ; Thu, 11 Apr 2013 07:49:02 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 364FD21F888B for ; Thu, 11 Apr 2013 07:49:02 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ZmlVZ2XG5z7Lj; Thu, 11 Apr 2013 10:48:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id dLEx4pH2mnrG; Thu, 11 Apr 2013 10:48:53 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 11 Apr 2013 10:48:53 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 47EA980BD7; Thu, 11 Apr 2013 10:48:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 39C55805AC; Thu, 11 Apr 2013 10:48:53 -0400 (EDT) Date: Thu, 11 Apr 2013 10:48:53 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Tero Kivinen In-Reply-To: <20838.50339.338198.280192@fireball.kivinen.iki.fi> Message-ID: References: <1365526990.17344.YahooMailNeo@web141003.mail.bf1.yahoo.com> <1365570965.81158.YahooMailNeo@web141003.mail.bf1.yahoo.com> <20838.46739.562430.596310@fireball.kivinen.iki.fi> <20838.50339.338198.280192@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org" , Kanaga Kannappan Subject: Re: [IPsec] IKEv2 initial contact handling? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 14:49:02 -0000 On Thu, 11 Apr 2013, Tero Kivinen wrote: > Not with IKEv2. > > If the IKE SA lifetime is gone, then you REKEY the IKE SA. This cannot > cause INITIAL_CONTACT notifications. Also when IKE SA is expired, or > deleted all the IPsec SAs are also deleted automatically, so there is > also no problem for INITIAL_CONTACT. Understood. I'll re-read the RFCs before implementing this for IKEv2. > You implementation will prevent that from working. We have an option to choose this behaviour, uniqueids=yes|no (default yes) Paul From sandeepkampati@huawei.com Fri Apr 12 02:52:16 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B161621F855A for ; Fri, 12 Apr 2013 02:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECR98eqF5RvQ for ; Fri, 12 Apr 2013 02:52:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9673F21F854F for ; Fri, 12 Apr 2013 02:52:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQH85829; Fri, 12 Apr 2013 09:52:14 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Apr 2013 10:51:36 +0100 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Apr 2013 10:52:10 +0100 Received: from blrprnc07ns (10.18.96.96) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server id 14.1.323.7; Fri, 12 Apr 2013 17:50:07 +0800 From: sandeep kampati To: "'Paul Wouters'" , "'Tero Kivinen'" References: <1365526990.17344.YahooMailNeo@web141003.mail.bf1.yahoo.com> <1365570965.81158.YahooMailNeo@web141003.mail.bf1.yahoo.com> <20838.46739.562430.596310@fireball.kivinen.iki.fi> <20838.50339.338198.280192@fireball.kivinen.iki.fi> In-Reply-To: Date: Fri, 12 Apr 2013 15:20:06 +0530 Organization: htipl Message-ID: <000301ce3763$1d7ffc60$587ff520$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac42w8FO1itx7OUsQyW8hI7t2Jp+DwAnnCnQ Content-Language: en-us X-Originating-IP: [10.18.96.96] X-CFilter-Loop: Reflected Cc: ipsec@ietf.org, 'Kanaga Kannappan' Subject: Re: [IPsec] IKEv2 initial contact handling? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sandeepkampati@huawei.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 09:52:16 -0000 In IKEv2 it MUST not send INITIAL_CONTACT notifications at time of reauthentication -Sandeep.kampati From kivinen@iki.fi Fri Apr 12 04:14:21 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B26721F89D3 for ; Fri, 12 Apr 2013 04:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yb7shNG5sDoh for ; Fri, 12 Apr 2013 04:14:21 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 94E5A21F8618 for ; Fri, 12 Apr 2013 04:14:20 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3CBEFOE012226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Apr 2013 14:14:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3CBEFOT021483; Fri, 12 Apr 2013 14:14:15 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20839.60551.20813.560946@fireball.kivinen.iki.fi> Date: Fri, 12 Apr 2013 14:14:15 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min Subject: [IPsec] FWD from internet-drafts@ietf.org: [Lwip] I-D Action: draft-ietf-lwig-ikev2-minimal-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 11:14:21 -0000 I submitted the minimal IKEv2 draft to the LWIG WG. This new version includes new updated text for the Raw Public Keys part. ---------------------------------------------------------------------- From: internet-drafts@ietf.org Sender: lwip-bounces@ietf.org To: i-d-announce@ietf.org Cc: lwip@ietf.org Subject: [Lwip] I-D Action: draft-ietf-lwig-ikev2-minimal-00.txt Date: Thu, 11 Apr 2013 18:41:39 -0700 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Light-Weight Implementation Guidance Working Group of the IETF. Title : Minimal IKEv2 Author(s) : Tero Kivinen Filename : draft-ietf-lwig-ikev2-minimal-00.txt Pages : 44 Date : 2013-04-11 Abstract: This document describes minimal version of the Internet Key Exchange version 2 (IKEv2) protocol. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation, and also describes various optimizations which can be done. The protocol described here is compliant with full IKEv2 with exception that this document only describes shared secret authentication (IKEv2 requires support for certificate authentication in addition to shared secret authentication). This document does not update or modify RFC 5996, but provides more compact description of the minimal version of the protocol. If this document and RFC 5996 conflicts then RFC 5996 is the authoritative description. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lwig-ikev2-minimal There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lwig-ikev2-minimal-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip -- kivinen@iki.fi From dharkins@lounge.org Fri Apr 12 15:47:36 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3562521F88A0 for ; Fri, 12 Apr 2013 15:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0x8uh69Ipqx for ; Fri, 12 Apr 2013 15:47:35 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id BA20D21F878F for ; Fri, 12 Apr 2013 15:47:35 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 94A8FA888010 for ; Fri, 12 Apr 2013 15:47:35 -0700 (PDT) Received: from 199.127.104.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 12 Apr 2013 15:47:35 -0700 (PDT) Message-ID: <05ee1611c9732b5410df679113ebcf79.squirrel@www.trepanning.net> Date: Fri, 12 Apr 2013 15:47:35 -0700 (PDT) From: "Dan Harkins" To: ipsec@ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [IPsec] new version of IKEv3 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 22:47:36 -0000 Hello! I've updated IKEv3 and the new version has been posted (see below). Major changes are: * support for NAT-T (which is different than the way it was done in prior versions of IKE, please take a look at it). * addressing the MiTM attack Valery Smyslov brought up on the list. * allowing more than one IKE SA per peer (which was kind of necessary to support NATs). I look forward to hearing any comments or issues people have with this protocol. As usual, if you plan on implementing it and would like to interoperate I'd love to hear from you. regards, Dan. ---------------------------------------------------------- A new version of I-D, draft-harkins-ikev3-01.txt has been successfully submitted by Dan Harkins and posted to the IETF repository. Filename: draft-harkins-ikev3 Revision: 01 Title: The (Real) Internet Key Exchange Creation date: 2013-04-12 Group: Individual Submission Number of pages: 43 URL: http://www.ietf.org/internet-drafts/draft-harkins-ikev3-01.txt Status: http://datatracker.ietf.org/doc/draft-harkins-ikev3 Htmlized: http://tools.ietf.org/html/draft-harkins-ikev3-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-harkins-ikev3-01 Abstract: The current version (v2) of the Internet Key Exchange failed to address many of the shortcomings of the original version (v1). This memo defines a new version (v3) of the Internet Key Exchange that attempts to do so. From Johannes.Merkle@secunet.com Mon Apr 15 05:01:53 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4838A21F900D for ; Mon, 15 Apr 2013 05:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7eivhuKelTs for ; Mon, 15 Apr 2013 05:01:52 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id A3A2C21F8F7F for ; Mon, 15 Apr 2013 05:01:52 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 706201A0139; Mon, 15 Apr 2013 14:01:49 +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 pIbouigutkNv; Mon, 15 Apr 2013 14:01:47 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id CA5751A008E; Mon, 15 Apr 2013 14:01:47 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Apr 2013 14:01:47 +0200 Message-ID: <516BEC2B.6010707@secunet.com> Date: Mon, 15 Apr 2013 14:01:47 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ipsec@ietf.org, kivinen@iki.fi References: <20799.34918.969821.935296@fireball.kivinen.iki.fi> In-Reply-To: <20799.34918.969821.935296@fireball.kivinen.iki.fi> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Apr 2013 12:01:47.0892 (UTC) FILETIME=[01A5E340:01CE39D1] Subject: Re: [IPsec] Signature authentication in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 12:01:53 -0000 Tero Kivinen wrote on 12.03.2013 20:56: > In the meeting I did not remember what was the name the PKIX had for > the signature blob, and in my slides written at midnight Sunday > evening, I said SubjectPublicKeyInfo, so here I am to provide some > correct information... > > So the thing is what is both in the signatureAlgorithm and > SubjectPublicKeyInfo, i.e. the AlgorithmI?dentifier: > > AlgorithmIdentifier ::= SEQUENCE { > algorithm OBJECT IDENTIFIER, > parameters ANY DEFINED BY algorithm OPTIONAL } > > > I.e where there algorithm is the OID we currently have in the > draft-kivinen-ipsecme-signature-auth, and the parameters is the one is > required to get the RSASSA-PSS to work. > > Anybody has objection to do it this way? > I agree with your proposal. It has become quiet around this draft. I really think, it is an important simplification of IKEv2 in the long tun. When can we expect the new revision? -- Johannes From kivinen@iki.fi Mon Apr 15 06:52:55 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726F421F86DE for ; Mon, 15 Apr 2013 06:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAZ4SvPxFzmJ for ; Mon, 15 Apr 2013 06:52:55 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B74321F86C5 for ; Mon, 15 Apr 2013 06:52:54 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3FDpamg022778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Apr 2013 16:51:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3FDpaT4005586; Mon, 15 Apr 2013 16:51:36 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20844.1512.584467.218852@fireball.kivinen.iki.fi> Date: Mon, 15 Apr 2013 16:51:36 +0300 From: Tero Kivinen To: Johannes Merkle In-Reply-To: <516BEC2B.6010707@secunet.com> References: <20799.34918.969821.935296@fireball.kivinen.iki.fi> <516BEC2B.6010707@secunet.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Signature authentication in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 13:52:55 -0000 Johannes Merkle writes: > Tero Kivinen wrote on 12.03.2013 20:56: > > In the meeting I did not remember what was the name the PKIX had for > > the signature blob, and in my slides written at midnight Sunday > > evening, I said SubjectPublicKeyInfo, so here I am to provide some > > correct information... > > > > So the thing is what is both in the signatureAlgorithm and > > SubjectPublicKeyInfo, i.e. the AlgorithmI?dentifier: > > > > AlgorithmIdentifier ::= SEQUENCE { > > algorithm OBJECT IDENTIFIER, > > parameters ANY DEFINED BY algorithm OPTIONAL } > > > > > > I.e where there algorithm is the OID we currently have in the > > draft-kivinen-ipsecme-signature-auth, and the parameters is the one is > > required to get the RSASSA-PSS to work. > > > > Anybody has objection to do it this way? > > > > I agree with your proposal. > > It has become quiet around this draft. I really think, it is an > important simplification of IKEv2 in the long tun. When > can we expect the new revision? Last week I would have said by the Thursday of last week, but then I ended up wasting more than a day trying to get the xml2rfc working (and trying the new version, and accidently updating my desktop etc), so I only managed to put out the first 2 of my drafts. I will try to update this tomorrow... -- kivinen@iki.fi From paul.hoffman@vpnc.org Tue Apr 16 09:09:30 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E7E21F9718 for ; Tue, 16 Apr 2013 09:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJRrUicxV8ft for ; Tue, 16 Apr 2013 09:09:24 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD3221F9711 for ; Tue, 16 Apr 2013 09:09:23 -0700 (PDT) Received: from [192.168.1.60] (c-98-210-236-174.hsd1.ca.comcast.net [98.210.236.174]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3GG97rC064260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Apr 2013 09:09:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Tue, 16 Apr 2013 09:09:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6CD9AE1A-1D27-42A6-8F59-EC7A6A4CECA3@vpnc.org> References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> <5697.1365476466@sandelman.ca> <17925.1365514002@sandelman.ca> <810C31990B57ED40B2062BA10D43FBF513E325@XMB111CNC.rim.net> <29765.1365518014@sandelman.ca> <810C31990B57ED40B2062BA10D43FBF513E46D@XMB111CNC.rim.net> To: Michael Richardson X-Mailer: Apple Mail (2.1503) Cc: IPsecme WG Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 16:09:30 -0000 +1 to "now that you understand it, please show where you were confused = before" so that we can close out the document and move it to the IETF. --Paul Hoffman On Apr 9, 2013, at 12:12 PM, Scott Fluhrer (sfluhrer) = wrote: >=20 >=20 >> -----Original Message----- >> From: Dan Brown [mailto:dbrown@certicom.com] >> Sent: Tuesday, April 09, 2013 1:09 PM >> To: 'Michael Richardson' >> Cc: IPsecme WG; Scott Fluhrer (sfluhrer) >> Subject: RE: [IPsec] NUDGE: WG Last Call for = draft-ietf-ipsecme-dh-checks >>=20 >>> -----Original Message----- >>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On = Behalf >>> Of Michael Richardson >>> Sent: Tuesday, April 09, 2013 10:34 AM >>>=20 >>>=20 >>> Is the the point here is that this is safe if we do these tests. >>>=20 >> [DB] Yes, that is the point. >>=20 >> I gather the document's motivation was unclear to you. Were the >> document's specified actions also unclear to you? >>=20 >> Could you suggest a specific clarification to the document that would = correct >> what made it unclear to you? >=20 > It would be of great help if you (Michael) could explain what was = unclear. >=20 > The entire point of this draft is to explain how to do some = cryptographical checks to someone who is not familiar with cryptography. = Hence, any complaint of "I didn't understand that" is valid; it shows = that we weren't as clear as we hoped. From paul.hoffman@vpnc.org Tue Apr 16 09:12:33 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D455721F974D for ; Tue, 16 Apr 2013 09:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sNFrZBoY1-a for ; Tue, 16 Apr 2013 09:12:33 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B0F6321F977B for ; Tue, 16 Apr 2013 09:12:30 -0700 (PDT) Received: from [192.168.1.60] (c-98-210-236-174.hsd1.ca.comcast.net [98.210.236.174]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3GGBuMh064488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 16 Apr 2013 09:12:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman X-Priority: 3 (Normal) In-Reply-To: <08d180a4c7de8488ae2f58370d6b5c8b.squirrel@www.trepanning.net> Date: Tue, 16 Apr 2013 09:11:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <78485366-9595-4268-9E3F-93C6FC2EED88@vpnc.org> References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> <08d180a4c7de8488ae2f58370d6b5c8b.squirrel@www.trepanning.net> To: IPsecme WG X-Mailer: Apple Mail (2.1503) Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 16:12:33 -0000 On Apr 9, 2013, at 1:13 PM, Dan Harkins wrote: > I think it looks fine and I have a nit that the authors can ignore > if they like. >=20 > I don't like the fact that RFC 5903 does not list a specific value = for > "a" in the parameter set definition and instead just says -3 in the > equation for the curve. This draft does the same sort of thing in > Section 2.3 by saying, "for groups 19, 20, 21, a=3D-3, and all other > values of a, b and p for the group are listed in the RFC." Which to > me sounds like it's the same value: minus three. >=20 > Note that RFC 5114 also defines these groups but lists the proper > (to me) value for "a". It's probably not right to just refer to RFC = 5114, > especially since RFC 5903 is listed in the repository for those = curves, > so my nit would be to change it to "for groups 19, 20, and 21, > a =3D -3 mod p, and for all other values...." just to let the reader = who > might not be so familiar with the topic know that "a" is not the same > for each curve. This sounds like a good clarification. Authors: please revise the draft = with this (and whatever text you can to clear up Michael Richardson's = earlier confusion). --Paul Hoffman= From mcr@sandelman.ca Tue Apr 16 10:02:00 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEACB21F9716 for ; Tue, 16 Apr 2013 10:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRVItcxazgs4 for ; Tue, 16 Apr 2013 10:02:00 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id E925721F9715 for ; Tue, 16 Apr 2013 10:01:59 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3EBCF20168 for ; Tue, 16 Apr 2013 13:11:55 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4B99E639D9; Tue, 16 Apr 2013 13:01:31 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 38839638E4 for ; Tue, 16 Apr 2013 13:01:31 -0400 (EDT) From: Michael Richardson To: IPsecme WG In-Reply-To: <6CD9AE1A-1D27-42A6-8F59-EC7A6A4CECA3@vpnc.org> References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> <5697.1365476466@sandelman.ca> <17925.1365514002@sandelman.ca> <810C31990B57ED40B2062BA10D43FBF513E325@XMB111CNC.rim.net> <29765.1365518014@sandelman.ca> <810C31990B57ED40B2062BA10D43FBF513E46D@XMB111CNC.rim.net> <6CD9AE1A-1D27-42A6-8F59-EC7A6A4CECA3@vpnc.org> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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 Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 17:02:01 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Paul" =3D=3D Paul Hoffman writes: Paul> +1 to "now that you understand it, please show where you were Paul> confused before" so that we can close out the document and Paul> move it to the IETF.=20 sorry, day job got in the way. rereading section 2.1/2.2 again. This leakage can be prevented if the recipient performs a test on the peer's public value, however this test is expensive (approximately as expensive as what reusing DH private values saves). does the stuff in () add anything? And is the word "saves" correct? In addition, the NIST standard [NIST-800-56A] requires that test (see section 5.6.2.4), hence anyone needing to conform to that standard will need to implement the test anyway. ("that test" refers to the test on the peer's public value? Visiting NIST-800-56A section 5.6.2.4.. but that section refers to private/public key pair generation, not MODP groups... but anyway. my suggested text: For a node which wishes to reuse its DH private value, in order to avoid this leakage, the following test is to be performed on the public value received from the peer before combining it with the node's private value. While this test is expensive, it is no more expensive than generating new DH private values, except that it does not require access to a high quality random value. This test is mandated by the NIST standard [NIST-800-56A] (see section 5.6.2.4), and is described here: It MUST check both that the peer's public value is in range (1 < r < p-1) and that r**q =3D 1 mod p (where q is the size of the subgroup, as listed in the RFC).=20=20 DH private values MAY then be reused.=20=20 This option is appropriate if conformance to [NIST-800-56A] is requir= ed. Alternatively, it MUST NOT reuse DH private values (that is, the DH private value=20 for each DH exchange MUST be generated from a fresh output of a cryptographically secure random number generator), and it MUST check that the peer's public value is in range (1 < r < p-1). This option is more appropriate if conformance to [NIST-800-56A] is not required. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUW2D64qHRg3pndX9AQKmFwQAxsqGEAP7fJu8QzdUqsHKJTtp+CUnp0Im QwjiMWyXBgOmzEKhrkmA7T+2bPaEn/wz/v9sDgaYhQ3z5K5zevdi93um91b6AqVg D1FkXSym8RfcikbYJ+qpMGotH85hRXFKRwmim/INhMqGGNCI7eDKRbnLCJekYFKy lN1DSZ4pQJw= =4WRe -----END PGP SIGNATURE----- --=-=-=-- From paul.hoffman@vpnc.org Wed Apr 17 08:18:43 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0461221E8050 for ; Wed, 17 Apr 2013 08:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESO5c1sEzMjy for ; Wed, 17 Apr 2013 08:18:42 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF5521E804C for ; Wed, 17 Apr 2013 08:18:42 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3HFIeEA017199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Apr 2013 08:18:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Wed, 17 Apr 2013 08:18:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Hoffman X-Mailer: Apple Mail (2.1503) Cc: IPsecme WG Subject: [IPsec] STRONG NUDGE: WG Last Call on draft-ietf-ipsecme-oob-pubkey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 15:18:43 -0000 We have gotten exactly one response to this, even though there were lots = of people who said they thought this was a valuable addition to IKEv2. = Please comment before Monday so we don't have to abandon the work. --Paul Hoffman On Apr 8, 2013, at 2:43 PM, Paul Hoffman wrote: > Greetings again. This begins the WG Last Call on = draft-ietf-ipsecme-oob-pubkey, "More Raw Public Keys for IKEv2". You can = find the current draft at = http://tools.ietf.org/html/draft-ietf-ipsecme-oob-pubkey >=20 > This document generated a fair amount of interest early, but we have = not had much discussion since. Yaron and I would *really* like to have = at least five WG members review the document and say on the list whether = or not they think it is ready in its current state to move to IETF = review. If you read it and feel it is not ready for any reason, please = also say that in your message to the list. >=20 > Again, participating in WG Last Calls is a great opportunity for those = who are less active in the WG but who want to contribute to the IETF to = make a difference. >=20 > The WG Last Call should end in two weeks, on April 22. Please review = the document before then. Thanks in advance! From kivinen@iki.fi Thu Apr 18 02:28:16 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0DD21F894B for ; Thu, 18 Apr 2013 02:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 314ZvGSjJ1YM for ; Thu, 18 Apr 2013 02:28:16 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E95421F8972 for ; Thu, 18 Apr 2013 02:28:15 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3I9QjYj012582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Apr 2013 12:26:45 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3I9QinG012877; Thu, 18 Apr 2013 12:26:44 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20847.48212.437658.582136@fireball.kivinen.iki.fi> Date: Thu, 18 Apr 2013 12:26:44 +0300 From: Tero Kivinen To: noblea@cisco.com, sgundave@cisco.com, jouni.nospam@gmail.com, baboescu@broadcom.com X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 12 min Cc: ipsec@ietf.org Subject: [IPsec] Some comments to the draft-gundavelli-ipsecme-3gpp-ims-options-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 09:28:16 -0000 In section 3 and 4, there is text saying: ---------------------------------------------------------------------- ... Length (2 octets) Length of the value field in octets. In this case, its 4. ... Length (2 octets) Length of the value field in octets. In this case, its 16. ... ---------------------------------------------------------------------- But the length of the configuration attribute value can also be 0 for the requests. At least in general case, I do not know whether this P-CSCF_IP{4,6}_ADDRESS option is supposed to be normal configurable option or something else. In normal case the client either sends empty request, and server fills the value in, or the client sends request telling the preferred value, and server either replies with that or something else. The draft also says: ---------------------------------------------------------------------- Multiple instances of this Attribute with different values can be present in the configuration payload and there is no implied preferrential order. ---------------------------------------------------------------------- In RFC5996 we have text which says that for INTERNAL_IP{4,6}_ADDRESS the multi-valued return values only work in a way, that client sends as many entries in the request as it is willing to get back in the reply, and server can only return as many (or fewer) items there was in the request. This is to allow client to decide whether it wants to support multi-valued addresses. Do you want to do similar thing here, or is it assumed that all implementations do allow multiple values for this attribute? The text from RFC5996 says as follows: ---------------------------------------------------------------------- o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the internal network, sometimes called a red node address or private address, and it MAY be a private address on the Internet. In a request message, the address specified is a requested address (or a zero-length address if no specific address is requested). If a specific address is requested, it likely indicates that a previous connection existed with this address and the requestor would like to reuse that address. With IPv6, a requestor MAY supply the low- order address octets it wants to use. Multiple internal addresses MAY be requested by requesting multiple internal address attributes. The responder MAY only send up to the number of addresses requested. ---------------------------------------------------------------------- This also points out how the request can either be empty or have some previously used value in. Do you want to do similar thing here? Also in section 5 Example Scenario, it would be nice to have values filled in to the P-CSCF_IP{4,6}_ADDRESS attributes, just like you have values filled to other attributes (INTERNAL_IP4_ADDRESS and INTERNAL_IP4_DNS). I.e. the request is most likely empty and reply contains something. ---------------------------------------------------------------------- Client Gateway -------- --------- HDR(IKE_SA_INIT), SAi1, KEi, Ni --> <-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ] HDR(IKE_AUTH), SK { IDi, CERT, [CERTREQ], AUTH, [IDr], CP(CFG_REQUEST) = { INTERNAL_IP4_ADDRESS(), INTERNAL_IP4_DNS(), P-CSCF_IP4_ADDRESS, P-CSCF_IP6_ADDRESS }, SAi2, TSi = (0, 0-65535, 0.0.0.0-255.255.255.255), TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } --> <-- HDR(IKE_AUTH), SK { IDr, CERT, AUTH, CP(CFG_REPLY) = { INTERNAL_IP4_ADDRESS(192.0.2.234), P-CSCF_IP4_ADDRESS, P-CSCF_IP6_ADDRESS, INTERNAL_IP4_DNS(198.51.100.33) }, SAr2, TSi = (0, 0-65535, 192.0.2.234-192.0.2.234), TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } Figure 4: P-CSCF Attribute Exchange -- kivinen@iki.fi From kivinen@iki.fi Thu Apr 18 04:00:25 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7111E21F8A7B for ; Thu, 18 Apr 2013 04:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3ZNrGAu3eP7 for ; Thu, 18 Apr 2013 04:00:24 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D36521F89B2 for ; Thu, 18 Apr 2013 04:00:23 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3IAvou0014413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Apr 2013 13:57:50 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3IAvolW021908; Thu, 18 Apr 2013 13:57:50 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20847.53678.49713.19290@fireball.kivinen.iki.fi> Date: Thu, 18 Apr 2013 13:57:50 +0300 From: Tero Kivinen To: mglt.ietf@gmail.com, k.pentikousis@huawei.com X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 23 min X-Total-Time: 90 min Cc: ipsec@ietf.org Subject: [IPsec] Some comments to the draft-mglt-ipsecme-security-gateway-discovery-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 11:00:25 -0000 In section 4.1 Multiple Interfaces you say: ---------------------------------------------------------------------- Distributed VPN infrastructures are composed of multiple, independent Security Gateways. Currently, IPsec [RFC4301] does not have the mechanisms that enable "moving" a VPN connection from one Security Gateway to another Security Gateway. In practice, this means that ---------------------------------------------------------------------- There is Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) RFC5685, which is standard track document allow redirecting the IKEv2 SA to another gateway. This can used when initially creating the tunnel, but it can also be used in the middle of the session, i.e. gateway can request client to move to another gateway. How is this draft working together with REDIRECT RFC? In section 5 this document seems to be using Notify payloads to do request reply protocol. I think configuration payloads might be better suited for this kind of request reply protocol. In section 5.1 the draft says: ---------------------------------------------------------------------- 5.1. Sending a NEIGHBOR_INFORMATION Query The initiator builds the NEIGHBOR_INFORMATION Notify Payload (described in Section 6.1) by setting the Question bit to 1 and providing the necessary Options. Notify Payloads have a Critical bit set. ---------------------------------------------------------------------- The RFC5996 says: ---------------------------------------------------------------------- 2.5. Version Numbers and Forward Compatibility ... Note that the critical flag applies only to the payload type, not the contents. If the payload type is recognized, but the payload contains something that is not (such as an unknown transform inside an SA payload, or an unknown Notify Message Type inside a Notify payload), the critical flag is ignored. ... 3.2. Generic Payload Header ... o Critical (1 bit) - MUST be set to zero if the sender wants the recipient to skip this payload if it does not understand the payload type code in the Next Payload field of the previous payload. MUST be set to one if the sender wants the recipient to reject this entire message if it does not understand the payload type. MUST be ignored by the recipient if the recipient understands the payload type code. MUST be set to zero for payload types defined in this document. Note that the critical bit applies to the current payload rather than the "next" payload whose type code appears in the first octet. The reasoning behind not setting the critical bit for payloads defined in this document is that all implementations MUST understand all payload types defined in this document and therefore must ignore the critical bit's value. Skipped payloads are expected to have valid Next Payload and Payload Length fields. See Section 2.5 for more information on this bit. ---------------------------------------------------------------------- I.e. it says that Notify payloads MUST have critical bit set to zero, as it is payload that is defined in the RFC5996, and as implementations will support Notify payloads, none of them will ever return UNSUPPORTED_CRITICAL_PAYLOAD error. The Critical bit only applies to the payload type, not contents. So the text in section 5.2 is incorrect: ---------------------------------------------------------------------- Once a NEIGHBOR_INFORMATION Notify Payload is received, the responder checks whether the Critical bit is set to 1. If the Critical Bit is set and the Notify Payload is not supported by the responder then, following [RFC5996] section 2.5, setting the Critical bit to one forces the Responder to send back a UNSUPPORTED_CRITICAL_PAYLOAD Notify Payload if it does not understand the received Notify Payload. ---------------------------------------------------------------------- As implementations do support Notify payloads, they will not return UNSUPPORTED_CRITICAL_PAYLOAD, even when they might not support NEIGHBOR_INFORMATION notify payload type. As the Notify Payload is specified in the RFC5996, all implementations will support it. Some minimal implementations might simply ignore them, if they do not support any of the features provided by the contents of the Notify Payload, but they do know how to ignore it. Also in same section: ---------------------------------------------------------------------- If no corresponding query has been sent previously an INVALID_SYNTAX MUST be sent back and the rest of the Notify Payload MUST be ignored. Conversely, if a query has been sent, the receiver will process the response as per Section 5.2.2. ---------------------------------------------------------------------- If the peer sends INVALID_SYNTAX notification back, that will cause the whole IKE SA to be deleted without separate delete notification. I do not assume this what is wanted here. Most likely it would be better to simply ignore unsocilicated message, than to tear down the whole IKE SA. The RFC5996 the INVALID_SYNTAX is defined as follows: ---------------------------------------------------------------------- 2.21.3. Error Handling after IKE SA is Authenticated ... If a peer parsing a request notices that it is badly formatted (after it has passed the message authentication code checks and window checks) and it returns an INVALID_SYNTAX notification, then this error notification is considered fatal in both peers, meaning that the IKE SA is deleted without needing an explicit Delete payload. ---------------------------------------------------------------------- In section 6.4.1 there is Padding payload defined: ---------------------------------------------------------------------- 6.4.1. Padding Payload: PADDING The Padding Payload is used to make the NEIGHBOR_INFORMATION Notify Payload length a multiple of 32 bits. ---------------------------------------------------------------------- Why is this needed? There is nothing in the IKEv2 that requires anything to be padded to specific length. This also opens one more side channel, to send information out as the "padding octects are for padding and MUST NOT be interpreted". -- kivinen@iki.fi From kivinen@iki.fi Thu Apr 18 04:09:14 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2530621F8EBF for ; Thu, 18 Apr 2013 04:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5RHhX8mwMxc for ; Thu, 18 Apr 2013 04:09:13 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F7E21F8EAD for ; Thu, 18 Apr 2013 04:09:13 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3IB7tw5003669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Apr 2013 14:07:55 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3IB7s0Z009000; Thu, 18 Apr 2013 14:07:54 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20847.54282.823646.681134@fireball.kivinen.iki.fi> Date: Thu, 18 Apr 2013 14:07:54 +0300 From: Tero Kivinen To: svan@elvis.ru X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 9 min Cc: ipsec@ietf.org Subject: [IPsec] Some comments to the draft-smyslov-ipsecme-ikev2-fragmentation-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 11:09:14 -0000 In picture in the "2.5. Fragmenting Message" there is field called "Next Payload", but the description says "Next Fragment": ---------------------------------------------------------------------- 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... o Next Fragment (1 octet) - in the very first fragment MUST be set to Payload Type of the first inner Payload (as in Encrypted Payload). In the rest fragments MUST be set to zero. ---------------------------------------------------------------------- In section 2.5.1 draft says: ---------------------------------------------------------------------- Using 576 bytes is a compromise - the value is large enough for the presented solution and small enough to avoid IP fragmentation in most situations. Sender MAY use other values if they are appropriate. ---------------------------------------------------------------------- I think you might also point out that other protocols also assume that same value, i.e. I think DNS packets sent over UDP also assume that same limit, and if that long IP packets do not work, then the network does not work for any real uses... -- kivinen@iki.fi From kivinen@iki.fi Fri Apr 19 05:10:08 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59D521F8F67 for ; Fri, 19 Apr 2013 05:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbb3Q+orBd93 for ; Fri, 19 Apr 2013 05:10:08 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5EC21F8F63 for ; Fri, 19 Apr 2013 05:10:07 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3JC8k47023369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Apr 2013 15:08:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3JC8jkq019013; Fri, 19 Apr 2013 15:08:45 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20849.13261.464684.303138@fireball.kivinen.iki.fi> Date: Fri, 19 Apr 2013 15:08:45 +0300 From: Tero Kivinen To: Stephen Hanna In-Reply-To: References: <20130409025346.7391.95143.idtracker@ietfa.amsl.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 9 min Cc: "ipsec@ietf.org" Subject: [IPsec] Please Review Changes to AD VPN Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 12:10:09 -0000 Stephen Hanna writes: > I have posted a new version of the AD VPN Problem > Statement that adds clarifying text to requirements > 6 and 7, as suggested by Tero. Please review and > comment. Is everyone (especially Tero) OK with the > new text? Those requirement 6 and 7 seems to be ok, but I am still bit concerned about the requirement 5. It seems to be bit too strict, and will forbid all kind of trusted 3rd party where the trusted 3rd party is any of the ADVPN peers. This of course rules out that temporary credentials cannot be any kind of shared secrets given out by the spoke, but it also forbids the spoke to act as introductioner and sending for example the hash of the end-points public key to the other end-point, and saying this public key hash matches that peer. The requirement 5 is: ---------------------------------------------------------------------- 5. One ADVPN peer MUST NOT be able to impersonate another ADVPN peer. This requirement is driven by use case 2.1. ADVPN peers (especially spokes) become compromised fairly often. The compromise of one ADVPN peer SHOULD NOT affect the security of other peers. ---------------------------------------------------------------------- If endpoint receives any kind of intrduction, or credential information from any other node from the ADVPN, that means that the node giving that information out can impersonate that other ADVPN peer. I.e. if endpoint A asks from spoke or hub S how endpoint B is authenticated, and where it is located, so it can take direct connection to it, the compromised spoke or hub S can provide incorrect credentials for the endpoint A claiming endpoint A's public key is Sp instead Bp, and do the same for endpoint B. It can also claim that endpoint B is located in his ownIP-address, so when endpoint A tries to move to point-to-point communication mode, it actually still goes through the S, as S can impersonate to be the other end. If the requirement 5 stays as it is, the only way I can think how authentication can be done is by using some other 3rd party which is not ADVPN peer. I think what is tried to be said here, is that any of the ADVPN peers MUST NOT have a way to get the long term authentication credentials for any othe ADVPN peers. The ADVPN peer giving out some kind of temporary authentication credentials, or providing information to other ADVPN peers how to authenticate some other ADVPN peer can still give out false information and cause possibility for ADVPN peer to impersonate some other ADVPN peer. -- kivinen@iki.fi From shanna@juniper.net Fri Apr 19 15:06:40 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BE621F95E1 for ; Fri, 19 Apr 2013 15:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3xbWKSHNmmv for ; Fri, 19 Apr 2013 15:06:40 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 224EE21F92CD for ; Fri, 19 Apr 2013 15:06:40 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUXG/79kKTwkzmdTvHlQta0axpnppk0ac@postini.com; Fri, 19 Apr 2013 15:06:40 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 19 Apr 2013 15:05:57 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 19 Apr 2013 15:05:57 -0700 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.206) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 19 Apr 2013 15:15:47 -0700 Received: from mail22-am1-R.bigfish.com (10.3.201.238) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 19 Apr 2013 22:05:55 +0000 Received: from mail22-am1 (localhost [127.0.0.1]) by mail22-am1-R.bigfish.com (Postfix) with ESMTP id F24CD1E0375 for ; Fri, 19 Apr 2013 22:05:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -2 X-BigFish: PS-2(zz1418I4015Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail22-am1 (localhost.localdomain [127.0.0.1]) by mail22-am1 (MessageSwitch) id 1366409153175447_12436; Fri, 19 Apr 2013 22:05:53 +0000 (UTC) Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.247]) by mail22-am1.bigfish.com (Postfix) with ESMTP id 285C3260052; Fri, 19 Apr 2013 22:05:53 +0000 (UTC) Received: from SN2PRD0510HT003.namprd05.prod.outlook.com (157.56.234.117) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 19 Apr 2013 22:05:53 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.65]) by SN2PRD0510HT003.namprd05.prod.outlook.com ([10.255.116.38]) with mapi id 14.16.0293.003; Fri, 19 Apr 2013 22:05:48 +0000 From: Stephen Hanna To: Tero Kivinen Thread-Topic: [IPsec] Please Review Changes to AD VPN Problem Statement Thread-Index: AQHONM5h3QJpx/aEQU6tLeXKyVrNLZjdg6uAgACiA9A= Date: Fri, 19 Apr 2013 22:05:47 +0000 Message-ID: References: <20130409025346.7391.95143.idtracker@ietfa.amsl.com> <20849.13261.464684.303138@fireball.kivinen.iki.fi> In-Reply-To: <20849.13261.464684.303138@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IKI.FI$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Please Review Changes to AD VPN Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 22:06:40 -0000 Tero, I agree with you that requirement 5 as currently worded is too strict. We don't want to end up with a situation where no ADVPN peers can participate in the establishment of the ADVPN! On the other hand, we want to limit the effects of the compromise of an endpoint because endpoint compromise (not gateway compromise) is a common occurrence. A compromised endpoint shouldn't be able to impersonate other peers. You proposed this text: > Any of the ADVPN peers MUST NOT have a way to get the long > term authentication credentials for any other ADVPN peers. I think that's correct. But I also think we want to say: > The compromise of an Endpoint MUST NOT affect the security > of communications between other Peers. Are you OK with replacing the current text for requirement 5 with those two sentences? I think that will preserve the essence of the requirement without making it too strict. Thanks, Steve From paul.hoffman@vpnc.org Fri Apr 19 16:25:35 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA59621F8FE5; Fri, 19 Apr 2013 16:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+pXa0g7qKHZ; Fri, 19 Apr 2013 16:25:35 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7C49121F8F69; Fri, 19 Apr 2013 16:25:35 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3JNPUkS040606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Apr 2013 16:25:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Apr 2013 16:25:30 -0700 Message-Id: To: iesg-secretary@ietf.org, Sean Turner Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Cc: IPsecme WG Subject: [IPsec] Please publish: draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 23:25:36 -0000 Document write-up for draft-ietf-ipsecme-ad-vpn-problem-05 1. Summary This is a document writeup for draft-ietf-ipsecme-ad-vpn-problem-05, = prepared by Paul Hoffman for Sean Turner. The document lists the requirements and likely use cases for = auto-discovery IPsec VPNs. These VPNs automate configuration when a very = large number of hosts and networks must communicate over IPsec in = environments where static configuration is not appropriate. There are = already a number of proprietary solutions to this problem, and this = document is meant as a precursor to the IETF possibly working on a = standardized interoperable solution. This document is appropriate for Informational because it lists = requirements and scenarios, not a protocol. 2. Review and Consensus The document was reviewed by many people in the WG over many months and = there is strong consensus to publish. There is one possible open issue = from one WG participant, but that can be dealt with during IETF review. 3. Intellectual Property Both authors have stated that their direct, personal knowledge of any = IPR related to this document has already been disclosed, in conformance = with BCPs 78 and 79. There was no WG discussion about any IPR = disclosures regarding this document. --Paul Hoffman= From internet-drafts@ietf.org Sat Apr 20 01:28:18 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF25021F9012; Sat, 20 Apr 2013 01:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.323 X-Spam-Level: X-Spam-Status: No, score=-102.323 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjCnmxAaltkz; Sat, 20 Apr 2013 01:28:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD8921F8D70; Sat, 20 Apr 2013 01:28:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p3 Message-ID: <20130420082818.24022.35136.idtracker@ietfa.amsl.com> Date: Sat, 20 Apr 2013 01:28:18 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 08:28:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Additional Diffie-Hellman Tests for IKEv2 Author(s) : Yaron Sheffer Scott Fluhrer Filename : draft-ietf-ipsecme-dh-checks-02.txt Pages : 10 Date : 2013-04-20 Abstract: This document adds a small number of mandatory tests required for the secure operation of IKEv2 with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called DSA groups. This document updates the IKEv2 protocol, RFC 5996. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-dh-checks-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paul.hoffman@vpnc.org Sat Apr 20 07:41:55 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B20A21F8E36 for ; Sat, 20 Apr 2013 07:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9TCgbozotxX for ; Sat, 20 Apr 2013 07:41:55 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD2121F85CC for ; Sat, 20 Apr 2013 07:41:55 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3KEfrcW063701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 20 Apr 2013 07:41:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <14A2C604-CDB7-4A37-A07F-627D8BFF85D0@vpnc.org> Date: Sat, 20 Apr 2013 07:41:56 -0700 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [IPsec] New WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 14:41:55 -0000 Greetings again. The authors of the DH checks draft have submitted a = significantly-revised draft based on the input of the WG Last Call. See = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-dh-checks-02 for = the difference. Based on the amount of new material, I want to have another (albeit = shorter) WG Last Call for this new version of the draft. Please send = comments to the WG by Monday, April 29. Note that if you did not = participate in the earlier WG Last Call, you are strongly urged to do so = now: the more review we get for our WG drafts, the better. Having said = that, it would be useful to hear from those who commented in the first = WG Last Call to say whether the changes are sufficient. --Paul Hoffman= From mcr@sandelman.ca Sun Apr 21 13:14:32 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B1B21F937D for ; Sun, 21 Apr 2013 13:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mslI71qNlxkv for ; Sun, 21 Apr 2013 13:14:31 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 2934321F9305 for ; Sun, 21 Apr 2013 13:14:31 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9161720168 for ; Sun, 21 Apr 2013 16:24:42 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 98AA263A58; Sun, 21 Apr 2013 16:13:57 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7F5AE63A57 for ; Sun, 21 Apr 2013 16:13:57 -0400 (EDT) From: Michael Richardson To: IPsecme WG In-Reply-To: <14A2C604-CDB7-4A37-A07F-627D8BFF85D0@vpnc.org> References: <14A2C604-CDB7-4A37-A07F-627D8BFF85D0@vpnc.org> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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 Subject: Re: [IPsec] New WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 20:14:32 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Paul" =3D=3D Paul Hoffman writes: Paul> Greetings again. The authors of the DH checks draft have Paul> submitted a significantly-revised draft based on the input of Paul> the WG Last Call. See Paul> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-dh-checks-02 Paul> for the difference. I don't see my suggested text for section 2.2, or any change to the text. At this point, I understand what section 2.2 is trying to say sufficiently well that I can't really tell if the existing text is clear enough for me. Paul> Based on the amount of new material, I want to have another Paul> (albeit shorter) WG Last Call for this new version of the Paul> draft. Please send comments to the WG by Monday, April The additional material seems clear enough to me. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUXRIhYqHRg3pndX9AQI/dQQAzPzRS7xp4VRTDOYGZZionFTHGIXH8jXI 3d/8HQAPRb4925ILN0woHnlFfTwrybznxY1rMxDk2dFTpgRA4JrX9/W2CBDncdab nvfSs+oqsmR44Kf2kZmKea4cN44kIXgDHjMmbefOItoR7Zr4ZZaGB9Za9tX4rqtT DLb/Yb8sNFo= =jZ2M -----END PGP SIGNATURE----- --=-=-=-- From sgundave@cisco.com Sun Apr 21 13:48:08 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB64121F93D7 for ; Sun, 21 Apr 2013 13:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00PCYlv1ntGS for ; Sun, 21 Apr 2013 13:48:07 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 524B421F93D6 for ; Sun, 21 Apr 2013 13:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6007; q=dns/txt; s=iport; t=1366577287; x=1367786887; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jvcnFsPpZqvL4LkRdvhUj2J/7mBFZQhmQC0vb0DyVQA=; b=mKe3JaImkFQngjgfSq1kHqQwrK4MgUIwBR/rtgMluA/xTSE6znhzfNci 9o8Aad/PHF2u+K+SYdKVCghc/AJ5hhX6e+FiXpsWGkfvmtUy1PV18enhf iFFgpuJMNn261L2xHNqypgABj4bchpwUqNR+snd7GZZPvxT0D/DGP6oc8 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACVPdFGtJXG8/2dsb2JhbABPgwbBOYEBFnSCIQEEJxM/EgEIIhRCJQIEAQ0FCIgMunePDjEHgmZhA5NGlGmDDIIo X-IronPort-AV: E=Sophos;i="4.87,520,1363132800"; d="scan'208";a="201267899" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 21 Apr 2013 20:48:07 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3LKm6c6004797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 21 Apr 2013 20:48:06 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.159]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Sun, 21 Apr 2013 15:48:06 -0500 From: "Sri Gundavelli (sgundave)" To: Tero Kivinen , "Aeneas Dodd-Noble (noblea)" , "jouni.nospam@gmail.com" , "baboescu@broadcom.com" Thread-Topic: Some comments to the draft-gundavelli-ipsecme-3gpp-ims-options-00.txt Thread-Index: AQHOPBbfkK3N7LSI7ECyznXpomQb85jhCVaA Date: Sun, 21 Apr 2013 20:48:06 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA81024577A@xmb-aln-x03.cisco.com> In-Reply-To: <20847.48212.437658.582136@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.211] Content-Type: text/plain; charset="us-ascii" Content-ID: <1E2EE21E54FE5D4BB1156AF7E9615A68@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Some comments to the draft-gundavelli-ipsecme-3gpp-ims-options-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 20:48:08 -0000 Hi Tero, Thanks a lot for the review comments. This is very helpful. Please see inline. On 4/18/13 2:26 AM, "Tero Kivinen" wrote: >In section 3 and 4, there is text saying: > >---------------------------------------------------------------------- >... > Length (2 octets) > Length of the value field in octets. In this case, its 4. >... > Length (2 octets) > Length of the value field in octets. In this case, its 16. >... >---------------------------------------------------------------------- > >But the length of the configuration attribute value can also be 0 for >the requests. At least in general case, I do not know whether this >P-CSCF_IP{4,6}_ADDRESS option is supposed to be normal configurable >option or something else. In normal case the client either sends empty >request, and server fills the value in, or the client sends request >telling the preferred value, and server either replies with that or >something else. The goal is to allow the client to request for the configuration value, so the server can populate it. So, the client sends a request with a NULL/0.0.0.0 value, and the server can include the Attribute with a proper value in the response message. > >The draft also says: > >---------------------------------------------------------------------- > Multiple instances of this Attribute with different values can be > present in the configuration payload and there is no implied > preferrential order. >---------------------------------------------------------------------- > >In RFC5996 we have text which says that for INTERNAL_IP{4,6}_ADDRESS >the multi-valued return values only work in a way, that client sends >as many entries in the request as it is willing to get back in the >reply, and server can only return as many (or fewer) items there was >in the request. This is to allow client to decide whether it wants to >support multi-valued addresses. Do you want to do similar thing here, >or is it assumed that all implementations do allow multiple values for >this attribute? The text from RFC5996 says as follows: The client should be able to include a single a instance of the Attribute with a value of 0.0.0.0, but the server should be able to offer one or more instances of the Attribute. In this case, there is no real requirement for the client to indicate capability for multiple instances. We can safely assume the client can handle one or more values. We did have some discussion on if there is an implied order when multiple instances of the Attribute or present. In the context of 3GPP interface where it will be used, the server obtains these Attribute values from the PGW over S2b interface and there is no such order on that interface. So, we will not indicate any order, its up to the client on how it decides to use those values. > >---------------------------------------------------------------------- > o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the > internal network, sometimes called a red node address or private > address, and it MAY be a private address on the Internet. In a > request message, the address specified is a requested address (or > a zero-length address if no specific address is requested). If a > specific address is requested, it likely indicates that a previous > connection existed with this address and the requestor would like > to reuse that address. With IPv6, a requestor MAY supply the low- > order address octets it wants to use. Multiple internal addresses > MAY be requested by requesting multiple internal address > attributes. The responder MAY only send up to the number of > addresses requested. >---------------------------------------------------------------------- > >This also points out how the request can either be empty or have some >previously used value in. Do you want to do similar thing here? The request should be empty. I don't believe ePDG is sending specific hints over S2b interface and so we are bound by that interface definition. I will check the spec to be sure. > >Also in section 5 Example Scenario, it would be nice to have values >filled in to the P-CSCF_IP{4,6}_ADDRESS attributes, just like you have >values filled to other attributes (INTERNAL_IP4_ADDRESS and >INTERNAL_IP4_DNS). I.e. the request is most likely empty and reply >contains something. Sure. Will address these comments. These are very good comment. Very helpful. Appreciate it. Regards Sri > >---------------------------------------------------------------------- > Client Gateway > -------- --------- > > HDR(IKE_SA_INIT), SAi1, KEi, Ni --> > > <-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ] > > HDR(IKE_AUTH), > SK { IDi, CERT, [CERTREQ], AUTH, [IDr], > CP(CFG_REQUEST) =3D > { INTERNAL_IP4_ADDRESS(), > INTERNAL_IP4_DNS(), > P-CSCF_IP4_ADDRESS, > P-CSCF_IP6_ADDRESS }, SAi2, > TSi =3D (0, 0-65535, 0.0.0.0-255.255.255.255), > TSr =3D (0, 0-65535, 0.0.0.0-255.255.255.255) } --> > > <-- HDR(IKE_AUTH), > SK { IDr, CERT, AUTH, > CP(CFG_REPLY) =3D > { INTERNAL_IP4_ADDRESS(192.0.2.234), > P-CSCF_IP4_ADDRESS, > P-CSCF_IP6_ADDRESS, > INTERNAL_IP4_DNS(198.51.100.33) }, > SAr2, > TSi =3D (0, 0-65535, 192.0.2.234-192.0.2.234), > TSr =3D (0, 0-65535, 0.0.0.0-255.255.255.255) } > > > Figure 4: P-CSCF Attribute Exchange >-- >kivinen@iki.fi From yaronf.ietf@gmail.com Mon Apr 22 00:29:09 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A68221F8517 for ; Mon, 22 Apr 2013 00:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.846 X-Spam-Level: X-Spam-Status: No, score=-100.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJSrGhgiR5zJ for ; Mon, 22 Apr 2013 00:29:07 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1196221F8481 for ; Mon, 22 Apr 2013 00:29:04 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id i48so5957608wef.30 for ; Mon, 22 Apr 2013 00:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ewY06ivLwb/o4OqWSHY+88MJLwyLLKzEuuHA3Z2fe3I=; b=timJw8AINjvt1l1kMm+yEhJ1+PkQKLa1jTC8fwD7GYvipewQHS5FXNR50hRlnbvp/q 7DQ9Oe01vcFZ8TB81cUZi1HeGhbLQvrIgwmWpMGPIiZ6U15nq5wa7dLGBMNruBc/qbr7 pNe8XkP0cDPILWJm/rJPNt4GW5/njxRrBOrFtKxYqlHSFWJzzolGVhmkml14zAMzQPLq 7TqqrD9a4hEL6gUfrwMk54803Qyr8lxDn6NoSjJC6QmaeTSEhS9MzWicAjoVjnGL77rv IN9y/TWcnxq5FOb/eC4eHqWmIM2HDlT8utjeFIGOsI5f+jR1c5/QCEsppDRvdEJmb6tb z6iw== X-Received: by 10.180.20.37 with SMTP id k5mr11128567wie.27.1366615744130; Mon, 22 Apr 2013 00:29:04 -0700 (PDT) Received: from [10.0.0.14] (109-186-115-180.bb.netvision.net.il. [109.186.115.180]) by mx.google.com with ESMTPS id ch6sm38680393eeb.17.2013.04.22.00.29.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Apr 2013 00:29:03 -0700 (PDT) Message-ID: <5174E6BD.7030200@gmail.com> Date: Mon, 22 Apr 2013 10:29:01 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Paul Hoffman , IPsecme WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] STRONG NUDGE: WG Last Call on draft-ietf-ipsecme-oob-pubkey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 07:29:09 -0000 We have still not heard any additional responses for this last call. If you think this draft is useful, please say so on the list. If you think it needs to be fixed, please send your comments. We are extending this LC until Friday of this week. Thanks, Yaron On 2013-04-17 18:18, Paul Hoffman wrote: > We have gotten exactly one response to this, even though there were lots of people who said they thought this was a valuable addition to IKEv2. Please comment before Monday so we don't have to abandon the work. > > --Paul Hoffman > > On Apr 8, 2013, at 2:43 PM, Paul Hoffman wrote: > >> Greetings again. This begins the WG Last Call on draft-ietf-ipsecme-oob-pubkey, "More Raw Public Keys for IKEv2". You can find the current draft at http://tools.ietf.org/html/draft-ietf-ipsecme-oob-pubkey >> >> This document generated a fair amount of interest early, but we have not had much discussion since. Yaron and I would *really* like to have at least five WG members review the document and say on the list whether or not they think it is ready in its current state to move to IETF review. If you read it and feel it is not ready for any reason, please also say that in your message to the list. >> >> Again, participating in WG Last Calls is a great opportunity for those who are less active in the WG but who want to contribute to the IETF to make a difference. >> >> The WG Last Call should end in two weeks, on April 22. Please review the document before then. Thanks in advance! > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From Johannes.Merkle@secunet.com Mon Apr 22 04:58:35 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BDC21F8A53 for ; Mon, 22 Apr 2013 04:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGHxMmfYNPkn for ; Mon, 22 Apr 2013 04:58:35 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3C621F88A9 for ; Mon, 22 Apr 2013 04:58:34 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id DB66A1A00A0; Mon, 22 Apr 2013 13:58:32 +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 G5s8ULkwwg8W; Mon, 22 Apr 2013 13:58:31 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id C4C281A007A; Mon, 22 Apr 2013 13:58:31 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Apr 2013 13:58:31 +0200 Message-ID: <517525E6.1080500@secunet.com> Date: Mon, 22 Apr 2013 13:58:30 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: draft-ietf-ipsecme-dh-checks@tools.ietf.org References: <14A2C604-CDB7-4A37-A07F-627D8BFF85D0@vpnc.org> In-Reply-To: <14A2C604-CDB7-4A37-A07F-627D8BFF85D0@vpnc.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2013 11:58:31.0799 (UTC) FILETIME=[B5A8B870:01CE3F50] Cc: ipsec@ietf.org, "Turner, Sean P." , Dan Harkins Subject: Re: [IPsec] New WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 11:58:35 -0000 > Based on the amount of new material, I want to have another (albeit shorter) WG Last Call for this new version of the draft. Please send comments to the WG by Monday, April 29. Note that if you did not participate in the earlier WG Last Call, you are strongly urged to do so now: the more review we get for our WG drafts, the better. Having said that, it would be useful to hear from those who commented in the first WG Last Call to say whether the changes are sufficient. > Please include draft-merkle-ikev2-ke-brainpool as informative reference and include in Section 2.3 a reference to it. Our draft defines new elliptic curves for IKEv2 for which the checks specified in Section 2.3 are applicable and is about to be published as RFC (RFC Ed Queue). This means that our draft will update the registry before your draft does. Otherwise, our draft would have to wait for your draft to be published which would introduce a considerable delay. For this reason, IANA has requested from us to resolve the current deadlock. -- Johannes From kivinen@iki.fi Mon Apr 22 05:08:52 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0476D21F902A for ; Mon, 22 Apr 2013 05:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bY-aTXlcKYvi for ; Mon, 22 Apr 2013 05:08:51 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC5D21F9029 for ; Mon, 22 Apr 2013 05:08:50 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3MC8iS1023679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Apr 2013 15:08:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3MC8hT6019004; Mon, 22 Apr 2013 15:08:43 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20853.10315.629195.503822@fireball.kivinen.iki.fi> Date: Mon, 22 Apr 2013 15:08:43 +0300 From: Tero Kivinen To: Stephen Hanna In-Reply-To: References: <20130409025346.7391.95143.idtracker@ietfa.amsl.com> <20849.13261.464684.303138@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 11 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Please Review Changes to AD VPN Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 12:08:52 -0000 Stephen Hanna writes: > I agree with you that requirement 5 as currently worded > is too strict. We don't want to end up with a situation > where no ADVPN peers can participate in the establishment > of the ADVPN! On the other hand, we want to limit the > effects of the compromise of an endpoint because endpoint > compromise (not gateway compromise) is a common occurrence. > A compromised endpoint shouldn't be able to impersonate > other peers. I agree. > You proposed this text: > > > Any of the ADVPN peers MUST NOT have a way to get the long > > term authentication credentials for any other ADVPN peers. > > I think that's correct. But I also think we want to say: > > > The compromise of an Endpoint MUST NOT affect the security > > of communications between other Peers. ^^^^^ => ADVPN Peers > Are you OK with replacing the current text for requirement 5 > with those two sentences? I think that will preserve the > essence of the requirement without making it too strict. I am ok with those two sentences. Note, that Endpoint does not include gateways, so the second sentence does not cover the compromize of the Spokes. I would even add text saying that "The compromize of an Gateway SHOULD NOT affect the security of the communications between ADVPN Peers not associated with that Gateway". That last one cannot easily be MUST NOT, as compromised gateway might be able to do all kind of tricks to affect the security of other ADVPN Peers, for example it can try to get the other ADVPN Peers to change their current Gateway to himself and then it will be able to comprimise them. Some of those we can protect, but plugging all possible holes might end up very hard. For example it might be impossible to make so that the ADVPN Peer who has been out of network for a while, will not connect back to that compromized Gateway... -- kivinen@iki.fi From kivinen@iki.fi Mon Apr 22 05:15:39 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA09F21F8F53 for ; Mon, 22 Apr 2013 05:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uivry3vNOMoV for ; Mon, 22 Apr 2013 05:15:38 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id E50F421F8F38 for ; Mon, 22 Apr 2013 05:15:37 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3MCFa67023498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Apr 2013 15:15:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3MCFZLr007964; Mon, 22 Apr 2013 15:15:35 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20853.10727.843185.874248@fireball.kivinen.iki.fi> Date: Mon, 22 Apr 2013 15:15:35 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: <14A2C604-CDB7-4A37-A07F-627D8BFF85D0@vpnc.org> References: <14A2C604-CDB7-4A37-A07F-627D8BFF85D0@vpnc.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: IPsecme WG Subject: [IPsec] New WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 12:15:39 -0000 Paul Hoffman writes: > Based on the amount of new material, I want to have another (albeit > shorter) WG Last Call for this new version of the draft. Please send > comments to the WG by Monday, April 29. Note that if you did not > participate in the earlier WG Last Call, you are strongly urged to > do so now: the more review we get for our WG drafts, the better. > Having said that, it would be useful to hear from those who > commented in the first WG Last Call to say whether the changes are > sufficient. Seems good for me. -- kivinen@iki.fi From kivinen@iki.fi Mon Apr 22 05:30:10 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F3C21E8053 for ; Mon, 22 Apr 2013 05:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16ybZznDcoBm for ; Mon, 22 Apr 2013 05:30:10 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE6C21E8051 for ; Mon, 22 Apr 2013 05:30:09 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3MCTuaL002160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Apr 2013 15:29:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3MCTuZN024319; Mon, 22 Apr 2013 15:29:56 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20853.11588.93501.817653@fireball.kivinen.iki.fi> Date: Mon, 22 Apr 2013 15:29:56 +0300 From: Tero Kivinen To: "Sri Gundavelli (sgundave)" In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA810245701@xmb-aln-x03.cisco.com> References: <20847.48212.437658.582136@fireball.kivinen.iki.fi> <24C0F3E22276D9438D6F366EB89FAEA810245701@xmb-aln-x03.cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 7 min Cc: "ipsec@ietf.org" , "Aeneas Dodd-Noble \(noblea\)" , "jouni.nospam@gmail.com" , "baboescu@broadcom.com" Subject: Re: [IPsec] Some comments to the draft-gundavelli-ipsecme-3gpp-ims-options-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 12:30:10 -0000 Sri Gundavelli (sgundave) writes: > Hi Tero, > > Thanks a lot for the review comments. This is very helpful. > > Please see inline. > > > On 4/18/13 2:26 AM, "Tero Kivinen" wrote: > > >In section 3 and 4, there is text saying: > > > >---------------------------------------------------------------------- > >... > > Length (2 octets) > > Length of the value field in octets. In this case, its 4. > >... > > Length (2 octets) > > Length of the value field in octets. In this case, its 16. > >... > >---------------------------------------------------------------------- > > > >But the length of the configuration attribute value can also be 0 for > >the requests. At least in general case, I do not know whether this > >P-CSCF_IP{4,6}_ADDRESS option is supposed to be normal configurable > >option or something else. In normal case the client either sends empty > >request, and server fills the value in, or the client sends request > >telling the preferred value, and server either replies with that or > >something else. > > The goal is to allow the client to request for the configuration value, so > the server can populate it. So, the client sends a request with a > NULL/0.0.0.0 value, and the server can include the Attribute with a proper > value in the response message. In normal IKEv2 case the configuration payload in that case will be empty, see RFC5996 section 3.15.1: ---------------------------------------------------------------------- 3.15.1. Configuration Attributes ... The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request information from its peer. If an attribute in the CFG_REQUEST Configuration payload is not zero-length, it is taken as a suggestion for that attribute. The CFG_REPLY Configuration payload MAY return that value, or a new one. It MAY also add new attributes and not include some requested ones. Unrecognized or unsupported attributes MUST be ignored in both requests and responses. ... ---------------------------------------------------------------------- It would be better to use same mechanisms for all IKEv2 configuration attributes, and not make special cases for some attributes. > >The draft also says: > > > >---------------------------------------------------------------------- > > Multiple instances of this Attribute with different values can be > > present in the configuration payload and there is no implied > > preferrential order. > >---------------------------------------------------------------------- > > > >In RFC5996 we have text which says that for INTERNAL_IP{4,6}_ADDRESS > >the multi-valued return values only work in a way, that client sends > >as many entries in the request as it is willing to get back in the > >reply, and server can only return as many (or fewer) items there was > >in the request. This is to allow client to decide whether it wants to > >support multi-valued addresses. Do you want to do similar thing here, > >or is it assumed that all implementations do allow multiple values for > >this attribute? The text from RFC5996 says as follows: > > > The client should be able to include a single a instance of the Attribute > with a value of 0.0.0.0, but the server should be able to offer one or > more instances of the Attribute. > > In this case, there is no real requirement for the client to indicate > capability for multiple instances. We can safely assume the client can > handle one or more values. Ok, if client is known to be able to handle multiple values, then there is no need to indicate that by sending multiple requests. > >---------------------------------------------------------------------- > > o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the > > internal network, sometimes called a red node address or private > > address, and it MAY be a private address on the Internet. In a > > request message, the address specified is a requested address (or > > a zero-length address if no specific address is requested). If a > > specific address is requested, it likely indicates that a previous > > connection existed with this address and the requestor would like > > to reuse that address. With IPv6, a requestor MAY supply the low- > > order address octets it wants to use. Multiple internal addresses > > MAY be requested by requesting multiple internal address > > attributes. The responder MAY only send up to the number of > > addresses requested. > >---------------------------------------------------------------------- > > > >This also points out how the request can either be empty or have some > >previously used value in. Do you want to do similar thing here? > > The request should be empty. I don't believe ePDG is sending specific > hints over S2b interface and so we are bound by that interface definition. > I will check the spec to be sure. In configuration payload format the empty attribute means that the attribute length is 0, and the value is omitted, in your case the attribute length was not allowed to be 0, so the attribute cannot be empty, but I think it would be better to change it so it can have length "0 or 4 octects" and "0 or 16 octects", just like all other IKEv2 Configuration Attributes. -- kivinen@iki.fi From shanna@juniper.net Mon Apr 22 06:00:59 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F79F21F9027 for ; Mon, 22 Apr 2013 06:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40Y39N-1+rYt for ; Mon, 22 Apr 2013 06:00:58 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 7A95B21F9026 for ; Mon, 22 Apr 2013 06:00:58 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUXU0ihFfJGSBzfLESXk8t/ORLl4gh8Ga@postini.com; Mon, 22 Apr 2013 06:00:58 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 22 Apr 2013 05:57:26 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 22 Apr 2013 05:57:25 -0700 Received: from CO9EHSOBE027.bigfish.com (207.46.163.27) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 22 Apr 2013 06:00:28 -0700 Received: from mail155-co9-R.bigfish.com (10.236.132.228) by CO9EHSOBE027.bigfish.com (10.236.130.90) with Microsoft SMTP Server id 14.1.225.23; Mon, 22 Apr 2013 12:57:25 +0000 Received: from mail155-co9 (localhost [127.0.0.1]) by mail155-co9-R.bigfish.com (Postfix) with ESMTP id 1CE8D80129 for ; Mon, 22 Apr 2013 12:57:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -25 X-BigFish: PS-25(zz9371I1102I542I1432I1418Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz8275dh1033ILz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail155-co9 (localhost.localdomain [127.0.0.1]) by mail155-co9 (MessageSwitch) id 1366635443828028_17718; Mon, 22 Apr 2013 12:57:23 +0000 (UTC) Received: from CO9EHSMHS022.bigfish.com (unknown [10.236.132.240]) by mail155-co9.bigfish.com (Postfix) with ESMTP id BE0AA200149; Mon, 22 Apr 2013 12:57:23 +0000 (UTC) Received: from SN2PRD0510HT005.namprd05.prod.outlook.com (157.56.234.117) by CO9EHSMHS022.bigfish.com (10.236.130.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 22 Apr 2013 12:57:22 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.65]) by SN2PRD0510HT005.namprd05.prod.outlook.com ([10.255.116.40]) with mapi id 14.16.0299.002; Mon, 22 Apr 2013 12:57:21 +0000 From: Stephen Hanna To: Tero Kivinen Thread-Topic: [IPsec] Please Review Changes to AD VPN Problem Statement Thread-Index: AQHONM5h3QJpx/aEQU6tLeXKyVrNLZjdg6uAgACiA9CABBT5gIAACh3w Date: Mon, 22 Apr 2013 12:57:20 +0000 Message-ID: References: <20130409025346.7391.95143.idtracker@ietfa.amsl.com> <20849.13261.464684.303138@fireball.kivinen.iki.fi> <20853.10315.629195.503822@fireball.kivinen.iki.fi> In-Reply-To: <20853.10315.629195.503822@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IKI.FI$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Please Review Changes to AD VPN Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 13:00:59 -0000 Tero, Thanks for your additional suggestions. I agree with those also. I will post a revised draft shortly containing the text that we have agreed upon. Take care, Steve > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Tero Kivinen > Sent: Monday, April 22, 2013 8:09 AM > To: Stephen Hanna > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Please Review Changes to AD VPN Problem Statement >=20 > Stephen Hanna writes: > > I agree with you that requirement 5 as currently worded > > is too strict. We don't want to end up with a situation > > where no ADVPN peers can participate in the establishment > > of the ADVPN! On the other hand, we want to limit the > > effects of the compromise of an endpoint because endpoint > > compromise (not gateway compromise) is a common occurrence. > > A compromised endpoint shouldn't be able to impersonate > > other peers. >=20 > I agree. >=20 > > You proposed this text: > > > > > Any of the ADVPN peers MUST NOT have a way to get the long > > > term authentication credentials for any other ADVPN peers. > > > > I think that's correct. But I also think we want to say: > > > > > The compromise of an Endpoint MUST NOT affect the security > > > of communications between other Peers. > ^^^^^ =3D> ADVPN Peers >=20 > > Are you OK with replacing the current text for requirement 5 > > with those two sentences? I think that will preserve the > > essence of the requirement without making it too strict. >=20 > I am ok with those two sentences. Note, that Endpoint does not include > gateways, so the second sentence does not cover the compromize of the > Spokes. I would even add text saying that "The compromize of an > Gateway SHOULD NOT affect the security of the communications between > ADVPN Peers not associated with that Gateway". That last one cannot > easily be MUST NOT, as compromised gateway might be able to do all > kind of tricks to affect the security of other ADVPN Peers, for > example it can try to get the other ADVPN Peers to change their > current Gateway to himself and then it will be able to comprimise > them. Some of those we can protect, but plugging all possible holes > might end up very hard. For example it might be impossible to make so > that the ADVPN Peer who has been out of network for a while, will not > connect back to that compromized Gateway... > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From internet-drafts@ietf.org Mon Apr 22 06:03:17 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2677D21F905C; Mon, 22 Apr 2013 06:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptfv6YAkq5De; Mon, 22 Apr 2013 06:03:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A217121F8FDB; Mon, 22 Apr 2013 06:03:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p3 Message-ID: <20130422130316.2891.80974.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2013 06:03:16 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 13:03:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Auto Discovery VPN Problem Statement and Requirements Author(s) : Steve Hanna Vishwas Manral Filename : draft-ietf-ipsecme-ad-vpn-problem-06.txt Pages : 11 Date : 2013-04-22 Abstract: This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements, for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases the IP address of endpoints change or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto Discovery VPN solution will address these requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ad-vpn-problem-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sgundave@cisco.com Mon Apr 22 07:26:10 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995ED11E80A5 for ; Mon, 22 Apr 2013 07:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJYn9YaJO82P for ; Mon, 22 Apr 2013 07:26:08 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 658D311E80A2 for ; Mon, 22 Apr 2013 07:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5826; q=dns/txt; s=iport; t=1366640766; x=1367850366; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=21s82wrFapy8/Zu08C4GRuRdAaD/4cc6NSZylILFpxk=; b=HY5SwYsEECUlJJHICg4pXrFFTgEMwOeTptyNksRT1gNSOgGV+2o03lhG 0gjrI8lPXVU86fhvpweprHMHqRajXw1HHxSPe4mnT578mtTJMRFPVHs6d I2xLjBUBfRswFJMHame11AZmDkjbyU634+8/cRYhKA8iGVuYxIDXwFass g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAMFHdVGtJXG8/2dsb2JhbABPgwbBOIEGFnSCHwEBAQQ6PxIBCBgKFEIlAgQOBQiIDLsYjw4xB4JmYQOTRpRpgwyCKA X-IronPort-AV: E=Sophos;i="4.87,526,1363132800"; d="scan'208";a="201607316" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 22 Apr 2013 14:26:06 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3MEQ5p1026783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Apr 2013 14:26:05 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.159]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 09:26:05 -0500 From: "Sri Gundavelli (sgundave)" To: Tero Kivinen Thread-Topic: Some comments to the draft-gundavelli-ipsecme-3gpp-ims-options-00.txt Thread-Index: AQHOPBbfkK3N7LSI7ECyznXpomQb85jhBvIAgAF+4wD//6sXAA== Date: Mon, 22 Apr 2013 14:26:04 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA810246BB5@xmb-aln-x03.cisco.com> In-Reply-To: <20853.11588.93501.817653@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.214] Content-Type: text/plain; charset="us-ascii" Content-ID: <3AB5253AA0A0C147BCBB080411C189EA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "Aeneas Dodd-Noble \(noblea\)" , "jouni.nospam@gmail.com" , "baboescu@broadcom.com" Subject: Re: [IPsec] Some comments to the draft-gundavelli-ipsecme-3gpp-ims-options-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 14:26:10 -0000 Hi Tero, On 4/22/13 5:29 AM, "Tero Kivinen" wrote: >Sri Gundavelli (sgundave) writes: >> Hi Tero, >>=20 >> Thanks a lot for the review comments. This is very helpful. >>=20 >> Please see inline. >>=20 >>=20 >> On 4/18/13 2:26 AM, "Tero Kivinen" wrote: >>=20 >> >In section 3 and 4, there is text saying: >> > >> >---------------------------------------------------------------------- >> >... >> > Length (2 octets) >> > Length of the value field in octets. In this case, its 4. >> >... >> > Length (2 octets) >> > Length of the value field in octets. In this case, its 16. >> >... >> >---------------------------------------------------------------------- >> > >> >But the length of the configuration attribute value can also be 0 for >> >the requests. At least in general case, I do not know whether this >> >P-CSCF_IP{4,6}_ADDRESS option is supposed to be normal configurable >> >option or something else. In normal case the client either sends empty >> >request, and server fills the value in, or the client sends request >> >telling the preferred value, and server either replies with that or >> >something else. >>=20 >> The goal is to allow the client to request for the configuration value, >>so >> the server can populate it. So, the client sends a request with a >> NULL/0.0.0.0 value, and the server can include the Attribute with a >>proper >> value in the response message. > >In normal IKEv2 case the configuration payload in that case will be >empty, see RFC5996 section 3.15.1: > >---------------------------------------------------------------------- >3.15.1. Configuration Attributes >... > The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request > information from its peer. If an attribute in the CFG_REQUEST > Configuration payload is not zero-length, it is taken as a suggestion > for that attribute. The CFG_REPLY Configuration payload MAY return > that value, or a new one. It MAY also add new attributes and not > include some requested ones. Unrecognized or unsupported attributes > MUST be ignored in both requests and responses. >... >---------------------------------------------------------------------- > >It would be better to use same mechanisms for all IKEv2 configuration >attributes, and not make special cases for some attributes. OK. This is fine. I will make the change. > >> >The draft also says: >> > >> >---------------------------------------------------------------------- >> > Multiple instances of this Attribute with different values can be >> > present in the configuration payload and there is no implied >> > preferrential order. >> >---------------------------------------------------------------------- >> > >> >In RFC5996 we have text which says that for INTERNAL_IP{4,6}_ADDRESS >> >the multi-valued return values only work in a way, that client sends >> >as many entries in the request as it is willing to get back in the >> >reply, and server can only return as many (or fewer) items there was >> >in the request. This is to allow client to decide whether it wants to >> >support multi-valued addresses. Do you want to do similar thing here, >> >or is it assumed that all implementations do allow multiple values for >> >this attribute? The text from RFC5996 says as follows: >>=20 >>=20 >> The client should be able to include a single a instance of the >>Attribute >> with a value of 0.0.0.0, but the server should be able to offer one or >> more instances of the Attribute. >>=20 >> In this case, there is no real requirement for the client to indicate >> capability for multiple instances. We can safely assume the client can >> handle one or more values. > >Ok, if client is known to be able to handle multiple values, then >there is no need to indicate that by sending multiple requests. Ack. > >> >---------------------------------------------------------------------- >> > o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the >> > internal network, sometimes called a red node address or private >> > address, and it MAY be a private address on the Internet. In a >> > request message, the address specified is a requested address (or >> > a zero-length address if no specific address is requested). If a >> > specific address is requested, it likely indicates that a >>previous >> > connection existed with this address and the requestor would like >> > to reuse that address. With IPv6, a requestor MAY supply the >>low- >> > order address octets it wants to use. Multiple internal >>addresses >> > MAY be requested by requesting multiple internal address >> > attributes. The responder MAY only send up to the number of >> > addresses requested. >> >---------------------------------------------------------------------- >> > >> >This also points out how the request can either be empty or have some >> >previously used value in. Do you want to do similar thing here? >>=20 >> The request should be empty. I don't believe ePDG is sending specific >> hints over S2b interface and so we are bound by that interface >>definition. >> I will check the spec to be sure. > >In configuration payload format the empty attribute means that the >attribute length is 0, and the value is omitted, in your case the >attribute length was not allowed to be 0, so the attribute cannot be >empty, but I think it would be better to change it so it can have >length "0 or 4 octects" and "0 or 16 octects", just like all other >IKEv2 Configuration Attributes. >-- Sure. I will make the change to allow empty container. Regards Sri >=20 >kivinen@iki.fi From paul.hoffman@vpnc.org Mon Apr 22 10:16:45 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE4E21E803D for ; Mon, 22 Apr 2013 10:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmUm3GohEIjY for ; Mon, 22 Apr 2013 10:16:44 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 97E3511E80CC for ; Mon, 22 Apr 2013 10:16:44 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3MHGgRN040254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Apr 2013 10:16:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <517525E6.1080500@secunet.com> Date: Mon, 22 Apr 2013 10:16:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <00C0CD96-B069-4449-AAB6-59105CA713E9@vpnc.org> References: <14A2C604-CDB7-4A37-A07F-627D8BFF85D0@vpnc.org> <517525E6.1080500@secunet.com> To: Johannes Merkle X-Mailer: Apple Mail (2.1503) Cc: IPsecme WG Subject: Re: [IPsec] New WG Last Call for draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 17:16:45 -0000 On Apr 22, 2013, at 4:58 AM, Johannes Merkle = wrote: >=20 >> Based on the amount of new material, I want to have another (albeit = shorter) WG Last Call for this new version of the draft. Please send = comments to the WG by Monday, April 29. Note that if you did not = participate in the earlier WG Last Call, you are strongly urged to do so = now: the more review we get for our WG drafts, the better. Having said = that, it would be useful to hear from those who commented in the first = WG Last Call to say whether the changes are sufficient. >>=20 >=20 >=20 > Please include draft-merkle-ikev2-ke-brainpool as informative = reference and include in Section 2.3 a reference to it. > Our draft defines new elliptic curves for IKEv2 for which the checks = specified in Section 2.3 are applicable and is > about to be published as RFC (RFC Ed Queue). This means that our draft = will update the registry before your draft does. >=20 > Otherwise, our draft would have to wait for your draft to be published = which would introduce a considerable delay. For > this reason, IANA has requested from us to resolve the current = deadlock. I'm confused. Could you send a copy of the message from IANA asking for = you to "resolve the current deadlock"? I don't see any deadlock at all, = so this might best be done by simply telling IANA to not block yours. This is not to say that draft-ietf-ipsecme-dh-checks should not list the = eventual RFC for draft-merkle-ikev2-ke-brainpool; it should. However, us = adding that to the current draft should have no effect on IANA. As shepherd for draft-ietf-ipsecme-dh-checks, I'm willing to deal with = IANA on this. --Paul Hoffman= From internet-drafts@ietf.org Mon Apr 22 11:47:46 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BC021F9310; Mon, 22 Apr 2013 11:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w85FbONX4Ce8; Mon, 22 Apr 2013 11:47:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F7521F92FB; Mon, 22 Apr 2013 11:47:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p3 Message-ID: <20130422184745.13680.44055.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2013 11:47:45 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 18:47:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Additional Diffie-Hellman Tests for IKEv2 Author(s) : Yaron Sheffer Scott Fluhrer Filename : draft-ietf-ipsecme-dh-checks-03.txt Pages : 11 Date : 2013-04-22 Abstract: This document adds a small number of mandatory tests required for the secure operation of IKEv2 with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called DSA groups. This document updates the IKEv2 protocol, RFC 5996. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-dh-checks-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paul.hoffman@vpnc.org Mon Apr 22 13:10:34 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3200321E80DF; Mon, 22 Apr 2013 13:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaAURzxZBw2b; Mon, 22 Apr 2013 13:10:33 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 228B721E80D5; Mon, 22 Apr 2013 13:10:30 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3MKAIgW091163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Apr 2013 13:10:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Apr 2013 13:10:17 -0700 Message-Id: <85FAF6CE-FF60-469D-89D8-51296DF489D2@vpnc.org> To: iesg-secretary@ietf.org, Sean Turner Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Cc: IPsecme WG Subject: [IPsec] Please publish: draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 20:10:34 -0000 Document write-up for draft-ietf-ipsecme-dh-checks-03 1. Summary This is a document writeup for draft-ietf-ipsecme-dh-checks-03, prepared = by Paul Hoffman for Sean Turner. The document corrects a problem found well after RFC 5996 was published. = Implementations that support elliptic curves and DSA, and also reuse = private keys, are vulnerable to some attacks that can be prevented by = some simple checking. This document specifies the circumstances where = the attack might happen and how to prevent them. This document is appropriate for Standards Track because, if the attack = had been known and understood when RFC 5996 was written, it would = certainly have been part of that document. 2. Review and Consensus The document was reviewed by enough active developers and = cryptographically-inclined participants to be sufficient for Standards = Track. There is definite consensus to publish. 3. Intellectual Property Both authors have stated that their direct, personal knowledge of any = IPR related to this document has already been disclosed, in conformance = with BCPs 78 and 79. There was no WG discussion about any IPR = disclosures regarding this document. --Paul Hoffman= From noreply@ietf.org Mon Apr 22 22:12:33 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E51221F9636 for ; Mon, 22 Apr 2013 22:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.841 X-Spam-Level: X-Spam-Status: No, score=-93.841 tagged_above=-999 required=5 tests=[AWL=-6.223, BAYES_50=0.001, DOS_OE_TO_MX=2.75, FH_RELAY_NODNS=1.451, FORGED_MUA_OUTLOOK=3.116, GB_ABOUTYOU=0.5, HELO_MISMATCH_ORG=0.611, MSOE_MID_WRONG_CASE=0.82, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxF5MaluEWPj for ; Mon, 22 Apr 2013 22:12:32 -0700 (PDT) Received: from ietf.org (unknown [110.234.9.158]) by ietfa.amsl.com (Postfix) with ESMTP id C2DEF21F9635 for ; Mon, 22 Apr 2013 22:12:31 -0700 (PDT) From: "Bounced mail" To: ipsec@ietf.org Date: Tue, 23 Apr 2013 10:40:18 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_DC9F9E56.52EF42A2" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20130423051231.C2DEF21F9635@ietfa.amsl.com> Subject: [IPsec] Delivery reports about your e-mail X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 05:12:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0007_DC9F9E56.52EF42A2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The original message was received at Tue, 23 Apr 2013 10:40:18 +0530 from ietf.org [53.249.81.99] ----- The following addresses had permanent fatal errors ----- ipsec@ietf.org ------=_NextPart_000_0007_DC9F9E56.52EF42A2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Length: 215 Connection: Close Dangerous Attachment has been Removed. The file "readme.zip" has been removed because of a virus. It was infected with the "W32/Mydoom.M!dam" virus. File quarantined as: "". http://www.fortinet.com/ve?vid=47739 ------=_NextPart_000_0007_DC9F9E56.52EF42A2-- From cuiyang@huawei.com Tue Apr 23 05:19:11 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACED821F866E for ; Tue, 23 Apr 2013 05:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfgP+aqH8ciE for ; Tue, 23 Apr 2013 05:19:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0F36221F8618 for ; Tue, 23 Apr 2013 05:19:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQS55999; Tue, 23 Apr 2013 12:19:06 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Apr 2013 13:18:35 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Apr 2013 20:19:03 +0800 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.115]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Tue, 23 Apr 2013 20:18:56 +0800 From: Cuiyang To: Yaron Sheffer , Paul Hoffman , IPsecme WG Thread-Topic: [IPsec] STRONG NUDGE: WG Last Call on draft-ietf-ipsecme-oob-pubkey Thread-Index: AQHOPyt/XLEuj0Vwv0mfwAnKDnkO95jjtboA Date: Tue, 23 Apr 2013 12:18:55 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE2163732B37D@nkgeml505-mbx.china.huawei.com> References: <5174E6BD.7030200@gmail.com> In-Reply-To: <5174E6BD.7030200@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.48.139] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [IPsec] STRONG NUDGE: WG Last Call on draft-ietf-ipsecme-oob-pubkey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 12:19:11 -0000 U3VwcG9ydCB0aGlzIGRyYWZ0IHRvIGdvIG9uIHRvIElFVEYgcmV2aWV3Lg0KDQpJIGhhdmUgcmVh ZCB0aGlzIGRyYWZ0IGFuZCBmZWVsIHRoYXQgaXQgaXMgdXNlZnVsIHRvIGxldCBJS0V2MiBzdXBw b3J0IG1vcmUgdHlwZXMgb2YgcmF3IHB1YmxpYyBrZXlzLCBzdWNoIGFzIEVDQy4NClRoZSBjZXJ0 aWZpY2F0ZSBlbmNvZGluZyBoYXMgdXNlZCBhIG5ldyBmb3JtYXQgYW5kIG9ic29sZXRlZCB0aGUg b2xkIFJTQSBwdWJsaWMga2V5IGZvcm1hdCAiMTEiLg0KQW5kIGlmIHN1Y2ggYW4gb2xkIGVuY29k aW5nIGlzIHJlY2VpdmVkLCBpdCBNVVNUIE5PVCBiZSBjb25zaWRlcmVkIGFzIGEgZmF0YWwgZXJy b3IuDQoNCk9uZSB0eXBvIGZvdW5kOiBhdCB0aGUgbGFzdCBzZW50ZW5jZSBpbiBTZWMgMy4gIm5l ZWRzIHRvIGZvbGxvd2VkIiBzaG91bGQgYmUgIm5lZWRzIHRvIGJlIGZvbGxvd2VkIi4NCg0KQlIg WWFuZw0KPT09PT09PT09PT09PT09PT09DQogWWFuZyBDdWksICBQaC5ELg0KIEh1YXdlaSBUZWNo bm9sb2dpZXMNCiBjdWl5YW5nQGh1YXdlaS5jb20NCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4g t6K8/sjLOiBpcHNlYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aXBzZWMtYm91bmNlc0BpZXRm Lm9yZ10gtPqx7SBZYXJvbg0KPiBTaGVmZmVyDQo+ILeiy83KsbzkOiAyMDEzxOo01MIyMsjVIDE1 OjI5DQo+IMrVvP7IyzogUGF1bCBIb2ZmbWFuOyBJUHNlY21lIFdHDQo+INb3zOI6IFJlOiBbSVBz ZWNdIFNUUk9ORyBOVURHRTogV0cgTGFzdCBDYWxsIG9uDQo+IGRyYWZ0LWlldGYtaXBzZWNtZS1v b2ItcHVia2V5DQo+IA0KPiBXZSBoYXZlIHN0aWxsIG5vdCBoZWFyZCBhbnkgYWRkaXRpb25hbCBy ZXNwb25zZXMgZm9yIHRoaXMgbGFzdCBjYWxsLiBJZg0KPiB5b3UgdGhpbmsgdGhpcyBkcmFmdCBp cyB1c2VmdWwsIHBsZWFzZSBzYXkgc28gb24gdGhlIGxpc3QuIElmIHlvdSB0aGluaw0KPiBpdCBu ZWVkcyB0byBiZSBmaXhlZCwgcGxlYXNlIHNlbmQgeW91ciBjb21tZW50cy4NCj4gDQo+IFdlIGFy ZSBleHRlbmRpbmcgdGhpcyBMQyB1bnRpbCBGcmlkYXkgb2YgdGhpcyB3ZWVrLg0KPiANCj4gVGhh bmtzLA0KPiAJWWFyb24NCj4gDQo+IE9uIDIwMTMtMDQtMTcgMTg6MTgsIFBhdWwgSG9mZm1hbiB3 cm90ZToNCj4gPiBXZSBoYXZlIGdvdHRlbiBleGFjdGx5IG9uZSByZXNwb25zZSB0byB0aGlzLCBl dmVuIHRob3VnaCB0aGVyZSB3ZXJlIGxvdHMgb2YNCj4gcGVvcGxlIHdobyBzYWlkIHRoZXkgdGhv dWdodCB0aGlzIHdhcyBhIHZhbHVhYmxlIGFkZGl0aW9uIHRvIElLRXYyLiBQbGVhc2UNCj4gY29t bWVudCBiZWZvcmUgTW9uZGF5IHNvIHdlIGRvbid0IGhhdmUgdG8gYWJhbmRvbiB0aGUgd29yay4N Cj4gPg0KPiA+IC0tUGF1bCBIb2ZmbWFuDQo+ID4NCj4gPiBPbiBBcHIgOCwgMjAxMywgYXQgMjo0 MyBQTSwgUGF1bCBIb2ZmbWFuIDxwYXVsLmhvZmZtYW5AdnBuYy5vcmc+IHdyb3RlOg0KPiA+DQo+ ID4+IEdyZWV0aW5ncyBhZ2Fpbi4gVGhpcyBiZWdpbnMgdGhlIFdHIExhc3QgQ2FsbCBvbg0KPiBk cmFmdC1pZXRmLWlwc2VjbWUtb29iLXB1YmtleSwgIk1vcmUgUmF3IFB1YmxpYyBLZXlzIGZvciBJ S0V2MiIuIFlvdSBjYW4gZmluZA0KPiB0aGUgY3VycmVudCBkcmFmdCBhdCBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwc2VjbWUtb29iLXB1YmtleQ0KPiA+Pg0KPiA+PiBU aGlzIGRvY3VtZW50IGdlbmVyYXRlZCBhIGZhaXIgYW1vdW50IG9mIGludGVyZXN0IGVhcmx5LCBi dXQgd2UgaGF2ZSBub3QNCj4gaGFkIG11Y2ggZGlzY3Vzc2lvbiBzaW5jZS4gWWFyb24gYW5kIEkg d291bGQgKnJlYWxseSogbGlrZSB0byBoYXZlIGF0IGxlYXN0IGZpdmUNCj4gV0cgbWVtYmVycyBy ZXZpZXcgdGhlIGRvY3VtZW50IGFuZCBzYXkgb24gdGhlIGxpc3Qgd2hldGhlciBvciBub3QgdGhl eQ0KPiB0aGluayBpdCBpcyByZWFkeSBpbiBpdHMgY3VycmVudCBzdGF0ZSB0byBtb3ZlIHRvIElF VEYgcmV2aWV3LiBJZiB5b3UgcmVhZCBpdCBhbmQNCj4gZmVlbCBpdCBpcyBub3QgcmVhZHkgZm9y IGFueSByZWFzb24sIHBsZWFzZSBhbHNvIHNheSB0aGF0IGluIHlvdXIgbWVzc2FnZSB0byB0aGUN Cj4gbGlzdC4NCj4gPj4NCj4gPj4gQWdhaW4sIHBhcnRpY2lwYXRpbmcgaW4gV0cgTGFzdCBDYWxs cyBpcyBhIGdyZWF0IG9wcG9ydHVuaXR5IGZvciB0aG9zZSB3aG8NCj4gYXJlIGxlc3MgYWN0aXZl IGluIHRoZSBXRyBidXQgd2hvIHdhbnQgdG8gY29udHJpYnV0ZSB0byB0aGUgSUVURiB0byBtYWtl IGENCj4gZGlmZmVyZW5jZS4NCj4gPj4NCj4gPj4gVGhlIFdHIExhc3QgQ2FsbCBzaG91bGQgZW5k IGluIHR3byB3ZWVrcywgb24gQXByaWwgMjIuIFBsZWFzZSByZXZpZXcgdGhlDQo+IGRvY3VtZW50 IGJlZm9yZSB0aGVuLiBUaGFua3MgaW4gYWR2YW5jZSENCj4gPg0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gSVBzZWMgbWFpbGluZyBsaXN0 DQo+ID4gSVBzZWNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwc2VjDQo+ID4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gSVBzZWMgbWFpbGluZyBsaXN0DQo+IElQc2VjQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCg== From Johannes.Merkle@secunet.com Tue Apr 23 10:41:19 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C5D21F9412 for ; Tue, 23 Apr 2013 10:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WF8ZmbOKULP for ; Tue, 23 Apr 2013 10:41:18 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id CD0EE21F93F1 for ; Tue, 23 Apr 2013 10:41:17 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 6B84B1A0080 for ; Tue, 23 Apr 2013 19:41:16 +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 IbA6rQwupzqT for ; Tue, 23 Apr 2013 19:41:14 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 805621A007F for ; Tue, 23 Apr 2013 19:41:14 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Apr 2013 19:41:14 +0200 Message-ID: <5176C7B9.50001@secunet.com> Date: Tue, 23 Apr 2013 19:41:13 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ipsec@ietf.org References: <20130422184745.13680.44055.idtracker@ietfa.amsl.com> In-Reply-To: <20130422184745.13680.44055.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 23 Apr 2013 17:41:14.0339 (UTC) FILETIME=[C04D1330:01CE4049] Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 17:41:19 -0000 I hope I am not too late as the document write-up has already been sent out. Section 2.3 specifies: A receiving peer MUST check that its peer's public value is valid; that is, it is not the point- at-infinity, and that the x and y parameters from the peer's public value satisfy the curve equation, that is, y**2 = x**3 + ax + b mod p How can a peer check this? I am not aware of any encoding rule for the point-at-infinity in RFC 5903 or RFC 5114. Does the encoding of SEC1 apply, where the point-at-infinity is encoded to 0x00? According to RFC 5903 this would be padded with zeros, so that the decoding algorithm of the receiving peer would obtain x=0 and y=0. These do certainly not fulfill the curve equation as the discriminant -16*(4*a^3 + 27*b^2) must be non-zero. So isn't the requirement to check that the value it is not the point-at-infinity confusing and redundant? Johannes > 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 : Additional Diffie-Hellman Tests for IKEv2 > Author(s) : Yaron Sheffer > Scott Fluhrer > Filename : draft-ietf-ipsecme-dh-checks-03.txt > Pages : 11 > Date : 2013-04-22 > > Abstract: > This document adds a small number of mandatory tests required for the > secure operation of IKEv2 with elliptic curve groups. No change is > required to IKE implementations that use modular exponential groups, > other than a few rarely used so-called DSA groups. This document > updates the IKEv2 protocol, RFC 5996. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-dh-checks-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Mit freundlichen Grüßen, Dr. Johannes Merkle Principal Beratung, Elektronische Identitäten 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 prvs=38251c59b3=dbrown@certicom.com Tue Apr 23 11:34:46 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A96F21F9623 for ; Tue, 23 Apr 2013 11:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIT4YZgCDc1e for ; Tue, 23 Apr 2013 11:34:44 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 69E6321F9621 for ; Tue, 23 Apr 2013 11:34:44 -0700 (PDT) X-AuditID: 0a41282f-b7f326d000005ad9-1d-5176d438e2d3 Received: from XCT107CNC.rim.net (xct107cnc.rim.net [10.65.161.207]) by mhs060cnc.rim.net (SBG) with SMTP id D7.0F.23257.834D6715; Tue, 23 Apr 2013 13:34:32 -0500 (CDT) Received: from XCT116CNC.rim.net (10.65.161.216) by XCT107CNC.rim.net (10.65.161.207) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 23 Apr 2013 14:34:32 -0400 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT116CNC.rim.net ([::1]) with mapi id 14.02.0328.009; Tue, 23 Apr 2013 14:34:31 -0400 From: Dan Brown To: 'Johannes Merkle' , "ipsec@ietf.org" Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-03.txt Thread-Index: AQHOP4oAIiS+sFdG0kqWmTRP6ozCHpjkV3mA///GaUA= Date: Tue, 23 Apr 2013 18:34:31 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF51437D8@XMB111CNC.rim.net> References: <20130422184745.13680.44055.idtracker@ietfa.amsl.com> <5176C7B9.50001@secunet.com> In-Reply-To: <5176C7B9.50001@secunet.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHKsWRmVeSWpSXmKPExsXC5bjwvK7FlbJAg+MblSz2b3nBZrFsxixG ByaPJUt+Mnlsal3CGsAU1cBok5RYUhacmZ6nb2eTmJeXX5JYkqqQklqcbKvkk5qemKMQUJRZ lphcqeCSWZyck5iZm1qkpJCZYqtkoqRQkJOYnJqbmldiq5RYUJCal6Jkx6WAAWyAyjLzFFLz kvNTMvPSbZU8g/11LSxMLXUNlex0Ezp5MlY1zmYpWKtUcXXeRaYGxnbpLkZODgkBE4kVBzcw QthiEhfurWfrYuTiEBJYxShx48Z3VghnJaPE4WPTWECqhATmMEo8avYDsdkEVCXuHz3HDGKL CERI/Jm7FWySsICLxOsLXYwQcVeJdwca2CFsK4lZL96B1bMA9a78uAoszivgJvF8zkwmiPkJ EsfOngCLcwpoSkw+M5UNxGYUkJXYffY6WA2zgLjErSfzmSCuFpBYsuc8M4QtKvHy8T9WCFtR 4sXkcywQ9XoSN6ZOYYOwtSWWLXzNDLFXUOLkzCdQfylIXLm+j2UCo/gsJCtmIWmfhaR9FpL2 BYwsqxgFczOKDcwMkvOS9Yoyc/XyUks2MYITiIb+Dsa37y0OMQpwMCrx8J7aXxYoxJpYVlyZ e4hRgoNZSYTXejZQiDclsbIqtSg/vqg0J7X4EKMrMIQmMktxJ+cDk1teSbyxgQFujpI474Ve oCEC6cB0lZ2aWpBaBDOHiYMTZA+XlEgxMOmkFiWWlmTEg1JjfDEwOUo1MCqntH2aFR15kE1r SvmmvF8bKtv75Ww8370I8191Oujx+jevtNcunDf1xelK9Wc7e0Ne2Im+yGH1vey7mfOYROud tYs/bN25tvzlp3Xc3ptPHF+3iG31zeJz+27xLy9fMe9siNs/AVbGJbt7D3YHs7xawM1wop2t c9V97eJTvAn/bnsdvaKq5+WoxFKckWioxVxUnAgAjLzUWmEDAAA= Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 18:34:46 -0000 Johannes, Good catch. This probably requires a clarification. I would suggest that the existing formats (x,y) of the correct length imply= a point in the finite plane, and in particular not the point at infinity. = In other words, whatever length-checking that peers currently use probably= suffices to check for this condition of not being the point-at-infinity. I disagree that (x,y)=3D(0,0) should be interpreted as the point-at-infinity= . I advise against a separate check for this, and instead to rely on the le= ngth-check and the curve equation-check. Elliptic curves exist, e.g. y^2 =3D x^3 + x, for which (0,0) is a point on t= he curve, but the point (0,0) would have order two, so would normally be con= sidered invalid (excluded by a cofactor check etc.). In the SEC1 format that you mention, which is similar to the IEEE and ANSI f= ormat, the 00 encoding occupies the initial octet position. This first octe= t acts like a tag, and takes a non-zero value when the point is on the finit= e plane. It seems that IKE does not use this tag octet. Best regards, Dan > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Johannes Merkle > Sent: Tuesday, April 23, 2013 1:41 PM > To: ipsec@ietf.org > Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-03.txt > > I hope I am not too late as the document write-up has already been sent > out. > > Section 2.3 specifies: > A receiving peer MUST check > that its peer's public value is valid; that is, it is not the point- > at-infinity, and that the x and y parameters from the peer's public > value satisfy the curve equation, that is, y**2 =3D x**3 + ax + b mod > p > > How can a peer check this? I am not aware of any encoding rule for the > point-at-infinity in RFC 5903 or RFC 5114. Does > the encoding of SEC1 apply, where the point-at-infinity is encoded to > 0x00? According to RFC 5903 this would be padded > with zeros, so that the decoding algorithm of the receiving peer would > obtain x=3D0 and y=3D0. These do certainly not > fulfill the curve equation as the discriminant -16*(4*a^3 + 27*b^2) > must be non-zero. > > So isn't the requirement to check that the value it is not the point- > at-infinity confusing and redundant? > > Johannes > > > > 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 : Additional Diffie-Hellman Tests for IKEv2 > > Author(s) : Yaron Sheffer > > Scott Fluhrer > > Filename : draft-ietf-ipsecme-dh-checks-03.txt > > Pages : 11 > > Date : 2013-04-22 > > > > Abstract: > > This document adds a small number of mandatory tests required for > the > > secure operation of IKEv2 with elliptic curve groups. No change > is > > required to IKE implementations that use modular exponential > groups, > > other than a few rarely used so-called DSA groups. This document > > updates the IKEv2 protocol, RFC 5996. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-03 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-dh-checks-03 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > -- > > Mit freundlichen Gr=FC=DFen, > Dr. Johannes Merkle > Principal Beratung, Elektronische Identit=E4ten > 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 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From kivinen@iki.fi Thu Apr 25 05:21:38 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE55121F944F for ; Thu, 25 Apr 2013 05:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYm2zV0L9lPg for ; Thu, 25 Apr 2013 05:21:36 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5F60421F937B for ; Thu, 25 Apr 2013 05:21:32 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3PCLCsk024586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Apr 2013 15:21:12 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3PCL8EW020063; Thu, 25 Apr 2013 15:21:08 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20857.8116.670800.734489@fireball.kivinen.iki.fi> Date: Thu, 25 Apr 2013 15:21:08 +0300 From: Tero Kivinen To: Cuiyang In-Reply-To: <8CC0CB0BCAE52F46882E17828A9AE2163732B37D@nkgeml505-mbx.china.huawei.com> References: <5174E6BD.7030200@gmail.com> <8CC0CB0BCAE52F46882E17828A9AE2163732B37D@nkgeml505-mbx.china.huawei.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 0 min Cc: IPsecme WG Subject: Re: [IPsec] STRONG NUDGE: WG Last Call on draft-ietf-ipsecme-oob-pubkey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 12:21:38 -0000 Cuiyang writes: > One typo found: at the last sentence in Sec 3. "needs to followed" > should be "needs to be followed". Fixed now in my local version. -- kivinen@iki.fi From Johannes.Merkle@secunet.com Thu Apr 25 05:43:54 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA0021F9590 for ; Thu, 25 Apr 2013 05:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3WjEVvZeIy5 for ; Thu, 25 Apr 2013 05:43:52 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2A221F95E1 for ; Thu, 25 Apr 2013 05:43:52 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id E1AC01A0088; Thu, 25 Apr 2013 14:43:50 +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 vYv8nd_7rT_x; Thu, 25 Apr 2013 14:43:49 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 4C8BD1A0087; Thu, 25 Apr 2013 14:43:49 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Apr 2013 14:43:49 +0200 Message-ID: <51792504.5010800@secunet.com> Date: Thu, 25 Apr 2013 14:43:48 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Dan Brown References: <20130422184745.13680.44055.idtracker@ietfa.amsl.com> <5176C7B9.50001@secunet.com> <810C31990B57ED40B2062BA10D43FBF51437D8@XMB111CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF51437D8@XMB111CNC.rim.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Apr 2013 12:43:49.0345 (UTC) FILETIME=[88AE9510:01CE41B2] Cc: "ipsec@ietf.org" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 12:43:54 -0000 > I disagree that (x,y)=(0,0) should be interpreted as the point-at-infinity. I advise against a separate check for this, and instead to rely on the length-check and the curve equation-check. I agree. As no encoding is defined for the point-at-infinity in IKEv2, there can be no check for it. Section 2.3 should be changed from A receiving peer MUST check that its peer's public value is valid; that is, it is not the point- at-infinity, and that the x and y parameters from the peer's public value satisfy the curve equation, that is, y**2 = x**3 + ax + b mod p to A receiving peer MUST check that its peer's public value is valid; that is, the x and y parameters from the peer's public value satisfy the curve equation, that is, y**2 = x**3 + ax + b mod p And a note should be added explaining, why a check for the point-at-infinity, as suggested by other standards, is not applicable for IKE. Johannes > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Johannes Merkle >> Sent: Tuesday, April 23, 2013 1:41 PM >> To: ipsec@ietf.org >> Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-03.txt >> >> I hope I am not too late as the document write-up has already been sent >> out. >> >> Section 2.3 specifies: >> A receiving peer MUST check >> that its peer's public value is valid; that is, it is not the point- >> at-infinity, and that the x and y parameters from the peer's public >> value satisfy the curve equation, that is, y**2 = x**3 + ax + b mod >> p >> >> How can a peer check this? I am not aware of any encoding rule for the >> point-at-infinity in RFC 5903 or RFC 5114. Does >> the encoding of SEC1 apply, where the point-at-infinity is encoded to >> 0x00? According to RFC 5903 this would be padded >> with zeros, so that the decoding algorithm of the receiving peer would >> obtain x=0 and y=0. These do certainly not >> fulfill the curve equation as the discriminant -16*(4*a^3 + 27*b^2) >> must be non-zero. >> >> So isn't the requirement to check that the value it is not the point- >> at-infinity confusing and redundant? >> >> Johannes >> >> >>> 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 : Additional Diffie-Hellman Tests for IKEv2 >>> Author(s) : Yaron Sheffer >>> Scott Fluhrer >>> Filename : draft-ietf-ipsecme-dh-checks-03.txt >>> Pages : 11 >>> Date : 2013-04-22 >>> >>> Abstract: >>> This document adds a small number of mandatory tests required for >> the >>> secure operation of IKEv2 with elliptic curve groups. No change >> is >>> required to IKE implementations that use modular exponential >> groups, >>> other than a few rarely used so-called DSA groups. This document >>> updates the IKEv2 protocol, RFC 5996. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-03 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-dh-checks-03 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >> > From yaronf.ietf@gmail.com Thu Apr 25 05:49:50 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D19921F8C08 for ; Thu, 25 Apr 2013 05:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-y0Gcp+ggCs for ; Thu, 25 Apr 2013 05:49:49 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 04F2A21F8523 for ; Thu, 25 Apr 2013 05:49:48 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id h14so1192462eak.7 for ; Thu, 25 Apr 2013 05:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fhPl4umj4pRBvllYJ507D32m2L3yrRpQjN3SYb2Ewtk=; b=Pcf2jEfTYSUBFUdYN/5UfzucgAhh2nDdtBhderxC07QONUKqj1Yxv/dDzN9ph7O1E8 Z13BtdwRlotpQFczyQZcVHeWtQ4UWGs30KPSqdCJG/KjXlUsB0GASI87qE/1qZ1n33SY pIxZx1HrYy2ylB6H40L6SzE6CU4dvDcG9tUvO30eJuRlPpjtVKH3OfQp74dzJQeXbIwi JZUtdWoeS1dq2dy+pI34MZPTaorKbCUHbk8EilzabVuZxLlUh+BR2AJ64PamwuQ4wBQ9 dzGKEUvm1YsSXcV/NOXEkyKJCwJQ1m2B5IPK+8CMogFO2EABtqJ/FE/FsY6IFxtkP/55 3Q4w== X-Received: by 10.14.194.70 with SMTP id l46mr28160702een.28.1366894187953; Thu, 25 Apr 2013 05:49:47 -0700 (PDT) Received: from [10.0.0.14] (109-186-115-180.bb.netvision.net.il. [109.186.115.180]) by mx.google.com with ESMTPSA id f9sm10182550eeu.11.2013.04.25.05.49.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Apr 2013 05:49:47 -0700 (PDT) Message-ID: <51792663.3030403@gmail.com> Date: Thu, 25 Apr 2013 15:49:39 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Johannes Merkle References: <20130422184745.13680.44055.idtracker@ietfa.amsl.com> <5176C7B9.50001@secunet.com> <810C31990B57ED40B2062BA10D43FBF51437D8@XMB111CNC.rim.net> <51792504.5010800@secunet.com> In-Reply-To: <51792504.5010800@secunet.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Dan Brown , "ipsec@ietf.org" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 12:49:50 -0000 I agree. I will implement the change when Sean completes his AD review of the draft. Thanks, Yaron On 2013-04-25 15:43, Johannes Merkle wrote: > >> I disagree that (x,y)=(0,0) should be interpreted as the point-at-infinity. I advise against a separate check for this, and instead to rely on the length-check and the curve equation-check. > > I agree. As no encoding is defined for the point-at-infinity in IKEv2, there can be no check for it. > > Section 2.3 should be changed from > A receiving peer MUST check > that its peer's public value is valid; that is, it is not the point- > at-infinity, and that the x and y parameters from the peer's public > value satisfy the curve equation, that is, y**2 = x**3 + ax + b mod p > > to > > A receiving peer MUST check > that its peer's public value is valid; that is, the x and y parameters > from the peer's public value satisfy the curve equation, that is, > y**2 = x**3 + ax + b mod p > > And a note should be added explaining, why a check for the point-at-infinity, as suggested by other standards, is not > applicable for IKE. > > Johannes > >> >>> -----Original Message----- >>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >>> Of Johannes Merkle >>> Sent: Tuesday, April 23, 2013 1:41 PM >>> To: ipsec@ietf.org >>> Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-03.txt >>> >>> I hope I am not too late as the document write-up has already been sent >>> out. >>> >>> Section 2.3 specifies: >>> A receiving peer MUST check >>> that its peer's public value is valid; that is, it is not the point- >>> at-infinity, and that the x and y parameters from the peer's public >>> value satisfy the curve equation, that is, y**2 = x**3 + ax + b mod >>> p >>> >>> How can a peer check this? I am not aware of any encoding rule for the >>> point-at-infinity in RFC 5903 or RFC 5114. Does >>> the encoding of SEC1 apply, where the point-at-infinity is encoded to >>> 0x00? According to RFC 5903 this would be padded >>> with zeros, so that the decoding algorithm of the receiving peer would >>> obtain x=0 and y=0. These do certainly not >>> fulfill the curve equation as the discriminant -16*(4*a^3 + 27*b^2) >>> must be non-zero. >>> >>> So isn't the requirement to check that the value it is not the point- >>> at-infinity confusing and redundant? >>> >>> Johannes >>> >>> >>>> 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 : Additional Diffie-Hellman Tests for IKEv2 >>>> Author(s) : Yaron Sheffer >>>> Scott Fluhrer >>>> Filename : draft-ietf-ipsecme-dh-checks-03.txt >>>> Pages : 11 >>>> Date : 2013-04-22 >>>> >>>> Abstract: >>>> This document adds a small number of mandatory tests required for >>> the >>>> secure operation of IKEv2 with elliptic curve groups. No change >>> is >>>> required to IKE implementations that use modular exponential >>> groups, >>>> other than a few rarely used so-called DSA groups. This document >>>> updates the IKEv2 protocol, RFC 5996. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-03 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-dh-checks-03 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>> >>> >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From tony.putman@alcatel-lucent.com Thu Apr 25 10:46:08 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512E921F963F for ; Thu, 25 Apr 2013 10:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sr9v6vtL2p-C for ; Thu, 25 Apr 2013 10:46:07 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8E57121F9638 for ; Thu, 25 Apr 2013 10:46:07 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r3PHk2oo011181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Apr 2013 12:46:03 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r3PHk0RZ029763 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Apr 2013 13:46:02 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 25 Apr 2013 13:46:01 -0400 Received: from FR711WXCHMBA01.zeu.alcatel-lucent.com ([169.254.1.210]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 25 Apr 2013 19:46:01 +0200 From: "PUTMAN, Tony (Tony)" To: IPsecme WG Thread-Topic: [IPsec] STRONG NUDGE: WG Last Call on draft-ietf-ipsecme-oob-pubkey Thread-Index: AQHOPys8pnjJHNtKUkCIvg9Re01fopjm6+Bg Date: Thu, 25 Apr 2013 17:46:00 +0000 Message-ID: <14BE57EA00BC0C469E17B5AD698FE6770150FF@FR711WXCHMBA01.zeu.alcatel-lucent.com> References: <5174E6BD.7030200@gmail.com> In-Reply-To: <5174E6BD.7030200@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: Paul Hoffman Subject: Re: [IPsec] STRONG NUDGE: WG Last Call on draft-ietf-ipsecme-oob-pubkey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 17:46:08 -0000 I would like to express support for this draft. I have reviewed the draft = and have no comments on the contents. I am a user of IPsec, not an implementer. I feel that this will make suppo= rt for raw keys more attractive to implementors so that it will become more= widely available. Raw public keys in conjunction with DANE is likely to b= e useful as a lighter-weight alternative to full PKI. Regards, Tony -- Tony Putman Alcatel-Lucent -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: 22 April 2013 08:29 To: Paul Hoffman; IPsecme WG Subject: Re: [IPsec] STRONG NUDGE: WG Last Call on draft-ietf-ipsecme-oob-p= ubkey We have still not heard any additional responses for this last call. If you think this draft is useful, please say so on the list. If you think it needs to be fixed, please send your comments. We are extending this LC until Friday of this week. Thanks, Yaron On 2013-04-17 18:18, Paul Hoffman wrote: > We have gotten exactly one response to this, even though there were lots = of people who said they thought this was a valuable addition to IKEv2. Plea= se comment before Monday so we don't have to abandon the work. > > --Paul Hoffman > > On Apr 8, 2013, at 2:43 PM, Paul Hoffman wrote: > >> Greetings again. This begins the WG Last Call on draft-ietf-ipsecme-oob-= pubkey, "More Raw Public Keys for IKEv2". You can find the current draft at= http://tools.ietf.org/html/draft-ietf-ipsecme-oob-pubkey >> >> This document generated a fair amount of interest early, but we have not= had much discussion since. Yaron and I would *really* like to have at leas= t five WG members review the document and say on the list whether or not th= ey think it is ready in its current state to move to IETF review. If you re= ad it and feel it is not ready for any reason, please also say that in your= message to the list. >> >> Again, participating in WG Last Calls is a great opportunity for those w= ho are less active in the WG but who want to contribute to the IETF to make= a difference. >> >> The WG Last Call should end in two weeks, on April 22. Please review the= document before then. Thanks in advance! > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From yumao9@gmail.com Fri Apr 26 20:10:38 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A5F21F9D73 for ; Fri, 26 Apr 2013 20:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 256x--ex6Ifc for ; Fri, 26 Apr 2013 20:10:38 -0700 (PDT) Received: from mail-ia0-x22c.google.com (mail-ia0-x22c.google.com [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0868C21F9D70 for ; Fri, 26 Apr 2013 20:10:37 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id i20so4276957ian.3 for ; Fri, 26 Apr 2013 20:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=hp1onqEPzWxhr9Ol7fyVBNolEFXRCxHQ8Xr1wruDbC4=; b=RDkmgTshZ7Tieo6LMXOxGBVStdj9TwmYFMVfhtuYaKGR35npeiZduQ+V+kDCbpB1IV ZuL9+Gf+pcYUfF2FjMLnTRURRtcnHTrVvvnA6prieTlYjv+nCkcCemxPYdYfqV2QPwpD WplyoC73Uqm8OjyuiYI2zjpqu+N/ApBFUg1xhk6wKIjq51yCQ733UjuN+B9yppykWziF QkEg4VLvDLoJGJ6PmJhPeDu1cCQln7yamfiHY/GMmkuYuUSya4fSSxw7d8XfLLjNiZww LDy2/sBDLq/CbuA31PSRVmwu9IsZ1GQ1toUqB/gBOSOZ1znVsVXD2u9h624+nC/u/e2q RCow== MIME-Version: 1.0 X-Received: by 10.50.77.110 with SMTP id r14mr3419826igw.85.1367032237663; Fri, 26 Apr 2013 20:10:37 -0700 (PDT) Received: by 10.42.102.19 with HTTP; Fri, 26 Apr 2013 20:10:37 -0700 (PDT) Date: Sat, 27 Apr 2013 11:10:37 +0800 Message-ID: From: Toby Mao To: IPsecme WG Content-Type: multipart/alternative; boundary=047d7bd75594ec2f3004db4efeb3 Cc: "maoyu@h3c.com" Subject: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 03:10:38 -0000 --047d7bd75594ec2f3004db4efeb3 Content-Type: text/plain; charset=ISO-8859-1 I agree with almost all the requirements in the draft-ietf-ipsecme-ad-vpn-problem. However, I think one more requirement should be added in the Section 4.1. The ADVPN solution SHOULD be able to implement Quality of Service (QoS) to regulate the traffic in the ADVPN topology. ADVPN peer SHOULD NOT send excessive traffic to the other members of ADVPN. The traffic for each ADVPN peer CAN be measured individually for shaping and policing. Best regards, Toby ---------- Forwarded message ---------- From: Date: Mon, Apr 22, 2013 at 9:03 PM Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt To: i-d-announce@ietf.org Cc: ipsec@ietf.org 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 : Auto Discovery VPN Problem Statement and Requirements Author(s) : Steve Hanna Vishwas Manral Filename : draft-ietf-ipsecme-ad-vpn-problem-06.txt Pages : 11 Date : 2013-04-22 Abstract: This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements, for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases the IP address of endpoints change or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto Discovery VPN solution will address these requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ad-vpn-problem-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --047d7bd75594ec2f3004db4efeb3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree with almost all the requirements in the draft-ietf= -ipsecme-ad-vpn-problem. However, I think one more requirement should be ad= ded in the Section 4.1.

The ADVPN solution SHOULD be able to impleme= nt Quality of Service (QoS) to regulate the traffic in the ADVPN topology. = ADVPN peer SHOULD NOT send excessive traffic to the other members of ADVPN.= The traffic for each ADVPN peer CAN be measured individually for shaping a= nd policing.

Best regards,
Toby

---------- Forw= arded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Apr 22, 2013 at 9:03 PM
Subject: [IPsec] I-D Action: draft-ie= tf-ipsecme-ad-vpn-problem-06.txt
To: i-d-announce@ietf.org
Cc: ipsec@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the IP Security Maintenance and Extensions = Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Auto Discovery VPN Problem Stat= ement and Requirements
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Steve Hanna
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Vishwas Manral
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-ipsecme-ad-vpn-problem= -06.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 11
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-22

Abstract:
=A0 =A0This document describes the problem of enabling a large number of =A0 =A0systems to communicate directly using IPsec to protect the traffic =A0 =A0between them. =A0It then expands on the requirements, for such a
=A0 =A0solution.

=A0 =A0Manual configuration of all possible tunnels is too cumbersome in =A0 =A0many such cases. =A0In other cases the IP address of endpoints chang= e
=A0 =A0or the endpoints may be behind NAT gateways, making static
=A0 =A0configuration impossible. =A0The Auto Discovery VPN solution will =A0 =A0address these requirements.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-a= d-vpn-problem

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-pro= blem-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ip= secme-ad-vpn-problem-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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

--047d7bd75594ec2f3004db4efeb3-- From paul.hoffman@vpnc.org Sat Apr 27 07:58:01 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E85521F98A7 for ; Sat, 27 Apr 2013 07:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZi6V5DBf0mS for ; Sat, 27 Apr 2013 07:58:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEA321F98A3 for ; Sat, 27 Apr 2013 07:58:00 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3REvq89073300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 27 Apr 2013 07:57:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Sat, 27 Apr 2013 07:57:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0C678C21-ECDD-4249-9DBB-B120DEE8613F@vpnc.org> References: To: Toby Mao X-Mailer: Apple Mail (2.1503) Cc: IPsecme WG , "maoyu@h3c.com" Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 14:58:01 -0000 These requirements might be useful to add in the next draft, but they = need to be refined. On Apr 26, 2013, at 8:10 PM, Toby Mao wrote: > The ADVPN solution SHOULD be able to implement Quality of Service = (QoS) to regulate the traffic in the ADVPN topology. Why is this statement needed? Do you see situations where an ADVPN = solution would be *prevented* from implementing some sort of QoS because = it was an ADVPN? > ADVPN peer SHOULD NOT send excessive traffic to the other members of = ADVPN. How would you define "excessive"? Where would that measurement be done? > The traffic for each ADVPN peer CAN be measured individually for = shaping and policing. Why is this statement needed? Do you see situations where an ADVPN = solution would be *prevented* from measuring individually? --Paul Hoffman= From paul.hoffman@vpnc.org Sat Apr 27 09:39:09 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4709821F9739 for ; Sat, 27 Apr 2013 09:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryg3Op8KD-kB for ; Sat, 27 Apr 2013 09:39:08 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A0C7021F972C for ; Sat, 27 Apr 2013 09:39:08 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3RGd753075611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 27 Apr 2013 09:39:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9DD83A21-6C8A-4EAC-A2E3-B8DE094A46E0@vpnc.org> Date: Sat, 27 Apr 2013 09:39:08 -0700 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [IPsec] On the WG not moving draft-ietf-ipsecme-oob-pubkey to the IETF X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 16:39:09 -0000 There was not enough support for draft-ietf-ipsecme-oob-pubkey for us to = say that there is WG consensus on the document. Only three people even = commented: Michael Richardson, Yang Cui, and Tony Putman. The document authors (who did a lot of hard work) should strongly = consider resubmitting the document again using a non-WG file name and = taking it to the Security Area Directors as an individual submission. I = believe that it should become a standard, despite with the = barely-visible support of this WG. --Paul Hoffman From yaronf.ietf@gmail.com Sat Apr 27 10:02:12 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A735021F9836 for ; Sat, 27 Apr 2013 10:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7maUVCINdWj for ; Sat, 27 Apr 2013 10:02:12 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DCAAE21F982D for ; Sat, 27 Apr 2013 10:02:11 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so2792245wgh.12 for ; Sat, 27 Apr 2013 10:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Ss62dVeZV7z6fqRWOrX3/FGbYqTh5Cq8vA3Nx13znB8=; b=zciRCzjcEGPpW5CJGnEsnHO0QMvgrB7E7ikb9PhThLnGYtLz4XYhNHDr4tEXNtaXPi Y9Hb1w+Mrw/v+h62IXAVfOJCRm7RTrFJ8oMSdwq1AjwoaRuTWdD9zIPhcoqOX/ALB7dq 5UTjrYzrOXlJo+ZYNGgHxWS60TfS2jcC73aAaTtFlkaGEfAQaJUn8ypMTvmX44cxHOOR oVymOxcu3FR1P2NCS4zrAIX4y2+cMjTTMPHPu5lk7QLyezHd3yirsYKha7bXlboDIJcG RXdere0eFp6x8ZlRcyV+ON63rNNx1Iws6yiXfo0XXfUJ8OIT5nHpnJV/z2G0rNoHE7dM qeFA== X-Received: by 10.180.20.37 with SMTP id k5mr9645148wie.27.1367082131098; Sat, 27 Apr 2013 10:02:11 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-176-108-129.red.bezeqint.net. [79.176.108.129]) by mx.google.com with ESMTPSA id dj7sm10110938wib.6.2013.04.27.10.02.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Apr 2013 10:02:10 -0700 (PDT) Message-ID: <517C0490.9010600@gmail.com> Date: Sat, 27 Apr 2013 20:02:08 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] IPsecME virtual interim meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 17:02:12 -0000 Dear IPsec folks, The ipsecme working group is chartered to come up with a solution for transporting long IKEv2 messages over networks that do not perform IP fragmentation correctly, and as a result drop overly long messages, usually IKE_AUTH messages. Our original plan was to base the solution on IKE-over-TCP, however the author of this draft decided to abandon it because he now prefers a different solution, similar to the (non-standard) IKEv1 Fragmentation payload that was implemented by several vendors (see http://msdn.microsoft.com/en-us/library/cc233251.aspx). We do not want to end up with a common but non-standard solution in IKEv2, which would practically guarantee interoperability issues. As a further data point, we are aware of IPR issues with Microsoft's solution; we have tried to clarify the issue with Microsoft but have not been successful yet. We would like to invite the group to a Virtual Interim Meeting (a.k.a. conference call), to discuss this problem. Potential outcomes of the meeting include: - The group decides that this is not an important problem. - This is an important problem and we have 1-2 people committed to author a draft along the lines of the non-standard IKEv1 mechanism. - This is an important problem and the group is happy to adopt draft-smyslov-ipsecme-ikev2-fragmentation (which solves the same problem in a somewhat different fashion). - The group still prefers IKE-over-TCP and there are committed authors to continue work on that draft. We propose to meet May 7, at 9:00am PST (16:00 UTC, 12:00 noon EST, 19:00 Israel) for 1 hour. We will publish a bridge number a week before the meeting. Please let us know if the date/time absolutely doesn't work for you. We welcome and invite discussion of these issues on the mailing list before the meeting. Thanks, Paul and Yaron From johnsonhammond1@hushmail.com Sat Apr 27 14:57:07 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9D921F9922 for ; Sat, 27 Apr 2013 14:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNj2FfoBROFo for ; Sat, 27 Apr 2013 14:57:07 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6D03A21F990D for ; Sat, 27 Apr 2013 14:57:07 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id AA5D7E7D4D for ; Sat, 27 Apr 2013 17:47:24 +0000 (UTC) X-hush-relay-time: 214 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp2.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:47:24 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 673FCE6739; Sat, 27 Apr 2013 17:47:24 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:47:24 -0400 To: ipsec@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427174724.673FCE6739@smtp.hushmail.com> Subject: [IPsec] Biggest Fake Conference in Computer Science X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 21:57:07 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From mcr@sandelman.ca Sat Apr 27 17:18:34 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4E321F8D8E for ; Sat, 27 Apr 2013 17:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1z6P9lDCXDf for ; Sat, 27 Apr 2013 17:18:33 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 7D68C21F8CB4 for ; Sat, 27 Apr 2013 17:18:27 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 849F020170; Sat, 27 Apr 2013 20:29:07 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7659F63A62; Sat, 27 Apr 2013 20:17:57 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5EE1463A61; Sat, 27 Apr 2013 20:17:57 -0400 (EDT) From: Michael Richardson To: Yaron Sheffer In-Reply-To: <517C0490.9010600@gmail.com> References: <517C0490.9010600@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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 Cc: IPsecme WG Subject: Re: [IPsec] IPsecME virtual interim meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 00:18:34 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Yaron" =3D=3D Yaron Sheffer writes: Yaron> We propose to meet May 7, at 9:00am PST (16:00 UTC, 12:00 noon E= ST, 19:00 Yaron> Israel) for 1 hour. We will publish a bridge number a week Yaron> before the meeting.=20 okay. Is that enough notice? I agree that the problem likely needs be solved in a standard way. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUXxqtYqHRg3pndX9AQJ+ogQAjprim5AfncJ8wcdB5oFHl8WUf7xBuM3O I4IuAfhnoo98LM34LnvtGmj73OoeQr+O6rsfkMcIrGf7mW0VM5YeD7GObqlJ0DcK N1I45kjYZW9IaYj/NtsioZHtE0YnHa8bN2JT2XV9LbB3Uy7Dxpbs6mve5VGxyW81 l2uaHRq4gxs= =nx0a -----END PGP SIGNATURE----- --=-=-=-- From ynir@checkpoint.com Sat Apr 27 23:55:52 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4015121F97FB for ; Sat, 27 Apr 2013 23:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2uVVDioc37H for ; Sat, 27 Apr 2013 23:55:51 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3804121F981B for ; Sat, 27 Apr 2013 23:55:50 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r3S6tmRq031334; Sun, 28 Apr 2013 09:55:48 +0300 X-CheckPoint: {517CC6E1-1C-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Sun, 28 Apr 2013 09:55:48 +0300 From: Yoav Nir To: Yaron Sheffer Thread-Topic: [IPsec] IPsecME virtual interim meeting Thread-Index: AQHOQ2j7ZhGECxqyw0G6MTCqHW7GhZjrAbWA Date: Sun, 28 Apr 2013 06:55:47 +0000 Message-ID: <8171432E-D286-437B-92AA-B193A38502B5@checkpoint.com> References: <517C0490.9010600@gmail.com> In-Reply-To: <517C0490.9010600@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.65] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11f40b2ea577d5c221bf47f00b07c1f4efd9dec348 Content-Type: text/plain; charset="us-ascii" Content-ID: <76E7E57C136396448FFB7129623DE0A2@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] IPsecME virtual interim meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 06:55:52 -0000 On Apr 27, 2013, at 8:02 PM, Yaron Sheffer wrote: > Dear IPsec folks, >=20 > The ipsecme working group is chartered to come up with a solution for tra= nsporting long IKEv2 messages over networks that do not perform IP fragment= ation correctly, and as a result drop overly long messages, usually IKE_AUT= H messages. >=20 > Our original plan was to base the solution on IKE-over-TCP, however the a= uthor of this draft decided to abandon it because he now prefers a differen= t solution, similar to the (non-standard) IKEv1 Fragmentation payload that = was implemented by several vendors (see http://msdn.microsoft.com/en-us/lib= rary/cc233251.aspx). We do not want to end up with a common but non-standar= d solution in IKEv2, which would practically guarantee interoperability iss= ues. Just to set the record straight, I did not decide to abandon it, and if the= group would like to pursue IKE-over-TCP I am willing to continue as editor= . As a vendor, though, I would much rather implement just one mechanism tha= t would work for both IKEv1 and IKEv2, and there is a huge installed base o= f IKEv1 with fragments. > We propose to meet May 7, at 9:00am PST (16:00 UTC, 12:00 noon EST, 19:00= Israel) for 1 hour. We will publish a bridge number a week before the meet= ing. >=20 > Please let us know if the date/time absolutely doesn't work for you. This works for me. Yoav From yaronf.ietf@gmail.com Sun Apr 28 00:20:20 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F4B21F9821 for ; Sun, 28 Apr 2013 00:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tq5LCDspWDT for ; Sun, 28 Apr 2013 00:20:20 -0700 (PDT) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id 10CAF21F97D1 for ; Sun, 28 Apr 2013 00:20:19 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id b15so1146597eek.37 for ; Sun, 28 Apr 2013 00:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0rntzcmY86YJiEJJ/5vYhNJ2Aq0gdvDxixXGmr+H3qk=; b=tfgvRX3JfiIQfUbQAfH8k156PPYDnfRKRHndUrkUblgQHo94K3uSFBLuFn4rqyHoI0 Z2spLgo5w7CJsUb5WJyx7gFOvpkP5pTnE3t5XkPPoXgikC89dI871XVDoxa9J94Sbhw9 jUp08AEWlJk3XkFiTa9A2ADoJ4tIu1AnJFnhgbg+QlU086wqxI7iwjCmeRvj1zwA87U9 IKAf1zNIzm/CIR6qy2G6pjAWg8E7pvTzELNHY7wzjKonrTp8ZMlHOJnbUFqjFNAy1KiN ZLAyovLolCOwqXBldZbNMMobCX8u3jGen1Y6UKyq0BMAiSExBCflRYZURQat3hGy730I YcFA== X-Received: by 10.14.219.8 with SMTP id l8mr7939255eep.40.1367133619147; Sun, 28 Apr 2013 00:20:19 -0700 (PDT) Received: from [10.0.0.14] (109-186-115-180.bb.netvision.net.il. [109.186.115.180]) by mx.google.com with ESMTPSA id w52sm4216375eev.12.2013.04.28.00.20.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Apr 2013 00:20:18 -0700 (PDT) Message-ID: <517CCDB0.3060901@gmail.com> Date: Sun, 28 Apr 2013 10:20:16 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Michael Richardson References: <517C0490.9010600@gmail.com> <9116.1367108277@sandelman.ca> In-Reply-To: <9116.1367108277@sandelman.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] IPsecME virtual interim meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 07:20:21 -0000 Hi Michael, formally yes, we only need 2 weeks' notice for a conference call: http://www.ietf.org/iesg/statement/interim-meetings.html But the date is not (yet) set in stone. Let us know if you cannot attend for any reason. Thanks, Yaron On 2013-04-28 03:17, Michael Richardson wrote: > >>>>>> "Yaron" == Yaron Sheffer writes: > Yaron> We propose to meet May 7, at 9:00am PST (16:00 UTC, 12:00 noon EST, 19:00 > Yaron> Israel) for 1 hour. We will publish a bridge number a week > Yaron> before the meeting. > > okay. > Is that enough notice? > > I agree that the problem likely needs be solved in a standard way. > From hannes.tschofenig@gmx.net Sun Apr 28 02:08:06 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461F121F998D for ; Sun, 28 Apr 2013 02:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U2uSdJJXXOC for ; Sun, 28 Apr 2013 02:08:04 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCFB21F9977 for ; Sun, 28 Apr 2013 02:08:04 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MaXUl-1UCnRC0PBx-00K9vD for ; Sun, 28 Apr 2013 11:08:03 +0200 Received: (qmail invoked by alias); 28 Apr 2013 09:08:02 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp027) with SMTP; 28 Apr 2013 11:08:02 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18XooAb+SgXwvNTj6XoJ5nioA0q43d50ebhKp11f0 zr8ptPki/P5jqu Message-ID: <517CE6EE.9010901@gmx.net> Date: Sun, 28 Apr 2013 12:07:58 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Yaron Sheffer References: <517C0490.9010600@gmail.com> <9116.1367108277@sandelman.ca> <517CCDB0.3060901@gmail.com> In-Reply-To: <517CCDB0.3060901@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IPsecme WG , Michael Richardson , hannes.tschofenig@gmx.net Subject: Re: [IPsec] IPsecME virtual interim meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 09:08:06 -0000 Hi Yaron, The issue is that it has to be announcement by the IESG secretary 2 weeks in advance. End of last year I suggested to simplify the rules for virtual interim meetings but my proposal was not well received, see http://list-archives.org/2012/12/03/ietf-ietf-org/simplifying-our-processes-conference-calls/f/1357342837 For some people it seems very important that the call conference call is announced on the IETF announcement list. It appears that there are people who are not on the working group mailing lists but would like to participate in conference calls. For that reason just announcing it on the mailing list does not count. Ciao Hannes On 04/28/2013 10:20 AM, Yaron Sheffer wrote: > Hi Michael, > > formally yes, we only need 2 weeks' notice for a conference call: > http://www.ietf.org/iesg/statement/interim-meetings.html > > But the date is not (yet) set in stone. Let us know if you cannot attend > for any reason. > > Thanks, > Yaron > > On 2013-04-28 03:17, Michael Richardson wrote: >> >>>>>>> "Yaron" == Yaron Sheffer writes: >> Yaron> We propose to meet May 7, at 9:00am PST (16:00 UTC, 12:00 >> noon EST, 19:00 >> Yaron> Israel) for 1 hour. We will publish a bridge number a week >> Yaron> before the meeting. >> >> okay. >> Is that enough notice? >> >> I agree that the problem likely needs be solved in a standard way. >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Sun Apr 28 02:26:24 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A3621F93E9 for ; Sun, 28 Apr 2013 02:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLpCdvNIKZHP for ; Sun, 28 Apr 2013 02:26:24 -0700 (PDT) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id F134021F92C0 for ; Sun, 28 Apr 2013 02:26:23 -0700 (PDT) Received: by mail-ea0-f181.google.com with SMTP id a11so2162628eae.12 for ; Sun, 28 Apr 2013 02:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lKZsAuESv+THaiU0fiUW4Nqw91k3yUf3enR/8WFU/ZU=; b=KGtMCIU6895WwHKVxh9Cif5Z1vJVklFSg5IuCfofHFSjdVtnpBBmN5fpMhR13wD7TY gJRrNo68qKicYajqx0wPeGO+wZsVTBN9TyDI8F3kdwLWxSsA8yYUQMYUKACIt4TsvFzs kY2Jr85ztaxQ7Jb8zbz9zW3pgJ+jxocG/gbAOpX30x7FPXgsagkkbK4mvgqiUC7JAMUf G7NOREmTiS6cFVf37Z0chhmyWAgLBSDpEEyQBM/paD7mJOyOJ0EJ5tp0Afk7wqW6sKGj NuJnVqxWgrzWuG3kSg/fTRXeo1JecQKAy9suAJTLXEiH/md/FqvWGlSD19Gn1MIREE01 m9+g== X-Received: by 10.14.221.67 with SMTP id q43mr64176042eep.20.1367141182916; Sun, 28 Apr 2013 02:26:22 -0700 (PDT) Received: from [10.0.0.14] (109-186-115-180.bb.netvision.net.il. [109.186.115.180]) by mx.google.com with ESMTPSA id v48sm26518128eeg.7.2013.04.28.02.26.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Apr 2013 02:26:22 -0700 (PDT) Message-ID: <517CEB3C.6020405@gmail.com> Date: Sun, 28 Apr 2013 12:26:20 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Hannes Tschofenig References: <517C0490.9010600@gmail.com> <9116.1367108277@sandelman.ca> <517CCDB0.3060901@gmail.com> <517CE6EE.9010901@gmx.net> In-Reply-To: <517CE6EE.9010901@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Michael Richardson Subject: Re: [IPsec] IPsecME virtual interim meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 09:26:25 -0000 It's much simpler than that: I'm fine with the process, I just got my numbers wrong (blush). May 7 is less than 2 weeks in the future. Instead, I'd like to propose Thursday, May 16, same time. Any objections? Thanks, Yaron On 2013-04-28 12:07, Hannes Tschofenig wrote: > Hi Yaron, > > The issue is that it has to be announcement by the IESG secretary 2 > weeks in advance. > > End of last year I suggested to simplify the rules for virtual interim > meetings but my proposal was not well received, see > http://list-archives.org/2012/12/03/ietf-ietf-org/simplifying-our-processes-conference-calls/f/1357342837 > > > For some people it seems very important that the call conference call is > announced on the IETF announcement list. It appears that there are > people who are not on the working group mailing lists but would like to > participate in conference calls. > > For that reason just announcing it on the mailing list does not count. > > Ciao > Hannes > > On 04/28/2013 10:20 AM, Yaron Sheffer wrote: >> Hi Michael, >> >> formally yes, we only need 2 weeks' notice for a conference call: >> http://www.ietf.org/iesg/statement/interim-meetings.html >> >> But the date is not (yet) set in stone. Let us know if you cannot attend >> for any reason. >> >> Thanks, >> Yaron >> >> On 2013-04-28 03:17, Michael Richardson wrote: >>> >>>>>>>> "Yaron" == Yaron Sheffer writes: >>> Yaron> We propose to meet May 7, at 9:00am PST (16:00 UTC, 12:00 >>> noon EST, 19:00 >>> Yaron> Israel) for 1 hour. We will publish a bridge number a week >>> Yaron> before the meeting. >>> >>> okay. >>> Is that enough notice? >>> >>> I agree that the problem likely needs be solved in a standard way. >>> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > From vishwas.ietf@gmail.com Sun Apr 28 21:00:17 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F0421F95EA for ; Sun, 28 Apr 2013 21:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvUed4QorSuH for ; Sun, 28 Apr 2013 21:00:16 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 776AA21F9579 for ; Sun, 28 Apr 2013 21:00:16 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id d10so2995643qca.9 for ; Sun, 28 Apr 2013 21:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=C+f1Ktc/baSNSILYJfgmnCQnctOThNoi6AiRhIrF7tQ=; b=fr8CzuqcZP9PJzAgpp582UuCm+OwekEyvHGkwtkJNwcfSjbrF4ZMVC7VN+82uY+xIV qXGg4jX8mxnXAf+o5t+FD8QLriIB2xSwJC+SvhV2wuXj71FmBKhZ3c3Cyfe0o9cyEtwf zhxBSov91a0A4XlcyZdx3RaZsD4cMgq1H5MeGaGia9g7DsBiKTFt9vwWEmTEYALcFhCi R/HIqhh8d5ha9y2I1E7pq+wEQs/qQa7lkYc540cXu+PONW9J9JT8OzCdQHWuYq1Cw7Su 6LtaQL/rfYLb73/WuaqK8+M13xITN8ygJJ+PhUOVaVluoFgGL3svosfSF8W/wWMHnn4p jFUg== MIME-Version: 1.0 X-Received: by 10.49.104.145 with SMTP id ge17mr45275674qeb.59.1367208015876; Sun, 28 Apr 2013 21:00:15 -0700 (PDT) Received: by 10.229.164.199 with HTTP; Sun, 28 Apr 2013 21:00:15 -0700 (PDT) In-Reply-To: <0C678C21-ECDD-4249-9DBB-B120DEE8613F@vpnc.org> References: <0C678C21-ECDD-4249-9DBB-B120DEE8613F@vpnc.org> Date: Mon, 29 Apr 2013 09:30:15 +0530 Message-ID: From: Vishwas Manral To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b5d8fc51ef20804db77ec8c Cc: IPsecme WG , "maoyu@h3c.com" , Toby Mao Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 04:00:17 -0000 --047d7b5d8fc51ef20804db77ec8c Content-Type: text/plain; charset=ISO-8859-1 Hi Toby, I absolutely understand the rational of where you are coming from. I agree with questions raised by Paul - we need to be characterize the requirement a bit further. I know QoS is important especially if there is an overload of traffic with multiple different use cases. However do we see it any different from any other VPN we currently run? I agree policing, shaping, marking etc are mechanisms to implement QoS and are important. May be the requirement would be to specify the capability to do fine grained QoS on a per peer basis on the Hub. Sounds reasonable? Thanks, Vishwas On Sat, Apr 27, 2013 at 8:27 PM, Paul Hoffman wrote: > These requirements might be useful to add in the next draft, but they need > to be refined. > > On Apr 26, 2013, at 8:10 PM, Toby Mao wrote: > > > The ADVPN solution SHOULD be able to implement Quality of Service (QoS) > to regulate the traffic in the ADVPN topology. > > Why is this statement needed? Do you see situations where an ADVPN > solution would be *prevented* from implementing some sort of QoS because it > was an ADVPN? > > > ADVPN peer SHOULD NOT send excessive traffic to the other members of > ADVPN. > > How would you define "excessive"? Where would that measurement be done? > > > The traffic for each ADVPN peer CAN be measured individually for shaping > and policing. > > Why is this statement needed? Do you see situations where an ADVPN > solution would be *prevented* from measuring individually? > > --Paul Hoffman > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --047d7b5d8fc51ef20804db77ec8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Toby,
=A0
I absolutely underst= and the rational of where you are coming from. I agree with questions raise= d by Paul - we need to be characterize the requirement a bit further.=A0
=A0
I know=A0QoS is important especially if there is an over= load of traffic with multiple different use cases. However do we see it any= different from any other VPN we currently run? I agree policing, shaping, = marking etc=A0are mechanisms to implement QoS and are important. May be the= requirement would be to specify the capability to do fine grained QoS on a= per peer basis on the Hub. Sounds reasonable?
=A0
Thanks,
Vishwas


On Sat, Apr 27, 2013 at 8:27 PM,= Paul Hoffman <paul.hoffman@vpnc.org> wrote:
These requirements might be useful to add in= the next draft, but they need to be refined.

On Apr 26, 2013, at 8:10 PM, Toby Mao <yumao9@gmail.com> wrote:

> The ADVPN solution SHOULD be able to implement Quality of Service (QoS= ) to regulate the traffic in the ADVPN topology.

Why is this statement needed? Do you see situations where an ADVPN so= lution would be *prevented* from implementing some sort of QoS because it w= as an ADVPN?

> ADVPN peer SHOULD NOT send excessive traffic to the other members of A= DVPN.

How would you define "excessive"? Where would that measurem= ent be done?

> The traffic for each ADVPN peer CAN be measured individually for shapi= ng and policing.

Why is this statement needed? Do you see situations where an ADVPN so= lution would be *prevented* from measuring individually?

--Paul Hoffman
_____________________= __________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--047d7b5d8fc51ef20804db77ec8c-- From turners@ieca.com Mon Apr 29 07:48:06 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86DB421F9E39 for ; Mon, 29 Apr 2013 07:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vk59D2Li5dQG for ; Mon, 29 Apr 2013 07:48:06 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.93.243.11]) by ietfa.amsl.com (Postfix) with ESMTP id 09B5621F9E35 for ; Mon, 29 Apr 2013 07:48:06 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id B706B19F7D351; Mon, 29 Apr 2013 09:48:04 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 6F1FA19F7D1A2 for ; Mon, 29 Apr 2013 09:48:04 -0500 (CDT) Received: from [147.28.0.178] (port=49997 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UWpN4-0003j1-PM for ipsec@ietf.org; Mon, 29 Apr 2013 09:48:02 -0500 Message-ID: <517E82EC.3090201@ieca.com> Date: Mon, 29 Apr 2013 08:25:48 -0600 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ipsec@ietf.org References: <20130425210804.2A7F1B1E002@rfc-editor.org> In-Reply-To: <20130425210804.2A7F1B1E002@rfc-editor.org> X-Forwarded-Message-Id: <20130425210804.2A7F1B1E002@rfc-editor.org> Content-Type: multipart/mixed; boundary="------------030406020207080408000403" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [147.28.0.178]:49997 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 12 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [IPsec] Fwd: [Editorial Errata Reported] RFC5282 (3605) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 14:48:06 -0000 This is a multi-part message in MIME format. --------------030406020207080408000403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The following errata was submitted and I'm inclined to mark it approved unless I hear otherwise. spt -------- Original Message -------- Subject: [Editorial Errata Reported] RFC5282 (3605) Date: Thu, 25 Apr 2013 14:08:04 -0700 (PDT) From: RFC Errata System To: black_david@emc.com, mcgrew@cisco.com, iesg@ietf.org CC: wtc@google.com, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC5282, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5282&eid=3605 -------------------------------------- Type: Editorial Reported by: Wan-Teh Chang Section: 10.1.3 Original Text ------------- This algorithm is identical to AEAD_AES_128_GCM (see Section 5.1 of [RFC5116]), except that the tag length, t, is 12, and an authentication tag with a length of 12 octets (64 bits) is used. Corrected Text -------------- This algorithm is identical to AEAD_AES_128_GCM (see Section 5.1 of [RFC5116]), except that the tag length, t, is 12, and an authentication tag with a length of 12 octets (96 bits) is used. Notes ----- "(64 bits)" should be changed to "(96 bits)". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5282 (draft-black-ipsec-ikev2-aead-modes-01) -------------------------------------- Title : Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol Publication Date : August 2008 Author(s) : D. Black, D. McGrew Category : PROPOSED STANDARD Source : IETF - NON WORKING GROUP Area : N/A Stream : IETF Verifying Party : IESG --------------030406020207080408000403 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" --------------030406020207080408000403-- From turners@ieca.com Mon Apr 29 07:48:08 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C47D21F9E4C for ; Mon, 29 Apr 2013 07:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS6kBFdPQxYe for ; Mon, 29 Apr 2013 07:48:07 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.176.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4B38521F9E35 for ; Mon, 29 Apr 2013 07:48:07 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id C654DB7893BE5; Mon, 29 Apr 2013 09:48:06 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id B707FB7893BC2 for ; Mon, 29 Apr 2013 09:48:06 -0500 (CDT) Received: from [147.28.0.178] (port=49998 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UWpN6-0003kD-E3 for ipsec@ietf.org; Mon, 29 Apr 2013 09:48:04 -0500 Message-ID: <517E82FF.2040706@ieca.com> Date: Mon, 29 Apr 2013 08:26:07 -0600 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ipsec@ietf.org References: <20130425210908.2988DB1E002@rfc-editor.org> In-Reply-To: <20130425210908.2988DB1E002@rfc-editor.org> X-Forwarded-Message-Id: <20130425210908.2988DB1E002@rfc-editor.org> Content-Type: multipart/mixed; boundary="------------060008010402020005010008" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [147.28.0.178]:49998 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 13 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [IPsec] Fwd: [Editorial Errata Reported] RFC5282 (3606) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 14:48:08 -0000 This is a multi-part message in MIME format. --------------060008010402020005010008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The following errata was submitted and I'm inclined to mark it approved unless I hear otherwise. spt -------- Original Message -------- Subject: [Editorial Errata Reported] RFC5282 (3606) Date: Thu, 25 Apr 2013 14:09:08 -0700 (PDT) From: RFC Errata System To: black_david@emc.com, mcgrew@cisco.com, iesg@ietf.org CC: wtc@google.com, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC5282, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5282&eid=3606 -------------------------------------- Type: Editorial Reported by: Wan-Teh Chang Section: 10.1.4 Original Text ------------- This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of [RFC5116], except that the tag length, t, is 12 and an authentication tag with a length of 12 octets (64 bits) is used. Corrected Text -------------- This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of [RFC5116], except that the tag length, t, is 12 and an authentication tag with a length of 12 octets (96 bits) is used. Notes ----- "(64 bits)" should be changed to "(96 bits)". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5282 (draft-black-ipsec-ikev2-aead-modes-01) -------------------------------------- Title : Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol Publication Date : August 2008 Author(s) : D. Black, D. McGrew Category : PROPOSED STANDARD Source : IETF - NON WORKING GROUP Area : N/A Stream : IETF Verifying Party : IESG --------------060008010402020005010008 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" --------------060008010402020005010008-- From yaronf.ietf@gmail.com Mon Apr 29 07:54:42 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4911421F9E1B for ; Mon, 29 Apr 2013 07:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8P5ZPw7WaShZ for ; Mon, 29 Apr 2013 07:54:40 -0700 (PDT) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id CDE7221F9E3F for ; Mon, 29 Apr 2013 07:54:30 -0700 (PDT) Received: by mail-ea0-f179.google.com with SMTP id h10so2588941eaj.38 for ; Mon, 29 Apr 2013 07:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Wj5g7L6BcaEEIkFW/ZkMFGdB/YcZ4O9wN5qwwPKM1kc=; b=jMGvhRs44rjvnGi3aEnvecQ+7QDZzlbWrNjuRHMaym2a6Sah/EvImQSwNrXAKlz9Mj M6foqHSBFQ5Mg95rJYlihuLSzkNiRYYa5lfoVirk2jEO7QWdRRGRmfpH325VnKdKk8dC rJxtIOIYsI7RQKbJf/g20tZM+nd8X66wpbJ/XTGf1jkT4eZJoXcOyZ7IT41+5TXOs98a m0anGuYiLRL4zJu4lnS4h1UqHTFcGarYkyGiPtmU9PqGuGMBHTraATwggQXTPlyaAzqn BFTerlhSPWoi59WvqwSogEAEwHz9/tStPIHhSMAK31pzJqUNV3/g/aZH3RAUwsYyuWGv COqg== X-Received: by 10.15.34.199 with SMTP id e47mr101950397eev.35.1367247269143; Mon, 29 Apr 2013 07:54:29 -0700 (PDT) Received: from [192.168.199.139] (diup-241-234.inter.net.il. [213.8.241.234]) by mx.google.com with ESMTPSA id k43sm33296309een.2.2013.04.29.07.54.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Apr 2013 07:54:28 -0700 (PDT) Message-ID: <517E89A2.4040508@gmail.com> Date: Mon, 29 Apr 2013 17:54:26 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Sean Turner References: <20130425210908.2988DB1E002@rfc-editor.org> <517E82FF.2040706@ieca.com> In-Reply-To: <517E82FF.2040706@ieca.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] Fwd: [Editorial Errata Reported] RFC5282 (3606) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 14:54:42 -0000 Yes (to both). Thanks, Yaron On 2013-04-29 17:26, Sean Turner wrote: > The following errata was submitted and I'm inclined to mark it approved > unless I hear otherwise. > > spt > > -------- Original Message -------- > Subject: [Editorial Errata Reported] RFC5282 (3606) > Date: Thu, 25 Apr 2013 14:09:08 -0700 (PDT) > From: RFC Errata System > To: black_david@emc.com, mcgrew@cisco.com, iesg@ietf.org > CC: wtc@google.com, rfc-editor@rfc-editor.org > > The following errata report has been submitted for RFC5282, > "Using Authenticated Encryption Algorithms with the Encrypted Payload of > the Internet Key Exchange version 2 (IKEv2) Protocol". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5282&eid=3606 > > -------------------------------------- > Type: Editorial > Reported by: Wan-Teh Chang > > Section: 10.1.4 > > Original Text > ------------- > This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of > [RFC5116], except that the tag length, t, is 12 and an authentication > tag with a length of 12 octets (64 bits) is used. > > Corrected Text > -------------- > This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of > [RFC5116], except that the tag length, t, is 12 and an authentication > tag with a length of 12 octets (96 bits) is used. > > Notes > ----- > "(64 bits)" should be changed to "(96 bits)". > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5282 (draft-black-ipsec-ikev2-aead-modes-01) > -------------------------------------- > Title : Using Authenticated Encryption Algorithms with the > Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol > Publication Date : August 2008 > Author(s) : D. Black, D. McGrew > Category : PROPOSED STANDARD > Source : IETF - NON WORKING GROUP > Area : N/A > Stream : IETF > Verifying Party : IESG > > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From turners@ieca.com Tue Apr 30 06:39:32 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9BC21F9BC5 for ; Tue, 30 Apr 2013 06:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqyvuMnIT7xP for ; Tue, 30 Apr 2013 06:39:27 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.239.11]) by ietfa.amsl.com (Postfix) with ESMTP id E8A1521F99AE for ; Tue, 30 Apr 2013 06:39:26 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 0A993EC22D64F; Tue, 30 Apr 2013 08:39:02 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id EF539EC22D605 for ; Tue, 30 Apr 2013 08:39:01 -0500 (CDT) Received: from [147.28.0.178] (port=50163 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UXAmE-0004bS-8F; Tue, 30 Apr 2013 08:39:26 -0500 Message-ID: <517FC98D.2020201@ieca.com> Date: Tue, 30 Apr 2013 07:39:25 -0600 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ipsec@ietf.org, draft-ietf-ipsecme-dh-checks@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [147.28.0.178]:50163 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [IPsec] AD review of draft-ietf-ipsecme-dh-checks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 13:39:32 -0000 Nicely written that makes it so much easier to review. Thanks. My comments in no particular order: 1. This document updates RFC 5996. I know one of my fellow ADs will ask why this is an updates before they get to s2. Can we add something to the introduction that says "This document updates RFC 5996 by providing new requirements for all IKEv2 implementations" or something like that. 2. s1/s3 indicates parts are taken from RFC 2412. Did you ask Hilarie if she was willing to grant you rights to publish under the current IETF's TLP in order to avoid including the pre-5378 boilerplate? In a nut shell if you copy text from an RFC before RFC 5378 you gotta ask. If you don't get an answer you need to include some additional boilerplate that says the draft includes pre-5378 text. All you need do is send her a message (I'd try ho@alum.mit.edu) explaining the situation and asking if she'd be willing to grant rights under the TLP (http://trustee.ietf.org/license-info/). Just forward the response to me so I know was done. If you'd rather not bother that's okay but then you need to add the following to the end of the copy right notice section: This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 3. s2.3: RFC 5114 uses y^2 = x^3 + ax + b (mod p) instead of y**2 = x**3 + ax + b mod p maybe best to stick with what's there or explain explain that it's different. 4. s1: r/elliptic curve groups/Elliptic Curve (EC) groups the term gets used later so you might as well introduce it early on 5. s3: r/ECC groups/EC groups or change it in s1 to match this section 5. s2.3/3: Seems like in s3 you added "*" to signify multiplication should you also do that in s2.3 to keep them consistent? 6. Please don't forget to incorporate Johannes suggestion. spt From yaronf.ietf@gmail.com Tue Apr 30 06:50:39 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E8E21F9AD4; Tue, 30 Apr 2013 06:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Do0ib1wQq+f; Tue, 30 Apr 2013 06:50:38 -0700 (PDT) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C74CD21F9AD3; Tue, 30 Apr 2013 06:50:37 -0700 (PDT) Received: by mail-bk0-f45.google.com with SMTP id j4so244542bkw.18 for ; Tue, 30 Apr 2013 06:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=mMqlSLbMtx9opOgrekgmMKSXMRbwhpf0QnLq3APSFb0=; b=Om+WMF2qYuvX6skoVF7KdP1FtRMvO8oLEHwcBmUYJH3gt4YOWhSgS0DsaxqppOiG5r npq3JvQAUfQuchhccBlyRFMEkYNtUyW0GskSUX9cAin276Tr95+RkiI6DZKTxPwvwhyY ueJK32VI8T9tiThatLYRl8m2RsH2RSKAo7/uqJA9CWWIePfWq/sv6oi3lN1/kLG71FHR thCGZYFTSnod955RVG0A/uWJeQdusHZnl9G58c+gTtjIHS1/8oOtOZZHmhHhcENbH014 1MyS126zs+EjF5Qo39N77vRrJ1nK+Rx3TLbT7HbkJCYJxxuaVzMAwEZWh5xXH3QBLP5Y u2BQ== X-Received: by 10.205.21.10 with SMTP id qq10mr22494116bkb.133.1367329836858; Tue, 30 Apr 2013 06:50:36 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-182-143-212.red.bezeqint.net. [79.182.143.212]) by mx.google.com with ESMTPSA id cv9sm8158238bkb.5.2013.04.30.06.50.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Apr 2013 06:50:35 -0700 (PDT) Message-ID: <517FCC2A.8060904@gmail.com> Date: Tue, 30 Apr 2013 16:50:34 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: IPsecme WG , iesg-secretary@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] IPsecME virtual interim meeting (revised date) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 13:50:39 -0000 Dear IPsec folks, The ipsecme working group is chartered to come up with a solution for transporting long IKEv2 messages over networks that do not perform IP fragmentation correctly, and as a result drop overly long messages, usually IKE_AUTH messages. Our original plan was to base the solution on IKE-over-TCP, however the author of this draft announced that he now prefers a different solution, similar to the (non-standard) IKEv1 Fragmentation payload that was implemented by several vendors (see http://msdn.microsoft.com/en-us/library/cc233251.aspx). We do not want to end up with a common but non-standard solution in IKEv2, which would practically guarantee interoperability issues. As a further data point, we are aware of IPR issues with Microsoft's solution; we have tried to clarify the issue with Microsoft but have not been successful yet. We would like to invite the group to a Virtual Interim Meeting (a.k.a. conference call), to discuss this problem. Potential outcomes of the meeting include: - The group decides that this is not an important problem. - This is an important problem and we have 1-2 people committed to author a draft along the lines of the non-standard IKEv1 mechanism. - This is an important problem and the group is happy to adopt draft-smyslov-ipsecme-ikev2-fragmentation (which solves the same problem in a somewhat different fashion). - The group still prefers IKE-over-TCP and there are committed authors to continue work on that draft. We propose to meet Thursday, May 16, at 9:00am PST (16:00 UTC, 12:00 noon EST, 19:00 Israel) for 1 hour. We will publish a bridge number a week before the meeting. Please let us know if the date/time absolutely doesn't work for you. We welcome and invite discussion of these issues on the mailing list before the meeting. Thanks, Paul and Yaron From turners@ieca.com Tue Apr 30 07:53:19 2013 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFF921F9B84 for ; Tue, 30 Apr 2013 07:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVah+BA0wNwv for ; Tue, 30 Apr 2013 07:53:07 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.41.242.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2A521F9AB9 for ; Tue, 30 Apr 2013 07:53:02 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 8BDC2C732526; Tue, 30 Apr 2013 09:52:53 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id DCD50C7320FA for ; Tue, 30 Apr 2013 09:52:52 -0500 (CDT) Received: from [128.107.52.236] (port=50255 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UXBvN-000465-ES; Tue, 30 Apr 2013 09:52:57 -0500 Message-ID: <517FDAC7.8080701@ieca.com> Date: Tue, 30 Apr 2013 08:52:55 -0600 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ipsec@ietf.org, draft-ietf-ipsecme-ad-vpn-problem@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [128.107.52.236]:50255 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [IPsec] AD re-review of draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 14:53:20 -0000 Please incorporate the QoS issue brought up by Toby. I'd like to make sure we have everything in the draft that the WG wants before issuing the WGLC. I also think the TSV/RTG directorates/ADs will be interested in that. Can you explain the rationale for the following the changes to requirement #5; I'm just not following it: OLD: 5. One ADVPN peer MUST NOT be able to impersonate another ADVPN peer. NEW: 5. Any of the ADVPN Peers MUST NOT have a way to get the long term authentication credentials for any other ADVPN Peers. The compromise of an Endpoint MUST NOT affect the security of communications between other ADVPN Peers. The compromise of a Gateway SHOULD NOT affect the security of the communications between ADVPN Peers not associated with that Gateway. Is the first sentence still saying basically: "peers can't impersonate peers"? Nits: - sec 1.1: Need to add what an ADVPN is and expand the acronym - sec 4/1.1: The terms allied and federated environment kind of come out of nowhere. Please add them to s1.1. I just to make sure it's clear what the difference is between the two.