From kivinen@iki.fi Mon Nov 2 06:13:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B37E3A6806 for ; Mon, 2 Nov 2009 06:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZ538YQddo8S for ; Mon, 2 Nov 2009 06:13:24 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 11F2C3A659B for ; Mon, 2 Nov 2009 06:13:23 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id nA2EDbbh005849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2009 16:13:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nA2EDakG003003; Mon, 2 Nov 2009 16:13:36 +0200 (EET) 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: <19182.59664.628328.76563@fireball.kivinen.iki.fi> Date: Mon, 2 Nov 2009 16:13:36 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <82DFB96E88E54DE98E9B6B5F766C3EB8@trustworks.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 10 min Cc: ipsec@ietf.org, Valery Smyslov Subject: Re: [IPsec] Fw: Preshared key authentication in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 14:13:25 -0000 Paul Hoffman writes: > At 9:58 AM +0300 10/30/09, Valery Smyslov wrote: > >Hi all, > > > >I'd like to reiterate my early message, which I haven't got answer to. > >My concerns are: > > > >1. How padding pre-sahred key with string "Key Pad for IKEv2" > > could help to avoid storing pre-shared key in IKE implementation > > if prf is not known untill IKE_SA_INIT exchange is finished? > > The PRF (or set of PRFs) is known by the receiving party. If the two > parties always only use one PRF, it is known. The padding is not a > universal solution for the reasons you give, but it works in the > common case of peers who know each other's crypto choices. As Paul said recipient knows which algorithms it support, and it can store the pre-shared key using all of those algoritms to its database. I.e. if it supports PRF_HMAC_SHA1, and PRF_AES128_XCBC then it needs to calculate the PRF(Shared Secret, "Key Pad for IKEv2") using those two PRFs and store both of the results to its authentication database. This way if someone manages to get the authentication database it cannot directly know the Shared Secret, it just knows the hash, and cannot use the Shared Secret in any other protocols. > >2. It is a bit unclear whether EAP generated key should also > > be padded before use in IKE, or used directly. > > I'm pretty sure the key is used in its PRF form, not in its "as is" > form, but I would want to hear from one or two implementers on that. As section 2.16 refers to the 2.15 and says the AUTH payloads in messages 7 and 8 using the syntax for shared secrets specified in section 2.15, and section 2.15 tells that this padding is used, so I think it should be used always (and by quick look in our code seemed to use the same format for both cases). -- kivinen@iki.fi From kivinen@iki.fi Mon Nov 2 06:18:42 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53B5E28C0EF for ; Mon, 2 Nov 2009 06:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpU5K0PtQfqX for ; Mon, 2 Nov 2009 06:18:41 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 28DC428C0DB for ; Mon, 2 Nov 2009 06:18:40 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id nA2EIxWj003092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2009 16:18:59 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nA2EIxBD006100; Mon, 2 Nov 2009 16:18:59 +0200 (EET) 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: <19182.59987.327545.475873@fireball.kivinen.iki.fi> Date: Mon, 2 Nov 2009 16:18:59 +0200 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAC@il-ex01.ad.checkpoint.com> <19178.63776.974040.367597@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: IPsecme WG Subject: Re: [IPsec] #120: CA indication with cert req - allowed types X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 14:18:42 -0000 David Wierbowski writes: > > So the text most likely should say that "For other values the > > certificate authority field contents is not defined, and can be > > anything (or empty) until specifications that specify their contents > > is published." > I do not think they can be anything. I think they need to be empty until > specifications that specify their contents are published. Thats fine for the sending side, but for recipient it is very hard to know when specification has been published, thus recipient should not reject (or crash) in case it receives certreq having type of x and having something inside the certificate authority field, even though no specification was available when that implementation was created. Thats why I think it would be safer to say they can be anything, or perhaps more accurate should say they MUST be sent as empty, but recipient MUST be able to handle CERTREQ regardless what there is in the certificate authority field. But on the other hand I do not think we want to add new MUSTs/SHOULDs etc here, but just say they can be anything (including empty) should be enough. -- kivinen@iki.fi From kivinen@iki.fi Mon Nov 2 06:25:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A19728C110 for ; Mon, 2 Nov 2009 06:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFAY-UW9UirK for ; Mon, 2 Nov 2009 06:25:24 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 43D0A28C10B for ; Mon, 2 Nov 2009 06:25:24 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id nA2EPekK004789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2009 16:25:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nA2EPeoR003807; Mon, 2 Nov 2009 16:25:40 +0200 (EET) 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: <19182.60388.220635.971305@fireball.kivinen.iki.fi> Date: Mon, 2 Nov 2009 16:25:40 +0200 From: Tero Kivinen To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774E7F6F461F@NOK-EUMSG-01.mgdnok.nokia.com> References: <19165.48619.530034.469960@fireball.kivinen.iki.fi> <19168.6686.368531.842814@fireball.kivinen.iki.fi> <808FD6E27AD4884E94820BC333B2DB774E7F6F461F@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: ipsec@ietf.org, sheila.frankel@nist.gov Subject: Re: [IPsec] RFC4307 & ENCR_NULL & USGv6 profile & Roadmap document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 14:25:25 -0000 Pasi.Eronen@nokia.com writes: > I think you're correct that RFC 4307 has a bug: ENCR_NULL > should be MUST NOT, instead of MAY (note that ENCR_NULL > in 4305/4835 is MUST). Go ahead and submit an errata > about this! Done. -- kivinen@iki.fi From svanru@gmail.com Mon Nov 2 06:40:33 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C0413A6885 for ; Mon, 2 Nov 2009 06:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.627 X-Spam-Level: X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_20=-0.74, J_CHICKENPOX_36=0.6, XMAILER_MIMEOLE_OL_7533E=0.513] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ots8bUW9SrGD for ; Mon, 2 Nov 2009 06:40:32 -0800 (PST) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by core3.amsl.com (Postfix) with ESMTP id D1E2F3A6817 for ; Mon, 2 Nov 2009 06:40:31 -0800 (PST) Received: by ewy18 with SMTP id 18so4451792ewy.43 for ; Mon, 02 Nov 2009 06:40:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:cc :references:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=tP48V8DYFx+4tWHYDeeq01mIRHx6ga4rvuy+q0Ep9xg=; b=Y99/dg1FMwAm1dzBxUOidtGrT4S366DFxSsZyCa4eqBaoVP6+vmp5Rjdi9cNIBSB60 da+rjxqaMfc26J4csLpe/SlDjvSVTIDBL3jSSLWKmG4NKvb07vcKvmyQW6vTmDrTnFy2 6B2w9NNHb+gx/OW8Cgrj9VDOCWyquraEztD/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=MUixWhA8y31JRivBw7+/LJHKSwD8F2grd2WcMrUzNe8nCSDk3KW4gUchQJUCP2ewNr NsIPf/wFqVAjU5Uf49gSwiUp1u4BSaPbrAiVX+T77++LcqGT5ZfBKzQJK24XyvPiFgLS shwBG1GGU/GDz9EGYBSL0Gea2L7WxjDHqE0ws= Received: by 10.216.93.6 with SMTP id k6mr4731834wef.89.1257172846980; Mon, 02 Nov 2009 06:40:46 -0800 (PST) Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 10sm15368657eyz.43.2009.11.02.06.40.44 (version=SSLv3 cipher=RC4-MD5); Mon, 02 Nov 2009 06:40:45 -0800 (PST) Message-ID: <1A567F18E9E144989D2F06830DB24CC6@trustworks.com> From: "Valery Smyslov" To: "Tero Kivinen" , "Paul Hoffman" References: <82DFB96E88E54DE98E9B6B5F766C3EB8@trustworks.com> <19182.59664.628328.76563@fireball.kivinen.iki.fi> Date: Mon, 2 Nov 2009 17:40:57 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4963.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 Cc: ipsec@ietf.org Subject: Re: [IPsec] Fw: Preshared key authentication in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 14:40:33 -0000 Hi Paul and Tero, thank you for your answers. > > The PRF (or set of PRFs) is known by the receiving party. If the two > > parties always only use one PRF, it is known. The padding is not a > > universal solution for the reasons you give, but it works in the > > common case of peers who know each other's crypto choices. > > As Paul said recipient knows which algorithms it support, and it can Sometimes it doesn't. I refer to implementations with pluggable crypto, when crypto providers are separated from IKE implementation and can be added/removed later. > store the pre-shared key using all of those algoritms to its database. > I.e. if it supports PRF_HMAC_SHA1, and PRF_AES128_XCBC then it needs > to calculate the PRF(Shared Secret, "Key Pad for IKEv2") using those > two PRFs and store both of the results to its authentication database. With this approach in case of pluggable crypto user must re-enter shared secret after any change in crypto configuration. It's not a big deal, just a bit inconvinient... Regards, Smyslov Valery. From kivinen@iki.fi Mon Nov 2 06:43:29 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF56628C14F for ; Mon, 2 Nov 2009 06:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggExzougp3+I for ; Mon, 2 Nov 2009 06:43:29 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id BA31828C0FC for ; Mon, 2 Nov 2009 06:43:28 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id nA2Ehh3d005234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2009 16:43:43 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nA2EhhVM007432; Mon, 2 Nov 2009 16:43:43 +0200 (EET) 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: <19182.61471.169867.876583@fireball.kivinen.iki.fi> Date: Mon, 2 Nov 2009 16:43:43 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <1A567F18E9E144989D2F06830DB24CC6@trustworks.com> References: <82DFB96E88E54DE98E9B6B5F766C3EB8@trustworks.com> <19182.59664.628328.76563@fireball.kivinen.iki.fi> <1A567F18E9E144989D2F06830DB24CC6@trustworks.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: ipsec@ietf.org, Paul Hoffman Subject: Re: [IPsec] Fw: Preshared key authentication in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 14:43:29 -0000 Valery Smyslov writes: > Hi Paul and Tero, > > thank you for your answers. > > > > The PRF (or set of PRFs) is known by the receiving party. If the two > > > parties always only use one PRF, it is known. The padding is not a > > > universal solution for the reasons you give, but it works in the > > > common case of peers who know each other's crypto choices. > > > > As Paul said recipient knows which algorithms it support, and it can > > Sometimes it doesn't. I refer to implementations with pluggable > crypto, when crypto providers are separated from IKE implementation > and can be added/removed later. Then you need to store the original shared key not the hashed version of it. -- kivinen@iki.fi From mglt.ietf@gmail.com Thu Nov 5 06:48:39 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93D1C3A6ACA; Thu, 5 Nov 2009 06:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30WEcuWXjdsx; Thu, 5 Nov 2009 06:48:38 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.189]) by core3.amsl.com (Postfix) with ESMTP id E1DFE3A6AB7; Thu, 5 Nov 2009 06:48:37 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id e6so19545gvc.15 for ; Thu, 05 Nov 2009 06:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=UosYlT4cHZFLu8YCDFkE/F3I0RvHsKXU2hoMJVh1X24=; b=pngIvEJ9EKW2WCeqnPdbP9qyOxhyHLI1a74vJHv/UFfgbm6Z4SRZX2QoFS7Cts/lHD /fB21F5foWL0iXsoyhmMCTyX2dEIylbAevSBklGb6xJ9zszuqMPicOs/eztZ1ZD8iEOQ q1XBPBP6cNalDEWtag8wTQhxthF7Xtp4kDtoE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=j65pGnmFugRE44wPvn8be8OVe08ldZqqtH1UBzko/l/WI9GzTcz+BeN8n4ucFiPTM8 NqcMY3SDq2nzNbsj6TBfeXZKCiVdppF/eYWb2fYW9t/C8f6KQtFe9S2v6w2O7SroOO0O EcFveLk0O+v+Z2lokiKxGLyj8L/c/Z76K22UY= MIME-Version: 1.0 Received: by 10.102.197.14 with SMTP id u14mr1179348muf.39.1257432536138; Thu, 05 Nov 2009 06:48:56 -0800 (PST) In-Reply-To: References: <51eafbcb0910210129x60cf00eek4ee53df746e515a8@mail.gmail.com> Date: Thu, 5 Nov 2009 15:48:56 +0100 Message-ID: <51eafbcb0911050648u61f05eaamd6b94e608109e392@mail.gmail.com> From: Daniel Migault To: =?ISO-8859-1?Q?Michael_T=FCxen?= Content-Type: multipart/alternative; boundary=0016364d274ba544800477a0d390 Cc: ipsec@ietf.org, multipathtcp@ietf.org, mif@ietf.org Subject: Re: [IPsec] [multipathtcp] IPsec multihoming and mobility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 14:48:39 -0000 --0016364d274ba544800477a0d390 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael, Thanks for your comment, I appreciate your feed back. Sections of the requirements draft on SCTP, SHIM6 should be filled, and I will mention RFC3554 in the SCTP section. In both drafts we consider only IKEv2, so I don't think RFC3554 is really relevant. I am not an expert on IKEv1, but it looks that features introduce= d by RFC3554 are not longer necessary since with IKEv2 since IKEv2 provides the ability to negotiate multiple Traffic Selector, and TS are not associated to the ID Payload anymore. On the other hand IKEv2 or IKEv1 and RFC3554 does not enable to modify the Traffic Selectors of the Security Association. And this is one of the thing we address in the drafts. Regards, Daniel On Wed, Oct 21, 2009 at 3:44 PM, Michael T=FCxen < Michael.Tuexen@lurchi.franken.de> wrote: > Hi Daniel, > > have you looked at > http://www.ietf.org/rfc/rfc3554.txt > > Best regards > Michael > > > On Oct 21, 2009, at 10:29 AM, Daniel Migault wrote: > > Hi folks, >> >> We are currently working on IPsec issues and multihoming. Here are our >> starting work with a presentation of scenarios and requirements we addre= ss, >> as well as the design of an extension to MOBIKE. >> >> Scenarios and Requirements : >> http://tools.ietf.org/html/draft-mglt-ipsec-mm-requirements-00 >> >> Protocol Design : >> http://tools.ietf.org/html/draft-mglt-ipsec-mm-mobikex-00 >> >> We are currently working implementing it, and looking on how other >> multihoming protocol can benefit from it. >> >> Feed backs and comments are really appreciated. >> >> Regards, >> >> Daniel >> >> >> -- >> Daniel Migault >> Orange Labs -- Security >> +33 6 70 72 69 58 >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> > > --=20 Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --0016364d274ba544800477a0d390 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael,

Thanks for your comment, I appreciate your feed back. <= br>
Sections of the requirements draft on SCTP, SHIM6 should be filled, = and I will mention RFC3554 in the SCTP section.

In both drafts we c= onsider only IKEv2, so I don't think RFC3554 is really relevant. I am n= ot an expert on IKEv1, but it looks that features introduced by RFC3554 are= not longer necessary since with IKEv2 since IKEv2 provides the ability to = negotiate multiple Traffic Selector, and TS are not associated to the ID Pa= yload anymore.

On the other hand IKEv2 or IKEv1 and RFC3554 does not=A0 enable to modi= fy the Traffic Selectors of the Security Association. And this is one of th= e thing we address in the drafts.

Regards,

Daniel

On Wed, Oct 21, 2009 at 3:44 PM, Michael T=FCxen= <= Michael.Tuexen@lurchi.franken.de> wrote:
Hi Daniel,

have you looked at
http://ww= w.ietf.org/rfc/rfc3554.txt

Best regards
Michael


On Oct 21, 2009, at 10:29 AM, Daniel Migault wrote:

=
Hi folks,

We are currently working on IPsec issues and multihoming. Here are our star= ting work with a presentation of scenarios and requirements we address, as = well as the design of an extension to MOBIKE.

Scenarios and Requirements :
http://tools.ietf.org/html/draft-mglt-ipsec-mm-requiremen= ts-00

Protocol Design :
http://tools.ietf.org/html/draft-mglt-ipsec-mm-mobikex-00<= br>
We are currently working implementing it, and looking on how other multihom= ing protocol can benefit from it.

Feed backs =A0and comments are really appreciated.

Regards,

Daniel


--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://www.ietf.org/mailman/listinfo/multipathtcp




--
Daniel Migault
Orang= e Labs -- Security
+33 6 70 72 69 58
--0016364d274ba544800477a0d390-- From rfc-editor@rfc-editor.org Thu Nov 5 16:08:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9125828C165; Thu, 5 Nov 2009 16:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.933 X-Spam-Level: X-Spam-Status: No, score=-16.933 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTLo3u1bvcAi; Thu, 5 Nov 2009 16:08:35 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 9AAE628C149; Thu, 5 Nov 2009 16:08:35 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id E4A9F3607E5; Thu, 5 Nov 2009 16:05:14 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20091106000514.E4A9F3607E5@bosco.isi.edu> Date: Thu, 5 Nov 2009 16:05:14 -0800 (PST) Cc: ipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [IPsec] RFC 5685 on Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 00:08:36 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5685 Title: Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) Author: V. Devarapalli, K. Weniger Status: Standards Track Date: November 2009 Mailbox: vijay@wichorus.com, kilian.weniger@googlemail.com Pages: 15 Characters: 35100 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsecme-ikev2-redirect-13.txt URL: http://www.rfc-editor.org/rfc/rfc5685.txt The Internet Key Exchange Protocol version 2 (IKEv2) is a protocol for setting up Virtual Private Network (VPN) tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. This document defines an IKEv2 extension that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent. [STANDARDS TRACK] This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From mcgrew@cisco.com Fri Nov 6 08:21:55 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39F33A683A for ; Fri, 6 Nov 2009 08:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdf+ZJU9Cw7U for ; Fri, 6 Nov 2009 08:21:54 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BBD413A682D for ; Fri, 6 Nov 2009 08:21:54 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG/c80qrR7Ht/2dsb2JhbADFSpd4hD0EgWc X-IronPort-AV: E=Sophos;i="4.44,694,1249257600"; d="scan'208";a="267376901" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 06 Nov 2009 16:22:15 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA6GMDnE004955; Fri, 6 Nov 2009 16:22:15 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 17:22:13 +0100 Received: from stealth-10-32-254-213.cisco.com ([10.32.254.213]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 17:22:11 +0100 Message-Id: <3A070C8D-782B-4CC2-B48E-0DA63EC5A4ED@cisco.com> From: David McGrew To: Paul Hoffman , Yaron Sheffer , ipsec@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 6 Nov 2009 08:22:09 -0800 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 06 Nov 2009 16:22:13.0102 (UTC) FILETIME=[4C29B8E0:01CA5EFD] Subject: [IPsec] Updating IPsec algorithm requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 16:21:55 -0000 Hi Paul, Yaron, and IPsec ME WG participants, I would like to propose an update to the algorithm requirements, as outlined below. regards, David -- Updating IPsec Algorithm Requirements AES in Galois/Counter Mode of operation (AES-GCM)[RFC4106][RFC4543] [RFC5282] should be recommended or required by the IPsec standards, because it provides higher efficiency than currently recommended algorithms with equivalent security, and is recommended by newer IPsec profiles [RFC4869]. Currently, AES in Counter Mode (AES-CTR)[RFC3686] is recommended as a SHOULD in "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835. AES-CTR is a useful algorithm because it admits efficient high speed implementations. However, it provides no authentication. From RFC3686: "With AES-CTR, it is trivial to use a valid ciphertext to forge other (valid to the decryptor) ciphertexts. Thus, it is equally catastrophic to use AES-CTR without a companion authentication function. Implementations MUST use AES-CTR in conjunction with an authentication function, such as HMAC-SHA-1-96 [HMAC-SHA]." Unfortunately, none of the authentication algorithms currently defined for IPsec (HMAC, XCBC-MAC) admit efficient high speed implementations. Thus the need for authentication undermines the efficiency of AES-CTR. AES-GCM was designed specifically to overcome this problem. It is a "combined mode" in the ESP sense [RFC4303], that provides both encryption and authentication. Internally, it combines AES-CTR with an authentication mechanism that can be efficiently implemented at high data rates. At the time that RFC 4835 was published (April 2007), there was not yet a stable normative reference for AES-GCM. This may have motivated the IPsec community to not rely on that algorithm in its recommendations. But November 2007 saw the publication of NIST SP 800-38D, "Recommendation for Block Cipher Modes of Operation: Galois/ Counter Mode (GCM) and GMAC", which removes any such concern. An additional change in favor of AES-GCM is its wide adoption by crypto hardware and software suppliers. It is especially important that AES-GCM be recommended over the use of AES-CTR with HMAC-SHA-256, because the latter combination of algorithms is considerably less efficient, and the former algorithm meets the security requirements. The IPsec ME Working Group should set a policy that makes it clear that HMAC-SHA-256 is not required for future implementations. HMAC-SHA-1 is believed to be secure (recall the "No Need for SHA-2" Open Letter http://www.vpnc.org/ietf-ipsec/02.ipsec/msg01840.html), but as the industry moves away from SHA1, HMAC-SHA-256 may be the first algorithm that comes to mind for some users of IPsec. Thus a policy clarification by the WG is essential. This should be done as soon as is practical, because the transition away from SHA-1 for digital signatures is already underway; many users plan to have that transition completed by the end of 2010 (see NIST SP 800-107, for example). AES-CBC and HMAC-SHA1 are valuable because those algorithms are widely implemented. This suggests that it makes sense to rely on those algorithms as mandatory-to-implement until such time as it becomes necessary or desirable to stop using HMAC-SHA1. AES-GCM should replace this combination of algorithms, when that time comes. From yaronf@checkpoint.com Fri Nov 6 09:53:09 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 952343A6946 for ; Fri, 6 Nov 2009 09:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48RumlUXdac7 for ; Fri, 6 Nov 2009 09:53:08 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 222D23A68F7 for ; Fri, 6 Nov 2009 09:53:07 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nA6HrTc6015177 for ; Fri, 6 Nov 2009 19:53:29 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 6 Nov 2009 19:53:33 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Fri, 6 Nov 2009 19:53:31 +0200 Thread-Topic: RFC 5685 on Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) Thread-Index: AcpedWniBLYGErp3ReWSoDx9L4qBRQAlFbLg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF872B99A@il-ex01.ad.checkpoint.com> References: <20091106000514.E4A9F3607E5@bosco.isi.edu> In-Reply-To: <20091106000514.E4A9F3607E5@bosco.isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] RFC 5685 on Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 17:53:09 -0000 This is the first RFC produced by the IPsecME working group. Congratulation= s and a big thank you to Vijay and Kilian! Yaron > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org > Sent: Friday, November 06, 2009 2:05 > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: ipsec@ietf.org; rfc-editor@rfc-editor.org > Subject: RFC 5685 on Redirect Mechanism for the Internet Key Exchange > Protocol Version 2 (IKEv2) >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 5685 >=20 > Title: Redirect Mechanism for the Internet > Key Exchange Protocol Version 2 (IKEv2) > Author: V. Devarapalli, K. Weniger > Status: Standards Track > Date: November 2009 > Mailbox: vijay@wichorus.com, > kilian.weniger@googlemail.com > Pages: 15 > Characters: 35100 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-ipsecme-ikev2-redirect-13.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc5685.txt >=20 > The Internet Key Exchange Protocol version 2 (IKEv2) is a protocol > for setting up Virtual Private Network (VPN) tunnels from a remote > location to a gateway so that the VPN client can access services in > the network behind the gateway. This document defines an IKEv2 > extension that allows an overloaded VPN gateway or a VPN gateway that > is being shut down for maintenance to redirect the VPN client to > attach to another gateway. The proposed mechanism can also be used > in Mobile IPv6 to enable the home agent to redirect the mobile node > to another home agent. [STANDARDS TRACK] >=20 > This document is a product of the IP Security Maintenance and Extensions > Working Group of the IETF. >=20 > This is now a Proposed Standard Protocol. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see http://www.rfc- > editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > USC/Information Sciences Institute >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce >=20 > Scanned by Check Point Total Security Gateway. From Paul_Koning@Dell.com Fri Nov 6 11:08:01 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39C1E3A69DD for ; Fri, 6 Nov 2009 11:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6B9DmJXiRpM for ; Fri, 6 Nov 2009 11:08:00 -0800 (PST) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by core3.amsl.com (Postfix) with ESMTP id 5CB873A683A for ; Fri, 6 Nov 2009 11:08:00 -0800 (PST) X-Loopcount0: from 12.110.134.31 X-IronPort-AV: E=Sophos;i="4.44,695,1249275600"; d="scan'208";a="420123507" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 06 Nov 2009 13:08:23 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19188.29670.319220.85945@pkoning-laptop.lab.equallogic.com> Date: Fri, 6 Nov 2009 14:07:18 -0500 From: Paul Koning To: mcgrew@cisco.com References: <3A070C8D-782B-4CC2-B48E-0DA63EC5A4ED@cisco.com> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-OriginalArrivalTime: 06 Nov 2009 19:07:22.0869 (UTC) FILETIME=[5ED82A50:01CA5F14] Cc: ipsec@ietf.org Subject: Re: [IPsec] Updating IPsec algorithm requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 19:08:01 -0000 Excerpt of message (sent 6 November 2009) by David McGrew: > Hi Paul, Yaron, and IPsec ME WG participants, > > I would like to propose an update to the algorithm requirements, as > outlined below. > ... > Currently, AES in Counter Mode (AES-CTR)[RFC3686] is recommended as a > SHOULD in "Cryptographic Algorithm Implementation Requirements for > Encapsulating Security Payload (ESP) and Authentication Header (AH)", > RFC 4835. AES-CTR is a useful algorithm because it admits efficient > high speed implementations. However, it provides no authentication. ... and therefore no confidentiality either, if used by itself, via the Bellovin attack. > From RFC3686: "With AES-CTR, it is trivial to use a valid ciphertext > to forge other (valid to the decryptor) ciphertexts. Thus, it is > equally catastrophic to use AES-CTR without a companion authentication > function. Implementations MUST use AES-CTR in conjunction with an > authentication function, such as HMAC-SHA-1-96 [HMAC-SHA]." > Unfortunately, none of the authentication algorithms currently defined > for IPsec (HMAC, XCBC-MAC) admit efficient high speed > implementations. Thus the need for authentication undermines the > efficiency of AES-CTR. > > AES-GCM was designed specifically to overcome this problem. ... > > It is especially important that AES-GCM be recommended over the use of > AES-CTR with HMAC-SHA-256, ... I agree. For the reasons you gave, and also to remove the temptation to run AES-CTR without authentication for performance reasons, even though the standard says not to do this. paul From paul.hoffman@vpnc.org Fri Nov 6 14:09:17 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48AF83A67FA for ; Fri, 6 Nov 2009 14:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.581 X-Spam-Level: X-Spam-Status: No, score=-5.581 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sco0ar5C42La for ; Fri, 6 Nov 2009 14:09:16 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 5C85C3A6909 for ; Fri, 6 Nov 2009 14:09:16 -0800 (PST) Received: from [10.0.0.148] ([219.163.11.104]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nA6M9XXH066634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 15:09:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19188.29670.319220.85945@pkoning-laptop.lab.equallogic.com> References: <3A070C8D-782B-4CC2-B48E-0DA63EC5A4ED@cisco.com> <19188.29670.319220.85945@pkoning-laptop.lab.equallogic.com> Date: Sat, 7 Nov 2009 07:09:32 +0900 To: Paul Koning , mcgrew@cisco.com From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ipsec@ietf.org Subject: Re: [IPsec] Updating IPsec algorithm requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 22:09:17 -0000 At 2:07 PM -0500 11/6/09, Paul Koning wrote: >I agree. For the reasons you gave, and also to remove the temptation >to run AES-CTR without authentication for performance reasons, even >though the standard says not to do this. It is usually not temptation, but by mistake, aided by poor UI practice on the parts of >90% of VPN vendors. That is, I have found few vendors in the VPNC lab that *prevent* you from running with null authentication. Having a combined mode in the mix, particularly if it is the required algorithm, would reduce the prevalence of this kind of mistake. --Paul Hoffman, Director --VPN Consortium From rdv@sfc.wide.ad.jp Sat Nov 7 20:17:42 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E8723A6837 for ; Sat, 7 Nov 2009 20:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-48ohrcq3VU for ; Sat, 7 Nov 2009 20:17:41 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id CD96E3A682B for ; Sat, 7 Nov 2009 20:17:40 -0800 (PST) Received: from host-17-84.meeting.ietf.org (host-17-84.meeting.ietf.org [133.93.17.84]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 058CB4C5B2 for ; Sun, 8 Nov 2009 13:17:59 +0900 (JST) Message-Id: <30676E84-F190-4DDA-8785-E1880D8422D0@sfc.wide.ad.jp> From: Rodney Van Meter To: ipsec@ietf.org Content-Type: multipart/signed; boundary=Apple-Mail-32-173730866; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 8 Nov 2009 13:16:44 +0900 X-Mailer: Apple Mail (2.936) Subject: [IPsec] IPsec with QKD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 04:17:42 -0000 --Apple-Mail-32-173730866 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Shota Nagayama and I have been experimenting with using keys generated by quantum key distribution (QKD) devices to key IPsec tunnels. (The devices we used were borrowed from NEC, but we don't claim to represent them.) We have written an I-D on the protocol modifications necessary, and are here in Hiroshima to discuss it. https://datatracker.ietf.org/drafts/draft-nagayama-ipsecme-ipsec-with-qkd/ For those who are interested, we have created a mailing list, which you can join: https://aqua.sfc.wide.ad.jp/mailman/listinfo/ipsecwithqkd Products for QKD already exist, and various experiments are underway, including a large one called SECOQC in Europe; the Japanese and U.S. governments also have sunk a lot of money into QKD. The European effort, in particular, is committed to standardizing many parts of QKD through the ITU. Although the existing products do not yet support IKE/IPsec (to the best of my knowledge, though things change), at least two implementations already exist, ours and BBN's (as described in Chip Elliott's SIGCOMM 2003 paper), as well as a recent paper by Sheila Frankel and collaborators at NIST. Now seems to be the time to create at least an experimental RFC on the topic, to minimize confusion and incompatibility; IETF, rather than ITU, would definitely be the place to standardize the changes to IKE. Although our protocol is unfortunately incompatible with BBN's, Chip has encouraged us to pursue an RFC. At a protocol level, the changes are actually minimal; essentially, the addition of two types of Payload Headers. There may still be some corners in the contents of messages and assumptions required to guarantee security; we look forward to hashing some of those out in person. Please, track us down here in Hiroshima; Shota and I will both be here until after the IPSECME meeting on Thursday. --Rod Rodney Van Meter assistant professor, Faculty of Environment and Information Studies, Keio University, Japan rdv@sfc.wide.ad.jp http://web.sfc.keio.ac.jp/~rdv/ http://www.sfc.wide.ad.jp/IRL/ --Apple-Mail-32-173730866 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKYDCCBFEw ggI5oAMCAQICAh+5MA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAkpQMRUwEwYDVQQKEwxXSURF IFByb2plY3QxHzAdBgNVBAMTFm1lbWJlcnMgb3JpZW50ZWQgQ0EgMDIwHhcNMDkwNjA4MDYzMjM0 WhcNMTEwNjMwMjM1OTU5WjBWMQswCQYDVQQGEwJKUDEVMBMGA1UEChMMV0lERSBQcm9qZWN0MQ0w CwYDVQQDEwQxMTAxMSEwHwYJKoZIhvcNAQkBFhJyZHZAc2ZjLndpZGUuYWQuanAwgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAMY/jkLuPVypmmFdv3yFs3G1Cf9n1q2y8ZHsBVsdHBu1/Aa2z8QJ qPD3T9itH2olwHeHbZrihgj6Yq3pgK47EJlx/IpUR3xEdfmYbgzZ+w/ODDfvSNtFLbfPY3yy1FNL +y1aLLmJjT6eqy80nmJrQlIrgTsiN2rLHRHWaiaEb0IDAgMBAAGjgb0wgbowDgYDVR0PAQEABAQD AgSwMCAGA1UdEQEBAAQWMBSBEnJkdkBzZmMud2lkZS5hZC5qcDA2BgNVHR8BAQAELDAqMCigJqAk hiJodHRwOi8vd3d3Lm1vY2Eud2lkZS5hZC5qcC9jcmwuY3JsMCIGA1UdIwEBAAQYMBaAFDjOxQk6 0w1U8lVx5kjHWvdE3+m6MCoGA1UdJQEBAAQgMB4GCCsGAQUFBwMEBggrBgEFBQcDAwYIKwYBBQUH AwIwDQYJKoZIhvcNAQEFBQADggIBABsJFLbjFiMXUdyi3ciFHoCUniBhmnqeM38tJ2ayQdr/s13P 0wXpKhnb0iX2Chze8bWOi0AD76WvlceQxuxwJvaBcAhIOzVbyVI7X+sQAYjGTBWhISVljc/DhO3a GH587YJFD5VdwXens9pmhsBovWYaBztVby+sdxjmHlVGq+oAmTeU9nwIVTizO0zV12hJEqjJ5cBh yYV8mOa1r9OCDHakNc7uDNCnrn7Kkx+jG3fqJl6D9MLZZJcqHGSsctVG+i1D6TXA6GZe+W86V+N4 idTjp/tndP0eKx692sTD0VHfph8PnMV9EqVMiGIM5hyF4UqhTkN5TpjwAC1vECnTTOAjpKdIQhPC hZM+jOf2d6KzE74xMmA4iQusRZFqTYAIndjyvqyi0TvSvlac86XLSKm65HefisGZ4+MRyMtjubnA XO1U8bejLWvDbblsVYSFuU/6IXBumr8Sh9xIeuFiN9JY+BI23e9oPWDSPG/h41B6iNob9py5XDyl kKr6tn5eN8j/swaQF7vaMPIv5qdDfsRbhbfYyg25A8va5evBbo1t8rvc6xlEcFO724qAPJMKrj5d FFpS3dmtSzUSiIrN/pDFfyF/15SN1bcW9YUJ2Ziu+IGy/IpMn11IK6qy94ybqdu3t+xGmJtwrBC7 F01UmXTx+Kg6JF++XgHwVP00tseaMIIGBzCCA++gAwIBAgICCRYwDQYJKoZIhvcNAQEFBQAwPjEL MAkGA1UEBhMCSlAxFTATBgNVBAoTDFdJREUgUHJvamVjdDEYMBYGA1UEAxMPV0lERSBST09UIENB IDAyMB4XDTA2MDUxODEzMzUzNloXDTE2MDYzMDIzNTk1OVowRTELMAkGA1UEBhMCSlAxFTATBgNV BAoTDFdJREUgUHJvamVjdDEfMB0GA1UEAxMWbWVtYmVycyBvcmllbnRlZCBDQSAwMjCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBAOAWEGfM92HciVLdGWw4dPq1X36X/wMNidhijS8uHzCB qRIY0vjoQDwvU1B+qzVVdgEepsq/eLLc1oRmPvm2Y3e/6GGES2vrQrVCmjpuPYm0vAh0qn3kf2G9 GByk6xwmgLtj1MOpBDRmd2wwojG7gz5Dy1ZGLjd60kad6h3dVyfA2dm01w21t3MFahxcSo1X+pnQ SJ5S/KTLPc+E/RjaXKkDtYu1JOOuyi2WG4tVtXeZttyaHa/+/8tPG3NO/KaVhN3T/XjRMrJkcXSL yjIEx3047WDd2YZ31BLGKCelvX5XPUKHvuVKnQbfjua7iTN5tb4ln/kbPMb77PWZ6Ha6msQCA8IJ oKR3jywldkHPxYsd75C2NkbfSl3kQoyzs4HQmIbbiSONoWP5fXSY60USv0KOYwAc20UScwmrw5ak tuatTl3p6zuuJ1Pu0/dj3xXjr9TkYOT3AkqGNHSMzfZXC+dcm9jy593FMcmuIrSGFfTBxV2iAzOI pyy5gVEf9MQ+EPibtWaneZ/riuZQq0OPPpDDym6w8qw8r6h2E6PF0bsgFGdReejSRb+rpnfv5tAA wtTO0PRzV8LfHUWcr1YB/JeLXmLvVnt9jbWex/HcjWmt+Eds7NWz9n7Q0wLv/wYv97uOyU0iejNc xOpbHOzsD+nN9qJGgkQsGssVWIvhYDXVAgMBAAGjggEGMIIBAjAPBgNVHRMBAf8EBTADAQH/MA4G A1UdDwEBAAQEAwIB/jBbBgNVHSABAQAEUTBPME0GCSqDCIycGAEBAjBAMD4GCCsGAQUFBwIBFjJo dHRwOi8vbW9jYS53aWRlLmFkLmpwL21vY2FfZ3VpZGUvbW9jYV9wb2xpY3kuaHRtbDA8BgNVHR8B AQAEMjAwMC6gLKAqhihodHRwOi8vd3d3LndpZGUuYWQuanAvY2Evd2lkZXJvb3RjcmwuY3JsMCAG A1UdDgEBAAQWBBQ4zsUJOtMNVPJVceZIx1r3RN/pujAiBgNVHSMBAQAEGDAWgBQMzKJLuc+x7LjU 6+SsCZdPsaIxMTANBgkqhkiG9w0BAQUFAAOCAgEACmaRrm9l9VBvWl7gEj9TLESbZYHGrWsWqYui 26MfvP+Z6y1wOjOfhUg/98IzveihHb/ihiuFiBOgALBinR9HRRPI4MxlcLsqMl2YPlFoRawjAd5W zX2PVLEwSX1cdU5TAtQV2k+aigoKdjeXRerNsnjWtZIBr0fsQ5MTRg3+qt8XDd0IgvaH8lMnkWmR GnE41Ke26OFURBbb97ccqHG0+gfetYp4VEtz2TcepyMyaomQNgl/0Bq5YO7hNRKF4Eifje+zHWrF +U5evQm/nyQgHZW44tSwIFixD1zNJB8mJ37Cx3xF6OGwkXaTfhqT76soVgzpPGRJq82IJbCt/CiC BuDKdLVKI9uZ814R55DbdDgi0r8z3E6KWm0Wj5eDJ70ENbRrCm0mn1AUeYM3YwP3/6PW0CmMGQvn z/BrudCG+LGHOQW1xGXVMdD43P9Z2yLjNLdWBa3yzolj/gK9Mf1rj67S2YFMkZ1QVch5u923vE/c HxN9WicPRPtmvdnI66dJcgn1qAioxxsXbDxbzyINYClRvyJYCnihJyrtTTuD5g//y1v+6egOVf1t bxmZ/IyPRK8Fc9nDIsiSX0VWr4leU3AufL60RB+qgfS3ycAO48uAkbtaDxrGkEYOWUzGldSWeXBQ TRynCYkgz06lXSj5I5klFVJWLxDftPKTxiv+CnExggIMMIICCAIBATBLMEUxCzAJBgNVBAYTAkpQ MRUwEwYDVQQKEwxXSURFIFByb2plY3QxHzAdBgNVBAMTFm1lbWJlcnMgb3JpZW50ZWQgQ0EgMDIC Ah+5MAkGBSsOAwIaBQCgggEXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEwODA0MTY0NVowIwYJKoZIhvcNAQkEMRYEFNEkpTs8pC9eq5s5V8VFhaC1ZU8fMFoG CSsGAQQBgjcQBDFNMEswRTELMAkGA1UEBhMCSlAxFTATBgNVBAoTDFdJREUgUHJvamVjdDEfMB0G A1UEAxMWbWVtYmVycyBvcmllbnRlZCBDQSAwMgICH7kwXAYLKoZIhvcNAQkQAgsxTaBLMEUxCzAJ BgNVBAYTAkpQMRUwEwYDVQQKEwxXSURFIFByb2plY3QxHzAdBgNVBAMTFm1lbWJlcnMgb3JpZW50 ZWQgQ0EgMDICAh+5MA0GCSqGSIb3DQEBAQUABIGAomSrVLm60jg1r8CjuwfR0dr6mY6venV7EfVr HzSyOabSYd1YkzvVEOBLVSN/HlEjBFeUrY4HmhmjZsknKhiGlrzIqCKBxt7AwvpGtQLZ6GAxYSYR Gy6xCuDwZ4PKzKI7J7u3Ia8YNU2/eIcfYdHzOmc0I0CnVo0M2NV6RxlnjNEAAAAAAAA= --Apple-Mail-32-173730866-- From wwwrun@core3.amsl.com Sat Nov 7 20:35:44 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id D4B403A68CB; Sat, 7 Nov 2009 20:35:44 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20091108043544.D4B403A68CB@core3.amsl.com> Date: Sat, 7 Nov 2009 20:35:44 -0800 (PST) Cc: ipsecme mailing list , ipsecme chair , Internet Architecture Board , RFC Editor Subject: [IPsec] Document Action: 'IPv6 Configuration in IKEv2' to Experimental RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 04:35:44 -0000 The IESG has approved the following document: - 'IPv6 Configuration in IKEv2 ' as an Experimental RFC This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-ipv6-config-03.txt Technical Summary This document describes new IKEv2 configuration attributes that let an IPsec security gateway assign IPv6 prefixes to a VPN client clients. This is needed because IKEv2 currently does not handle all features of IPv6 that it should, such as enabling a virtual link. Working Group Summary The document has light consensus of the IPsecME WG with no objections to publication as an Experimental RFC. Document Quality There was initial interest in this protocol from many participants, but only a few seem to have done an in-depth review. Despite that, the document has no obvious problems and could turn out to be quite useful as there is greater deployment of IPsec in IPv6 environments. This document should be revisited as more implementations of remote access IPv6 IPsec are created and deployed. Personnel Paul Hoffman is the Document Shepherd; Tim Polk is the Responsible Area Director. From yaronf@checkpoint.com Sun Nov 8 18:17:10 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31F23A68E3 for ; Sun, 8 Nov 2009 18:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.625 X-Spam-Level: X-Spam-Status: No, score=-4.625 tagged_above=-999 required=5 tests=[AWL=0.974, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbUW8qah63lD for ; Sun, 8 Nov 2009 18:17:09 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 47F5F3A6841 for ; Sun, 8 Nov 2009 18:17:09 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nA92HPc6021349; Mon, 9 Nov 2009 04:17:25 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 9 Nov 2009 04:17:28 +0200 From: Yaron Sheffer To: David McGrew , Paul Hoffman , "ipsec@ietf.org" Date: Mon, 9 Nov 2009 04:17:26 +0200 Thread-Topic: Updating IPsec algorithm requirements Thread-Index: Acpe/VQTlbYzY70/RUGhEYE1fwkQQwB47taw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF872BB9C@il-ex01.ad.checkpoint.com> References: <3A070C8D-782B-4CC2-B48E-0DA63EC5A4ED@cisco.com> In-Reply-To: <3A070C8D-782B-4CC2-B48E-0DA63EC5A4ED@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Updating IPsec algorithm requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 02:17:11 -0000 Hi David, I believe it's a bit early to make a SHOULD/MUST recommendation, at the tim= e we are still finalizing the algorithm requirements, with the work on the = Roadmap document, and the AES-CTR draft. The vast majority of deployed systems are software-based, and AES-GCM provi= des them with a marginal performance improvement at best. So we would need = a strong security argument to start this migration. May I also ask that you validate consensus behind your proposal on CFRG, i.= e. the superiority of AES-GCM (presumably, 128-bit) over AES-CBC+SHA-1 or A= ES-CBC+AES-XCBC, and whether or not there are any good alternatives to it. Thanks, Yaron > -----Original Message----- > From: David McGrew [mailto:mcgrew@cisco.com] > Sent: Saturday, November 07, 2009 1:22 > To: Paul Hoffman; Yaron Sheffer; ipsec@ietf.org > Subject: Updating IPsec algorithm requirements >=20 > Hi Paul, Yaron, and IPsec ME WG participants, >=20 > I would like to propose an update to the algorithm requirements, as > outlined below. >=20 > regards, >=20 > David >=20 > -- >=20 > Updating IPsec Algorithm Requirements >=20 > AES in Galois/Counter Mode of operation (AES-GCM)[RFC4106][RFC4543] > [RFC5282] should be recommended or required by the IPsec standards, > because it provides higher efficiency than currently recommended > algorithms with equivalent security, and is recommended by newer IPsec > profiles [RFC4869]. >=20 > Currently, AES in Counter Mode (AES-CTR)[RFC3686] is recommended as a > SHOULD in "Cryptographic Algorithm Implementation Requirements for > Encapsulating Security Payload (ESP) and Authentication Header (AH)", > RFC 4835. AES-CTR is a useful algorithm because it admits efficient > high speed implementations. However, it provides no authentication. > From RFC3686: "With AES-CTR, it is trivial to use a valid ciphertext > to forge other (valid to the decryptor) ciphertexts. Thus, it is > equally catastrophic to use AES-CTR without a companion authentication > function. Implementations MUST use AES-CTR in conjunction with an > authentication function, such as HMAC-SHA-1-96 [HMAC-SHA]." > Unfortunately, none of the authentication algorithms currently defined > for IPsec (HMAC, XCBC-MAC) admit efficient high speed > implementations. Thus the need for authentication undermines the > efficiency of AES-CTR. >=20 > AES-GCM was designed specifically to overcome this problem. It is a > "combined mode" in the ESP sense [RFC4303], that provides both > encryption and authentication. Internally, it combines AES-CTR with > an authentication mechanism that can be efficiently implemented at > high data rates. >=20 > At the time that RFC 4835 was published (April 2007), there was not > yet a stable normative reference for AES-GCM. This may have motivated > the IPsec community to not rely on that algorithm in its > recommendations. But November 2007 saw the publication of NIST SP > 800-38D, "Recommendation for Block Cipher Modes of Operation: Galois/ > Counter Mode (GCM) and GMAC", which removes any such concern. An > additional change in favor of AES-GCM is its wide adoption by > crypto hardware and software suppliers. >=20 > It is especially important that AES-GCM be recommended over the use of > AES-CTR with HMAC-SHA-256, because the latter combination of > algorithms is considerably less efficient, and the former algorithm > meets the security requirements. The IPsec ME Working Group should > set a policy that makes it clear that HMAC-SHA-256 is not required for > future implementations. HMAC-SHA-1 is believed to be secure (recall > the "No Need for SHA-2" Open Letter > http://www.vpnc.org/ietf-ipsec/02.ipsec/msg01840.html), but as the > industry moves away from SHA1, HMAC-SHA-256 may be the first algorithm > that comes to mind for some users of IPsec. Thus a policy > clarification by the WG is essential. This should be done as soon > as is practical, because the transition away from SHA-1 for digital > signatures is already underway; many users plan to have that transition > completed by the end of 2010 (see NIST SP 800-107, for example). >=20 > AES-CBC and HMAC-SHA1 are valuable because those algorithms are widely > implemented. This suggests that it makes sense to rely on those > algorithms as mandatory-to-implement until such time as it becomes > necessary or desirable to stop using HMAC-SHA1. AES-GCM should > replace this combination of algorithms, when that time comes. >=20 >=20 >=20 > Scanned by Check Point Total Security Gateway. From srinid@cisco.com Mon Nov 9 01:41:15 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 406053A67FB for ; Mon, 9 Nov 2009 01:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozu1lVSA0rZP for ; Mon, 9 Nov 2009 01:41:12 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0A8FF3A6783 for ; Mon, 9 Nov 2009 01:41:12 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAENy90pAaHte/2dsb2JhbACCJCzBTZZAgjmCBQSBaHg X-IronPort-AV: E=Sophos;i="4.44,707,1249257600"; d="scan'208,217";a="103063556" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 09 Nov 2009 09:41:37 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA99fSO9003016 for ; Mon, 9 Nov 2009 09:41:37 GMT Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 15:11:36 +0530 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6120.D45599EA" Date: Mon, 9 Nov 2009 15:11:35 +0530 Message-ID: <3A8C969225424C4D8E6BEE65ED8552DA4C4068@XMB-BGL-41C.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EAP Identity request in IKEv2 Thread-Index: AcphINOUdgdsx/fWR1KgVBp/ms+t4A== From: "Srinivasu S R S Dhulipala (srinid)" To: X-OriginalArrivalTime: 09 Nov 2009 09:41:36.0543 (UTC) FILETIME=[D47F22F0:01CA6120] Subject: [IPsec] EAP Identity request in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 09:41:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6120.D45599EA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I see that RFC4306 has the following lines at the end of Sec3.16: =20 Note that since IKE passes an indication of initiator identity in message 3 of the protocol, the responder SHOULD NOT send EAP Identity requests. The initiator SHOULD, however, respond to such requests if it receives them. =20 I see that from draft-ietf-ipsecme-ikev2bis-01, "SHOUD" and "SHOULD NOT" were demoted to "should" and "should not", the text now looks as below: =20 {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an indication of initiator identity in message 3 of the protocol, the responder should not send EAP Identity requests. The initiator may, however, respond to such requests if it receives them. =20 Also, "The initiator SHOULD" is now "The initiator may". =20 I would like to understand why these changes were done. Why do we need to do an EAP-ID request as IDi should carry an indication of the client's identity? =20 Thanks, Srinivas ------_=_NextPart_001_01CA6120.D45599EA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I see that RFC4306 has the following lines at the = end of Sec3.16:

 

   Note that since IKE passes an indication of initiator identity = in

   message 3 of the protocol, the responder SHOULD NOT send EAP = Identity

   requests.  The initiator SHOULD, however, respond to such requests = if

   it receives them.

 

I see that from draft-ietf-ipsecme-ikev2bis-01, = “SHOUD” and “SHOULD NOT” were demoted to

“should” and “should not”, = the text now looks as below:

 

   {{ Demoted the SHOULD NOT and SHOULD }} Note that =
since IKE passes an
   indication of =
initiator identity in message 3 of the protocol, =
the
   responder should not send EAP =
Identity requests.  The initiator =
may,
   however, respond to such requests =
if it receives them.

 

Also, “The initiator SHOULD” is now = “The initiator may”.

 

I would like to understand why these changes were = done. Why do we need to do an EAP-ID

request as IDi should carry an indication of the = client’s identity?

 

Thanks,

Srinivas

------_=_NextPart_001_01CA6120.D45599EA-- From mcgrew@cisco.com Mon Nov 9 06:02:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7393A6B6E for ; Mon, 9 Nov 2009 06:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.491 X-Spam-Level: X-Spam-Status: No, score=-7.491 tagged_above=-999 required=5 tests=[AWL=1.108, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfssoXLtqv5A for ; Mon, 9 Nov 2009 06:01:59 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4AB833A69DB for ; Mon, 9 Nov 2009 06:01:59 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 1760 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPKu90qrR7H+/2dsb2JhbADGC5ZYgkaBeASBaA X-IronPort-AV: E=Sophos;i="4.44,708,1249257600"; d="p7s'?scan'208";a="428170395" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 09 Nov 2009 14:02:25 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA9E2PA9007890; Mon, 9 Nov 2009 14:02:25 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 06:02:25 -0800 Received: from stealth-10-32-254-214.cisco.com ([10.32.254.214]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 06:02:24 -0800 Message-Id: From: David McGrew To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF872BB9C@il-ex01.ad.checkpoint.com> Content-Type: multipart/signed; boundary=Apple-Mail-222-295269496; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 06:02:23 -0800 References: <3A070C8D-782B-4CC2-B48E-0DA63EC5A4ED@cisco.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF872BB9C@il-ex01.ad.checkpoint.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Nov 2009 14:02:25.0221 (UTC) FILETIME=[43D5E750:01CA6145] Cc: "ipsec@ietf.org" , Paul Hoffman Subject: Re: [IPsec] Updating IPsec algorithm requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:02:00 -0000 --Apple-Mail-222-295269496 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Yaron, On Nov 8, 2009, at 6:17 PM, Yaron Sheffer wrote: > Hi David, > > I believe it's a bit early to make a SHOULD/MUST recommendation, at > the time we are still finalizing the algorithm requirements, with > the work on the Roadmap document, and the AES-CTR draft. Is the intent of the Roadmap to document the extant RFCs, or the current consensus of the working group? If it is only documenting current RFCs, then surely it should not hold up WG action on recommending policy updates. If it is documenting current consensus of the WG, then it would seem appropriate to discuss updating the algorithm requirements in the context of that draft (and it would seem urgent to do so). What bearing does draft-ietf-ipsecme-aes-ctr-ikev2-02.txt have on the policy issue? There are good reasons for recommending AES-GCM over AES-CTR, and there are already RFCs for using AES-GCM in IKEv2. > > The vast majority of deployed systems are software-based, and AES- > GCM provides them with a marginal performance improvement at best. > So we would need a strong security argument to start this migration. I respectfully but strongly disagree. The important issue is not about security; it is about performance/cost. All of the algorithms that we are discussing provide enough security, but they have widely different performance/cost characteristics. Even if AES-GCM provided advantages only to hardware-based systems, it would be worth recommending for broad adoption, because software-based systems need to make connections with hardware-based systems. A broad recommendation is needed in order to ensure interoperability. However, many software implementations (perhaps even a majority) can benefit from performance advantages. Some new processors have added support for the finite-field multiplication operation used in GCM [1] as well as for AES [2]. Extremely fast software implementations have been reported [3]. > > May I also ask that you validate consensus behind your proposal on > CFRG, i.e. the superiority of AES-GCM (presumably, 128-bit) over AES- > CBC+SHA-1 or AES-CBC+AES-XCBC, and whether or not there are any good > alternatives to it. There is not much point to asking CFRG, since the performance advantages of GCM are well established. If we want to find out how well those advantages apply to the implementation environments that are typical for IPsec, let's ask for input from this WG. But even this question is tangential. There are implementers that will benefit from using AES-GCM, and that algorithm is clearly better than AES- CTR. What possible reason can one put forward for recommending AES- CTR over AES-GCM in ESP? Let's develop an IPsec policy that supports cost effective high speed implementations. We know that AES-CBC won't get us there, and neither will AES-CTR with HMAC-SHA-256. regards, David [1] http://software.intel.com/en-us/articles/carry-less-multiplication-and-its-usage-for-computing-the-gcm-mode/ [2] http://software.intel.com/file/20457 [3] http://eprint.iacr.org/2009/129 > > Thanks, > Yaron > >> -----Original Message----- >> From: David McGrew [mailto:mcgrew@cisco.com] >> Sent: Saturday, November 07, 2009 1:22 >> To: Paul Hoffman; Yaron Sheffer; ipsec@ietf.org >> Subject: Updating IPsec algorithm requirements >> >> Hi Paul, Yaron, and IPsec ME WG participants, >> >> I would like to propose an update to the algorithm requirements, as >> outlined below. >> >> regards, >> >> David >> >> -- >> >> Updating IPsec Algorithm Requirements >> >> AES in Galois/Counter Mode of operation (AES-GCM)[RFC4106][RFC4543] >> [RFC5282] should be recommended or required by the IPsec standards, >> because it provides higher efficiency than currently recommended >> algorithms with equivalent security, and is recommended by newer >> IPsec >> profiles [RFC4869]. >> >> Currently, AES in Counter Mode (AES-CTR)[RFC3686] is recommended as a >> SHOULD in "Cryptographic Algorithm Implementation Requirements for >> Encapsulating Security Payload (ESP) and Authentication Header (AH)", >> RFC 4835. AES-CTR is a useful algorithm because it admits efficient >> high speed implementations. However, it provides no authentication. >> From RFC3686: "With AES-CTR, it is trivial to use a valid ciphertext >> to forge other (valid to the decryptor) ciphertexts. Thus, it is >> equally catastrophic to use AES-CTR without a companion >> authentication >> function. Implementations MUST use AES-CTR in conjunction with an >> authentication function, such as HMAC-SHA-1-96 [HMAC-SHA]." >> Unfortunately, none of the authentication algorithms currently >> defined >> for IPsec (HMAC, XCBC-MAC) admit efficient high speed >> implementations. Thus the need for authentication undermines the >> efficiency of AES-CTR. >> >> AES-GCM was designed specifically to overcome this problem. It is a >> "combined mode" in the ESP sense [RFC4303], that provides both >> encryption and authentication. Internally, it combines AES-CTR with >> an authentication mechanism that can be efficiently implemented at >> high data rates. >> >> At the time that RFC 4835 was published (April 2007), there was not >> yet a stable normative reference for AES-GCM. This may have >> motivated >> the IPsec community to not rely on that algorithm in its >> recommendations. But November 2007 saw the publication of NIST SP >> 800-38D, "Recommendation for Block Cipher Modes of Operation: Galois/ >> Counter Mode (GCM) and GMAC", which removes any such concern. An >> additional change in favor of AES-GCM is its wide adoption by >> crypto hardware and software suppliers. >> >> It is especially important that AES-GCM be recommended over the use >> of >> AES-CTR with HMAC-SHA-256, because the latter combination of >> algorithms is considerably less efficient, and the former algorithm >> meets the security requirements. The IPsec ME Working Group should >> set a policy that makes it clear that HMAC-SHA-256 is not required >> for >> future implementations. HMAC-SHA-1 is believed to be secure (recall >> the "No Need for SHA-2" Open Letter >> http://www.vpnc.org/ietf-ipsec/02.ipsec/msg01840.html), but as the >> industry moves away from SHA1, HMAC-SHA-256 may be the first >> algorithm >> that comes to mind for some users of IPsec. Thus a policy >> clarification by the WG is essential. This should be done as soon >> as is practical, because the transition away from SHA-1 for digital >> signatures is already underway; many users plan to have that >> transition >> completed by the end of 2010 (see NIST SP 800-107, for example). >> >> AES-CBC and HMAC-SHA1 are valuable because those algorithms are >> widely >> implemented. This suggests that it makes sense to rely on those >> algorithms as mandatory-to-implement until such time as it becomes >> necessary or desirable to stop using HMAC-SHA1. AES-GCM should >> replace this combination of algorithms, when that time comes. >> >> >> >> Scanned by Check Point Total Security Gateway. --Apple-Mail-222-295269496 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDnjCCA5ow ggKCoAMCAQICAWQwCwYJKoZIhvcNAQEFMG0xFTATBgNVBAMMDERhdmlkIE1jR3JldzETMBEGA1UE CAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMxETAPBgNVBAcMCFNhbiBKb3NlMR8wHQYJKoZIhvcN AQkBFhBtY2dyZXdAY2lzY28uY29tMB4XDTA4MTIwOTIyMDMzMFoXDTA5MTIwOTIyMDMzMFowbTEV MBMGA1UEAwwMRGF2aWQgTWNHcmV3MRMwEQYDVQQIDApDYWxpZm9ybmlhMQswCQYDVQQGEwJVUzER MA8GA1UEBwwIU2FuIEpvc2UxHzAdBgkqhkiG9w0BCQEWEG1jZ3Jld0BjaXNjby5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDh5WR1gATRK4ubbWwmG2T/XTUeVc2FAxnmtoYy00fM 5jp3DYFXHkWj4Cl8RVVfAJxP/2PhKsTl0qx2b7N9pIZZa6BaODEyJ8yVMRHloHrpzHeU8DIrst/H SFVkcJvl3p9LFD42BCvznzQ48VxnWX68OCk7GAwg6XoKMY8Z1F70PVvcZ0JcbnDuKx0efQ+P74uY UdpjRYSXb2xJUziGs5k6b1kTr5754B3tnYCGkum49YAbONpsOL4R+e4HNNrkVTx254ggrcDb1GDr IpZYCSPh6lZWwOp0XBoJiLYEKXuBf/jSNEv15/Kt/Uu5Oh8jUBxkBHGAVZuaVu25s3Zk9waLAgMB AAGjRzBFMA4GA1UdDwEB/wQEAwIEsDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDBDAbBgNVHREEFDAS gRBtY2dyZXdAY2lzY28uY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCbD+Y6Yu0d5FZHSGd7WTP7vlo+ SE2rF0YzqvcMYrEuu6VBbkOFGfq3leu2WVJinXYQwAgaZ7vJpH43/bjDIK4YuOqAUv57ZQjtCJ6W 6b0rdG8/A2cWcGoDjqmjAGJ4TC8oMIc0h33QPEjsGdon0nsV0QCxrgWcWEjFSzlE6kbR4pT3yA2V zo7byNoDoYpH5otGH0/cRQM9i6ENTytxzczPeNTt2uaMp/3s8MZ5W/0Yz8U/yy5bcS5TGrqgTvN7 mI+nngoJ4TNKapSpdSqCyEK86z51VWtRRFyBosLQsNhMYb7HWzW/mIQCG0SygOVjUcRPKxhYUokR gCmxsHqcL1uMMYIDBDCCAwACAQEwcjBtMRUwEwYDVQQDDAxEYXZpZCBNY0dyZXcxEzARBgNVBAgM CkNhbGlmb3JuaWExCzAJBgNVBAYTAlVTMREwDwYDVQQHDAhTYW4gSm9zZTEfMB0GCSqGSIb3DQEJ ARYQbWNncmV3QGNpc2NvLmNvbQIBZDAJBgUrDgMCGgUAoIIBZzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTExMDkxNDAyMjRaMCMGCSqGSIb3DQEJBDEWBBRofnVr PS/OZHS4MivucI19dHL70DCBgQYJKwYBBAGCNxAEMXQwcjBtMRUwEwYDVQQDDAxEYXZpZCBNY0dy ZXcxEzARBgNVBAgMCkNhbGlmb3JuaWExCzAJBgNVBAYTAlVTMREwDwYDVQQHDAhTYW4gSm9zZTEf MB0GCSqGSIb3DQEJARYQbWNncmV3QGNpc2NvLmNvbQIBZDCBgwYLKoZIhvcNAQkQAgsxdKByMG0x FTATBgNVBAMMDERhdmlkIE1jR3JldzETMBEGA1UECAwKQ2FsaWZvcm5pYTELMAkGA1UEBhMCVVMx ETAPBgNVBAcMCFNhbiBKb3NlMR8wHQYJKoZIhvcNAQkBFhBtY2dyZXdAY2lzY28uY29tAgFkMA0G CSqGSIb3DQEBAQUABIIBAJJNvvuGNn20K0nU0Bm36xbqgISPgkKBQ+4FyDU/+vz+vdRduEDdspP/ 1YinWyBYRpgTIi8TxnDUGO92emTpAuP2QYWACEowI9GP7BAjQhZZDuesduGfGp9DdYauf2B6Inpq smDQxX4iAOS9wFkXyR0cDNFaprzvBVfPlI9giLH6D+/rGDKQeLaiF2aPHoO/EERX2h7MIuOx7zpJ D7e02zlBssY/Co45IjJFYIM+HDtEjTV2poqhwqGqdrVBKFV6ujPMZSJWzdtVJiLz5xbGIh+DlzNK 9BYAX2ghRRnP1PA7wg4H67oQEj3DzWzJVvO8kQS+zS/DGWsoBP9SwaFz3e0AAAAAAAA= --Apple-Mail-222-295269496-- From root@core3.amsl.com Mon Nov 9 14:30:02 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DA9633A69B8; Mon, 9 Nov 2009 14:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091109223002.DA9633A69B8@core3.amsl.com> Date: Mon, 9 Nov 2009 14:30:02 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-10.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 22:30:03 -0000 --NextPart 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 : Wrapped ESP for Traffic Visibility Author(s) : K. Grewal, et al. Filename : draft-ietf-ipsecme-traffic-visibility-10.txt Pages : 15 Date : 2009-11-09 This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on the Encapsulating Security Payload (ESP) [RFC4303], and is designed to allow intermediate devices to (1) ascertain if data confidentiality is being employed within ESP and if not, (2) inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec ESP standard, there is no way to differentiate between encrypted and unencrypted payloads by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate integrity-only ESP from ESP-encrypted packets, without compromising on the security provided by ESP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-traffic-visibility-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-09142403.I-D@ietf.org> --NextPart-- From amjads@cisco.com Tue Nov 10 03:40:24 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEF953A6A09 for ; Tue, 10 Nov 2009 03:40:24 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp0vNx-Tw+ey for ; Tue, 10 Nov 2009 03:40:24 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 158403A684F for ; Tue, 10 Nov 2009 03:40:24 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJPg+EpAaHte/2dsb2JhbADFNpgPgjmCBQSBaHg X-IronPort-AV: E=Sophos;i="4.44,715,1249257600"; d="scan'208";a="48765515" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 10 Nov 2009 11:40:50 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAABenhB011065 for ; Tue, 10 Nov 2009 11:40:49 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 17:10:29 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 17:10:27 +0530 Message-ID: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification on identities involved in IKEv2 EAP authentication Thread-Index: Acph+pkictL1WLM7QbeokDzD/meezw== From: "Amjad Inamdar (amjads)" To: X-OriginalArrivalTime: 10 Nov 2009 11:40:29.0327 (UTC) FILETIME=[9A6159F0:01CA61FA] Subject: [IPsec] Clarification on identities involved in IKEv2 EAP authentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 11:40:24 -0000 Hi, =20 With IKEv2 EAP authentication, there are 3 identities involved 1) IDi - IKEv2 initiator identity sent in msg-3 2) EAP identity that gateway (IKE2 responder) can request from the client (IKEv2 initiator) 3) Authenticated EAP identity that third party EAP server provides to the gateway (IKEv2 responder). Could someone please clarify from RFC standpoint if=20 1) The 3 identities mentioned above MUST/SHOULD be same 2) If not same, what purpose should each of the above identities serve 3) The mandatory/recommended format for each of the above identites=20 Thanks, -Amjad From ynir@checkpoint.com Tue Nov 10 03:58:57 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7C213A696D for ; Tue, 10 Nov 2009 03:58:57 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxUarlHM5e2y for ; Tue, 10 Nov 2009 03:58:57 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7FAA83A687F for ; Tue, 10 Nov 2009 03:58:56 -0800 (PST) X-CheckPoint: {4AF95282-6-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id F277329C004; Tue, 10 Nov 2009 13:59:22 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D21D329C002; Tue, 10 Nov 2009 13:59:22 +0200 (IST) X-CheckPoint: {4AF95282-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAABxMc6024625; Tue, 10 Nov 2009 13:59:22 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 10 Nov 2009 13:59:24 +0200 From: Yoav Nir To: "Amjad Inamdar (amjads)" Date: Tue, 10 Nov 2009 13:59:19 +0200 Thread-Topic: [IPsec] Clarification on identities involved in IKEv2 EAP authentication Thread-Index: Acph/T6sbxIgyziASaiLecrXjL4UOA== Message-ID: <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com> References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com> In-Reply-To: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-64-374285746"; protocol="application/pkcs7-signature" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Clarification on identities involved in IKEv2 EAP authentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 11:58:57 -0000 --Apple-Mail-64-374285746 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On Nov 10, 2009, at 1:40 PM, Amjad Inamdar (amjads) wrote: > Hi, > > With IKEv2 EAP authentication, there are 3 identities involved > > 1) IDi - IKEv2 initiator identity sent in msg-3 > 2) EAP identity that gateway (IKE2 responder) can request from the > client (IKEv2 initiator) > 3) Authenticated EAP identity that third party EAP server provides to > the gateway (IKEv2 responder). > > > Could someone please clarify from RFC standpoint if > > 1) The 3 identities mentioned above MUST/SHOULD be same No, although they typically are. > 2) If not same, what purpose should each of the above identities serve 1) mainly used as a hint for the gateway as to which AAA server to choose 2) It's the AAA server that may request the identity, and it's internal to AAA. It doesn't play in IKE 3) That's the authenticated identity of the user. That is what the responder uses for policy decisions. > 3) The mandatory/recommended format for each of the above identites All the types in section 3.5 are acceptable, but the most used ones are ID_RFC822_ADDR and ID_DER_ASN1_DN --Apple-Mail-64-374285746 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEHWPmpet94anoiUADSB7pZcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUxOTIxMDYyOFoXDTEwMDUxOTIxMDYy OFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN5Dac6srAGq YgV/Ggt0eXG8MRQRMR1SmIXm66utqDjcJhKDwKeyV5ICqQFr8ETbYZ7YgvSkXE7o9StCeqVvxKt0 hR5DTjho49VrCiaKex3q6d/VNh6E22yBqZBYbVa5xsxcPK6V2g/GXhyoNjoezeRVlRm0bbQtscKt GOt5BJFjjL5Ns/x0MktYgn24NIDnsTJKPEXl7vQzpwp6tnJJuiz/ttdW+7PII8vTkoHZpNGPW/aS bLR01T8ga739zosQ57YAdkih69BMHb+Q9zpRoSyd6NGEQ124TtskwWSAPAvw3TF2p0NlMKBU02Bt B07zkCodlx6sqOxeX7nVML26zI8CAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAA+x/ZiahLKaSb/kWVGx2gJAGAG5 C065lmMky3hmur1IfUa9GBXJO40Z4CdiD6Y/4wQgHkBPnRF4YdhMjd2ecE03/9+x4grNKaXaeiIl MXQtniPa1tO++O/8eaPiMx6AF+v4njB/q0CUpYF78fTloJuhflNPvdbV46Xj41fIDoFAMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB1j5qXrfeGp6IlAA0ge6WXMAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTExMDEx NTkyMFowIwYJKoZIhvcNAQkEMRYEFJ0dMBS+mSgvjyrxXrhepun8MRvKMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdY+al633hqei JQANIHullzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQdY+al633hqeiJQANIHullzANBgkqhkiG9w0BAQEFAASCAQBq5iv0KVRq c7mEx9xqBMP0dRvPKXvdXZ1caU2MGC54fQxcmYeYt6Qyl+XQWu1xa9Bv+449zhcgb+boZJmbC4q0 t0NTF4Hh+dokQWDPUgZgcZGL4JZZpq5OvXhhQSFLNK1migGQJGUUWfDajCw/63BlUxZes+C3l0Gq ly9537lnqgqq1DnDWEFls994tUNpFoOI90mAxQ0aHxmhru+vb8OgCgP7sj7uHJv//AxNLTgcRvm0 5PuEedxW7yBxzdogn2++9CWYSboA6WUUjMaK4zdctAMQk7mL3ViHoSHNtLeLt+Wg6qsmgryx1QYK plYuqhxW1qK+iIIB6fShKaD6LRKdAAAAAAAA --Apple-Mail-64-374285746-- From amjads@cisco.com Tue Nov 10 05:30:24 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44F4D3A6805 for ; Tue, 10 Nov 2009 05:30:24 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JarL81bUUTU for ; Tue, 10 Nov 2009 05:30:23 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 68B773A672F for ; Tue, 10 Nov 2009 05:30:23 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGv5+EqrR7Ht/2dsb2JhbADFY5gVgjmCBQSBaHg X-IronPort-AV: E=Sophos;i="4.44,716,1249257600"; d="scan'208";a="268842973" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 10 Nov 2009 13:30:50 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAADUniX001747; Tue, 10 Nov 2009 13:30:50 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 19:00:48 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 19:00:46 +0530 Message-ID: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F1074@XMB-BGL-417.cisco.com> In-Reply-To: <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Clarification on identities involved in IKEv2 EAPauthentication Thread-Index: Acph/T6sbxIgyziASaiLecrXjL4UOAACRCUg References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com> <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com> From: "Amjad Inamdar (amjads)" To: "Yoav Nir" X-OriginalArrivalTime: 10 Nov 2009 13:30:48.0666 (UTC) FILETIME=[03D053A0:01CA620A] Cc: ipsec@ietf.org Subject: Re: [IPsec] Clarification on identities involved in IKEv2 EAPauthentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 13:30:24 -0000 Hi Yaov, Thanks for your reply. Please see my comments inline.=20 -----Original Message----- From: Yoav Nir [mailto:ynir@checkpoint.com]=20 Sent: Tuesday, November 10, 2009 5:29 PM To: Amjad Inamdar (amjads) Cc: ipsec@ietf.org Subject: Re: [IPsec] Clarification on identities involved in IKEv2 EAPauthentication On Nov 10, 2009, at 1:40 PM, Amjad Inamdar (amjads) wrote: > Hi, > > With IKEv2 EAP authentication, there are 3 identities involved > > 1) IDi - IKEv2 initiator identity sent in msg-3 > 2) EAP identity that gateway (IKE2 responder) can request from the=20 > client (IKEv2 initiator) > 3) Authenticated EAP identity that third party EAP server provides to=20 > the gateway (IKEv2 responder). > > > Could someone please clarify from RFC standpoint if > > 1) The 3 identities mentioned above MUST/SHOULD be same No, although they typically are. [Amjad] Is there a use case for not having IDi same as EAP identity? Having them same would simplify policy decisions. > 2) If not same, what purpose should each of the above identities serve 1) mainly used as a hint for the gateway as to which AAA server to choose [Amjad] EAP authentication is typically used with remote access and IDi of type IP_ADDR may not be very useful here as a hint for AAA server. So it will help to have recommened ID types for such cases. 2) It's the AAA server that may request the identity, and it's internal to AAA. It doesn't play in IKE [Amjad] Does it mean that if gateway is just acting as a pass-through, gateway MUST-NOT request EAP identity from the client as per RFC? If AAA server does not provide authenticated identity to the gateway (RFC does not seem to mandate that), the only way for gateway is to request EAP identity from the client, for policy decisions, unless IDi carries EAP identity which again is not mandated by RFC. 3) That's the authenticated identity of the user. That is what the responder uses for policy decisions. > 3) The mandatory/recommended format for each of the above identites All the types in section 3.5 are acceptable, but the most used ones are ID_RFC822_ADDR and ID_DER_ASN1_DN [Amjad] Are IKEv2 identity types acceptable as EAP identity as well? Thanks, -Amjad From paul.hoffman@vpnc.org Tue Nov 10 12:53:46 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 007303A6900 for ; Tue, 10 Nov 2009 12:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.972 X-Spam-Level: X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW3iHHT-9EDZ for ; Tue, 10 Nov 2009 12:53:45 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 3A8E83A65A6 for ; Tue, 10 Nov 2009 12:53:45 -0800 (PST) Received: from [133.93.24.35] (host-128-35.meeting.ietf.org [133.93.128.35]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAAKs6W7078738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2009 13:54:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F1074@XMB-BGL-417.cisco.com> References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com> <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com> <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F1074@XMB-BGL-417.cisco.com> Date: Wed, 11 Nov 2009 05:54:05 +0900 To: "Amjad Inamdar (amjads)" , "Yoav Nir" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ipsec@ietf.org Subject: Re: [IPsec] Clarification on identities involved in IKEv2 EAPauthentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 20:53:46 -0000 The identity types are local policy. We don't want to prohibit particular types, even if they are uncommon. --Paul Hoffman, Director --VPN Consortium From sha.abdulla@gmail.com Tue Nov 10 19:35:53 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8425D3A6C00 for ; Tue, 10 Nov 2009 19:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CegoNpr+dNo1 for ; Tue, 10 Nov 2009 19:35:52 -0800 (PST) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id B695F3A6892 for ; Tue, 10 Nov 2009 19:35:52 -0800 (PST) Received: by pzk42 with SMTP id 42so538751pzk.31 for ; Tue, 10 Nov 2009 19:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=LEqhRAvsP+/NTzWK8+UHqNJdgggtDedU6ig7Yje00Yk=; b=QdpOGojjmAxu+rhiYQDX53GM2JP4X6se9WE3BAg1kjrgpLA/3u5qLcCtQhhN3DPEdh DO9uNxiBbgjc1a/JAFtXqaTChhmRez8smcYM/jknGc5xRjxxU47M1ISaYebVlSKkE9qA r9cFuVJdB8H3Vwvi/AY6wWI6qd5gLEWwZ1LIA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wO7f9etqSBMCvZFJog/SEaHn8UPW/uxpOTNKiwlWpW1oXy9Lb2ksbQ4Wp5fZ4jxXQN Rph+09MUCHB/uYZnyxWwFb1iLbYslOiggkpKxQ2iCyaNbbluQlNe3DRGCAlXFVWp9Nk2 RbdezGfPlGByQmmXDjImuXk+ujSL6rSskz2AE= MIME-Version: 1.0 Received: by 10.141.42.17 with SMTP id u17mr54027rvj.85.1257910578239; Tue, 10 Nov 2009 19:36:18 -0800 (PST) In-Reply-To: References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com> <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com> <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F1074@XMB-BGL-417.cisco.com> Date: Wed, 11 Nov 2009 09:06:18 +0530 Message-ID: <4298ab9e0911101936h282d9403g71a029808ac6b8c0@mail.gmail.com> From: shaik abdulla To: Paul Hoffman Content-Type: multipart/alternative; boundary=000e0cd20a5c2cd8b6047810217d Cc: ipsec@ietf.org, Yoav Nir , "Amjad Inamdar \(amjads\)" Subject: Re: [IPsec] Clarification on identities involved in IKEv2 EAPauthentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:35:53 -0000 --000e0cd20a5c2cd8b6047810217d Content-Type: text/plain; charset=ISO-8859-1 Hi, Is there any windows API for IKEV2.If so please send me link. On Wed, Nov 11, 2009 at 2:24 AM, Paul Hoffman wrote: > The identity types are local policy. We don't want to prohibit particular > types, even if they are uncommon. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Regards Shaik Abdulla --000e0cd20a5c2cd8b6047810217d Content-Type: text/html; charset=ISO-8859-1 Hi,
Is there any windows API for IKEV2.If so please send me link.

On Wed, Nov 11, 2009 at 2:24 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
The identity types are local policy. We don't want to prohibit particular types, even if they are uncommon.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



--
Regards
Shaik Abdulla

--000e0cd20a5c2cd8b6047810217d-- From andreas.steffen@strongswan.org Tue Nov 10 23:04:09 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D903F3A6C16 for ; Tue, 10 Nov 2009 23:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shib7178Hm1I for ; Tue, 10 Nov 2009 23:04:09 -0800 (PST) Received: from strongswan.org (sidv0150.hsr.ch [152.96.52.150]) by core3.amsl.com (Postfix) with ESMTP id DEC1A3A68FA for ; Tue, 10 Nov 2009 23:04:08 -0800 (PST) Received: from [10.10.0.1] (koala.strongsec.com [10.10.0.1]) by strongswan.org (Postfix) with ESMTP id 538BDEFBD7; Wed, 11 Nov 2009 08:04:33 +0100 (CET) Message-ID: <4AFA6200.6000406@strongswan.org> Date: Wed, 11 Nov 2009 08:04:32 +0100 From: Andreas Steffen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: shaik abdulla References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com> <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com> <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F1074@XMB-BGL-417.cisco.com> <4298ab9e0911101936h282d9403g71a029808ac6b8c0@mail.gmail.com> In-Reply-To: <4298ab9e0911101936h282d9403g71a029808ac6b8c0@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Yoav Nir , Paul Hoffman , "Amjad Inamdar \(amjads\)" Subject: Re: [IPsec] Clarification on identities involved in IKEv2 EAPauthentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 07:04:09 -0000 Have a look at the following Windows 7 IKEv2 HOWTO: http://wiki.strongswan.org/wiki/strongswan/Windows7 Best regards Andreas Steffen shaik abdulla wrote: > Hi, > Is there any windows API for IKEV2.If so please send me link. ====================================================================== Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== From srinid@cisco.com Wed Nov 11 05:27:28 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5385128C17E for ; Wed, 11 Nov 2009 05:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BdGKHx9PmcA for ; Wed, 11 Nov 2009 05:27:26 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A34B33A688D for ; Wed, 11 Nov 2009 05:27:25 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAEAOpK+kqrR7H+/2dsb2JhbACCJizBMZgZgjeCBQSBa3s X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208,217";a="269464938" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 11 Nov 2009 13:27:53 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nABDRq09007529 for ; Wed, 11 Nov 2009 13:27:52 GMT Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 18:57:51 +0530 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA62D2.C44458D2" Date: Wed, 11 Nov 2009 18:57:50 +0530 Message-ID: <3A8C969225424C4D8E6BEE65ED8552DA4C446A@XMB-BGL-41C.cisco.com> In-Reply-To: <3A8C969225424C4D8E6BEE65ED8552DA4C4068@XMB-BGL-41C.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] EAP Identity request in IKEv2 Thread-Index: AcphINOUdgdsx/fWR1KgVBp/ms+t4ABry3aw References: <3A8C969225424C4D8E6BEE65ED8552DA4C4068@XMB-BGL-41C.cisco.com> From: "Srinivasu S R S Dhulipala (srinid)" To: "Srinivasu S R S Dhulipala (srinid)" , X-OriginalArrivalTime: 11 Nov 2009 13:27:51.0069 (UTC) FILETIME=[C45EECD0:01CA62D2] Subject: Re: [IPsec] EAP Identity request in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 13:27:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA62D2.C44458D2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resending the query again, as I did not see any response to this query. =20 It looks like additional EAP ID request to the client is not needed, so I think we should move the "should" to "SHOULD" again. Any thoughts? =20 Thanks, Srinivas =20 From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Srinivasu S R S Dhulipala (srinid) Sent: Monday, November 09, 2009 3:12 PM To: ipsec@ietf.org Subject: [IPsec] EAP Identity request in IKEv2 =20 Hi, =20 I see that RFC4306 has the following lines at the end of Sec3.16: =20 Note that since IKE passes an indication of initiator identity in message 3 of the protocol, the responder SHOULD NOT send EAP Identity requests. The initiator SHOULD, however, respond to such requests if it receives them. =20 I see that from draft-ietf-ipsecme-ikev2bis-01, "SHOUD" and "SHOULD NOT" were demoted to "should" and "should not", the text now looks as below: =20 {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an indication of initiator identity in message 3 of the protocol, the responder should not send EAP Identity requests. The initiator may, however, respond to such requests if it receives them. =20 Also, "The initiator SHOULD" is now "The initiator may". =20 I would like to understand why these changes were done. Why do we need to do an EAP-ID request as IDi should carry an indication of the client's identity? =20 Thanks, Srinivas ------_=_NextPart_001_01CA62D2.C44458D2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Resending the query = again, as I did not see any response to this query.

 

It looks like = additional EAP ID request to the client is not needed, so I think we should = move

the = “should” to “SHOULD” again. Any thoughts?

 

Thanks,

Srinivas

 

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Srinivasu S R S Dhulipala (srinid)
Sent: Monday, November 09, 2009 3:12 PM
To: ipsec@ietf.org
Subject: [IPsec] EAP Identity request in = IKEv2

 

Hi,

 

I see that RFC4306 has the following lines at the = end of Sec3.16:

 

   Note that since IKE passes an indication of initiator identity = in

   message 3 of the protocol, the responder SHOULD NOT send EAP = Identity

   requests.  The initiator SHOULD, however, respond to such requests = if

   it receives them.

 

I see that from draft-ietf-ipsecme-ikev2bis-01, “SHOUD” and “SHOULD NOT” were demoted = to

“should” and “should not”, = the text now looks as below:

 

   {{ Demoted the SHOULD NOT and SHOULD }} Note that =
since IKE passes an
   indication of =
initiator identity in message 3 of the protocol, =
the
   responder should not send EAP =
Identity requests.  The initiator =
may,
   however, respond to such requests =
if it receives them.

 

Also, “The initiator SHOULD” is now = “The initiator may”.

 

I would like to understand why these changes were = done. Why do we need to do an EAP-ID

request as IDi should carry an indication of the client’s identity?

 

Thanks,

Srinivas

------_=_NextPart_001_01CA62D2.C44458D2-- From srinid@cisco.com Wed Nov 11 05:39:20 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256E528C326 for ; Wed, 11 Nov 2009 05:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA2dNPyQRgHh for ; Wed, 11 Nov 2009 05:39:19 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4790428C324 for ; Wed, 11 Nov 2009 05:39:19 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAH9N+kpAaHte/2dsb2JhbADEH5gZgjeCBQSBa3s X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208";a="103538734" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2009 13:39:47 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nABDdj0o025345; Wed, 11 Nov 2009 13:39:46 GMT Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 19:09:45 +0530 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2009 19:09:44 +0530 Message-ID: <3A8C969225424C4D8E6BEE65ED8552DA4C446E@XMB-BGL-41C.cisco.com> In-Reply-To: <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Clarification on identities involved in IKEv2EAP authentication Thread-Index: Acph/T6sbxIgyziASaiLecrXjL4UOAA1qQFw References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com> <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com> From: "Srinivasu S R S Dhulipala (srinid)" To: "Yoav Nir" , "Amjad Inamdar (amjads)" X-OriginalArrivalTime: 11 Nov 2009 13:39:45.0536 (UTC) FILETIME=[6E39F000:01CA62D4] Cc: ipsec@ietf.org Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAP authentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 13:39:20 -0000 Hi Yoav, Please see inline for [SRINI]. Thanks, Srinivas -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Tuesday, November 10, 2009 5:29 PM To: Amjad Inamdar (amjads) Cc: ipsec@ietf.org Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAP authentication On Nov 10, 2009, at 1:40 PM, Amjad Inamdar (amjads) wrote: > Hi, > > With IKEv2 EAP authentication, there are 3 identities involved > > 1) IDi - IKEv2 initiator identity sent in msg-3 > 2) EAP identity that gateway (IKE2 responder) can request from the=20 > client (IKEv2 initiator) > 3) Authenticated EAP identity that third party EAP server provides to=20 > the gateway (IKEv2 responder). > > > Could someone please clarify from RFC standpoint if > > 1) The 3 identities mentioned above MUST/SHOULD be same No, although they typically are. > 2) If not same, what purpose should each of the above identities serve 1) mainly used as a hint for the gateway as to which AAA server to choose 2) It's the AAA server that may request the identity, and it's internal to AAA. It doesn't play in IKE [SRINI] Does this imply that gateway SHOULD not send EAP identity request to the client, we see that one 3rd party IKEv2 client is sending IP address as IDi, from which we can't take any hints. Moreover, the same client is expecting an EAP-ID request to be sent, else EAP is failing. I've started another thread about why did we demote "SHOULD" to "should" if the gateway is Not supposed to send EAP-identity request to the client. I think we should promote it back. 3) That's the authenticated identity of the user. That is what the responder uses for policy decisions. > 3) The mandatory/recommended format for each of the above identites All the types in section 3.5 are acceptable, but the most used ones are ID_RFC822_ADDR and ID_DER_ASN1_DN From ynir@checkpoint.com Wed Nov 11 05:52:43 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB79028C1B4 for ; Wed, 11 Nov 2009 05:52:43 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtE7O2UsRB6Q for ; Wed, 11 Nov 2009 05:52:43 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8124528C1A9 for ; Wed, 11 Nov 2009 05:52:42 -0800 (PST) X-CheckPoint: {4AFABEA1-0-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6DEE12AC002; Wed, 11 Nov 2009 15:53:06 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3CCFD29C01C; Wed, 11 Nov 2009 15:53:06 +0200 (IST) X-CheckPoint: {4AFABE9E-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nABDr5c6006861; Wed, 11 Nov 2009 15:53:05 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 11 Nov 2009 15:53:08 +0200 From: Yoav Nir To: "Srinivasu S R S Dhulipala (srinid)" Date: Wed, 11 Nov 2009 15:53:02 +0200 Thread-Topic: [IPsec] Clarification on identities involved in IKEv2EAP authentication Thread-Index: Acpi1kw291b4GgRjTrOgPf4P8xKyKA== Message-ID: <39008D85-3D9B-4B8B-A9FA-C4C91658630E@checkpoint.com> References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com> <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com> <3A8C969225424C4D8E6BEE65ED8552DA4C446E@XMB-BGL-41C.cisco.com> In-Reply-To: <3A8C969225424C4D8E6BEE65ED8552DA4C446E@XMB-BGL-41C.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-10-467508548"; protocol="application/pkcs7-signature" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "Amjad Inamdar \(amjads\)" Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAP authentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 13:52:43 -0000 --Apple-Mail-10-467508548 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 11, 2009, at 3:39 PM, Srinivasu S R S Dhulipala (srinid) wrote: >=20 >> 2) If not same, what purpose should each of the above identities = serve >=20 > 1) mainly used as a hint for the gateway as to which AAA server to > choose > 2) It's the AAA server that may request the identity, and it's > internal to AAA. It doesn't play in IKE >=20 > [SRINI] Does this imply that gateway SHOULD not send EAP identity > request to the client, > we see that one 3rd party IKEv2 client is sending IP = address > as IDi, from which we can't > take any hints. Moreover, the same client is expecting an > EAP-ID request to be sent, > else EAP is failing. > I've started another thread about why did we demote = "SHOULD" > to "should" if the gateway is > Not supposed to send EAP-identity request to the client. I > think we should promote it back. The gateway never sends any EAP identity requests at all. If such a = request exists, it is sent by the AAA server. The gateway serves only as = a pass-through. For that reason, there is typically no reason for the gateway to inspect = the contents of the EAP payload. --Apple-Mail-10-467508548 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEHWPmpet94anoiUADSB7pZcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUxOTIxMDYyOFoXDTEwMDUxOTIxMDYy OFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN5Dac6srAGq YgV/Ggt0eXG8MRQRMR1SmIXm66utqDjcJhKDwKeyV5ICqQFr8ETbYZ7YgvSkXE7o9StCeqVvxKt0 hR5DTjho49VrCiaKex3q6d/VNh6E22yBqZBYbVa5xsxcPK6V2g/GXhyoNjoezeRVlRm0bbQtscKt GOt5BJFjjL5Ns/x0MktYgn24NIDnsTJKPEXl7vQzpwp6tnJJuiz/ttdW+7PII8vTkoHZpNGPW/aS bLR01T8ga739zosQ57YAdkih69BMHb+Q9zpRoSyd6NGEQ124TtskwWSAPAvw3TF2p0NlMKBU02Bt B07zkCodlx6sqOxeX7nVML26zI8CAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAA+x/ZiahLKaSb/kWVGx2gJAGAG5 C065lmMky3hmur1IfUa9GBXJO40Z4CdiD6Y/4wQgHkBPnRF4YdhMjd2ecE03/9+x4grNKaXaeiIl MXQtniPa1tO++O/8eaPiMx6AF+v4njB/q0CUpYF78fTloJuhflNPvdbV46Xj41fIDoFAMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB1j5qXrfeGp6IlAA0ge6WXMAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTExMTEz NTMwM1owIwYJKoZIhvcNAQkEMRYEFHeigY5tFDjf6CA4QBj4yJ3FhbFjMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdY+al633hqei JQANIHullzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQdY+al633hqeiJQANIHullzANBgkqhkiG9w0BAQEFAASCAQAEAUsjaJrL /QJ4uY8JURU5TdNQkSdsUZzWQ2bkn/i66s4j03EAOu8PobAOGiJOMevem3GB85s3cMJX4evF3Z8E WnBX4+GaATC/fHTeIPMoTJmrlAbOp/TyyrPtlFngdMYHeowSarmV/e46H5hm4QsZ+I9XqDQZSrLl PUbbwQWRnnj89RBMK3ZKHJW7wTMqJLNMhuXg/q+YySWD3p8sPZOv4RDNzWtIc7c0y7OVMlpJm4ax Zu/zmWKETf+b2A7IK8rWx8UiAqA5JCgW1V058h+bCAve/rF5lFMEDbZK2vjcMeBdpNogaO5ypNaB 7yJkyVMrRB21FNqa65NrVDgU8+OMAAAAAAAA --Apple-Mail-10-467508548-- From srinid@cisco.com Wed Nov 11 06:05:11 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D86C28C19A for ; Wed, 11 Nov 2009 06:05:11 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5GmRpe6NpSO for ; Wed, 11 Nov 2009 06:05:10 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 75BF528C192 for ; Wed, 11 Nov 2009 06:05:10 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB9T+kqrRN+J/2dsb2JhbADEe5gegjeCBQSBa3s X-IronPort-AV: E=Sophos;i="4.44,723,1249257600"; d="scan'208";a="269484939" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 11 Nov 2009 14:05:38 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nABE5beB028512; Wed, 11 Nov 2009 14:05:38 GMT Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 19:35:36 +0530 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2009 19:35:35 +0530 Message-ID: <3A8C969225424C4D8E6BEE65ED8552DA4C4472@XMB-BGL-41C.cisco.com> In-Reply-To: <39008D85-3D9B-4B8B-A9FA-C4C91658630E@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Thread-Index: Acpi1kw291b4GgRjTrOgPf4P8xKyKAAAWeZg References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com> <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com> <3A8C969225424C4D8E6BEE65ED8552DA4C446E@XMB-BGL-41C.cisco.com> <39008D85-3D9B-4B8B-A9FA-C4C91658630E@checkpoint.com> From: "Srinivasu S R S Dhulipala (srinid)" To: "Yoav Nir" X-OriginalArrivalTime: 11 Nov 2009 14:05:36.0300 (UTC) FILETIME=[0A8DBEC0:01CA62D8] Cc: ipsec@ietf.org, "Amjad Inamdar \(amjads\)" Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 14:05:11 -0000 Hi Yoav, Thanks for the quick response. Please see inline. -----Original Message----- From: Yoav Nir [mailto:ynir@checkpoint.com]=20 Sent: Wednesday, November 11, 2009 7:23 PM To: Srinivasu S R S Dhulipala (srinid) Cc: Amjad Inamdar (amjads); ipsec@ietf.org Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication On Nov 11, 2009, at 3:39 PM, Srinivasu S R S Dhulipala (srinid) wrote: >=20 >> 2) If not same, what purpose should each of the above identities serve >=20 > 1) mainly used as a hint for the gateway as to which AAA server to > choose > 2) It's the AAA server that may request the identity, and it's > internal to AAA. It doesn't play in IKE >=20 > [SRINI] Does this imply that gateway SHOULD not send EAP identity > request to the client, > we see that one 3rd party IKEv2 client is sending IP address > as IDi, from which we can't > take any hints. Moreover, the same client is expecting an > EAP-ID request to be sent, > else EAP is failing. > I've started another thread about why did we demote "SHOULD" > to "should" if the gateway is > Not supposed to send EAP-identity request to the client. I > think we should promote it back. The gateway never sends any EAP identity requests at all. If such a request exists, it is sent by the AAA server. The gateway serves only as a pass-through. [SRINI] Text below from sec 3.16 of the bis hints that responder may send, but it says It should not. In RFC 4306, it was "SHOULD NOT", in the bis it is "should not". =20 {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an indication of initiator identity in message 3 of the protocol, the responder should not send EAP Identity requests. The initiator may, however, respond to such requests if it receives them. Thanks, Srinivas For that reason, there is typically no reason for the gateway to inspect the contents of the EAP payload. From ynir@checkpoint.com Wed Nov 11 06:11:49 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8B328C187 for ; Wed, 11 Nov 2009 06:11:49 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAV3nvwzPzkL for ; Wed, 11 Nov 2009 06:11:47 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 00F003A687C for ; Wed, 11 Nov 2009 06:11:47 -0800 (PST) X-CheckPoint: {4AFAC31A-6-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B102429C004; Wed, 11 Nov 2009 16:12:14 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 9449229C002; Wed, 11 Nov 2009 16:12:14 +0200 (IST) X-CheckPoint: {4AFAC31A-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nABECDc6012140; Wed, 11 Nov 2009 16:12:14 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 11 Nov 2009 16:12:16 +0200 From: Yoav Nir To: "Srinivasu S R S Dhulipala (srinid)" Date: Wed, 11 Nov 2009 16:12:11 +0200 Thread-Topic: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Thread-Index: Acpi2PjABhslUgobT2munaiqCel1RQ== Message-ID: <4A5E60B4-E903-441F-A839-09FE9198B468@checkpoint.com> References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com> <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com> <3A8C969225424C4D8E6BEE65ED8552DA4C446E@XMB-BGL-41C.cisco.com> <39008D85-3D9B-4B8B-A9FA-C4C91658630E@checkpoint.com> <3A8C969225424C4D8E6BEE65ED8552DA4C4472@XMB-BGL-41C.cisco.com> In-Reply-To: <3A8C969225424C4D8E6BEE65ED8552DA4C4472@XMB-BGL-41C.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-11-468657087"; protocol="application/pkcs7-signature" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "Amjad Inamdar \(amjads\)" Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 14:11:49 -0000 --Apple-Mail-11-468657087 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The text is a little vague here, because the draft only describes the = use of EAP, and does not mandate anything for an AAA server. If the gateway is also the EAP authenticator, then it makes no sense to = send the identity request, because the reply has already been received = in packet #3. If the EAP authenticator is separate, it still does not make sense, as = the gateway could have passed the identity hint to the authenticator. = But some AAA servers always begin a session by requesting an identity. = We don't want to make their use a SHOULD NOT. We don't want to mandate = anything for them. So we accept that some servers may send an identity = request even though the hint is already given. Since the gateway acts as a pass-through, the requirement here is more = for the client, which is typically more integrated. The client should be = prepared to give an identity hint both in IKE and later in the EAP = session. On Nov 11, 2009, at 4:05 PM, Srinivasu S R S Dhulipala (srinid) wrote: > Hi Yoav, >=20 > Thanks for the quick response. Please see inline. >=20 > -----Original Message----- > From: Yoav Nir [mailto:ynir@checkpoint.com]=20 > Sent: Wednesday, November 11, 2009 7:23 PM > To: Srinivasu S R S Dhulipala (srinid) > Cc: Amjad Inamdar (amjads); ipsec@ietf.org > Subject: Re: [IPsec] Clarification on identities involved in > IKEv2EAPauthentication >=20 >=20 > On Nov 11, 2009, at 3:39 PM, Srinivasu S R S Dhulipala (srinid) wrote: >>=20 >>> 2) If not same, what purpose should each of the above identities > serve >>=20 >> 1) mainly used as a hint for the gateway as to which AAA server to >> choose >> 2) It's the AAA server that may request the identity, and it's >> internal to AAA. It doesn't play in IKE >>=20 >> [SRINI] Does this imply that gateway SHOULD not send EAP identity >> request to the client, >> we see that one 3rd party IKEv2 client is sending IP > address >> as IDi, from which we can't >> take any hints. Moreover, the same client is expecting an >> EAP-ID request to be sent, >> else EAP is failing. >> I've started another thread about why did we demote > "SHOULD" >> to "should" if the gateway is >> Not supposed to send EAP-identity request to the client. I >> think we should promote it back. >=20 > The gateway never sends any EAP identity requests at all. If such a > request exists, it is sent by the AAA server. The gateway serves only = as > a pass-through. >=20 > [SRINI] Text below from sec 3.16 of the bis hints that responder may > send, but it says > It should not. In RFC 4306, it was "SHOULD NOT", in the bis > it is "should not". >=20 > {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes = an > indication of initiator identity in message 3 of the protocol, the > responder should not send EAP Identity requests. The initiator may, > however, respond to such requests if it receives them. >=20 > Thanks, > Srinivas >=20 > For that reason, there is typically no reason for the gateway to = inspect > the contents of the EAP payload. >=20 >=20 >=20 > Scanned by Check Point Total Security Gateway. --Apple-Mail-11-468657087 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEHWPmpet94anoiUADSB7pZcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUxOTIxMDYyOFoXDTEwMDUxOTIxMDYy OFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN5Dac6srAGq YgV/Ggt0eXG8MRQRMR1SmIXm66utqDjcJhKDwKeyV5ICqQFr8ETbYZ7YgvSkXE7o9StCeqVvxKt0 hR5DTjho49VrCiaKex3q6d/VNh6E22yBqZBYbVa5xsxcPK6V2g/GXhyoNjoezeRVlRm0bbQtscKt GOt5BJFjjL5Ns/x0MktYgn24NIDnsTJKPEXl7vQzpwp6tnJJuiz/ttdW+7PII8vTkoHZpNGPW/aS bLR01T8ga739zosQ57YAdkih69BMHb+Q9zpRoSyd6NGEQ124TtskwWSAPAvw3TF2p0NlMKBU02Bt B07zkCodlx6sqOxeX7nVML26zI8CAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAA+x/ZiahLKaSb/kWVGx2gJAGAG5 C065lmMky3hmur1IfUa9GBXJO40Z4CdiD6Y/4wQgHkBPnRF4YdhMjd2ecE03/9+x4grNKaXaeiIl MXQtniPa1tO++O/8eaPiMx6AF+v4njB/q0CUpYF78fTloJuhflNPvdbV46Xj41fIDoFAMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB1j5qXrfeGp6IlAA0ge6WXMAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTExMTE0 MTIxMVowIwYJKoZIhvcNAQkEMRYEFPk/wF4ew19pra7ZGJY2m3cZ4ADlMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdY+al633hqei JQANIHullzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQdY+al633hqeiJQANIHullzANBgkqhkiG9w0BAQEFAASCAQCy8Iy2+Xap KPx6zPIK6m20jmajGfIqOFqh5fpZyLk7VBdL/YbMkVqY8bVvdxrZ5ZEu3hNHkQgkFZdV6cgNgDlY /F2taK1WQfrUagCytTHiQGishABqFFseu4rY1EwHg7CVdvsPlVN3qxvl4LM7Y44nWc5U0ThI0c6g ZkhpPNAyGmkXxFF2ArVO87FVNK7OAoKv0as6pE9mFu9HJ719YB+CBG4iG6RB83Ljj4qNALBu4/Cn aYsBaf5c2XVSeZu/zsYhLzBUd8xsHcMceYCyc5C9kskW+y5mDN98+nsLn/D98RgE/BdYRle4d30K hjTnun1idPCR4nmjGEmMpNE3ejYkAAAAAAAA --Apple-Mail-11-468657087-- From kohn.jack@gmail.com Wed Nov 11 08:05:33 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388883A6900 for ; Wed, 11 Nov 2009 08:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+KOOuMovmnO for ; Wed, 11 Nov 2009 08:05:32 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 466C13A69E0 for ; Wed, 11 Nov 2009 08:05:32 -0800 (PST) Received: by ywh13 with SMTP id 13so1262072ywh.29 for ; Wed, 11 Nov 2009 08:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=vEFo4USUK3SY5Rzqjw90ook0Wselq0M4oXpnZKKX42U=; b=ZY23GkIQryFM5VrRlKetSkLmlpOEDQCWo6t50SOboMgUvF3469C/gYUeNN1Lxm5IBc bVoCiPumMnEck18qF0O/KxxsbS9caoUrCqsOmPsVnBpsL5fcmfPJA5+2t3uIX/wjKEcp tWItDq0L1guYIJsMparNasyWBymGfjcvyJFZY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=V6mCb1pZ0P8bw74ijOBumGOH1Ea47dTjV+kJ7PBwRGnexjmWFxLM1T5kt9ivsy51YE vSU2mfw43Jp33NuCTO/2aX88uNnaBLl+5vXBkAQOoLZOquQEma6Cse3MnF2PQM9J8CdV u2Hl/XuyEAvyZLf3mziBJsT+G9dRRQpRCD/I4= MIME-Version: 1.0 Received: by 10.91.183.4 with SMTP id k4mr2681010agp.41.1257955555939; Wed, 11 Nov 2009 08:05:55 -0800 (PST) Date: Wed, 11 Nov 2009 21:35:55 +0530 Message-ID: From: Jack Kohn To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=0016e64655240e155f04781a9a81 Subject: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 16:05:33 -0000 --0016e64655240e155f04781a9a81 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, >From operational perspective if we are supporting both v4 and v6 (and we will) then having different protocols ESP and AH is and will be a nightmare. Common denominator is ESP-Null. However, there were issues with ESP-Null as it couldnt be deep inspected which has now been solved with WESP. In short, the argument that "Oh, but we can inspect AH packets" is not relevant anymore. Given this, should we still have AH as a MAY for IPSEC - Cant we deprecate it? WESP is ESP++, and it offers everthing that ESP offers plus more. What is our stance for ESP moving forward? Also, I see that a lot of work done in other WGs is still using ESP (primarily for data integrity). Shouldn=92t they be moving to WESP, as WESP offers more flexibility? Jack --0016e64655240e155f04781a9a81 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,

From operational perspective if we are supporting both v4 and v6= (and we will) then having different protocols ESP and AH is and will be a = nightmare.=A0 Common denominator is ESP-Null. However, there were issues wi= th ESP-Null as it couldnt be deep inspected which has now been solved with = WESP.

In short, the argument that "Oh, but we can inspect AH packets&quo= t; is not relevant anymore.

Given this, should we still have AH as a= MAY for IPSEC - Cant we deprecate it?

WESP is ESP++, and it offers= everthing that ESP offers plus more. What is our stance for ESP moving for= ward?

Also, I see that a lot of work done in other WGs is still using ESP (pr= imarily for data integrity). Shouldn=92t they be moving to WESP, as WESP of= fers more flexibility?

Jack

--0016e64655240e155f04781a9a81-- From lelaw@tycho.ncsc.mil Tue Nov 10 14:15:10 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254C43A6A87 for ; Tue, 10 Nov 2009 14:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGjIrUiXnMJk for ; Tue, 10 Nov 2009 14:15:09 -0800 (PST) Received: from msux-gh1-uea02.nsa.gov (msux-gh1-uea02.nsa.gov [63.239.67.2]) by core3.amsl.com (Postfix) with ESMTP id 470033A6A3E for ; Tue, 10 Nov 2009 14:15:09 -0800 (PST) Received: from smtp.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id nAAMHaDc021987 for ; Tue, 10 Nov 2009 22:17:36 GMT Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6253.541AA1F5" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 10 Nov 2009 17:15:36 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC4869 bis submitted Thread-Index: AcpiU1O0nSZrevdBSBW8DNVZupILgA== From: "Law, Laurie" To: X-Mailman-Approved-At: Wed, 11 Nov 2009 08:07:28 -0800 Subject: [IPsec] RFC4869 bis submitted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 22:37:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6253.541AA1F5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable A bis has been submitted for RFC 4869, "Suite B Cryptographic Suites for IPsec". It is available at http://tools.ietf.org/html/draft-law-rfc4869bis-00=20 =20 This Internet-Draft makes several minor changes to the suites in RFC 4869 and incorporates comments that have been posted to the ipsec mailing list. =20 Laurie Law National Information Assurance Research Laboratory National Security Agency ------_=_NextPart_001_01CA6253.541AA1F5 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

A bis has been submitted for RFC 4869, "Suite = B=20 Cryptographic Suites for IPsec". It is available at http://tools.ietf.org/html/draft-law-rfc4869bis-00 =
 
This = Internet-Draft=20 makes several minor changes to the suites in RFC 4869 = and incorporates=20 comments that have been posted to the ipsec mailing = list.
 
Laurie = Law
National Information=20 Assurance Research Laboratory
National Security=20 Agency
------_=_NextPart_001_01CA6253.541AA1F5-- From welterk@us.ibm.com Wed Nov 11 11:42:32 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697A53A68CC for ; Wed, 11 Nov 2009 11:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qY24FRckBFqd for ; Wed, 11 Nov 2009 11:42:30 -0800 (PST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id 9215A3A6830 for ; Wed, 11 Nov 2009 11:42:30 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nABJegGr028843 for ; Wed, 11 Nov 2009 12:40:42 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nABJgZw7039400 for ; Wed, 11 Nov 2009 12:42:35 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nABJgW2c011509 for ; Wed, 11 Nov 2009 12:42:32 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nABJgWjB011506 for ; Wed, 11 Nov 2009 12:42:32 -0700 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 2772CC5D:A3AE43C1-8825766B:0069F220; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/11/2009 11:42:27 AM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/11/2009 11:42:27 AM, Serialize complete at 11/11/2009 11:42:27 AM, S/MIME Sign failed at 11/11/2009 11:42:27 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 11/11/2009 12:42:31, Serialize complete at 11/11/2009 12:42:31 Message-ID: Date: Wed, 11 Nov 2009 11:42:30 -0800 Content-Type: multipart/alternative; boundary="=_alternative 006C41DA8825766B_=" Subject: Re: [IPsec] Closing the IKEv2bis open issues X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 19:42:32 -0000 This is a multipart message in MIME format. --=_alternative 006C41DA8825766B_= Content-Type: text/plain; charset="US-ASCII" > Issue #22, Add section on simultaneous IKE SA rekey > > There is no consensus on this issue. Tero Kivinen and David Wierbowski have deep differences of > opinion, and almost no one else has participated. I have reviewed the discussion, and I think > both people have strong merits to their opinion. Therefore, Yaron and I will try to coordinate > a design team effort that includes Tero, David, and any others who have thought about this issue > in depth. If that fails to come out with an agreed-to solution, we will probably drop back to > adding a short, inconclusive, descriptive > note in the IKEv2bis document. A design team was convened including Dan McDonald, Tero Kivinen, Raj Singh, David Wierbowski and Keith Welter to resolve Issue #22. The design team reached agreement on the following general approach as well as specific proposed text: - Import text from RFC 4718 section 5.11.10 into new ikev2biz draft section 2.25 "Exchange Collisions" - Replace NO_PROPOSAL_CHOSEN and NO_ADDITIONAL_SAS with new TEMPORARY_FAILURE error type notify. - Add new CHILD_SA_NOT_FOUND error type notify for one collision case. - Add text in new section 2.25 describing what to do when the new notify types are received. The proposed text that follows includes a new section and updates to existing sections for ikev2bis. 2.25 Exchange Collisions (New Section) Since IKEv2 exchanges can be initiated by both peers, it is possible that two exchanges affecting the same SA partly overlap. This can lead to a situation where the SA state information is temporarily not synchronized, and a peer can receive a request it cannot process in a normal fashion. Obviously, using a window size greater than one leads to more complex situations, especially if requests are processed out of order. In this section, we concentrate on problems that can arise even with window size 1 and recommend solutions. A TEMPORARY_FAILURE notification SHOULD be sent when a host receives a request that cannot be completed due to a temporary condition such as a rekeying operation. When a host receives a TEMPORARY_FAILURE notification, it MUST NOT immediately retry the operation but wait so that the sender may complete whatever operation caused the temporary condition. The recipient MAY retry the request one or more times over a period of several minutes. If a host continues to receive TEMPORARY_FAILURE on the same IKE SA after several minutes then it SHOULD conclude that state information is out-of-sync and close the IKE SA. A CHILD_SA_NOT_FOUND notification SHOULD be sent when a host receives a request to rekey a Child SA that does not exist. A host that receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA and send a request to create a new Child SA from scratch. If a host receives a request to rekey: o a Child SA that the host is currently trying to close: reply with TEMPORARY_FAILURE. o a Child SA that the host is currently rekeying: reply as usual, but prepare to close redundant SAs later based on the nonces. o a Child SA that does not exist: reply with CHILD_SA_NOT_FOUND. o the IKE SA, and the host is currently rekeying the IKE SA: reply as usual, but prepare to close redundant SAs and move inherited Child SAs later based on the nonces. o the IKE SA, and the host is currently creating, rekeying, or closing a Child SA: reply with TEMPORARY_FAILURE. o the IKE SA, and the host is currently trying to close the IKE SA: reply with TEMPORARY_FAILURE. If a host receives a request to close: o a Child SA that the host is currently trying to close: reply without Delete payloads. o a Child SA that the host is currently rekeying: reply as usual, with Delete payload. o a Child SA that does not exist: reply without Delete payloads. o the IKE SA, and the host is currently rekeying the IKE SA: reply as usual, and forget about our own rekeying request. o the IKE SA, and the host is currently trying to close the IKE SA: reply as usual, and forget about our own close request. If a host receives a request to create or rekey a CHILD_SA when it is currently rekeying the IKE_SA: reply with TEMPORARY_FAILURE. If a host receives a request to delete a Child SA when it is currently rekeying the IKE SA: reply as usual, with Delete payload. 3.10.1. Notify Message Types (Updates) ... NOTIFY messages: error types Value ------------------------------------------------------------------- ... TEMPORARY_FAILURE 40 See section 2.25. CHILD_SA_NOT_FOUND 41 See section 2.25. RESERVED TO IANA 42-8191 ... 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange (Updates) Add the following sentence to the end of the first paragraph of section 1.3.2: "Once a host receives a request to rekey an IKE SA or sends a request to rekey an IKE SA it SHOULD NOT start any new CREATE_CHILD_SA exchanges on the IKE SA being rekeyed." The new paragraph should now read: "The initiator sends SA offer(s) in the SA payload, a nonce in the Ni payload, and a Diffie-Hellman value in the KEi payload. The KEi payload MUST be included. New initiator and responder SPIs are supplied in the SPI fields of the SA payload. Once a host receives a request to rekey an IKE SA or sends a request to rekey an IKE SA it SHOULD NOT start any new CREATE_CHILD_SA exchanges on the IKE SA being rekeyed." 2.8.2. Simultaneous IKE SA Rekeying (Updates) Update the second paragraph so that it reads as follows: "The case where both endpoints notice the simultaneous rekeying works the same way as with Child SAs. After the CREATE_CHILD_SA exchanges, three IKE SAs exist between A and B; the old IKE SA and two new IKE SAs. The new IKE SA containing the lowest nonce inherits the Child SAs. If only one side detects a simultaneous rekey then redundant SAs are not created. In this case, when the end which didn't notice the simultaneous rekey gets the request to rekey the IKE SA that it has already successfully rekeyed, it will return TEMPORARY_FAILURE as it is an IKE SA it is currently trying to close (whether it has already sent the delete notification for it or not). If the end which did notice the simultaneous rekey gets the delete from the other end for the old IKE SA then it knows that the other end didn't detect simultaneous rekey, and it can forget its own rekey attempt." Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) --=_alternative 006C41DA8825766B_= Content-Type: text/html; charset="US-ASCII"
> Issue #22, Add section on simultaneous IKE SA rekey
> <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/22>
> There is no consensus on this issue. Tero Kivinen and David Wierbowski have deep differences of
> opinion, and almost no one else has participated. I have reviewed the discussion, and I think
> both people have strong merits to their opinion. Therefore, Yaron and I will try to coordinate
> a design team effort that includes Tero, David, and any others who have thought about this issue
> in depth. If that fails to come out with an agreed-to solution, we will probably drop back to
> adding a short, inconclusive, descriptive > note in the IKEv2bis document.

A design team was convened including Dan McDonald, Tero Kivinen, Raj Singh, David Wierbowski and Keith Welter to resolve Issue #22.  The design team reached agreement on the following general approach as well as specific proposed text:
- Import text from RFC 4718 section 5.11.10 into new ikev2biz draft section 2.25 "Exchange Collisions"
- Replace NO_PROPOSAL_CHOSEN and NO_ADDITIONAL_SAS with new TEMPORARY_FAILURE error type notify.
- Add new CHILD_SA_NOT_FOUND error type notify for one collision case.
- Add text in new section 2.25 describing what to do when the new notify types are received.

The proposed text that follows includes a new section and updates to existing sections for ikev2bis.

2.25 Exchange Collisions (New Section)

Since IKEv2 exchanges can be initiated by both peers, it is possible
that two exchanges affecting the same SA partly overlap. This can
lead to a situation where the SA state information is temporarily not
synchronized, and a peer can receive a request it cannot process in a
normal fashion.

Obviously, using a window size greater than one leads to
more complex situations, especially if requests are processed out of
order. In this section, we concentrate on problems that can arise
even with window size 1 and recommend solutions.

A TEMPORARY_FAILURE notification SHOULD be sent when a host receives
a request that cannot be completed due to a temporary condition such
as a rekeying operation. When a host receives a TEMPORARY_FAILURE
notification, it MUST NOT immediately retry the operation but wait so
that the sender may complete whatever operation caused the temporary
condition. The recipient MAY retry the request one or more times over
a period of several minutes. If a host continues to receive
TEMPORARY_FAILURE on the same IKE SA after several minutes then it
SHOULD conclude that state information is out-of-sync and close the
IKE SA.

A CHILD_SA_NOT_FOUND notification SHOULD be sent when a host receives
a request to rekey a Child SA that does not exist. A host that
receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the
Child SA and send a request to create a new Child SA from scratch.

If a host receives a request to rekey:

o a Child SA that the host is currently trying to close: reply
with TEMPORARY_FAILURE.

o a Child SA that the host is currently rekeying: reply as
usual, but prepare to close redundant SAs later based on the
nonces.

o a Child SA that does not exist: reply with
CHILD_SA_NOT_FOUND.

o the IKE SA, and the host is currently rekeying the IKE SA: reply
as usual, but prepare to close redundant SAs and move inherited
Child SAs later based on the nonces.

o the IKE SA, and the host is currently creating, rekeying,
or closing a Child SA: reply with TEMPORARY_FAILURE.

o the IKE SA, and the host is currently trying to close the IKE SA:
reply with TEMPORARY_FAILURE.

If a host receives a request to close:

o a Child SA that the host is currently trying to close: reply
without Delete payloads.

o a Child SA that the host is currently rekeying: reply as
usual, with Delete payload.

o a Child SA that does not exist: reply without Delete
payloads.

o the IKE SA, and the host is currently rekeying the IKE SA: reply
as usual, and forget about our own rekeying request.

o the IKE SA, and the host is currently trying to close the IKE SA:
reply as usual, and forget about our own close request.

If a host receives a request to create or rekey a CHILD_SA when it is
currently rekeying the IKE_SA: reply with TEMPORARY_FAILURE.

If a host receives a request to delete a Child SA when it is
currently rekeying the IKE SA:
reply as usual, with Delete payload.


3.10.1. Notify Message Types (Updates)
...
NOTIFY messages: error types Value
-------------------------------------------------------------------
...
TEMPORARY_FAILURE 40
See section 2.25.

CHILD_SA_NOT_FOUND 41
See section 2.25.

RESERVED TO IANA 42-8191
...

1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange (Updates)

Add the following sentence to the end of the first paragraph of section 1.3.2:
"Once a host receives a request to rekey an IKE SA or sends a request to rekey
an IKE SA it SHOULD NOT start any new CREATE_CHILD_SA exchanges on the IKE SA
being rekeyed."

The new paragraph should now read:
"The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
payload, and a Diffie-Hellman value in the KEi payload. The KEi
payload MUST be included. New initiator and responder SPIs are
supplied in the SPI fields of the SA payload. Once a host receives
a request to rekey an IKE SA or sends a request to rekey an IKE SA
it SHOULD NOT start any new CREATE_CHILD_SA exchanges on the IKE SA
being rekeyed."

2.8.2. Simultaneous IKE SA Rekeying (Updates)

Update the second paragraph so that it reads as follows:
"The case where both endpoints notice the simultaneous rekeying works
the same way as with Child SAs. After the CREATE_CHILD_SA exchanges,
three IKE SAs exist between A and B; the old IKE SA and two new IKE SAs.
The new IKE SA containing the lowest nonce inherits the Child SAs.
If only one side detects a simultaneous rekey then redundant SAs are
not created. In this case, when the end which didn't notice the
simultaneous rekey gets the request to rekey the IKE SA that it has
already successfully rekeyed, it will return TEMPORARY_FAILURE as it
is an IKE SA it is currently trying to close (whether it has already
sent the delete notification for it or not). If the end which did
notice the simultaneous rekey gets the delete from the other end for
the old IKE SA then it knows that the other end didn't detect
simultaneous rekey, and it can forget its own rekey attempt."

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)
 --=_alternative 006C41DA8825766B_=-- From ynir@checkpoint.com Wed Nov 11 12:12:02 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9763528C0D9 for ; Wed, 11 Nov 2009 12:12:02 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOL4UqQp4SN1 for ; Wed, 11 Nov 2009 12:12:00 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 86F3F3A69B2 for ; Wed, 11 Nov 2009 12:11:59 -0800 (PST) X-CheckPoint: {4AFB1784-2-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1339229C00B; Wed, 11 Nov 2009 22:12:27 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D65EF29C002; Wed, 11 Nov 2009 22:12:26 +0200 (IST) X-CheckPoint: {4AFB1783-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nABKCQc6014131; Wed, 11 Nov 2009 22:12:26 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 11 Nov 2009 22:12:28 +0200 From: Yoav Nir To: "Law, Laurie" , "ipsec@ietf.org" Date: Wed, 11 Nov 2009 22:07:31 +0200 Thread-Topic: RFC4869 bis submitted Thread-Index: AcpiU1O0nSZrevdBSBW8DNVZupILgAAt0Yk8 Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB3@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] RFC4869 bis submitted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 20:12:03 -0000 Hi If you're bissing this thing, can we please please please entirely get rid = of the requirement to use ECDSA certificates? While the algorithms and DH groups are subject to configuration in the UI a= nd negotiation in IKE, the algorithm used to sign the certificates is outsi= de the IKE implementation. You usually have a certificate that you need to = use, and it's the CA's decision whether this is signed with RSA, DSA or ECD= SA. There's even some ambiguity, because it's not necessarily true, that th= e public key in the certificate is for the same algorithms used to sign the= certificate. The UI suites RFC that defined VPN-A and VPN-B did not mandate RSA or DSA. = I don't see why 4869 or 4869-bis should. I don't think it's part of the alg= orithm configuration. Yoav ________________________________________ From: ipsec-bounces@ietf.org [ipsec-bounces@ietf.org] On Behalf Of Law, Lau= rie [lelaw@tycho.ncsc.mil] Sent: Wednesday, November 11, 2009 00:15 To: ipsec@ietf.org Subject: [IPsec] RFC4869 bis submitted A bis has been submitted for RFC 4869, "Suite B Cryptographic Suites for IP= sec". It is available at http://tools.ietf.org/html/draft-law-rfc4869bis-00 This Internet-Draft makes several minor changes to the suites in RFC 4869 a= nd incorporates comments that have been posted to the ipsec mailing list. Laurie Law National Information Assurance Research Laboratory National Security Agency From danmcd@sun.com Wed Nov 11 12:52:16 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8B693A692A for ; Wed, 11 Nov 2009 12:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YukBG5WGHm5J for ; Wed, 11 Nov 2009 12:52:16 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 0C13A3A684A for ; Wed, 11 Nov 2009 12:52:16 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nABKqehM019154; Wed, 11 Nov 2009 20:52:40 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nABKqeYO009521; Wed, 11 Nov 2009 15:52:40 -0500 (EST) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nABKqdcb109262; Wed, 11 Nov 2009 15:52:39 -0500 (EST) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id nABKqcDL109261; Wed, 11 Nov 2009 15:52:38 -0500 (EST) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Wed, 11 Nov 2009 15:52:38 -0500 From: Dan McDonald To: Yoav Nir Message-ID: <20091111205238.GK101633@sun.com> References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB3@il-ex01.ad.checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB3@il-ex01.ad.checkpoint.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "ipsec@ietf.org" , "Law, Laurie" Subject: Re: [IPsec] RFC4869 bis submitted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 20:52:16 -0000 On Wed, Nov 11, 2009 at 10:07:31PM +0200, Yoav Nir wrote: > While the algorithms and DH groups are subject to configuration in the UI > and negotiation in IKE, the algorithm used to sign the certificates is > outside the IKE implementation. You usually have a certificate that you > need to use, and it's the CA's decision whether this is signed with RSA, > DSA or ECDSA. There's even some ambiguity, because it's not necessarily > true, that the public key in the certificate is for the same algorithms > used to sign the certificate. I strongly agree with Yoav here. Especially given certificate operations are much rarer in IKEv2 (given their SAs last indefinitely long), would 2048-bit RSA or 4096-bit RSA certs be unreasonable? I understand the cert-chain issues with weak hashes, but those do not come directly into play during the IKE exchange. (Imagine self-signed certs for IKE, e.g.) > The UI suites RFC that defined VPN-A and VPN-B did not mandate RSA or > DSA. I don't see why 4869 or 4869-bis should. I don't think it's part of > the algorithm configuration. Also --> the new bis document talks about IKEv1's Phase 2 Diffie-Hellman as a MAY without saying it. I quote: Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2) MUST be supported by both parties in this suite. The initiator of this exchange MAY include a new Diffie-Hellman key; if it is included, it MUST use the 256-bit random ECP group. If the initiator of the exchange includes a Diffie-Hellman key, the responder MUST include a Diffie-Hellman key, and it MUST use the 256-bit random ECP group. Many IKEv1's have Phase 2 PFS as an on/off switch. It would be nice if you picked one for these (either always-on or always-off). Dan From kent@bbn.com Wed Nov 11 12:56:20 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B52153A692A for ; Wed, 11 Nov 2009 12:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNMeD2vVhTEJ for ; Wed, 11 Nov 2009 12:56:20 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 09D953A68D2 for ; Wed, 11 Nov 2009 12:56:20 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[133.93.112.234]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N8KFD-0001y4-Ay; Wed, 11 Nov 2009 15:56:47 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 11 Nov 2009 15:56:39 -0500 To: Jack Kohn From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ipsec@ietf.org Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 20:56:20 -0000 Jack, I would have no problem deprecating AH in the context of the IPsec architecture document, if others agree. It is less efficient than ESP-NULL. However, other WGs have cited AH as the IPsec protocol of choice for integrity/authentication in their environments, so there will be a need to coordinate with them, and it may be unacceptable to kill AH as a standalone protocol for them. I am not comfortable with the notion of ESP with WESP. WESP adds more per-packet overhead than ESP, and some users are very sensitive to this aspect of IPsec use. Also, other WG rely on ESP and we would need to convince them that the packet inspection features of WESP merit making changes to their standards, which might be a tough sell. So, I cannot support this suggestion. Steve From smoonen@us.ibm.com Wed Nov 11 13:06:34 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 308E33A6A7C; Wed, 11 Nov 2009 13:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4+dlYcrZVG1; Wed, 11 Nov 2009 13:06:32 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id CA86A3A6864; Wed, 11 Nov 2009 13:06:32 -0800 (PST) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e31.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nABKxpP2029087; Wed, 11 Nov 2009 13:59:51 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nABL6enk080704; Wed, 11 Nov 2009 14:06:41 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nABL6aFx011286; Wed, 11 Nov 2009 14:06:37 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nABL6aTO011282; Wed, 11 Nov 2009 14:06:36 -0700 In-Reply-To: References: To: Jack Kohn MIME-Version: 1.0 X-KeepSent: F6A67C78:1AD019EA-8525766B:00727DFC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/11/2009 04:04:31 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/11/2009 04:04:31 PM, Serialize complete at 11/11/2009 04:04:31 PM, S/MIME Sign failed at 11/11/2009 04:04:31 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 11/11/2009 14:06:35, Serialize complete at 11/11/2009 14:06:35 Message-ID: Date: Wed, 11 Nov 2009 16:06:34 -0500 Content-Type: multipart/alternative; boundary="=_alternative 0073C5508525766B_=" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 21:06:34 -0000 This is a multipart message in MIME format. --=_alternative 0073C5508525766B_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SmFjaywgSSdtIG5vdCBzdXJlIGl0J3MgY2xlYXIgeWV0IHdoZXRoZXIgV0VTUCB3aWxsIGJlIHdp ZGVseSBhZG9wdGVkLiANClRoZXJlJ3MgZGlzYWdyZWVtZW50IGJldHdlZW4gZW5kLW5vZGUgYW5k IG1pZGRsZS1ub2RlIGZvbGtzIGFzIHRvIHdoZXRoZXIgDQpXRVNQIG9yIGhldXJpc3RpY3MgYXJl IHRoZSBiZXN0IGFwcHJvYWNoIGZvciBpbnNwZWN0aW9uIG9mIEVTUC1OVUxMIA0KdHJhZmZpYy4g IEkgdGhpbmsgdGhhdCBlbmQtbm9kZSB2ZW5kb3JzIHdpbGwgYmUgdmVyeSByZWx1Y3RhbnQgdG8g YWRvcHQgDQpXRVNQIHdpZGVseSB1bnRpbCB0aGVyZSBpcyBicm9hZCBjdXN0b21lciBkZW1hbmQg Zm9yIGl0LCBhbmQgSSdtIG5vdCBzdXJlIA0KdGhhdCB0aGlzIGRlbWFuZCB3aWxsIGV2ZXIgbWF0 ZXJpYWxpemUuDQoNClRoaXMgaXMgYWxsIG15IHBlcnNvbmFsIG9waW5pb24sIG9mIGNvdXJzZS4g IEJ1dCBpdCBzZWVtcyB0byBtZSB0aGF0IA0KaGV1cmlzdGljcyB3aWxsIGhhdmUgdG8gYmUgYWRv cHRlZCBieSBjb21wZXRpdGl2ZSBtaWRkbGUtbm9kZSB2ZW5kb3JzLCBhbmQgDQp0aGVyZWZvcmUg KGJhcnJpbmcgYW55IGV4dGVuc2lvbnMgdG8gV0VTUCB0aGF0IG1ha2UgaXQgYXR0cmFjdGl2ZSBm b3IgDQpvdGhlciByZWFzb25zKSB0aGUgdXNlIG9mIGhldXJpc3RpY3Mgd2lsbCBwcm9iYWJseSBh bHdheXMgYmUgbW9yZSANCndpZGVzcHJlYWQgYW5kIHdpbGwgZGFtcGVuIHRoZSBkZW1hbmQgZm9y IFdFU1AuICBBZGRpdGlvbmFsbHksIEVTUC1OVUxMIA0KaXRzZWxmIGhhcyByYXRoZXIgbmFycm93 IGFwcGxpY2FiaWxpdHkgaW4gYW4gZW52aXJvbm1lbnQgd2hlcmUgZW5kLXRvLWVuZCANCmVuY3J5 cHRpb24gaXMgaW5jcmVhc2luZ2x5IGNvbW1vbiwgd2hpY2ggZnVydGhlciBsaW1pdHMgdGhlIGNh c2VzIHdoZXJlIA0KdGhlcmUgd2lsbCBiZSBhbiBhYnNvbHV0ZSBuZWVkIGZvciBXRVNQLiAgRnVy dGhlcm1vcmUsIHRoZXJlIHdpbGwgYWx3YXlzIA0KYmUgdmFsaWQgcmVhc29ucyB0byB1c2UgQUgg KHJlZHVjZWQgb3ZlcmhlYWQgY29tcGFyZWQgdG8gV0VTUCkuDQoNCkZvciByZWFzb25zIGxpa2Ug dGhlc2UsIEkgYmVsaWV2ZSBpdCdzIHByZW1hdHVyZSB0byBjYWxsIGZvciBkZXByZWNhdGlvbiAN Cm9mIEFIIGFuZCBldmVuIG1vcmUgcHJlbWF0dXJlIHRvIHN0YXJ0IHByZWZlcnJpbmcgV0VTUCB0 byBFU1AuDQoNCldoYXQgc3RhdHVzIHdpbGwgdGhlIFdFU1AgUkZDIGhhdmU/ICBFeHBlcmltZW50 YWwsIGluZm9ybWF0aW9uYWwsIA0Kc3RhbmRhcmRzIHRyYWNrLCBldGMuPw0KDQoNClNjb3R0IE1v b25lbiAoc21vb25lbkB1cy5pYm0uY29tKQ0Kei9PUyBDb21tdW5pY2F0aW9ucyBTZXJ2ZXIgVENQ L0lQIERldmVsb3BtZW50DQpodHRwOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9zbW9vbmVuDQoNCg0K DQpGcm9tOg0KSmFjayBLb2huIDxrb2huLmphY2tAZ21haWwuY29tPg0KVG86DQppcHNlY0BpZXRm Lm9yZw0KRGF0ZToNCjExLzExLzIwMDkgMTE6MDYgQU0NClN1YmplY3Q6DQpbSVBzZWNdIFdFU1Ag LSBSb2FkbWFwIEFoZWFkDQoNCg0KDQpIaSwNCg0KRnJvbSBvcGVyYXRpb25hbCBwZXJzcGVjdGl2 ZSBpZiB3ZSBhcmUgc3VwcG9ydGluZyBib3RoIHY0IGFuZCB2NiAoYW5kIHdlIA0Kd2lsbCkgdGhl biBoYXZpbmcgZGlmZmVyZW50IHByb3RvY29scyBFU1AgYW5kIEFIIGlzIGFuZCB3aWxsIGJlIGEg DQpuaWdodG1hcmUuICBDb21tb24gZGVub21pbmF0b3IgaXMgRVNQLU51bGwuIEhvd2V2ZXIsIHRo ZXJlIHdlcmUgaXNzdWVzIA0Kd2l0aCBFU1AtTnVsbCBhcyBpdCBjb3VsZG50IGJlIGRlZXAgaW5z cGVjdGVkIHdoaWNoIGhhcyBub3cgYmVlbiBzb2x2ZWQgDQp3aXRoIFdFU1AuDQoNCkluIHNob3J0 LCB0aGUgYXJndW1lbnQgdGhhdCAiT2gsIGJ1dCB3ZSBjYW4gaW5zcGVjdCBBSCBwYWNrZXRzIiBp cyBub3QgDQpyZWxldmFudCBhbnltb3JlLg0KDQpHaXZlbiB0aGlzLCBzaG91bGQgd2Ugc3RpbGwg aGF2ZSBBSCBhcyBhIE1BWSBmb3IgSVBTRUMgLSBDYW50IHdlIGRlcHJlY2F0ZSANCml0PyANCg0K V0VTUCBpcyBFU1ArKywgYW5kIGl0IG9mZmVycyBldmVydGhpbmcgdGhhdCBFU1Agb2ZmZXJzIHBs dXMgbW9yZS4gV2hhdCBpcyANCm91ciBzdGFuY2UgZm9yIEVTUCBtb3ZpbmcgZm9yd2FyZD8NCg0K QWxzbywgSSBzZWUgdGhhdCBhIGxvdCBvZiB3b3JrIGRvbmUgaW4gb3RoZXIgV0dzIGlzIHN0aWxs IHVzaW5nIEVTUCANCihwcmltYXJpbHkgZm9yIGRhdGEgaW50ZWdyaXR5KS4gU2hvdWxkbuKAmXQg dGhleSBiZSBtb3ZpbmcgdG8gV0VTUCwgYXMgV0VTUCANCm9mZmVycyBtb3JlIGZsZXhpYmlsaXR5 Pw0KDQpKYWNrDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KSVBzZWMgbWFpbGluZyBsaXN0DQpJUHNlY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0KDQoNCg0K --=_alternative 0073C5508525766B_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkphY2ssIEknbSBub3Qgc3VyZSBp dCdzIGNsZWFyIHlldCB3aGV0aGVyDQpXRVNQIHdpbGwgYmUgd2lkZWx5IGFkb3B0ZWQuICZuYnNw O1RoZXJlJ3MgZGlzYWdyZWVtZW50IGJldHdlZW4gZW5kLW5vZGUNCmFuZCBtaWRkbGUtbm9kZSBm b2xrcyBhcyB0byB3aGV0aGVyIFdFU1Agb3IgaGV1cmlzdGljcyBhcmUgdGhlIGJlc3QgYXBwcm9h Y2gNCmZvciBpbnNwZWN0aW9uIG9mIEVTUC1OVUxMIHRyYWZmaWMuICZuYnNwO0kgdGhpbmsgdGhh dCBlbmQtbm9kZSB2ZW5kb3JzDQp3aWxsIGJlIHZlcnkgcmVsdWN0YW50IHRvIGFkb3B0IFdFU1Ag d2lkZWx5IHVudGlsIHRoZXJlIGlzIGJyb2FkIGN1c3RvbWVyDQpkZW1hbmQgZm9yIGl0LCBhbmQg SSdtIG5vdCBzdXJlIHRoYXQgdGhpcyBkZW1hbmQgd2lsbCBldmVyIG1hdGVyaWFsaXplLjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhpcyBpcyBhbGwg bXkgcGVyc29uYWwgb3Bpbmlvbiwgb2YNCmNvdXJzZS4gJm5ic3A7QnV0IGl0IHNlZW1zIHRvIG1l IHRoYXQgaGV1cmlzdGljcyB3aWxsIGhhdmUgdG8gYmUgYWRvcHRlZA0KYnkgY29tcGV0aXRpdmUg bWlkZGxlLW5vZGUgdmVuZG9ycywgYW5kIHRoZXJlZm9yZSAoYmFycmluZyBhbnkgZXh0ZW5zaW9u cw0KdG8gV0VTUCB0aGF0IG1ha2UgaXQgYXR0cmFjdGl2ZSBmb3Igb3RoZXIgcmVhc29ucykgdGhl IHVzZSBvZiBoZXVyaXN0aWNzDQp3aWxsIHByb2JhYmx5IGFsd2F5cyBiZSBtb3JlIHdpZGVzcHJl YWQgYW5kIHdpbGwgZGFtcGVuIHRoZSBkZW1hbmQgZm9yDQpXRVNQLiAmbmJzcDtBZGRpdGlvbmFs bHksIEVTUC1OVUxMIGl0c2VsZiBoYXMgcmF0aGVyIG5hcnJvdyBhcHBsaWNhYmlsaXR5DQppbiBh biBlbnZpcm9ubWVudCB3aGVyZSBlbmQtdG8tZW5kIGVuY3J5cHRpb24gaXMgaW5jcmVhc2luZ2x5 IGNvbW1vbiwgd2hpY2gNCmZ1cnRoZXIgbGltaXRzIHRoZSBjYXNlcyB3aGVyZSB0aGVyZSB3aWxs IGJlIGFuIGFic29sdXRlIG5lZWQgZm9yIFdFU1AuDQombmJzcDtGdXJ0aGVybW9yZSwgdGhlcmUg d2lsbCBhbHdheXMgYmUgdmFsaWQgcmVhc29ucyB0byB1c2UgQUggKHJlZHVjZWQNCm92ZXJoZWFk IGNvbXBhcmVkIHRvIFdFU1ApLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Rm9yIHJlYXNvbnMgbGlrZSB0aGVzZSwgSSBiZWxpZXZlIGl0J3MNCnByZW1h dHVyZSB0byBjYWxsIGZvciBkZXByZWNhdGlvbiBvZiBBSCBhbmQgZXZlbiBtb3JlIHByZW1hdHVy ZSB0byBzdGFydA0KcHJlZmVycmluZyBXRVNQIHRvIEVTUC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldoYXQgc3RhdHVzIHdpbGwgdGhlIFdFU1AgUkZD IGhhdmU/DQombmJzcDtFeHBlcmltZW50YWwsIGluZm9ybWF0aW9uYWwsIHN0YW5kYXJkcyB0cmFj aywgZXRjLj88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pjxicj4NClNjb3R0IE1vb25lbiAoc21vb25lbkB1cy5pYm0uY29tKTxicj4NCnovT1MgQ29tbXVu aWNhdGlvbnMgU2VydmVyIFRDUC9JUCBEZXZlbG9wbWVudDxicj4NCjwvZm9udD48YSBocmVmPWh0 dHA6Ly93d3cubGlua2VkaW4uY29tL2luL3Ntb29uZW4+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPmh0dHA6Ly93d3cubGlua2VkaW4uY29tL2luL3Ntb29uZW48L2ZvbnQ+PC9hPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD48 Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5Gcm9tOjwvZm9udD4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+SmFjayBLb2huICZsdDtrb2huLmph Y2tAZ21haWwuY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPjxmb250IHNpemU9 MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPlRvOjwvZm9udD4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+aXBzZWNAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5E YXRlOjwvZm9udD4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MTEvMTEvMjAw OSAxMTowNiBBTTwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPjxmb250IHNpemU9MSBjb2xv cj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPlN1YmplY3Q6PC9mb250Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bSVBzZWNdIFdFU1AgLSBSb2FkbWFwIEFoZWFkPC9mb250 PjwvdGFibGU+DQo8YnI+DQo8aHIgbm9zaGFkZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXpl PTM+SGksPGJyPg0KPGJyPg0KRnJvbSBvcGVyYXRpb25hbCBwZXJzcGVjdGl2ZSBpZiB3ZSBhcmUg c3VwcG9ydGluZyBib3RoIHY0IGFuZCB2NiAoYW5kIHdlDQp3aWxsKSB0aGVuIGhhdmluZyBkaWZm ZXJlbnQgcHJvdG9jb2xzIEVTUCBhbmQgQUggaXMgYW5kIHdpbGwgYmUgYSBuaWdodG1hcmUuJm5i c3A7DQpDb21tb24gZGVub21pbmF0b3IgaXMgRVNQLU51bGwuIEhvd2V2ZXIsIHRoZXJlIHdlcmUg aXNzdWVzIHdpdGggRVNQLU51bGwNCmFzIGl0IGNvdWxkbnQgYmUgZGVlcCBpbnNwZWN0ZWQgd2hp Y2ggaGFzIG5vdyBiZWVuIHNvbHZlZCB3aXRoIFdFU1AuPGJyPg0KPGJyPg0KSW4gc2hvcnQsIHRo ZSBhcmd1bWVudCB0aGF0ICZxdW90O09oLCBidXQgd2UgY2FuIGluc3BlY3QgQUggcGFja2V0cyZx dW90Ow0KaXMgbm90IHJlbGV2YW50IGFueW1vcmUuPGJyPg0KPGJyPg0KR2l2ZW4gdGhpcywgc2hv dWxkIHdlIHN0aWxsIGhhdmUgQUggYXMgYSBNQVkgZm9yIElQU0VDIC0gQ2FudCB3ZSBkZXByZWNh dGUNCml0PyA8YnI+DQo8YnI+DQpXRVNQIGlzIEVTUCsrLCBhbmQgaXQgb2ZmZXJzIGV2ZXJ0aGlu ZyB0aGF0IEVTUCBvZmZlcnMgcGx1cyBtb3JlLiBXaGF0DQppcyBvdXIgc3RhbmNlIGZvciBFU1Ag bW92aW5nIGZvcndhcmQ/PGJyPg0KPGJyPg0KQWxzbywgSSBzZWUgdGhhdCBhIGxvdCBvZiB3b3Jr IGRvbmUgaW4gb3RoZXIgV0dzIGlzIHN0aWxsIHVzaW5nIEVTUCAocHJpbWFyaWx5DQpmb3IgZGF0 YSBpbnRlZ3JpdHkpLiBTaG91bGRu4oCZdCB0aGV5IGJlIG1vdmluZyB0byBXRVNQLCBhcyBXRVNQ IG9mZmVycw0KbW9yZSBmbGV4aWJpbGl0eT88YnI+DQo8YnI+DQpKYWNrPGJyPg0KPC9mb250Pjx0 dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpJUHNlYyBtYWlsaW5nIGxpc3Q8YnI+DQpJUHNlY0BpZXRmLm9yZzxicj4NCjwv Zm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHNlYz48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXBzZWM8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90 dD4NCjxicj4NCjxicj4NCg== --=_alternative 0073C5508525766B_=-- From kivinen@iki.fi Wed Nov 11 15:31:13 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D2773A67D9 for ; Wed, 11 Nov 2009 15:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyrRoTYormcE for ; Wed, 11 Nov 2009 15:31:12 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 0243228C0DD for ; Wed, 11 Nov 2009 15:31:11 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nABNVSr9017098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Nov 2009 01:31:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nABNVQUO019610; Thu, 12 Nov 2009 01:31:26 +0200 (EET) 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: <19195.18766.767555.230392@fireball.kivinen.iki.fi> Date: Thu, 12 Nov 2009 01:31:26 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <4A5E60B4-E903-441F-A839-09FE9198B468@checkpoint.com> References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com> <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com> <3A8C969225424C4D8E6BEE65ED8552DA4C446E@XMB-BGL-41C.cisco.com> <39008D85-3D9B-4B8B-A9FA-C4C91658630E@checkpoint.com> <3A8C969225424C4D8E6BEE65ED8552DA4C4472@XMB-BGL-41C.cisco.com> <4A5E60B4-E903-441F-A839-09FE9198B468@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 4 min Cc: "ipsec@ietf.org" , "Amjad Inamdar \(amjads\)" Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 23:31:13 -0000 Yoav Nir writes: > Since the gateway acts as a pass-through, the requirement here is > more for the client, which is typically more integrated. The client > should be prepared to give an identity hint both in IKE and later in > the EAP session. And in that case the identities should really be same, and if they differ then the authenticated identity needs to be used for policy lookups, meaning that the EAP identity needs to be used. So the gateway needs to get that authenticated identity from the AAA server so it can do policy lookups based on it. -- kivinen@iki.fi From kivinen@iki.fi Wed Nov 11 15:56:28 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A703A6B72 for ; Wed, 11 Nov 2009 15:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMLlBzWUpa3q for ; Wed, 11 Nov 2009 15:56:27 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7113A6993 for ; Wed, 11 Nov 2009 15:56:26 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nABNuqkG028957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Nov 2009 01:56:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nABNuqeN006455; Thu, 12 Nov 2009 01:56:52 +0200 (EET) 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: <19195.20292.100878.21682@fireball.kivinen.iki.fi> Date: Thu, 12 Nov 2009 01:56:52 +0200 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: ipsec@ietf.org, Jack Kohn Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 23:56:28 -0000 Scott C Moonen writes: > Jack, I'm not sure it's clear yet whether WESP will be widely adopted. > There's disagreement between end-node and middle-node folks as to whether > WESP or heuristics are the best approach for inspection of ESP-NULL > traffic. I think that end-node vendors will be very reluctant to adopt > WESP widely until there is broad customer demand for it, and I'm not sure > that this demand will ever materialize. I agree on that... > This is all my personal opinion, of course. But it seems to me that > heuristics will have to be adopted by competitive middle-node vendors, and > therefore (barring any extensions to WESP that make it attractive for > other reasons) the use of heuristics will probably always be more > widespread and will dampen the demand for WESP. Additionally, ESP-NULL > itself has rather narrow applicability in an environment where end-to-end > encryption is increasingly common, which further limits the cases where > there will be an absolute need for WESP. Furthermore, there will always > be valid reasons to use AH (reduced overhead compared to WESP). And wider protection, i.e. IP addresses and options... > For reasons like these, I believe it's premature to call for deprecation > of AH and even more premature to start preferring WESP to ESP. Agree on that too. > What status will the WESP RFC have? Experimental, informational, > standards track, etc.? It is aimed for proposed standard, altough I would be happier if would be aimed for experimental. -- kivinen@iki.fi From mcr@marajade.sandelman.ca Wed Nov 11 17:40:59 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 110E43A67B1 for ; Wed, 11 Nov 2009 17:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+7XzUS1F9Ox for ; Wed, 11 Nov 2009 17:40:58 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id E1F8A3A67FA for ; Wed, 11 Nov 2009 17:40:57 -0800 (PST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 687A5342E6 for ; Wed, 11 Nov 2009 20:32:34 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id A043B4E793 for ; Wed, 11 Nov 2009 20:41:21 -0500 (EST) Prev-Resent: Wed, 11 Nov 2009 19:03:11 -0500 Prev-Resent: "kivinen@iki.fi, ipsecme@ietf.org " From: Michael Richardson X-Message-Flag: You should stop using Outlook. Switch to Thunderbird. To: Tero Kivinen X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 04 Nov 2009 10:02:46 -0500 Message-ID: <10247.1257346966@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Resent-To: ipsec@ietf.org Resent-Date: Wed, 11 Nov 2009 20:41:21 -0500 Resent-Message-ID: <18304.1257990081@marajade.sandelman.ca> Resent-From: Michael Richardson Cc: ipsecme@ietf.org Subject: [IPsec] comments on esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 01:40:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > As end nodes might be able to > bypass those checks by using encrypted ESP instead of ESP-NULL, these > kinds of scenarios also require very specific policies to forbid such > circumvention. The question is, are these end-nodes malicious, or are they just ignorant? > Because the traffic inspected is usually host to host traffic inside > one organization, that usually means transport mode IPsec is used. It is? I'll bet 95% of actual transport mode IPsec has an L2TP layer inside. === I agree with the analysis of section 3, in particular the explanation of how hardware can be programmed to statefully match the ESP-NULL flows. It might be worth noting that NAT-T ESP-NULL flows *ALREADY* have a 5-tuple (likely unique) marker, and that if the inspector is also a NA(P)T, that it already is keeping the right state. section 4. It might be worth having a reference for "flow cache". I think that there is a document on Cisco Netflow, and I also think that FORCES has something that relates to the Linux "flow" things. I think it might also be worth staying that this is really a "microflow" cache. Include a forward reference to section 7, so the reader knows UDP will be dealt with. In particular, in the text relating to NAT-T encapsulated IKE packets. If they are not allowed through (queue until sure, or drop option), then the SA might not get setup ever.. section 8.2 I'd rather see the math/calculations in a display... that would eliminate the difficulty in reading when things are wrapped. page 16: those cases the packet must be marked "unsure". s/must/MUST/ ??? I have read the appendix code, and I do not see anything glaringly out at me, but I'd have to sit down and actually implement to know if all the situations are taken care of. It seems like good guidance, and the statements in the Appendix were familiar from reading the text. In conclusion: while I think the whole inspection notion is ridiculous, and likely is going to get in the way of deployment of new protocols, and may well help the "throttlers" (cf. Mark Handley's Net Neutrality presentation at IETF75), I find that if the inspection people follow the very sage advice of Kivinen and McDonald, that the least amount of harm possible will be done. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSvGXlICLcPvd0N1lAQIQ+Af/ViKcqG7Ed9CLVzXbiZOUGUArYJizkO5t teH+U6DuvPmfX2yLr4cZhEcH5CmhfF6xh2Y2Lg3yc5+IGjk2pqzwn6eRONfP1bwO 8LcFZQ+a215sVCHoFDNFhMzyyMi6i2F/wiyNnSpfEG3HX3gvjonkZJcWKxm6lbyr uNNPs2BrC11OQcqGsyVXqH1C2T5c42cdauh/Z3U7hxflyf/WNFU3iux3I8SgmgWx QkZBwp8U60ugbuN/LuA3O72+XXChfQPQppR50aX1RLS86D5UmJoyJvsuA0XOfLSg qS9H+RWMRk4RgLiO4DrlwhYVoKznhwf48XTaCTa8nPT+rT2ffLzepA== =H/OJ -----END PGP SIGNATURE----- From manav.bhatia@alcatel-lucent.com Wed Nov 11 18:01:58 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE77E3A692A for ; Wed, 11 Nov 2009 18:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytuHrTZpJkVI for ; Wed, 11 Nov 2009 18:01:57 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id CF35C3A69C5 for ; Wed, 11 Nov 2009 18:01:57 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id nAC22PIw014680; Wed, 11 Nov 2009 20:02:25 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (h202-65-2-130.alcatel.com [202.65.2.130]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id nAC22NxC011072; Wed, 11 Nov 2009 20:02:24 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id nAC20tGm018653; Thu, 12 Nov 2009 10:00:57 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 12 Nov 2009 07:32:21 +0530 From: "Bhatia, Manav (Manav)" To: Scott C Moonen , Jack Kohn Date: Thu, 12 Nov 2009 07:32:18 +0530 Thread-Topic: [IPsec] WESP - Roadmap Ahead Thread-Index: AcpjEvdzf17YD+2NT+KtXbSkpJVbQgAID50w Message-ID: <7C362EEF9C7896468B36C9B79200D8350A681DDBD3@INBANSXCHMBSA1.in.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.130 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 02:01:59 -0000 Scott, > From: ipsec-bounces@ietf.org On Behalf Of Scott C Moonen > Sent: Thursday, November 12, 2009 2.37 AM > To: Jack Kohn > Cc: ipsec@ietf.org; ipsec-bounces@ietf.org > Subject: Re: [IPsec] WESP - Roadmap Ahead >=09 > Jack, I'm not sure it's clear yet whether WESP will be widely adopted. =20 > There's disagreement between end-node and middle-node folks as to whether= =20 > WESP or heuristics are the best approach for inspection of ESP-NULL traff= ic. =20 > I think that end-node vendors will be very reluctant to adopt=20 I cant comment on the interest of the end-node vendors, but i can certainly= say that this will be of interest to the router vendors. There are current= ly a lot of applications (routing/signaling for instance) where we use ESP-= NULL for integrity protection (confidentiality is not an issue there) and i= t will be really good if there are ways to deep inspect these packets for p= roper QoS treatment. > WESP widely until there is broad customer demand for it, and I'm not=20 > sure that this demand will ever materialize.=20 >=09 > This is all my personal opinion, of course. But it seems to me that heur= istics=20 > will have to be adopted by competitive middle-node vendors, and=20 > therefore (barring any extensions to WESP that make it attractive=20 > for other reasons) the use of heuristics will probably always be more=20 > widespread and will dampen the demand for WESP. Additionally,=20 There you go: http://tools.ietf.org/html/draft-montenegro-ipsecme-wesp-extensions-00 > ESP-NULL itself has rather narrow applicability in an environment where=20 > end-to-end encryption is increasingly common, which further limits=20 Most routing, signaling protocols use ESP-NULL (it's a MUST, while support = for AH is a MAY) and I can see benefits of moving to WESP from the QoS pers= pective. I am not saying that we cannot do QoS with ESP, but it just become= s a tad more flexible/easier with WESP. > the cases where there will be an absolute need for WESP. Furthermore,=20 > there will always be valid reasons to use AH (reduced overhead compared t= o WESP).=20 >=09 > For reasons like these, I believe it's premature to call for deprecation= =20 > of AH and even more premature to start preferring WESP to ESP.=20 I agree. > > What status will the WESP RFC have? Experimental, informational, standar= ds track, etc.?=20 Standards Track Cheers, Manav >=20 > > Scott Moonen (smoonen@us.ibm.com) > z/OS Communications Server TCP/IP Development > http://www.linkedin.com/in/smoonen = =20 =09 From manav.bhatia@alcatel-lucent.com Wed Nov 11 18:14:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE6E3A68FC for ; Wed, 11 Nov 2009 18:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1T77fv+Gcd-z for ; Wed, 11 Nov 2009 18:14:35 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id B3FE53A689F for ; Wed, 11 Nov 2009 18:14:35 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id nAC2F1dm019957; Wed, 11 Nov 2009 20:15:01 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (aprelay03.apac.alcatel-lucent.com [202.65.2.133]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id nAC2EwWg018523; Wed, 11 Nov 2009 20:14:59 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id nAC2HhSM016330; Thu, 12 Nov 2009 10:17:43 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 12 Nov 2009 07:44:56 +0530 From: "Bhatia, Manav (Manav)" To: Stephen Kent , Jack Kohn Date: Thu, 12 Nov 2009 07:44:55 +0530 Thread-Topic: [IPsec] WESP - Roadmap Ahead Thread-Index: AcpjEZq5yyREj0RRRIaIg15Xsq/aBgAKs2SQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350A681DDBDB@INBANSXCHMBSA1.in.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.133 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 02:14:36 -0000 Steve, > I would have no problem deprecating AH in the context of the IPsec=20 > architecture document, if others agree. It is less efficient than=20 > ESP-NULL. However, other WGs have cited AH as the IPsec protocol of=20 > choice for integrity/authentication in their environments, so there=20 > will be a need to coordinate with them, and it may be unacceptable to=20 > kill AH as a standalone protocol for them. I agree that it is a trifle too early to start deprecating AH, though I wou= ldn't mind doing so. OTOH, don't most WGs already suggest AH as a MAY, and = ESP-NULL as a MUST? In any case what should be the stand for the newer wor= k that comes out of these WGs. Should they spell out support for AH, or sho= uld they just be talking about ESP (or ESP-NULL or WESP)? If we want to deprecate AH, or at least discourage its use in the context o= f the IPSec architecture in the near future then shouldn't we be working on= this? >=20 > I am not comfortable with the notion of ESP with WESP. WESP adds=20 > more per-packet overhead than ESP, and some users are very sensitive=20 > to this aspect of IPsec use. Also, other WG rely on ESP and we would=20 > need to convince them that the packet inspection features of WESP=20 > merit making changes to their standards, which might be a tough sell.=20 I agree. However, we should start socializing WESP in other WGs so that fol= ks are at least aware of it.=20 Cheers, Manav > So, I cannot support this suggestion. >=20 > Steve > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > = From paul.hoffman@vpnc.org Wed Nov 11 18:28:56 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BD0B3A689F for ; Wed, 11 Nov 2009 18:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.255 X-Spam-Level: X-Spam-Status: No, score=-5.255 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzyZl1PYfKHo for ; Wed, 11 Nov 2009 18:28:55 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 015D33A6828 for ; Wed, 11 Nov 2009 18:28:54 -0800 (PST) Received: from [133.93.128.35] (host-40-59.meeting.ietf.org [133.93.40.59]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAC2TKLl075439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Nov 2009 19:29:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 12 Nov 2009 11:29:15 +0900 To: ipsec@ietf.org From: Paul Hoffman Content-Type: text/html; charset="us-ascii" Subject: [IPsec] Finishing #22 (was: Re: Closing the IKEv2bis open issues) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 02:28:56 -0000 Finishing #22 (was: Re: [IPsec] Closing the IKEv2bis open
Resent so that the issue number is in subject line only. Please reply to this thread.

At 11:42 AM -0800 11/11/09, Keith Welter wrote:
> Issue #22, Add section on simultaneous IKE SA rekey
> <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/22>
> There is no consensus on this issue. Tero Kivinen and David Wierbowski have deep differences of
> opinion, and almost no one else has participated. I have reviewed the discussion, and I think
> both people have strong merits to their opinion. Therefore, Yaron and I will try to coordinate
> a design team effort that includes Tero, David, and any others who have thought about this issue
> in depth. If that fails to come out with an agreed-to solution, we will probably drop back to
> adding a short, inconclusive, descriptive > note in the IKEv2bis document.

A design team was convened including Dan McDonald, Tero Kivinen, Raj Singh, David Wierbowski and Keith Welter to resolve Issue #22.  The design team reached agreement on the following general approach as well as specific proposed text:
- Import text from RFC 4718 section 5.11.10 into new ikev2biz draft section 2.25 "Exchange Collisions"
- Replace NO_PROPOSAL_CHOSEN and NO_ADDITIONAL_SAS with new TEMPORARY_FAILURE error type notify.
- Add new CHILD_SA_NOT_FOUND error type notify for one collision case.
- Add text in new section 2.25 describing what to do when the new notify types are received.

The proposed text that follows includes a new section and updates to existing sections for ikev2bis.

2.25 Exchange Collisions (New Section)

Since IKEv2 exchanges can be initiated by both peers, it is possible
that two exchanges affecting the same SA partly overlap. This can
lead to a situation where the SA state information is temporarily not
synchronized, and a peer can receive a request it cannot process in a
normal fashion.

Obviously, using a window size greater than one leads to
more complex situations, especially if requests are processed out of
order. In this section, we concentrate on problems that can arise
even with window size 1 and recommend solutions.

A TEMPORARY_FAILURE notification SHOULD be sent when a host receives
a request that cannot be completed due to a temporary condition such
as a rekeying operation. When a host receives a TEMPORARY_FAILURE
notification, it MUST NOT immediately retry the operation but wait so
that the sender may complete whatever operation caused the temporary
condition. The recipient MAY retry the request one or more times over
a period of several minutes. If a host continues to receive
TEMPORARY_FAILURE on the same IKE SA after several minutes then it
SHOULD conclude that state information is out-of-sync and close the
IKE SA.

A CHILD_SA_NOT_FOUND notification SHOULD be sent when a host receives
a request to rekey a Child SA that does not exist. A host that
receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the
Child SA and send a request to create a new Child SA from scratch.

If a host receives a request to rekey:

o a Child SA that the host is currently trying to close: reply
with TEMPORARY_FAILURE.

o a Child SA that the host is currently rekeying: reply as
usual, but prepare to close redundant SAs later based on the
nonces.

o a Child SA that does not exist: reply with
CHILD_SA_NOT_FOUND.

o the IKE SA, and the host is currently rekeying the IKE SA: reply
as usual, but prepare to close redundant SAs and move inherited
Child SAs later based on the nonces.

o the IKE SA, and the host is currently creating, rekeying,
or closing a Child SA: reply with TEMPORARY_FAILURE.

o the IKE SA, and the host is currently trying to close the IKE SA:
reply with TEMPORARY_FAILURE.

If a host receives a request to close:

o a Child SA that the host is currently trying to close: reply
without Delete payloads.

o a Child SA that the host is currently rekeying: reply as
usual, with Delete payload.

o a Child SA that does not exist: reply without Delete
payloads.

o the IKE SA, and the host is currently rekeying the IKE SA: reply
as usual, and forget about our own rekeying request.

o the IKE SA, and the host is currently trying to close the IKE SA:
reply as usual, and forget about our own close request.

If a host receives a request to create or rekey a CHILD_SA when it is
currently rekeying the IKE_SA: reply with TEMPORARY_FAILURE.

If a host receives a request to delete a Child SA when it is
currently rekeying the IKE SA:
reply as usual, with Delete payload.


3.10.1. Notify Message Types (Updates)
...
NOTIFY messages: error types Value
-------------------------------------------------------------------
...
TEMPORARY_FAILURE 40
See section 2.25.

CHILD_SA_NOT_FOUND 41
See section 2.25.

RESERVED TO IANA 42-8191
...

1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange (Updates)

Add the following sentence to the end of the first paragraph of section 1.3.2:
"Once a host receives a request to rekey an IKE SA or sends a request to rekey
an IKE SA it SHOULD NOT start any new CREATE_CHILD_SA exchanges on the IKE SA
being rekeyed."

The new paragraph should now read:
"The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
payload, and a Diffie-Hellman value in the KEi payload. The KEi
payload MUST be included. New initiator and responder SPIs are
supplied in the SPI fields of the SA payload. Once a host receives
a request to rekey an IKE SA or sends a request to rekey an IKE SA
it SHOULD NOT start any new CREATE_CHILD_SA exchanges on the IKE SA
being rekeyed."

2.8.2. Simultaneous IKE SA Rekeying (Updates)

Update the second paragraph so that it reads as follows:
"The case where both endpoints notice the simultaneous rekeying works
the same way as with Child SAs. After the CREATE_CHILD_SA exchanges,
three IKE SAs exist between A and B; the old IKE SA and two new IKE SAs.
The new IKE SA containing the lowest nonce inherits the Child SAs.
If only one side detects a simultaneous rekey then redundant SAs are
not created. In this case, when the end which didn't notice the
simultaneous rekey gets the request to rekey the IKE SA that it has
already successfully rekeyed, it will return TEMPORARY_FAILURE as it
is an IKE SA it is currently trying to close (whether it has already
sent the delete notification for it or not). If the end which did
notice the simultaneous rekey gets the delete from the other end for
the old IKE SA then it knows that the other end didn't detect
simultaneous rekey, and it can forget its own rekey attempt."

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)

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

From kent@bbn.com Wed Nov 11 19:29:44 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D335A3A67AD for ; Wed, 11 Nov 2009 19:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fr08PMYRlDUD for ; Wed, 11 Nov 2009 19:29:44 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 18F123A676A for ; Wed, 11 Nov 2009 19:29:44 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[133.93.16.246]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N8QNu-0000gK-9x; Wed, 11 Nov 2009 22:30:10 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350A681DDBDB@INBANSXCHMBSA1.in.alcatel-luce nt.com> References: <7C362EEF9C7896468B36C9B79200D8350A681DDBDB@INBANSXCHMBSA1.in.alcatel-luce nt.com> Date: Wed, 11 Nov 2009 22:28:25 -0500 To: "Bhatia, Manav (Manav)" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , Jack Kohn Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 03:29:44 -0000 At 7:44 AM +0530 11/12/09, Bhatia, Manav (Manav) wrote: >Steve, > >> I would have no problem deprecating AH in the context of the IPsec >> architecture document, if others agree. It is less efficient than >> ESP-NULL. However, other WGs have cited AH as the IPsec protocol of >> choice for integrity/authentication in their environments, so there >> will be a need to coordinate with them, and it may be unacceptable to >> kill AH as a standalone protocol for them. > >I agree that it is a trifle too early to start deprecating AH, >though I wouldn't mind doing so. OTOH, don't most WGs already >suggest AH as a MAY, and ESP-NULL as a MUST? Not always. For example, I believe that OSPF security makes use of AH, outside the IPsec context. >In any case what should be the stand for the newer work that comes >out of these WGs. Should they spell out support for AH, or should >they just be talking about ESP (or ESP-NULL or WESP)? I'd recommend ESP-NULL, unless the context on which the operate might require inspection by an intermediate system. >If we want to deprecate AH, or at least discourage its use in the >context of the IPSec architecture in the near future then shouldn't >we be working on this? Part of the problem is that some WGs want to make use of IPsec protocols outside of the IPsec architecture. > > I am not comfortable with the notion of ESP with WESP. WESP adds > > more per-packet overhead than ESP, and some users are very sensitive >> to this aspect of IPsec use. Also, other WG rely on ESP and we would >> need to convince them that the packet inspection features of WESP >> merit making changes to their standards, which might be a tough sell. > >I agree. However, we should start socializing WESP in other WGs so >that folks are at least aware of it. Agree. From rsjenwar@gmail.com Wed Nov 11 19:34:07 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4B273A676A for ; Wed, 11 Nov 2009 19:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kpdmw4J7362x for ; Wed, 11 Nov 2009 19:34:06 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 836D33A67AB for ; Wed, 11 Nov 2009 19:34:06 -0800 (PST) Received: by bwz23 with SMTP id 23so1803234bwz.29 for ; Wed, 11 Nov 2009 19:34:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=fFhoB+x20dgDr+HY7uTU2rLzanuR1+ncxsU4tnOWUgQ=; b=x8TYZVAYxs/kdW5rEZm4h6Z9nGrdcFDEyKaYnvnj9krfWxJsG1lE3YBhfaCciSh7C1 mBqsxQv0Oc/LP0Q/GebOxi1O9vBn0x+6wLNOcq4OyY1QlCt20BykCCx7AZrC46QpKJ6T 18gI+4UEB9nKY7nBgpjAIboLx6dz1Rk5lA9ng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kLGITk/qRx2ZGqd+B1nb6M56JNrkRlFDudPYzXd7HWXC1igsNJmTm344u7X1x6QWyW IlHSFAmfbY4oilbk0t652aQ2qeawuspa3ytTwaeTw24pt5mX4I0HCNwOsFLhC8jtb6b7 LdbXdocgwj/oHjQTkB4owxII7H+lkVUj3pppo= MIME-Version: 1.0 Received: by 10.216.93.17 with SMTP id k17mr30504wef.31.1257996872563; Wed, 11 Nov 2009 19:34:32 -0800 (PST) In-Reply-To: <19195.18766.767555.230392@fireball.kivinen.iki.fi> References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com> <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com> <3A8C969225424C4D8E6BEE65ED8552DA4C446E@XMB-BGL-41C.cisco.com> <39008D85-3D9B-4B8B-A9FA-C4C91658630E@checkpoint.com> <3A8C969225424C4D8E6BEE65ED8552DA4C4472@XMB-BGL-41C.cisco.com> <4A5E60B4-E903-441F-A839-09FE9198B468@checkpoint.com> <19195.18766.767555.230392@fireball.kivinen.iki.fi> Date: Thu, 12 Nov 2009 09:04:32 +0530 Message-ID: <7ccecf670911111934u70f28feegf053b835ff3fb0f@mail.gmail.com> From: Raj Singh To: Tero Kivinen Content-Type: multipart/alternative; boundary=0016e6d7e33ab7bb4a047824382c Cc: "ipsec@ietf.org" , Yoav Nir , "Amjad Inamdar \(amjads\)" Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 03:34:07 -0000 --0016e6d7e33ab7bb4a047824382c Content-Type: text/plain; charset=UTF-8 The selection of AAA server will be based on IDi then EAP will happen. The gateway will get EAP authenticated ID from the AAA server. If EAP identity is different from IDi and no policy is found for EAP identity. The gateway should initiate deletion of the SA. Also, if policy is found based on EAP identity, but its different from IDi, EAP identity should be given priority and its attributes should be applied on that SA. On Thu, Nov 12, 2009 at 5:01 AM, Tero Kivinen wrote: > Yoav Nir writes: > > Since the gateway acts as a pass-through, the requirement here is > > more for the client, which is typically more integrated. The client > > should be prepared to give an identity hint both in IKE and later in > > the EAP session. > > And in that case the identities should really be same, and if they > differ then the authenticated identity needs to be used for policy > lookups, meaning that the EAP identity needs to be used. So the > gateway needs to get that authenticated identity from the AAA server > so it can do policy lookups based on it. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0016e6d7e33ab7bb4a047824382c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The selection of AAA server will be based on IDi then EAP will happen.
= The gateway will get EAP authenticated ID from the AAA server.
If E= AP identity is different from IDi and no policy is found for EAP identity.<= /div>
The gateway should initiate deletion of the SA.
Also, if pol= icy is found based on EAP identity, but its different from IDi,=C2=A0
=
EAP identity should be given priority and its attributes should be app= lied on that SA.

On Thu, Nov 12, 2009 at 5:01 AM, Tero Kivine= n <kivinen@iki.fi> wrote:
Yoav Nir writes:
> Since the gateway acts as a pass-through, the requirement here is
> more for the client, which is typically more integrated. The client > should be prepared to give an identity hint both in IKE and later in > the EAP session.

And in that case the identities should really be same, and if they differ then the authenticated identity needs to be used for policy
lookups, meaning that the EAP identity needs to be used. So the
gateway needs to get that authenticated identity from the AAA server
so it can do policy lookups based on it.
--
kivinen@iki.fi
__________________________________= _____________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--0016e6d7e33ab7bb4a047824382c-- From merike@doubleshotsecurity.com Wed Nov 11 19:49:17 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC6E3A6960 for ; Wed, 11 Nov 2009 19:49:17 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTC0gTjoiVS7 for ; Wed, 11 Nov 2009 19:49:16 -0800 (PST) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by core3.amsl.com (Postfix) with ESMTP id BED9B28C1ED for ; Wed, 11 Nov 2009 19:48:45 -0800 (PST) Received: from [192.168.66.56] ([65.102.159.229]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id nAC3n4CK018577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Nov 2009 19:49:05 -0800 In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350A681DDBDB@INBANSXCHMBSA1.in.alcatel-luce nt.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> Content-Transfer-Encoding: 7bit From: Merike Kaeo Date: Wed, 11 Nov 2009 19:49:29 -0800 To: Stephen Kent X-Mailer: Apple Mail (2.753.1) Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Jack Kohn Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 03:49:17 -0000 All of the standards I've seen that explicitly define how IPsec is to be used for authentication (including RFC 4552 - Authentication/ Confidentiality for OSPFv3) say that for authentication ESP-Null MUST be used and AH MAY. Which RFCs specify AH specifically as a MUST for authentication/ integrity? Now on the flip side, in practical implementations, most vendors I know of started off with AH being used for OSPFv3 and I doubt in practice people are using ESP-Null. Would love to be wrong here :) - merike On Nov 11, 2009, at 7:28 PM, Stephen Kent wrote: > At 7:44 AM +0530 11/12/09, Bhatia, Manav (Manav) wrote: >> Steve, >> >>> I would have no problem deprecating AH in the context of the IPsec >>> architecture document, if others agree. It is less efficient than >>> ESP-NULL. However, other WGs have cited AH as the IPsec protocol of >>> choice for integrity/authentication in their environments, so there >>> will be a need to coordinate with them, and it may be >>> unacceptable to >>> kill AH as a standalone protocol for them. >> >> I agree that it is a trifle too early to start deprecating AH, >> though I wouldn't mind doing so. OTOH, don't most WGs already >> suggest AH as a MAY, and ESP-NULL as a MUST? > > Not always. For example, I believe that OSPF security makes use of > AH, outside the IPsec context. > >> In any case what should be the stand for the newer work that comes >> out of these WGs. Should they spell out support for AH, or should >> they just be talking about ESP (or ESP-NULL or WESP)? > > I'd recommend ESP-NULL, unless the context on which the operate > might require inspection by an intermediate system. > >> If we want to deprecate AH, or at least discourage its use in the >> context of the IPSec architecture in the near future then >> shouldn't we be working on this? > > Part of the problem is that some WGs want to make use of IPsec > protocols outside of the IPsec architecture. > >> > I am not comfortable with the notion of ESP with WESP. WESP adds >> > more per-packet overhead than ESP, and some users are very >> sensitive >>> to this aspect of IPsec use. Also, other WG rely on ESP and we >>> would >>> need to convince them that the packet inspection features of WESP >>> merit making changes to their standards, which might be a tough >>> sell. >> >> I agree. However, we should start socializing WESP in other WGs so >> that folks are at least aware of it. > > Agree. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From yaronf@checkpoint.com Wed Nov 11 19:49:18 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2EDE28C1EA; Wed, 11 Nov 2009 19:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.681 X-Spam-Level: X-Spam-Status: No, score=-3.681 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwE+nSI1OCzX; Wed, 11 Nov 2009 19:49:16 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id C332028C1EE; Wed, 11 Nov 2009 19:48:48 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAC3nFc6018888; Thu, 12 Nov 2009 05:49:15 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 12 Nov 2009 05:49:18 +0200 From: Yaron Sheffer To: "saag@ietf.org" Date: Thu, 12 Nov 2009 05:49:13 +0200 Thread-Topic: IPsecME WG report Thread-Index: AcpjSxlUYagSMqn2TV+/4QxI9+z5IQ== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF872C10F@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF872C10Filex01adche_" MIME-Version: 1.0 Cc: IPsecme WG Subject: [IPsec] IPsecME WG report X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 03:49:18 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF872C10Filex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPsecME met this morning. We have one RFC (IKEv2 Redirect) recently published, and a couple more in t= he RFC Editor queue. The other "small" drafts are coming along as well. The group is making progress on IKEv2-bis, and we had a presentation on one= thorny protocol issue that was resolved by a design team. Our goal is to m= ove it out of the WG *before* the next F2F meeting. The bulk of the meeting was presentation of 7 candidate work items. The gro= up was polled for volunteer reviewers and contributors for each of these. T= his process will continue on the mailing list, and eventually we will propo= se a new charter, retaining the number of concurrent work items. On the process side, we had one presenter on an audio bridge - which worked= fine - and another as a prerecorded "podcast", which also worked after som= e technical fumbling. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF872C10Filex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IPsecME met this morning.

 

We have one RFC (IKEv2 Redirect) recently published, and= a couple more in the RFC Editor queue. The other “small” drafts a= re coming along as well.

 

The group is making progress on IKEv2-bis, and we had a presentation on one thorny protocol issue that was resolved by a design tea= m. Our goal is to move it out of the WG *b= efore* the next F2F meeting.

 

The bulk of the meeting was presentation of 7 candidate = work items. The group was polled for volunteer reviewers and contributors for ea= ch of these. This process will continue on the mailing list, and eventually we will propose a new charter, retaining the number of concurrent work items.<= o:p>

 

On the process side, we had one presenter on an audio br= idge – which worked fine – and another as a prerecorded “podca= st”, which also worked after some technical fumbling.

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF872C10Filex01adche_-- From manav.bhatia@alcatel-lucent.com Wed Nov 11 19:59:45 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0FD53A67D3 for ; Wed, 11 Nov 2009 19:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBOwjMsrjenV for ; Wed, 11 Nov 2009 19:59:44 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by core3.amsl.com (Postfix) with ESMTP id 084E03A6892 for ; Wed, 11 Nov 2009 19:59:43 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id nAC4077V011841; Wed, 11 Nov 2009 22:00:07 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (h202-65-2-130.alcatel.com [202.65.2.130]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id nAC405O4018666; Wed, 11 Nov 2009 22:00:06 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id nAC3wbKx006095; Thu, 12 Nov 2009 11:58:37 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 12 Nov 2009 09:30:02 +0530 From: "Bhatia, Manav (Manav)" To: Merike Kaeo Date: Thu, 12 Nov 2009 09:30:00 +0530 Thread-Topic: [IPsec] WESP - Roadmap Ahead Thread-Index: AcpjSx3m4qrpp3CyTxOP25K11Lm9xwAACEaA Message-ID: <7C362EEF9C7896468B36C9B79200D8350A681DDBF4@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350A681DDBDB@INBANSXCHMBSA1.in.alcatel-luce nt.com> <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> In-Reply-To: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 172.22.12.27 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.130 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 03:59:45 -0000 =20 > All of the standards I've seen that explicitly define how=20 > IPsec is to =20 > be used for authentication (including RFC 4552 - Authentication/=20 > Confidentiality for OSPFv3) say that for authentication=20 > ESP-Null MUST =20 > be used and AH MAY. Yes, this is correct. The latest PIM-SM authentication document (http://tools.ietf.org/html/draft= -ietf-pim-sm-linklocal-08) uses IPSec to authenticate link-local messages i= n PIM-SM. It too says that ESP is a MUST while use of AH is optional. =20 >=20 > Which RFCs specify AH specifically as a MUST for authentication/=20 > integrity? I am not aware of any that do that. >=20 > Now on the flip side, in practical implementations, most vendors I =20 > know of started off with AH being used for OSPFv3 and I doubt in =20 > practice people are using ESP-Null. Would love to be wrong here :) I don't think this is really true. I know of at least two major vendors tha= t use ESP-NULL and one of them doesn't even support AH. Cheers, Manav >=20 > - merike >=20 > On Nov 11, 2009, at 7:28 PM, Stephen Kent wrote: >=20 > > At 7:44 AM +0530 11/12/09, Bhatia, Manav (Manav) wrote: > >> Steve, > >> > >>> I would have no problem deprecating AH in the context of=20 > the IPsec > >>> architecture document, if others agree. It is less=20 > efficient than > >>> ESP-NULL. However, other WGs have cited AH as the IPsec=20 > protocol of > >>> choice for integrity/authentication in their=20 > environments, so there > >>> will be a need to coordinate with them, and it may be =20 > >>> unacceptable to > >>> kill AH as a standalone protocol for them. > >> > >> I agree that it is a trifle too early to start deprecating AH, =20 > >> though I wouldn't mind doing so. OTOH, don't most WGs already =20 > >> suggest AH as a MAY, and ESP-NULL as a MUST? > > > > Not always. For example, I believe that OSPF security makes use of =20 > > AH, outside the IPsec context. > > > >> In any case what should be the stand for the newer work=20 > that comes =20 > >> out of these WGs. Should they spell out support for AH, or should =20 > >> they just be talking about ESP (or ESP-NULL or WESP)? > > > > I'd recommend ESP-NULL, unless the context on which the operate =20 > > might require inspection by an intermediate system. > > > >> If we want to deprecate AH, or at least discourage its use in the =20 > >> context of the IPSec architecture in the near future then =20 > >> shouldn't we be working on this? > > > > Part of the problem is that some WGs want to make use of IPsec =20 > > protocols outside of the IPsec architecture. > > > >> > I am not comfortable with the notion of ESP with WESP. =20 > WESP adds > >> > more per-packet overhead than ESP, and some users are very =20 > >> sensitive > >>> to this aspect of IPsec use. Also, other WG rely on ESP and we =20 > >>> would > >>> need to convince them that the packet inspection features of WESP > >>> merit making changes to their standards, which might be a tough =20 > >>> sell. > >> > >> I agree. However, we should start socializing WESP in=20 > other WGs so =20 > >> that folks are at least aware of it. > > > > Agree. > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > >=20 > = From kent@bbn.com Wed Nov 11 20:07:34 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0A5B3A682E for ; Wed, 11 Nov 2009 20:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-hwN5V5oPG9 for ; Wed, 11 Nov 2009 20:07:33 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id DD7A33A63EB for ; Wed, 11 Nov 2009 20:07:33 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[133.93.16.246]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N8QyW-0001HR-A4; Wed, 11 Nov 2009 23:08:00 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> References: <7C362EEF9C7896468B36C9B79200D8350A681DDBDB@INBANSXCHMBSA1.in.alcatel-luce nt.com> <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> Date: Wed, 11 Nov 2009 23:07:56 -0500 To: Merike Kaeo From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Jack Kohn Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 04:07:34 -0000 At 7:49 PM -0800 11/11/09, Merike Kaeo wrote: >All of the standards I've seen that explicitly define how IPsec is >to be used for authentication (including RFC 4552 - >Authentication/Confidentiality for OSPFv3) say that for >authentication ESP-Null MUST be used and AH MAY. > >Which RFCs specify AH specifically as a MUST for authentication/integrity? > >Now on the flip side, in practical implementations, most vendors I >know of started off with AH being used for OSPFv3 and I doubt in >practice people are using ESP-Null. Would love to be wrong here :) > >- merike Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL (although they never refer to it that way) as a MUST, and AH as a MAY. I probably was confused because the authors did not understand the IPsec model as per RFC 4301, when I sat down and talked with them over 3 years ago, with Sam Hartman in his SEC AD role. I am amazed that, in the final analysis, they did try to adhere to the 4301 model (see section 11)! I don't know if any other apps have done what I thought (erroneously) had been done here. Steve From manav.bhatia@alcatel-lucent.com Wed Nov 11 20:09:06 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80F7E3A689C for ; Wed, 11 Nov 2009 20:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fC9lAc+H20Lw for ; Wed, 11 Nov 2009 20:09:05 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id 950AE3A6875 for ; Wed, 11 Nov 2009 20:09:05 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id nAC49Ruk005296; Wed, 11 Nov 2009 22:09:27 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (h202-65-2-130.alcatel.com [202.65.2.130]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id nAC49QJ5024851; Wed, 11 Nov 2009 22:09:27 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id nAC47xt9007781; Thu, 12 Nov 2009 12:07:59 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 12 Nov 2009 09:39:24 +0530 From: "Bhatia, Manav (Manav)" To: Merike Kaeo , Stephen Kent Date: Thu, 12 Nov 2009 09:39:23 +0530 Thread-Topic: [IPsec] WESP - Roadmap Ahead Thread-Index: AcpjSx3m4qrpp3CyTxOP25K11Lm9xwAAnMMg Message-ID: <7C362EEF9C7896468B36C9B79200D8350A681DDBF7@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350A681DDBDB@INBANSXCHMBSA1.in.alcatel-luce nt.com> <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> In-Reply-To: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.130 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 04:09:06 -0000 >=20 > All of the standards I've seen that explicitly define how=20 > IPsec is to =20 > be used for authentication (including RFC 4552 - Authentication/=20 > Confidentiality for OSPFv3) say that for authentication=20 > ESP-Null MUST =20 > be used and AH MAY. In fact there was some discussion of using IPSec for OSPFv2 authentication,= and that proposal too uses ESP as a MUST and AH as a MAY. http://tools.ietf.org/html/draft-gupta-ospf-ospfv2-sec-01 Cheers, Manav >=20 > Which RFCs specify AH specifically as a MUST for authentication/=20 > integrity? >=20 > Now on the flip side, in practical implementations, most vendors I =20 > know of started off with AH being used for OSPFv3 and I doubt in =20 > practice people are using ESP-Null. Would love to be wrong here :) >=20 > - merike >=20 > On Nov 11, 2009, at 7:28 PM, Stephen Kent wrote: >=20 > > At 7:44 AM +0530 11/12/09, Bhatia, Manav (Manav) wrote: > >> Steve, > >> > >>> I would have no problem deprecating AH in the context of=20 > the IPsec > >>> architecture document, if others agree. It is less=20 > efficient than > >>> ESP-NULL. However, other WGs have cited AH as the IPsec=20 > protocol of > >>> choice for integrity/authentication in their=20 > environments, so there > >>> will be a need to coordinate with them, and it may be =20 > >>> unacceptable to > >>> kill AH as a standalone protocol for them. > >> > >> I agree that it is a trifle too early to start deprecating AH, =20 > >> though I wouldn't mind doing so. OTOH, don't most WGs already =20 > >> suggest AH as a MAY, and ESP-NULL as a MUST? > > > > Not always. For example, I believe that OSPF security makes use of =20 > > AH, outside the IPsec context. > > > >> In any case what should be the stand for the newer work=20 > that comes =20 > >> out of these WGs. Should they spell out support for AH, or should =20 > >> they just be talking about ESP (or ESP-NULL or WESP)? > > > > I'd recommend ESP-NULL, unless the context on which the operate =20 > > might require inspection by an intermediate system. > > > >> If we want to deprecate AH, or at least discourage its use in the =20 > >> context of the IPSec architecture in the near future then =20 > >> shouldn't we be working on this? > > > > Part of the problem is that some WGs want to make use of IPsec =20 > > protocols outside of the IPsec architecture. > > > >> > I am not comfortable with the notion of ESP with WESP. =20 > WESP adds > >> > more per-packet overhead than ESP, and some users are very =20 > >> sensitive > >>> to this aspect of IPsec use. Also, other WG rely on ESP and we =20 > >>> would > >>> need to convince them that the packet inspection features of WESP > >>> merit making changes to their standards, which might be a tough =20 > >>> sell. > >> > >> I agree. However, we should start socializing WESP in=20 > other WGs so =20 > >> that folks are at least aware of it. > > > > Agree. > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > >=20 > = From kohn.jack@gmail.com Wed Nov 11 20:29:46 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4232B28C143 for ; Wed, 11 Nov 2009 20:29:46 -0800 (PST) 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.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npAZmkUFbL5B for ; Wed, 11 Nov 2009 20:29:45 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 6594D3A6767 for ; Wed, 11 Nov 2009 20:29:45 -0800 (PST) Received: by gxk28 with SMTP id 28so1721944gxk.9 for ; Wed, 11 Nov 2009 20:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=aAnDAuJZJS3Ddf3w7sFw63Uzok4LbJ51RhwywiGTZ9A=; b=vPNSR4IoKZ+9kOvpbsvBVnyV662ojXblkzD5QFAGDPVNU8DdTk2YdGA8Jwc18v8F5M 9renfcQB7l3/TnG3rBD2M1SgqjATRIC8iRC8DiJQkvNpu6Ztl3YkgH+R+O5oQVdZtoOm TPXtfIqXmbAV+0FSB/lvTVHKHnPXWqdx0hIt4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MxJuTJ0T/WwlmR/R1QhA7x7DAtasQrh619oQvg9w4eN0fleeyxyITw+5VOe6x1NT8O ZKufFJDGKPo2Q34gL1f5PoFfZmo+m1O1ES3zk0UuMzcUqE67ZP8WdLOvyeXLZDHH/4s/ tcjeyhFtoXAlwq8rrZ7rjW0lNBadHU2TCFNXM= MIME-Version: 1.0 Received: by 10.91.20.28 with SMTP id x28mr3788638agi.23.1258000211743; Wed, 11 Nov 2009 20:30:11 -0800 (PST) In-Reply-To: References: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> Date: Thu, 12 Nov 2009 10:00:11 +0530 Message-ID: From: Jack Kohn To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Merike Kaeo Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 04:29:46 -0000 > > Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL (although > they never refer to it that way) as a MUST, and AH as a MAY. Ok, so can we work on deprecating AH? This way new standards defined in other WGs dont have to provide support for AH. Jack > > I probably was confused because the authors did not understand the IPsec > model as per RFC 4301, when I sat down and talked with them over 3 years > ago, with Sam Hartman in his SEC AD role. I am amazed that, in the final > analysis, they did try to adhere to the 4301 model (see section 11)! > > I don't know if any other apps have done what I thought (erroneously) had > been done here. > > Steve > > From mglt.ietf@gmail.com Wed Nov 11 21:44:13 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839CD3A687B for ; Wed, 11 Nov 2009 21:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ws1XDu1L2YHq for ; Wed, 11 Nov 2009 21:44:12 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 2076D3A6B7C for ; Wed, 11 Nov 2009 21:44:02 -0800 (PST) Received: by fxm7 with SMTP id 7so1854495fxm.29 for ; Wed, 11 Nov 2009 21:44:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=kF2FJouZ3Esk01Dupyn63nyCF2TFG/5U1ZMZnv2p9TQ=; b=HK6vKUqlMGyzvz8o1CUYQg5mH1qPX59qvJB7n+xtjEEl7yD2JzHp75dG5uLOUIVCmc gejaj5izjBABxhwFMSIa96O0qaDKc0HqP4WNHf+0nQ9bCQ6DIqnMXVvogIqkzP7M3hse GcGuxJ2oyxZUdsrVHtZGzkG3QPdUrru1pn4XI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=H9t9EMc+GIEPka6fG1OWZsib0jwb7xW7IOF2xJhFqTe91do8QS4Ndym4761woexKLi XX/VyoF0dAm1GeyGxLp0yEjbLL+REQzseKJ3tT/eCAWn6QRB3RiV3GZ5qw9QfUhROsY6 TdbhlghnyHBUXXDCqSrGjwjUAwwjGvUtqAbas= MIME-Version: 1.0 Received: by 10.103.50.28 with SMTP id c28mr812459muk.17.1258004667258; Wed, 11 Nov 2009 21:44:27 -0800 (PST) In-Reply-To: References: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> Date: Thu, 12 Nov 2009 06:44:27 +0100 Message-ID: <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.com> From: Daniel Migault To: Jack Kohn Content-Type: multipart/alternative; boundary=0016e65ae21251591504782609de Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Stephen Kent , Merike Kaeo Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 05:44:13 -0000 --0016e65ae21251591504782609de Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 12, 2009 at 5:30 AM, Jack Kohn wrote: > > > > Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL (although > > they never refer to it that way) as a MUST, and AH as a MAY. > > Ok, so can we work on deprecating AH? This way new standards defined > in other WGs dont have to provide support for AH. > > AH is a security feature we need to keep for header authentication. Other WG may chose not to deal with AH and only consider ESP. I don't see what's wrong with that? Regards Daniel -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --0016e65ae21251591504782609de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Nov 12, 2009 at 5:30 AM, Jack Ko= hn <kohn.jack@g= mail.com> wrote:
>
> Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL (altho= ugh
> they never refer to it that way) as a MUST, and AH as a MAY.

Ok, so can we work on deprecating AH? This way new standards defined<= br> in other WGs dont have to provide support for AH.


AH is a security = feature we need to keep for header authentication. Other WG may chose not t= o deal with AH and only consider ESP. I don't see what's wrong with= that?

=A0Regards

Daniel
--
Daniel Migault
Orange Labs -- Sec= urity
+33 6 70 72 69 58
--0016e65ae21251591504782609de-- From ynir@checkpoint.com Thu Nov 12 00:32:01 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003FC3A6A40 for ; Thu, 12 Nov 2009 00:32:01 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1K4YOxEBYMh for ; Thu, 12 Nov 2009 00:32:00 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 991B73A6872 for ; Thu, 12 Nov 2009 00:31:59 -0800 (PST) X-CheckPoint: {4AFBC4EE-E-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8077F29C00E; Thu, 12 Nov 2009 10:32:26 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5CEFC29C002; Thu, 12 Nov 2009 10:32:26 +0200 (IST) X-CheckPoint: {4AFBC4ED-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAC8WPc6018033; Thu, 12 Nov 2009 10:32:26 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 12 Nov 2009 10:32:28 +0200 From: Yoav Nir To: Raj Singh Date: Thu, 12 Nov 2009 10:32:24 +0200 Thread-Topic: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Thread-Index: AcpjcqsORhsCHZtuTo679B5d8F1kaQ== Message-ID: References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com> <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com> <3A8C969225424C4D8E6BEE65ED8552DA4C446E@XMB-BGL-41C.cisco.com> <39008D85-3D9B-4B8B-A9FA-C4C91658630E@checkpoint.com> <3A8C969225424C4D8E6BEE65ED8552DA4C4472@XMB-BGL-41C.cisco.com> <4A5E60B4-E903-441F-A839-09FE9198B468@checkpoint.com> <19195.18766.767555.230392@fireball.kivinen.iki.fi> <7ccecf670911111934u70f28feegf053b835ff3fb0f@mail.gmail.com> In-Reply-To: <7ccecf670911111934u70f28feegf053b835ff3fb0f@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-6-534670648"; protocol="application/pkcs7-signature" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "Amjad Inamdar \(amjads\)" , Tero Kivinen Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 08:32:01 -0000 --Apple-Mail-6-534670648 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 12, 2009, at 5:34 AM, Raj Singh wrote: > The selection of AAA server will be based on IDi then EAP will happen. > The gateway will get EAP authenticated ID from the AAA server. > If EAP identity is different from IDi and no policy is found for EAP = identity. > The gateway should initiate deletion of the SA. Actually, the gateway doesn't need to delete the SA. The gateway = receives the EAP identity before the end of the IKE_AUTH exchanges, so = it can terminate with an AUTHENTICATION_FAILED. No need for DELETE --Apple-Mail-6-534670648 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEHWPmpet94anoiUADSB7pZcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUxOTIxMDYyOFoXDTEwMDUxOTIxMDYy OFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN5Dac6srAGq YgV/Ggt0eXG8MRQRMR1SmIXm66utqDjcJhKDwKeyV5ICqQFr8ETbYZ7YgvSkXE7o9StCeqVvxKt0 hR5DTjho49VrCiaKex3q6d/VNh6E22yBqZBYbVa5xsxcPK6V2g/GXhyoNjoezeRVlRm0bbQtscKt GOt5BJFjjL5Ns/x0MktYgn24NIDnsTJKPEXl7vQzpwp6tnJJuiz/ttdW+7PII8vTkoHZpNGPW/aS bLR01T8ga739zosQ57YAdkih69BMHb+Q9zpRoSyd6NGEQ124TtskwWSAPAvw3TF2p0NlMKBU02Bt B07zkCodlx6sqOxeX7nVML26zI8CAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAA+x/ZiahLKaSb/kWVGx2gJAGAG5 C065lmMky3hmur1IfUa9GBXJO40Z4CdiD6Y/4wQgHkBPnRF4YdhMjd2ecE03/9+x4grNKaXaeiIl MXQtniPa1tO++O/8eaPiMx6AF+v4njB/q0CUpYF78fTloJuhflNPvdbV46Xj41fIDoFAMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB1j5qXrfeGp6IlAA0ge6WXMAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTExMjA4 MzIyNVowIwYJKoZIhvcNAQkEMRYEFDZSUWK7LxkQK2upJeRpgK+eRh6mMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdY+al633hqei JQANIHullzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQdY+al633hqeiJQANIHullzANBgkqhkiG9w0BAQEFAASCAQAkfUkLGpvj 19a5Hnh3NTzUYmr79TSf1Jlk4/D+naX6aIT/d4Lx6skWu882Rlsv78XA2aVyrWiJVhqAdvDzJ1Ib BDUQLm6u9yaBJDr/do+Y1DMGQ03j250BJiGOvYc/IJ0k162B9cSS5ldUCvrTSkEkTm3eBgbqcnVA Rn94/vPjOs+s96cUHMA9RWvi1sZ1JNMrmLfR0KshUUpKZGlxAUiKeIKaH8klLe9NXO+gqks7feDD EdJpn8B8c1/79Wu3WMizwfcG5B/TVt5XgeOpI+HXf0GtIj1YaUO2YG8iyv98cCXEC+4UPXKdYK8v vvYUrwiUluLCHxI5bMKKoQXqgTG0AAAAAAAA --Apple-Mail-6-534670648-- From amjads@cisco.com Thu Nov 12 02:40:42 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416C73A67F6 for ; Thu, 12 Nov 2009 02:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v42yXk6ax9Fa for ; Thu, 12 Nov 2009 02:40:41 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6B9473A6920 for ; Thu, 12 Nov 2009 02:40:41 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIN1+0pAaHte/2dsb2JhbADEJ5gEgjeCBQSBbHs X-IronPort-AV: E=Sophos;i="4.44,727,1249257600"; d="scan'208";a="49148183" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 12 Nov 2009 10:41:09 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nACAd3rL002882; Thu, 12 Nov 2009 10:41:08 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 16:11:08 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Nov 2009 16:09:02 +0530 Message-ID: <1CFAB1B15A6C1142BD1FC07D1CA82AB2016E66F5@XMB-BGL-417.cisco.com> In-Reply-To: <2E13B90533934A499FD727F9B353613C5155A7@zin33exm29.fsl.freescale.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Thread-Index: AcpjJy+IbwOddBiQS5iIcvnXvUEoawAElh4gAAlcq7A= References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com><4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com><3A8C969225424C4D8E6BEE65ED8552DA4C446E@XMB-BGL-41C.cisco.com><39008D85-3D9B-4B8B-A9FA-C4C91658630E@checkpoint.com><3A8C969225424C4D8E6BEE65ED8552DA4C4472@XMB-BGL-41C.cisco.com><4A5E60B4-E903-441F-A839-09FE9198B468@checkpoint.com> <19195.18766.767555.230392@fireball.kivinen.iki.fi> <2E13B90533934A499FD727F9B353613C5155A7@zin33exm29.fsl.freescale.net> From: "Amjad Inamdar (amjads)" To: "Murthy N Srinivas-B22237" , "Tero Kivinen" , "Yoav Nir" X-OriginalArrivalTime: 12 Nov 2009 10:41:08.0085 (UTC) FILETIME=[A48A7250:01CA6384] Cc: ipsec@ietf.org Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 10:40:42 -0000 Hi Murthy, As per the RFC, with EAP authentication, policy lookups and access control decisions should be based on EAP identity, so the gatway needs to know the EAP identity. The source of EAP identity for gateway is either IDi (when IDi is same as EAP identity) or AAA server providing authenticated EAP identity neither of which is mandated by RFC, and in case client(via IDi) and AAA server do not provide EAP identity, the only way gateway can get EAP identity is via EAP identity request to the client. ----- Ikev2-bis-05 section 2.16, last paragraph ----- When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for AAA routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method. It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder. In this case, the authenticated identity has to be sent from the AAA server to the IKEv2 responder. ---------------------------------------------------------- Thanks, -Amjad -----Original Message----- From: Murthy N Srinivas-B22237 [mailto:B22237@freescale.com]=20 Sent: Thursday, November 12, 2009 7:30 AM To: Tero Kivinen; Yoav Nir Cc: ipsec@ietf.org; Amjad Inamdar (amjads) Subject: RE: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Policy lookups are selected by Authenticator based on Authorization information received from AAA server after successful Authentication. The AAA sever uses an attribute(radius) to send a reference to the Authorization information specific for the specific client.The Authenticator need not know the EAP identitity of the client, if it is different from IKE identity. =20 The Authenticator requires to know the EAP identity only if it implements the AAA server functionality. =20 ns murthy -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Thursday, November 12, 2009 5:01 AM To: Yoav Nir Cc: ipsec@ietf.org; Amjad Inamdar (amjads) Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Yoav Nir writes: > Since the gateway acts as a pass-through, the requirement here is more > for the client, which is typically more integrated. The client should=20 > be prepared to give an identity hint both in IKE and later in the EAP=20 > session. And in that case the identities should really be same, and if they differ then the authenticated identity needs to be used for policy lookups, meaning that the EAP identity needs to be used. So the gateway needs to get that authenticated identity from the AAA server so it can do policy lookups based on it.=20 -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From B22237@freescale.com Wed Nov 11 17:59:38 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840F228C17B for ; Wed, 11 Nov 2009 17:59:38 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZFe+2rT8QRT for ; Wed, 11 Nov 2009 17:59:37 -0800 (PST) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id A11FE28C184 for ; Wed, 11 Nov 2009 17:59:37 -0800 (PST) Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id nAC1xoXf019105 for ; Wed, 11 Nov 2009 18:59:55 -0700 (MST) Received: from zin33exm29.fsl.freescale.net (zin33exm29.ap.freescale.net [10.232.192.28]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id nAC1xnbO023980 for ; Wed, 11 Nov 2009 19:59:50 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Nov 2009 07:29:47 +0530 Message-ID: <2E13B90533934A499FD727F9B353613C5155A7@zin33exm29.fsl.freescale.net> In-Reply-To: <19195.18766.767555.230392@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Thread-Index: AcpjJy+IbwOddBiQS5iIcvnXvUEoawAElh4g References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com><4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com><3A8C969225424C4D8E6BEE65ED8552DA4C446E@XMB-BGL-41C.cisco.com><39008D85-3D9B-4B8B-A9FA-C4C91658630E@checkpoint.com><3A8C969225424C4D8E6BEE65ED8552DA4C4472@XMB-BGL-41C.cisco.com><4A5E60B4-E903-441F-A839-09FE9198B468@checkpoint.com> <19195.18766.767555.230392@fireball.kivinen.iki.fi> From: "Murthy N Srinivas-B22237" To: "Tero Kivinen" , "Yoav Nir" X-Brightmail-Tracker: AAAAAQAAAWE= X-Brightmail-Tracker: AAAAAQAAAWE= X-Mailman-Approved-At: Thu, 12 Nov 2009 08:08:39 -0800 Cc: ipsec@ietf.org, "Amjad Inamdar \(amjads\)" Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 02:01:38 -0000 Policy lookups are selected by Authenticator based on Authorization information received from AAA server after successful Authentication. The AAA sever uses an attribute(radius) to send a reference to the Authorization information specific for the specific client.The Authenticator need not know the EAP identitity of the client, if it is different from IKE identity. =20 The Authenticator requires to know the EAP identity only if it implements the AAA server functionality. =20 ns murthy -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Thursday, November 12, 2009 5:01 AM To: Yoav Nir Cc: ipsec@ietf.org; Amjad Inamdar (amjads) Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Yoav Nir writes: > Since the gateway acts as a pass-through, the requirement here is more > for the client, which is typically more integrated. The client should=20 > be prepared to give an identity hint both in IKE and later in the EAP=20 > session. And in that case the identities should really be same, and if they differ then the authenticated identity needs to be used for policy lookups, meaning that the EAP identity needs to be used. So the gateway needs to get that authenticated identity from the AAA server so it can do policy lookups based on it.=20 -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From B22237@freescale.com Thu Nov 12 05:04:58 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40F93A689E for ; Thu, 12 Nov 2009 05:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agpOCflvmFYm for ; Thu, 12 Nov 2009 05:04:57 -0800 (PST) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id C7D3B3A6774 for ; Thu, 12 Nov 2009 05:04:57 -0800 (PST) Received: from de01smr02.am.mot.com (de01smr02.freescale.net [10.208.0.151]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id nACD5Hlg003036 for ; Thu, 12 Nov 2009 06:05:22 -0700 (MST) Received: from zin33exm29.fsl.freescale.net (zin33exm29.ap.freescale.net [10.232.192.28]) by de01smr02.am.mot.com (8.13.1/8.13.0) with ESMTP id nACD9KdT020520 for ; Thu, 12 Nov 2009 07:09:21 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Nov 2009 18:35:08 +0530 Message-ID: <2E13B90533934A499FD727F9B353613C51563E@zin33exm29.fsl.freescale.net> In-Reply-To: <1CFAB1B15A6C1142BD1FC07D1CA82AB2016E66F5@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Thread-Index: AcpjJy+IbwOddBiQS5iIcvnXvUEoawAElh4gAAlcq7AADktBsA== References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com><4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com><3A8C969225424C4D8E6BEE65ED8552DA4C446E@XMB-BGL-41C.cisco.com><39008D85-3D9B-4B8B-A9FA-C4C91658630E@checkpoint.com><3A8C969225424C4D8E6BEE65ED8552DA4C4472@XMB-BGL-41C.cisco.com><4A5E60B4-E903-441F-A839-09FE9198B468@checkpoint.com> <19195.18766.767555.230392@fireball.kivinen.iki.fi> <2E13B90533934A499FD727F9B353613C5155A7@zin33exm29.fsl.freescale.net> <1CFAB1B15A6C1142BD1FC07D1CA82AB2016E66F5@XMB-BGL-417.cisco.com> From: "Murthy N Srinivas-B22237" To: "Amjad Inamdar (amjads)" , "Tero Kivinen" , "Yoav Nir" X-Brightmail-Tracker: AAAAAQAAAWE= X-Brightmail-Tracker: AAAAAQAAAWE= X-Mailman-Approved-At: Thu, 12 Nov 2009 08:09:01 -0800 Cc: ipsec@ietf.org Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 13:04:58 -0000 Amjad, If the Authenticator includes the AAA server implementation,it should no the EAP identity to enforce policies.If AAA server is separate,we can add an attribute to AAA server for this purpose and in which case Authenticator does not have to know the EAP identity.It will use the attribute to select the policies. Thanks -ns murthy=20 -----Original Message----- From: Amjad Inamdar (amjads) [mailto:amjads@cisco.com]=20 Sent: Thursday, November 12, 2009 4:09 PM To: Murthy N Srinivas-B22237; Tero Kivinen; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Hi Murthy, As per the RFC, with EAP authentication, policy lookups and access control decisions should be based on EAP identity, so the gatway needs to know the EAP identity. The source of EAP identity for gateway is either IDi (when IDi is same as EAP identity) or AAA server providing authenticated EAP identity neither of which is mandated by RFC, and in case client(via IDi) and AAA server do not provide EAP identity, the only way gateway can get EAP identity is via EAP identity request to the client. ----- Ikev2-bis-05 section 2.16, last paragraph ----- When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for AAA routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method. It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder. In this case, the authenticated identity has to be sent from the AAA server to the IKEv2 responder. ---------------------------------------------------------- Thanks, -Amjad -----Original Message----- From: Murthy N Srinivas-B22237 [mailto:B22237@freescale.com] Sent: Thursday, November 12, 2009 7:30 AM To: Tero Kivinen; Yoav Nir Cc: ipsec@ietf.org; Amjad Inamdar (amjads) Subject: RE: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Policy lookups are selected by Authenticator based on Authorization information received from AAA server after successful Authentication. The AAA sever uses an attribute(radius) to send a reference to the Authorization information specific for the specific client.The Authenticator need not know the EAP identitity of the client, if it is different from IKE identity. =20 The Authenticator requires to know the EAP identity only if it implements the AAA server functionality. =20 ns murthy -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Thursday, November 12, 2009 5:01 AM To: Yoav Nir Cc: ipsec@ietf.org; Amjad Inamdar (amjads) Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Yoav Nir writes: > Since the gateway acts as a pass-through, the requirement here is more > for the client, which is typically more integrated. The client should=20 > be prepared to give an identity hint both in IKE and later in the EAP=20 > session. And in that case the identities should really be same, and if they differ then the authenticated identity needs to be used for policy lookups, meaning that the EAP identity needs to be used. So the gateway needs to get that authenticated identity from the AAA server so it can do policy lookups based on it.=20 -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From smb@cs.columbia.edu Thu Nov 12 10:27:06 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B91AE3A6AF3 for ; Thu, 12 Nov 2009 10:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+HUNybq6d+M for ; Thu, 12 Nov 2009 10:27:05 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id A7F603A6AF2 for ; Thu, 12 Nov 2009 10:27:05 -0800 (PST) Received: from 254.sub-75-207-162.myvzw.com (254.sub-75-207-162.myvzw.com [75.207.162.254]) (user=smb2132 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nACIRULQ029263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 12 Nov 2009 13:27:32 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: Date: Thu, 12 Nov 2009 09:54:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stephen Kent X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: ipsec@ietf.org, Jack Kohn Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 18:27:06 -0000 On Nov 11, 2009, at 3:56 PM, Stephen Kent wrote: > Jack, >=20 > I would have no problem deprecating AH in the context of the IPsec = architecture document, if others agree. It is less efficient than = ESP-NULL. However, other WGs have cited AH as the IPsec protocol of = choice for integrity/authentication in their environments, so there will = be a need to coordinate with them, and it may be unacceptable to kill AH = as a standalone protocol for them. I believe that most such uses date from the "just use IPsec" era of = security design. I further suspect that it is very rarely used or even = implemented in practice, and that in many cases it wouldn't in fact have = been usable. Yes, as a matter of due diligence someone needs to check if it's still = mandated for anything, and if so figure out what to do. But I'd be very = happy if AH were to go awa; I concluded in 1995 that it was pretty = useless. --Steve Bellovin, http://www.cs.columbia.edu/~smb From smoonen@us.ibm.com Thu Nov 12 11:41:47 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61FAC3A67D4; Thu, 12 Nov 2009 11:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRl2-DbYMUZw; Thu, 12 Nov 2009 11:41:45 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id B39333A691F; Thu, 12 Nov 2009 11:41:45 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nACJb4c9025964; Thu, 12 Nov 2009 12:37:04 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id nACJg14O238056; Thu, 12 Nov 2009 12:42:02 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nACJg1PN030255; Thu, 12 Nov 2009 12:42:01 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nACJg1GS030250; Thu, 12 Nov 2009 12:42:01 -0700 In-Reply-To: <20091111205238.GK101633@sun.com> References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB3@il-ex01.ad.checkpoint.com> <20091111205238.GK101633@sun.com> To: Dan McDonald MIME-Version: 1.0 X-KeepSent: A9EE68F0:EBDA9158-8525766C:006A268C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/12/2009 02:41:42 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/12/2009 02:41:42 PM, Serialize complete at 11/12/2009 02:41:42 PM, S/MIME Sign failed at 11/12/2009 02:41:42 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 11/12/2009 12:42:01, Serialize complete at 11/12/2009 12:42:01 Message-ID: Date: Thu, 12 Nov 2009 14:42:00 -0500 Content-Type: multipart/alternative; boundary="=_alternative 006C306D8525766C_=" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org, Yoav Nir , "Law, Laurie" Subject: Re: [IPsec] RFC4869 bis submitted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 19:41:47 -0000 This is a multipart message in MIME format. --=_alternative 006C306D8525766C_= Content-Type: text/plain; charset="US-ASCII" > > While the algorithms and DH groups are subject to configuration in the UI > > and negotiation in IKE, the algorithm used to sign the certificates is > > outside the IKE implementation. You usually have a certificate that you > > need to use, and it's the CA's decision whether this is signed with RSA, > > DSA or ECDSA. There's even some ambiguity, because it's not necessarily > > true, that the public key in the certificate is for the same algorithms > > used to sign the certificate. > > I strongly agree with Yoav here. I strongly agree with Yoav and Dan on decoupling the authentication method from the suite. This places an unnatural configuration burden on an IKE implementation. It is proper to configure one's choice of certificate -- but it is not natural to configure the certificate's authentication algorithm independently of simply choosing the desired certificate or CA. > Many IKEv1's have Phase 2 PFS as an on/off switch. It would be nice if you > picked one for these (either always-on or always-off). How would such an implementation handle RFC 4308? Our own implementation supports sending offers with and without PFS, but it does seem odd to me that these RFCs would punt on the decision to use PFS. There are valid reasons for either approach (CPU cost versus key independence). I suppose we could create separate versions of the suites with and without PFS, but it's probably ok for the suites to simply be "opinionated". I guess that means we'd go with PFS=on. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Dan McDonald To: Yoav Nir Cc: "ipsec@ietf.org" , "Law, Laurie" Date: 11/11/2009 03:54 PM Subject: Re: [IPsec] RFC4869 bis submitted On Wed, Nov 11, 2009 at 10:07:31PM +0200, Yoav Nir wrote: > While the algorithms and DH groups are subject to configuration in the UI > and negotiation in IKE, the algorithm used to sign the certificates is > outside the IKE implementation. You usually have a certificate that you > need to use, and it's the CA's decision whether this is signed with RSA, > DSA or ECDSA. There's even some ambiguity, because it's not necessarily > true, that the public key in the certificate is for the same algorithms > used to sign the certificate. I strongly agree with Yoav here. Especially given certificate operations are much rarer in IKEv2 (given their SAs last indefinitely long), would 2048-bit RSA or 4096-bit RSA certs be unreasonable? I understand the cert-chain issues with weak hashes, but those do not come directly into play during the IKE exchange. (Imagine self-signed certs for IKE, e.g.) > The UI suites RFC that defined VPN-A and VPN-B did not mandate RSA or > DSA. I don't see why 4869 or 4869-bis should. I don't think it's part of > the algorithm configuration. Also --> the new bis document talks about IKEv1's Phase 2 Diffie-Hellman as a MAY without saying it. I quote: Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2) MUST be supported by both parties in this suite. The initiator of this exchange MAY include a new Diffie-Hellman key; if it is included, it MUST use the 256-bit random ECP group. If the initiator of the exchange includes a Diffie-Hellman key, the responder MUST include a Diffie-Hellman key, and it MUST use the 256-bit random ECP group. Many IKEv1's have Phase 2 PFS as an on/off switch. It would be nice if you picked one for these (either always-on or always-off). Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 006C306D8525766C_= Content-Type: text/html; charset="US-ASCII"
> > While the algorithms and DH groups are subject to configuration in the UI
> > and negotiation in IKE, the algorithm used to sign the certificates is
> > outside the IKE implementation. You usually have a certificate that you
> > need to use, and it's the CA's decision whether this is signed with RSA,
> > DSA or ECDSA. There's even some ambiguity, because it's not necessarily
> > true, that the public key in the certificate is for the same algorithms
> > used to sign the certificate.
>
> I strongly agree with Yoav here.

I strongly agree with Yoav and Dan on decoupling the authentication method from the suite.  This places an unnatural configuration burden on an IKE implementation.  It is proper to configure one's choice of certificate -- but it is not natural to configure the certificate's authentication algorithm independently of simply choosing the desired certificate or CA.

> Many IKEv1's have Phase 2 PFS as an on/off switch.  It would be nice if you
> picked one for these (either always-on or always-off).

How would such an implementation handle RFC 4308?  Our own implementation supports sending offers with and without PFS, but it does seem odd to me that these RFCs would punt on the decision to use PFS.  There are valid reasons for either approach (CPU cost versus key independence).  I suppose we could create separate versions of the suites with and without PFS, but it's probably ok for the suites to simply be "opinionated".  I guess that means we'd go with PFS=on.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Dan McDonald <danmcd@sun.com>
To: Yoav Nir <ynir@checkpoint.com>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "Law, Laurie" <lelaw@tycho.ncsc.mil>
Date: 11/11/2009 03:54 PM
Subject: Re: [IPsec] RFC4869 bis submitted




On Wed, Nov 11, 2009 at 10:07:31PM +0200, Yoav Nir wrote:
> While the algorithms and DH groups are subject to configuration in the UI
> and negotiation in IKE, the algorithm used to sign the certificates is
> outside the IKE implementation. You usually have a certificate that you
> need to use, and it's the CA's decision whether this is signed with RSA,
> DSA or ECDSA. There's even some ambiguity, because it's not necessarily
> true, that the public key in the certificate is for the same algorithms
> used to sign the certificate.

I strongly agree with Yoav here.

Especially given certificate operations are much rarer in IKEv2 (given their
SAs last indefinitely long), would 2048-bit RSA or 4096-bit RSA certs be
unreasonable?  I understand the cert-chain issues with weak hashes, but those
do not come directly into play during the IKE exchange.  (Imagine self-signed
certs for IKE, e.g.)

> The UI suites RFC that defined VPN-A and VPN-B did not mandate RSA or
> DSA. I don't see why 4869 or 4869-bis should. I don't think it's part of
> the algorithm configuration.

Also --> the new bis document talks about IKEv1's Phase 2 Diffie-Hellman as a
MAY without saying it.  I quote:

 Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
 MUST be supported by both parties in this suite.  The initiator of
 this exchange MAY include a new Diffie-Hellman key; if it is
 included, it MUST use the 256-bit random ECP group.  If the
 initiator of the exchange includes a Diffie-Hellman key, the
 responder MUST include a Diffie-Hellman key, and it MUST use the
 256-bit random ECP group.

Many IKEv1's have Phase 2 PFS as an on/off switch.  It would be nice if you
picked one for these (either always-on or always-off).

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

--=_alternative 006C306D8525766C_=-- From fdetienn@cisco.com Thu Nov 12 14:35:45 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5070F3A68D3 for ; Thu, 12 Nov 2009 14:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEmb3OVJGV9r for ; Thu, 12 Nov 2009 14:35:44 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 0CD583A68A5 for ; Thu, 12 Nov 2009 14:35:43 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nACMWPtJ003806; Thu, 12 Nov 2009 23:32:25 +0100 (CET) Received: from ams-fdetienn-8717.cisco.com (ams-fdetienn-8717.cisco.com [10.55.136.232]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nACMWKuN027728; Thu, 12 Nov 2009 23:32:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-12-585065835 From: Frederic Detienne In-Reply-To: <39008D85-3D9B-4B8B-A9FA-C4C91658630E@checkpoint.com> Date: Thu, 12 Nov 2009 23:32:19 +0100 Message-Id: <8D65C1C1-F360-4139-B8C8-17D57A5E4EB1@cisco.com> References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com> <4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com> <3A8C969225424C4D8E6BEE65ED8552DA4C446E@XMB-BGL-41C.cisco.com> <39008D85-3D9B-4B8B-A9FA-C4C91658630E@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Thu, 12 Nov 2009 16:46:01 -0800 Cc: "ipsec@ietf.org" , "Amjad Inamdar \(amjads\)" Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAP authentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 22:35:45 -0000 --Apple-Mail-12-585065835 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 11 Nov 2009, at 14:53, Yoav Nir wrote: >=20 > On Nov 11, 2009, at 3:39 PM, Srinivasu S R S Dhulipala (srinid) wrote: >>=20 >>> 2) If not same, what purpose should each of the above identities = serve >>=20 >> 1) mainly used as a hint for the gateway as to which AAA server to >> choose >> 2) It's the AAA server that may request the identity, and it's >> internal to AAA. It doesn't play in IKE >>=20 >> [SRINI] Does this imply that gateway SHOULD not send EAP identity >> request to the client, >> we see that one 3rd party IKEv2 client is sending IP = address >> as IDi, from which we can't >> take any hints. Moreover, the same client is expecting an >> EAP-ID request to be sent, >> else EAP is failing. >> I've started another thread about why did we demote = "SHOULD" >> to "should" if the gateway is >> Not supposed to send EAP-identity request to the client. I >> think we should promote it back. >=20 > The gateway never sends any EAP identity requests at all. If such a = request exists, it is sent by the AAA server. The gateway serves only as = a pass-through. >=20 > For that reason, there is typically no reason for the gateway to = inspect the contents of the EAP payload. This is the gist of the question. It is tempting for the client = implementation to send just a dummy IDi (like an IP address) that = prevents proper selection of the AAA server for subsequent = authentication. The client rationale being that the proper ID will be = passed during EAP. As such inspecting the ID_request is also tempting to = circumvent the client's behavior. It would be a good idea to recommend IDi to be meaningful for AAA = selection and avoid drama's. Something like: --8<-- IDi SHOULD be meaningful enough for the responder to select an adequate = authentication and authorization profile. The IDi SHOULD be unique in = the authentication domain, constant over time and structured. ID_FQDN, = ID_DER_ASN1_DN, ID_RFC822_ADDR are good candidates for an IDi. Other ID = types are good if they match the above criteria. --8<-- This is something that is not immediately obvious to the client = developers and will help server developers to convey their point. fred >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail-12-585065835 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On = Nov 11, 2009, at 3:39 PM, Srinivasu S R S Dhulipala (srinid) = wrote:

2) If not same, what purpose = should each of the above identities = serve

 1) = mainly used as a hint for the gateway as to which AAA server = to
choose
 2) = It's the AAA server that may request the identity, and = it's
internal to AAA. It = doesn't play in IKE

[SRINI] Does = this imply that gateway SHOULD not send EAP = identity
request to the = client,
=           we see that = one 3rd party IKEv2 client is sending IP = address
as IDi, from which we = can't
=           take any = hints. Moreover, the same client is expecting = an
EAP-ID request to be = sent,
=           else EAP is = failing.
=           I've started = another thread about why did we demote = "SHOULD"
to "should" if the = gateway is
=           Not supposed = to send EAP-identity request to the client. = I
think we should promote it = back.

The gateway never sends any EAP identity = requests at all. If such a request exists, it is sent by the AAA server. = The gateway serves only as a pass-through.

For that reason, there = is typically no reason for the gateway to inspect the contents of the = EAP payload.

This is the gist = of the question. It is tempting for the client implementation to send = just a dummy IDi (like an IP address) that prevents proper selection of = the AAA server for subsequent authentication. The client rationale being = that the proper ID will be passed during EAP. As such inspecting the = ID_request is also tempting to circumvent the client's = behavior.

It would be a good idea to recommend = IDi to be meaningful for AAA selection and avoid drama's. Something = like:

--8<--
IDi SHOULD be = meaningful enough for the responder to select an adequate authentication = and authorization profile. The IDi SHOULD be unique in the = authentication domain, constant over time and structured. ID_FQDN, = ID_DER_ASN1_DN, ID_RFC822_ADDR are good candidates for an IDi. Other ID types are good = if they match the above = criteria.
--8<--

This = is something that is not immediately obvious to the client developers = and will help server developers to convey their = point.

= fred


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

= --Apple-Mail-12-585065835-- From paul.hoffman@vpnc.org Thu Nov 12 16:58:34 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E339528C148 for ; Thu, 12 Nov 2009 16:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.933 X-Spam-Level: X-Spam-Status: No, score=-5.933 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGGgu6kWliED for ; Thu, 12 Nov 2009 16:58:34 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 8FF2D28C0D8 for ; Thu, 12 Nov 2009 16:58:32 -0800 (PST) Received: from [133.93.128.35] (host-56-202.meeting.ietf.org [133.93.56.202]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAD0wtUg059978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Nov 2009 17:58:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB3@il-ex01.ad.checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB3@il-ex01.ad.checkpoint.com> Date: Fri, 13 Nov 2009 09:58:15 +0900 To: Yoav Nir , "Law, Laurie" , "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] RFC4869 bis submitted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 00:58:35 -0000 At 10:07 PM +0200 11/11/09, Yoav Nir wrote: >If you're bissing this thing, can we please please please entirely get rid of the requirement to use ECDSA certificates? There is no "we" here. It is not a WG item, it is an individual submission that the authors chose to alert the WG about. Having said that, it is perfectly natural for the submitters to require a particular type of authentication in a suite. For this one, it is clear that they want to use EC throughout the suite for asymmetric operations. For a different one, the organization specifying the suite might allow RSA but require a particular key size to match the strength desired. >While the algorithms and DH groups are subject to configuration in the UI and negotiation in IKE, the algorithm used to sign the certificates is outside the IKE implementation. That is not at all true. The IKE implementation must be able to both sign and verify using the keys in the certificates, so the algorithm is quite inside the IKE implementation. > You usually have a certificate that you need to use, and it's the CA's decision whether this is signed with RSA, DSA or ECDSA. There's even some ambiguity, because it's not necessarily true, that the public key in the certificate is for the same algorithms used to sign the certificate. The draft says: The authentication method for systems that use IKEv2 MUST be either ECDSA-256 or ECDSA-384 [RFC4754]. How would you reword that to say that both the keys in the certificates and the keys that signed them must be either ECDSA-256 or ECDSA-384? >The UI suites RFC that defined VPN-A and VPN-B did not mandate RSA or DSA. Correct. >I don't see why 4869 or 4869-bis should. Because that is what the creators of the profile want. The whole purpose of profiles is to allow the creators to be able to state all of the relevant crypto policy. >I don't think it's part of the algorithm configuration. How is the signing algorithm of the certificates used *not* part of the algorithm configuration? --Paul Hoffman, Director --VPN Consortium From manav.bhatia@alcatel-lucent.com Thu Nov 12 17:18:09 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D2D928C140 for ; Thu, 12 Nov 2009 17:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQU3CulA6dyR for ; Thu, 12 Nov 2009 17:18:08 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id 7AD2C28C0FC for ; Thu, 12 Nov 2009 17:18:08 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id nAD1IJLa011386; Thu, 12 Nov 2009 19:18:19 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (h202-65-2-130.alcatel.com [202.65.2.130]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id nAD1IHkQ025163; Thu, 12 Nov 2009 19:18:18 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id nAD1Gkid015393; Fri, 13 Nov 2009 09:16:47 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 13 Nov 2009 06:48:15 +0530 From: "Bhatia, Manav (Manav)" To: Daniel Migault Date: Fri, 13 Nov 2009 06:48:13 +0530 Thread-Topic: [IPsec] WESP - Roadmap Ahead Thread-Index: AcpjWzY1tlG9w3GDRPO2LkSZ8gmclAAoTEfQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB2C85E06@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.com> In-Reply-To: <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.130 Cc: "ipsec@ietf.org" , Stephen Kent , Kaeo , Merike Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 01:18:09 -0000 Daniel, > AH is a security feature we need to keep for header authentication =20 Am really not sure about the value that AH adds even in case of header auth= entication. =20 So what fields does AH protect: =20 Version, Payload length, Next Header, Source IP and dest IP =20 The only field worth modifying is the source and the dest IP. Now note that= an IPSec SA is established between a pair of source IP and dest IP. Upon r= eceipt of a packet containing an AH header, the receiver determines the app= ropriate (unidirectional) SA, based on the dest IP, security protocol (AH),= and the SPI (it could also include the source IP). If the attacker modifie= s (or spoofs) either of the source or the dest IP, the SA lookup will fail = and the receiver will regardless discard the packet. So what are we gaining= by AH "header authentication"? AH can only add value over ESP-NULL if there are instances where despite ad= dress spoofing we erroneously process the IPSec packet. I don't see that ha= ppening, so is this really an issue? Cheers, Manav ________________________________ From: Daniel Migault [mailto:mglt.ietf@gmail.com]=20 Sent: Thursday, November 12, 2009 11.14 AM To: Jack Kohn Cc: Stephen Kent; ipsec@ietf.org; Bhatia, Manav (Manav); Merike Kaeo Subject: Re: [IPsec] WESP - Roadmap Ahead =09 On Thu, Nov 12, 2009 at 5:30 AM, Jack Kohn wrote: > > Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL (althou= gh > they never refer to it that way) as a MUST, and AH as a MAY. =09 Ok, so can we work on deprecating AH? This way new standards defined in other WGs dont have to provide support for AH. =09 AH is a security feature we need to keep for header authentication. Other = WG may chose not to deal with AH and only consider ESP. I don't see what's = wrong with that? =09 Regards =09 Daniel --=20 Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 =09 From rfgraveman@gmail.com Thu Nov 12 17:36:59 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3929F3A691A for ; Thu, 12 Nov 2009 17:36:59 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FDheKm9hHXb for ; Thu, 12 Nov 2009 17:36:58 -0800 (PST) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id 2DBF93A67F0 for ; Thu, 12 Nov 2009 17:36:58 -0800 (PST) Received: by iwn16 with SMTP id 16so2331322iwn.29 for ; Thu, 12 Nov 2009 17:37:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ludoHXDB3xdVB3vtEYQLHuvA0l2rKrKzDR4At2ELP0E=; b=RtelFkzpLZI78nSjdX5E+zr+DeHNfwmSfIbF0etoS7bGZNzTS/k957B0kgaE66Lc9l QQkQkaBOlnA8Cm5NNnLgWh/LDgA6HcQx1gEk+FM7Mlx897fRbjYwRT5ygLpNYMdkx5++ w0dBGvvYmcarqpnyUNZuscXpwUKqx/buOli5s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CxfKZ2xwu/ZK1nJRw1eDNpDVQYAQAXbb30hFM/L/Lkr8Sozb9iydFygRzHyxtMK8xT Jgkus+JMN3aI3GZ9/qndeg1h2BUQ8bFqOPBDyMNAkz9jrp5VV98AISmx+3y8LcHdQsJY Kaxs0U9/DNUMNil4a/bXoA7c8g+izL5gSUlvQ= MIME-Version: 1.0 Received: by 10.231.26.131 with SMTP id e3mr3299806ibc.0.1258076245111; Thu, 12 Nov 2009 17:37:25 -0800 (PST) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350AB2C85E06@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.com> <7C362EEF9C7896468B36C9B79200D8350AB2C85E06@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 12 Nov 2009 20:37:25 -0500 Message-ID: <45c8c21a0911121737v1659cc01vd716ab401023af1e@mail.gmail.com> From: Richard Graveman To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" , Merike@core3.amsl.com, Kaeo , Stephen Kent , Daniel Migault Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 01:36:59 -0000 I think this argument implicitly assumes unicast. Rich Graveman On Thu, Nov 12, 2009 at 8:18 PM, Bhatia, Manav (Manav) wrote: > Daniel, > >> AH is a security feature we need to keep for header authentication > > Am really not sure about the value that AH adds even in case of header au= thentication. > > So what fields does AH protect: > > Version, Payload length, Next Header, Source IP and dest IP > > The only field worth modifying is the source and the dest IP. Now note th= at an IPSec SA is established between a pair of source IP and dest IP. Upon= receipt of a packet containing an AH header, the receiver determines the a= ppropriate (unidirectional) SA, based on the dest IP, security protocol (AH= ), and the SPI (it could also include the source IP). If the attacker modif= ies (or spoofs) either of the source or the dest IP, the SA lookup will fai= l and the receiver will regardless discard the packet. So what are we gaini= ng by AH "header authentication"? > > AH can only add value over ESP-NULL if there are instances where despite = address spoofing we erroneously process the IPSec packet. I don't see that = happening, so is this really an issue? > > Cheers, Manav > ________________________________ > > =A0 =A0 =A0 =A0From: Daniel Migault [mailto:mglt.ietf@gmail.com] > =A0 =A0 =A0 =A0Sent: Thursday, November 12, 2009 11.14 AM > =A0 =A0 =A0 =A0To: Jack Kohn > =A0 =A0 =A0 =A0Cc: Stephen Kent; ipsec@ietf.org; Bhatia, Manav (Manav); M= erike Kaeo > =A0 =A0 =A0 =A0Subject: Re: [IPsec] WESP - Roadmap Ahead > > =A0 =A0 =A0 =A0On Thu, Nov 12, 2009 at 5:30 AM, Jack Kohn wrote: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Whoops, I was wrong. I looked at 4552 an= d they do cite ESP-NULL (although > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> they never refer to it that way) as a MU= ST, and AH as a MAY. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ok, so can we work on deprecating AH? This= way new standards defined > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in other WGs dont have to provide support = for AH. > > > =A0 =A0 =A0 =A0AH is a security feature we need to keep for header authen= tication. Other WG may chose not to deal with AH and only consider ESP. I d= on't see what's wrong with that? > > =A0 =A0 =A0 =A0 Regards > > =A0 =A0 =A0 =A0Daniel > =A0 =A0 =A0 =A0-- > =A0 =A0 =A0 =A0Daniel Migault > =A0 =A0 =A0 =A0Orange Labs -- Security > =A0 =A0 =A0 =A0+33 6 70 72 69 58 > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From kent@bbn.com Thu Nov 12 18:14:43 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E01D23A698F for ; Thu, 12 Nov 2009 18:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWseYOdH4+Bq for ; Thu, 12 Nov 2009 18:14:43 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 215DD3A6839 for ; Thu, 12 Nov 2009 18:14:43 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[133.93.16.246]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N8lgr-0002Uf-CW; Thu, 12 Nov 2009 21:15:10 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350AB2C85E06@INBANSXCHMBSA1.in.alcatel-luce nt.com> References: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.com> <7C362EEF9C7896468B36C9B79200D8350AB2C85E06@INBANSXCHMBSA1.in.alcatel-luce nt.com> Date: Thu, 12 Nov 2009 20:33:11 -0500 To: "Bhatia, Manav (Manav)" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , Merike@core3.amsl.com, Kaeo , Daniel Migault Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 02:14:44 -0000 At 6:48 AM +0530 11/13/09, Bhatia, Manav (Manav) wrote: >Daniel, > >> AH is a security feature we need to keep for header authentication > >Am really not sure about the value that AH adds even in case of >header authentication. > >So what fields does AH protect: > >Version, Payload length, Next Header, Source IP and dest IP you forgot IPv4 and IPv6 options that have predictable values at the destination Steve From kent@bbn.com Thu Nov 12 18:37:48 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAAF53A6955 for ; Thu, 12 Nov 2009 18:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VXiwarEF0w9 for ; Thu, 12 Nov 2009 18:37:48 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 174823A683D for ; Thu, 12 Nov 2009 18:37:48 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[133.93.16.246]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N8m3E-0002rv-Bh for ipsec@ietf.org; Thu, 12 Nov 2009 21:38:16 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB3@il-ex01.ad.checkpoint.com> Date: Thu, 12 Nov 2009 21:38:13 -0500 To: ipsec@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Re: [IPsec] RFC4869 bis submitted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 02:37:48 -0000 I agree with all of Paul's observations. The scope of this profile is entirely appropriate. Steve From manav.bhatia@alcatel-lucent.com Thu Nov 12 20:42:35 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A071D3A6A38 for ; Thu, 12 Nov 2009 20:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXe2xhhbhfBW for ; Thu, 12 Nov 2009 20:42:34 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by core3.amsl.com (Postfix) with ESMTP id B76333A676A for ; Thu, 12 Nov 2009 20:42:34 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id nAD4gtXI005475; Thu, 12 Nov 2009 22:42:56 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (aprelay03.apac.alcatel-lucent.com [202.65.2.133]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id nAD4grC0013133; Thu, 12 Nov 2009 22:42:54 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id nAD4jjqD014942; Fri, 13 Nov 2009 12:45:46 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 13 Nov 2009 10:12:50 +0530 From: "Bhatia, Manav (Manav)" To: Stephen Kent Date: Fri, 13 Nov 2009 10:12:47 +0530 Thread-Topic: [IPsec] WESP - Roadmap Ahead Thread-Index: AcpkByQNmvb9tFQzS8OQWAWEttLuSAADUvvg Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB2C85E59@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.com> <7C362EEF9C7896468B36C9B79200D8350AB2C85E06@INBANSXCHMBSA1.in.alcatel-luce nt.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 172.22.12.27 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.133 Cc: "ipsec@ietf.org" , "Merike@core3.amsl.com" , Kaeo , Daniel Migault Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 04:42:35 -0000 > > > >So what fields does AH protect: > > > >Version, Payload length, Next Header, Source IP and dest IP >=20 > you forgot IPv4 and IPv6 options that have predictable values at the=20 > destination Lets start with the IPv6 Type 0 Route Header (aka "Source Routing" in v4 pa= rlance), which is a mutable but a predictable extension header. It has been= discovered and is widely known that these functionalities can be exploited= in order to perform remote network discovery, can be used to bypass firewa= lls and can be used for DoS attacks. RFC 5095 has more details on this. Thi= s has been deprecated and nobody is really using this. Hop-by-Hop Options and Destination Extension Headers These options contain a bit that indicates whether the option might change = (unpredictably) during transit. For any option for which contents may chan= ge en-route, the entire "Option Data" field must be treated as zero-valued = octets when computing or verifying the ICV. The Option Type and Opt Data L= en are included in the ICV calculation. All options for which the bit indic= ates immutability are included in the ICV calculation. =20 If we were to use ESP-NULL instead then there is no way to validate whether= the Option Type and Opt Data Len is valid or not till the processing is do= ne at the receiving end. So, what kind of attack can be possibly done by changing these values? What= is the real risk involved here? Fragmentation Header Fragmentation occurs after AH processing and the reassembly, before AH proc= essing on the other end. So, there is really no gain there too. Cheers, Manav=20 From manav.bhatia@alcatel-lucent.com Thu Nov 12 20:55:22 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38D543A6801 for ; Thu, 12 Nov 2009 20:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNrYSaOYxl+d for ; Thu, 12 Nov 2009 20:55:21 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id 5E33D3A67DB for ; Thu, 12 Nov 2009 20:55:21 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id nAD4toQd007573; Thu, 12 Nov 2009 22:55:50 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (h202-65-2-130.alcatel.com [202.65.2.130]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id nAD4tma6021181; Thu, 12 Nov 2009 22:55:49 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id nAD4pGI1016640; Fri, 13 Nov 2009 12:54:18 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 13 Nov 2009 10:24:29 +0530 From: "Bhatia, Manav (Manav)" To: Richard Graveman Date: Fri, 13 Nov 2009 10:24:27 +0530 Thread-Topic: [IPsec] WESP - Roadmap Ahead Thread-Index: AcpkAd3D8mOSnPSbSvmyQgCKy2ELlgAGlD9A Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB2C85E6D@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.com> <7C362EEF9C7896468B36C9B79200D8350AB2C85E06@INBANSXCHMBSA1.in.alcatel-lucent.com> <45c8c21a0911121737v1659cc01vd716ab401023af1e@mail.gmail.com> In-Reply-To: <45c8c21a0911121737v1659cc01vd716ab401023af1e@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.130 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 04:55:22 -0000 Yup, that's correct I had not considered multicast. SSM groups would use a 3-tuple SA identifier composed of an SPI, a dest mca= st address, and the source IP. An Any-Source Multicast group SA would only = require an SPI and a dest mcast identifier. If either of the IPs change, wo= uldn't the SAD lookup fail? Cheers, Manav > -----Original Message----- > From: Richard Graveman [mailto:rfgraveman@gmail.com]=20 > Sent: Friday, November 13, 2009 7.07 AM > To: Bhatia, Manav (Manav) > Cc: Daniel Migault; ipsec@ietf.org; Stephen Kent; Kaeo;=20 > Merike@core3.amsl.com > Subject: Re: [IPsec] WESP - Roadmap Ahead >=20 > I think this argument implicitly assumes unicast. >=20 > Rich Graveman >=20 > On Thu, Nov 12, 2009 at 8:18 PM, Bhatia, Manav (Manav) > wrote: > > Daniel, > > > >> AH is a security feature we need to keep for header authentication > > > > Am really not sure about the value that AH adds even in=20 > case of header authentication. > > > > So what fields does AH protect: > > > > Version, Payload length, Next Header, Source IP and dest IP > > From kent@bbn.com Thu Nov 12 21:15:59 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6AB93A68FC for ; Thu, 12 Nov 2009 21:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtzubWd4jWnp for ; Thu, 12 Nov 2009 21:15:59 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 001333A691C for ; Thu, 12 Nov 2009 21:15:58 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[133.93.16.246]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1N8oWH-0005Eb-CZ; Fri, 13 Nov 2009 00:16:26 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350AB2C85E59@INBANSXCHMBSA1.in.alcatel-luce nt.com> References: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.com> <7C362EEF9C7896468B36C9B79200D8350AB2C85E06@INBANSXCHMBSA1.in.alcatel-luce nt.com> <7C362EEF9C7896468B36C9B79200D8350AB2C85E59@INBANSXCHMBSA1.in.alcatel-luce nt.com> Date: Fri, 13 Nov 2009 00:16:21 -0500 To: "Bhatia, Manav (Manav)" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 05:15:59 -0000 My message pointed out that there was no mention of options, Your reply picked a couple of option examples and argued that they were either not used or did not pose a security problem. The right way to generate a god answer is to construct a table of all the options, and provide a rationale for why each one is not covered, deprecated, or not secruity relevant. Also, note that IPSO and CIPSO are examples of options that were discussed at the IPSECME meeting this week, where there is a need to bind the options to the payload. I observed that using tunnel mode (ESP) addresses this concern, but one could also note that using AH would do the same, with lower per-packet bandwidth overhead. Steve From amjads@cisco.com Thu Nov 12 23:00:17 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5221C3A681F for ; Thu, 12 Nov 2009 23:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOUHvwBb0zND for ; Thu, 12 Nov 2009 23:00:16 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2A2CE3A67BD for ; Thu, 12 Nov 2009 23:00:16 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPuS/EqrR7H+/2dsb2JhbAC9GJgjgjeCBQSBbX4 X-IronPort-AV: E=Sophos;i="4.44,735,1249257600"; d="scan'208";a="431600374" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 13 Nov 2009 07:00:46 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAD70gl5010624; Fri, 13 Nov 2009 07:00:45 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Nov 2009 12:30:43 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Nov 2009 12:30:40 +0530 Message-ID: <1CFAB1B15A6C1142BD1FC07D1CA82AB2016E687F@XMB-BGL-417.cisco.com> In-Reply-To: <2E13B90533934A499FD727F9B353613C51563E@zin33exm29.fsl.freescale.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Thread-Index: AcpjJy+IbwOddBiQS5iIcvnXvUEoawAElh4gAAlcq7AADktBsAAlbamg References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com><4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com><3A8C969225424C4D8E6BEE65ED8552DA4C446E@XMB-BGL-41C.cisco.com><39008D85-3D9B-4B8B-A9FA-C4C91658630E@checkpoint.com><3A8C969225424C4D8E6BEE65ED8552DA4C4472@XMB-BGL-41C.cisco.com><4A5E60B4-E903-441F-A839-09FE9198B468@checkpoint.com> <19195.18766.767555.230392@fireball.kivinen.iki.fi> <2E13B90533934A499FD727F9B353613C5155A7@zin33exm29.fsl.freescale.net> <1CFAB1B15A6C1142BD1FC07D1CA82AB2016E66F5@XMB-BGL-417.cisco.com> <2E13B90533934A499FD727F9B353613C51563E@zin33exm29.fsl.freescale.net> From: "Amjad Inamdar (amjads)" To: "Murthy N Srinivas-B22237" , "Tero Kivinen" , "Yoav Nir" X-OriginalArrivalTime: 13 Nov 2009 07:00:43.0321 (UTC) FILETIME=[04615A90:01CA642F] Cc: ipsec@ietf.org Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 07:00:17 -0000 Hi Murthy, IKEv2 gatway even when acting as a pass-through would need the authenticated EAP identity for local policy decisions. For instance, gateway can group remote users based on the authenticated EAP-id (e.g. based on the domain/realm part of the ID). Further, with PSK and PKI auth methods, it is the authenticated ID that is used for policy decisions and that should be same even with EAP auth. Thanks, -Amjad=20 -----Original Message----- From: Murthy N Srinivas-B22237 [mailto:B22237@freescale.com]=20 Sent: Thursday, November 12, 2009 6:35 PM To: Amjad Inamdar (amjads); Tero Kivinen; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Amjad, If the Authenticator includes the AAA server implementation,it should no the EAP identity to enforce policies.If AAA server is separate,we can add an attribute to AAA server for this purpose and in which case Authenticator does not have to know the EAP identity.It will use the attribute to select the policies. Thanks -ns murthy=20 -----Original Message----- From: Amjad Inamdar (amjads) [mailto:amjads@cisco.com] Sent: Thursday, November 12, 2009 4:09 PM To: Murthy N Srinivas-B22237; Tero Kivinen; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Hi Murthy, As per the RFC, with EAP authentication, policy lookups and access control decisions should be based on EAP identity, so the gatway needs to know the EAP identity. The source of EAP identity for gateway is either IDi (when IDi is same as EAP identity) or AAA server providing authenticated EAP identity neither of which is mandated by RFC, and in case client(via IDi) and AAA server do not provide EAP identity, the only way gateway can get EAP identity is via EAP identity request to the client. ----- Ikev2-bis-05 section 2.16, last paragraph ----- When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for AAA routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method. It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder. In this case, the authenticated identity has to be sent from the AAA server to the IKEv2 responder. ---------------------------------------------------------- Thanks, -Amjad -----Original Message----- From: Murthy N Srinivas-B22237 [mailto:B22237@freescale.com] Sent: Thursday, November 12, 2009 7:30 AM To: Tero Kivinen; Yoav Nir Cc: ipsec@ietf.org; Amjad Inamdar (amjads) Subject: RE: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Policy lookups are selected by Authenticator based on Authorization information received from AAA server after successful Authentication. The AAA sever uses an attribute(radius) to send a reference to the Authorization information specific for the specific client.The Authenticator need not know the EAP identitity of the client, if it is different from IKE identity. =20 The Authenticator requires to know the EAP identity only if it implements the AAA server functionality. =20 ns murthy -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Thursday, November 12, 2009 5:01 AM To: Yoav Nir Cc: ipsec@ietf.org; Amjad Inamdar (amjads) Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Yoav Nir writes: > Since the gateway acts as a pass-through, the requirement here is more > for the client, which is typically more integrated. The client should=20 > be prepared to give an identity hint both in IKE and later in the EAP=20 > session. And in that case the identities should really be same, and if they differ then the authenticated identity needs to be used for policy lookups, meaning that the EAP identity needs to be used. So the gateway needs to get that authenticated identity from the AAA server so it can do policy lookups based on it.=20 -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From smoonen@us.ibm.com Fri Nov 13 06:10:53 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8C553A6810; Fri, 13 Nov 2009 06:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqNMYfMjLRBe; Fri, 13 Nov 2009 06:10:50 -0800 (PST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id AE1E83A6844; Fri, 13 Nov 2009 06:10:46 -0800 (PST) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e36.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nADE8toj002642; Fri, 13 Nov 2009 07:08:55 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nADEAxOk147530; Fri, 13 Nov 2009 07:11:02 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nADEAtR6004070; Fri, 13 Nov 2009 07:10:55 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nADEAt1n004067; Fri, 13 Nov 2009 07:10:55 -0700 In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB3@il-ex01.ad.checkpoint.com> To: Paul Hoffman MIME-Version: 1.0 X-KeepSent: A410ADE8:D37DCBCB-8525766D:00484633; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/13/2009 09:10:38 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/13/2009 09:10:38 AM, Serialize complete at 11/13/2009 09:10:38 AM, S/MIME Sign failed at 11/13/2009 09:10:38 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 11/13/2009 07:10:55, Serialize complete at 11/13/2009 07:10:55 Message-ID: Date: Fri, 13 Nov 2009 09:10:54 -0500 Content-Type: multipart/alternative; boundary="=_alternative 004DE0E18525766D_=" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org, Yoav Nir , "Law, Laurie" Subject: Re: [IPsec] RFC4869 bis submitted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 14:10:53 -0000 This is a multipart message in MIME format. --=_alternative 004DE0E18525766D_= Content-Type: text/plain; charset="US-ASCII" > Having said that, it is perfectly natural for the submitters to > require a particular type of authentication in a suite. For this one, > it is clear that they want to use EC throughout the suite for > asymmetric operations. For a different one, the organization > specifying the suite might allow RSA but require a particular key size > to match the strength desired. > . . . > How is the signing algorithm of the certificates used *not* part of > the algorithm configuration? I agree that is a natural goal for an organization's policy. But we can still discuss whether it is appropriate for the goal to be enforced in a suite. For example, it's a reasonable goal to require that "ICMP redirects are not permitted through this SA", but it's unnatural to enforce that requirement in a suite. I think the ECDSA requirement is another case where it is more appropriate to address the policy requirement elsewhere -- through an organization's PKI infrastructure and administration rather than through the IKE configuration. Often the IKE administration and PKI administration are separate roles, and the IKE administrator uses whatever certificates the PKI folks provide. IKE already configures the certificate to be used; RFC 4869 and this draft essentially require IKE to configure right alongside that the assertion to "fail this operation if this certificate (which my PKI administrator has already deemed acceptable) is not ECDSA-256 or ECDSA-384". It does provide another level of assurance that ECDSA was used, but is it IKE's job to second-guess the PKI administrator? Furthermore, the requirement as stated isn't well-defined: 1) Does this require that IKE check its local certificate for use of ECDSA? 2) Does this require that IKE check the remote certificate for use of ECDSA? 3) Does this require that IKE check the trust chain for use of ECDSA? So far we've interpreted RFC 4869 as requiring only #1 (you're responsible to ensure your own certificate is ECDSA-nnn) but not #2 and #3. I would still much prefer to see the ECDSA requirement dropped from the draft, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Paul Hoffman To: Yoav Nir , "Law, Laurie" , "ipsec@ietf.org" Date: 11/12/2009 07:59 PM Subject: Re: [IPsec] RFC4869 bis submitted At 10:07 PM +0200 11/11/09, Yoav Nir wrote: >If you're bissing this thing, can we please please please entirely get rid of the requirement to use ECDSA certificates? There is no "we" here. It is not a WG item, it is an individual submission that the authors chose to alert the WG about. Having said that, it is perfectly natural for the submitters to require a particular type of authentication in a suite. For this one, it is clear that they want to use EC throughout the suite for asymmetric operations. For a different one, the organization specifying the suite might allow RSA but require a particular key size to match the strength desired. >While the algorithms and DH groups are subject to configuration in the UI and negotiation in IKE, the algorithm used to sign the certificates is outside the IKE implementation. That is not at all true. The IKE implementation must be able to both sign and verify using the keys in the certificates, so the algorithm is quite inside the IKE implementation. > You usually have a certificate that you need to use, and it's the CA's decision whether this is signed with RSA, DSA or ECDSA. There's even some ambiguity, because it's not necessarily true, that the public key in the certificate is for the same algorithms used to sign the certificate. The draft says: The authentication method for systems that use IKEv2 MUST be either ECDSA-256 or ECDSA-384 [RFC4754]. How would you reword that to say that both the keys in the certificates and the keys that signed them must be either ECDSA-256 or ECDSA-384? >The UI suites RFC that defined VPN-A and VPN-B did not mandate RSA or DSA. Correct. >I don't see why 4869 or 4869-bis should. Because that is what the creators of the profile want. The whole purpose of profiles is to allow the creators to be able to state all of the relevant crypto policy. >I don't think it's part of the algorithm configuration. How is the signing algorithm of the certificates used *not* part of the algorithm configuration? --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 004DE0E18525766D_= Content-Type: text/html; charset="US-ASCII"
> Having said that, it is perfectly natural for the submitters to
> require a particular type of authentication in a suite. For this one,
> it is clear that they want to use EC throughout the suite for
> asymmetric operations. For a different one, the organization
> specifying the suite might allow RSA but require a particular key size
> to match the strength desired.
> . . .
> How is the signing algorithm of the certificates used *not* part of
> the algorithm configuration?

I agree that is a natural goal for an organization's policy.  But we can still discuss whether it is appropriate for the goal to be enforced in a suite.  For example, it's a reasonable goal to require that "ICMP redirects are not permitted through this SA", but it's unnatural to enforce that requirement in a suite.

I think the ECDSA requirement is another case where it is more appropriate to address the policy requirement elsewhere -- through an organization's PKI infrastructure and administration rather than through the IKE configuration.  Often the IKE administration and PKI administration are separate roles, and the IKE administrator uses whatever certificates the PKI folks provide.  IKE already configures the certificate to be used; RFC 4869 and this draft essentially require IKE to configure right alongside that the assertion to "fail this operation if this certificate (which my PKI administrator has already deemed acceptable) is not ECDSA-256 or ECDSA-384".  It does provide another level of assurance that ECDSA was used, but is it IKE's job to second-guess the PKI administrator?

Furthermore, the requirement as stated isn't well-defined:

1) Does this require that IKE check its local certificate for use of ECDSA?
2) Does this require that IKE check the remote certificate for use of ECDSA?
3) Does this require that IKE check the trust chain for use of ECDSA?

So far we've interpreted RFC 4869 as requiring only #1 (you're responsible to ensure your own certificate is ECDSA-nnn) but not #2 and #3.

I would still much prefer to see the ECDSA requirement dropped from the draft,


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Yoav Nir <ynir@checkpoint.com>, "Law, Laurie" <lelaw@tycho.ncsc.mil>, "ipsec@ietf.org" <ipsec@ietf.org>
Date: 11/12/2009 07:59 PM
Subject: Re: [IPsec] RFC4869 bis submitted




At 10:07 PM +0200 11/11/09, Yoav Nir wrote:
>If you're bissing this thing, can we please please please entirely get rid of the requirement to use ECDSA certificates?

There is no "we" here. It is not a WG item, it is an individual submission that the authors chose to alert the WG about.

Having said that, it is perfectly natural for the submitters to require a particular type of authentication in a suite. For this one, it is clear that they want to use EC throughout the suite for asymmetric operations. For a different one, the organization specifying the suite might allow RSA but require a particular key size to match the strength desired.

>While the algorithms and DH groups are subject to configuration in the UI and negotiation in IKE, the algorithm used to sign the certificates is outside the IKE implementation.

That is not at all true. The IKE implementation must be able to both sign and verify using the keys in the certificates, so the algorithm is quite inside the IKE implementation.

> You usually have a certificate that you need to use, and it's the CA's decision whether this is signed with RSA, DSA or ECDSA. There's even some ambiguity, because it's not necessarily true, that the public key in the certificate is for the same algorithms used to sign the certificate.

The draft says:
 The authentication method for systems that use IKEv2 MUST be either
 ECDSA-256 or ECDSA-384 [RFC4754].
How would you reword that to say that both the keys in the certificates and the keys that signed them must be either ECDSA-256 or ECDSA-384?

>The UI suites RFC that defined VPN-A and VPN-B did not mandate RSA or DSA.

Correct.

>I don't see why 4869 or 4869-bis should.

Because that is what the creators of the profile want. The whole purpose of profiles is to allow the creators to be able to state all of the relevant crypto policy.

>I don't think it's part of the algorithm configuration.

How is the signing algorithm of the certificates used *not* part of the algorithm configuration?

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 004DE0E18525766D_=-- From smb@cs.columbia.edu Fri Nov 13 09:46:40 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BD453A67B4 for ; Fri, 13 Nov 2009 09:46:40 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ub0KMfcHA6MR for ; Fri, 13 Nov 2009 09:46:39 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 0EEAE3A672E for ; Fri, 13 Nov 2009 09:46:38 -0800 (PST) Received: from [172.20.33.20] ([208.51.118.2]) (user=smb2132 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nADHl3iE024025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Nov 2009 12:47:04 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: Date: Fri, 13 Nov 2009 12:47:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.com> <7C362EEF9C7896468B36C9B79200D8350AB2C85E06@INBANSXCHMBSA1.in.alcatel-luce nt.com> <7C362EEF9C7896468B36C9B79200D8350AB2C85E59@INBANSXCHMBSA1.in.alcatel-luce nt.com> To: Stephen Kent X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 17:46:40 -0000 On Nov 13, 2009, at 12:16 AM, Stephen Kent wrote: > My message pointed out that there was no mention of options, Your = reply picked a couple of option examples and argued that they were = either not used or did not pose a security problem. >=20 > The right way to generate a god answer is to construct a table of all = the options, and provide a rationale for why each one is not covered, = deprecated, or not secruity relevant. Divine guidance is, I suppose, one way to do protocol design, but it = could lead to *real* religious wars.... >=20 > Also, note that IPSO and CIPSO are examples of options that were = discussed at the IPSECME meeting this week, where there is a need to = bind the options to the payload. I observed that using tunnel mode = (ESP) addresses this concern, but one could also note that using AH = would do the same, with lower per-packet bandwidth overhead. Or put the labels in the SA, since especially for IPSO you probably want = cryptographic separation of different security levels. I did go through the analysis you suggest for IPv4 and concluded that = nothing was both protectable and useful. I also noted the following = issue: Furthermore, the AH spec says that we can't enumerate the v4 options, and hence whether or not they should be included or not -- but RFC1122 says that unknown IP options MUST be silently ignored. So an implementation can receive an option that it doesn't recognize, doesn't know if it changes en route, must be ignored anyway -- but may or may not be = included in the AH calculation, and the receiver doesn't know. Note, of course, that that was from 1995; I have not repeated the = analysis for newer AH or IPv6 specs. --Steve Bellovin, http://www.cs.columbia.edu/~smb From smoonen@us.ibm.com Fri Nov 13 12:44:48 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFD503A680A; Fri, 13 Nov 2009 12:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wU1ojNaNeJpX; Fri, 13 Nov 2009 12:44:47 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id DAAAA3A67AC; Fri, 13 Nov 2009 12:44:46 -0800 (PST) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e31.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nADKcF6C004711; Fri, 13 Nov 2009 13:38:15 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nADKj5fm068792; Fri, 13 Nov 2009 13:45:07 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nADDdh8r011169; Fri, 13 Nov 2009 06:39:43 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nADDdh1q011121; Fri, 13 Nov 2009 06:39:43 -0700 In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB3@il-ex01.ad.checkpoint.com> To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: A602726A:95E26416-8525766D:0070F5BA; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/13/2009 03:44:44 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/13/2009 03:44:44 PM, Serialize complete at 11/13/2009 03:44:44 PM, S/MIME Sign failed at 11/13/2009 03:44:44 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 11/13/2009 13:45:04, Serialize complete at 11/13/2009 13:45:04 Message-ID: Date: Fri, 13 Nov 2009 15:45:03 -0500 Content-Type: multipart/alternative; boundary="=_alternative 0071F5AC8525766D_=" Cc: ipsec-bounces@ietf.org, Yoav Nir , "Law, Laurie" , Paul Hoffman Subject: Re: [IPsec] RFC4869 bis submitted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 20:44:48 -0000 This is a multipart message in MIME format. --=_alternative 0071F5AC8525766D_= Content-Type: text/plain; charset="US-ASCII" Also, it occurs to me that the purpose of a suite isn't to enforce this kind of policy decision, just to give them names for interoperability purposes. E.g., the existence of SuiteB-XYZ doesn't prevent you from negotiating DES under the table somewhere; it just prevents you from negotiating DES and calling it SuiteB-XYZ. That doesn't in itself imply that ECDSA doesn't belong in the suite. But since the goal is interoperability, maybe there are alternative ways of achieving interoperability. For example, one could simply state this: "An implementation MUST NOT indicate support for SuiteB-XYZ for IKEv2 unless it supports authentication using ECDSA-256 and ECDSA-384 digital signatures. An implementation MUST NOT indicate support for SuiteB-XYZ for IKEv1 unless it supports either pre-shared key authentication or authentication using ECDSA-256 and ECDSA-384 digital signatures." Something like that, perhaps? That achieves the goal of guaranteeing ECDSA interoperability for SuiteB-*, but without making IKE responsible to micromanage decisions that are really within the PKI domain. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Scott C Moonen/Raleigh/IBM@IBMUS To: Paul Hoffman Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org, Yoav Nir , "Law, Laurie" Date: 11/13/2009 09:11 AM Subject: Re: [IPsec] RFC4869 bis submitted > Having said that, it is perfectly natural for the submitters to > require a particular type of authentication in a suite. For this one, > it is clear that they want to use EC throughout the suite for > asymmetric operations. For a different one, the organization > specifying the suite might allow RSA but require a particular key size > to match the strength desired. > . . . > How is the signing algorithm of the certificates used *not* part of > the algorithm configuration? I agree that is a natural goal for an organization's policy. But we can still discuss whether it is appropriate for the goal to be enforced in a suite. For example, it's a reasonable goal to require that "ICMP redirects are not permitted through this SA", but it's unnatural to enforce that requirement in a suite. I think the ECDSA requirement is another case where it is more appropriate to address the policy requirement elsewhere -- through an organization's PKI infrastructure and administration rather than through the IKE configuration. Often the IKE administration and PKI administration are separate roles, and the IKE administrator uses whatever certificates the PKI folks provide. IKE already configures the certificate to be used; RFC 4869 and this draft essentially require IKE to configure right alongside that the assertion to "fail this operation if this certificate (which my PKI administrator has already deemed acceptable) is not ECDSA-256 or ECDSA-384". It does provide another level of assurance that ECDSA was used, but is it IKE's job to second-guess the PKI administrator? Furthermore, the requirement as stated isn't well-defined: 1) Does this require that IKE check its local certificate for use of ECDSA? 2) Does this require that IKE check the remote certificate for use of ECDSA? 3) Does this require that IKE check the trust chain for use of ECDSA? So far we've interpreted RFC 4869 as requiring only #1 (you're responsible to ensure your own certificate is ECDSA-nnn) but not #2 and #3. I would still much prefer to see the ECDSA requirement dropped from the draft, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Paul Hoffman To: Yoav Nir , "Law, Laurie" , "ipsec@ietf.org" Date: 11/12/2009 07:59 PM Subject: Re: [IPsec] RFC4869 bis submitted At 10:07 PM +0200 11/11/09, Yoav Nir wrote: >If you're bissing this thing, can we please please please entirely get rid of the requirement to use ECDSA certificates? There is no "we" here. It is not a WG item, it is an individual submission that the authors chose to alert the WG about. Having said that, it is perfectly natural for the submitters to require a particular type of authentication in a suite. For this one, it is clear that they want to use EC throughout the suite for asymmetric operations. For a different one, the organization specifying the suite might allow RSA but require a particular key size to match the strength desired. >While the algorithms and DH groups are subject to configuration in the UI and negotiation in IKE, the algorithm used to sign the certificates is outside the IKE implementation. That is not at all true. The IKE implementation must be able to both sign and verify using the keys in the certificates, so the algorithm is quite inside the IKE implementation. > You usually have a certificate that you need to use, and it's the CA's decision whether this is signed with RSA, DSA or ECDSA. There's even some ambiguity, because it's not necessarily true, that the public key in the certificate is for the same algorithms used to sign the certificate. The draft says: The authentication method for systems that use IKEv2 MUST be either ECDSA-256 or ECDSA-384 [RFC4754]. How would you reword that to say that both the keys in the certificates and the keys that signed them must be either ECDSA-256 or ECDSA-384? >The UI suites RFC that defined VPN-A and VPN-B did not mandate RSA or DSA. Correct. >I don't see why 4869 or 4869-bis should. Because that is what the creators of the profile want. The whole purpose of profiles is to allow the creators to be able to state all of the relevant crypto policy. >I don't think it's part of the algorithm configuration. How is the signing algorithm of the certificates used *not* part of the algorithm configuration? --Paul Hoffman, Director --VPN Consortium _______________________________________________ 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 --=_alternative 0071F5AC8525766D_= Content-Type: text/html; charset="US-ASCII"
Also, it occurs to me that the purpose of a suite isn't to enforce this kind of policy decision, just to give them names for interoperability purposes.

E.g., the existence of SuiteB-XYZ doesn't prevent you from negotiating DES under the table somewhere; it just prevents you from negotiating DES and calling it SuiteB-XYZ.

That doesn't in itself imply that ECDSA doesn't belong in the suite.  But since the goal is interoperability, maybe there are alternative ways of achieving interoperability.  For example, one could simply state this:

"An implementation MUST NOT indicate support for SuiteB-XYZ for IKEv2 unless it supports authentication using ECDSA-256 and ECDSA-384 digital signatures.  An implementation MUST NOT indicate support for SuiteB-XYZ for IKEv1 unless it supports either pre-shared key authentication or authentication using ECDSA-256 and ECDSA-384 digital signatures."

Something like that, perhaps?  That achieves the goal of guaranteeing ECDSA interoperability for SuiteB-*, but without making IKE responsible to micromanage decisions that are really within the PKI domain.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Scott C Moonen/Raleigh/IBM@IBMUS
To: Paul Hoffman <paul.hoffman@vpnc.org>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, ipsec-bounces@ietf.org, Yoav Nir <ynir@checkpoint.com>, "Law, Laurie" <lelaw@tycho.ncsc.mil>
Date: 11/13/2009 09:11 AM
Subject: Re: [IPsec] RFC4869 bis submitted





> Having said that, it is perfectly natural for the submitters to
> require a particular type of authentication in a suite. For this one,
> it is clear that they want to use EC throughout the suite for
> asymmetric operations. For a different one, the organization
> specifying the suite might allow RSA but require a particular key size
> to match the strength desired.
> . . .
> How is the signing algorithm of the certificates used *not* part of
> the algorithm configuration?

I agree that is a natural goal for an organization's policy.  But we can still discuss whether it is appropriate for the goal to be enforced in a suite.  For example, it's a reasonable goal to require that "ICMP redirects are not permitted through this SA", but it's unnatural to enforce that requirement in a suite.

I think the ECDSA requirement is another case where it is more appropriate to address the policy requirement elsewhere -- through an organization's PKI infrastructure and administration rather than through the IKE configuration.  Often the IKE administration and PKI administration are separate roles, and the IKE administrator uses whatever certificates the PKI folks provide.  IKE already configures the certificate to be used; RFC 4869 and this draft essentially require IKE to configure right alongside that the assertion to "fail this operation if this certificate (which my PKI administrator has already deemed acceptable) is not ECDSA-256 or ECDSA-384".  It does provide another level of assurance that ECDSA was used, but is it IKE's job to second-guess the PKI administrator?

Furthermore, the requirement as stated isn't well-defined:

1) Does this require that IKE check its local certificate for use of ECDSA?
2) Does this require that IKE check the remote certificate for use of ECDSA?
3) Does this require that IKE check the trust chain for use of ECDSA?

So far we've interpreted RFC 4869 as requiring only #1 (you're responsible to ensure your own certificate is ECDSA-nnn) but not #2 and #3.

I would still much prefer to see the ECDSA requirement dropped from the draft,


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Yoav Nir <ynir@checkpoint.com>, "Law, Laurie" <lelaw@tycho.ncsc.mil>, "ipsec@ietf.org" <ipsec@ietf.org>
Date: 11/12/2009 07:59 PM
Subject: Re: [IPsec] RFC4869 bis submitted



At 10:07 PM +0200 11/11/09, Yoav Nir wrote:
>If you're bissing this thing, can we please please please entirely get rid of the requirement to use ECDSA certificates?

There is no "we" here. It is not a WG item, it is an individual submission that the authors chose to alert the WG about.

Having said that, it is perfectly natural for the submitters to require a particular type of authentication in a suite. For this one, it is clear that they want to use EC throughout the suite for asymmetric operations. For a different one, the organization specifying the suite might allow RSA but require a particular key size to match the strength desired.

>While the algorithms and DH groups are subject to configuration in the UI and negotiation in IKE, the algorithm used to sign the certificates is outside the IKE implementation.

That is not at all true. The IKE implementation must be able to both sign and verify using the keys in the certificates, so the algorithm is quite inside the IKE implementation.

> You usually have a certificate that you need to use, and it's the CA's decision whether this is signed with RSA, DSA or ECDSA. There's even some ambiguity, because it's not necessarily true, that the public key in the certificate is for the same algorithms used to sign the certificate.

The draft says:
The authentication method for systems that use IKEv2 MUST be either
ECDSA-256 or ECDSA-384 [RFC4754].
How would you reword that to say that both the keys in the certificates and the keys that signed them must be either ECDSA-256 or ECDSA-384?

>The UI suites RFC that defined VPN-A and VPN-B did not mandate RSA or DSA.

Correct.

>I don't see why 4869 or 4869-bis should.

Because that is what the creators of the profile want. The whole purpose of profiles is to allow the creators to be able to state all of the relevant crypto policy.

>I don't think it's part of the algorithm configuration.

How is the signing algorithm of the certificates used *not* part of the algorithm configuration?

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
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

--=_alternative 0071F5AC8525766D_=-- From ynir@checkpoint.com Fri Nov 13 13:35:59 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084863A6830 for ; Fri, 13 Nov 2009 13:35:59 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faMOmIf5sH6H for ; Fri, 13 Nov 2009 13:35:58 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 875FD3A67E7 for ; Fri, 13 Nov 2009 13:35:57 -0800 (PST) X-CheckPoint: {4AFDCE1C-5-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 973DF29C005; Fri, 13 Nov 2009 23:36:25 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7641A29C002; Fri, 13 Nov 2009 23:36:25 +0200 (IST) X-CheckPoint: {4AFDCE1C-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nADLaOc6012159; Fri, 13 Nov 2009 23:36:25 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 13 Nov 2009 23:36:30 +0200 From: Yoav Nir To: Paul Hoffman , "Law, Laurie" , "ipsec@ietf.org" Date: Fri, 13 Nov 2009 23:36:29 +0200 Thread-Topic: [IPsec] RFC4869 bis submitted Thread-Index: Acpj/H/a53jsEq2/QJqSc2E+uHr38gAq/64F Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A4EC023@il-ex01.ad.checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133FB36A4EBFB3@il-ex01.ad.checkpoint.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] RFC4869 bis submitted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 21:35:59 -0000 I strongly disagree with this. UI suites are not "profiles". To quote from= RFC 4308: This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKEv1 or with IKEv2. Since we want them to be in the UI, we can't have 50 different ones, so thi= s registry cannot accommodate a profile for every government, institution a= nd military in the world. We want to have few of them (I'd say no more than= 8) that are relevant at any given point. This is why I was against definin= g a "VPN-C" a few years ago, that would have been AES-CBC with HMAC-SHA1, a= nd DH group 14.=20 So while I'd like to have a "new algorithm" suite in my UI, that would use = AES-GCM, SHA-256/384 and the ECDH groups, it doesn't make sense to add a re= quirement for ECDSA certs to that list. Definitely not when they're in the= same "list" as VPN-A and VPN-B. =20 ________________________________________ From: Paul Hoffman [paul.hoffman@vpnc.org] Sent: Friday, November 13, 2009 02:58 To: Yoav Nir; Law, Laurie; ipsec@ietf.org Subject: Re: [IPsec] RFC4869 bis submitted At 10:07 PM +0200 11/11/09, Yoav Nir wrote: >If you're bissing this thing, can we please please please entirely get rid= of the requirement to use ECDSA certificates? There is no "we" here. It is not a WG item, it is an individual submission = that the authors chose to alert the WG about. Having said that, it is perfectly natural for the submitters to require a p= articular type of authentication in a suite. For this one, it is clear that= they want to use EC throughout the suite for asymmetric operations. For a = different one, the organization specifying the suite might allow RSA but re= quire a particular key size to match the strength desired. >While the algorithms and DH groups are subject to configuration in the UI = and negotiation in IKE, the algorithm used to sign the certificates is outs= ide the IKE implementation. That is not at all true. The IKE implementation must be able to both sign a= nd verify using the keys in the certificates, so the algorithm is quite ins= ide the IKE implementation. > You usually have a certificate that you need to use, and it's the CA's de= cision whether this is signed with RSA, DSA or ECDSA. There's even some amb= iguity, because it's not necessarily true, that the public key in the certi= ficate is for the same algorithms used to sign the certificate. The draft says: The authentication method for systems that use IKEv2 MUST be either ECDSA-256 or ECDSA-384 [RFC4754]. How would you reword that to say that both the keys in the certificates and= the keys that signed them must be either ECDSA-256 or ECDSA-384? >The UI suites RFC that defined VPN-A and VPN-B did not mandate RSA or DSA. Correct. >I don't see why 4869 or 4869-bis should. Because that is what the creators of the profile want. The whole purpose of= profiles is to allow the creators to be able to state all of the relevant = crypto policy. >I don't think it's part of the algorithm configuration. How is the signing algorithm of the certificates used *not* part of the alg= orithm configuration? --Paul Hoffman, Director --VPN Consortium From B22237@freescale.com Fri Nov 13 01:10:30 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A31C3A67C1 for ; Fri, 13 Nov 2009 01:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEe2+RrxjboV for ; Fri, 13 Nov 2009 01:10:29 -0800 (PST) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id 1FAC13A6859 for ; Fri, 13 Nov 2009 01:10:29 -0800 (PST) Received: from de01smr02.am.mot.com (de01smr02.freescale.net [10.208.0.151]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id nAD9AgEB009211 for ; Fri, 13 Nov 2009 02:10:48 -0700 (MST) Received: from zin33exm29.fsl.freescale.net (zin33exm29.ap.freescale.net [10.232.192.28]) by de01smr02.am.mot.com (8.13.1/8.13.0) with ESMTP id nAD9EkFe020226 for ; Fri, 13 Nov 2009 03:14:48 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Nov 2009 14:40:42 +0530 Message-ID: <2E13B90533934A499FD727F9B353613C5156CB@zin33exm29.fsl.freescale.net> In-Reply-To: <1CFAB1B15A6C1142BD1FC07D1CA82AB2016E687F@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Thread-Index: AcpjJy+IbwOddBiQS5iIcvnXvUEoawAElh4gAAlcq7AADktBsAAlbamgAASMWYA= References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com><4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com><3A8C969225424C4D8E6BEE65ED8552DA4C446E@XMB-BGL-41C.cisco.com><39008D85-3D9B-4B8B-A9FA-C4C91658630E@checkpoint.com><3A8C969225424C4D8E6BEE65ED8552DA4C4472@XMB-BGL-41C.cisco.com><4A5E60B4-E903-441F-A839-09FE9198B468@checkpoint.com> <19195.18766.767555.230392@fireball.kivinen.iki.fi> <2E13B90533934A499FD727F9B353613C5155A7@zin33exm29.fsl.freescale.net> <1CFAB1B15A6C1142BD1FC07D1CA82AB2016E66F5@XMB-BGL-417.cisco.com> <2E13B90533934A499FD727F9B353613C51563E@zin33exm29.fsl.freescale.net> <1CFAB1B15A6C1142BD1FC07D1CA82AB2016E687F@XMB-BGL-417.cisco.com> From: "Murthy N Srinivas-B22237" To: "Amjad Inamdar (amjads)" , "Tero Kivinen" , "Yoav Nir" X-Brightmail-Tracker: AAAAAQAAAWE= X-Brightmail-Tracker: AAAAAQAAAWE= X-Mailman-Approved-At: Sat, 14 Nov 2009 13:56:21 -0800 Cc: ipsec@ietf.org Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 09:10:30 -0000 Amjad, AAA Server (Radius server) is configured with 1.domain/realm part of the EAP Identity as the "user name". 2.Along with this we can configure a radius attribue with a unique identifier.This identifier is sent by AAA server to Authenticator along with Authention success packet. 3.This identifier is known to the Authenticator which controls policies.Multiple users can be configured at AAA server with the same identifier. 4.This way,Authenticator is not required to know the EAP-identity. Thanks -nsmurthy =20 -----Original Message----- From: Amjad Inamdar (amjads) [mailto:amjads@cisco.com]=20 Sent: Friday, November 13, 2009 12:31 PM To: Murthy N Srinivas-B22237; Tero Kivinen; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Hi Murthy, IKEv2 gatway even when acting as a pass-through would need the authenticated EAP identity for local policy decisions. For instance, gateway can group remote users based on the authenticated EAP-id (e.g. based on the domain/realm part of the ID). Further, with PSK and PKI auth methods, it is the authenticated ID that is used for policy decisions and that should be same even with EAP auth. Thanks, -Amjad=20 -----Original Message----- From: Murthy N Srinivas-B22237 [mailto:B22237@freescale.com] Sent: Thursday, November 12, 2009 6:35 PM To: Amjad Inamdar (amjads); Tero Kivinen; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Amjad, If the Authenticator includes the AAA server implementation,it should no the EAP identity to enforce policies.If AAA server is separate,we can add an attribute to AAA server for this purpose and in which case Authenticator does not have to know the EAP identity.It will use the attribute to select the policies. Thanks -ns murthy=20 -----Original Message----- From: Amjad Inamdar (amjads) [mailto:amjads@cisco.com] Sent: Thursday, November 12, 2009 4:09 PM To: Murthy N Srinivas-B22237; Tero Kivinen; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Hi Murthy, As per the RFC, with EAP authentication, policy lookups and access control decisions should be based on EAP identity, so the gatway needs to know the EAP identity. The source of EAP identity for gateway is either IDi (when IDi is same as EAP identity) or AAA server providing authenticated EAP identity neither of which is mandated by RFC, and in case client(via IDi) and AAA server do not provide EAP identity, the only way gateway can get EAP identity is via EAP identity request to the client. ----- Ikev2-bis-05 section 2.16, last paragraph ----- When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for AAA routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method. It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder. In this case, the authenticated identity has to be sent from the AAA server to the IKEv2 responder. ---------------------------------------------------------- Thanks, -Amjad -----Original Message----- From: Murthy N Srinivas-B22237 [mailto:B22237@freescale.com] Sent: Thursday, November 12, 2009 7:30 AM To: Tero Kivinen; Yoav Nir Cc: ipsec@ietf.org; Amjad Inamdar (amjads) Subject: RE: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Policy lookups are selected by Authenticator based on Authorization information received from AAA server after successful Authentication. The AAA sever uses an attribute(radius) to send a reference to the Authorization information specific for the specific client.The Authenticator need not know the EAP identitity of the client, if it is different from IKE identity. =20 The Authenticator requires to know the EAP identity only if it implements the AAA server functionality. =20 ns murthy -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Thursday, November 12, 2009 5:01 AM To: Yoav Nir Cc: ipsec@ietf.org; Amjad Inamdar (amjads) Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication Yoav Nir writes: > Since the gateway acts as a pass-through, the requirement here is more > for the client, which is typically more integrated. The client should=20 > be prepared to give an identity hint both in IKE and later in the EAP=20 > session. And in that case the identities should really be same, and if they differ then the authenticated identity needs to be used for policy lookups, meaning that the EAP identity needs to be used. So the gateway needs to get that authenticated identity from the AAA server so it can do policy lookups based on it.=20 -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Sun Nov 15 07:46:03 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87FCF3A67AA for ; Sun, 15 Nov 2009 07:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrBuXq3UsXPG for ; Sun, 15 Nov 2009 07:46:02 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 540783A68D7 for ; Sun, 15 Nov 2009 07:46:01 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAFFkRs9014891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 17:46:27 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAFFkQfN016576; Sun, 15 Nov 2009 17:46:26 +0200 (EET) 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=unknown Content-Transfer-Encoding: quoted-printable Message-ID: <19200.8786.266973.313959@fireball.kivinen.iki.fi> Date: Sun, 15 Nov 2009 17:46:26 +0200 From: Tero Kivinen To: Jack Kohn In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 15 min Cc: ipsec@ietf.org Subject: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 15:46:03 -0000 Jack Kohn writes: > From operational perspective if we are supporting both v4 and v6 (and= we > will) then having different protocols ESP and AH is and will be a > nightmare. Common denominator is ESP-Null. However, there were issue= s with > ESP-Null as it couldnt be deep inspected which has now been solved wi= th > WESP. ESP-NULL and AH will still have different properties. AH will also protect data which is not protected by the ESP-NULL, i.e. IP-header including IP-addresses (unless ESP-NULL is used with tunnel mode).=20 > In short, the argument that "Oh, but we can inspect AH packets" is no= t > relevant anymore. I do not think it was never really relevant... AH was not used because it offers ability to inspect packets, it was used when encryption was not necessarely and where protection of the IP header was needed.=20 > Given this, should we still have AH as a MAY for IPSEC - Cant we depr= ecate > it=3F I do not see any reason why it should be deprecated. It is already MAY which means it does not need to be implemented unless your environment or use scenario needs it. I was earlier in favor of changing it to MAY, but I do not think we need to move it further than that.=20 > WESP is ESP++, and it offers everthing that ESP offers plus more. Wha= t is > our stance for ESP moving forward=3F I am very sceptical for the WESP getting lots of implementations quickly, so I do not really consider WESP as competitor for ESP. Also I do not see any reason to wasting bytes for extra WESP header for encrypted traffic, so I assume WESP will be used (if it will be used) for ESP-NULL traffic not for encrypted traffic.=20 > Also, I see that a lot of work done in other WGs is still using ESP > (primarily for data integrity). Shouldn=92t they be moving to WESP, a= s WESP > offers more flexibility=3F It will take several years before implementations start to implement WESP, and even more years before hardware chips support WESP. Most of the IPsec users are still using IKEv1, even when we published IKEv2 2005, i.e. 4 years ago. And IKEv2 draft was finished and publication was requested at end of 2003. So stable draft which could be used to implement IKEv2 was ready 6 years ago, and while there are several implementations out, people are still using IKEv1. Also before WESP can be used people would first need to move to IKEv2 anyways...=20 --=20 kivinen@iki.fi From manav.bhatia@alcatel-lucent.com Sun Nov 15 22:18:57 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 348B73A68A4 for ; Sun, 15 Nov 2009 22:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THRcsber325l for ; Sun, 15 Nov 2009 22:18:56 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by core3.amsl.com (Postfix) with ESMTP id 53D133A6870 for ; Sun, 15 Nov 2009 22:18:55 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id nAG6IruX028695; Mon, 16 Nov 2009 00:18:53 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (aprelay03.apac.alcatel-lucent.com [202.65.2.133]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id nAG6Ipur015301; Mon, 16 Nov 2009 00:18:52 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id nAG6MAB8026560; Mon, 16 Nov 2009 14:22:10 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Mon, 16 Nov 2009 11:48:50 +0530 From: "Bhatia, Manav (Manav)" To: Tero Kivinen Date: Mon, 16 Nov 2009 11:48:48 +0530 Thread-Topic: [IPsec] WESP - Roadmap Ahead Thread-Index: AcpmCtVP6qERY3p6TjuS7qvOx0SrZwAd373w Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB2C86306@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <19200.8786.266973.313959@fireball.kivinen.iki.fi> In-Reply-To: <19200.8786.266973.313959@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 172.22.12.27 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.133 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 06:18:57 -0000 =20 >=20 > It will take several years before implementations start to implement > WESP, and even more years before hardware chips support WESP. Most of > the IPsec users are still using IKEv1, even when we published IKEv2 > 2005, i.e. 4 years ago. And IKEv2 draft was finished and publication > was requested at end of 2003. >=20 > So stable draft which could be used to implement IKEv2 was ready 6 > years ago, and while there are several implementations out, people are > still using IKEv1. Also before WESP can be used people would first > need to move to IKEv2 anyways...=20 Not all applications of WESP (or AH and ESP for that matter) would require = an IKEv2 negotiation. You could use WESP as a protocol for routing protocol= authentication without an IKEv2 extension. And the reason why you might want to use WESP is to prioritize certain prot= ocol packets over the others, as is normally done for v4 control packets (e= .g. OSPFv3 HELLOs and ACKs over other OSPFv3 packets) Cheers, Manav= From kivinen@iki.fi Mon Nov 16 05:09:16 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B01BF3A6AA3 for ; Mon, 16 Nov 2009 05:09:16 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KiQn-yFE3Ja for ; Mon, 16 Nov 2009 05:09:16 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9FA083A680C for ; Mon, 16 Nov 2009 05:09:15 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAGD95iD026258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 15:09:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAGD94u5019263; Mon, 16 Nov 2009 15:09:04 +0200 (EET) 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: <19201.20208.563706.519993@fireball.kivinen.iki.fi> Date: Mon, 16 Nov 2009 15:09:04 +0200 From: Tero Kivinen To: "Bhatia, Manav (Manav)" In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350AB2C86306@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <19200.8786.266973.313959@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D8350AB2C86306@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 13:09:16 -0000 Bhatia, Manav (Manav) writes: > And the reason why you might want to use WESP is to prioritize > certain protocol packets over the others, as is normally done for v4 > control packets (e.g. OSPFv3 HELLOs and ACKs over other OSPFv3 > packets) You cannot do that, as if the packets get reordered more than what is the replay window size of the responder, then older packets will get dropped. If you want to do QoS you need to use multiple IPsec SAs each carrying only one traffic for one QoS level. See RFC4301 section 4.1. -- kivinen@iki.fi From fd@cisco.com Mon Nov 16 05:32:39 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62CEE3A6AAF for ; Mon, 16 Nov 2009 05:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFLZfIfm+zYP for ; Mon, 16 Nov 2009 05:32:38 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 087653A689E for ; Mon, 16 Nov 2009 05:32:37 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAGDP1FV023345; Mon, 16 Nov 2009 14:25:02 +0100 (CET) Received: from ams-fdetienn-8715.cisco.com (ams-fdetienn-8715.cisco.com [10.55.136.230]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nAGDP0g0019490; Mon, 16 Nov 2009 14:25:00 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Frederic Detienne In-Reply-To: <2E13B90533934A499FD727F9B353613C5156CB@zin33exm29.fsl.freescale.net> Date: Mon, 16 Nov 2009 14:24:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0B1ECA1C-056C-4F2F-9C33-BF5BA4741558@cisco.com> References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2015F102B@XMB-BGL-417.cisco.com><4C814C81-70C3-4597-B279-FED18230331C@checkpoint.com><3A8C969225424C4D8E6BEE65ED8552DA4C446E@XMB-BGL-41C.cisco.com><39008D85-3D9B-4B8B-A9FA-C4C91658630E@checkpoint.com><3A8C969225424C4D8E6BEE65ED8552DA4C4472@XMB-BGL-41C.cisco.com><4A5E60B4-E903-441F-A839-09FE9198B468@checkpoint.com> <19195.18766.767555.230392@fireball.kivinen.iki.fi> <2E13B90533934A499FD727F9B353613C5155A7@zin33exm29.fsl.freescale.net> <1CFAB1B15A6C1142BD1FC07D1CA82AB2016E66F5@XMB-BGL-417.cisco.com> <2E13B90533934A499FD727F9B353613C51563E@zin33exm29.fsl.freescale.net> <1CFAB1B15A6C1142BD1FC07D1CA82AB2016E687F@XMB-BGL-417.cisco.com> <2E13B90533934A499FD727F9B353613C5156CB@zin33exm29.fsl.freescale.net> To: Murthy N Srinivas-B22237 X-Mailer: Apple Mail (2.1077) Cc: ipsec@ietf.org, Yoav Nir , Tero Kivinen , "Amjad Inamdar \(amjads\)" Subject: Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 13:32:39 -0000 On 13 Nov 2009, at 10:10, Murthy N Srinivas-B22237 wrote: > Amjad, >=20 > AAA Server (Radius server) is configured with > 1.domain/realm part of the EAP Identity as the "user name". > 2.Along with this we can configure a radius attribue with a unique > identifier.This identifier is sent by AAA server to Authenticator = along > with Authention success packet. > 3.This identifier is known to the Authenticator which controls > policies.Multiple users can be configured at AAA server with the same > identifier. > 4.This way,Authenticator is not required to know the EAP-identity. the problem is that the RADIUS ACCESS-ACCEPT and the ID would be sent at = the end of the EAP exchange -- at this point, it is too late for some = operations. Some characteristics like for instance allowing the use of EAP for a = given identity have to be known BEFORE EAP is complete. We do not want = to waste time failing the EAP exchange if we can know from the beginning = that EAP can't be used for a given identity. An other example is if the = domain portion of an RFC822 ID should be used to pick a AAA server from = a list of possible servers. It is reasonable to recommend passing "a sensible" identity from the = beginning. thanks, fred > Thanks > -nsmurthy >=20 >=20 > -----Original Message----- > From: Amjad Inamdar (amjads) [mailto:amjads@cisco.com]=20 > Sent: Friday, November 13, 2009 12:31 PM > To: Murthy N Srinivas-B22237; Tero Kivinen; Yoav Nir > Cc: ipsec@ietf.org > Subject: RE: [IPsec] Clarification on identities involved in > IKEv2EAPauthentication >=20 > Hi Murthy, >=20 > IKEv2 gatway even when acting as a pass-through would need the > authenticated EAP identity for local policy decisions. For instance, > gateway can group remote users based on the authenticated EAP-id (e.g. > based on the domain/realm part of the ID). Further, with PSK and PKI > auth methods, it is the authenticated ID that is used for policy > decisions and that should be same even with EAP auth. >=20 > Thanks, > -Amjad=20 >=20 > -----Original Message----- > From: Murthy N Srinivas-B22237 [mailto:B22237@freescale.com] > Sent: Thursday, November 12, 2009 6:35 PM > To: Amjad Inamdar (amjads); Tero Kivinen; Yoav Nir > Cc: ipsec@ietf.org > Subject: RE: [IPsec] Clarification on identities involved in > IKEv2EAPauthentication >=20 >=20 > Amjad, >=20 > If the Authenticator includes the AAA server implementation,it should = no > the EAP identity to enforce policies.If AAA server is separate,we can > add an attribute to AAA server for this purpose and in which case > Authenticator does not have to know the EAP identity.It will use the > attribute to select the policies. >=20 > Thanks > -ns murthy=20 >=20 > -----Original Message----- > From: Amjad Inamdar (amjads) [mailto:amjads@cisco.com] > Sent: Thursday, November 12, 2009 4:09 PM > To: Murthy N Srinivas-B22237; Tero Kivinen; Yoav Nir > Cc: ipsec@ietf.org > Subject: RE: [IPsec] Clarification on identities involved in > IKEv2EAPauthentication >=20 > Hi Murthy, >=20 > As per the RFC, with EAP authentication, policy lookups and access > control decisions should be based on EAP identity, so the gatway needs > to know the EAP identity. >=20 > The source of EAP identity for gateway is either IDi (when IDi is same > as EAP identity) or AAA server providing authenticated EAP identity > neither of which is mandated by RFC, and in case client(via IDi) and = AAA > server do not provide EAP identity, the only way gateway can get EAP > identity is via EAP identity request to the client. >=20 > ----- Ikev2-bis-05 section 2.16, last paragraph ----- > When the initiator authentication uses EAP, it is possible that the > contents of the IDi payload is used only for AAA routing purposes = and > selecting which EAP method to use. This value may be different from > the identity authenticated by the EAP method. It is important that > policy lookups and access control decisions use the actual > authenticated identity. Often the EAP server is implemented in a > separate AAA server that communicates with the IKEv2 responder. In > this case, the authenticated identity has to be sent from the AAA > server to the IKEv2 responder. > ---------------------------------------------------------- >=20 > Thanks, > -Amjad >=20 >=20 >=20 > -----Original Message----- > From: Murthy N Srinivas-B22237 [mailto:B22237@freescale.com] > Sent: Thursday, November 12, 2009 7:30 AM > To: Tero Kivinen; Yoav Nir > Cc: ipsec@ietf.org; Amjad Inamdar (amjads) > Subject: RE: [IPsec] Clarification on identities involved in > IKEv2EAPauthentication >=20 >=20 > Policy lookups are selected by Authenticator based on Authorization > information received from AAA server after successful Authentication. > The AAA sever uses an attribute(radius) to send a reference to the > Authorization information specific for the specific client.The > Authenticator need not know the EAP identitity of the client, if it is > different from IKE identity. =20 >=20 > The Authenticator requires to know the EAP identity only if it > implements the AAA server functionality. >=20 > ns murthy >=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Tero Kivinen > Sent: Thursday, November 12, 2009 5:01 AM > To: Yoav Nir > Cc: ipsec@ietf.org; Amjad Inamdar (amjads) > Subject: Re: [IPsec] Clarification on identities involved in > IKEv2EAPauthentication >=20 > Yoav Nir writes: >> Since the gateway acts as a pass-through, the requirement here is = more >=20 >> for the client, which is typically more integrated. The client should=20= >> be prepared to give an identity hint both in IKE and later in the EAP=20= >> session. >=20 > And in that case the identities should really be same, and if they > differ then the authenticated identity needs to be used for policy > lookups, meaning that the EAP identity needs to be used. So the = gateway > needs to get that authenticated identity from the AAA server so it can > do policy lookups based on it.=20 > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From manav.bhatia@alcatel-lucent.com Mon Nov 16 06:21:37 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C3843A6AA1 for ; Mon, 16 Nov 2009 06:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkMCs7JENLqc for ; Mon, 16 Nov 2009 06:21:32 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id 529E73A6978 for ; Mon, 16 Nov 2009 06:21:32 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id nAGELUrB021530; Mon, 16 Nov 2009 08:21:31 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (aprelay03.apac.alcatel-lucent.com [202.65.2.133]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id nAGELTWU013705; Mon, 16 Nov 2009 08:21:30 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id nAGENs8u017958; Mon, 16 Nov 2009 22:24:50 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Mon, 16 Nov 2009 19:50:33 +0530 From: "Bhatia, Manav (Manav)" To: Tero Kivinen Date: Mon, 16 Nov 2009 19:50:31 +0530 Thread-Topic: [IPsec] WESP - Roadmap Ahead Thread-Index: AcpmvgBVj9/tnnYAQkCAuP4OqweGLAACZRew Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB2C86581@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <19200.8786.266973.313959@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D8350AB2C86306@INBANSXCHMBSA1.in.alcatel-lucent.com> <19201.20208.563706.519993@fireball.kivinen.iki.fi> In-Reply-To: <19201.20208.563706.519993@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 172.22.12.28 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.133 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 14:21:37 -0000 This is an implementation specific optimization that has already been solve= d in multiple implementations. Cheers, Manav > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi]=20 > Sent: Monday, November 16, 2009 6.39 PM > To: Bhatia, Manav (Manav) > Cc: ipsec@ietf.org > Subject: RE: [IPsec] WESP - Roadmap Ahead >=20 > Bhatia, Manav (Manav) writes: > > And the reason why you might want to use WESP is to prioritize > > certain protocol packets over the others, as is normally done for v4 > > control packets (e.g. OSPFv3 HELLOs and ACKs over other OSPFv3 > > packets)=20 >=20 > You cannot do that, as if the packets get reordered more than what is > the replay window size of the responder, then older packets will get > dropped. If you want to do QoS you need to use multiple IPsec SAs each > carrying only one traffic for one QoS level. >=20 > See RFC4301 section 4.1. > --=20 > kivinen@iki.fi > = From kent@bbn.com Mon Nov 16 08:26:03 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D276428C187 for ; Mon, 16 Nov 2009 08:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d99aw1dc-M5r for ; Mon, 16 Nov 2009 08:26:03 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 1FEF928C16F for ; Mon, 16 Nov 2009 08:26:03 -0800 (PST) Received: from dhcp89-089-228.bbn.com ([128.89.89.228]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NA4Ol-0006i6-CW; Mon, 16 Nov 2009 11:25:52 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350AB2C86581@INBANSXCHMBSA1.in.alcatel-luce nt.com> References: <19200.8786.266973.313959@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D8350AB2C86306@INBANSXCHMBSA1.in.alcatel-luce nt.com> <19201.20208.563706.519993@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D8350AB2C86581@INBANSXCHMBSA1.in.alcatel-luce nt.com> Date: Mon, 16 Nov 2009 11:18:52 -0500 To: "Bhatia, Manav (Manav)" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 16:26:03 -0000 At 7:50 PM +0530 11/16/09, Bhatia, Manav (Manav) wrote: >This is an implementation specific optimization that has already >been solved in multiple implementations. > >Cheers, Manav Is the phrase "implementation specific" a euphemism for non-standard? Steve From kent@bbn.com Mon Nov 16 08:40:03 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CBC03A6AE0 for ; Mon, 16 Nov 2009 08:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ooeCx7pghhZ for ; Mon, 16 Nov 2009 08:40:02 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5626C3A6ADE for ; Mon, 16 Nov 2009 08:40:02 -0800 (PST) Received: from dhcp89-089-228.bbn.com ([128.89.89.228]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NA4cP-0007A0-Cd; Mon, 16 Nov 2009 11:39:58 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.com> <7C362EEF9C7896468B36C9B79200D8350AB2C85E06@INBANSXCHMBSA1.in.alcatel-luce nt.com> <7C362EEF9C7896468B36C9B79200D8350AB2C85E59@INBANSXCHMBSA1.in.alcatel-luce nt.com> Date: Mon, 16 Nov 2009 11:39:30 -0500 To: Steven Bellovin From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 16:40:03 -0000 >... > >Divine guidance is, I suppose, one way to do protocol design, but it >could lead to *real* religious wars.... an appropriate caution given my typo :-). > > >> Also, note that IPSO and CIPSO are examples of options that were >>discussed at the IPSECME meeting this week, where there is a need >>to bind the options to the payload. I observed that using tunnel >>mode (ESP) addresses this concern, but one could also note that >>using AH would do the same, with lower per-packet bandwidth >>overhead. > >Or put the labels in the SA, since especially for IPSO you probably >want cryptographic separation of different security levels. There are various options here. I know of devices that have opted to use ESP in tunnel mode to ensure the binding, and that is what I noted during the IPSECME WG session. I may know of an instance or two where AH has been used to do this, because if introduced less (bandwidth) overhead than tunnel mode. Implementations that make use of IPSO or CIPSO should negotiate the labels as part of the SA. The label should be part of the SPD, and be checked based on SAD entry data cached form the SPD. (Can you tell that I've been through al of this?) We had a presentation by Joy (remotely) on adding label support, as a new work item, which would explore these issues in more detail, if we choose to adopt this as a new Wg item. >I did go through the analysis you suggest for IPv4 and concluded >that nothing was both protectable and useful. I also noted the >following issue: > > Furthermore, the AH spec says that we can't > enumerate the v4 options, and hence whether or not they should > be included or not -- but RFC1122 says that unknown IP options > MUST be silently ignored. So an implementation can receive an > option that it doesn't recognize, doesn't know if it changes > en route, must be ignored anyway -- but may or may not be included > in the AH calculation, and the receiver doesn't know. > >Note, of course, that that was from 1995; I have not repeated the >analysis for newer AH or IPv6 specs. I am not suggesting that any aspect of your analysis is flawed. I am suggesting that before the WG chooses to further deprecate AH, it needs to document the analysis supporting this decision, not just cite a couple of examples and make general statements in support of such an action. Steve From danmcd@sun.com Mon Nov 16 08:53:40 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104F13A6AE2 for ; Mon, 16 Nov 2009 08:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjRqhbVKuBMq for ; Mon, 16 Nov 2009 08:53:39 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 11BD03A6AAA for ; Mon, 16 Nov 2009 08:53:39 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAGGrPDI028563; Mon, 16 Nov 2009 16:53:26 GMT Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAGGrPBs008404; Mon, 16 Nov 2009 11:53:25 -0500 (EST) Received: from kebe.East.Sun.COM (localhost [127.0.0.1]) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAGGqm2f002032; Mon, 16 Nov 2009 11:52:48 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAGGqm3A002031; Mon, 16 Nov 2009 11:52:48 -0500 (EST) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Mon, 16 Nov 2009 11:52:48 -0500 From: Dan McDonald To: Stephen Kent Message-ID: <20091116165248.GJ1232@kebe.East.Sun.COM> References: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Steven Bellovin Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 16:53:40 -0000 On Mon, Nov 16, 2009 at 11:39:30AM -0500, Stephen Kent wrote: > >Or put the labels in the SA, since especially for IPSO you probably > >want cryptographic separation of different security levels. > > There are various options here. I know of devices that have opted to > use ESP in tunnel mode to ensure the binding, and that is what I > noted during the IPSECME WG session. I may know of an instance or two > where AH has been used to do this, because if introduced less > (bandwidth) overhead than tunnel mode. Implementations that make use > of IPSO or CIPSO should negotiate the labels as part of the SA. The > label should be part of the SPD, and be checked based on SAD entry > data cached form the SPD. (Can you tell that I've been through al of > this?) We had a presentation by Joy (remotely) on adding label > support, as a new work item, which would explore these issues in more > detail, if we choose to adopt this as a new Wg item. If the WG takes on labeling, please make sure we don't concentrate on just one platform (SELinux). Besides Joy's work, there's now also SA-implicit labeling on another platform: http://hub.opensolaris.org/bin/view/Project+txipsec/ Once build 128 hits the servers, you can play with it! FYI, Dan From kohn.jack@gmail.com Mon Nov 16 16:19:18 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4C353A679C for ; Mon, 16 Nov 2009 16:19:18 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjUSbXu7SNao for ; Mon, 16 Nov 2009 16:19:18 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id F379E3A6811 for ; Mon, 16 Nov 2009 16:19:17 -0800 (PST) Received: by yxe30 with SMTP id 30so6676057yxe.29 for ; Mon, 16 Nov 2009 16:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=GGOaXglL1YlWoBsEBgXpSmEXLaK2zYBfEIU7tp+KE/A=; b=uAgN6bB1N8dwsQ5Vd+sbmdOfwGTR3VBwd9Yy0JMS5rXLjqKPEQTy2AB5x8R4Key8x0 yTJ4Kflg7B7KuHV1dQX9Q2/8McbWg/0PFcVt6riiwFFhz2YNmJs1Q2J83iowan52XvI6 y6cKHB8IXVBygR/ShFCUWsVGzgYmcX8sVez/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AC4LAJTIXFKyktckpqZ6RaizrFMqR4ozv5pWTmFY3Lds0cmuP+Mjsc7h3OiIB69bfY FZz2VeKBAR4HOKrT81n5rnwyUSkG1ZkM+v/dfi6QSZLBYupidVZJI2oa4MbpaJnZdX5j O2pvJ9zRUMhj55/WOXbq/NjsSzIwwGVysYbyM= MIME-Version: 1.0 Received: by 10.91.50.3 with SMTP id c3mr5330071agk.38.1258417153347; Mon, 16 Nov 2009 16:19:13 -0800 (PST) In-Reply-To: References: <19200.8786.266973.313959@fireball.kivinen.iki.fi> <19201.20208.563706.519993@fireball.kivinen.iki.fi> Date: Tue, 17 Nov 2009 05:49:13 +0530 Message-ID: From: Jack Kohn To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Tero Kivinen Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 00:19:18 -0000 There multiple "implementation specific" optimizations available. One such optimization that is currently in use in multiple platforms is: Do the seq number check, and then place the packets in different priority queues/paths based on the kind of packet it is. Proprietary ASICs on the routers can easily do this and its one of those things that differentiate one vendor from the other. Jack On Mon, Nov 16, 2009 at 9:48 PM, Stephen Kent wrote: > At 7:50 PM +0530 11/16/09, Bhatia, Manav (Manav) wrote: >> >> This is an implementation specific optimization that has already been >> solved in multiple implementations. >> >> Cheers, Manav > > Is the phrase "implementation specific" a euphemism for non-standard? > > Steve > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From vnktshsriram@gmail.com Mon Nov 16 20:21:22 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 139CB3A6A61 for ; Mon, 16 Nov 2009 20:21:22 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10k-FbIoIv+a for ; Mon, 16 Nov 2009 20:21:21 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 480293A6A30 for ; Mon, 16 Nov 2009 20:21:21 -0800 (PST) Received: by qyk41 with SMTP id 41so2869600qyk.29 for ; Mon, 16 Nov 2009 20:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=gaP2yhIUYzihEQn0YcrKM2Ai61Ora0xWl3CZ7uTmf+c=; b=BRbzNO4gYmnJ5nFXiwt2oamlMGVOfw5ANmfOfPxc/tJmhiXu3zyYqyv80k5//GqABX bqIb+3AF+sQ8WblQoeqnqtdHLtSyo23psA3SsASub4M0xApiOrUDtt3DhqvZ57pJK2rD H0rRCr4X+JrkkfiPs8B6eAYEWbUKHgeGFVsvU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PeOFr8LNNMwu6kuYI8I0JIGVRwpIhZX45nRMk0gRRfR2tBh6P67Zwd7RP+thb105gw d+aUipYfkL9MeIZefCIaESMRX/Ro54z3RJi5QThzjlwHlfGI3VFxHyPzS3KgjE//1N4e mfov3FC4QbqTfjz4he05ARdD+ebCT3VsFPZaE= MIME-Version: 1.0 Received: by 10.224.33.3 with SMTP id f3mr5308199qad.24.1258431677674; Mon, 16 Nov 2009 20:21:17 -0800 (PST) In-Reply-To: <19201.20208.563706.519993@fireball.kivinen.iki.fi> References: <19200.8786.266973.313959@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D8350AB2C86306@INBANSXCHMBSA1.in.alcatel-lucent.com> <19201.20208.563706.519993@fireball.kivinen.iki.fi> Date: Tue, 17 Nov 2009 09:51:17 +0530 Message-ID: From: Venkatesh Sriram To: Tero Kivinen Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 04:21:22 -0000 Tero, On Mon, Nov 16, 2009 at 6:39 PM, Tero Kivinen wrote: > Bhatia, Manav (Manav) writes: >> And the reason why you might want to use WESP is to prioritize >> certain protocol packets over the others, as is normally done for v4 >> control packets (e.g. OSPFv3 HELLOs and ACKs over other OSPFv3 >> packets) > > You cannot do that, as if the packets get reordered more than what is > the replay window size of the responder, then older packets will get > dropped. If you want to do QoS you need to use multiple IPsec SAs each > carrying only one traffic for one QoS level. Since processing of the sequence number fields is at the discretion of the receiver, it can always elect not to enable the anti-replay service for a specific SA for which it needs to prioritize certain packets. Also if the keys have been manually distributed, which would most probably happen if WESP is being used as a standalone protocol then compliant implementations SHOULD NOT provide anti-replay service. In addition to this, we are discussing a multi-sender SA in which case replay protection is anyways NOT recommended. Sriram From gregory.ietf@gmail.com Tue Nov 17 11:03:13 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609A23A69C7 for ; Tue, 17 Nov 2009 11:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ra+IZyPJIq2Y for ; Tue, 17 Nov 2009 11:03:12 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 577873A6AED for ; Tue, 17 Nov 2009 11:03:12 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so142593fga.13 for ; Tue, 17 Nov 2009 11:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=PILtq3kSqS7ZpXLbejTGFF8qZSqS+RynMRklqJ6USuc=; b=I/xm+w9e4mmJsbTqUCb2RBZc2GrInv0BoqScEHzhZ7S9M3i0eM/nPWSYFVfwnQTR6D iRf5ui5jRjQUACq9MCjfhwv3T5QJ3BjSIFV52iGONpVCFqqHbO3ZMLDTBb9F9Z9P+k8k 01L6sVbpQX0NJhnyTxBdGGmtsDziiaYmMmnm4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=u/RWqAZLoD37Ytk7m+NTb5d/jQYKbef/4yWHuOizDc/IqFabugrlnxX25HCT4Y7NtU M1KxzcMXeSyvMXqDiujm3l5xItUS4z+CYl4Dba0VvJubdh+yygZ0FLgGMiWnjCSiObst MsQnRdUtEUgSwYzcJdMPItb9AZzHKbO9ZTih4= MIME-Version: 1.0 Received: by 10.87.38.33 with SMTP id q33mr419919fgj.3.1258484584304; Tue, 17 Nov 2009 11:03:04 -0800 (PST) In-Reply-To: References: <19200.8786.266973.313959@fireball.kivinen.iki.fi> <19201.20208.563706.519993@fireball.kivinen.iki.fi> Date: Tue, 17 Nov 2009 11:03:04 -0800 Message-ID: From: Gregory Lebovitz To: Stephen Kent Content-Type: multipart/alternative; boundary=0016364593c49a4fac047895c620 Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Tero Kivinen Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 19:03:13 -0000 --0016364593c49a4fac047895c620 Content-Type: text/plain; charset=ISO-8859-1 inline... On Mon, Nov 16, 2009 at 8:18 AM, Stephen Kent wrote: > At 7:50 PM +0530 11/16/09, Bhatia, Manav (Manav) wrote: > >> This is an implementation specific optimization that has already been >> solved in multiple implementations. >> >> Cheers, Manav >> > > Is the phrase "implementation specific" a euphemism for non-standard? > GML> Or perhaps, a local security policy decision to ease up on the size of the enforcement window -- aka ease security requirements -- in order to get more QoS enforcement capability -- aka convenience -- ?? GML> Gregory > > Steve > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --0016364593c49a4fac047895c620 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable inline...

On Mon, Nov 16, 2009 at 8:18 AM= , Stephen Kent <kent@b= bn.com> wrote:
At 7:50 PM +0530 11/16/09, Bhatia, Manav (Manav) wrote:
This is an implementation specific optimization that has already been solve= d in multiple implementations.

Cheers, Manav

Is the phrase "implementation specific" a euphemism for non-stand= ard?

GML> =A0Or perhaps, a local sec= urity policy decision to ease up on the size of the enforcement window -- a= ka ease security requirements -- in order to get more QoS enforcement capab= ility -- aka convenience -- ??

GML> Gregory
=A0

Steve

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



--
----
IET= F related email from
Gregory M. Lebovitz
Juniper Networks
--0016364593c49a4fac047895c620-- From gregory.ietf@gmail.com Tue Nov 17 11:19:46 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DF383A69EC for ; Tue, 17 Nov 2009 11:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKDmP86v7LTU for ; Tue, 17 Nov 2009 11:19:45 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id BCAB43A6939 for ; Tue, 17 Nov 2009 11:19:44 -0800 (PST) Received: by fxm7 with SMTP id 7so347634fxm.29 for ; Tue, 17 Nov 2009 11:19:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=EEc5fZb4yOfzen4yeagT72obHdh178GEuQx7irMEnw0=; b=ek7qFTQ/bnVong8EbKFMYZ34hfJ4MmqCucfw+v8rEwyq9yykvcDyNijlAEkwkwolbG B68d1mi63kzkTa9WscieRyZEExkt6WMBbL3WM3Fi3zDmX7Gpia42PM7ihMp4i+2o7CJz wEx3Vh0+sdPuJ76o3JEx5W9k+ommjVwVC5/1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=updsNt9n5TyP6lfhbrwPVW8EAP2Eg1UXMYouRH50JSy5fklOgHzuY7LiaAj6IQytMa 64kUepTVxg4wOQm1uk68G/p+QebuOcUH7cgCeJ/7Y73pHBTshe/kh//7amDZksVodZmo 5IHJOTQB2fvfnYuXRMRJ2lQU7WSh2eyU+AqS4= MIME-Version: 1.0 Received: by 10.86.204.9 with SMTP id b9mr433001fgg.7.1258485576090; Tue, 17 Nov 2009 11:19:36 -0800 (PST) In-Reply-To: References: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.com> Date: Tue, 17 Nov 2009 11:19:36 -0800 Message-ID: From: Gregory Lebovitz To: Jack Kohn Content-Type: multipart/alternative; boundary=001485ea7db1b7c6f40478960193 Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Stephen Kent , Steven Bellovin Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 19:19:46 -0000 --001485ea7db1b7c6f40478960193 Content-Type: text/plain; charset=ISO-8859-1 inline... On Mon, Nov 16, 2009 at 8:39 AM, Stephen Kent wrote: --snip-- > I am not suggesting that any aspect of your analysis is flawed. I am > suggesting that before the WG chooses to further deprecate AH, it needs to > document the analysis supporting this decision, not just cite a couple of > examples and make general statements in support of such an action. > WESP implementations need to occur, be deployed, and have some time in operational networks. It would benefit the standards process to get some feedback from the operational community once this has happened. Whether or not we call it "experimental", we need to try out the WESP mechanism, in parallel with the heuristics method, in the wild and see what comes of them. We need not be shy about WESP's existence and benefits. I agree we ought to go on a bit of an intra-IETF "road show" and get the word to other Areas and WG's about WESP as compared to AH, and see what feedback we get. This can only help the standards process. In this context, Steve's suggestion for a an analysis document would be very helpful. Much of the arguments made in this thread would be excellently housed in said document. After some time in the wild, If we observe signs that WESP is operationally replacing AH, then we could seriously discuss deprecating AH. HTH, Gregory. > > Steve > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --001485ea7db1b7c6f40478960193 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable inline...

On Mon, Nov 16, 2009 at 8:39 AM= , Stephen Kent <kent@b= bn.com> wrote:

--snip--
=A0
I am not suggesting that any aspect of your analysis is flawed. I am sugges= ting that before the WG chooses to further deprecate AH, it needs to docume= nt the analysis supporting this decision, not just cite a couple of example= s and make general statements in support of such an action.

WESP implementations need to occur, be dep= loyed, and have some time in operational networks. It would benefit the sta= ndards process to get some feedback from the operational community once thi= s has happened. Whether or not we call it "experimental", we need= to try out the WESP mechanism, in parallel with the heuristics method, in = the wild and see what comes of them.=A0

We need not be shy about WESP's existence and benef= its. I agree we ought to go on a bit of an intra-IETF "road show"= and get the word to other Areas and WG's about WESP as compared to AH,= and see what feedback we get. This can only help the standards process. In= this context, Steve's suggestion for a an analysis document would be v= ery helpful. Much of the arguments made in this thread would be excellently= housed in said document.

After some time in the wild, If we observe signs that W= ESP is operationally replacing AH, then we could seriously discuss deprecat= ing AH.

HTH,
Gregory.
=A0

Steve

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



--
----
IET= F related email from
Gregory M. Lebovitz
Juniper Networks
--001485ea7db1b7c6f40478960193-- From kohn.jack@gmail.com Tue Nov 17 16:13:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C5C13A67B3 for ; Tue, 17 Nov 2009 16:13:36 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtbNMduASRQT for ; Tue, 17 Nov 2009 16:13:34 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 8B41B3A69E3 for ; Tue, 17 Nov 2009 16:13:34 -0800 (PST) Received: by gxk28 with SMTP id 28so591179gxk.9 for ; Tue, 17 Nov 2009 16:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=i4/ypum1J/aLIdwqRvKj4gWzBXrSZjCneCkHUCJ/l9Q=; b=l7Qq82DzMwO26mDRyVSg5wcBagnNQpBT49w8qE4M7DneE+7TQfAYylc9rSIlIW6ZBY VBAchHWZEYOIqgnZ77Rq3aHWEFj8SCbDsZ0bhYEbupo7Vb9iJM3T87bpUzae7ojwj7Zq JXZpcHeFkWonodx+RIaI6y0RpoVJYd5okQaCI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nIFotYqw20BfVFzekfkRqjf3dQr06zjXhubx4HuAEVYpx+ig5qXk/72W4isK0Ncz8t tDWMu7Ze8Crzfd92F5jDpzZnrhf6D4J7k0cObS8zpAUE1Jxxjqv42I6UF3Zo72XatQPl +BMdkwR5sIF66uAcE6GL8UNm6flMyMKI641Po= MIME-Version: 1.0 Received: by 10.90.58.2 with SMTP id g2mr987847aga.73.1258503208730; Tue, 17 Nov 2009 16:13:28 -0800 (PST) In-Reply-To: References: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.com> Date: Wed, 18 Nov 2009 05:43:28 +0530 Message-ID: From: Jack Kohn To: Gregory Lebovitz Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:13:36 -0000 Gregory, Do you see how WESP can be used in KARP? Jack On Wed, Nov 18, 2009 at 12:49 AM, Gregory Lebovitz wrote: > inline... > > On Mon, Nov 16, 2009 at 8:39 AM, Stephen Kent wrote: > --snip-- > >> >> I am not suggesting that any aspect of your analysis is flawed. I am >> suggesting that before the WG chooses to further deprecate AH, it needs to >> document the analysis supporting this decision, not just cite a couple of >> examples and make general statements in support of such an action. > > WESP implementations need to occur, be deployed, and have some time in > operational networks. It would benefit the standards process to get some > feedback from the operational community once this has happened. Whether or > not we call it "experimental", we need to try out the WESP mechanism, in > parallel with the heuristics method, in the wild and see what comes of > them. > We need not be shy about WESP's existence and benefits. I agree we ought to > go on a bit of an intra-IETF "road show" and get the word to other Areas and > WG's about WESP as compared to AH, and see what feedback we get. This can > only help the standards process. In this context, Steve's suggestion for a > an analysis document would be very helpful. Much of the arguments made in > this thread would be excellently housed in said document. > After some time in the wild, If we observe signs that WESP is operationally > replacing AH, then we could seriously discuss deprecating AH. > HTH, > Gregory. > >> >> Steve >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > > > -- > ---- > IETF related email from > Gregory M. Lebovitz > Juniper Networks > From yaronf@checkpoint.com Tue Nov 17 23:30:26 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98BFC3A6B56 for ; Tue, 17 Nov 2009 23:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8b3Q8SyVc0C for ; Tue, 17 Nov 2009 23:30:21 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 5CF663A682C for ; Tue, 17 Nov 2009 23:30:21 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAI7UFGo008660 for ; Wed, 18 Nov 2009 09:30:15 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 18 Nov 2009 09:30:21 +0200 From: Yaron Sheffer To: IPsecme WG Date: Wed, 18 Nov 2009 09:30:21 +0200 Thread-Topic: Ensuring future extensibility for WESP Thread-Index: AcpoFSLc1kth/nrBQ1azCQhwolsjHA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888ABAF@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888ABAFilex01adche_" MIME-Version: 1.0 Subject: [IPsec] Ensuring future extensibility for WESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 07:30:26 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888ABAFilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The recent draft on extending WESP which was presented in Hiroshima, explai= ns why the current WESP is *not* extensible, and we would need a new versio= n number if we are to add any extensions in the future. It is up to the WG to decide whether or not we want to adopt the draft, giv= en that many people were skeptical about the specific extensions proposed. = But regardless of that, it would be a mistake to publish WESP today with no= facility for extensibility. After consulting with Pasi (the draft is at a = very late stage, having been through IESG review), I would like to make a s= imple proposal to add this extensibility, with (almost) no change to the cu= rrent draft. This will leave us with future options, at virtually no cost. = I am basically just changing the semantics of the Padding field. Specifical= ly: 1. Rename IPv6Padding to "Padding (Reserved for Future Use)", and allow it = to be any length <256, subject to the IPv4 and IPv6 alignment constraints. 2. If P=3D1 (Padding Present flag), the first octet of the Padding field wi= ll hold the padding's length. [Hardware implementations can check that it i= s 4 for IPv6, otherwise move the packet to the slow path]. All other Paddin= g octets are sent as zero, and ignored by the receiver. Note that there are barely any changes on the wire, as long as we don't hav= e extensions. In particular the length remains unchanged. Thanks, Yaron --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888ABAFilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The recent draft on extending WESP which was presented i= n Hiroshima, explai= ns why the current WESP is *not* extensible, and we would need a new version number if we are to add any extensions in the future.

 

It is up to the WG to decide whether or not we want to a= dopt the draft, given that many people were skeptical about the specific extensi= ons proposed. But regardless of that, it would be a mistake to publish WESP tod= ay with no facility for extensibility. After consulting with Pasi (the draft is at = a very late stage, having been through IESG review), I would like to make a simple proposal to add this extensibility, with (almost) no change to the current draft. This will leave us with future options, at virtually no cost= . I am basically just changing the semantics of the Padding field. Specifically= :

 

1. Rename IPv6Padding to ̶= 0;Padding (Reserved for Future Use)”, and allow it to be any length <256, su= bject to the IPv4 and IPv6 alignment constraints.

2. If P=3D1 (Padding Present f= lag), the first octet of the Padding field will hold the padding's length. [Hardw= are implementations can check that it is 4 for IPv6, otherwise move the packet = to the slow path]. All other Padding octets are sent as zero, and ignored by t= he receiver.

 

Note that there are barely any changes on the wire, as long as we don't have extensions. In particular the= length remains unchanged.

 

Thanks,

     =        Yaron

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888ABAFilex01adche_-- From hyla81420@mypacks.net Tue Nov 17 22:31:58 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90293A6B44 for ; Tue, 17 Nov 2009 22:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8l1lxQQo2Iz for ; Tue, 17 Nov 2009 22:31:57 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 632323A6A3E for ; Tue, 17 Nov 2009 22:31:49 -0800 (PST) Received: from [209.86.224.43] (helo=elwamui-norfolk.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NAe4v-00027c-OA for ipsec@ietf.org; Wed, 18 Nov 2009 01:31:45 -0500 Received: from 68.99.128.115 by webmail.earthlink.net with HTTP; Wed, 18 Nov 2009 01:31:45 -0500 Message-ID: <32855890.1258525905711.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Date: Tue, 17 Nov 2009 23:31:45 -0700 (GMT-07:00) From: hyla81420@mypacks.net To: ipsec@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: e65ff8be1ec94f802adf59f7e2246db04d2b10475b5711207ee96239bbaa95f39b706e9f58239052c965d6d45243e2d1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.43 Subject: [IPsec] How long does an IKEv1 session take to complete? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 15:08:03 -0000 Greetings. Is there any data out there that quantifies how long a typical IKEv1 session (main mode and/or aggressive mode) take to complete? Hyla From danmcd@sun.com Wed Nov 18 08:28:34 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42463A6961 for ; Wed, 18 Nov 2009 08:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St5Ar7mMRESV for ; Wed, 18 Nov 2009 08:28:34 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 2BDAB3A694F for ; Wed, 18 Nov 2009 08:28:33 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAIGSVUg013856; Wed, 18 Nov 2009 16:28:31 GMT Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAIGSVPR016492; Wed, 18 Nov 2009 11:28:31 -0500 (EST) Received: from kebe.East.Sun.COM (localhost [127.0.0.1]) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAIGRrL2002824; Wed, 18 Nov 2009 11:27:53 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAIGRoGH002823; Wed, 18 Nov 2009 11:27:50 -0500 (EST) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Wed, 18 Nov 2009 11:27:50 -0500 From: Dan McDonald To: hyla81420@mypacks.net Message-ID: <20091118162750.GB1178@kebe.East.Sun.COM> References: <32855890.1258525905711.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32855890.1258525905711.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ipsec@ietf.org Subject: Re: [IPsec] How long does an IKEv1 session take to complete? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 16:28:35 -0000 On Tue, Nov 17, 2009 at 11:31:45PM -0700, hyla81420@mypacks.net wrote: > Greetings. Is there any data out there that quantifies how long a typical > IKEv1 session (main mode and/or aggressive mode) take to complete? I don't think anyone's done a thorough survey of implementations or parameters they use. If anyone has, or knows of such a survey, they should really share with this list. A LOT depends on what you use for your Oakley Group, your authentication method (and the certificate key size in the case of certificates), and, of course, the hardware upon which you run it. There's a lot of combinations there! Dan From gregory.ietf@gmail.com Wed Nov 18 10:00:29 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B8853A6A04 for ; Wed, 18 Nov 2009 10:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TE7qAXl+I+Kv for ; Wed, 18 Nov 2009 10:00:28 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 892883A6AC6 for ; Wed, 18 Nov 2009 10:00:28 -0800 (PST) Received: by fxm7 with SMTP id 7so1500752fxm.29 for ; Wed, 18 Nov 2009 10:00:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=4CgNk4K6QCy3q5NusN7nzo3hPyjR8KaiiU2+K4MvvBY=; b=DQKliXodTPefk22hMozgf1oGF9Y+9YPKYit5AAO/mA/TOcmzyk6pkQxmlpxb1tpZt/ k4+wgbb0ZKWgXpHOX7IbqXN8R1uiyzw7RSJb7X39E0EHV1jRjSaClCHEVw0oQD8fkAn6 BIssd04bQ6fa6FQU65T6J2Q++RG+XZdQ8jiWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iWbEE0foip1corcwWe5tnhIkovyTuMSxblba6TYrO0/bba56HeqOjEr0CqMcjrwsM4 z6YZJ53Hb7hxHqwgnQJwnNYw8H/fVYlB1ENA1PCDRafr97hOkqvxNpm4FBJWelbK5i9v tWd3kRuDx6T/BxlBDKG+axk9fol2VP8dvLaNI= MIME-Version: 1.0 Received: by 10.204.155.73 with SMTP id r9mr577783bkw.14.1258567222382; Wed, 18 Nov 2009 10:00:22 -0800 (PST) In-Reply-To: <20091118162750.GB1178@kebe.East.Sun.COM> References: <32855890.1258525905711.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> <20091118162750.GB1178@kebe.East.Sun.COM> Date: Wed, 18 Nov 2009 10:00:22 -0800 Message-ID: From: Gregory Lebovitz To: Dan McDonald Content-Type: multipart/alternative; boundary=0015175cfa8e3751150478a904a7 Cc: ipsec@ietf.org Subject: Re: [IPsec] How long does an IKEv1 session take to complete? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 18:00:29 -0000 --0015175cfa8e3751150478a904a7 Content-Type: text/plain; charset=ISO-8859-1 Additionally it will depend on the round trip time across the network between the two peers. Vendors who are selling network boxes that can do a large number of simultaneous IKE negotiations tend to care more about simultaneous IKE SA negotiations per second than they do the actual negotiation time of any one single negotiation. HTH, Gregory. On Wed, Nov 18, 2009 at 8:27 AM, Dan McDonald wrote: > On Tue, Nov 17, 2009 at 11:31:45PM -0700, hyla81420@mypacks.net wrote: > > > > Greetings. Is there any data out there that quantifies how long a typical > > IKEv1 session (main mode and/or aggressive mode) take to complete? > > I don't think anyone's done a thorough survey of implementations or > parameters they use. If anyone has, or knows of such a survey, they should > really share with this list. > > A LOT depends on what you use for your Oakley Group, your authentication > method (and the certificate key size in the case of certificates), and, of > course, the hardware upon which you run it. There's a lot of combinations > there! > > Dan > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --0015175cfa8e3751150478a904a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Additionally it will depend on the round trip time across the network betwe= en the two peers.

Vendors who are selling network boxes = that can do a large number of simultaneous IKE negotiations tend to care mo= re about simultaneous IKE SA negotiations per second than they do the actua= l negotiation time of any one single negotiation.=A0

HTH,
Gregory.

On Wed, Nov 18, 2009 at 8:27 AM, Dan McDonald <danmcd@sun.com> wrote:
On Tue, Nov 17, 2009 at 11:31:45PM -0700, hyla81420@mypacks.net wrote:
<SNIP!>

> Greetings. Is there any data out there that quantifies how long a typi= cal
> IKEv1 session (main mode and/or aggressive mode) take to complete?

I don't think anyone's done a thorough survey of implementati= ons or
parameters they use. =A0If anyone has, or knows of such a survey, they shou= ld
really share with this list.

A LOT depends on what you use for your Oakley Group, your authentication method (and the certificate key size in the case of certificates), and, of<= br> course, the hardware upon which you run it. =A0There's a lot of combina= tions
there!

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



--
----
IET= F related email from
Gregory M. Lebovitz
Juniper Networks
--0015175cfa8e3751150478a904a7-- From danmcd@sun.com Wed Nov 18 10:03:05 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC4C3A6A04 for ; Wed, 18 Nov 2009 10:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMk06OoMH-uy for ; Wed, 18 Nov 2009 10:03:04 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 933883A6821 for ; Wed, 18 Nov 2009 10:03:04 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAII2xBZ027430 for ; Wed, 18 Nov 2009 18:02:59 GMT Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.4) with ESMTP id nAII2w8v021531 for ; Wed, 18 Nov 2009 13:02:58 -0500 (EST) Received: from kebe.East.Sun.COM (localhost [127.0.0.1]) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAII2L1N003588 for ; Wed, 18 Nov 2009 13:02:21 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAII2L8W003587 for ipsec@ietf.org; Wed, 18 Nov 2009 13:02:21 -0500 (EST) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Wed, 18 Nov 2009 13:02:21 -0500 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20091118180221.GF1178@kebe.East.Sun.COM> References: <32855890.1258525905711.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> <20091118162750.GB1178@kebe.East.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [IPsec] How long does an IKEv1 session take to complete? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 18:03:05 -0000 On Wed, Nov 18, 2009 at 10:00:22AM -0800, Gregory Lebovitz wrote: > Additionally it will depend on the round trip time across the network > between the two peers. Ahh, of course. > Vendors who are selling network boxes that can do a large number of > simultaneous IKE negotiations tend to care more about simultaneous IKE SA > negotiations per second than they do the actual negotiation time of any one > single negotiation. Yes, the throughput vs. latency issues. A user might care about his/her latency (0-to-IPsec times), but a server vendor (not just a VPN box, BTW -- imagine the IPsec-protected server) might care a lot more about aggregate P1s/second. Dan From ynir@checkpoint.com Wed Nov 18 21:49:20 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B63B28C12F for ; Wed, 18 Nov 2009 21:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRyYkZ+C9VXr for ; Wed, 18 Nov 2009 21:49:19 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 610F528C0E5 for ; Wed, 18 Nov 2009 21:49:19 -0800 (PST) X-CheckPoint: {4B04D8E5-5-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 0E89929C005; Thu, 19 Nov 2009 07:49:16 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id DB55729C002; Thu, 19 Nov 2009 07:49:15 +0200 (IST) X-CheckPoint: {4B04D8E5-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAJ5nFGo002370; Thu, 19 Nov 2009 07:49:15 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 19 Nov 2009 07:49:21 +0200 From: Yoav Nir To: " " Date: Thu, 19 Nov 2009 07:49:15 +0200 Thread-Topic: [IPsec] How long does an IKEv1 session take to complete? Thread-Index: Acpo3AqT4eyxBnQLQcuKXACHJUVYtw== Message-ID: References: <32855890.1258525905711.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> In-Reply-To: <32855890.1258525905711.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-21--1017801792"; protocol="application/pkcs7-signature" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] How long does an IKEv1 session take to complete? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 05:49:20 -0000 --Apple-Mail-21--1017801792 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii What Dan and Gregory said. But assuming an unloaded gateway, with "normal" hardware (Any Intel, AMD = or PowerPC processor from the last 10 years or a recent ARM), then even = if you use relatively secure parameters (2048-bit DH group, 2048-bit RSA = keys) the round trip time is going to dominate. The calculations = themselves take less than 20 milliseconds. So phase 1 should take about 3 round trips. On Nov 18, 2009, at 8:31 AM, = wrote: > Greetings. Is there any data out there that quantifies how long a = typical IKEv1 session (main mode and/or aggressive mode) take to = complete? >=20 > Hyla --Apple-Mail-21--1017801792 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEHWPmpet94anoiUADSB7pZcwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDUxOTIxMDYyOFoXDTEwMDUxOTIxMDYy OFowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN5Dac6srAGq YgV/Ggt0eXG8MRQRMR1SmIXm66utqDjcJhKDwKeyV5ICqQFr8ETbYZ7YgvSkXE7o9StCeqVvxKt0 hR5DTjho49VrCiaKex3q6d/VNh6E22yBqZBYbVa5xsxcPK6V2g/GXhyoNjoezeRVlRm0bbQtscKt GOt5BJFjjL5Ns/x0MktYgn24NIDnsTJKPEXl7vQzpwp6tnJJuiz/ttdW+7PII8vTkoHZpNGPW/aS bLR01T8ga739zosQ57YAdkih69BMHb+Q9zpRoSyd6NGEQ124TtskwWSAPAvw3TF2p0NlMKBU02Bt B07zkCodlx6sqOxeX7nVML26zI8CAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAA+x/ZiahLKaSb/kWVGx2gJAGAG5 C065lmMky3hmur1IfUa9GBXJO40Z4CdiD6Y/4wQgHkBPnRF4YdhMjd2ecE03/9+x4grNKaXaeiIl MXQtniPa1tO++O/8eaPiMx6AF+v4njB/q0CUpYF78fTloJuhflNPvdbV46Xj41fIDoFAMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB1j5qXrfeGp6IlAA0ge6WXMAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTExOTA1 NDkxNlowIwYJKoZIhvcNAQkEMRYEFKYPu+isF1qDRp3bNnL+XX5XmHPMMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdY+al633hqei JQANIHullzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQdY+al633hqeiJQANIHullzANBgkqhkiG9w0BAQEFAASCAQBLTY2amvZM Kh5fDT9L8dc8DWx239c/CmUSanG3T7/vM4dCmKVz0f7cx14VycrKWCa5T7DHJXB9+FXaRBbXD2jR Nxy0mOBdJba4c2++3dZgmN0fdYzYmsAZUWeRqeSfH69ZTH60ROEKorBzu2RbhHPx+z4Z0uqGOKf2 LY2vNzvjyq4sRdi79Z59mh/xoLkTR5SkgCsNA47HghZVLEDAS5HNv79KUhrBnH2ZTb2EXiO8QAP+ 9LpSaxcQ4SsDpGjUrYS/ncZh/rSjeau5kilA9v/dW7INNgfmtUf0c+fQh9ILYlc7fzsK1hTx40AZ lfzFJsAvhIqfNuR2v/zuX5QYrgwZAAAAAAAA --Apple-Mail-21--1017801792-- From tmo@iki.fi Thu Nov 19 00:43:59 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 362243A6AE7 for ; Thu, 19 Nov 2009 00:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.259 X-Spam-Level: * X-Spam-Status: No, score=1.259 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PROFIT1=3.858] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrFr-QrsTCMj for ; Thu, 19 Nov 2009 00:43:58 -0800 (PST) Received: from aho.jnai.com (jnai.com [212.16.111.196]) by core3.amsl.com (Postfix) with ESMTP id 602133A6858 for ; Thu, 19 Nov 2009 00:43:58 -0800 (PST) Received: from [10.9.0.226] (dhcp226.jnai.com [10.9.0.226]) by aho.jnai.com (Postfix) with ESMTP id 4BD9B78404 for ; Thu, 19 Nov 2009 10:43:49 +0200 (EET) Message-ID: <4B050533.5030102@iki.fi> Date: Thu, 19 Nov 2009 10:43:31 +0200 From: Tero Mononen User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: ipsec@ietf.org X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 19 Nov 2009 08:03:03 -0800 Subject: [IPsec] Comments on draft-ietf-ipsecme-esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 08:47:12 -0000 Tero, Dan and others, I've read your informational draft. Overall comments: The draft contains quite a lot of background information (what you are trying to achieve on technical point of view, what were the alternative solutions considered). Part of this background is also available on WESP draft. Making this draft an information disclosure on "algorithm to determine if IPsec ESP packet stream has been encrypted or not", without too much explanation or hand waving would increase its usability. The background could be find by-reference on the WESP RFC. Please consider adding definitions/glossary entries for the following concepts: flow, flow-cache. I know they are relevant on certain implementations, but not necessarily well defined on that sense, or at least introducing these terms properly before using them. About the abstract: Consider changing abstract in a way that really points out the good on this approach. Something like: -8<--- This document describes an algorithm for distinguishing IPSEC ESP- NULL packets from encrypted ESP packets. The algorithm can be used on intermediate devices, like traffic analyzers, and deep inspection engines, to quickly decide whether given packet flow is interesting or not. Use of this algorithm does not require any changes made on existing RFC4303 compliant IPSEC hosts. -8<--- About the algorithm: Pseudo-code seems sane, and was understandable after reading the specification part. However I did not try to implement it, nor really proof its correctness. P.S. Please ignore the following meaningless whining: About Security Considerations: Raises a question, why is this all needed? What is the use case? Neither this, nor WESP draft can give a simple answer for the question. If encrypted traffic is allowed to pass traffic analyzer/intrusion detector/intrusion prevention/firewall/whatever, the malicious end nodes will use encryption. If encrypted traffic is dropped by intermediate, then there is an end node policy issue. Detection whether an ESP packet payload is encrypted or not should already be fast on deep inspection packet matching hardware. -- Tero Mononen From vishwas.ietf@gmail.com Thu Nov 19 10:42:33 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E2E93A677E for ; Thu, 19 Nov 2009 10:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AkEpuHHdg6v for ; Thu, 19 Nov 2009 10:42:32 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 7F7823A6405 for ; Thu, 19 Nov 2009 10:42:32 -0800 (PST) Received: by gxk28 with SMTP id 28so2312850gxk.9 for ; Thu, 19 Nov 2009 10:42:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bJPJZpo6QaBu6vCPYABhqJQWG/4pIa/qSIF7qyvp1oI=; b=MMQaC6n+mGoOsH4WSoM2GsPpj62XWAibaJNK9PuNYzaYe/5rsTEkI5NRH8tsIz8BpR +tSQ8EmEVIQ24FiCY0r1IvdJvd6HPsZeQ5m4yICXaDQp6Hv6pc3GjLnqOPvxpKtPt0so SOSe/RbIzHcMpUyma7wAEl4LbNFwp9/6Kkn78= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VZ4B+JCNXzzJ3glyY3zwV2a+P/4f6jT0ZVAIcECsl7dA0HxAQ7j+9LkJmRLuVLTPXm hDe60PW91TiH0ycHj1gDF85wqrm1FOwRH5/wpG2IYh7Og8hJQcjK9WDSkSI8+evvkLkg jY0oW1Ow/tFx1ILLaY0ZzA4dRh2uj8Qcfnr5M= MIME-Version: 1.0 Received: by 10.150.26.42 with SMTP id 42mr675328ybz.302.1258656147177; Thu, 19 Nov 2009 10:42:27 -0800 (PST) In-Reply-To: <4B050533.5030102@iki.fi> References: <4B050533.5030102@iki.fi> Date: Thu, 19 Nov 2009 10:42:27 -0800 Message-ID: <77ead0ec0911191042o68759777o81af6bc8d7fa8a6b@mail.gmail.com> From: Vishwas Manral To: Tero Mononen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 18:42:33 -0000 Hi Tero, Let me answer the very relevant question you have raised and got no reply for yet. Let me first give you a short background. We had a similar discussion on ESP-NULL versus AH and merits of a heuristics approach in 2007 on the SAAG list. You can have a look at the discussion http://www.ietf.org/mail-archive/web/saag/current/msg01933.html and the related mails. Tero Kivinen's point at that time too was that we can do heuristics based approach. Also look at the archive http://www.ietf.org/mail-archive/web/ipsec/current/msg01902.html of the question I had raised. > =A0Raises a question, why is this all needed? What is the use case? > =A0Neither this, nor WESP draft can give a simple answer for the > =A0question. If encrypted traffic is allowed to pass traffic > =A0analyzer/intrusion detector/intrusion prevention/firewall/whatever, > =A0the malicious end nodes will use encryption. If encrypted traffic > =A0is dropped by intermediate, then there is an end node policy > =A0issue. =A0Detection whether an ESP packet payload is encrypted or > =A0not should already be fast on deep inspection packet matching > =A0hardware. Like mentioned in the mail assume an application that runs within an enterprise and uses ESP-NULL only service. We could filter out all packets for that application port at the firewall itself as we can look deeper into the packet if we had a mechanism to know if the packet is encrypted or not. So if an encrypted packet came for an SA which used ESP-NULL, it would not be processed properly and dropped like you mentioned by the application anyway. However by knowing ESP-NULL at the edge we could drop packets for applications from domains disallowed to send packet in (even though the packets are replayed packets and so will actually be treated as correct packets by the application). This is also one reason an application may use ESP-NULL, that way firewalls can do their work and the application is safe from being bombarded by packets from outside the domain. The use cases of doing the detection of ESP-NULL versus encrypted packets however are limited. Thanks, Vishwas From sommerfeld@sun.com Thu Nov 19 13:51:41 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73EA23A699E for ; Thu, 19 Nov 2009 13:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QF-W-DKafvMJ for ; Thu, 19 Nov 2009 13:51:40 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 960683A67A5 for ; Thu, 19 Nov 2009 13:51:40 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAJLpcLA027499; Thu, 19 Nov 2009 21:51:38 GMT Received: from thunk-west.local (dhcp-mpk17-108-155.SFBay.Sun.COM [129.146.108.155]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAJLpbbZ027426; Thu, 19 Nov 2009 13:51:37 -0800 (PST) Received: from thunk-west.local (thunk-west [127.0.0.1]) by thunk-west.local (8.14.3+Sun/8.14.3) with ESMTP id nAJLpbr9016076; Thu, 19 Nov 2009 13:51:37 -0800 (PST) Received: (from sommerfeld@localhost) by thunk-west.local (8.14.3+Sun/8.14.3/Submit) id nAJLpbAS016075; Thu, 19 Nov 2009 13:51:37 -0800 (PST) X-Authentication-Warning: thunk-west.local: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: "Law, Laurie" In-Reply-To: References: Content-Type: text/plain; charset="ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Nov 2009 13:51:37 -0800 Message-ID: <1258667497.15596.206.camel@thunk-west> Mime-Version: 1.0 Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC4869 bis submitted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 21:51:41 -0000 On Tue, 2009-11-10 at 17:15 -0500, Law, Laurie wrote: > This Internet-Draft makes several minor changes to the suites in RFC > 4869 and incorporates comments that have been posted to the ipsec > mailing list. On reading the spec, it's not clear to me whether an IKEv1 implementation which supports ECP-based DH (rfc4753) with preshared keys but not ECDSA (rfc4754) is considered to usefully implement this specification. As a practical matter, the ECDSA piece of this spec is likely to be the largest and last piece built -- given a working elliptic curve codebase, plugging ephemeral ECDH into an IKE implementation is a much smaller problem than building ECDSA into both an IKE implementation and the PKI client codebase, tools, and keystores it relies on. - Bill From paul.hoffman@vpnc.org Thu Nov 19 15:08:45 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 603A23A67F4 for ; Thu, 19 Nov 2009 15:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.996 X-Spam-Level: X-Spam-Status: No, score=-5.996 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAvLlurcFWrM for ; Thu, 19 Nov 2009 15:08:44 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id A58CB3A67B2 for ; Thu, 19 Nov 2009 15:08:44 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAJN8e4r042011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Nov 2009 16:08:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1258667497.15596.206.camel@thunk-west> References: <1258667497.15596.206.camel@thunk-west> Date: Thu, 19 Nov 2009 15:08:39 -0800 To: Bill Sommerfeld , "Law, Laurie" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC4869 bis submitted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 23:08:45 -0000 At 1:51 PM -0800 11/19/09, Bill Sommerfeld wrote: >On Tue, 2009-11-10 at 17:15 -0500, Law, Laurie wrote: >> This Internet-Draft makes several minor changes to the suites in RFC >> 4869 and incorporates comments that have been posted to the ipsec >> mailing list. > >On reading the spec, it's not clear to me whether an IKEv1 >implementation which supports ECP-based DH (rfc4753) with preshared keys >but not ECDSA (rfc4754) is considered to usefully implement this >specification. The text says: IKEv1 implementations MUST support pre-shared key authentication [RFC2409] for interoperability. The authentication method used with IKEv1 MUST be either pre-shared key [RFC2409] or ECDSA-256 [RFC4754]. To me, that sounds like preshared keys are just fine for IKEv1 in this profile, but I might be misunderstanding what you mean by "usefully". >As a practical matter, the ECDSA piece of this spec is likely to be the >largest and last piece built -- given a working elliptic curve codebase, >plugging ephemeral ECDH into an IKE implementation is a much smaller >problem than building ECDSA into both an IKE implementation and the PKI >client codebase, tools, and keystores it relies on. Probably true, but ECDSA is far from impossible, as the OpenSSL people have shown for a while now. --Paul Hoffman, Director --VPN Consortium From sommerfeld@sun.com Thu Nov 19 15:45:47 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8D13A698F for ; Thu, 19 Nov 2009 15:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o37zi4KIl2Cx for ; Thu, 19 Nov 2009 15:45:46 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 47C8F3A68C1 for ; Thu, 19 Nov 2009 15:45:46 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAJNjeNE012431; Thu, 19 Nov 2009 23:45:40 GMT Received: from thunk-west.local (dhcp-mpk17-108-155.SFBay.Sun.COM [129.146.108.155]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAJNjcqg027412; Thu, 19 Nov 2009 15:45:38 -0800 (PST) Received: from thunk-west.local (thunk-west [127.0.0.1]) by thunk-west.local (8.14.3+Sun/8.14.3) with ESMTP id nAJNjYr0016400; Thu, 19 Nov 2009 15:45:34 -0800 (PST) Received: (from sommerfeld@localhost) by thunk-west.local (8.14.3+Sun/8.14.3/Submit) id nAJNjYnj016399; Thu, 19 Nov 2009 15:45:34 -0800 (PST) X-Authentication-Warning: thunk-west.local: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Paul Hoffman In-Reply-To: References: <1258667497.15596.206.camel@thunk-west> Content-Type: text/plain; charset="ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Nov 2009 15:45:34 -0800 Message-ID: <1258674334.15596.312.camel@thunk-west> Mime-Version: 1.0 Cc: ipsec@ietf.org, "Law, Laurie" Subject: Re: [IPsec] RFC4869 bis submitted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 23:45:47 -0000 On Thu, 2009-11-19 at 15:08 -0800, Paul Hoffman wrote: > The text says: > IKEv1 implementations MUST > support pre-shared key authentication [RFC2409] for interoperability. > The authentication method used with IKEv1 MUST be either pre-shared > key [RFC2409] or ECDSA-256 [RFC4754]. > To me, that sounds like preshared keys are just fine for IKEv1 in this > profile, but I might be misunderstanding what you mean by "usefully". I make a distinction between "optional to use" and "optional to implement". There are many things which are optional to use but effectively mandatory to implement -- an implementation is not viewed as complete unless it allows the use of the option. As you pointed out earlier in this thread, this profile is an individual submission describing a particular organization's requirements. I'm reluctant to guess or rely on the guess of someone who isn't part of this organization when the document itself could be clarified. > >As a practical matter, the ECDSA piece of this spec is likely to be the > >largest and last piece built -- given a working elliptic curve codebase, > >plugging ephemeral ECDH into an IKE implementation is a much smaller > >problem than building ECDSA into both an IKE implementation and the PKI > >client codebase, tools, and keystores it relies on. >=20 > Probably true, but ECDSA is far from impossible, as the OpenSSL people > have shown for a while now. There is a large gap between "can deliver next week" and "impossible". (I'll also note in passing that changing which PKI client codebase you use in an IKE implementation is also a sizeable task). - Bill From paul.hoffman@vpnc.org Thu Nov 19 15:56:30 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FF7B28C0EA for ; Thu, 19 Nov 2009 15:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.003 X-Spam-Level: X-Spam-Status: No, score=-6.003 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia7jbilhxM+S for ; Thu, 19 Nov 2009 15:56:29 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id BDFDA28C0E4 for ; Thu, 19 Nov 2009 15:56:29 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAJNuPVI044086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Nov 2009 16:56:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1258674334.15596.312.camel@thunk-west> References: <1258667497.15596.206.camel@thunk-west> <1258674334.15596.312.camel@thunk-west> Date: Thu, 19 Nov 2009 15:56:24 -0800 To: Bill Sommerfeld From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ipsec@ietf.org, "Law, Laurie" Subject: Re: [IPsec] RFC4869 bis submitted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 23:56:30 -0000 At 3:45 PM -0800 11/19/09, Bill Sommerfeld wrote: >On Thu, 2009-11-19 at 15:08 -0800, Paul Hoffman wrote: >> The text says: >> IKEv1 implementations MUST >> support pre-shared key authentication [RFC2409] for interoperability. >> The authentication method used with IKEv1 MUST be either pre-shared >> key [RFC2409] or ECDSA-256 [RFC4754]. >> To me, that sounds like preshared keys are just fine for IKEv1 in this >> profile, but I might be misunderstanding what you mean by "usefully". > >I make a distinction between "optional to use" and "optional to >implement". There are many things which are optional to use but >effectively mandatory to implement -- an implementation is not viewed as >complete unless it allows the use of the option. Given that this is IKEv1, where both parties must authenticate using the same authentication mechanism, I have assumed that this text means that ECDSA is not mandatory to implement in IKEv1 for this profile. >As you pointed out earlier in this thread, this profile is an individual >submission describing a particular organization's requirements. I'm >reluctant to guess or rely on the guess of someone who isn't part of >this organization when the document itself could be clarified. Given that this is a revision to an existing RFC, the authors may not know the words that would make this clear to you. Suggested wording for them? >There is a large gap between "can deliver next week" and "impossible". RFC 4869 was published more than a week ago. :-) --Paul Hoffman, Director --VPN Consortium From manav.bhatia@alcatel-lucent.com Fri Nov 20 02:28:45 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CC3C3A690D for ; Fri, 20 Nov 2009 02:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTHbJP-AHwrN for ; Fri, 20 Nov 2009 02:28:40 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by core3.amsl.com (Postfix) with ESMTP id 1B9033A6AA7 for ; Fri, 20 Nov 2009 02:28:39 -0800 (PST) Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id nAKASX3b014432; Fri, 20 Nov 2009 04:28:33 -0600 (CST) Received: from mail.apac.alcatel-lucent.com (aprelay03.apac.alcatel-lucent.com [202.65.2.133]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id nAKASUns018899; Fri, 20 Nov 2009 04:28:31 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id nAKAWNAB012528; Fri, 20 Nov 2009 18:32:24 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 20 Nov 2009 15:58:29 +0530 From: "Bhatia, Manav (Manav)" To: Yaron Sheffer , IPsecme WG Date: Fri, 20 Nov 2009 15:58:27 +0530 Thread-Topic: Ensuring future extensibility for WESP Thread-Index: AcpoFSLc1kth/nrBQ1azCQhwolsjHABtrruQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB2F637DD@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888ABAF@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888ABAF@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350AB2F637DDINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 172.22.12.27 X-Scanned-By: MIMEDefang 2.64 on 202.65.2.133 Subject: Re: [IPsec] Ensuring future extensibility for WESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 10:28:45 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350AB2F637DDINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yaron, I am fine with these changes and i think we must have them to keep WESP ext= ensible! Thanks, Manav ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Wednesday, November 18, 2009 1.00 PM To: IPsecme WG Subject: [IPsec] Ensuring future extensibility for WESP Hi, The recent draft on extending WESP which was presented in Hiroshima, explai= ns why the current WESP is *not* extensible, and we would need a new versio= n number if we are to add any extensions in the future. It is up to the WG to decide whether or not we want to adopt the draft, giv= en that many people were skeptical about the specific extensions proposed. = But regardless of that, it would be a mistake to publish WESP today with no= facility for extensibility. After consulting with Pasi (the draft is at a = very late stage, having been through IESG review), I would like to make a s= imple proposal to add this extensibility, with (almost) no change to the cu= rrent draft. This will leave us with future options, at virtually no cost. = I am basically just changing the semantics of the Padding field. Specifical= ly: 1. Rename IPv6Padding to "Padding (Reserved for Future Use)", and allow it = to be any length <256, subject to the IPv4 and IPv6 alignment constraints. 2. If P=3D1 (Padding Present flag), the first octet of the Padding field wi= ll hold the padding's length. [Hardware implementations can check that it i= s 4 for IPv6, otherwise move the packet to the slow path]. All other Paddin= g octets are sent as zero, and ignored by the receiver. Note that there are barely any changes on the wire, as long as we don't hav= e extensions. In particular the length remains unchanged. Thanks, Yaron --_000_7C362EEF9C7896468B36C9B79200D8350AB2F637DDINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Yaron,
 
I am fine with these changes and i think we must= have=20 them to keep WESP extensible! 
 
Thanks, Manav

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron=20 Sheffer
Sent: Wednesday, November 18, 2009 1.00 PM
To:=20 IPsecme WG
Subject: [IPsec] Ensuring future extensibility for=20 WESP

Hi,

 

The recent draft on extendi= ng WESP=20 which was presented in Hiroshima, explains why the current WE= SP is=20 *not* extensible, and we = would=20 need a new version number if we are to add any extensions in the=20 future.

 

It is up to the WG to decid= e=20 whether or not we want to adopt the draft, given that many people were=20 skeptical about the specific extensions proposed. But regardless of that,= it=20 would be a mistake to publish WESP today with no facility for extensibili= ty.=20 After consulting with Pasi (the draft is at a very late stage, having bee= n=20 through IESG review), I would like to make a simple proposal to add this= =20 extensibility, with (almost) no change to the current draft. This will le= ave=20 us with future options, at virtually no cost. I am basically just changin= g the=20 semantics of the Padding field. Specifically:

 

1. Rename IPv6Padding to &#= 8220;Padding=20 (Reserved for Future Use)”, and allow it to be any length <256, = subject to=20 the IPv4 and IPv6 alignment constraints.

2. If P=3D1 (Padding Presen= t flag),=20 the first octet of the Padding field will hold the padding's length. [Har= dware=20 implementations can check that it is 4 for IPv6, otherwise move the packe= t to=20 the slow path]. All other Padding octets are sent as zero, and ignored by= the=20 receiver.

 

Note that there are barely = any=20 changes on the wire, as long as we don't have extensions. In particular t= he=20 length remains unchanged.

 

Thanks,

    &nb= sp;      =20 Yaron

--_000_7C362EEF9C7896468B36C9B79200D8350AB2F637DDINBANSXCHMBSA_-- From ken.grewal@intel.com Fri Nov 20 09:05:34 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 242B53A6A58 for ; Fri, 20 Nov 2009 09:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N868g3hLx4fC for ; Fri, 20 Nov 2009 09:05:30 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id B9C913A689E for ; Fri, 20 Nov 2009 09:05:30 -0800 (PST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 20 Nov 2009 08:50:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.44,778,1249282800"; d="scan'208,217";a="571537605" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by orsmga001.jf.intel.com with ESMTP; 20 Nov 2009 09:05:18 -0800 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi; Fri, 20 Nov 2009 10:05:27 -0700 From: "Grewal, Ken" To: Yaron Sheffer , IPsecme WG Date: Fri, 20 Nov 2009 10:04:04 -0700 Thread-Topic: Ensuring future extensibility for WESP Thread-Index: AcpoFSLc1kth/nrBQ1azCQhwolsjHAB7bc5Q Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888ABAF@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888ABAF@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C49B4B6450D9AA48AB99694D2EB0A483382B3294rrsmsx505amrcor_" MIME-Version: 1.0 Subject: Re: [IPsec] Ensuring future extensibility for WESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 17:05:34 -0000 --_000_C49B4B6450D9AA48AB99694D2EB0A483382B3294rrsmsx505amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support this change to ensure future compatibility with the base draft. As Yaron indicates, the extension header size is as per the current draft a= nd we are just adding some semantics to the pad field. There is also minimal textual change in the document. Thanks, - Ken From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Tuesday, November 17, 2009 11:30 PM To: IPsecme WG Subject: [IPsec] Ensuring future extensibility for WESP Hi, The recent draft on extending WESP which was presented in Hiroshima, explai= ns why the current WESP is *not* extensible, and we would need a new versio= n number if we are to add any extensions in the future. It is up to the WG to decide whether or not we want to adopt the draft, giv= en that many people were skeptical about the specific extensions proposed. = But regardless of that, it would be a mistake to publish WESP today with no= facility for extensibility. After consulting with Pasi (the draft is at a = very late stage, having been through IESG review), I would like to make a s= imple proposal to add this extensibility, with (almost) no change to the cu= rrent draft. This will leave us with future options, at virtually no cost. = I am basically just changing the semantics of the Padding field. Specifical= ly: 1. Rename IPv6Padding to "Padding (Reserved for Future Use)", and allow it = to be any length <256, subject to the IPv4 and IPv6 alignment constraints. 2. If P=3D1 (Padding Present flag), the first octet of the Padding field wi= ll hold the padding's length. [Hardware implementations can check that it i= s 4 for IPv6, otherwise move the packet to the slow path]. All other Paddin= g octets are sent as zero, and ignored by the receiver. Note that there are barely any changes on the wire, as long as we don't hav= e extensions. In particular the length remains unchanged. Thanks, Yaron --_000_C49B4B6450D9AA48AB99694D2EB0A483382B3294rrsmsx505amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support this change to ensure future compatibility with th= e base draft.

As Yaron indicates, the extension header size is as per the current draft and we are just adding some semantics to the pad field. =

 

There is also minimal textual change in the document.

 

Thanks,

- Ken<= /p>

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Yaron Sheffer
Sent: Tuesday, November 17, 2009 11:30 PM
To: IPsecme WG
Subject: [IPsec] Ensuring future extensibility for WESP

 

Hi,

 

The recent draft on extending WESP which was presented in Hiroshima, explains w= hy the current WESP is *not* extensible, and we would need a new versio= n number if we are to add any extensions in the future.

 

It is up to the WG to decide whether or not we want to adopt the draft, given = that many people were skeptical about the specific extensions proposed. But regardless of that, it would be a mistake to publish WESP today with no facility for extensibility. After consulting with Pasi (the draft is at a v= ery late stage, having been through IESG review), I would like to make a simple proposal to add this extensibility, with (almost) no change to the current draft. This will leave us with future options, at virtually no cost. I am basically just changing the semantics of the Padding field. Specifically:

 

1. Rename IPv6Padding to “Padding (Reserved for Future Use)”, and allow it to be any length <256, subject to the IPv4 and IPv6 alignment constraints.

2. If P=3D1 (Padding Present flag), the f= irst octet of the Padding field will hold the padding's length. [Hardware implementations can check that it is 4 for IPv6, otherwise move the packet = to the slow path]. All other Padding octets are sent as zero, and ignored by t= he receiver.

 

Note that there are barely any changes on= the wire, as long as we don't have extensions. In particular the length remains unchanged.

 

Thanks,

       = ;     Yaron

--_000_C49B4B6450D9AA48AB99694D2EB0A483382B3294rrsmsx505amrcor_-- From kohn.jack@gmail.com Fri Nov 20 16:24:50 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6423A67E4 for ; Fri, 20 Nov 2009 16:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AJvJSdz1ulE for ; Fri, 20 Nov 2009 16:24:49 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id B7BE63A67BE for ; Fri, 20 Nov 2009 16:24:49 -0800 (PST) Received: by ywh13 with SMTP id 13so4450942ywh.29 for ; Fri, 20 Nov 2009 16:24:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9A+9s3WxdKop+2uF+SoJnpazql3ll7tRGa5qlsVAlH0=; b=rx0mkZEGTGSRYJuq5WeY9vIMlD71gKLFVnuKWIo0xfWlBmcu1bVsnCOmp7vzLRNtDX PbKFpyYswEF+p+C7kqHbARtXnybppPeblVd7IaExWbEbX6sAgG4GItzeBrTczC/jYVms csDfrQ7kHgw0ZKWXbpMEA7MYEHC4ZYJy2lgng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=caJS5/KTyTE+JSIvKAvO/ouDfozCvqN06RU/C3WuCdMC/4E8jISJd/hdYQsLc/wwfi /ZS8coiW2zZbgJmwPZ+pbrZTFDm/eARfVeuZiQ0PK0QMpTXMOWEcHkxRjERgCEI0aQa5 0iU+BLxr22r9IGsKMdEDgVjT5x9E4WbFhr83s= MIME-Version: 1.0 Received: by 10.90.14.13 with SMTP id 13mr3301525agn.117.1258763074082; Fri, 20 Nov 2009 16:24:34 -0800 (PST) In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888ABAF@il-ex01.ad.checkpoint.com> Date: Sat, 21 Nov 2009 05:54:33 +0530 Message-ID: From: Jack Kohn To: "Grewal, Ken" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: IPsecme WG Subject: Re: [IPsec] Ensuring future extensibility for WESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 00:24:50 -0000 I support this as well. Jack On Fri, Nov 20, 2009 at 10:34 PM, Grewal, Ken wrote: > I support this change to ensure future compatibility with the base draft. > > As Yaron indicates, the extension header size is as per the current draft > and we are just adding some semantics to the pad field. > > > > There is also minimal textual change in the document. > > > > Thanks, > > - Ken > > > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Yaron Sheffer > Sent: Tuesday, November 17, 2009 11:30 PM > To: IPsecme WG > Subject: [IPsec] Ensuring future extensibility for WESP > > > > Hi, > > > > The recent draft on extending WESP which was presented in Hiroshima, > explains why the current WESP is *not* extensible, and we would need a ne= w > version number if we are to add any extensions in the future. > > > > It is up to the WG to decide whether or not we want to adopt the draft, > given that many people were skeptical about the specific extensions > proposed. But regardless of that, it would be a mistake to publish WESP > today with no facility for extensibility. After consulting with Pasi (the > draft is at a very late stage, having been through IESG review), I would > like to make a simple proposal to add this extensibility, with (almost) n= o > change to the current draft. This will leave us with future options, at > virtually no cost. I am basically just changing the semantics of the Padd= ing > field. Specifically: > > > > 1. Rename IPv6Padding to =93Padding (Reserved for Future Use)=94, and all= ow it > to be any length <256, subject to the IPv4 and IPv6 alignment constraints= . > > 2. If P=3D1 (Padding Present flag), the first octet of the Padding field = will > hold the padding's length. [Hardware implementations can check that it is= 4 > for IPv6, otherwise move the packet to the slow path]. All other Padding > octets are sent as zero, and ignored by the receiver. > > > > Note that there are barely any changes on the wire, as long as we don't h= ave > extensions. In particular the length remains unchanged. > > > > Thanks, > > Yaron > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > From kent@bbn.com Sat Nov 21 05:03:10 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12DF53A682D for ; Sat, 21 Nov 2009 05:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vC4lNNh3GtlD for ; Sat, 21 Nov 2009 05:03:09 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 1EFC43A6819 for ; Sat, 21 Nov 2009 05:03:09 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.3]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NBpcE-0005AC-A3; Sat, 21 Nov 2009 08:03:02 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <19200.8786.266973.313959@fireball.kivinen.iki.fi> <19201.20208.563706.519993@fireball.kivinen.iki.fi> Date: Sat, 21 Nov 2009 08:03:02 -0500 To: Gregory Lebovitz From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-953313913==_ma============" Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Tero Kivinen Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 13:03:10 -0000 --============_-953313913==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 11:03 AM -0800 11/17/09, Gregory Lebovitz wrote: >inline... > >On Mon, Nov 16, 2009 at 8:18 AM, Stephen Kent ><kent@bbn.com> wrote: > >At 7:50 PM +0530 11/16/09, Bhatia, Manav (Manav) wrote: > >This is an implementation specific optimization that has already >been solved in multiple implementations. > >Cheers, Manav > > >Is the phrase "implementation specific" a euphemism for non-standard? > > >GML> Or perhaps, a local security policy decision to ease up on the >size of the enforcement window -- aka ease security requirements -- >in order to get more QoS enforcement capability -- aka convenience >-- ?? 4301 contains We have explicit directions on how to use multiple SAs when the peers know that they want to send traffic with different QoS parameters. This appears to be an instance where the middle boxes are to examining traffic, and putting in into different QoS queues. That raises the question of how a receiver would know that this is happening, so that a bigger enforcement window is needed. ESP and AH already allow a receiving peer to select any size window that it wants, bigger than the specified minimum. So that is not an issue. Steve --============_-953313913==_ma============ Content-Type: text/html; charset="us-ascii" Re: [IPsec] WESP - Roadmap Ahead
At 11:03 AM -0800 11/17/09, Gregory Lebovitz wrote:
inline...
On Mon, Nov 16, 2009 at 8:18 AM, Stephen Kent <kent@bbn.com> wrote:
At 7:50 PM +0530 11/16/09, Bhatia, Manav (Manav) wrote:
This is an implementation specific optimization that has already been solved in multiple implementations.

Cheers, Manav

Is the phrase "implementation specific" a euphemism for non-standard?

GML>  Or perhaps, a local security policy decision to ease up on the size of the enforcement window -- aka ease security requirements -- in order to get more QoS enforcement capability -- aka convenience -- ??

4301 contains We have explicit directions on how to use multiple SAs when the peers know that they want to send traffic with different QoS parameters. This appears to be an instance where the middle boxes are to examining traffic, and putting in into different QoS queues. That raises the question of how a receiver would know that this is happening, so that a bigger enforcement window is needed.

ESP and AH already allow a receiving peer to select any size window that it wants, bigger than the specified minimum. So that is not an issue.

Steve
--============_-953313913==_ma============-- From kohn.jack@gmail.com Sat Nov 21 09:39:44 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAAF43A696C for ; Sat, 21 Nov 2009 09:39:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMJGwYmCivcC for ; Sat, 21 Nov 2009 09:39:44 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id DA4243A6960 for ; Sat, 21 Nov 2009 09:39:43 -0800 (PST) Received: by ywh15 with SMTP id 15so4145086ywh.5 for ; Sat, 21 Nov 2009 09:39:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=p5cin/nXmd5h23yHxxusSGl1QhuSJquelQaH1buNK1w=; b=EuWBLZVHh//oOfcANz/SIT62sx4ZGCi640fYeSBv3pn9YZBUjfFysbExKdLrW76z98 FMdhalTpZsBoBsUgXdi+4nwTQ0xB98Uh7AckMJjvd7pQpHw2sbn293i1aX64uueu66hE HDSkIDKJ7GVD1aJit63TYk58mRQCsQ6lEXAM8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TTlRYvqSyg47n7C7DWnSPrkqmnaBNDL6XsPMrrL+jwHPF9OsLpjTPuoGOP2QPMp1+f E4bWgf6znyAVzDVARiaaVriQ8+ahCLaGagUZ7duz+P6aeV7sgsopsdBcPbYDk3tQl4qO F+KTJSB1P/Kg6x/aSSzuKhYwiZfTqvhNuN458= MIME-Version: 1.0 Received: by 10.91.164.17 with SMTP id r17mr4292943ago.92.1258825176022; Sat, 21 Nov 2009 09:39:36 -0800 (PST) In-Reply-To: References: <19200.8786.266973.313959@fireball.kivinen.iki.fi> <19201.20208.563706.519993@fireball.kivinen.iki.fi> Date: Sat, 21 Nov 2009 23:09:35 +0530 Message-ID: From: Jack Kohn To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Tero Kivinen Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 17:39:44 -0000 Steve, > > 4301 contains We have explicit directions on how to use multiple SAs when > the peers know that they want to send traffic with different QoS parameters. > This appears to be an instance where the middle boxes are to examining > traffic, and putting in into different QoS queues. That raises the question You got it all wrong. The sender is sending packets with the same QoS parameters; its the receiver thats trying to prioritize some packets over the others. One would typically do this for the Hellos/KeepAlives that are associated with a protocol, so that the adjacency/peering session are not timed out. Jack From hyla81420@mypacks.net Sat Nov 21 12:53:35 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14883A68C3 for ; Sat, 21 Nov 2009 12:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G75v-kWY9tPU for ; Sat, 21 Nov 2009 12:53:35 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 25DAA3A688C for ; Sat, 21 Nov 2009 12:53:35 -0800 (PST) Received: from [209.86.224.46] (helo=elwamui-royal.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NBwxW-0000HF-4r for ipsec@ietf.org; Sat, 21 Nov 2009 15:53:30 -0500 Received: from 144.189.100.25 by webmail.earthlink.net with HTTP; Sat, 21 Nov 2009 15:53:29 -0500 Message-ID: <155808.1258836809981.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Sat, 21 Nov 2009 13:53:29 -0700 (GMT-07:00) From: hyla81420@mypacks.net To: IPSEC List Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: e65ff8be1ec94f802adf59f7e2246db04d2b10475b57112024f0a00d9a1b29a4d131d9f4cf9c7243c6b317bf5bc479bb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.46 Subject: Re: [IPsec] How long does an IKEv1 session take to complete? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 20:53:36 -0000 Thanks All. Round trip is definitely one part of it, and as you pointed out, my question was related to if the DH group/RSA computation were seen to be expensive. 20 msecs are not prohibitive. I was also hoping to garner any info on open source implementations as my end goals is for seeking an IKEv1 product so it would have been great to know where proprietary solutions stand relatively speaking. Any pointers would be greatly appreciated. -----Original Message----- >From: Yoav Nir >Sent: Nov 18, 2009 10:49 PM >To: " " >Cc: "ipsec@ietf.org" >Subject: Re: [IPsec] How long does an IKEv1 session take to complete? > >What Dan and Gregory said. > >But assuming an unloaded gateway, with "normal" hardware (Any Intel, AMD or PowerPC processor from the last 10 years or a recent ARM), then even if you use relatively secure parameters (2048-bit DH group, 2048-bit RSA keys) the round trip time is going to dominate. The calculations themselves take less than 20 milliseconds. > >So phase 1 should take about 3 round trips. > >On Nov 18, 2009, at 8:31 AM, wrote: > >> Greetings. Is there any data out there that quantifies how long a typical IKEv1 session (main mode and/or aggressive mode) take to complete? >> >> Hyla > From kent@bbn.com Sun Nov 22 06:25:57 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7B63A6819 for ; Sun, 22 Nov 2009 06:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OdgUApUWrpp for ; Sun, 22 Nov 2009 06:25:56 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id BED0A3A67A2 for ; Sun, 22 Nov 2009 06:25:56 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.3]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NCDNv-0000wK-A7; Sun, 22 Nov 2009 09:25:51 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <19200.8786.266973.313959@fireball.kivinen.iki.fi> <19201.20208.563706.519993@fireball.kivinen.iki.fi> Date: Sun, 22 Nov 2009 09:25:47 -0500 To: Jack Kohn From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Tero Kivinen Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 14:25:57 -0000 At 11:09 PM +0530 11/21/09, Jack Kohn wrote: >Steve, > >> >> 4301 contains We have explicit directions on how to use multiple SAs when >> the peers know that they want to send traffic with different QoS parameters. >> This appears to be an instance where the middle boxes are to examining >> traffic, and putting in into different QoS queues. That raises the question > >You got it all wrong. The sender is sending packets with the same QoS >parameters; its the receiver thats trying to prioritize some packets >over the others. One would typically do this for the Hellos/KeepAlives >that are associated with a protocol, so that the adjacency/peering >session are not timed out. > >Jack Jack, Maybe I got it "all wrong" because the explanation provided in the messages was, at best, ambiguous :-). Your description above is only marginally better: - it fails to characterize the range of protocols for which you believe this argument applies, -it fails to explain how WESP is relevant, since a receiver has the ability to process encrypted packets. WESP is a protocol that has been promoted as designed to aid middle boxes, not end systems Steve From kohn.jack@gmail.com Sun Nov 22 15:17:51 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19D6A3A680E for ; Sun, 22 Nov 2009 15:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMV4YGVAfGB6 for ; Sun, 22 Nov 2009 15:17:50 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 2EFCA3A67F5 for ; Sun, 22 Nov 2009 15:17:50 -0800 (PST) Received: by ywh15 with SMTP id 15so4789891ywh.5 for ; Sun, 22 Nov 2009 15:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=taiHBEhgVEYezjX0C6oJTcoDz82ZvKePKcyYVHzHRGI=; b=WqhtQKuiYtwFozv7HhU7e909tLs841cUsRl1u0tihv52KTrvLbAhzyPNXO7FKx6MCJ /e7lNh/IZwq2DKEKYDCq3HaMqbapJtmXOE0H+s9F4B+4wxUX5xTb5KLzIMaGOAlJzCrb 0uOh4xEHh4gvMm3Z5f9Rp/1MK2jbBW1McE3UM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=V+r7b8OR7CY/RUUML4YplFkmS31xQq2B5pb4gMZr91lyliy7vaR0sj5GJ8ImLXh5dY uTHHGVEfC2g7MyqU8tiSAL23Vj/nRTg/mpxJcm4e3ztsr0+Vk08NOqXUjo0KRvAFaoJ3 3TT7cjRNtg+RH94OBOK2lKoLq4JFjkkzUEROM= MIME-Version: 1.0 Received: by 10.90.217.13 with SMTP id p13mr5559852agg.108.1258931862110; Sun, 22 Nov 2009 15:17:42 -0800 (PST) In-Reply-To: References: <19200.8786.266973.313959@fireball.kivinen.iki.fi> <19201.20208.563706.519993@fireball.kivinen.iki.fi> Date: Mon, 23 Nov 2009 04:47:42 +0530 Message-ID: From: Jack Kohn To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 23:17:51 -0000 >> >> You got it all wrong. The sender is sending packets with the same QoS >> parameters; its the receiver thats trying to prioritize some packets >> over the others. One would typically do this for the Hellos/KeepAlives >> that are associated with a protocol, so that the adjacency/peering >> session are not timed out. >> >> Jack > > Jack, > > Maybe I got it "all wrong" because the explanation provided in the messages > was, at best, ambiguous :-). > > Your description above is only marginally better: > > - it fails to characterize the range of protocols for which you > believe this argument applies, http://www.ietf.org/mail-archive/web/ipsec/current/msg05070.html This is one example, we could think of some more. > > -it fails to explain how WESP is relevant, since a receiver has the This has already been discussed in this email thread earlier. > ability to process encrypted packets. WESP is a protocol that has been > promoted as designed to aid middle boxes, not end systems Border Gateway Protocol (BGP) (http://www.ietf.org/rfc/rfc4271.txt) was originally designed to work as an Exterior Gateway Protocol (EGP). Today besides working as an EGP it is used in myriad other applications, from discovering nodes in a VPN to distributing advisory messages to remote network operators. So, i dont see a reason why we should restrict ourselves to the applications for which a protocol can be used .. Jack > > Steve > From kivinen@iki.fi Mon Nov 23 05:07:22 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787A33A6A70 for ; Mon, 23 Nov 2009 05:07:22 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aZJQi5+l2pD for ; Mon, 23 Nov 2009 05:07:21 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id AD73C3A69A1 for ; Mon, 23 Nov 2009 05:07:18 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAND79LI019844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 15:07:10 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAND79VK019019; Mon, 23 Nov 2009 15:07:09 +0200 (EET) 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: <19210.35069.312878.963930@fireball.kivinen.iki.fi> Date: Mon, 23 Nov 2009 15:07:09 +0200 From: Tero Kivinen To: Nicolas Williams In-Reply-To: <20091014173852.GO887@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328329@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BD9338E802@il-ex01.ad.checkpoint.com> <20091013183424.GH887@Sun.COM> <19157.47028.842967.590918@fireball.kivinen.iki.fi> <20091014173852.GO887@Sun.COM> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 13 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 13:07:22 -0000 Nicolas Williams writes: > On Wed, Oct 14, 2009 at 02:36:20PM +0300, Tero Kivinen wrote: > > Yes. That was what I tried to say. Do you think my already changed > > sentence is ok, or do we need to explain it more. > > Well, the heuristics will benefit from the information cached for the > TCP/UDP flow over the previous SA. "...benefit from the existing flows" > doesn't quite get that point across (though it's the only realistic > meaning). Changed the text still more: Generic protocol checking is much easier with pre-existing state. For example, when many TCP / UDP flows are established over one IPsec SA, a rekey produces a new SA which needs heuristics to detect its parameters, and those heuristics benefit from the existing TCP / UDP flows which were present in the previous IPsec SA. In that case it is just enough to check that if a new IPsec SA has packets belonging to the flows of some other IPsec SA (previous IPsec SA before rekey), and if those flows are already known by the deep inspection engine, it will give a strong leaning that the new SA is really ESP-NULL. > But surely actively trying to elicit retransmissions could be used > as a way to get enough information to classify a flow... The > retransmissions should have different MACs, thus retransmissions > help resolve ambiguities, even if the policy isn't to drop packets that > cannot be inspected. I would be quite hesitant to add text which actively tries to elicit more retransmissions. If packets are dropped because of policy reasons and that triggers retransmissions which helps heuristics, then that is good. If packets are passed through then we can most likely use heuristics over multiple packets to gain same information. > > If the policy is so that packets are passed, even when we cannot yet > > inspect them, then the next packet still might be to the same flow. > > I see. Having a policy that says "drop packets that can't be inspected" > actually helps resolve ambiguities if the end nodes retransmit. Yes, but it also helps to resolve ambiguities, if we see multiple packets to the same flow, i.e. get 3 TCP packets having same source and destionation IP and ports, and first having SYN bit, next reply having SYN/ACK and next one having ACK (with all of them with expected sequence numbers etc). > > enforcement and protection of the end node. One way to enforce > > deep inspection for all traffic, is to forbid encrypted ESP > > completely, in which case ESP-NULL detection is easier, as all > > packets must be ESP-NULL based on the policy, and further > > restriction can eliminate ambiguities in ICV and IV sizes. > ^ > s > > Great! Fixed. > A few more comments: > > - Should there be an explicit threat model in the document? I am not sure if it belongs to this document, or to the WESP or as separate document. I agree that having explicit threat model could probably help understanding the problem, but I am not sure I am correct person to write such. > I think > the threat model is this: > > - End nodes trying to access inappropriate data, end nodes trying > sneak confidential data out, but without collusion with other end > nodes outside the network. > > - Malware (since deep inspection could find malware and terminate > flows before malware downloads complete). > > The first one shows how simple it is to defeat deep packet > inspection: just find a peer to collude with. There is also some cases where this can be used even when there is no real threat, i.e. statics, and log gathering etc. > - A security considerations note about the security impact of forcing > the use of ESP-NULL (and/or WESP) would be nice. Specifically a note > about the increased risk of sending confidential information where > eavesdroppers can see it. Added note: Using ESP-NULL or especially forcing using of it everywhere inside the enterprice can have increased risk of sending confidential information where eavesdroppers can see it. > The thought occurred that the pseudo-code could be expressed as a BSD > Packet Filter program. From what I can tell BPF does not have > instructions by which one can implement state caching, but you could > still implement, and _test_, large parts of the code in the appendix as > BPF programs. I wouldn't demand that -- it's a lot of work for a > feature that we all seem to agree is not exactly hot (and it might mean > doing implementation work for some vendors for free). I do not expect the pseudo-code to include all required operations, and I do not think it would be good idea to put executable code in the RFC. It is meant to be as example pseudo-code, not final implementation. I think it might be better if someone could take that pseudo-code, and implement as much as possible of it as BSD packet filter or some other filtering language and put that out as open-source implementation. This might be suitable exercise for some student out there... :-) -- kivinen@iki.fi From kivinen@iki.fi Mon Nov 23 05:43:48 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4248B3A6A82 for ; Mon, 23 Nov 2009 05:43:48 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0plvfjRPR1TM for ; Mon, 23 Nov 2009 05:43:47 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1EC633A6A83 for ; Mon, 23 Nov 2009 05:43:46 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nANDhd6W021244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 15:43:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nANDhcSf022505; Mon, 23 Nov 2009 15:43:38 +0200 (EET) 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: <19210.37258.147689.357367@fireball.kivinen.iki.fi> Date: Mon, 23 Nov 2009 15:43:38 +0200 From: Tero Kivinen To: Tero Mononen In-Reply-To: <4B050533.5030102@iki.fi> References: <4B050533.5030102@iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: ipsec@ietf.org Subject: [IPsec] Comments on draft-ietf-ipsecme-esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 13:43:48 -0000 Tero Mononen writes: > Overall comments: > > The draft contains quite a lot of background information (what you are > trying to achieve on technical point of view, what were the > alternative solutions considered). Part of this background is also > available on WESP draft. > > Making this draft an information disclosure on "algorithm to > determine if IPsec ESP packet stream has been encrypted or not", > without too much explanation or hand waving would increase its > usability. The background could be find by-reference on the WESP > RFC. I think having background information in this document also makes this document easier to understand. WESP document actually has quite a little of the background information. > Please consider adding definitions/glossary entries for the > following concepts: flow, flow-cache. I know they are relevant on > certain implementations, but not necessarily well defined on that > sense, or at least introducing these terms properly before using > them. I added terminology section and added those terms there. > About the abstract: > > Consider changing abstract in a way that really points out the > good on this approach. Something like: > > -8<--- > > This document describes an algorithm for distinguishing IPSEC > ESP- NULL packets from encrypted ESP packets. The algorithm can > be used on intermediate devices, like traffic analyzers, and deep > inspection engines, to quickly decide whether given packet flow is > interesting or not. Use of this algorithm does not require any > changes made on existing RFC4303 compliant IPSEC hosts. > > -8<--- Changed. -- kivinen@iki.fi From kivinen@iki.fi Mon Nov 23 05:53:41 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F9FA3A693C for ; Mon, 23 Nov 2009 05:53:41 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6e8R3ipcpXSw for ; Mon, 23 Nov 2009 05:53:40 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 98B223A68B0 for ; Mon, 23 Nov 2009 05:53:39 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nANDrYoh021039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Nov 2009 15:53:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nANDrY5L020075; Mon, 23 Nov 2009 15:53:34 +0200 (EET) Date: Mon, 23 Nov 2009 15:53:34 +0200 (EET) Resent-From: kivinen@iki.fi Message-Id: <200911231353.nANDrY5L020075@fireball.kivinen.iki.fi> X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f Resent-Message-ID: <19210.37854.280474.200170@fireball.kivinen.iki.fi> Resent-Date: Mon, 23 Nov 2009 15:53:34 +0200 Resent-To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Michael Richardson In-Reply-To: <10247.1257346966@marajade.sandelman.ca> References: <10247.1257346966@marajade.sandelman.ca> X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 0 min Cc: ipsec@ietf.org Subject: [IPsec] comments on esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 13:53:41 -0000 Michael Richardson writes: > > As end nodes might be able to > > bypass those checks by using encrypted ESP instead of ESP-NULL, these > > kinds of scenarios also require very specific policies to forbid such > > circumvention. > > The question is, are these end-nodes malicious, or are they just > ignorant? Good question, and I do not have good answer to that, as I do not think we have clear threat model for WESP / heuristics. > > Because the traffic inspected is usually host to host traffic inside > > one organization, that usually means transport mode IPsec is used. > > It is? I'll bet 95% of actual transport mode IPsec has an L2TP layer inside. Inside one enterprise? I do not think so. I guess most of the IPsec traffic is VPN style tunnel mode, but as that is going over untrusted networks (there is word private there :) they are encrypted, thus outside the scope of this draft. Same goes with the L2TP transport mode cases. I added a note there saying: Note, that most of the current uses of the IPsec are not host to host traffic inside one organization, but for the intended use cases for the heuristics this will most likely be the case. Also tunnel mode case is much easier to solve than transport mode as it is much easier to detect the IP header inside the ESP-NULL packet. > I agree with the analysis of section 3, in particular the explanation of > how hardware can be programmed to statefully match the ESP-NULL flows. > It might be worth noting that NAT-T ESP-NULL flows *ALREADY* have a > 5-tuple (likely unique) marker, and that if the inspector is also a NA(P)T, > that it already is keeping the right state. Do you have any exact wordings where to add what. > section 4. > > It might be worth having a reference for "flow cache". I think that > there is a document on Cisco Netflow, and I also think that FORCES has > something that relates to the Linux "flow" things. I think it might > also be worth staying that this is really a "microflow" cache. I added new terms to terminology section saying: Flow TCP/UDP or IPsec flow is a stream of packets part of the same TCP/ UDP or IPsec stream, i.e. TCP flow is a stream of packets having same 5 tuple (source and destination ip and port, and TCP protocol). Flow Cache Deep inspection engines and similar use cache of flows going through the device, and that cache keeps state of all flows going through the device. IPsec Flow IPsec flow stream of packets having same source IP, destination IP, protocol (ESP/AH) and SPI. Strictly speaking source IP does not need to be as part of the flow identification, but as it can be there depending on the receiving implementation it is safer to assume it is always part of the flow identification. > Include a forward reference to section 7, so the reader knows UDP will > be dealt with. In particular, in the text relating to NAT-T > encapsulated IKE packets. If they are not allowed through (queue until > sure, or drop option), then the SA might not get setup ever.. Hmm... I think it should be enough to cover UDP encapsulation in the section 7, do you really think we need forward reference from here? If so, can you give me some exact text? > section 8.2 > > I'd rather see the math/calculations in a display... that would > eliminate the difficulty in reading when things are wrapped. Done. > page 16: > > those cases the packet must be marked "unsure". > > s/must/MUST/ ??? I do not use RFC2119 words in the document as this is not really protocol description. Changed the text to: In those cases the packets are marked as "unsure". > In conclusion: while I think the whole inspection notion is ridiculous, > and likely is going to get in the way of deployment of > new protocols, and may well help the "throttlers" > (cf. Mark Handley's Net Neutrality presentation at > IETF75), I find that if the inspection people follow the > very sage advice of Kivinen and McDonald, that the least > amount of harm possible will be done. -- kivinen@iki.fi From kivinen@iki.fi Mon Nov 23 05:59:07 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2CA3A6A6E for ; Mon, 23 Nov 2009 05:59:07 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVk74IuVYHly for ; Mon, 23 Nov 2009 05:59:07 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id ACF463A68B4 for ; Mon, 23 Nov 2009 05:59:06 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nANDx16i019588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Nov 2009 15:59:01 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nANDx1be021764; Mon, 23 Nov 2009 15:59:01 +0200 (EET) 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: <19210.38181.376046.564780@fireball.kivinen.iki.fi> Date: Mon, 23 Nov 2009 15:59:01 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Subject: [IPsec] draft-ietf-ipsecme-esp-null-heuristics-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 13:59:07 -0000 Submitted now a new version of the heuristics draft, which includes changes from Williams, Mononen, Richardson, Graveman and Moononen. This should now include all changes that were requested, if I missed some, send me a note. Draft can already be found from the ietf repository http://www.ietf.org/id/draft-ietf-ipsecme-esp-null-heuristics-02.txt but it takes some time before it appears to the tools site (i.e. if you want to get diffs etc): http://tools.ietf.org/html/draft-ietf-ipsecme-esp-null-heuristics -- kivinen@iki.fi From root@core3.amsl.com Mon Nov 23 06:00:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B026D3A6A79; Mon, 23 Nov 2009 06:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091123140001.B026D3A6A79@core3.amsl.com> Date: Mon, 23 Nov 2009 06:00:01 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-esp-null-heuristics-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 14:00:01 -0000 --NextPart 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 : Heuristics for Detecting ESP-NULL packets Author(s) : T. Kivinen, D. McDonald Filename : draft-ietf-ipsecme-esp-null-heuristics-02.txt Pages : 35 Date : 2009-11-23 This document describes an algorithm for distinguishing IPsec ESP- NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. The algorithm can be used on intermediate devices, like traffic analyzers, and deep inspection engines, to quickly decide whether given packet flow is interesting or not. Use of this algorithm does not require any changes made on existing RFC4303 compliant IPsec hosts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-esp-null-heuristics-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-esp-null-heuristics-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-23055412.I-D@ietf.org> --NextPart-- From paul.hoffman@vpnc.org Mon Nov 23 12:27:11 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA5C3A69E6 for ; Mon, 23 Nov 2009 12:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.264 X-Spam-Level: X-Spam-Status: No, score=-5.264 tagged_above=-999 required=5 tests=[AWL=-0.707, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1w90wPQbVwa for ; Mon, 23 Nov 2009 12:27:11 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id F3FCD3A677E for ; Mon, 23 Nov 2009 12:27:10 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nANKR2B8031762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 13:27:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 23 Nov 2009 12:27:01 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Hiroshima meeting minutes posted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 20:27:11 -0000 They are at ; please let Yaron or I know if you find any errors. FWIW, Gabriel got them to us almost immediately after the meeting, so the lateness is the fault of your WG chairs, not of the minutes-taker. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Mon Nov 23 16:18:59 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F32D28C0E1 for ; Mon, 23 Nov 2009 16:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.93 X-Spam-Level: X-Spam-Status: No, score=-5.93 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xe5PZd5pY4Ro for ; Mon, 23 Nov 2009 16:18:58 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 4E9603A67B5 for ; Mon, 23 Nov 2009 16:18:58 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAO0Irme043397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Nov 2009 17:18:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 23 Nov 2009 16:18:51 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] #121: Rekeying IKE SAs: KEr errors and PRF question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 00:18:59 -0000 We earlier agreed in issue #50 to make the KEr in Section 1.3.2 (Rekeying IKE SAs with the CREATE_CHILD_SA Exchange) mandatory: <-- HDR, SK {SA, Nr, KEr} Note that this is not in the current draft, but will be in the next one. So, what happens if the responder does not include a KEr, following the syntax in RFC 4306? Does the process revert back to using only the SK_d and the new nonces, or does the responder reject the request and indicate its preferred DH group in the INVALID_KE_PAYLOAD notification payload (section 1.3)? The latter seems much more likely, given the text in 2.18. If so, we should say so explicitly. Section 2.18 also states that in the case of the old and new IKE SA selecting different PRFs, that the rekeying exchange (for SKEYSEED) is done using the *old* IKE SA's PRF. What happens after that? The end of section 2.18 says that SK_d, etc are computed from SKEYSEED as specified in section 2.14. If the PRF changed, which PRF is used for the prf+ calculations, the old PRF or the new PRF? --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Mon Nov 23 16:32:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11373A6939 for ; Mon, 23 Nov 2009 16:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.942 X-Spam-Level: X-Spam-Status: No, score=-5.942 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISFAymZSnGeD for ; Mon, 23 Nov 2009 16:32:52 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0FCB13A6778 for ; Mon, 23 Nov 2009 16:32:52 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAO0Wks9044030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Nov 2009 17:32:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 23 Nov 2009 16:32:43 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] #122: Integrity proposals with combined algorithms X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 00:32:52 -0000 The 4th paragraph of section 3.3 says "If an algorithm that combines encryption and integrity protection is proposed, it MUST be proposed as an encryption algorithm and an integrity protection algorithm MUST NOT be proposed." This means that an integrity protection algorithm can only be proposed with a Transform ID equal to NONE, given that a few paragraphs above, it says: "Combined-mode ciphers include both integrity and encryption in a single encryption algorithm, and are not allowed to be offered with a separate integrity algorithm other than "none"." We should thus make this clear in the 4th paragraph. HOWEVER, in section 3.3.2, in the table for transform types, it says: Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP (*) Negotiating an integrity algorithm is mandatory for the Encrypted payload format specified in this document. For example, [AEAD] specifies additional formats based on authenticated encryption, in which a separate integrity algorithm is not negotiated. The second sentence seems wrong. Proposed rewording: For example, [AEAD] specifies additional formats based on authenticated encryption, in which the integrity algorithm is an inherent part of the combined algorithm; in this case, the integrity algorithm is specified as "none". --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Mon Nov 23 16:37:30 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 540F93A6B39 for ; Mon, 23 Nov 2009 16:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.951 X-Spam-Level: X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw4-Pc0NSy9i for ; Mon, 23 Nov 2009 16:37:29 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 7D7493A6B35 for ; Mon, 23 Nov 2009 16:37:29 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAO0bOVh044289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Nov 2009 17:37:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 23 Nov 2009 16:37:22 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 00:37:30 -0000 This has flummoxed a few reviewers. Tables such as those in section 3.3.2 are already out of date because things have been added since RFC 4306. I propose that we remove all these tables from IKEv2bis, and add notes pointing to the current IANA registries. I cannot see how doing this lookup will hurt developers: in fact, it forces them to actually look at the up-to-date tables. I can see how we might want to leave the tables in, but it really is confusing. --Paul Hoffman, Director --VPN Consortium From danmcd@sun.com Mon Nov 23 17:09:43 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A5EA3A6834 for ; Mon, 23 Nov 2009 17:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTK36RwfV9Yn for ; Mon, 23 Nov 2009 17:09:42 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 559B03A63D3 for ; Mon, 23 Nov 2009 17:09:42 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAO19a2Y028558 for ; Tue, 24 Nov 2009 01:09:37 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTL00C009I8RZ00@mail-amer.sun.com> for ipsec@ietf.org; Mon, 23 Nov 2009 18:09:36 -0700 (MST) Received: from @ ([unknown] [71.174.113.16]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTL00C2M9VXDQ20@mail-amer.sun.com>; Mon, 23 Nov 2009 18:09:36 -0700 (MST) Date: Mon, 23 Nov 2009 20:09:33 -0500 From: Dan McDonald In-reply-to: Sender: Dan.McDonald@sun.com To: Paul Hoffman Message-id: <20091124010933.GA3457@mactavish> Organization: Sun Microsystems, Inc. - Solaris Networking & Security References: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: IPsecme WG Subject: Re: [IPsec] #122: Integrity proposals with combined algorithms X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 01:09:43 -0000 On Mon, Nov 23, 2009 at 04:32:43PM -0800, Paul Hoffman wrote: > The second sentence seems wrong. Proposed rewording: > For example, > [AEAD] specifies additional formats based on authenticated > encryption, in which the integrity algorithm is an inherent > part of the combined algorithm; in this case, the > integrity algorithm is specified as "none". Yes, this is much clearer, given we have a well-defined "none" value for integrity. Dan From danmcd@sun.com Mon Nov 23 17:12:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB1AB3A63D3 for ; Mon, 23 Nov 2009 17:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnMMquKvsoCl for ; Mon, 23 Nov 2009 17:12:34 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 8E9D43A6855 for ; Mon, 23 Nov 2009 17:12:34 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAO1CUXL025683 for ; Tue, 24 Nov 2009 01:12:30 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTL001009RAIE00@mail-amer.sun.com> for ipsec@ietf.org; Mon, 23 Nov 2009 18:12:30 -0700 (MST) Received: from @ ([unknown] [71.174.113.16]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTL00FMHA0SK8C0@mail-amer.sun.com>; Mon, 23 Nov 2009 18:12:30 -0700 (MST) Date: Mon, 23 Nov 2009 20:12:28 -0500 From: Dan McDonald In-reply-to: Sender: Dan.McDonald@sun.com To: Paul Hoffman Message-id: <20091124011228.GC3457@mactavish> Organization: Sun Microsystems, Inc. - Solaris Networking & Security References: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: IPsecme WG Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 01:12:36 -0000 On Mon, Nov 23, 2009 at 04:37:22PM -0800, Paul Hoffman wrote: > This has flummoxed a few reviewers. Tables such as those in section 3.3.2 > are already out of date because things have been added since RFC 4306. I > propose that we remove all these tables from IKEv2bis, and add notes > pointing to the current IANA registries. I cannot see how doing this lookup > will hurt developers: in fact, it forces them to actually look at the > up-to-date tables. I can see how we might want to leave the tables in, but > it really is confusing. Can you move 'em to an appendix, with a permanent URL reference to the IANA up-to-date versions? Dan From paul.hoffman@vpnc.org Mon Nov 23 17:18:40 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55853A693A for ; Mon, 23 Nov 2009 17:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.959 X-Spam-Level: X-Spam-Status: No, score=-5.959 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chF3Bj72-gb6 for ; Mon, 23 Nov 2009 17:18:39 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C41593A67FA for ; Mon, 23 Nov 2009 17:18:39 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAO1IV1I046138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 18:18:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <349076FF-487D-4B6C-91EB-1E845B2303F6@checkpoint.com> References: <349076FF-487D-4B6C-91EB-1E845B2303F6@checkpoint.com> Date: Mon, 23 Nov 2009 17:09:15 -0800 To: Yoav Nir From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: [IPsec] Closing #25 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 01:18:41 -0000 At 9:46 AM +0200 10/21/09, Yoav Nir wrote: >A few lines above this section it already says "If the responder's policy allows it to accept the first selector of TSi and TSr, then the responder MUST narrow the traffic selectors to a subset that includes the initiator's first choices." > >So there is a MUST requirement to select the initiator's first choice (if possible), so I don't think the SHOULD and MAY are appropriate here. The way I read this section, it only clarifies what to do if the initiator traffic selector (first or not) is too broad. In that case, we shouldn't mention the initiator's choices. > >On Oct 20, 2009, at 6:19 PM, Paul Hoffman wrote: > >>Issue #25, Choice of the right TS when narrowing > >>Proposed change: >> When narrowing is done, there may be several subsets that are >> acceptable but their union is not. In this case, the responder >> SHOULD select the initiator's first choice (to be interoperable >> with RFC 4306), but MAY arbitrarily select any of them, >> and MAY include an >> ADDITIONAL_TS_POSSIBLE notification in the response. God call. I have closed #25 without making any change. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Mon Nov 23 17:27:43 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D82893A6846 for ; Mon, 23 Nov 2009 17:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.966 X-Spam-Level: X-Spam-Status: No, score=-5.966 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWgRAP+NUu+d for ; Mon, 23 Nov 2009 17:27:43 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2B2C83A67B5 for ; Mon, 23 Nov 2009 17:27:43 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAO1Rbit046556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 18:27:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20091124011228.GC3457@mactavish> References: <20091124011228.GC3457@mactavish> Date: Mon, 23 Nov 2009 17:27:36 -0800 To: Dan McDonald From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 01:27:43 -0000 At 8:12 PM -0500 11/23/09, Dan McDonald wrote: >On Mon, Nov 23, 2009 at 04:37:22PM -0800, Paul Hoffman wrote: > >> This has flummoxed a few reviewers. Tables such as those in section 3.3.2 >> are already out of date because things have been added since RFC 4306. I >> propose that we remove all these tables from IKEv2bis, and add notes >> pointing to the current IANA registries. I cannot see how doing this lookup >> will hurt developers: in fact, it forces them to actually look at the >> up-to-date tables. I can see how we might want to leave the tables in, but >> it really is confusing. > >Can you move 'em to an appendix, with a permanent URL reference to the IANA >up-to-date versions? As long as you mean "an appendix that clearly says 'these were in RFC 4306 but are now out-of-date but are here just for reference and you want to look at '", I'm OK with that as well. --Paul Hoffman, Director --VPN Consortium From danmcd@sun.com Mon Nov 23 17:37:38 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B39023A6ADC for ; Mon, 23 Nov 2009 17:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qlv8KThIB-EU for ; Mon, 23 Nov 2009 17:37:38 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id F30F33A6AAC for ; Mon, 23 Nov 2009 17:37:37 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAO1bXxd002627 for ; Tue, 24 Nov 2009 01:37:34 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTL00B00B3D8700@mail-amer.sun.com> for ipsec@ietf.org; Mon, 23 Nov 2009 18:37:33 -0700 (MST) Received: from @ ([unknown] [71.174.113.16]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTL00C3IB6KDQ80@mail-amer.sun.com> for ipsec@ietf.org; Mon, 23 Nov 2009 18:37:33 -0700 (MST) Date: Mon, 23 Nov 2009 20:37:32 -0500 From: Dan McDonald In-reply-to: Sender: Dan.McDonald@sun.com To: ipsec@ietf.org Message-id: <20091124013732.GD3457@mactavish> Organization: Sun Microsystems, Inc. - Solaris Networking & Security References: <20091124011228.GC3457@mactavish> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 01:37:38 -0000 On Mon, Nov 23, 2009 at 05:27:36PM -0800, Paul Hoffman wrote: > >Can you move 'em to an appendix, with a permanent URL reference to the IANA > >up-to-date versions? > > As long as you mean "an appendix that clearly says 'these were in RFC 4306 > but are now out-of-date but are here just for reference and you want to > look at '", I'm OK with that as well. I'd actually go one better -- snapshot what's on IANA today (or the day before RFC-editor pulls the switch) with the warning you quote ('... just for reference and you want to look at '). The warning and URL is the critical part. Dan From danmcd@sun.com Mon Nov 23 17:41:35 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1024F3A6B00 for ; Mon, 23 Nov 2009 17:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ecsc3Ojf6+E for ; Mon, 23 Nov 2009 17:41:34 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 65FB73A6AF9 for ; Mon, 23 Nov 2009 17:41:34 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAO1fUko003421 for ; Tue, 24 Nov 2009 01:41:30 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTL00D00BAVX300@mail-amer.sun.com> for ipsec@ietf.org; Mon, 23 Nov 2009 18:41:30 -0700 (MST) Received: from @ ([unknown] [71.174.113.16]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTL00CT0BD4DQ80@mail-amer.sun.com> for ipsec@ietf.org; Mon, 23 Nov 2009 18:41:30 -0700 (MST) Date: Mon, 23 Nov 2009 20:41:27 -0500 From: Dan McDonald In-reply-to: <20091124013732.GD3457@mactavish> Sender: Dan.McDonald@sun.com To: ipsec@ietf.org Message-id: <20091124014127.GE3457@mactavish> Organization: Sun Microsystems, Inc. - Solaris Networking & Security References: <20091124011228.GC3457@mactavish> <20091124013732.GD3457@mactavish> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 01:41:35 -0000 On Mon, Nov 23, 2009 at 08:37:32PM -0500, Dan McDonald wrote: > The warning and URL is the critical part. "are the critical part," - uggh, mustn't press Send so quickly. Dan From paul.hoffman@vpnc.org Mon Nov 23 17:46:20 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43ED528C1C6 for ; Mon, 23 Nov 2009 17:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.971 X-Spam-Level: X-Spam-Status: No, score=-5.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NH8Ma2zmQ2kW for ; Mon, 23 Nov 2009 17:46:19 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 85C8B3A6AE9 for ; Mon, 23 Nov 2009 17:46:19 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAO1kDh1047458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 18:46:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20091124013732.GD3457@mactavish> References: <20091124011228.GC3457@mactavish> <20091124013732.GD3457@mactavish> Date: Mon, 23 Nov 2009 17:46:12 -0800 To: Dan McDonald , ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 01:46:20 -0000 At 8:37 PM -0500 11/23/09, Dan McDonald wrote: >On Mon, Nov 23, 2009 at 05:27:36PM -0800, Paul Hoffman wrote: >> >Can you move 'em to an appendix, with a permanent URL reference to the IANA >> >up-to-date versions? >> >> As long as you mean "an appendix that clearly says 'these were in RFC 4306 >> but are now out-of-date but are here just for reference and you want to >> look at '", I'm OK with that as well. > >I'd actually go one better -- snapshot what's on IANA today (or the day >before RFC-editor pulls the switch) with the warning you quote ('... just >for reference and you want to look at '). The warning and URL is the >critical part. Oh, yuck. No. I could see doing this to keep the "bis" nature of the document intact by providing the old tables, but not creating a clone of the IANA registry. I *really* don't think it is that hard for a developer to resolve a URL and read the tables there. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Mon Nov 23 18:37:54 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC3C63A6B28 for ; Mon, 23 Nov 2009 18:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6UxCwjd5bcZ for ; Mon, 23 Nov 2009 18:37:54 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id EA2B23A6B20 for ; Mon, 23 Nov 2009 18:37:53 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAO2blOQ049630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 19:37:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 23 Nov 2009 18:37:46 -0800 To: Keith Welter From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ipsec@ietf.org Subject: [IPsec] Closing #25 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 02:37:54 -0000 At 11:42 AM -0800 11/11/09, Keith Welter wrote: >A design team was convened including Dan McDonald, Tero Kivinen, Raj Singh, David Wierbowski and Keith Welter to resolve Issue #22. The design team reached agreement on the following general approach as well as specific proposed text: . . . Many, many thanks for all this work. I have now input all the text (with some wordsmithing and rearranging) in -06. However, I have changed one part: At 11:42 AM -0800 11/11/09, Keith Welter wrote: >3.10.1. Notify Message Types (Updates) >... >NOTIFY messages: error types Value >------------------------------------------------------------------- >... >TEMPORARY_FAILURE 40 >See section 2.25. > >CHILD_SA_NOT_FOUND 41 >See section 2.25. > >RESERVED TO IANA 42-8191 >... The values 40 and 41 *are already taken* in the IANA registry. I have substituted {TBA1} and {TBA2} for them in -06. (This reaffirms my desire to implement issue #123 and rip out the old tables.) --Paul Hoffman, Director --VPN Consortium From smb@cs.columbia.edu Mon Nov 23 19:20:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 658B428C1F8 for ; Mon, 23 Nov 2009 19:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUBSg+ggSA5e for ; Mon, 23 Nov 2009 19:20:35 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 9B88028C1F7 for ; Mon, 23 Nov 2009 19:20:35 -0800 (PST) Received: from [192.168.2.182] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nAO3KUJ9009386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Nov 2009 22:20:30 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: Date: Mon, 23 Nov 2009 22:20:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <61E8E1CA-708A-4D8A-8445-E33AECB07A3E@cs.columbia.edu> References: <20091124011228.GC3457@mactavish> <20091124013732.GD3457@mactavish> To: Paul Hoffman X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: ipsec@ietf.org, Dan McDonald Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 03:20:36 -0000 On Nov 23, 2009, at 8:46 PM, Paul Hoffman wrote: > I *really* don't think it is that hard for a developer to resolve a = URL and read the tables there. Leave out the table; give the URL and mention 4306. If you have two = more-or-less authoritative sources for the same information, some folks = will use one and some the other. Point to the URL as *the* source, and = say that it subsumes all values given in 4306. --Steve Bellovin, http://www.cs.columbia.edu/~smb From yaronf@checkpoint.com Mon Nov 23 22:54:43 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A1FC28C0D9 for ; Mon, 23 Nov 2009 22:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.337 X-Spam-Level: X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2jtwtIRzgE4 for ; Mon, 23 Nov 2009 22:54:42 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 41F6B28C0D7 for ; Mon, 23 Nov 2009 22:54:41 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAO6sOGo016042; Tue, 24 Nov 2009 08:54:25 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 24 Nov 2009 08:54:30 +0200 From: Yaron Sheffer To: Steven Bellovin , Paul Hoffman Date: Tue, 24 Nov 2009 08:54:29 +0200 Thread-Topic: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis Thread-Index: AcpstRvxtihCThtNSGuXQrOb3VlAVAAHWWMA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B366@il-ex01.ad.checkpoint.com> References: <20091124011228.GC3457@mactavish> <20091124013732.GD3457@mactavish> <61E8E1CA-708A-4D8A-8445-E33AECB07A3E@cs.columbia.edu> In-Reply-To: <61E8E1CA-708A-4D8A-8445-E33AECB07A3E@cs.columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Dan McDonald Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 06:54:43 -0000 Hi Paul, Please add to Issue #123 a list of the affected tables. For example, I woul= dn't imagine the list of notification types moving away, even though it's a= lready been extended by IANA. Similarly for the stuff in Sec. 3.6, which is= strongly related to descriptive text. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Steven Bellovin > Sent: Tuesday, November 24, 2009 5:20 > To: Paul Hoffman > Cc: ipsec@ietf.org; Dan McDonald > Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from > IKEv2bis >=20 >=20 > On Nov 23, 2009, at 8:46 PM, Paul Hoffman wrote: > > I *really* don't think it is that hard for a developer to resolve a URL > and read the tables there. >=20 >=20 > Leave out the table; give the URL and mention 4306. If you have two more= - > or-less authoritative sources for the same information, some folks will > use one and some the other. Point to the URL as *the* source, and say > that it subsumes all values given in 4306. >=20 > --Steve Bellovin, http://www.cs.columbia.edu/~smb >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From yaronf@checkpoint.com Mon Nov 23 22:58:07 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E206B3A6403 for ; Mon, 23 Nov 2009 22:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocusTJq245nQ for ; Mon, 23 Nov 2009 22:58:07 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 862AD28C1F7 for ; Mon, 23 Nov 2009 22:58:06 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAO6w0Go016822; Tue, 24 Nov 2009 08:58:01 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 24 Nov 2009 08:58:06 +0200 From: Yaron Sheffer To: Paul Hoffman , Keith Welter Date: Tue, 24 Nov 2009 08:58:05 +0200 Thread-Topic: Closing #22 (was: RE: [IPsec] Closing #25) Thread-Index: AcpsryUDvz89kYtxSPGQdoDvWl/W0gAJAKYw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B367@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: [IPsec] Closing #22 (was: RE: Closing #25) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 06:58:08 -0000 And this is exactly the table that I claim needs to remain in the spec. A l= ist of errors - even if partial! - is essential to understanding a protocol= . Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Tuesday, November 24, 2009 4:38 > To: Keith Welter > Cc: ipsec@ietf.org > Subject: [IPsec] Closing #25 >=20 > At 11:42 AM -0800 11/11/09, Keith Welter wrote: > >A design team was convened including Dan McDonald, Tero Kivinen, Raj > Singh, David Wierbowski and Keith Welter to resolve Issue #22. The desig= n > team reached agreement on the following general approach as well as > specific proposed text: . . . >=20 > Many, many thanks for all this work. I have now input all the text (with > some wordsmithing and rearranging) in -06. However, I have changed one > part: >=20 > At 11:42 AM -0800 11/11/09, Keith Welter wrote: > >3.10.1. Notify Message Types (Updates) > >... > >NOTIFY messages: error types Value > >------------------------------------------------------------------- > >... > >TEMPORARY_FAILURE 40 > >See section 2.25. > > > >CHILD_SA_NOT_FOUND 41 > >See section 2.25. > > > >RESERVED TO IANA 42-8191 > >... >=20 > The values 40 and 41 *are already taken* in the IANA registry. I have > substituted {TBA1} and {TBA2} for them in -06. (This reaffirms my desire > to implement issue #123 and rip out the old tables.) >=20 > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From Pasi.Eronen@nokia.com Tue Nov 24 04:24:13 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47AE3A6A32 for ; Tue, 24 Nov 2009 04:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aD3b9TYjniN1 for ; Tue, 24 Nov 2009 04:24:13 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 84F143A69C0 for ; Tue, 24 Nov 2009 04:24:12 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAOCNdPW013132; Tue, 24 Nov 2009 14:24:04 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 14:24:03 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 14:23:54 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 14:23:50 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 24 Nov 2009 13:23:49 +0100 From: To: , Date: Tue, 24 Nov 2009 13:23:48 +0100 Thread-Topic: [IPsec] #121: Rekeying IKE SAs: KEr errors and PRF question Thread-Index: Acpsm8sXtHRhGMW6TEqZPZ3rsv2gxQAY5pOg Message-ID: <808FD6E27AD4884E94820BC333B2DB774F310BBF5B@NOK-EUMSG-01.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Nov 2009 12:23:50.0316 (UTC) FILETIME=[FA7946C0:01CA6D00] X-Nokia-AV: Clean Subject: Re: [IPsec] #121: Rekeying IKE SAs: KEr errors and PRF question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 12:24:13 -0000 Paul Hoffman wrote: > We earlier agreed in issue #50 to make the KEr in Section 1.3.2 > (Rekeying IKE SAs with the CREATE_CHILD_SA Exchange) mandatory: > <-- HDR, SK {SA, Nr, KEr} > Note that this is not in the current draft, but will be in the next > one. >=20 > So, what happens if the responder does not include a KEr, following the > syntax in RFC 4306? =20 This would happen only if the responder's SA payload has value "NONE" for transform type 4, right? But the text in Section 2.18 already prohibits this... > Does the process revert back to using only the SK_d and the new > nonces, or does the responder reject the request and indicate its > preferred DH group in the INVALID_KE_PAYLOAD notification payload > (section 1.3)? The latter seems much more likely, given the text in > 2.18. If so, we should say so explicitly. >=20 > Section 2.18 also states that in the case of the old and new IKE SA > selecting different PRFs, that the rekeying exchange (for SKEYSEED) is > done using the *old* IKE SA's PRF. What happens after that? The end > of section 2.18 says that SK_d, etc are computed from SKEYSEED as > specified in section 2.14. If the PRF changed, which PRF is used for > the prf+ calculations, the old PRF or the new PRF? SK_* are computed from SKEYSEED using the new IKE SA's PRF. Best regards, Pasi From Pasi.Eronen@nokia.com Tue Nov 24 04:32:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72A928C118 for ; Tue, 24 Nov 2009 04:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hd3dCrL0MXCT for ; Tue, 24 Nov 2009 04:32:51 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 7315F3A680D for ; Tue, 24 Nov 2009 04:32:51 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAOCWW05016887; Tue, 24 Nov 2009 14:32:44 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 14:32:09 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 14:32:04 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 14:32:00 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 24 Nov 2009 13:31:59 +0100 From: To: , Date: Tue, 24 Nov 2009 13:31:58 +0100 Thread-Topic: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis Thread-Index: AcpsnxYA1I/5ktGTS8G6trg78ElkEQAYj5QQ Message-ID: <808FD6E27AD4884E94820BC333B2DB774F310BBF70@NOK-EUMSG-01.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Nov 2009 12:32:00.0422 (UTC) FILETIME=[1E998460:01CA6D02] X-Nokia-AV: Clean Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 12:32:52 -0000 Typically IETF specs don't require someone implementing RFC NNNN to actually find and read the IANA registry -- all the needed numbers are in the RFC. (The IANA registry is just an IETF process tool for making=20 sure the same number doesn't get used for multiple purposes, not part of the actual protocol specification.) Perhaps the "reserved to IANA: 12-200" etc. lines are slightly confusing, and we could omit them (and say something like "this document specifies the meaning of these values; to find what values are specified in other documents, go look at the IANA registry") Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of ext Paul Hoffman > Sent: 24 November, 2009 02:37 > To: IPsecme WG > Subject: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis >=20 > This has flummoxed a few reviewers. Tables such as those in section > 3.3.2 are already out of date because things have been added since RFC > 4306. I propose that we remove all these tables from IKEv2bis, and add > notes pointing to the current IANA registries. I cannot see how doing > this lookup will hurt developers: in fact, it forces them to actually > look at the up-to-date tables. I can see how we might want to leave the > tables in, but it really is confusing. >=20 > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Tue Nov 24 05:54:28 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81C8A3A6A3E for ; Tue, 24 Nov 2009 05:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xMp4jRYO2Rb for ; Tue, 24 Nov 2009 05:54:27 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 53DBA3A6784 for ; Tue, 24 Nov 2009 05:54:26 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAODsIVt004048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 15:54:18 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAODsGuS028870; Tue, 24 Nov 2009 15:54:16 +0200 (EET) 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: <19211.58760.146418.200791@fireball.kivinen.iki.fi> Date: Tue, 24 Nov 2009 15:54:16 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 17 min Cc: IPsecme WG Subject: [IPsec] #121: Rekeying IKE SAs: KEr errors and PRF question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 13:54:28 -0000 Paul Hoffman writes: > We earlier agreed in issue #50 to make the KEr in Section 1.3.2 > (Rekeying IKE SAs with the CREATE_CHILD_SA Exchange) mandatory: > <-- HDR, SK {SA, Nr, KEr} > Note that this is not in the current draft, but will be in the next one. > > So, what happens if the responder does not include a KEr, following > the syntax in RFC 4306? Does the process revert back to using only > the SK_d and the new nonces, or does the responder reject the > request and indicate its preferred DH group in the > INVALID_KE_PAYLOAD notification payload (section 1.3)? The latter > seems much more likely, given the text in 2.18. If so, we should say > so explicitly. Note, that this can only happen if initiator allowed responder to not give KEr. Initiator tells the responder whether it requires Diffie-Hellman by listing Diffie-Hellman groups in its SA payload. If it does not include group 0 (NONE) then responder does not have option to send KEr (both for RFC4306 and IKEv2bis implementations). RFC4306 implementations are allowed to include the Diffie-Hellman group 0 (NONE), but IKEv2bis implementations are not allowed to include it anymore. This means that if RFC4306 implementation talks as initiator to the IKEv2bis responder implementation and RFC4306 implementation selects Diffie-Hellman group 0, and does not include KEi then IKEv2bis implementation will return INVALID_KE_PAYLOAD and request RFC4306 implementation to select some other group (provided the RFC4306 implementation listed any acceptable group in its SA payload). If they cannot find group which is acceptable for both then the negotiation will fail with NO_PROPOSAL_CHOSEN. On the other hand if IKEv2bis implementation talks as initiator to the RFC4306 implementation, then IKEv2bis implementation will include KEi, and MUST NOT include group 0 (NONE) in its SA payload, thus RFC4306 implementation is not allowed to select group 0, meaning it must return proper KEr, or NO_PROPOSAL_CHOSEN if none of the groups were acceptable (or INVALID_KE_PAYLOAD if group selected by KEi was not acceptable, but some other group in SA payload is). This means that if either end is IKEv2bis implementation, there cannot be situation where KEr is ignored, and where we would not have g^ir (new) for SKEYSEED calculation. I do not think we need extra text for this, as if implementors follow the currect text in section 2.18 which says IKEv2bis implementations MUST NOT propose the value "NONE, and MUST NOT accept such proposal, then there is no problem. > Section 2.18 also states that in the case of the old and new IKE SA > selecting different PRFs, that the rekeying exchange (for SKEYSEED) > is done using the *old* IKE SA's PRF. What happens after that? The > end of section 2.18 says that SK_d, etc are computed from SKEYSEED > as specified in section 2.14. If the PRF changed, which PRF is used > for the prf+ calculations, the old PRF or the new PRF? I would interpret "because the rekeying exchange belongs to the old IKE SA, it is the old IKE SA's PRF that is used", to cover also the SK_d, SK_ai, etc generation and also prf+ uses. First thing that uses new PRF, is when new IKE SA is used to generate KEYMAT, or SKEYSEED for next IKE SA rekey. But I agree this is not very clear, and could be clarified. -- kivinen@iki.fi From kivinen@iki.fi Tue Nov 24 06:08:21 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90ED73A6784 for ; Tue, 24 Nov 2009 06:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEwgrlskcW3V for ; Tue, 24 Nov 2009 06:08:20 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id EF3EC3A67F2 for ; Tue, 24 Nov 2009 06:08:19 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAOE8EQu001896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 16:08:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAOE8DMI002902; Tue, 24 Nov 2009 16:08:13 +0200 (EET) 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: <19211.59597.904754.490768@fireball.kivinen.iki.fi> Date: Tue, 24 Nov 2009 16:08:13 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 12 min Cc: IPsecme WG Subject: [IPsec] #122: Integrity proposals with combined algorithms X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:08:21 -0000 Paul Hoffman writes: > The 4th paragraph of section 3.3 says "If an algorithm that combines > encryption and integrity protection is proposed, it MUST be proposed > as an encryption algorithm and an integrity protection algorithm > MUST NOT be proposed." This means that an integrity protection > algorithm can only be proposed with a Transform ID equal to NONE, > given that a few paragraphs above, it says: "Combined-mode ciphers > include both integrity and encryption in a single encryption > algorithm, and are not allowed to be offered with a separate > integrity algorithm other than "none"." We should thus make this > clear in the 4th paragraph. I interpreted the text "integrity protection algorithm MUST NOT be proposed" to mean that there is no transform type 3 (Integrity algorithm) at all in the proposal, i.e. it is left out completely. Accepting proposal having transform type 3 (Integrity algorithm) with value 0 (none) is ok, but I think we should prefer for not including it at all, as it makes packets shorter. I agree that the text earlier would indicate that you send "NONE", but RFC5282 says: This document updates [RFC4306] to require that when an authenticated encryption algorithm is selected as the encryption algorithm for any SA (IKE or ESP), an integrity algorithm MUST NOT be selected for that SA. This document further updates [RFC4306] to require that if all of the encryption algorithms in any proposal are authenticated encryption algorithms, then the proposal MUST NOT propose any integrity transforms. where I read the "MUST NOT propose any ingerity tranforms" to also include integrity transform for value 0 (NONE). So I would change the section 3.3 text where it says Combined-mode ciphers include both integrity and encryption in a single encryption algorithm, and are not allowed to be offered with a separate integrity algorithm other than "none". to say Combined-mode ciphers include both integrity and encryption in a single encryption algorithm, and are not allowed to be offered with a separate integrity algorithm. to align with the RFC5282. Also note that the [AEAD] reference to the RFC5116 in IKEv2bis is wrong, it should point to the RFC5282, which defines how AEAD modes are used in IKE (all those references refer to IKEv2 used of AEAD). > HOWEVER, in section 3.3.2, in the table for transform types, it says: > Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP > (*) Negotiating an integrity algorithm is mandatory for the > Encrypted payload format specified in this document. For example, > [AEAD] specifies additional formats based on authenticated > encryption, in which a separate integrity algorithm is not > negotiated. > The second sentence seems wrong. Proposed rewording: > For example, > [AEAD] specifies additional formats based on authenticated > encryption, in which the integrity algorithm is an inherent > part of the combined algorithm; in this case, the > integrity algorithm is specified as "none". When you fix the reference from RFC5116 to RFC5282, then you notice that NONE is not allowed, thus the original text was correct and your new text is incorrect, as NONE cannot be proposed or accepted. -- kivinen@iki.fi From kivinen@iki.fi Tue Nov 24 06:17:19 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7163A67D4 for ; Tue, 24 Nov 2009 06:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+XgsC9gLd5o for ; Tue, 24 Nov 2009 06:17:18 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C11283A63C9 for ; Tue, 24 Nov 2009 06:17:17 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAOEHCb4003018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 16:17:12 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAOEHBCf002630; Tue, 24 Nov 2009 16:17:11 +0200 (EET) 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: <19211.60135.834509.954897@fireball.kivinen.iki.fi> Date: Tue, 24 Nov 2009 16:17:11 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 8 min Cc: IPsecme WG Subject: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:17:19 -0000 Paul Hoffman writes: > This has flummoxed a few reviewers. Tables such as those in section > 3.3.2 are already out of date because things have been added since > RFC 4306. I propose that we remove all these tables from IKEv2bis, > and add notes pointing to the current IANA registries. I cannot see > how doing this lookup will hurt developers: in fact, it forces them > to actually look at the up-to-date tables. I can see how we might > want to leave the tables in, but it really is confusing. I would be in favor of removing the tables which are updated frequently, but I think most of the tables should still stay in the IKEv2bis. For example I think IKEv2 exchange types, Next Payload Types, Protocol ID, Transform type values etc should stay, but for example tables like Transform type 1 (Encryption Algorithm) could point to the IANA registry. I.e if table is integral part of the protocol, then it should stay in the IKEv2bis document, but if it is something like listing of crypto algorithm etc, then it can be changed to point to the IANA registry. Mostly that means that if the IANA registry has some other RFC(s) as reference for the values in the registry (ENCR_3DES points ot RFC2451 etc, PRF_HMAC_MD5 points to RFC2104) then it it is useful to put references to the IANA registry. On the other hand if only references in the IANA registry is back to the RFC4306 (or IKEv2bis document in future), then its bit pointless to ask people to go to the iana registry to see that they should read this document they are reading to get more information :-) For examples of such registries are Next Payload Type, Transform Type Values, IKEv2 Transform Attribute Types, IKEv2 Identification Payload ID Types, IKEv2 Certificate Encodings... -- kivinen@iki.fi From kivinen@iki.fi Tue Nov 24 06:32:22 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF223A69A2 for ; Tue, 24 Nov 2009 06:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNJlOAtPj+BR for ; Tue, 24 Nov 2009 06:32:21 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id CBD363A6861 for ; Tue, 24 Nov 2009 06:32:20 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAOEWCMO002792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Nov 2009 16:32:12 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAOEWBK1003097; Tue, 24 Nov 2009 16:32:11 +0200 (EET) Date: Tue, 24 Nov 2009 16:32:11 +0200 (EET) Resent-From: kivinen@iki.fi Message-Id: <200911241432.nAOEWBK1003097@fireball.kivinen.iki.fi> X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f Resent-Message-ID: <19211.61035.901278.727206@fireball.kivinen.iki.fi> Resent-Date: Tue, 24 Nov 2009 16:32:11 +0200 Resent-To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Michael Richardson In-Reply-To: <6762.1258985518@marajade.sandelman.ca> References: <10247.1257346966@marajade.sandelman.ca> <19210.35881.683962.654367@fireball.kivinen.iki.fi> <6762.1258985518@marajade.sandelman.ca> X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: ipsec@ietf.org Subject: Re: [IPsec] comments on esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:32:22 -0000 Michael Richardson writes: > >> It is? I'll bet 95% of actual transport mode IPsec has an L2TP > >> layer inside. > > Tero> Inside one enterprise? I do not think so. I guess most of the > Tero> IPsec traffic is VPN style tunnel mode, but as that is going > Tero> over untrusted networks (there is word private there :) they > Tero> are encrypted, thus outside the scope of this draft. > > I see the "inside one organization" part now. > I was thinking that much of the transport-mode traffic crossing an > enterprises' border is likely on-site consultants, who are doing remote > access back to their HQ. Yes, but those consultants do use encryption when connecting to the enterprise network. Most likely their encrypted traffic is terminated on the security gateway on the enterprise network border, and then it might go forward without encryption (it might have end to end ESP-NULL inside the encrypted tunnel mode ESP when it arrives to the sgw, and sgw might strip encrypted tunnel mode ESP out and leave transport mode ESP-NULL inside). > Tero> I added a note there saying: > > Tero> Note, that most of the current uses of the IPsec are not > Tero> host to host traffic inside one organization, but for the > Tero> intended use cases for the heuristics this will most likely be > Tero> the case. Also tunnel mode case is much easier to solve than > Tero> transport mode as it is much easier to detect the IP header > Tero> inside the ESP-NULL packet. > > I think that's 5%, with 95% being above, but maybe I don't know why > this stateful inspection device is "inside" It is "inside" as I do not belive anybody belives they could leave encryption off for traffic that goes outside of the enterprise... Remember that all of this is always talking about ESP-NULL traffic only. > > >> I agree with the analysis of section 3, in particular the > >> explanation of how hardware can be programmed to statefully match > >> the ESP-NULL flows. It might be worth noting that NAT-T ESP-NULL > >> flows *ALREADY* have a 5-tuple (likely unique) marker, and that > >> if the inspector is also a NA(P)T, that it already is keeping the > >> right state. > > Tero> Do you have any exact wordings where to add what. > > I think that there is later on text about this, and maybe just a > forward reference is enough. > "As described in section 7, UDP encapsulated ESP traffic > may also have have NAPT applied to it, and so there is already > a 5-tuple state in the stateful inspection gateway Ok, added that to the end of section 3. " > Tero> Flow > Tero> TCP/UDP or IPsec flow is a stream of packets part of the > Tero> same TCP/ UDP or IPsec stream, i.e. TCP flow is a stream of > Tero> packets having same 5 tuple (source and destination ip and > Tero> port, and TCP protocol). > > okay, I would run this by the transport and Internet area folks, > because I think this disagrees with their definition of flow. How does that disagree in their definition of flow? On the other hand it really does not matter whether it disagrees or not, this is what we mean by flow in this document, so as we define it there, it should be clear for people what we mean by flow. -- kivinen@iki.fi From smoonen@us.ibm.com Tue Nov 24 06:34:49 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AC5C3A6A6C; Tue, 24 Nov 2009 06:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dH+eVF0B9wY1; Tue, 24 Nov 2009 06:34:48 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id DFBD43A6861; Tue, 24 Nov 2009 06:34:47 -0800 (PST) Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e9.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id nAOET7F3020646; Tue, 24 Nov 2009 09:29:07 -0500 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nAOEYgDd105922; Tue, 24 Nov 2009 09:34:42 -0500 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nAOEaMIK018155; Tue, 24 Nov 2009 07:36:22 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nAOEaL8b018146; Tue, 24 Nov 2009 07:36:22 -0700 In-Reply-To: <19211.58760.146418.200791@fireball.kivinen.iki.fi> References: <19211.58760.146418.200791@fireball.kivinen.iki.fi> MIME-Version: 1.0 X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/24/2009 09:29:09 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/24/2009 09:29:09 AM, Serialize complete at 11/24/2009 09:29:09 AM, S/MIME Sign failed at 11/24/2009 09:29:09 AM: The cryptographic key was not found, S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/24/2009 09:29:21 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/24/2009 09:29:21 AM, Serialize complete at 11/24/2009 09:29:21 AM, S/MIME Sign failed at 11/24/2009 09:29:21 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 11/24/2009 07:34:38, Serialize complete at 11/24/2009 07:34:38 To: Tero Kivinen X-KeepSent: 014949C9:2D2A37A6-85257678:004F4391; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen Message-ID: Date: Tue, 24 Nov 2009 09:34:37 -0500 Content-Type: multipart/alternative; boundary="=_alternative 004F976385257678_=" Cc: IPsecme WG , ipsec-bounces@ietf.org, Paul Hoffman Subject: Re: [IPsec] #121: Rekeying IKE SAs: KEr errors and PRF question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:34:49 -0000 This is a multipart message in MIME format. --=_alternative 004F976385257678_= Content-Type: text/plain; charset="US-ASCII" > > Section 2.18 also states that in the case of the old and new IKE SA > > selecting different PRFs, that the rekeying exchange (for SKEYSEED) > > is done using the *old* IKE SA's PRF. What happens after that? The > > end of section 2.18 says that SK_d, etc are computed from SKEYSEED > > as specified in section 2.14. If the PRF changed, which PRF is used > > for the prf+ calculations, the old PRF or the new PRF? > > I would interpret "because the rekeying exchange belongs to the old > IKE SA, it is the old IKE SA's PRF that is used", to cover also the > SK_d, SK_ai, etc generation and also prf+ uses. First thing that uses > new PRF, is when new IKE SA is used to generate KEYMAT, or SKEYSEED > for next IKE SA rekey. But I agree this is not very clear, and could > be clarified. We've interpreted it as follows: 1) the old IKE SA's PRF is used to produce SKEYSEED, but 2) the new IKE SA's PRF is used to produce SK_x. We've successfully interoperated with a number of other platforms that seem to have made the same interpretation. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Paul Hoffman Cc: IPsecme WG Date: 11/24/2009 08:55 AM Subject: [IPsec] #121: Rekeying IKE SAs: KEr errors and PRF question Paul Hoffman writes: > We earlier agreed in issue #50 to make the KEr in Section 1.3.2 > (Rekeying IKE SAs with the CREATE_CHILD_SA Exchange) mandatory: > <-- HDR, SK {SA, Nr, KEr} > Note that this is not in the current draft, but will be in the next one. > > So, what happens if the responder does not include a KEr, following > the syntax in RFC 4306? Does the process revert back to using only > the SK_d and the new nonces, or does the responder reject the > request and indicate its preferred DH group in the > INVALID_KE_PAYLOAD notification payload (section 1.3)? The latter > seems much more likely, given the text in 2.18. If so, we should say > so explicitly. Note, that this can only happen if initiator allowed responder to not give KEr. Initiator tells the responder whether it requires Diffie-Hellman by listing Diffie-Hellman groups in its SA payload. If it does not include group 0 (NONE) then responder does not have option to send KEr (both for RFC4306 and IKEv2bis implementations). RFC4306 implementations are allowed to include the Diffie-Hellman group 0 (NONE), but IKEv2bis implementations are not allowed to include it anymore. This means that if RFC4306 implementation talks as initiator to the IKEv2bis responder implementation and RFC4306 implementation selects Diffie-Hellman group 0, and does not include KEi then IKEv2bis implementation will return INVALID_KE_PAYLOAD and request RFC4306 implementation to select some other group (provided the RFC4306 implementation listed any acceptable group in its SA payload). If they cannot find group which is acceptable for both then the negotiation will fail with NO_PROPOSAL_CHOSEN. On the other hand if IKEv2bis implementation talks as initiator to the RFC4306 implementation, then IKEv2bis implementation will include KEi, and MUST NOT include group 0 (NONE) in its SA payload, thus RFC4306 implementation is not allowed to select group 0, meaning it must return proper KEr, or NO_PROPOSAL_CHOSEN if none of the groups were acceptable (or INVALID_KE_PAYLOAD if group selected by KEi was not acceptable, but some other group in SA payload is). This means that if either end is IKEv2bis implementation, there cannot be situation where KEr is ignored, and where we would not have g^ir (new) for SKEYSEED calculation. I do not think we need extra text for this, as if implementors follow the currect text in section 2.18 which says IKEv2bis implementations MUST NOT propose the value "NONE, and MUST NOT accept such proposal, then there is no problem. > Section 2.18 also states that in the case of the old and new IKE SA > selecting different PRFs, that the rekeying exchange (for SKEYSEED) > is done using the *old* IKE SA's PRF. What happens after that? The > end of section 2.18 says that SK_d, etc are computed from SKEYSEED > as specified in section 2.14. If the PRF changed, which PRF is used > for the prf+ calculations, the old PRF or the new PRF? I would interpret "because the rekeying exchange belongs to the old IKE SA, it is the old IKE SA's PRF that is used", to cover also the SK_d, SK_ai, etc generation and also prf+ uses. First thing that uses new PRF, is when new IKE SA is used to generate KEYMAT, or SKEYSEED for next IKE SA rekey. But I agree this is not very clear, and could be clarified. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 004F976385257678_= Content-Type: text/html; charset="US-ASCII"
> > Section 2.18 also states that in the case of the old and new IKE SA
> > selecting different PRFs, that the rekeying exchange (for SKEYSEED)
> > is done using the *old* IKE SA's PRF.  What happens after that?  The
> > end of section 2.18 says that SK_d, etc are computed from SKEYSEED
> > as specified in section 2.14.  If the PRF changed, which PRF is used
> > for the prf+ calculations, the old PRF or the new PRF?
>
> I would interpret "because the rekeying exchange belongs to the old
> IKE SA, it is the old IKE SA's PRF that is used", to cover also the
> SK_d, SK_ai, etc generation and also prf+ uses. First thing that uses
> new PRF, is when new IKE SA is used to generate KEYMAT, or SKEYSEED
> for next IKE SA rekey. But I agree this is not very clear, and could
> be clarified.

We've interpreted it as follows: 1) the old IKE SA's PRF is used to produce SKEYSEED, but 2) the new IKE SA's PRF is used to produce SK_x.

We've successfully interoperated with a number of other platforms that seem to have made the same interpretation.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Tero Kivinen <kivinen@iki.fi>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Cc: IPsecme WG <ipsec@ietf.org>
Date: 11/24/2009 08:55 AM
Subject: [IPsec]  #121: Rekeying IKE SAs: KEr errors and PRF question




Paul Hoffman writes:
> We earlier agreed in issue #50 to make the KEr in Section 1.3.2
> (Rekeying IKE SAs with the CREATE_CHILD_SA Exchange) mandatory:
>                              <--  HDR, SK {SA, Nr, KEr}
> Note that this is not in the current draft, but will be in the next one.
>
> So, what happens if the responder does not include a KEr, following
> the syntax in RFC 4306?  Does the process revert back to using only
> the SK_d and the new nonces, or does the responder reject the
> request and indicate its preferred DH group in the
> INVALID_KE_PAYLOAD notification payload (section 1.3)? The latter
> seems much more likely, given the text in 2.18. If so, we should say
> so explicitly.

Note, that this can only happen if initiator allowed responder to not
give KEr. Initiator tells the responder whether it requires
Diffie-Hellman by listing Diffie-Hellman groups in its SA payload. If
it does not include group 0 (NONE) then responder does not have option
to send KEr (both for RFC4306 and IKEv2bis implementations).

RFC4306 implementations are allowed to include the Diffie-Hellman
group 0 (NONE), but IKEv2bis implementations are not allowed to
include it anymore.

This means that if RFC4306 implementation talks as initiator to the
IKEv2bis responder implementation and RFC4306 implementation selects
Diffie-Hellman group 0, and does not include KEi then IKEv2bis
implementation will return INVALID_KE_PAYLOAD and request RFC4306
implementation to select some other group (provided the RFC4306
implementation listed any acceptable group in its SA payload). If they
cannot find group which is acceptable for both then the negotiation
will fail with NO_PROPOSAL_CHOSEN.

On the other hand if IKEv2bis implementation talks as initiator to the
RFC4306 implementation, then IKEv2bis implementation will include KEi,
and MUST NOT include group 0 (NONE) in its SA payload, thus RFC4306
implementation is not allowed to select group 0, meaning it must
return proper KEr, or NO_PROPOSAL_CHOSEN if none of the groups were
acceptable (or INVALID_KE_PAYLOAD if group selected by KEi was not
acceptable, but some other group in SA payload is).

This means that if either end is IKEv2bis implementation, there cannot
be situation where KEr is ignored, and where we would not have g^ir
(new) for SKEYSEED calculation.

I do not think we need extra text for this, as if implementors follow
the currect text in section 2.18 which says IKEv2bis implementations
MUST NOT propose the value "NONE, and MUST NOT accept such proposal,
then there is no problem.

> Section 2.18 also states that in the case of the old and new IKE SA
> selecting different PRFs, that the rekeying exchange (for SKEYSEED)
> is done using the *old* IKE SA's PRF.  What happens after that?  The
> end of section 2.18 says that SK_d, etc are computed from SKEYSEED
> as specified in section 2.14.  If the PRF changed, which PRF is used
> for the prf+ calculations, the old PRF or the new PRF?

I would interpret "because the rekeying exchange belongs to the old
IKE SA, it is the old IKE SA's PRF that is used", to cover also the
SK_d, SK_ai, etc generation and also prf+ uses. First thing that uses
new PRF, is when new IKE SA is used to generate KEYMAT, or SKEYSEED
for next IKE SA rekey. But I agree this is not very clear, and could
be clarified.
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 004F976385257678_=-- From kivinen@iki.fi Tue Nov 24 06:50:15 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6F43A6A60; Tue, 24 Nov 2009 06:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9iIvAOPb8Wm; Tue, 24 Nov 2009 06:50:14 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 085443A67F4; Tue, 24 Nov 2009 06:50:13 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAOEo8EX003865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 16:50:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAOEo7AO004508; Tue, 24 Nov 2009 16:50:07 +0200 (EET) 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: <19211.62111.964182.719403@fireball.kivinen.iki.fi> Date: Tue, 24 Nov 2009 16:50:07 +0200 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <19211.58760.146418.200791@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 5 min Cc: IPsecme WG , ipsec-bounces@ietf.org, Paul Hoffman Subject: Re: [IPsec] #121: Rekeying IKE SAs: KEr errors and PRF question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:50:15 -0000 Scott C Moonen writes: > We've interpreted it as follows: 1) the old IKE SA's PRF is used to > produce SKEYSEED, but 2) the new IKE SA's PRF is used to produce SK_x. Hmm... when reading my code, it seems I do the same, but when I read the text I interpreted it differently, so I think we need some clarification text there... -- kivinen@iki.fi From paul.hoffman@vpnc.org Tue Nov 24 07:44:01 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053353A6A8D for ; Tue, 24 Nov 2009 07:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.981 X-Spam-Level: X-Spam-Status: No, score=-5.981 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwTo5s-f4NIV for ; Tue, 24 Nov 2009 07:44:00 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 4E7613A6A80 for ; Tue, 24 Nov 2009 07:44:00 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAOFhiR6093150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 08:43:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B367@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF888B367@il-ex01.ad.checkpoint.com> Date: Tue, 24 Nov 2009 07:43:42 -0800 To: Yaron Sheffer From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Closing #22 (was: RE: Closing #25) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 15:44:01 -0000 At 8:58 AM +0200 11/24/09, Yaron Sheffer wrote: >And this is exactly the table that I claim needs to remain in the spec. A list of errors - even if partial! - is essential to understanding a protocol. The table is fine: as proven by the fact that none of many authors of this new text, the numbers are not. --Paul Hoffman, Director --VPN Consortium From kent@bbn.com Tue Nov 24 08:40:10 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED033A68F9 for ; Tue, 24 Nov 2009 08:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmYWeyZqjDBT for ; Tue, 24 Nov 2009 08:40:09 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 3161928C106 for ; Tue, 24 Nov 2009 08:40:08 -0800 (PST) Received: from dhcp89-089-105.bbn.com ([128.89.89.105]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NCyQt-0001OG-CM; Tue, 24 Nov 2009 11:40:03 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <19200.8786.266973.313959@fireball.kivinen.iki.fi> <19201.20208.563706.519993@fireball.kivinen.iki.fi> Date: Tue, 24 Nov 2009 11:40:01 -0500 To: Jack Kohn From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 16:40:10 -0000 >... > > - it fails to characterize the range of protocols for which you >> believe this argument applies, > >http://www.ietf.org/mail-archive/web/ipsec/current/msg05070.html > >This is one example, we could think of some more. This is only one example, and I think it is not "mainstream", so more examples would be helpful. > > > > -it fails to explain how WESP is relevant, since a receiver has the > >This has already been discussed in this email thread earlier. Not a very specific reference :-(. > > ability to process encrypted packets. WESP is a protocol that has been >> promoted as designed to aid middle boxes, not end systems > >Border Gateway Protocol (BGP) (http://www.ietf.org/rfc/rfc4271.txt) >was originally designed to work as an Exterior Gateway Protocol (EGP). >Today besides working as an EGP it is used in myriad other >applications, from discovering nodes in a VPN to distributing advisory >messages to remote network operators. So, i dont see a reason why we >should restrict ourselves to the applications for which a protocol can >be used .. I would NEVER use BGP as a good example of a protocol that has been extended to cover a broader range of contexts, if security is the focus of the discussion. Let me try to recapitulate the context of our discussion, since I have had trouble following the thread: - the principle example offered is OSPFv3 use of IPsec - OSPFv3 relies on both unicast and multicast SAs - in either case, a router receiving IPsec-protected OSPFv3 traffic will have an SAD entry for the traffic, which means that the router will know that the traffic will be protected via AH or ESP. if ESP is employed, a router receiving traffic will know ESP-NULL is used. - RFC 4552 mandates support for using different SAs for DSCP-marked traffic - RFC 4552 calls for manual keying for both unicast and multicast SAs, and states that a receiver is not checking sequence numbers. In a given OSPF context (e.g., an AS), all the routers are operated by the same administrative entity (based on the definition of an AS). If the AS in which OSPF is being employed chooses to use ESP-NULL, all the routers can be configured to require this, as part of local SPD management. Why do we need to use WESP in this context? The current argument you provided was that this was an issue for a router receiving OSPF traffic, not a middlebox issue. But the router knows that the traffic will be ESP-NULL, and knows the algorithm employed, so it should be able to examine this traffic easily. If the router wants to process traffic out-of-order, after examination, that too is easy, since there is no receiver sequence number checking, so processing the rest of the traffic (potentially with gaps) will not be a problem from an IPsec perspective. I went back and analyzed the thread to see how we got to this point. In his message of 11/16, Manav said: >And the reason why you might want to use WESP is to prioritize >certain protocol packets over the others, as is normally done for v4 >control packets (e.g. OSPFv3 HELLOs and ACKs over other OSPFv3 >packets) Tero question this assertion, citing packet ordering concerns, and Manav provided the following cryptic comment: >This is an implementation specific optimization that has already >been solved in multiple implementations. That caused me to ask what "implementation specific" optimizations meant, which resulted in your response (11/17) >Do the seq number check, and then place the packets in different >priority queues/paths based on the kind of packet it is. Proprietary >ASICs on the routers can easily do this and its one of those things >that differentiate one vendor from the other. This response seems confusing, since it discusses a sequence number check being performed in a context (OSPFv3) that calls for no such checks. Sriram noted that in a manual keying context (not just OSPFv3) sequence checking is not performed, which reaffirmed the notion that this thread went awry. Finally, Gregory said: >GML> Or perhaps, a local security policy decision to ease up on the >size of the enforcement window -- aka ease security requirements -- >in order to get more QoS enforcement capability -- aka convenience >-- ?? Which prompted my reply (10/21) noting that 4301 mandates QoS support via use of multiple SAs (which, as noted above, is also called for by 4552) and that using larger receive windows is always a local matter, not an implementation specific optimization. It was this response that you labelled as "all wrong" and said: >... The sender is sending packets with the same QoS >parameters; its the receiver thats trying to prioritize some packets >over the others. One would typically do this for the Hellos/KeepAlives >that are associated with a protocol, so that the adjacency/peering >session are not timed out. So, it does not appear that the context has changed since Manav cited OSPFv3 a week ago, yet all the arguments about sequence number checking (by IPsec) are irrelevant in this context. I have seen no good arguments about why WESP is needed here, i.e., what benefits it offers for a router receiving OSPF traffic, some of which may need to be processed out-of-order. Steve From yaronf@checkpoint.com Tue Nov 24 09:09:28 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4FB73A6847 for ; Tue, 24 Nov 2009 09:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2a35+a3Y7MS for ; Tue, 24 Nov 2009 09:09:25 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 667993A6944 for ; Tue, 24 Nov 2009 09:09:25 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAOH9JGo011035 for ; Tue, 24 Nov 2009 19:09:19 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 24 Nov 2009 19:09:25 +0200 From: Yaron Sheffer To: IPsecme WG Date: Tue, 24 Nov 2009 19:09:23 +0200 Thread-Topic: Cert-related IKEv2-bis issues Thread-Index: AcptJVrbQZECNxBHRGKbZNTYuxjneA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFDF@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFDFilex01adche_" MIME-Version: 1.0 Subject: [IPsec] Cert-related IKEv2-bis issues X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:09:28 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFDFilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Since we didn't have time to discuss these issues in Hiroshima, I'd like to= reopen them on the list. Please refer to my slides: http://www.ietf.org/proceedings/09nov/slides/ips= ecme-7.pdf for a summary of the issues. This message will be followed by a restatement of each of the 5 issues. Our intention (believe it or not) is to start WG last call on IKEv2-bis Rea= l Soon Now, but we want to have these issues closed before we do so. Thanks, Yaron --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFDFilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Since we didn’t have time to discuss these issues = in Hiroshima, I̵= 7;d like to reopen them on the list.

 

Please refer to my slides: http://= www.ietf.org/proceedings/09nov/slides/ipsecme-7.pdf for a summary of the issues.

 

This message will be followed by a restatement of each o= f the 5 issues.

 

Our intention (believe it or not) is to start WG last ca= ll on IKEv2-bis Real Soon Now, but we want to have these issues closed before = we do so.

 

Thanks,

         &n= bsp;  Yaron

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFDFilex01adche_-- From yaronf@checkpoint.com Tue Nov 24 09:10:29 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04E583A693E for ; Tue, 24 Nov 2009 09:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKiaB7MUrGs7 for ; Tue, 24 Nov 2009 09:10:28 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 871B33A689C for ; Tue, 24 Nov 2009 09:10:27 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAOH9JGq011035 for ; Tue, 24 Nov 2009 19:09:20 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 24 Nov 2009 19:09:25 +0200 From: Yaron Sheffer To: IPsecme WG Date: Tue, 24 Nov 2009 19:09:24 +0200 Thread-Topic: #117: Hash and URL interop Thread-Index: AcpY7LaHo4XNYlksQG2848du6xjjCQUOh/4Q Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE1@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA9@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA9@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE1ilex01adche_" MIME-Version: 1.0 Subject: Re: [IPsec] #117: Hash and URL interop X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:10:29 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE1ilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resending. There may be value in other URL methods, just maybe, but OTOH th= ey would confuse developers and add security issues. ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Friday, October 30, 2009 1:18 To: IPsecme WG Subject: [IPsec] #117: Hash and URL interop To improve interoperability, allow only the "http" URL method. The current = text (end of sec. 3.6) implies that any method is allowed, although HTTP MU= ST be supported. Scanned by Check Point Total Security Gateway. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE1ilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Resending. There may be value in other= URL methods, just maybe, but OTOH they would confuse developers and add securit= y issues.

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer
Sent: Friday, October 30, 20= 09 1:18
To: IPsecme WG
Subject: [IPsec] #117: Hash = and URL interop

 

To im= prove interoperability, allow only the "http" URL method. The current t= ext (end of sec. 3.6) implies that any method is allowed, although HTTP MUST be supported.



Scanned by Check Point Total Security Gateway.

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE1ilex01adche_-- From yaronf@checkpoint.com Tue Nov 24 09:10:30 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A1033A6944 for ; Tue, 24 Nov 2009 09:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWlNhx5rdTAx for ; Tue, 24 Nov 2009 09:10:29 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id B0AC43A68C4 for ; Tue, 24 Nov 2009 09:10:28 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAOH9JGr011035 for ; Tue, 24 Nov 2009 19:09:20 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 24 Nov 2009 19:09:25 +0200 From: Yaron Sheffer To: IPsecme WG Date: Tue, 24 Nov 2009 19:09:24 +0200 Thread-Topic: #118: Reference for PKCS #7 Thread-Index: AcpY7OK6EkCI/g2jQAC0C8W6KdSE8AUOiUwQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE2@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAA@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAA@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE2ilex01adche_" MIME-Version: 1.0 Subject: Re: [IPsec] #118: Reference for PKCS #7 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:10:30 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE2ilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Russ later pointed out that there are multiple RFCs defining PKCS #7. Input= s on current implementations are welcome. ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Friday, October 30, 2009 1:18 To: IPsecme WG Subject: [IPsec] #118: Reference for PKCS #7 PKCS#7 should reference RFC 2315. Scanned by Check Point Total Security Gateway. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE2ilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Russ later pointed out that there are multiple RFCs defining PKCS #7. Inputs on current implementations are welco= me.

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer
Sent: Friday, October 30, 20= 09 1:18
To: IPsecme WG
Subject: [IPsec] #118: Refer= ence for PKCS #7

 

PKCS#= 7  should reference RFC 2315.



Scanned by Check Point Total Security Gateway.

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE2ilex01adche_-- From yaronf@checkpoint.com Tue Nov 24 09:10:38 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81DC028C139 for ; Tue, 24 Nov 2009 09:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08RmwE+2vFQb for ; Tue, 24 Nov 2009 09:10:30 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id DBA7F3A693E for ; Tue, 24 Nov 2009 09:10:29 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAOH9JGt011035 for ; Tue, 24 Nov 2009 19:09:21 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 24 Nov 2009 19:09:26 +0200 From: Yaron Sheffer To: IPsecme WG Date: Tue, 24 Nov 2009 19:08:42 +0200 Thread-Topic: #120: CA indication with cert req - allowed types Thread-Index: AcpY7aER8O2EnOH0ScGN8V+2YUNFTgUOt3LQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE4@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAC@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAC@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE4ilex01adche_" MIME-Version: 1.0 Subject: Re: [IPsec] #120: CA indication with cert req - allowed types X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:10:39 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE4ilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please also see Tero's follow-up here: http://www.ietf.org/mail-archive/web= /ipsec/current/msg04990.html ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Friday, October 30, 2009 1:15 To: IPsecme WG Subject: [IPsec] #120: CA indication with cert req - allowed types Sec. 3.7 has: The contents of the "Certification Authority" field are defined only for X.= 509 certificates, which are types 4, 10, 12, and 13. Other values SHOULD NO= T be used until standards-track specifications that specify their use are p= ublished. This excludes certificate requests of type 7, i.e. for CRLs. For requesting= a specific CRL type 7 would make sense, in particular in chain situations.= Should we add it to the list of allowed types here? OTOH, this allows type 10, which is unspecified and should be removed. Scanned by Check Point Total Security Gateway. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE4ilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please also see Tero’s follow-up here: h= ttp://www.ietf.org/mail-archive/web/ipsec/current/msg04990.html

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer
Sent: Friday, October 30, 20= 09 1:15
To: IPsecme WG
Subject: [IPsec] #120: CA indication with cert req - allowed types

 

Sec. 3.7 has:

The contents of the "Certificat= ion Authority" field are defined only for X.509 certificates, which are ty= pes 4, 10, 12, and 13. Other values SHOULD NOT be used until standards-track specifications that specify their use are published.

This excludes certificate requests of type 7, i.e. for CRLs. F= or requesting a specific CRL type 7 would make sense, in particular in chain situations. Should we add it to the list of allowed types here?<= /span>

OTOH, this allows type 10, which is unspecified and should be removed.

 



Scanned by Check Point Total Security Gateway.

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE4ilex01adche_-- From yaronf@checkpoint.com Tue Nov 24 09:10:39 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A9633A6B6B for ; Tue, 24 Nov 2009 09:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VqkaQclSIiB for ; Tue, 24 Nov 2009 09:10:32 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 1647328C111 for ; Tue, 24 Nov 2009 09:10:30 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAOH9JGp011035 for ; Tue, 24 Nov 2009 19:09:20 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 24 Nov 2009 19:09:25 +0200 From: Yaron Sheffer To: IPsecme WG Date: Tue, 24 Nov 2009 19:09:24 +0200 Thread-Topic: #116: The AUTH payload signature Thread-Index: AcpY7JIWsaUaiVnDRVWi32jyvGpWeAUOPQXQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE0@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA8@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA8@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE0ilex01adche_" MIME-Version: 1.0 Subject: Re: [IPsec] #116: The AUTH payload signature X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:10:39 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE0ilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tero requested a clarification: I'm proposing to say that the certificate's= hash algorithm does not determine the AUTH hash function (which is the neg= otiated PRF). Implementations may use the certificates received from a give= n peer as a hint for selecting a mutually-understood PRF with that peer. And yes, the last sentence refers to this text: To promote interoperability, implementations that support this type SHOULD = support signatures that use SHA-1 as the hash function and SHOULD use SHA-1= as the default hash function when generating signatures. ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Friday, October 30, 2009 1:18 To: IPsecme WG Subject: [IPsec] #116: The AUTH payload signature The definition of the payload (sec. 3.8) should mention explicitly that the= payload hash algorithm is unrelated to the one used in the certificate, or= the algorithm used to sign the IKE Encrypted Payload. Moreover, the words "by default" are confusing and should be deleted. Scanned by Check Point Total Security Gateway. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE0ilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tero requested a clarification: I̵= 7;m proposing to say that the certificate’s hash algorithm does not deter= mine the AUTH hash function (which is the negotiated PRF). Implementations may u= se the certificates received from a given peer as a hint for selecting a mutually-understood PRF with that peer.

 

And yes, the last sentence refers to t= his text:

 

To promote interoperability, implement= ations that support this type SHOULD support signatures that use SHA-1 as the hash function and SHOULD use SHA-1 as the default hash function when generating signatures.

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer
Sent: Friday, October 30, 20= 09 1:18
To: IPsecme WG
Subject: [IPsec] #116: The A= UTH payload signature

 

The definition of the payload (sec. 3.8) should mention explic= itly that the payload hash algorithm is unrelated to the one used in the certificate, or the algorithm used to sign the IKE Encrypted Payload.<= /o:p>

Moreover, the words "by default" are confusing and should be deleted.

 



Scanned by Check Point Total Security Gateway.

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE0ilex01adche_-- From yaronf@checkpoint.com Tue Nov 24 09:10:40 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 315973A6B6F for ; Tue, 24 Nov 2009 09:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRL-7kL4mYq7 for ; Tue, 24 Nov 2009 09:10:35 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 0406828C129 for ; Tue, 24 Nov 2009 09:10:32 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAOH9JGs011035 for ; Tue, 24 Nov 2009 19:09:21 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 24 Nov 2009 19:09:26 +0200 From: Yaron Sheffer To: IPsecme WG Date: Tue, 24 Nov 2009 19:09:25 +0200 Thread-Topic: #119: Which certificate types can be mixed in one exchange? Thread-Index: AcpY7RujsaPOPWKnQK+8SRjY4rhHTgUOhcVA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE3@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAB@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAB@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE3ilex01adche_" MIME-Version: 1.0 Subject: Re: [IPsec] #119: Which certificate types can be mixed in one exchange? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:10:40 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE3ilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There was very limited discussion of this issue, which I see as the main re= ason why Sec. 3.6 is underspecified. If my proposal below is too restrictiv= e we can expand it somewhat but still keep the number of possible combinati= ons at a level where testing (and interoperability) is possible. David also asked whether we'd want to fold RFC 4806 (OCSP extensions to IKE= v2) into -bis. My personal opinion is No, despite the fact that it is a Pro= posed Standard. ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Friday, October 30, 2009 1:18 To: IPsecme WG Subject: [IPsec] #119: Which certificate types can be mixed in one exchange= ? Should be added to Sec. 3.6, probably as a new subsection. One Hash & URL (H&U) bundle only. Or... One Raw RSA key, or... One or more cert payloads of either type 4 or H&U (type 12) Can have one or more CRLs and/or OCSP content (RFC 4806) added to any of the above, except for Raw RSA. Scanned by Check Point Total Security Gateway. --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE3ilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There was very limited discussion of t= his issue, which I see as the main reason why Sec. 3.6 is underspecified. If my proposal below is too restrictive we can expand it somewhat but still keep = the number of possible combinations at a level where testing (and interoperabil= ity) is possible.

 

David also asked whether we’d wa= nt to fold RFC 4806 (OCSP extensions to IKEv2) into –bis. My personal opinion is No, despite the fact that it is a Proposed Standard.<= /span>

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer
Sent: Friday, October 30, 20= 09 1:18
To: IPsecme WG
Subject: [IPsec] #119: Which certificate types can be mixed in one exchange?

 

Should be added to Sec. 3.6, probably as a new subsection.

One Hash & URL (H&U) bundle only. Or...

One Raw RSA key, or...

One or more cert payloads of either type 4 or H&U (type 12= )

Can have one or more CRLs and/or OCSP content (RFC 4806) added to any of the above, except for Raw RSA.=

 



Scanned by Check Point Total Security Gateway.

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE3ilex01adche_-- From julienl@qualcomm.com Tue Nov 24 09:20:29 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31E523A6954 for ; Tue, 24 Nov 2009 09:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.359 X-Spam-Level: X-Spam-Status: No, score=-105.359 tagged_above=-999 required=5 tests=[AWL=1.240, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkQbk4RymZxV for ; Tue, 24 Nov 2009 09:20:28 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 38AEB3A67A6 for ; Tue, 24 Nov 2009 09:20:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1259083224; x=1290619224; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"ipsec@ietf.org"=20|CC:=20"btns-ch airs@tools.ietf.org"=20|Date: =20Tue,=2024=20Nov=202009=2009:20:19=20-0800|Subject:=20B TNS=20IPsec=20APIs|Thread-Topic:=20BTNS=20IPsec=20APIs |Thread-Index:=20AcptKmXa3+tOLrG6SYqkZ0Y2PeA4fA=3D=3D |Message-ID:=20|Reply-To:=20"btns@ietf.org "=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5812"=3B=20a=3D"28338029"; bh=QBx83oFUo5hOdeuFh8YtlK6NWluCyfHCRqgQuzvP/sY=; b=pWAk2sWLFF69f+fvsIkNck9EqH9XeqstMHJVDQm+J87+82JLA1bRILei v48lDTst2wbIq4dVNzLR66lXUmABdGRbnSXXqEM+X6b/k3YDDFE3k5tDp wN8spXf4tjR0hB7YHt733rgHp01ZuT7Fu6rB5Md8ZBFyfi1s9BE80z9WW E=; X-IronPort-AV: E=McAfee;i="5400,1158,5812"; a="28338029" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 24 Nov 2009 09:20:23 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAOHKNWW018303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Nov 2009 09:20:23 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nAOHKCJx029008 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Nov 2009 09:20:23 -0800 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 24 Nov 2009 09:20:21 -0800 Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.639.21; Tue, 24 Nov 2009 09:20:21 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Tue, 24 Nov 2009 09:20:21 -0800 From: "Laganier, Julien" To: "ipsec@ietf.org" Date: Tue, 24 Nov 2009 09:20:19 -0800 Thread-Topic: BTNS IPsec APIs Thread-Index: AcptKmXa3+tOLrG6SYqkZ0Y2PeA4fA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "btns-chairs@tools.ietf.org" Subject: [IPsec] BTNS IPsec APIs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "btns@ietf.org" List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:20:29 -0000 Folks, Is there anybody interested in helping completing the BTNS IPsec APIs docum= ents? If you are, please also state the level of commitment you're willing = to dedicate to that goal (e.g., editing, contributing, reviewing.)=20 If there isn't enough interest it seems the logical next step for the BTNS = WG is to close without publishing the API docs. Please send your replies to the BTNS WG mailing list --julien, BTNS co-chair From paul.hoffman@vpnc.org Tue Nov 24 09:31:04 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACB3828C0E5 for ; Tue, 24 Nov 2009 09:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.985 X-Spam-Level: X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkZ-J-scpb7w for ; Tue, 24 Nov 2009 09:31:04 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id F224D28C0E6 for ; Tue, 24 Nov 2009 09:31:03 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAOHUwKP099360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Nov 2009 10:30:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19211.60135.834509.954897@fireball.kivinen.iki.fi> References: <19211.60135.834509.954897@fireball.kivinen.iki.fi> Date: Tue, 24 Nov 2009 09:30:56 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:31:04 -0000 Yes, I should have worked this out more fully before posting. In all cases, I would add a reference to the IANA registry. Only lists code points: remove the whole table 2.22: IPComp Tranform IDs 3.1: Exchange types 3.3.1: Protocol ID 3.3.2: Encryption, PRF, integrity, DH group, ESN 3.3.5: Transform attributes 3.15: CFG type Lists semantics, remove the code points but leave the semantics: 3.5: Identification types 3.10.1: Notify messages 3.13.1: Traffic selectors Other: 3.2: Next payload type -- remove value 3.3.2: Transform type -- remove type number 3.3.3: Transform types by protocol -- leave in whole table 3.6: Certificate encoding -- remove type number, leave in UNSPECIFIED 3.15.1: Attribute types -- remove type number --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Tue Nov 24 10:14:09 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27A073A692F for ; Tue, 24 Nov 2009 10:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.988 X-Spam-Level: X-Spam-Status: No, score=-5.988 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 719SY+ii8dzG for ; Tue, 24 Nov 2009 10:14:07 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id CB8B23A6816 for ; Tue, 24 Nov 2009 10:14:07 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAOIE1ef001853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 11:14:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19211.59597.904754.490768@fireball.kivinen.iki.fi> References: <19211.59597.904754.490768@fireball.kivinen.iki.fi> Date: Tue, 24 Nov 2009 10:13:59 -0800 To: Tero Kivinen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] #122: Integrity proposals with combined algorithms X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:14:09 -0000 At 4:08 PM +0200 11/24/09, Tero Kivinen wrote: >Paul Hoffman writes: >> The 4th paragraph of section 3.3 says "If an algorithm that combines >> encryption and integrity protection is proposed, it MUST be proposed >> as an encryption algorithm and an integrity protection algorithm >> MUST NOT be proposed." This means that an integrity protection >> algorithm can only be proposed with a Transform ID equal to NONE, >> given that a few paragraphs above, it says: "Combined-mode ciphers >> include both integrity and encryption in a single encryption >> algorithm, and are not allowed to be offered with a separate >> integrity algorithm other than "none"." We should thus make this >> clear in the 4th paragraph. > >I interpreted the text "integrity protection algorithm MUST NOT be >proposed" to mean that there is no transform type 3 (Integrity >algorithm) at all in the proposal, i.e. it is left out completely. > >Accepting proposal having transform type 3 (Integrity algorithm) with >value 0 (none) is ok, but I think we should prefer for not including >it at all, as it makes packets shorter. > >I agree that the text earlier would indicate that you send "NONE", but >RFC5282 says: > > This document updates [RFC4306] to require that when an > authenticated encryption algorithm is selected as the encryption > algorithm for any SA (IKE or ESP), an integrity algorithm MUST NOT > be selected for that SA. This document further updates [RFC4306] to > require that if all of the encryption algorithms in any proposal are > authenticated encryption algorithms, then the proposal MUST NOT > propose any integrity transforms. > >where I read the "MUST NOT propose any ingerity tranforms" to also >include integrity transform for value 0 (NONE). > >So I would change the section 3.3 text where it says > > Combined-mode ciphers include both > integrity and encryption in a single encryption algorithm, and are > not allowed to be offered with a separate integrity algorithm other > than "none". > >to say > > Combined-mode ciphers include both > integrity and encryption in a single encryption algorithm, and are > not allowed to be offered with a separate integrity algorithm. > >to align with the RFC5282. I'm pretty sure others have read this the other way: you must give a transform of "none". Are people OK with wording that says "MUST either offer an integrity algorithm or a single integrity algorithm of 'none'"? >Also note that the [AEAD] reference to the RFC5116 in IKEv2bis is >wrong, it should point to the RFC5282, which defines how AEAD modes >are used in IKE (all those references refer to IKEv2 used of AEAD). Good catch; fixed in the next draft. > >> HOWEVER, in section 3.3.2, in the table for transform types, it says: >> Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP >> (*) Negotiating an integrity algorithm is mandatory for the >> Encrypted payload format specified in this document. For example, >> [AEAD] specifies additional formats based on authenticated >> encryption, in which a separate integrity algorithm is not >> negotiated. >> The second sentence seems wrong. Proposed rewording: >> For example, >> [AEAD] specifies additional formats based on authenticated >> encryption, in which the integrity algorithm is an inherent >> part of the combined algorithm; in this case, the >> integrity algorithm is specified as "none". > >When you fix the reference from RFC5116 to RFC5282, then you notice >that NONE is not allowed, thus the original text was correct and your >new text is incorrect, as NONE cannot be proposed or accepted. I still don't think NONE is not allowed, but I want to hear from others. If no one implemented sending 'none', I'm happy to remove it, but I don't want to break anyone's implementation. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Tue Nov 24 10:29:23 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92FA728C144 for ; Tue, 24 Nov 2009 10:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.994 X-Spam-Level: X-Spam-Status: No, score=-5.994 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sONUwJ6RrXE for ; Tue, 24 Nov 2009 10:29:22 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id CCB8628C138 for ; Tue, 24 Nov 2009 10:29:22 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAOIT6CR002832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 11:29:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE2@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAA@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE2@il-ex01.ad.checkpoint.com> Date: Tue, 24 Nov 2009 10:29:05 -0800 To: Yaron Sheffer , IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] #118: Reference for PKCS #7 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:29:23 -0000 At 7:09 PM +0200 11/24/09, Yaron Sheffer wrote: >Russ later pointed out that there are multiple RFCs defining PKCS #7. Inputs on current implementations are welcome. > >PKCS#7 should reference RFC 2315. I think we should leave this as UNSPECIFIED. There are many ways to wrap an X.509 certificate in a CMS message, and we don't know what any vendor has done. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Tue Nov 24 10:35:39 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657913A68B7 for ; Tue, 24 Nov 2009 10:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.996 X-Spam-Level: X-Spam-Status: No, score=-5.996 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpZr79EDSo05 for ; Tue, 24 Nov 2009 10:35:38 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id ABA263A6830 for ; Tue, 24 Nov 2009 10:35:38 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAOIT6CP002832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 11:29:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE1@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA9@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE1@il-ex01.ad.checkpoint.com> Date: Tue, 24 Nov 2009 10:24:43 -0800 To: Yaron Sheffer , IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] #117: Hash and URL interop X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:35:39 -0000 At 7:09 PM +0200 11/24/09, Yaron Sheffer wrote: >Resending. There may be value in other URL methods, just maybe, but OTOH they would confuse developers and add security issues. I agree with only listing HTTP. --Paul Hoffman, Director --VPN Consortium From yaronf@checkpoint.com Tue Nov 24 13:30:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0123A68DD for ; Tue, 24 Nov 2009 13:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BQczypx3AQF for ; Tue, 24 Nov 2009 13:30:00 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id B60FD3A68D5 for ; Tue, 24 Nov 2009 13:29:59 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAOLToGo014223; Tue, 24 Nov 2009 23:29:50 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 24 Nov 2009 23:29:55 +0200 From: Yaron Sheffer To: Paul Hoffman , IPsecme WG Date: Tue, 24 Nov 2009 23:29:52 +0200 Thread-Topic: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis Thread-Index: AcptK+v6YHda9NGSQHmH54lCRQSKeQAH8dKg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0010@il-ex01.ad.checkpoint.com> References: <19211.60135.834509.954897@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 21:30:01 -0000 Hi Paul, I have marked below with an asterisk those that I think should stay in the = document, because they are important to understanding/implementing the prot= ocol. Overall, I'm not sure this exercise is worth our time. In particular if we = strip tables of their values, there's a high risk of introducing inconsiste= ncies between the document and the IANA registry. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Tuesday, November 24, 2009 19:31 > To: IPsecme WG > Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from > IKEv2bis >=20 > Yes, I should have worked this out more fully before posting. >=20 > In all cases, I would add a reference to the IANA registry. >=20 > Only lists code points: remove the whole table > 2.22: IPComp Tranform IDs > 3.1: Exchange types [*] > 3.3.1: Protocol ID [*] > 3.3.2: Encryption, PRF, integrity, DH group, ESN > 3.3.5: Transform attributes [* ??] > 3.15: CFG type [*] >=20 > Lists semantics, remove the code points but leave the semantics: > 3.5: Identification types=20 > 3.10.1: Notify messages > 3.13.1: Traffic selectors >=20 > Other: > 3.2: Next payload type -- remove value > 3.3.2: Transform type -- remove type number > 3.3.3: Transform types by protocol -- leave in whole table > 3.6: Certificate encoding -- remove type number, leave in UNSPECIFIED > 3.15.1: Attribute types -- remove type number >=20 >=20 > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From kohn.jack@gmail.com Tue Nov 24 19:35:55 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B915C28C1CA for ; Tue, 24 Nov 2009 19:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4isfndgmP1H for ; Tue, 24 Nov 2009 19:35:55 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id CE7F028C1C1 for ; Tue, 24 Nov 2009 19:35:54 -0800 (PST) Received: by gxk28 with SMTP id 28so6587695gxk.9 for ; Tue, 24 Nov 2009 19:35:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=rvHztCl6pxLKGWyROnw33kkXArd6O+hQomZ9cJs0dBg=; b=qGGWPSASkFzlmHmeYjmemZqtn9gA7wZV2ChFteY4ANsHKPQyGwUx2D4dUmXPA4/bnZ pqvLARdQJrzjhu+l1ENssE8YpX99/aAJ4H1YMcI/eSzNmaBYYOz8qBogiRB7gNBU7OE5 VrAao91HjUKYv8obOvxHcqc+aZ9bTUfof16R0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cDBFB6H8H62JvwVyeS4RovofpxZBgAOHyScC3GrsMVDV1hLAzF0OKgtT6q51ZTJlMe vffdtjPWYmf7q5xIZvi4yEufrw9p/2sPu07eBXGnDDUE4Q38hGm3Du/qukXCgqf8Qgul yid9qlLRcrx+ckuUkWESffSgvUmJQjREraQcw= MIME-Version: 1.0 Received: by 10.90.40.37 with SMTP id n37mr9501503agn.74.1259120146473; Tue, 24 Nov 2009 19:35:46 -0800 (PST) In-Reply-To: References: <19200.8786.266973.313959@fireball.kivinen.iki.fi> <19201.20208.563706.519993@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 09:05:46 +0530 Message-ID: From: Jack Kohn To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 03:35:55 -0000 > > - the principle example offered is OSPFv3 use of IPsec > - OSPFv3 relies on both unicast and multicast SAs > - in either case, a router receiving IPsec-protected OSPFv3 traffic > will have an SAD entry for the traffic, which means that the > router will know that the traffic will be protected via AH > or ESP. if ESP is employed, a router receiving traffic will know > ESP-NULL is used. > - RFC 4552 mandates support for using different SAs for DSCP-marked > traffic > - RFC 4552 calls for manual keying for both unicast and multicast > SAs, > and states that a receiver is not checking sequence numbers. > > In a given OSPF context (e.g., an AS), all the routers are operated by the > same administrative entity (based on the definition of an AS). If the AS in > which OSPF is being employed chooses to use ESP-NULL, all the routers can be > configured to require this, as part of local SPD management. > > Why do we need to use WESP in this context? The current argument you > provided was that this was an issue for a router receiving OSPF traffic, not > a middlebox issue. But the router knows that the traffic will be ESP-NULL, > and knows the algorithm employed, so it should be able to examine this > traffic easily. If the router wants to process traffic out-of-order, after > examination, that too is easy, since there is no receiver sequence number > checking, so processing the rest of the traffic (potentially with gaps) will > not be a problem from an IPsec perspective. Assume we dont have WESP. The end router having scores of OSPF adjacencies will have following rules in its database for *each* adjacency: Incoming Pkt carries SPI X, then look at the nth bit and if its a OSPF HELLO, put it in Ospfv3HighPrioQueue. Incoming Pkt carries SPI X, then look at the mth bit and if its a OSPF ACK, put it in Ospfv3HighPrioQueue. This is assuming that SPI X corresponds to ESP-NULL and one can disambiguate OSPF Hellos/ACKs from other OSPF packets by looking at the nth bit and the mth bit (Please note that n could also be equal to m). Now, if this router has N adjacencies then the # of rules required = 2 x N = 2N Thus the # of filter entries scales up linearly with the # of adjacencies. Now, assume that we were using WESP. You would need just two rules in your filter database saying the following: Incoming Pkt is WESP integrity Protected, then look at the nth bit and if its a OSPF HELLO, put it in Ospfv3HighPrioQueue. Incoming Pkt is WESP integrity Protected, then look at the mth bit and if its a OSPF ACK, put it in Ospfv3HighPrioQueue. Thus one now needs only 2 rules in the HW to prioritize packets for *all* OSPF adjacencies. This becomes a huge advantage when we start scaling up the OSPF adjacencies. Jack. From ynir@checkpoint.com Wed Nov 25 00:32:29 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E8CC3A67B0 for ; Wed, 25 Nov 2009 00:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrjRXxrFZ22d for ; Wed, 25 Nov 2009 00:32:28 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 347073A6A01 for ; Wed, 25 Nov 2009 00:32:28 -0800 (PST) X-CheckPoint: {4B0CE7DE-0-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 61F9729C008; Wed, 25 Nov 2009 10:32:19 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2FF0929C005; Wed, 25 Nov 2009 10:32:19 +0200 (IST) X-CheckPoint: {4B0CE7DA-0-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAP8WIGo001046; Wed, 25 Nov 2009 10:32:18 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 25 Nov 2009 10:32:24 +0200 From: Yoav Nir To: Paul Hoffman Date: Wed, 25 Nov 2009 10:32:15 +0200 Thread-Topic: [IPsec] #117: Hash and URL interop Thread-Index: Acptqc/0X4V08TEYTSCPOrQj2Ekh0w== Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA9@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE1@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] #117: Hash and URL interop X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 08:32:29 -0000 +1 Even things that seem obvious like https and ftp require a lot of considera= tions, like how to verify the certificate in https, or what identity to pre= sent in ftp. If someone wants to specify additional URL methods, they can specify then i= n an I-D. On Nov 24, 2009, at 8:24 PM, Paul Hoffman wrote: > At 7:09 PM +0200 11/24/09, Yaron Sheffer wrote: >> Resending. There may be value in other URL methods, just maybe, but OTOH= they would confuse developers and add security issues. >=20 > I agree with only listing HTTP. >=20 > --Paul Hoffman, Director > --VPN Consortium From mglt.ietf@gmail.com Wed Nov 25 03:11:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78B083A69F5 for ; Wed, 25 Nov 2009 03:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPdCrxETtUB4 for ; Wed, 25 Nov 2009 03:11:20 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id E722C28C207 for ; Wed, 25 Nov 2009 03:11:16 -0800 (PST) Received: by fxm5 with SMTP id 5so6811672fxm.28 for ; Wed, 25 Nov 2009 03:11:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8gQOkWM2+colAcEdqLCR5csop9QkOalMX1R/EVDfMiU=; b=I949inPN63G3Tz54IJ50r0sTTKaiXVPPZRUH6jCtLNdNB5FqwtgtWaBZDCRhWGPsh6 tuUzm0L2A34GVdva2ZQVkZ4g4uSiClMr9raRqGV26DtN8pwbnd8aO1gstNKM6zjhBXwJ ITLA2/i4JsdYxnleOqVdQQ9o2YOki81yTDkzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hkofi2Gc7KIM6QpHY0Vf7Qvln1dD8YT/MteHcT7lSWAs+zdSYKwwYl9oSgc/H847tl V4QdezVEUo0zn7MXrDEg7qpddDYJ+tkmeCRM/O1+blVbT9iHX7/Z26AUfUt6SZZ9+8Dh zVJzKuNSNVCDN+y/A94gKsRpyvynXwtZVsW8U= MIME-Version: 1.0 Received: by 10.102.226.17 with SMTP id y17mr3293436mug.67.1259147469193; Wed, 25 Nov 2009 03:11:09 -0800 (PST) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350AB2C85E06@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.com> <7C362EEF9C7896468B36C9B79200D8350AB2C85E06@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Wed, 25 Nov 2009 12:11:09 +0100 Message-ID: <51eafbcb0911250311h5465f034q5bcfd01ad826987b@mail.gmail.com> From: Daniel Migault To: "Bhatia, Manav (Manav)" Content-Type: multipart/alternative; boundary=0016364d205b9f03740479301d91 Cc: "ipsec@ietf.org" , Stephen Kent , Merike Kaeo Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 11:11:28 -0000 --0016364d205b9f03740479301d91 Content-Type: text/plain; charset=ISO-8859-1 Hi Manav, I agree that for an already negotiated SA, the SPD lookup detects IP source address spoofing. So in that case ESP detects the address spoofing during the SPD check whereas AH would detect it while checking the signature check. However SAD lookup is done with the longest match rule, and section 4.1 of RFC4301 specifies : "3. Search the SAD for a match on only SPI if the receiver has chosen to maintain a single SPI space for AH and ESP, and on both SPI and protocol, otherwise." This seems to enable a ESP or AH datagram with spoofed IP addresses to match the SAD and SPD. If we consider a middleboxe that changes the IP address, then using ESP will not detect the IP address spoof. On the other hand using AH the spoofing attack will be detected. There are some cases you want to protect the IP address header with IP addresses and options. The example I have in mind is when you are a mobile or a multihomed node, you are changing you IP address and want to notify your peer with a IPsec protected signalling message. - MIPv6 [RFC3776] uses ESP to protects the BU message. The information to be carried is the new CoA. Since ESP does not protects the IP header, the BU datagram carries the IP address in its Payload, thus carrying twice this information. It seems that AH would avoid repeating information. - MOBIKE [RFC4555] MOBIKE does not protect the new IP value which is taken from the IP header. In some cases this can lead to traffic redirecting attacks. The main purpose of this attack seems to be DoS. Thus I would not consider AH as ESP_NULL equivalent, and thus feel AH should not be removed. Nevertheless, AH has a major drawback which is NAT. For now we can only hope IPv6 will bring an end-to-end connectivity. At least AH would take considerable advantage of this statement! IMO, rather then removing AH I would see if future use of the Internet make it "historical" or not. For now it might be too soon to take such a decision. Furthermore, AH does not cause "problems" with other protocols, since they can chose not to use it. Regards, Daniel Regards, Daniel On Fri, Nov 13, 2009 at 2:18 AM, Bhatia, Manav (Manav) < manav.bhatia@alcatel-lucent.com> wrote: > Daniel, > > > AH is a security feature we need to keep for header authentication > > Am really not sure about the value that AH adds even in case of header > authentication. > > So what fields does AH protect: > > Version, Payload length, Next Header, Source IP and dest IP > > The only field worth modifying is the source and the dest IP. Now note that > an IPSec SA is established between a pair of source IP and dest IP. Upon > receipt of a packet containing an AH header, the receiver determines the > appropriate (unidirectional) SA, based on the dest IP, security protocol > (AH), and the SPI (it could also include the source IP). If the attacker > modifies (or spoofs) either of the source or the dest IP, the SA lookup will > fail and the receiver will regardless discard the packet. So what are we > gaining by AH "header authentication"? > > AH can only add value over ESP-NULL if there are instances where despite > address spoofing we erroneously process the IPSec packet. I don't see that > happening, so is this really an issue? > > Cheers, Manav > ________________________________ > > From: Daniel Migault [mailto:mglt.ietf@gmail.com] > Sent: Thursday, November 12, 2009 11.14 AM > To: Jack Kohn > Cc: Stephen Kent; ipsec@ietf.org; Bhatia, Manav (Manav); Merike > Kaeo > Subject: Re: [IPsec] WESP - Roadmap Ahead > > On Thu, Nov 12, 2009 at 5:30 AM, Jack Kohn > wrote: > > > > Whoops, I was wrong. I looked at 4552 and they do cite > ESP-NULL (although > > they never refer to it that way) as a MUST, and AH as a > MAY. > > Ok, so can we work on deprecating AH? This way new standards > defined > in other WGs dont have to provide support for AH. > > > AH is a security feature we need to keep for header authentication. > Other WG may chose not to deal with AH and only consider ESP. I don't see > what's wrong with that? > > Regards > > Daniel > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > > > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --0016364d205b9f03740479301d91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Manav,

I agree that for an already negotiated SA, the SPD looku= p detects IP source address spoofing. So in that case ESP detects the addre= ss spoofing during the SPD check whereas AH would detect it while checking = the signature check.

However SAD lookup is done with the longest match rule, and section 4.1= of RFC4301 specifies :
      "3. Search the SAD for a match o=
n only SPI if the receiver has
         chosen to maintain a single SPI =
space for AH and ESP, and on

         both SPI and protocol, otherwise."

This seems to ena= ble a ESP or AH datagram with spoofed IP addresses to match the SAD and SPD= . If we consider a middleboxe that changes the IP address, then using ESP w= ill not detect the IP address spoof. On the other hand using AH the spoofin= g attack will be detected.

There are some cases you want to protect the IP address header with IP addresses and options. The example I have in mind is when you are a mobile or a multihomed node, you are changing you IP address and want to notify your peer with a IPsec protected signalling message.
=A0=A0= =A0=A0=A0 - MIPv6 [RFC3776] uses ESP to protects the BU message. The inform= ation to be carried is the new CoA. Since ESP does not protects the IP head= er, the BU datagram carries the IP address in its Payload, thus carrying tw= ice this information. It seems that AH would avoid repeating information. =A0 =A0 =A0 - MOBIKE [RFC4555] MOBIKE does not protect the new IP value which is taken from the IP header. In some cases t= his can lead to traffic redirecting attacks. The main purpose of this attac= k seems to be DoS.

Thus I would not consider AH as ESP_NULL equival= ent, and thus feel AH should not be removed. Nevertheless, AH has a major d= rawback which is NAT. For now we can only hope IPv6 will bring an end-to-en= d connectivity. At least AH would take considerable advantage of this state= ment!

IMO, rather then removing AH I would see if future use of the Internet = make it "historical" or not. For now it might be too soon to take= such a decision. Furthermore, AH does not cause "problems" with = other protocols, since they can chose not to use it.

Regards,
=A0
Daniel

Regards,

Daniel

On Fri, Nov 13, 2009 at 2:18 AM, Bhatia, Manav (Manav)= <m= anav.bhatia@alcatel-lucent.com> wrote:
Daniel,

> AH is a security feature we need to keep for header authentication

Am really not sure about the value that AH adds even in case of heade= r authentication.

So what fields does AH protect:

Version, Payload length, Next Header, Source IP and dest IP

The only field worth modifying is the source and the dest IP. Now note that= an IPSec SA is established between a pair of source IP and dest IP. Upon r= eceipt of a packet containing an AH header, the receiver determines the app= ropriate (unidirectional) SA, based on the dest IP, security protocol (AH),= and the SPI (it could also include the source IP). If the attacker modifie= s (or spoofs) either of the source or the dest IP, the SA lookup will fail = and the receiver will regardless discard the packet. So what are we gaining= by AH "header authentication"?

AH can only add value over ESP-NULL if there are instances where despite ad= dress spoofing we erroneously process the IPSec packet. I don't see tha= t happening, so is this really an issue?

Cheers, Manav
________________________________

=A0 =A0 =A0 =A0From: Daniel Migault [mailto:mglt.ietf@gmail.com]
=A0 =A0 =A0 =A0Sent: Thursday, November 12, 2009 11.14 AM
=A0 =A0 =A0 =A0To: Jack Kohn
=A0 =A0 =A0 =A0Cc: Stephen Kent; ipsec@i= etf.org; Bhatia, Manav (Manav); Merike Kaeo
=A0 =A0 =A0 =A0Subject: Re: [IPsec] WESP - Roadmap Ahead=

=A0 =A0 =A0 =A0On Thu, Nov 12, 200= 9 at 5:30 AM, Jack Kohn <kohn.jac= k@gmail.com> wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> Whoops, I was wrong. I looked at 4552 = and they do cite ESP-NULL (although
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0> they never refer to it that way) as a = MUST, and AH as a MAY.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ok, so can we work on deprecating AH? This = way new standards defined
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in other WGs dont have to provide support f= or AH.


=A0 =A0 =A0 =A0AH is a security feature we need to keep for header authent= ication. Other WG may chose not to deal with AH and only consider ESP. I do= n't see what's wrong with that?

=A0 =A0 =A0 =A0 Regards

=A0 =A0 =A0 =A0Daniel
=A0 =A0 =A0 =A0--
=A0 =A0 =A0 =A0Daniel Migault
=A0 =A0 =A0 =A0Orange Labs -- Security
=A0 =A0 =A0 =A0+33 6 70 72 69 58





--
Daniel Miga= ult
Orange Labs -- Security
+33 6 70 72 69 58
--0016364d205b9f03740479301d91-- From kivinen@iki.fi Wed Nov 25 03:44:42 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520293A6916 for ; Wed, 25 Nov 2009 03:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Glz-eYXWQRjT for ; Wed, 25 Nov 2009 03:44:41 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 43B603A68C8 for ; Wed, 25 Nov 2009 03:44:40 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAPBiPUF013698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 13:44:25 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAPBiOHw012988; Wed, 25 Nov 2009 13:44:24 +0200 (EET) 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: <19213.6296.58382.691986@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 13:44:24 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE0@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA8@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE0@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: IPsecme WG Subject: Re: [IPsec] #116: The AUTH payload signature X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 11:44:42 -0000 Yaron Sheffer writes: > Tero requested a clarification: I'm proposing to say that the > certificate's hash algorithm does not determine the AUTH hash > function (which is the negotiated PRF). Implementations may use the > certificates received from a given peer as a hint for selecting a > mutually-understood PRF with that peer. That I can accept. They are not unrelated, but certificate's hash algorithm does not determine AUTH hash algorithm. > And yes, the last sentence refers to this text: > > To promote interoperability, implementations that support this type > SHOULD support signatures that use SHA-1 as the hash function and > SHOULD use SHA-1 as the default hash function when generating > signatures. Do you have new proposed text? -- kivinen@iki.fi From kivinen@iki.fi Wed Nov 25 03:55:09 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 613EB3A6886 for ; Wed, 25 Nov 2009 03:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWB5AWROiAcs for ; Wed, 25 Nov 2009 03:55:08 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0D23A67A5 for ; Wed, 25 Nov 2009 03:55:08 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAPBt0au014084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 13:55:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAPBt0D1013234; Wed, 25 Nov 2009 13:55:00 +0200 (EET) 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: <19213.6931.976983.442284@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 13:54:59 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE1@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA9@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE1@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 9 min Cc: IPsecme WG Subject: Re: [IPsec] #117: Hash and URL interop X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 11:55:09 -0000 Yaron Sheffer writes: > Resending. There may be value in other URL methods, just maybe, but > OTOH they would confuse developers and add security issues. I still reiterate that I do not think we can add "MUST NOT" for other URL methods, as that would be change that can make existing implementations non-conforming (if they happen to send some other url methods). We have been in other cases careful not to make changes that could make currently conforming implementations non-conforming, so I think this should be similar case. Btw, our implementation only sends http urls for now. > To improve interoperability, allow only the "http" URL method. The > current text (end of sec. 3.6) implies that any method is allowed, > although HTTP MUST be supported. I still think the current text mandating one method (MUST for http) provides good enough interoperability. I do not see nede to change this. See my previous comment about this: http://www.ietf.org/mail-archive/web/ipsec/current/msg04987.html -- kivinen@iki.fi From kivinen@iki.fi Wed Nov 25 04:01:34 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037BA3A6886 for ; Wed, 25 Nov 2009 04:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1J5t+CKg-aAu for ; Wed, 25 Nov 2009 04:01:33 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1AFDE3A6A27 for ; Wed, 25 Nov 2009 04:01:31 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAPC1O5R012891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 14:01:24 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAPC1OFl013962; Wed, 25 Nov 2009 14:01:24 +0200 (EET) 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: <19213.7316.277814.1281@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 14:01:24 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE2@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAA@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE2@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: IPsecme WG Subject: Re: [IPsec] #118: Reference for PKCS #7 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 12:01:34 -0000 Yaron Sheffer writes: > Russ later pointed out that there are multiple RFCs defining PKCS > #7. Inputs on current implementations are welcome. > > PKCS#7 should reference RFC 2315. I think the two options is either RFC5652 (latest CMS) or RFC2315 (original PKCS#7). All other of the rfcs have been obsoleted by the RFC5652. I do not know enough of the later CMS versions, but RFC2630 says that it should be backward compatible with RFC2315 expect where it was changed to "accommodate attribute certificate transfer and key agreement techniques for key management". As I do not think we need any of those in IKEv2, I think it is enough to refer to the RFC2315. -- kivinen@iki.fi From kivinen@iki.fi Wed Nov 25 04:23:28 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E65EA3A69F5 for ; Wed, 25 Nov 2009 04:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfYMrAApARYL for ; Wed, 25 Nov 2009 04:23:28 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B2DE83A68C8 for ; Wed, 25 Nov 2009 04:23:27 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAPCNGZU015228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 14:23:16 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAPCNGNv014167; Wed, 25 Nov 2009 14:23:16 +0200 (EET) 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: <19213.8628.334377.872920@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 14:23:16 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE3@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAB@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE3@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 20 min Cc: IPsecme WG Subject: Re: [IPsec] #119: Which certificate types can be mixed in one exchange? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 12:23:29 -0000 Yaron Sheffer writes: > There was very limited discussion of this issue, which I see as the > main reason why Sec. 3.6 is underspecified. If my proposal below is > too restrictive we can expand it somewhat but still keep the number > of possible combinations at a level where testing (and > interoperability) is possible. I think the list is too restrictive. For example we definately want to allow sending both Raw RSA key, and same key using some certificate format. This would be the one that can be used bootstrap environments for using Raw RSA keys in the beginning (and each host will have list of allowed rsa keys (or hashes of them)), and then later each site can be updated to include proper certificate from some CA too, and they can still talk to the old non updated hosts using Raw RSA keys, and to new updated hosts using certificates. This means the PKI does not need to be taken in to use as atomic operation, but it can be rolled in to use slowly one host at time. I agree there is no point of having multiple Raw RSA keys, i.e. we could limit the number of those to one (or zero). I do not think we can make too much other restrictions without making existing implementations non-conforming. I can also see uses for multiple hash and url bundles, in case the responder has for example certificate signed by 2 different CAs and initiator didn't specify which of them should be used, so responder can send hash and url bundles for both of them. > David also asked whether we'd want to fold RFC 4806 (OCSP extensions > to IKEv2) into -bis. My personal opinion is No, despite the fact > that it is a Proposed Standard. I agree on that. > Subject: [IPsec] #119: Which certificate types can be mixed in one exchange? > > > Should be added to Sec. 3.6, probably as a new subsection. > > One Hash & URL (H&U) bundle only. Or... > > One Raw RSA key, or... > > One or more cert payloads of either type 4 or H&U (type 12) > > Can have one or more CRLs and/or OCSP content (RFC > 4806) added to any of the above, > except for Raw RSA. -- kivinen@iki.fi From kivinen@iki.fi Wed Nov 25 04:30:24 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07EF83A6A21 for ; Wed, 25 Nov 2009 04:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9cPxiJqHzO9 for ; Wed, 25 Nov 2009 04:30:22 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 7D86A3A68E4 for ; Wed, 25 Nov 2009 04:30:22 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAPCUEwL011499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 14:30:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAPCUEJB015302; Wed, 25 Nov 2009 14:30:14 +0200 (EET) 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: <19213.9046.156284.824605@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 14:30:14 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE4@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAC@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE4@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: IPsecme WG Subject: Re: [IPsec] #120: CA indication with cert req - allowed types X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 12:30:24 -0000 Yaron Sheffer writes: > Please also see Tero's follow-up here: > http://www.ietf.org/mail-archive/web/ipsec/current/msg04990.html I still agree what I said back then :-) > Subject: [IPsec] #120: CA indication with cert req - allowed types > > > Sec. 3.7 has: > > The contents of the "Certification Authority" field are defined only > for X.509 certificates, which are types 4, 10, 12, and 13. Other > values SHOULD NOT be used until standards-track specifications that > specify their use are published. > > This excludes certificate requests of type 7, i.e. for CRLs. For > requesting a specific CRL type 7 would make sense, in particular in > chain situations. Should we add it to the list of allowed types > here? > > OTOH, this allows type 10, which is unspecified and should be removed. And there is also format 14 which also can be sent as CERTREQ and it can have empty certificate authority or it can have some hashes from trusted responder's public keys. -- kivinen@iki.fi From kivinen@iki.fi Wed Nov 25 04:41:55 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4E13A6A3F for ; Wed, 25 Nov 2009 04:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMoB240-xXCT for ; Wed, 25 Nov 2009 04:41:54 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 372A23A6A39 for ; Wed, 25 Nov 2009 04:41:54 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAPCflAk012921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 14:41:47 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAPCfkXH015161; Wed, 25 Nov 2009 14:41:46 +0200 (EET) 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: <19213.9738.693741.410069@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 14:41:46 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <19211.60135.834509.954897@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 9 min Cc: IPsecme WG Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 12:41:55 -0000 Paul Hoffman writes: > Yes, I should have worked this out more fully before posting. > > In all cases, I would add a reference to the IANA registry. > > Only lists code points: remove the whole table > 2.22: IPComp Tranform IDs > 3.3.2: Encryption, PRF, integrity, DH group, ESN I can agree removing those whole tables. > 3.1: Exchange types > 3.3.1: Protocol ID > 3.3.5: Transform attributes > 3.15: CFG type These I would leave in, but remove the RESERVED, RESERVED TO IANA and PRIVATE USE lines, i.e. leave only the values used in this document. These are needed when developing the protocol, and having yet another indirection there would just be annoying developers. > Lists semantics, remove the code points but leave the semantics: > 3.5: Identification types > 3.10.1: Notify messages > 3.13.1: Traffic selectors I would keep values for those too, but remove RESERVED/PRIVATE etc ranges, i.e. keep numbers needed to implement this protocol (and referenced by this RFC), but by removing the reserved and private use range definitions, it makes it clear this is not full list, so if someone wants to see full list, they need to go to the iana-registry. And I would move these to the same category: > 3.2: Next payload type -- remove value > 3.3.2: Transform type -- remove type number > 3.6: Certificate encoding -- remove type number, leave in UNSPECIFIED > 3.15.1: Attribute types -- remove type number I.e. leave number. > 3.3.3: Transform types by protocol -- leave in whole table This I agree :-) -- kivinen@iki.fi From yaronf@checkpoint.com Wed Nov 25 05:01:08 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C5D28C224 for ; Wed, 25 Nov 2009 05:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uOv82aMETOh for ; Wed, 25 Nov 2009 05:01:08 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id A63CB28C21E for ; Wed, 25 Nov 2009 05:01:07 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAPD10Go021594; Wed, 25 Nov 2009 15:01:01 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 25 Nov 2009 15:01:06 +0200 From: Yaron Sheffer To: Tero Kivinen Date: Wed, 25 Nov 2009 15:01:05 +0200 Thread-Topic: [IPsec] #118: Reference for PKCS #7 Thread-Index: Acptxwenywo3hGljRBuvqDZ/TtQ9KAAB6o2A Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E012E@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAA@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE2@il-ex01.ad.checkpoint.com> <19213.7316.277814.1281@fireball.kivinen.iki.fi> In-Reply-To: <19213.7316.277814.1281@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] #118: Reference for PKCS #7 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 13:01:09 -0000 No, Sec. 1.1.1 of RFC 5652 (which you are quoting) only describes the diffe= rences between the original PKCS #7 v1.5 and RFC 2630. There follow a few m= ore sections with other bells and whistles leading to RFC 5652. Besides, even if the later RFCs are (mostly) *backward compatible* with RFC= 2315, they may still be adding useful stuff. This is just speculation on m= y part, not actual knowledge. Thanks, Yaron > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Wednesday, November 25, 2009 14:01 > To: Yaron Sheffer > Cc: IPsecme WG > Subject: Re: [IPsec] #118: Reference for PKCS #7 >=20 > Yaron Sheffer writes: > > Russ later pointed out that there are multiple RFCs defining PKCS > > #7. Inputs on current implementations are welcome. > > > > PKCS#7 should reference RFC 2315. >=20 > I think the two options is either RFC5652 (latest CMS) or RFC2315 > (original PKCS#7). All other of the rfcs have been obsoleted by the > RFC5652. >=20 > I do not know enough of the later CMS versions, but RFC2630 says that > it should be backward compatible with RFC2315 expect where it was > changed to "accommodate attribute certificate transfer and key > agreement techniques for key management". >=20 > As I do not think we need any of those in IKEv2, I think it is enough > to refer to the RFC2315. > -- > kivinen@iki.fi >=20 > Scanned by Check Point Total Security Gateway. From kivinen@iki.fi Wed Nov 25 05:04:35 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D5728C222 for ; Wed, 25 Nov 2009 05:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32+sm8Ky27ly for ; Wed, 25 Nov 2009 05:04:33 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C725528C21E for ; Wed, 25 Nov 2009 05:04:32 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAPD4NUT013733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 15:04:23 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAPD4M5L014488; Wed, 25 Nov 2009 15:04:22 +0200 (EET) 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: <19213.11094.860914.790618@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 15:04:22 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <19211.59597.904754.490768@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 19 min Cc: IPsecme WG Subject: Re: [IPsec] #122: Integrity proposals with combined algorithms X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 13:04:35 -0000 Paul Hoffman writes: > I'm pretty sure others have read this the other way: you must give a > transform of "none". I do not see any point why I should send none, when it is better to just leave it out, this is what you normally do for ESP when you use combined mode ciphers. Leaving it out makes packets smaller... The problem is that in IKEv2 you are explicitly FORBIDDEN of using integrity algorithm of NONE: 5. Security Considerations ... choices in this protocol, see [SIGMA] and [SKEME]. Though the security of negotiated CHILD_SAs does not depend on the strength of the encryption and integrity protection negotiated in the IKE_SA, implementations MUST NOT negotiate NONE as the IKE integrity protection algorithm or ENCR_NULL as the IKE encryption algorithm. And someone might interpret that there cannot be Integrity algorithm NONE in any proposal for IKEv2 SA (in a sense there is no separate IKE integrity protection algorithm at all, but integrity protection is provided by the encryption algorithm). > Are people OK with wording that says "MUST either offer an integrity > algorithm or a single integrity algorithm of 'none'"? If you add "no" somewhere there (i.e. MUST either offer no integrity algorithm...) then I can accept it. > I still don't think NONE is not allowed, but I want to hear from > others. If no one implemented sending 'none', I'm happy to remove > it, but I don't want to break anyone's implementation. We do not support combined modes for IKEv2 SA yet (only for ESP, and in ESP we do not send integrity algorithm at all, but we do accept other ends proposal if they send none). -- kivinen@iki.fi From kivinen@iki.fi Wed Nov 25 05:44:57 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 882CC3A69C3 for ; Wed, 25 Nov 2009 05:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLxxhRJtji7I for ; Wed, 25 Nov 2009 05:44:56 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 6D6D73A67A8 for ; Wed, 25 Nov 2009 05:44:56 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAPDictw016250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 15:44:38 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAPDib0d014155; Wed, 25 Nov 2009 15:44:37 +0200 (EET) 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: <19213.13509.411432.158022@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 15:44:37 +0200 From: Tero Kivinen To: Jack Kohn In-Reply-To: References: <19200.8786.266973.313959@fireball.kivinen.iki.fi> <19201.20208.563706.519993@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" , Stephen Kent Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 13:44:57 -0000 Jack Kohn writes: > Assume we dont have WESP. I would like to, but unfortunately I lost :-) > The end router having scores of OSPF adjacencies will have following > rules in its database for *each* adjacency: > > Incoming Pkt carries SPI X, then look at the nth bit and if its a OSPF > HELLO, put it in Ospfv3HighPrioQueue. > Incoming Pkt carries SPI X, then look at the mth bit and if its a OSPF > ACK, put it in Ospfv3HighPrioQueue. As all of those IPsec connections is created by node, it actually knows which algorithms are allowed, so it can very quickly do simple run partial heuristics on the packet to know it is ESP-NULL. Or actually it can also make so that if SPI number bit x is set then the IPsec SA is using ESP-NULL for ospf, otherwise it is normal encrypted traffic or something else. As SPI allocation is local matter for this node, it can do this kind of things. Middle boxes (where wesp and heuristics are really intended for) cannot do this kind of things, but end-boxes can. So for end boxes there is even more efficient methods than using WESP to do the same thing. Splitting SPI range to indicate algorithms is more efficient than WESP, as then you do waste extra bytes for extra header. > Thus one now needs only 2 rules in the HW to prioritize packets for > *all* OSPF adjacencies. > > This becomes a huge advantage when we start scaling up the OSPF > adjacencies. If you start using IPsec protected OSPF then you most likely will require hardware support for IPsec also, and SPI lookup to find out the algorithms etc is very fast first step done in there. After that you know the parameters for the SA and you can then do this kind of prioritizing before forwarding packet to the actual crypto engines. On the other hand it might be better to just put few extra dollars for the hardware and get fast enough crypto chips so you can do this prioritizing using AUTHENTICATED data from the packet, i.e. after IPsec processing as that will protect against attackers flooding the Ospfv3HighPrioQueue by sending packets matching your bits. -- kivinen@iki.fi From kivinen@iki.fi Wed Nov 25 05:52:28 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C846E3A67A8 for ; Wed, 25 Nov 2009 05:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-bHRYrNWlgM for ; Wed, 25 Nov 2009 05:52:28 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A91E03A63EB for ; Wed, 25 Nov 2009 05:52:27 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAPDqIrI014445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 15:52:18 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAPDqITK014367; Wed, 25 Nov 2009 15:52:18 +0200 (EET) 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: <19213.13970.105797.850084@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 15:52:18 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA9@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE1@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] #117: Hash and URL interop X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 13:52:28 -0000 Yoav Nir writes: > Even things that seem obvious like https and ftp require a lot of > considerations, like how to verify the certificate in https, or what > identity to present in ftp. > > If someone wants to specify additional URL methods, they can specify > then in an I-D. Yes, and but if the current documents says MUST NOT for them, then they can have problems talking to the current implementations. On the other hand nobody has yet answered to my earlier question what they plan to say in the draft. Original text said "allow only http URL", and I said MUST NOT would not be ok for me. Paul said: > > I agree with only listing HTTP. which does not tell what he means with that. Do he mean that we only list http (currently we do that, we say MUST for http urls and do not list any other url methods). So I would really like to see the exact wording before I can say anything else. Or at least better explination what is meant. -- kivinen@iki.fi From kivinen@iki.fi Wed Nov 25 06:00:24 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1837E28C24A for ; Wed, 25 Nov 2009 06:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OYkMoELX8+S for ; Wed, 25 Nov 2009 06:00:23 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E0C5F28C241 for ; Wed, 25 Nov 2009 06:00:22 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAPDxxZm015138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 15:59:59 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAPDxwkk015157; Wed, 25 Nov 2009 15:59:58 +0200 (EET) 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: <19213.14430.479067.369482@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 15:59:58 +0200 From: Tero Kivinen To: Daniel Migault In-Reply-To: <51eafbcb0911250311h5465f034q5bcfd01ad826987b@mail.gmail.com> References: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.com> <7C362EEF9C7896468B36C9B79200D8350AB2C85E06@INBANSXCHMBSA1.in.alcatel-lucent.com> <51eafbcb0911250311h5465f034q5bcfd01ad826987b@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Stephen Kent , Merike Kaeo Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 14:00:24 -0000 Daniel Migault writes: > I agree that for an already negotiated SA, the SPD lookup detects IP source > address spoofing. Not quite true, as you point out yourself. > So in that case ESP detects the address spoofing during > the SPD check whereas AH would detect it while checking the signature check. > > However SAD lookup is done with the longest match rule, and section 4.1 of > RFC4301 specifies : > > "3. Search the SAD for a match on only SPI if the receiver has > chosen to maintain a single SPI space for AH and ESP, and on > both SPI and protocol, otherwise." > > > This seems to enable a ESP or AH datagram with spoofed IP addresses to match > the SAD and SPD. Yes, and this is very important to get NAT-T and MOBIKE to work as there the source address might change (either because NAT box rebooted or otherwise forgot the mapping, and gave new IP address for the IPsec connection, or because host moved around using MOBIKE). > If we consider a middleboxe that changes the IP address, > then using ESP will not detect the IP address spoof. On the other hand using > AH the spoofing attack will be detected. Yes. > Thus I would not consider AH as ESP_NULL equivalent, and thus feel AH should > not be removed. Nevertheless, AH has a major drawback which is NAT. For now > we can only hope IPv6 will bring an end-to-end connectivity. At least AH > would take considerable advantage of this statement! To reiterate for others, the major drawback in AH is that it actually detects changes in the source / destination IP addresses, thus it breaks if there is evil attackers (called NATs) in the middle who try to modify source and/or destination addresses... > IMO, rather then removing AH I would see if future use of the Internet make > it "historical" or not. For now it might be too soon to take such a > decision. Furthermore, AH does not cause "problems" with other protocols, > since they can chose not to use it. I agree. -- kivinen@iki.fi From kivinen@iki.fi Wed Nov 25 06:00:45 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37A9828C24B for ; Wed, 25 Nov 2009 06:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnQb17n9BrZf for ; Wed, 25 Nov 2009 06:00:44 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 93E4528C242 for ; Wed, 25 Nov 2009 06:00:43 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAPE0USB015710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Nov 2009 16:00:30 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAPE0Uv1014824; Wed, 25 Nov 2009 16:00:30 +0200 (EET) Date: Wed, 25 Nov 2009 16:00:30 +0200 (EET) Resent-From: kivinen@iki.fi Message-Id: <200911251400.nAPE0Uv1014824@fireball.kivinen.iki.fi> X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f Resent-Message-ID: <19213.14462.928236.781126@fireball.kivinen.iki.fi> Resent-Date: Wed, 25 Nov 2009 16:00:30 +0200 Resent-To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Michael Richardson In-Reply-To: <23183.1259080996@marajade.sandelman.ca> References: <10247.1257346966@marajade.sandelman.ca> <19210.35881.683962.654367@fireball.kivinen.iki.fi> <6762.1258985518@marajade.sandelman.ca> <19211.50148.822367.818236@fireball.kivinen.iki.fi> <23183.1259080996@marajade.sandelman.ca> X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 0 min Cc: ipsec@ietf.org Subject: Re: [IPsec] comments on esp-null-heuristics-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 14:00:45 -0000 Michael Richardson writes: > Tero> How does that disagree in their definition of flow? > > A flow in the routing and ASIC space is an origin/destination IP address > pair only. A microflow is the 5-tuple. Never heard about microflow before. Wikipedia says: Applied to Internet routers, a flow may be a host-to-host communication path, or a socket-to-socket communication identified by a unique combination of source and destination addresses and port numbers, together with transport protocol (for example, UDP or TCP). In the TCP case, a flow may be a virtual circuit, also known as a virtual connection or a byte stream. It also says it could be "a sequence of packets from a source computer to a destination", which would match other flow definition, so I guess there is no one standardized definition... Wikipedia does not know anything about microflows... RFC2474 seems to be the one which defines microflow, and RFC2991 defines flow to be "represent the granularity at which the router keeps state", which might be just source and destination addresses, or it might contain protocol id, and RFC2991 also says that "flow" is not necessarily synonymous with the term "microflow", but does not also say it cannot be. Deep inspection engines usually keep state on granularity of port numbers, so I do not think the flow definition we use here is inheritly different from RFC 2991. Then for example rfc4821 (Packetization Layer Path MTU Discovery) defines flow to be: Flow: A context in which MTU Discovery algorithms can be invoked. This is naturally an instance of a Packetization Protocol, for example, one side of a TCP connection. and RFC5626 (Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)) says: Flow: A Flow is a transport-layer association between two hosts that is represented by the network address and port number of both ends and by the transport protocol. For TCP, a flow is equivalent to a TCP connection. For UDP a flow is a bidirectional stream of datagrams between a single pair of IP addresses and ports of both peers. With TCP, a flow often has a one-to-one correspondence with a single file descriptor in the operating system. so I do not think there is one agreed on definition of flow. > Tero> On the other hand it really does not matter whether it > Tero> disagrees or not, this is what we mean by flow in this > Tero> document, so as we define it there, it should be clear for > Tero> people what we mean by flow. > > Well, your document will be read by ASIC designers and they already have > a definition of flow and microflow, and if you want to confuse them, > then that's fine. I do not want to use definition that would confuse all others either. It is bad if one group of people is confused, but don't really want to confuse other people by using term they do not know (including me). Perhaps the best way is to say in the terminology definition of flow that in some context (diffserv and bhp) this is called microflow. -- kivinen@iki.fi From kent@bbn.com Wed Nov 25 06:32:04 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 999CE3A690C for ; Wed, 25 Nov 2009 06:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhbpyuePTyEP for ; Wed, 25 Nov 2009 06:32:03 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id AB6AC3A6AB1 for ; Wed, 25 Nov 2009 06:32:03 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NDIuU-0007qu-Ap; Wed, 25 Nov 2009 09:31:58 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <19200.8786.266973.313959@fireball.kivinen.iki.fi> <19201.20208.563706.519993@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 09:31:52 -0500 To: Jack Kohn From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 14:32:04 -0000 At 9:05 AM +0530 11/25/09, Jack Kohn wrote: > > > >... > >Assume we dont have WESP. > >The end router having scores of OSPF adjacencies will have following >rules in its database for *each* adjacency: > >Incoming Pkt carries SPI X, then look at the nth bit and if its a OSPF >HELLO, put it in Ospfv3HighPrioQueue. >Incoming Pkt carries SPI X, then look at the mth bit and if its a OSPF >ACK, put it in Ospfv3HighPrioQueue. > >This is assuming that SPI X corresponds to ESP-NULL and one can >disambiguate OSPF Hellos/ACKs from other OSPF packets by looking at >the nth bit and the mth bit (Please note that n could also be equal to >m). These packets are arriving on a multicast SA, so the preferred way to do the lookup, to make certain that the packet is from a relevant router is to perform the lookup as described in section 4.1 (pages 12+13) of RFC 4301. That means that these SAs generally are uniquely identified based on both the SPI value and the source and/or destination addresses. So, you would need to refine the matching algorithm described above based on the rules from 4301. >Now, if this router has N adjacencies then the # of rules required = >2 x N = 2N > >Thus the # of filter entries scales up linearly with the # of adjacencies. I've always found the 4552 discussion of SA use a bit confusing, but my recollection is that it called for reusing SAs in a way to avoid this problem (see Figure 3, section 7, page 7). But I am not completely confident about this, based on the wording in that RFC. >Now, assume that we were using WESP. > >You would need just two rules in your filter database saying the following: > >Incoming Pkt is WESP integrity Protected, then look at the nth bit and >if its a OSPF HELLO, put it in Ospfv3HighPrioQueue. >Incoming Pkt is WESP integrity Protected, then look at the mth bit and >if its a OSPF ACK, put it in Ospfv3HighPrioQueue. This is much simpler, but also potentially inaccurate. Specifically, because it pays no attention to the SAD info, it would grab ANY packet that passes through the router, uses WESP, and that matches the bits that one uses to decide of a packet is an OSPF HELLO or ACK. >Thus one now needs only 2 rules in the HW to prioritize packets for >*all* OSPF adjacencies. Unless you used some other rules to narrow down the set of packets subject to these quick checks, other packets may be grabbed. Steve From kent@bbn.com Wed Nov 25 06:40:11 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A074D3A6AC5 for ; Wed, 25 Nov 2009 06:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gsz1Wgk3Dl0G for ; Wed, 25 Nov 2009 06:40:11 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id DF06E3A68D3 for ; Wed, 25 Nov 2009 06:40:10 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NDJ2J-0007xa-Ar; Wed, 25 Nov 2009 09:40:03 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <51eafbcb0911250311h5465f034q5bcfd01ad826987b@mail.gmail.com> References: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.com> <7C362EEF9C7896468B36C9B79200D8350AB2C85E06@INBANSXCHMBSA1.in.alcatel-luce nt.com> <51eafbcb0911250311h5465f034q5bcfd01ad826987b@mail.gmail.com> Date: Wed, 25 Nov 2009 09:40:00 -0500 To: Daniel Migault From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Merike Kaeo Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 14:40:11 -0000 At 12:11 PM +0100 11/25/09, Daniel Migault wrote: >Hi Manav, > >I agree that for an already negotiated SA, the SPD lookup detects IP >source address spoofing. So in that case ESP detects the address >spoofing during the SPD check whereas AH would detect it while >checking the signature check. > >However SAD lookup is done with the longest match rule, and section >4.1 of RFC4301 specifies : > "3. Search the SAD for a match on only SPI if the receiver has > chosen to maintain a single SPI space for AH and ESP, and on > > both SPI and protocol, otherwise." > >This seems to enable a ESP or AH datagram with spoofed IP addresses >to match the SAD and SPD. I'm confused at this juncture. The 4301 inbound processing algorithm (section 5.2 in RFC 4310) refers to SAD entries for processing IPsec-protected packets; the SPD inbound cache (SPD-I) is used only for bypass and discard traffic. So there should be no reference to the SPD in the sentence immediately above, right? Also, you should remind folks that this rule applies only to multicast SAs. That's relevant to the OSPFv3 discussion we are having, but it seems inconsistent with the comment below of a middlebox that changes addresses, i.e., does one really expect to encounter a NAT on a link between two routers running OSPF? I am not criticizing your later comments about AH vs. ESP applicability in mobile environments, just trying to keep the various arguments straight. Steve From yaronf@checkpoint.com Wed Nov 25 06:44:26 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17CA428C24C for ; Wed, 25 Nov 2009 06:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SV105SCeo3EK for ; Wed, 25 Nov 2009 06:44:25 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id A9E663A6ACB for ; Wed, 25 Nov 2009 06:44:24 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAPEiEGo022370; Wed, 25 Nov 2009 16:44:14 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 25 Nov 2009 16:44:20 +0200 From: Yaron Sheffer To: Tero Kivinen , Yoav Nir Date: Wed, 25 Nov 2009 16:44:18 +0200 Thread-Topic: [IPsec] #117: Hash and URL interop Thread-Index: Acpt1otPLQu6CiJoQ5GQKgfZLzuTPAABl6kQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E016D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA9@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE1@il-ex01.ad.checkpoint.com> <19213.13970.105797.850084@fireball.kivinen.iki.fi> In-Reply-To: <19213.13970.105797.850084@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] #117: Hash and URL interop X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 14:44:26 -0000 Can you live with: Implementations MUST support HTTP. The behavior of other URL methods is not= currently specified, so such methods SHOULD NOT be used in the absence of = a Standards Track document defining them. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Tero Kivinen > Sent: Wednesday, November 25, 2009 15:52 > To: Yoav Nir > Cc: IPsecme WG; Paul Hoffman > Subject: Re: [IPsec] #117: Hash and URL interop >=20 > Yoav Nir writes: > > Even things that seem obvious like https and ftp require a lot of > > considerations, like how to verify the certificate in https, or what > > identity to present in ftp. > > > > If someone wants to specify additional URL methods, they can specify > > then in an I-D. >=20 > Yes, and but if the current documents says MUST NOT for them, then they > can have problems talking to the current implementations. >=20 > On the other hand nobody has yet answered to my earlier question what the= y > plan to say in the draft. Original text said "allow only http URL", and I > said MUST NOT would not be ok for me. >=20 > Paul said: >=20 > > > I agree with only listing HTTP. >=20 > which does not tell what he means with that. Do he mean that we only list > http (currently we do that, we say MUST for http urls and do not list any > other url methods). >=20 > So I would really like to see the exact wording before I can say anything > else. Or at least better explination what is meant. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From kivinen@iki.fi Wed Nov 25 07:14:22 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDF1E3A684D for ; Wed, 25 Nov 2009 07:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5h203vWZIZG for ; Wed, 25 Nov 2009 07:14:20 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2427A3A6863 for ; Wed, 25 Nov 2009 07:14:19 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAPFE5Ps016270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 17:14:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAPFE5OT014757; Wed, 25 Nov 2009 17:14:05 +0200 (EET) 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: <19213.18877.502688.416220@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 17:14:05 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E012E@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EAA@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE2@il-ex01.ad.checkpoint.com> <19213.7316.277814.1281@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E012E@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 72 min Cc: IPsecme WG Subject: Re: [IPsec] #118: Reference for PKCS #7 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:14:22 -0000 Yaron Sheffer writes: > No, Sec. 1.1.1 of RFC 5652 (which you are quoting) only describes > the differences between the original PKCS #7 v1.5 and RFC 2630. I took the text from RFC2630 Abstract, didn't check the later ones in that much detail to find out the changes since sections... :) > There follow a few more sections with other bells and whistles > leading to RFC 5652. Yes, but I do not think we need any of those bells and whistles. > Besides, even if the later RFCs are (mostly) *backward compatible* > with RFC 2315, they may still be adding useful stuff. This is just > speculation on my part, not actual knowledge. The PKCS#7 has been used to just put together buch of certificates and send them to other end in format that other ends certificate library can easily parse, and then take the certificates out from the PKCS#7 container and use them to validate the certificate used in the authentication. This is how it was used in IKEv1 and this is how I expect it to be used in IKEv2. I.e. it was mostly what we now have with the certificate bundle, but that ASN.1 blob was sent inband and using different format. In our IKEv1 code we just recursively went through the PKCS#7 blob and added all certificate and CRLs we found from there to the certificate manager and then tried to find suitable valid certificate based on the ID. We never had any code to send those PKCS#7 wrapped blobs, but I do remember that for some vendors that was almost the only format they supported (for certificate chains). My old isakmp test site seemed to have 26 connections using pkcs#7 format to send certs in from 5 different hosts. -- kivinen@iki.fi From kivinen@iki.fi Wed Nov 25 07:25:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 994013A6A79 for ; Wed, 25 Nov 2009 07:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 571yZbIif1YW for ; Wed, 25 Nov 2009 07:25:24 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 739D23A6A78 for ; Wed, 25 Nov 2009 07:25:24 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAPFPEDb015374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 17:25:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAPFPEb0014427; Wed, 25 Nov 2009 17:25:14 +0200 (EET) 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: <19213.19546.581975.240144@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 17:25:14 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E016D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA9@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE1@il-ex01.ad.checkpoint.com> <19213.13970.105797.850084@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E016D@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: IPsecme WG , Yoav Nir , Paul Hoffman Subject: Re: [IPsec] #117: Hash and URL interop X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:25:25 -0000 Yaron Sheffer writes: > Can you live with: > > Implementations MUST support HTTP. This is already in the RFC4306. > The behavior of other URL methods is not currently specified, so > such methods SHOULD NOT be used in the absence of a Standards Track > document defining them. This addition is ok for me, altough I do not think we need to have *Standard Track* documents to be able to use, I would just say "in the absens of document defining them". I think having information RFC telling how to use ftp URLs should be ok, especially as some people might be against making such document standard track document. -- kivinen@iki.fi From smoonen@us.ibm.com Wed Nov 25 07:34:24 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EAD13A6863; Wed, 25 Nov 2009 07:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[AWL=2.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeAhVangz9O7; Wed, 25 Nov 2009 07:34:22 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id AA8DE3A6829; Wed, 25 Nov 2009 07:34:22 -0800 (PST) Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e4.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id nAPFPi3T027927; Wed, 25 Nov 2009 10:25:44 -0500 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nAPFYGtJ108610; Wed, 25 Nov 2009 10:34:16 -0500 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nAPFXgGP002663; Wed, 25 Nov 2009 08:33:42 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nAPFXgkj002654; Wed, 25 Nov 2009 08:33:42 -0700 In-Reply-To: <19213.19546.581975.240144@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA9@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE1@il-ex01.ad.checkpoint.com> <19213.13970.105797.850084@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E016D@il-ex01.ad.checkpoint.com> <19213.19546.581975.240144@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: 064115A9:83CEEF47-85257679:00551253; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/25/2009 10:32:58 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/25/2009 10:32:58 AM, Serialize complete at 11/25/2009 10:32:58 AM, S/MIME Sign failed at 11/25/2009 10:32:58 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 11/25/2009 08:33:41, Serialize complete at 11/25/2009 08:33:41 Message-ID: Date: Wed, 25 Nov 2009 10:33:40 -0500 Content-Type: multipart/alternative; boundary="=_alternative 00556AA185257679_=" Cc: IPsecme WG , ipsec-bounces@ietf.org, Yoav Nir , Paul Hoffman Subject: Re: [IPsec] #117: Hash and URL interop X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:34:24 -0000 This is a multipart message in MIME format. --=_alternative 00556AA185257679_= Content-Type: text/plain; charset="US-ASCII" > > The behavior of other URL methods is not currently specified, so > > such methods SHOULD NOT be used in the absence of a Standards Track > > document defining them. > > This addition is ok for me, altough I do not think we need to have > *Standard Track* documents to be able to use, I would just say "in the > absens of document defining them". I think having information RFC > telling how to use ftp URLs should be ok, especially as some people > might be against making such document standard track document. I agree. As an aside, I would expect any such document not only to loosely specify the behavior of https or ftp URLs (for example), but also to introduce new notify types such as HTTPS_CERT_LOOKUP_SUPPORTED and FTP_CERT_LOOKUP_SUPPORTED. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Yaron Sheffer Cc: IPsecme WG , Yoav Nir , Paul Hoffman Date: 11/25/2009 10:25 AM Subject: Re: [IPsec] #117: Hash and URL interop Yaron Sheffer writes: > Can you live with: > > Implementations MUST support HTTP. This is already in the RFC4306. > The behavior of other URL methods is not currently specified, so > such methods SHOULD NOT be used in the absence of a Standards Track > document defining them. This addition is ok for me, altough I do not think we need to have *Standard Track* documents to be able to use, I would just say "in the absens of document defining them". I think having information RFC telling how to use ftp URLs should be ok, especially as some people might be against making such document standard track document. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 00556AA185257679_= Content-Type: text/html; charset="US-ASCII"
> > The behavior of other URL methods is not currently specified, so
> > such methods SHOULD NOT be used in the absence of a Standards Track
> > document defining them.
>
> This addition is ok for me, altough I do not think we need to have
> *Standard Track* documents to be able to use, I would just say "in the
> absens of document defining them". I think having information RFC
> telling how to use ftp URLs should be ok, especially as some people
> might be against making such document standard track document.

I agree.

As an aside, I would expect any such document not only to loosely specify the behavior of https or ftp URLs (for example), but also to introduce new notify types such as HTTPS_CERT_LOOKUP_SUPPORTED and FTP_CERT_LOOKUP_SUPPORTED.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Tero Kivinen <kivinen@iki.fi>
To: Yaron Sheffer <yaronf@checkpoint.com>
Cc: IPsecme WG <ipsec@ietf.org>, Yoav Nir <ynir@checkpoint.com>, Paul Hoffman <paul.hoffman@vpnc.org>
Date: 11/25/2009 10:25 AM
Subject: Re: [IPsec] #117: Hash and URL interop




Yaron Sheffer writes:
> Can you live with:
>
> Implementations MUST support HTTP.

This is already in the RFC4306.

> The behavior of other URL methods is not currently specified, so
> such methods SHOULD NOT be used in the absence of a Standards Track
> document defining them.

This addition is ok for me, altough I do not think we need to have
*Standard Track* documents to be able to use, I would just say "in the
absens of document defining them". I think having information RFC
telling how to use ftp URLs should be ok, especially as some people
might be against making such document standard track document.
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 00556AA185257679_=-- From harhittam@gmail.com Wed Nov 25 08:09:58 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FEA228C265 for ; Wed, 25 Nov 2009 08:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS530cbQlGIy for ; Wed, 25 Nov 2009 08:09:57 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 6E33228C0E7 for ; Wed, 25 Nov 2009 08:09:57 -0800 (PST) Received: by bwz23 with SMTP id 23so7421935bwz.29 for ; Wed, 25 Nov 2009 08:09:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=eZDba13ybYxEj89+cCqRtDDilEMs/QBsxFiO9B1Kcr0=; b=kSx6xncmapp7rLG02eva/xu25fJXObP8Fpn/zkxX4b6r4GChhPgYlmKg7S5PEPVGsl RwUZRAoh3gbHtzqCRcQpAZcQmQ36PMK4CISB1/AE9qCwFylYx/N73v2BrjROUiSCk9XX IMAxbykz13badrRWl4lm+k1n+DhBoOVt9Mrm8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=vCXwEVrghY6yK00p+leur0ZWWYL3FK9mFYsFeenJcFroYDXIaMLsUv9R2NATvxdmts kyeidin1Gqmo+7c8PeVNyyuRpIa9HmFZKmVaRwuG8IWJcKlT3MTwlVraW0KqnI6AKfZr 9oQMxSwEKz0qdp75X2BqKoU1vzehed2KIkBUA= MIME-Version: 1.0 Received: by 10.204.15.16 with SMTP id i16mr1121826bka.72.1259165388872; Wed, 25 Nov 2009 08:09:48 -0800 (PST) Date: Wed, 25 Nov 2009 18:09:48 +0200 Message-ID: From: Harhit Tam To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=000325554016b79e4a04793449f7 Subject: [IPsec] SS certificate question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:09:58 -0000 --000325554016b79e4a04793449f7 Content-Type: text/plain; charset=ISO-8859-1 Hello, I have two IPsec peers that shared self-signed certificates via a secure out-of-band channel. Where should I put the peer's certificate so that IKEv2 can use it for authentication? Is it the Peer Authorization Database? Regards, Harhit --000325554016b79e4a04793449f7 Content-Type: text/html; charset=ISO-8859-1 Hello,

I have two IPsec peers that shared self-signed certificates via a secure out-of-band channel.

Where should I put the peer's certificate so that IKEv2 can use it for authentication?

Is it the Peer Authorization Database?

Regards,

Harhit
--000325554016b79e4a04793449f7-- From paul.hoffman@vpnc.org Wed Nov 25 08:21:18 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 399233A6AC5 for ; Wed, 25 Nov 2009 08:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzUr3QIhzM2n for ; Wed, 25 Nov 2009 08:21:17 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 8F57C3A6AB4 for ; Wed, 25 Nov 2009 08:21:17 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAPGL1Qi071247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 09:21:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E016D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA9@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE1@il-ex01.ad.checkpoint.com> <19213.13970.105797.850084@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E016D@il-ex01.ad.checkpoint.com> Date: Wed, 25 Nov 2009 08:20:59 -0800 To: Yaron Sheffer , Tero Kivinen , Yoav Nir From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] #117: Hash and URL interop X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:21:18 -0000 At 4:44 PM +0200 11/25/09, Yaron Sheffer wrote: >Can you live with: > >Implementations MUST support HTTP. The behavior of other URL methods is not currently specified, so such methods SHOULD NOT be used in the absence of a Standards Track document defining them. No. There is no technical or interop reason for the SHOULD NOT. Everyone MUST support HTTP and the rest is up to them. If someone later specifies how to do FTP or whatever, that is fine. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Wed Nov 25 08:22:03 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BD5C3A6A00 for ; Wed, 25 Nov 2009 08:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.001 X-Spam-Level: X-Spam-Status: No, score=-6.001 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7a744H2g3jlN for ; Wed, 25 Nov 2009 08:22:02 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 547773A6947 for ; Wed, 25 Nov 2009 08:22:02 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAPGLmO0071300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 09:21:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19213.6296.58382.691986@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDA1213EA8@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88DFFE0@il-ex01.ad.checkpoint.com> <19213.6296.58382.691986@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 08:21:46 -0800 To: Tero Kivinen , Yaron Sheffer From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] #116: The AUTH payload signature X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:22:03 -0000 At 1:44 PM +0200 11/25/09, Tero Kivinen wrote: >Yaron Sheffer writes: >> Tero requested a clarification: I'm proposing to say that the >> certificate's hash algorithm does not determine the AUTH hash >> function (which is the negotiated PRF). Implementations may use the >> certificates received from a given peer as a hint for selecting a >> mutually-understood PRF with that peer. > >That I can accept. They are not unrelated, but certificate's hash >algorithm does not determine AUTH hash algorithm. +1 > > And yes, the last sentence refers to this text: >> >> To promote interoperability, implementations that support this type >> SHOULD support signatures that use SHA-1 as the hash function and >> SHOULD use SHA-1 as the default hash function when generating >> signatures. > >Do you have new proposed text? +1. :-) --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Wed Nov 25 08:30:56 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA2C3A6AA0 for ; Wed, 25 Nov 2009 08:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.002 X-Spam-Level: X-Spam-Status: No, score=-6.002 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DtA7IF960Ag for ; Wed, 25 Nov 2009 08:30:55 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B532E3A6AD9 for ; Wed, 25 Nov 2009 08:30:55 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAPGUn19071788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 09:30:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19213.11094.860914.790618@fireball.kivinen.iki.fi> References: <19211.59597.904754.490768@fireball.kivinen.iki.fi> <19213.11094.860914.790618@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 08:30:48 -0800 To: Tero Kivinen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] #122: Integrity proposals with combined algorithms X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:30:56 -0000 At 3:04 PM +0200 11/25/09, Tero Kivinen wrote: > > Are people OK with wording that says "MUST either offer an integrity > > algorithm or a single integrity algorithm of 'none'"? > >If you add "no" somewhere there (i.e. MUST either offer no integrity >algorithm...) then I can accept it. Er, right. MUST either offer no integrity algorithm or a single integrity algorithm of "none" Does anyone have a problem with this new wording? --Paul Hoffman, Director --VPN Consortium From smoonen@us.ibm.com Wed Nov 25 08:35:26 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FCE03A6AA7; Wed, 25 Nov 2009 08:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8q2hwPPI7Qg; Wed, 25 Nov 2009 08:35:25 -0800 (PST) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id 40A793A6AA3; Wed, 25 Nov 2009 08:35:25 -0800 (PST) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e38.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nAPGUaCt012485; Wed, 25 Nov 2009 09:30:36 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nAPGYv0P018244; Wed, 25 Nov 2009 09:35:10 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nAPARMDd006428; Wed, 25 Nov 2009 03:27:22 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nAPARMgv006382; Wed, 25 Nov 2009 03:27:22 -0700 In-Reply-To: References: <19211.59597.904754.490768@fireball.kivinen.iki.fi> <19213.11094.860914.790618@fireball.kivinen.iki.fi> MIME-Version: 1.0 X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/25/2009 11:34:35 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/25/2009 11:34:35 AM, Serialize complete at 11/25/2009 11:34:35 AM, S/MIME Sign failed at 11/25/2009 11:34:35 AM: The cryptographic key was not found, S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/25/2009 11:34:40 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/25/2009 11:34:40 AM, Serialize complete at 11/25/2009 11:34:40 AM, S/MIME Sign failed at 11/25/2009 11:34:40 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 11/25/2009 09:34:56, Serialize complete at 11/25/2009 09:34:56 To: Paul Hoffman X-KeepSent: 68D7C7F4:8EA0CD30-85257679:005AE6AD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen Message-ID: Date: Wed, 25 Nov 2009 11:34:54 -0500 Content-Type: multipart/alternative; boundary="=_alternative 005B10A085257679_=" Cc: IPsecme WG , ipsec-bounces@ietf.org, Tero Kivinen Subject: Re: [IPsec] #122: Integrity proposals with combined algorithms X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:35:26 -0000 This is a multipart message in MIME format. --=_alternative 005B10A085257679_= Content-Type: text/plain; charset="US-ASCII" > MUST either offer no integrity algorithm or a single integrity algorithm of "none" > > Does anyone have a problem with this new wording? I suggest we specify that one or the other as the preferred approach. Maybe add an additional sentence saying SHOULD for no transform and MAY for transform=none? Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Paul Hoffman To: Tero Kivinen Cc: IPsecme WG Date: 11/25/2009 11:31 AM Subject: Re: [IPsec] #122: Integrity proposals with combined algorithms At 3:04 PM +0200 11/25/09, Tero Kivinen wrote: > > Are people OK with wording that says "MUST either offer an integrity > > algorithm or a single integrity algorithm of 'none'"? > >If you add "no" somewhere there (i.e. MUST either offer no integrity >algorithm...) then I can accept it. Er, right. MUST either offer no integrity algorithm or a single integrity algorithm of "none" Does anyone have a problem with this new wording? --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 005B10A085257679_= Content-Type: text/html; charset="US-ASCII"
> MUST either offer no integrity algorithm or a single integrity algorithm of "none"
>
> Does anyone have a problem with this new wording?

I suggest we specify that one or the other as the preferred approach.  Maybe add an additional sentence saying SHOULD for no transform and MAY for transform=none?


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Tero Kivinen <kivinen@iki.fi>
Cc: IPsecme WG <ipsec@ietf.org>
Date: 11/25/2009 11:31 AM
Subject: Re: [IPsec] #122: Integrity proposals with combined algorithms




At 3:04 PM +0200 11/25/09, Tero Kivinen wrote:
> > Are people OK with wording that says "MUST either offer an integrity
> > algorithm or a single integrity algorithm of 'none'"?
>
>If you add "no" somewhere there (i.e. MUST either offer no integrity
>algorithm...) then I can accept it.

Er, right.

MUST either offer no integrity algorithm or a single integrity algorithm of "none"

Does anyone have a problem with this new wording?

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 005B10A085257679_=-- From paul.hoffman@vpnc.org Wed Nov 25 08:39:17 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F7253A6A00 for ; Wed, 25 Nov 2009 08:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.004 X-Spam-Level: X-Spam-Status: No, score=-6.004 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kfz24DqhIKlb for ; Wed, 25 Nov 2009 08:39:16 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 95A203A6893 for ; Wed, 25 Nov 2009 08:39:16 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAPGdAAu072333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Nov 2009 09:39:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19213.9738.693741.410069@fireball.kivinen.iki.fi> References: <19211.60135.834509.954897@fireball.kivinen.iki.fi> <19213.9738.693741.410069@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 08:39:08 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:39:17 -0000 Based on Tero and Yaron's responses, I have a different idea: - Leave all the tables in - Remove the numbers from every table - Removed the "reserved", "reserved to IANA", and "private use" lines - Precede each table with the following boilerplate paragraph: The following table only lists the entries that appeared in [IKEV2]. There may be new entries, private use values, and so on; see [IKEV2IANA] for up-to-date information. - Add [IKEV2IANA] to the Normative References; it will point to the URL of the IANA registry. --Paul Hoffman, Director --VPN Consortium From danmcd@sun.com Wed Nov 25 08:56:26 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5BF3A6AB5 for ; Wed, 25 Nov 2009 08:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTkzx2yPmspy for ; Wed, 25 Nov 2009 08:56:26 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 1B3F13A6AA3 for ; Wed, 25 Nov 2009 08:56:26 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAPGuKuU028953 for ; Wed, 25 Nov 2009 16:56:20 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.4) with ESMTP id nAPGuJA6001331 for ; Wed, 25 Nov 2009 11:56:20 -0500 (EST) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nAPGfD1n102376; Wed, 25 Nov 2009 11:41:13 -0500 (EST) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id nAPGfCVs102375; Wed, 25 Nov 2009 11:41:12 -0500 (EST) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Wed, 25 Nov 2009 11:41:12 -0500 From: Dan McDonald To: Harhit Tam Message-ID: <20091125164112.GA102338@sun.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ipsec@ietf.org Subject: Re: [IPsec] SS certificate question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:56:26 -0000 On Wed, Nov 25, 2009 at 06:09:48PM +0200, Harhit Tam wrote: > Hello, > > I have two IPsec peers that shared self-signed certificates via a secure > out-of-band channel. This sort of deployment is not as uncommon as some might think. > Where should I put the peer's certificate so that IKEv2 can use it for > authentication? > > Is it the Peer Authorization Database? The PAD isn't a certificate repository per se (from where your IKE gets its certificates is really implementation-specific), but the PAD would be the place to say (for example): Upon seeing IKE identity , verify with certificate . where is either the Distinguished Name or one of the Subject Alternative Names of the certificate . The PAD is where you say to trust the self-signed certificate. Where the certificate actually resides is up to your implementation. Hope this helps, Dan From danmcd@sun.com Wed Nov 25 09:00:38 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B7728C23F for ; Wed, 25 Nov 2009 09:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gr71nbA-qtyF for ; Wed, 25 Nov 2009 09:00:38 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id F024D3A6AA3 for ; Wed, 25 Nov 2009 09:00:37 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAPH0WeG010465 for ; Wed, 25 Nov 2009 17:00:33 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.4) with ESMTP id nAPH0Wta003188 for ; Wed, 25 Nov 2009 12:00:32 -0500 (EST) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id nAPGqu5P102451; Wed, 25 Nov 2009 11:52:57 -0500 (EST) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id nAPGqtYU102450; Wed, 25 Nov 2009 11:52:55 -0500 (EST) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Wed, 25 Nov 2009 11:52:55 -0500 From: Dan McDonald To: Paul Hoffman Message-ID: <20091125165255.GB102338@sun.com> References: <19211.60135.834509.954897@fireball.kivinen.iki.fi> <19213.9738.693741.410069@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.20 (2009-06-14) Cc: IPsecme WG Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 17:00:38 -0000 On Wed, Nov 25, 2009 at 08:39:08AM -0800, Paul Hoffman wrote: > - Add [IKEV2IANA] to the Normative References; it will point to the URL of > the IANA registry. Yes, this is better. Dan From paul.hoffman@vpnc.org Wed Nov 25 09:29:21 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B2183A6A62; Wed, 25 Nov 2009 09:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.006 X-Spam-Level: X-Spam-Status: No, score=-6.006 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbgc1sPth+M2; Wed, 25 Nov 2009 09:29:20 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id AD4BA3A6843; Wed, 25 Nov 2009 09:29:20 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAPHTEsQ075793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 10:29:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <19211.59597.904754.490768@fireball.kivinen.iki.fi> <19213.11094.860914.790618@fireball.kivinen.iki.fi> Date: Wed, 25 Nov 2009 09:29:10 -0800 To: Scott C Moonen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG , ipsec-bounces@ietf.org, Tero Kivinen Subject: Re: [IPsec] #122: Integrity proposals with combined algorithms X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 17:29:21 -0000 At 11:34 AM -0500 11/25/09, Scott C Moonen wrote: > > MUST either offer no integrity algorithm or a single integrity algorithm of "none" >> >> Does anyone have a problem with this new wording? > >I suggest we specify that one or the other as the preferred approach. Maybe add an additional sentence saying SHOULD for no transform and MAY for transform=none? I hate honing down that far: it confuses future developers. How about: MUST either offer no integrity algorithm or a single integrity algorithm of "none", with no integrity algorithm being the preferred method --Paul Hoffman, Director --VPN Consortium From smoonen@us.ibm.com Wed Nov 25 09:47:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 209483A687A; Wed, 25 Nov 2009 09:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.831 X-Spam-Level: X-Spam-Status: No, score=-5.831 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNo5ZAHobTIJ; Wed, 25 Nov 2009 09:47:51 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id 185663A694C; Wed, 25 Nov 2009 09:47:51 -0800 (PST) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e32.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nAPHgD6U028069; Wed, 25 Nov 2009 10:42:13 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nAPHlLLE181598; Wed, 25 Nov 2009 10:47:22 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nAPHlLoH029770; Wed, 25 Nov 2009 10:47:21 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nAPHlLAt029767; Wed, 25 Nov 2009 10:47:21 -0700 In-Reply-To: References: <19211.59597.904754.490768@fireball.kivinen.iki.fi> <19213.11094.860914.790618@fireball.kivinen.iki.fi> To: Paul Hoffman MIME-Version: 1.0 X-KeepSent: 8B3AA740:DF48C7F3-85257679:00614762; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/25/2009 12:43:09 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 11/25/2009 12:43:09 PM, Serialize complete at 11/25/2009 12:43:09 PM, S/MIME Sign failed at 11/25/2009 12:43:09 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 11/25/2009 10:47:20, Serialize complete at 11/25/2009 10:47:20 Message-ID: Date: Wed, 25 Nov 2009 12:47:19 -0500 Content-Type: multipart/alternative; boundary="=_alternative 006155B985257679_=" Cc: IPsecme WG , ipsec-bounces@ietf.org, Tero Kivinen Subject: Re: [IPsec] #122: Integrity proposals with combined algorithms X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 17:47:52 -0000 This is a multipart message in MIME format. --=_alternative 006155B985257679_= Content-Type: text/plain; charset="US-ASCII" > MUST either offer no integrity algorithm or a single integrity algorithm of "none", with no integrity algorithm being the preferred method Sounds good, thanks, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Paul Hoffman To: Scott C Moonen/Raleigh/IBM@IBMUS Cc: IPsecme WG , ipsec-bounces@ietf.org, Tero Kivinen Date: 11/25/2009 12:29 PM Subject: Re: [IPsec] #122: Integrity proposals with combined algorithms At 11:34 AM -0500 11/25/09, Scott C Moonen wrote: > > MUST either offer no integrity algorithm or a single integrity algorithm of "none" >> >> Does anyone have a problem with this new wording? > >I suggest we specify that one or the other as the preferred approach. Maybe add an additional sentence saying SHOULD for no transform and MAY for transform=none? I hate honing down that far: it confuses future developers. How about: MUST either offer no integrity algorithm or a single integrity algorithm of "none", with no integrity algorithm being the preferred method --Paul Hoffman, Director --VPN Consortium --=_alternative 006155B985257679_= Content-Type: text/html; charset="US-ASCII"
> MUST either offer no integrity algorithm or a single integrity algorithm of "none", with no integrity algorithm being the preferred method

Sounds good, thanks,


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen


From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Scott C Moonen/Raleigh/IBM@IBMUS
Cc: IPsecme WG <ipsec@ietf.org>, ipsec-bounces@ietf.org, Tero Kivinen <kivinen@iki.fi>
Date: 11/25/2009 12:29 PM
Subject: Re: [IPsec] #122: Integrity proposals with combined algorithms




At 11:34 AM -0500 11/25/09, Scott C Moonen wrote:
> > MUST either offer no integrity algorithm or a single integrity algorithm of "none"
>>
>> Does anyone have a problem with this new wording?
>
>I suggest we specify that one or the other as the preferred approach.  Maybe add an additional sentence saying SHOULD for no transform and MAY for transform=none?

I hate honing down that far: it confuses future developers. How about:

MUST either offer no integrity algorithm or a single integrity algorithm of "none", with no integrity algorithm being the preferred method

--Paul Hoffman, Director
--VPN Consortium

--=_alternative 006155B985257679_=-- From root@core3.amsl.com Wed Nov 25 10:00:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D12F33A6AB9; Wed, 25 Nov 2009 10:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091125180001.D12F33A6AB9@core3.amsl.com> Date: Wed, 25 Nov 2009 10:00:01 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-aes-ctr-ikev2-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:00:01 -0000 --NextPart 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 : Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 Author(s) : S. Shen, Y. Mao, S. murthy Filename : draft-ietf-ipsecme-aes-ctr-ikev2-03.txt Pages : 17 Date : 2009-11-25 This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit initialization vector, by IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-aes-ctr-ikev2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-25095611.I-D@ietf.org> --NextPart-- From kohn.jack@gmail.com Wed Nov 25 16:17:48 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0862D3A67CC for ; Wed, 25 Nov 2009 16:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t8MEIOSyRrH for ; Wed, 25 Nov 2009 16:17:47 -0800 (PST) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id 193793A67AF for ; Wed, 25 Nov 2009 16:17:47 -0800 (PST) Received: by yxe4 with SMTP id 4so261976yxe.32 for ; Wed, 25 Nov 2009 16:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=44XtFcxBPKn/obXUUk/YCui+jSjqwTnAqzwSy65t1dA=; b=WI0fBL7lRlFqs/gOKmP41tIjjJhDAVQ1kmLiIbUtUX4qztI6XH3cKVA0XQ7sEifAfM kszuOPJ14DpReLCvo8/0Fb0tL0IAqgQe2uXMMBsN90dDWnjD42A4kgH0L2ZUj8N5Id1A SnjgaHlU/dBcmR7XGLlo1sDfJE3eanp77D01U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=yFH7kYVkmVE89R5yjKvTJ5u0QVbjSrMYRVAeB8ELC9+Q6bAjku2iWsOhXXzRzHnUGe MmjpmSegWwmXaWIvt06RMAYNWDZU9qHhMVwJoYs/df459cO3SkWZz6z2V4uKxzytI+GA Nz1qy002e9bthB0zeFi6yF8KJmQvcMWic9zmU= MIME-Version: 1.0 Received: by 10.90.16.9 with SMTP id 9mr11178314agp.11.1259194653500; Wed, 25 Nov 2009 16:17:33 -0800 (PST) In-Reply-To: References: Date: Thu, 26 Nov 2009 05:47:33 +0530 Message-ID: From: Jack Kohn To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 00:17:48 -0000 > >> Now, assume that we were using WESP. >> >> You would need just two rules in your filter database saying the >> following: >> >> Incoming Pkt is WESP integrity Protected, then look at the nth bit and >> if its a OSPF HELLO, put it in Ospfv3HighPrioQueue. >> Incoming Pkt is WESP integrity Protected, then look at the mth bit and >> if its a OSPF ACK, put it in Ospfv3HighPrioQueue. > > This is much simpler, but also potentially inaccurate. Specifically, because > it pays no attention to the SAD info, it would grab ANY packet that passes > through the router, uses WESP, and that matches the bits that one uses to > decide of a packet is an OSPF HELLO or ACK. Obviously the following rules would only be applied if the IP packet was addressed to the router that was doing these checks. This way it will not trap the other packets passing through this router. > >> Thus one now needs only 2 rules in the HW to prioritize packets for >> *all* OSPF adjacencies. > > Unless you used some other rules to narrow down the set of packets subject > to these quick checks, other packets may be grabbed. Same as above. It is trivial to find out if the packet is locally bound, or needs to be routed. Jack From sean.s.shen@gmail.com Wed Nov 25 19:04:33 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8518E3A68BC for ; Wed, 25 Nov 2009 19:04:33 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOPqCB1g5I1R for ; Wed, 25 Nov 2009 19:04:32 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id CF1B63A6874 for ; Wed, 25 Nov 2009 19:04:32 -0800 (PST) Received: by pwi6 with SMTP id 6so249920pwi.29 for ; Wed, 25 Nov 2009 19:04:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Jao9dg3Wlj9iMqIHZp5xSsR3kobY4GYUdIQ+9LfU3Ac=; b=F2Fp2PIjm7yGRYVOk2FvnmDbOMP8rapUynIQZHaZQOCPD+lUE/l7tUvIxoL2/a8MQ2 oiuk0WfcXPl5MFNGNKP7ZeavYHrx4G2BCfY8JGIEKHLZ95q4yqpTdqxw4t2OFkvy99FX 9jqfvvofirFzbXwydojTxbQXDJvKvpeR4pvRY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JGOIviwz8M5Pr4mjOiDV98saRbbm7FKTUmzcM63tlDGWFa6OhFHC/TyXqHjLWop8PK Wl5hs1yxNYpBqcq5Tm3APhgweQ97X4I/7ySQhXJwcnOVx0Skwu5n3mZOBRpPTHP6iOpF +9h3BukhYn7cH5iUlrYZ0rnlXcV0xdzWq0QoY= MIME-Version: 1.0 Received: by 10.115.132.5 with SMTP id j5mr17257967wan.129.1259204663627; Wed, 25 Nov 2009 19:04:23 -0800 (PST) Date: Thu, 26 Nov 2009 11:04:23 +0800 Message-ID: <80b5a9190911251904q3e774609hc0db0c3267190124@mail.gmail.com> From: Sean Shen To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [IPsec] draft-ietf-ipsecme-aes-ctr-ikev2-03 was submitted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 03:04:33 -0000 Dear IPsec people, The updated version of draft-ietf-ipsecme-aes-ctr-ikev2 was just submitted: http://www.ietf.org/staging/draft-ietf-ipsecme-aes-ctr-ikev2-03.txt Abstract: This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit initialization vector, by IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. Your reviews will be appreciated. Best, Sean Besides typos and grammas, the major changes due to previous comments are: #1 section 2.2 and 2.3 involving rounds and blocksizes intro of AES algorithms were considered unnecessary and dropped. Hence currently sectioin 2 has no subsections. #2 The keysize requirements which were in section 2.2 were moved to the beginning of section 5. #3 The reference to the roadmap draft was removed since it was not quoted in the document. From kivinen@iki.fi Thu Nov 26 03:17:01 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4313A6BCD; Thu, 26 Nov 2009 03:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHqhFRyMV5oB; Thu, 26 Nov 2009 03:17:00 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 36BA03A6BC7; Thu, 26 Nov 2009 03:16:59 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAQBGo4b003873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 13:16:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAQBGmi2001665; Thu, 26 Nov 2009 13:16:48 +0200 (EET) 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: <19214.25504.547607.471062@fireball.kivinen.iki.fi> Date: Thu, 26 Nov 2009 13:16:48 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <19211.59597.904754.490768@fireball.kivinen.iki.fi> <19213.11094.860914.790618@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Cc: IPsecme WG , ipsec-bounces@ietf.org Subject: Re: [IPsec] #122: Integrity proposals with combined algorithms X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 11:17:01 -0000 Paul Hoffman writes: > MUST either offer no integrity algorithm or a single integrity > algorithm of "none", with no integrity algorithm being the preferred > method That is fine for me. It would also be fine for me to change "preferred" with "RECOMMENDED" (RFC2119 synonym for SHOULD), but I can accept on not using RFC2119 language too. -- kivinen@iki.fi From kivinen@iki.fi Thu Nov 26 03:26:08 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 309A03A6BC8 for ; Thu, 26 Nov 2009 03:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIxoEXLS87yB for ; Thu, 26 Nov 2009 03:26:07 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 0510F3A68A8 for ; Thu, 26 Nov 2009 03:26:06 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAQBQ0Fu003754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 13:26:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAQBPxQ7002659; Thu, 26 Nov 2009 13:25:59 +0200 (EET) 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: <19214.26055.878779.973603@fireball.kivinen.iki.fi> Date: Thu, 26 Nov 2009 13:25:59 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <19211.60135.834509.954897@fireball.kivinen.iki.fi> <19213.9738.693741.410069@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Cc: IPsecme WG Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 11:26:08 -0000 Paul Hoffman writes: > Based on Tero and Yaron's responses, I have a different idea: > > - Leave all the tables in I think the encryption, hash algorithm etc tables could be removed completely, i.e. the Transform type n tables in section 3.3.2. Those tables change quite often, and they are not really needed for implementation, as almost every implementation will anyways only implement some of those, and/or offer a way to easily add new algorithms when those come. > - Removed the "reserved", "reserved to IANA", and "private use" lines > - Precede each table with the following boilerplate paragraph: > The following table only lists the entries that appeared > in [IKEV2]. There may be new entries, private use values, > and so on; see [IKEV2IANA] for up-to-date information. > - Add [IKEV2IANA] to the Normative References; it will point to the > URL of the IANA registry. These all are ok for me. > - Remove the numbers from every table I would rather keep the numbers for those tables which are really needed for implementing the protocol. I hate when I am implementing something and reading the RFC, and then suddenly I notice that I need to go and fetch some url somewhere to find the actual numbers, even worse when I am doing that in airplane or similar where I do not have network connectivity... Usually I assume that if I need to implement RFCxxxx, I should be able to do it mostly by using just that RFC or some other RFCs. This is not true always as there are references to the crypto algorithms found in textbooks, or standards defined by other bodies, but here I do not think there is reason to require using external reference. The numbers that are there in the tables are not going to change, so they will not get outdated, they will not get to be wrong. There might be new ones added, and the warning you propose should take care of that. If there would be an possiblity that for example Exchanget type IKE_AUTH could change from its current value of 35 to something else, then I would agree leaving it out from the RFC, but as it is going to be that same number forever, I do not see any reason why I should use indirection to find out what that number is. -- kivinen@iki.fi From paul.hoffman@vpnc.org Thu Nov 26 09:11:23 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A962E28C11A for ; Thu, 26 Nov 2009 09:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.007 X-Spam-Level: X-Spam-Status: No, score=-6.007 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIDy5t-qbNmz for ; Thu, 26 Nov 2009 09:11:21 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id CDCE128C149 for ; Thu, 26 Nov 2009 09:11:20 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAQHBDe8053466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 10:11:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19214.26055.878779.973603@fireball.kivinen.iki.fi> References: <19211.60135.834509.954897@fireball.kivinen.iki.fi> <19213.9738.693741.410069@fireball.kivinen.iki.fi> <19214.26055.878779.973603@fireball.kivinen.iki.fi> Date: Thu, 26 Nov 2009 09:11:13 -0800 To: Tero Kivinen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 17:11:23 -0000 At 1:25 PM +0200 11/26/09, Tero Kivinen wrote: >Paul Hoffman writes: > > - Remove the numbers from every table > >I would rather keep the numbers for those tables which are really >needed for implementing the protocol. And here we disagree completely. >I hate when I am implementing something and reading the RFC, and then >suddenly I notice that I need to go and fetch some url somewhere to >find the actual numbers, even worse when I am doing that in airplane >or similar where I do not have network connectivity... In this case, you only need to fetch a single page from IANA for all the tables. If you did that for any of the tables, you would have it for all of them. It does not feel appropriate to optimize for the case of someone coding IPsec without Internet access for a few hours. --Paul Hoffman, Director --VPN Consortium From yaronf@checkpoint.com Thu Nov 26 09:24:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E0028C0E7 for ; Thu, 26 Nov 2009 09:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc0TRNvZZJ6W for ; Thu, 26 Nov 2009 09:24:51 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 09CA328C10A for ; Thu, 26 Nov 2009 09:24:49 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nAQHOgGo010848; Thu, 26 Nov 2009 19:24:42 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 26 Nov 2009 19:24:48 +0200 From: Yaron Sheffer To: Paul Hoffman , Tero Kivinen Date: Thu, 26 Nov 2009 19:24:46 +0200 Thread-Topic: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis Thread-Index: Acpuu4Ljx8BcCo2tSmWmUwdvApuGJwAAGIbA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0341@il-ex01.ad.checkpoint.com> References: <19211.60135.834509.954897@fireball.kivinen.iki.fi> <19213.9738.693741.410069@fireball.kivinen.iki.fi> <19214.26055.878779.973603@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 17:24:52 -0000 Given the amount of interest on the list, I prefer the "do nothing" approac= h. Just add this text somewhere (maybe multiple times): This table is (these tables are) only current as of the publication date o= f RFC 4306. Other values may have been added since, or will be added after = the publication of this document. Implementors are advised to refer to [IAN= A] for the latest values. And be done with it. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Thursday, November 26, 2009 19:11 > To: Tero Kivinen > Cc: IPsecme WG > Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from > IKEv2bis >=20 > At 1:25 PM +0200 11/26/09, Tero Kivinen wrote: > >Paul Hoffman writes: > > > - Remove the numbers from every table > > > >I would rather keep the numbers for those tables which are really > >needed for implementing the protocol. >=20 > And here we disagree completely. >=20 > >I hate when I am implementing something and reading the RFC, and then > >suddenly I notice that I need to go and fetch some url somewhere to > >find the actual numbers, even worse when I am doing that in airplane > >or similar where I do not have network connectivity... >=20 > In this case, you only need to fetch a single page from IANA for all the > tables. If you did that for any of the tables, you would have it for all > of them. >=20 > It does not feel appropriate to optimize for the case of someone coding > IPsec without Internet access for a few hours. >=20 > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From A.Hoenes@TR-Sys.de Thu Nov 26 14:42:59 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F5F93A6921 for ; Thu, 26 Nov 2009 14:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.046 X-Spam-Level: ** X-Spam-Status: No, score=2.046 tagged_above=-999 required=5 tests=[AWL=0.795, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckXkWPOFMxYb for ; Thu, 26 Nov 2009 14:42:58 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id D7AFD3A687E for ; Thu, 26 Nov 2009 14:42:57 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA211485315; Thu, 26 Nov 2009 23:41:55 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA09449; Thu, 26 Nov 2009 23:41:54 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200911262241.XAA09449@TR-Sys.de> To: ipsec@ietf.org Date: Thu, 26 Nov 2009 23:41:54 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] draft-ietf-ipsecme-aes-ctr-ikev2-03 was submitted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 22:42:59 -0000 Folks, I'd like to confirm that my previously raised concerns regarding draft-ietf-ipsecme-aes-ctr-ikev2-02 have been resolved in the -03 version. Thanks to the authors for discussion and their cooperation. This draft now seems ready to proceed. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From paul.hoffman@vpnc.org Thu Nov 26 15:28:09 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79A43A696C for ; Thu, 26 Nov 2009 15:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.009 X-Spam-Level: X-Spam-Status: No, score=-6.009 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZWTTA61+xlM for ; Thu, 26 Nov 2009 15:28:09 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 393A73A67AC for ; Thu, 26 Nov 2009 15:28:09 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAQNS2Ps073251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Nov 2009 16:28:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0341@il-ex01.ad.checkpoint.com> References: <19211.60135.834509.954897@fireball.kivinen.iki.fi> <19213.9738.693741.410069@fireball.kivinen.iki.fi> <19214.26055.878779.973603@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0341@il-ex01.ad.checkpoint.com> Date: Thu, 26 Nov 2009 15:28:01 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 23:28:10 -0000 At 7:24 PM +0200 11/26/09, Yaron Sheffer wrote: >Given the amount of interest on the list, I prefer the "do nothing" approach. That makes no sense. People seem interested in fixing the problem of the lists being confusing. There is nothing confusing about removing the assigned numbers: it only causes a developer who is actively coding at the moment to grab one file from IANA. That file will contain all of the values needed for developing from IKEv2bis (including the two new values we are assigning), and will also contain values and pointers for other extensions in which they might be interested. Removing the assigned numbers also causes people who will be expanding on IKEv2bis to actually fetch the IANA registry before they do their work. We have a recent example of why that would be useful. --Paul Hoffman, Director --VPN Consortium From svanru@gmail.com Fri Nov 27 00:42:15 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0043A6826 for ; Fri, 27 Nov 2009 00:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, XMAILER_MIMEOLE_OL_7533E=0.513] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdvgiLhm-YCz for ; Fri, 27 Nov 2009 00:42:14 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id E651E3A67D1 for ; Fri, 27 Nov 2009 00:42:13 -0800 (PST) Received: by ewy6 with SMTP id 6so355161ewy.29 for ; Fri, 27 Nov 2009 00:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=p4C298Za1uCYAs7hrxPXwgI9+8YTH4IQhyKcGwyP3nk=; b=mu0TKJ6lJZbye8woP/jOjyeerPuHqNLleJCmFtQHgSiGTLfuvU9Hcev8JhcX8n9WGA x/smvQl52nyCX5nSSEUx2IwdR91UDrTu4suYW7qfZ2r1t32z/apAJiubtCC1Q51rB5M+ lkZhqqh2SOwAtXb6idjrj8xEjuYAVhA29mTXM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=gFt68ZjGrMeZDaB2gNk2Ej4/5veqE0cmvrNaPIqahp4Di3y7daYAvSDCutB4G6Ab/q smaBDOnk8ZglRNoDNIMRmfsO3PqblLGAqb1Id0OCeJPSVJLfZDnfBaDeHsO/eoKj+y/P HiRXIg/TTooaJLnncwXjEWCASVFzuIYmht93Q= Received: by 10.213.0.151 with SMTP id 23mr553860ebb.43.1259311324130; Fri, 27 Nov 2009 00:42:04 -0800 (PST) Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 16sm815818ewy.14.2009.11.27.00.42.02 (version=SSLv3 cipher=RC4-MD5); Fri, 27 Nov 2009 00:42:03 -0800 (PST) Message-ID: <4A045CD937B940C08E6E32600C6EA52C@trustworks.com> From: "Valery Smyslov" To: "IPsecme WG" , "Paul Hoffman" References: <19211.60135.834509.954897@fireball.kivinen.iki.fi><19213.9738.693741.410069@fireball.kivinen.iki.fi><19214.26055.878779.973603@fireball.kivinen.iki.fi><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0341@il-ex01.ad.checkpoint.com> Date: Fri, 27 Nov 2009 11:42:51 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4963.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 08:42:15 -0000 Hi, let me pop into with my 2 cents. As an implementer, I strongly dislike an idea to remove all the numbers from the RFC. In my opinion, that would confuse people even more than now, for the following reasons: 1. Magic numbers would become splited between two sources (note, that not all of them are listed in IANA, for example payload types are, but Proposal and Transform substructures types are not, they are specified in the RFC only). 2. IANA registry already contains some very specific entries (like, for example, those that came from RFC4595) and their number will be increasing. I think, those numbers would confuse some implementers, who might be thinking that they need to support all of them. 3. Sometimes there might be difficulties in matching names from RFC with IANA entries. For example, IANA registry has an entry named ENCR_AES-CCM_8, but in RFC5282 this algorithm is called AEAD_AES_128_CCM_SHORT_8. Are you sure these names reference the same algorithm? I prefer to check their IDs in RFC and in IANA registry. 4. Some entries in Diffie-Hellman Group Transform IDs table do not really assign individual numbers, but instead point to other documens, even to RFC4306 itself, where the numbers are assigned. By the way, some magic numbers in RFC4306 are present not only in tables, but in text also (for example Payload Types, TS Types). Do they need to be removed from text also? What about EAP Message format and magic numbers? Remove and just reference RFC3748 (or IANA entry for EAP)? I think, removing all magic numbers from the RFC would make implementing less convinient and more error-prone, so I strongly support either "do nothing" approach, or Tero's suggestion. Those numbers won't change, so their presence must not hurt, just will make implementing of base protocol more convinient. Regards, Smyslov Valery. ----- Original Message ----- From: "Paul Hoffman" To: "IPsecme WG" Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis > At 7:24 PM +0200 11/26/09, Yaron Sheffer wrote: > >Given the amount of interest on the list, I prefer the "do nothing" approach. > > That makes no sense. People seem interested in fixing the problem of the lists being confusing. > > There is nothing confusing about removing the assigned numbers: it only causes a developer who is actively coding at the moment to grab one file from IANA. That file will contain all of the values needed for developing from IKEv2bis (including the two new values we are assigning), and will also contain values and pointers for other extensions in which they might be interested. > > Removing the assigned numbers also causes people who will be expanding on IKEv2bis to actually fetch the IANA registry before they do their work. We have a recent example of why that would be useful. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Fri Nov 27 03:07:35 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69063A6918 for ; Fri, 27 Nov 2009 03:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCRN03kf3gT5 for ; Fri, 27 Nov 2009 03:07:35 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF903A6901 for ; Fri, 27 Nov 2009 03:07:34 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nARB7ONX011069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 13:07:24 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nARB7M3d013481; Fri, 27 Nov 2009 13:07:22 +0200 (EET) 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: <19215.45802.726722.524904@fireball.kivinen.iki.fi> Date: Fri, 27 Nov 2009 13:07:22 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <19211.60135.834509.954897@fireball.kivinen.iki.fi> <19213.9738.693741.410069@fireball.kivinen.iki.fi> <19214.26055.878779.973603@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0341@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 9 min Cc: IPsecme WG Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 11:07:36 -0000 Paul Hoffman writes: > At 7:24 PM +0200 11/26/09, Yaron Sheffer wrote: > >Given the amount of interest on the list, I prefer the "do nothing" > approach. > > That makes no sense. People seem interested in fixing the problem of > the lists being confusing. I agree that we should do something. > There is nothing confusing about removing the assigned numbers: it > only causes a developer who is actively coding at the moment to grab > one file from IANA. That file will contain all of the values needed > for developing from IKEv2bis (including the two new values we are > assigning), and will also contain values and pointers for other > extensions in which they might be interested. Not only those who are coding, but also those are debugging or supporting implementations, as quite often they do not remember all the numbers or the packet formats exactly, so they use the RFC to check out the packet formats and numbers, and only if numbers are not there then they need to go to IANA. > Removing the assigned numbers also causes people who will be > expanding on IKEv2bis to actually fetch the IANA registry before > they do their work. We have a recent example of why that would be > useful. I do not think this would have caused anything, as I most likely would have also picked numbers 40, and 41 anyways because I remember that 39 was last number used in RFC4306... There is reason why there is IANA assignment phase in the RFC assignment process, so there was no harm done even when someone took some numbers instead of using TBA1 and TBA2. If we split this to three parts: 1) I think almost everybody can agree that we can remove RESERVED and PRIVATE use ranges and numbers from the all tables, and add notice saying these are partial lists and go and check IANA for full list. 2) I think quite a lot of people agree that we should remove algorithm tables i.e ENCR_*, PRF_*, AUTH_*, Diffie-Hellman groups, extended sequence number tables and IPCOMP_*, i.e. all Transform type 1-5 tables and IPCOMP transform ID table from the RFC. 3) The thing we do not all agree on is whether to keep the numbers for the rest of the tables. I.e. do we want to remove numbers from rest? I myselfo would say yes for 1, and 2, and no for 3. -- kivinen@iki.fi From paul.hoffman@vpnc.org Fri Nov 27 09:17:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4E5C3A6A00 for ; Fri, 27 Nov 2009 09:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.01 X-Spam-Level: X-Spam-Status: No, score=-6.01 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 294zyrJgCwMw for ; Fri, 27 Nov 2009 09:17:27 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id E81EC3A686E for ; Fri, 27 Nov 2009 09:17:26 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nARHHHSs028367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 10:17:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A045CD937B940C08E6E32600C6EA52C@trustworks.com> References: <19211.60135.834509.954897@fireball. kivinen.iki.fi><19213.9738.693741.41 0069@fireball.kivinen.iki.fi><19214. 26055.878779.973603@fireball.kivinen.iki.fi><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0341@il-ex01.ad.checkpoin t.com> <4A045CD937B940C08E6E32600C6EA52C@trustworks.com> Date: Fri, 27 Nov 2009 09:16:33 -0800 To: "Valery Smyslov" , "IPsecme WG" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 17:17:28 -0000 At 11:42 AM +0300 11/27/09, Valery Smyslov wrote: >In my opinion, that would confuse people even more than now, for the >following reasons: > >1. Magic numbers would become splited between two sources (note, that not >all of them > are listed in IANA, for example payload types are, but Proposal and >Transform > substructures types are not, they are specified in the RFC only). This is incorrect. The proposal is to remove the value numbers from the tables, not the figures that contain the substructures. Anything that is only in the RFC would obviously not be removed. >2. IANA registry already contains some very specific entries (like, for >example, > those that came from RFC4595) and their number will be increasing. I >think, > those numbers would confuse some implementers, who might be thinking > that they need to support all of them. If a developer does not know how to read the IANA tables, we are all in trouble. Nothing in the tables says "you must implement every thing in these tables", of course. Are you proposing that we get rid of the IANA registry altogether, or we hide it from developers? If not, how do you rectify this with your concern about confusion? I am now deeply concerned with this WG's relationship to the IANA registry. >3. Sometimes there might be difficulties in matching names from RFC with >IANA entries. > For example, IANA registry has an entry named ENCR_AES-CCM_8, but in > RFC5282 this algorithm is called AEAD_AES_128_CCM_SHORT_8. Are you sure > these names reference the same algorithm? I prefer to check their IDs in >RFC > and in IANA registry. This is a bug in the IANA registry that needs to be fixed. It is not related to the values being in the RFC. Tero has spent a lot of time trying to fix the registry, but clearly we need more effort here. I will certainly make sure that the names in the registry match those in RFC 4306, and that the exact names are used in IKEv2bis. >4. Some entries in Diffie-Hellman Group Transform IDs table do not really >assign > individual numbers, but instead point to other documens, even to RFC4306 >itself, > where the numbers are assigned. Again, I am concerned that you think we should get rid of the IANA registry. That is not how the IETF works. >By the way, some magic numbers in RFC4306 are present not only in tables, >but >in text also (for example Payload Types, TS Types). Do they need to be >removed >from text also? Yes, in my current draft, I already did that, and repeated the boilerplate. > What about EAP Message format and magic numbers? Remove and just reference RFC3748 (or IANA entry for EAP)? No, those were left in because they came from an RFC, not from a particular IANA registry where the names match what we have in IKEv2bis. >I think, removing all magic numbers from the RFC would make implementing >less convinient Yes. >and more error-prone No. >, so I strongly support either "do >nothing" >approach, or Tero's suggestion. This is completely inconsistent. Tero's approach would lead you to need the IANA registry to implement IKEv2. >Those numbers won't change, so their >presence must not hurt, This is probably incorrect. In many WGs, when errors are found in old definitions, the error is corrected *and a new value is assigned*. That is the only way to assure interoperability. >just will make implementing of base protocol more >convinient. The goal of our work is clarity and interoperability, not convenience, particularly when the inconvenience is remedied by one extra lookup. --Paul Hoffman, Director --VPN Consortium From svanru@gmail.com Fri Nov 27 12:11:48 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02E153A68AF for ; Fri, 27 Nov 2009 12:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN8waHTrpSJm for ; Fri, 27 Nov 2009 12:11:40 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 553443A6A82 for ; Fri, 27 Nov 2009 12:11:35 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id l26so678411fgb.13 for ; Fri, 27 Nov 2009 12:11:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=w4Fyk1iArxeYBSUuncjtUb3aAudplC7SQiGoQc6ZqPY=; b=DhqK3sZ0vA/uwQDriEBg66o/FDvOQUKa42IHmkJ1/tU/UtIVM8QU8QH1X+T6jwHxpz XafTsmhNCu5KWDF18ptVztxdCPXSX+Y/tJA874ghhlm3llps7cbpPXy3XWGmjDNUocjM QguNEJs6mJ8sYW2i+6zb/vLmU1Xj6UnFL9/fw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=C457MCunIVOZKPs5GnwrqgCDgV1JsBZLRgpFbt5YCyTWLp6CO20X/yGeg3UWeKCROS cXCRVnKUmfxpevV+nKr2knjpUuqQBR27At6Vxwgv8nZVDJzw/kDR2CAmjjwt3ix0rvQN d/l8e9E/fxszoU5qnqsHa+GSC9gP0G55CbaSA= Received: by 10.103.84.32 with SMTP id m32mr513236mul.33.1259352687013; Fri, 27 Nov 2009 12:11:27 -0800 (PST) Received: from chichi (ppp85-140-117-123.pppoe.mtu-net.ru [85.140.117.123]) by mx.google.com with ESMTPS id s10sm5281455muh.48.2009.11.27.12.11.25 (version=SSLv3 cipher=RC4-MD5); Fri, 27 Nov 2009 12:11:25 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "IPsecme WG" , "Paul Hoffman" References: <19211.60135.834509.954897@fireball. kivinen.iki.fi><19213.9738.693741.41 0069@fireball.kivinen.iki.fi><19214. 26055.878779.973603@fireball.kivinen.iki.fi><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0341@il-ex01.ad.checkpoin t.com> <4A045CD937B940C08E6E32600C6EA52C@trustworks.com> Date: Fri, 27 Nov 2009 23:11:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 20:11:48 -0000 Hi Paul, please, see inline. >>2. IANA registry already contains some very specific entries (like, for >>example, >> those that came from RFC4595) and their number will be increasing. I >>think, >> those numbers would confuse some implementers, who might be thinking >> that they need to support all of them. > > If a developer does not know how to read the IANA tables, we are all in > trouble. Nothing in the tables says "you must implement every thing in > these tables", of course. > > Are you proposing that we get rid of the IANA registry altogether, or we > hide it from developers? Not, of course. > If not, how do you rectify this with your concern about confusion? For someone, who spent quite a lot of time working in this area, it is not difficult fo figure out what is really important and what is not. But, I think, a newcomer could be confused by a long list of all possible numbers. >>3. Sometimes there might be difficulties in matching names from RFC with >>IANA entries. >> For example, IANA registry has an entry named ENCR_AES-CCM_8, but in >> RFC5282 this algorithm is called AEAD_AES_128_CCM_SHORT_8. Are you >> sure >> these names reference the same algorithm? I prefer to check their IDs >> in >>RFC >> and in IANA registry. > > This is a bug in the IANA registry that needs to be fixed. It is not > related to the values being in the RFC. Tero has spent a lot of time > trying to fix the registry, but clearly we need more effort here. I will > certainly make sure that the names in the registry match those in RFC > 4306, and that the exact names are used in IKEv2bis. For RFC4306 that seems to be true. >>4. Some entries in Diffie-Hellman Group Transform IDs table do not really >>assign >> individual numbers, but instead point to other documens, even to >> RFC4306 >>itself, >> where the numbers are assigned. > > Again, I am concerned that you think we should get rid of the IANA > registry. That is not how the IETF works. No, you didn't get the point. I meant that Diffie-Hellman Group Transform IDs table in two cases doesn't assign individual numbers, just ranges. For example: 1-2 Defined in Appendix B [RFC4306] 14-18 Defined in [RFC3526] [RFC3526] So, in first case it just points back to RFC4306 Appendix B, where the actual numbers (what is 1 and what is 2) are assigned. Probably it may (and must) be changed, but in its current form it's ridiculos - you went to IANA for real numbers and have found only pointer back to RFC4306 where you just have come from... >> What about EAP Message format and magic numbers? Remove and just >> reference RFC3748 (or IANA entry for EAP)? > > No, those were left in because they came from an RFC, not from a > particular IANA registry where the names match what we have in IKEv2bis. EAP numbers listed in RFC4306 might also be changed in future, so from your logic it's better just to point to http://www.iana.org/assignments/eap-numbers, right? >>I think, removing all magic numbers from the RFC would make implementing >>less convinient > > Yes. > >>and more error-prone > > No. I don't agree with you. Remember, when IKEv2 was being developed, one of the motivations for single self-contained document was complaint from implementers that having 3 RFC (2408, 2409, 2407) for IKEv1 was very inconvinient and provoked confusions that led to interoperability problems. Now you suggest to make IKEv2 not self-contained again. Of course, I understand that IANA registry is not another RFC, but I still prefer single self-contained document for core protocol. If you need extensions - go to IANA and look for added numbers, but core protocol must be implementable reading as few sources, as possible, preferrably one. >>, so I strongly support either "do >>nothing" >>approach, or Tero's suggestion. > > This is completely inconsistent. Tero's approach would lead you to need > the IANA registry to implement IKEv2. Tero's approach is a compromise. You will need the IANA only for few types of magic numbers, most of which don't affect protocol logic. I can leave with it. >>Those numbers won't change, so their >>presence must not hurt, > > This is probably incorrect. In many WGs, when errors are found in old > definitions, the error is corrected *and a new value is assigned*. That is > the only way to assure interoperability. As far as I understand, in this case new RFC must be issued, which will obsolete current one, won't it? If so, no contradiction. >>just will make implementing of base protocol more >>convinient. > > The goal of our work is clarity and interoperability, not convenience, > particularly when the inconvenience is remedied by one extra lookup. Just out of curiosity: is such approach (removing magic numbers from RFC completely) widely used in IETF? If memory serves me, all RFC I've read contained their magic numbers (of course they were duplicated in IANA) and that didn't lead to interoperability problems, I think. What is an origin for your conclusion that this practice leads to the lack of interoperability (of course if RFC and IANA are synchronized)? Regards, Smyslov Valery. From huangmin@huaweisymantec.com Sat Nov 28 01:10:37 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A373E3A690E for ; Sat, 28 Nov 2009 01:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.889 X-Spam-Level: X-Spam-Status: No, score=0.889 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_40=-0.185, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1h-4UzKBZ3V for ; Sat, 28 Nov 2009 01:10:33 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 568673A679C for ; Sat, 28 Nov 2009 01:10:33 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTT00F2EATCZF40@hstga01-in.huaweisymantec.com> for ipsec@ietf.org; Sat, 28 Nov 2009 17:10:25 +0800 (CST) Received: from h00104745 ([10.27.154.97]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KTT005Z6ATC3H10@hstml02-in.huaweisymantec.com> for ipsec@ietf.org; Sat, 28 Nov 2009 17:10:24 +0800 (CST) From: Min Huang To: gabriel.montenegro@microsoft.com, ken.grewal@intel.com Date: Sat, 28 Nov 2009 17:10:23 +0800 Message-id: <000301ca700a$9eb38730$619a1b0a@china.huawei.com> X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcpwCp37ip7uI/lzSOqTl4uk5fhFgw== Cc: ipsec@ietf.org Subject: [IPsec] Review of draft-montenegro-ipsecme-wesp-extensions-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 09:10:37 -0000 Section2, Page4 1 bit: Extensions Present (X). Setting the Extensions Present bit to 1 indicates that WESP Extensions are present between the WESP Header and the ESP Header (as shown above). The recipient MUST ensure consistency of this flag with the negotiated policy and MUST drop the incoming packet otherwise. "MUST drop the incoming packet otherwise", is *MUST* necessary here? IMHO, ignoring some extensions but the payload data available instead of dropping the whole packet MAY be required in some scenarios. Section2.1.1, Page6 The recipient of an OAM CV option MUST add the OAM CV option to the first subsequent packet that is small enough to hold it, or generate an empty packet after a timeout. I can't understand this paragraph well. I'm sorry for my poor English as a non-native English speaker. Which is required small enough? The OAM CV option? It is already small with zero-length data. The first subsequent packet? But why this need to be small enough? "or generate an empty packet after a timeout", is it indicated that the empty packet with OAM CV option? Would you make this paragraph clearer? Section2.1.2, Page6&7 IKE or ESP has already defined some error notification messages. In my personal opinion,The advantage of WESP error notification options compared to IKE/ESP error notification messages is the extended information fields which could carry some important information. Section2.3, Page9 I like the idea of Encryption Offset option. This option will provide flexibility of the data encryption. It can help the intermediate devices to detect the visible part of upper layer data. Even more, besides offset, a new field could be added to this option which stands for the length of data need to be encrypted. For example, the offset field is X, the length of encrypted date field is Y, this indicates only the Y octets data from the X octets from the beginning of the payload data is encrypted. This means that this extension can provide a kind of ability that just a part of the payload data is encrypted. It is just my humble opinions, welcome for more discussions. Best regards, Min Huang From huangmin@huaweisymantec.com Sat Nov 28 01:57:11 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E9AA3A697E for ; Sat, 28 Nov 2009 01:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.497 X-Spam-Level: X-Spam-Status: No, score=0.497 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_37=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0sTE0L4VHK2 for ; Sat, 28 Nov 2009 01:57:10 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id CF04A3A6974 for ; Sat, 28 Nov 2009 01:57:09 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTT006SRCYTRE30@hstga02-in.huaweisymantec.com> for ipsec@ietf.org; Sat, 28 Nov 2009 17:56:53 +0800 (CST) Received: from h00104745 ([10.27.154.97]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KTT0046QCYSZO20@hstml02-in.huaweisymantec.com> for ipsec@ietf.org; Sat, 28 Nov 2009 17:56:53 +0800 (CST) From: Min Huang To: 'Yaron Sheffer' Date: Sat, 28 Nov 2009 17:56:52 +0800 Message-id: <000401ca7011$1cafaaf0$619a1b0a@china.huawei.com> X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcpwERxLgpIkjGkuTrSRqgDiJxEEPw== Cc: ipsec@ietf.org Subject: Re: [IPsec] Ensuring future extensibility for WESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 09:57:11 -0000 I like this as well. This is the minimal change to add extensilibity to WESP. Howerver, there is a small problem here. As Yaron suggested: >2. If P=1 (Padding Present flag), the first octet of the Padding field will > hold the padding's length. [Hardware implementations can check that it is 4 > for IPv6, otherwise move the packet to the slow path]. All other Padding > octets are sent as zero, and ignored by the receiver. According to draft-ietf-ipsecme-traffic-visibility-10,Section 2, Page 6 HdrLen, 8 bits: Offset from the beginning of the WESP header to the beginning of the Rest of Payload Data (i.e., past the IV, if present) within the encapsulated ESP header, in octets. HdrLen MUST be set to zero when using ESP with encryption. When using integrity-only ESP, the following HdrLen values are invalid: any value less than 12; any value that is not a multiple of 4; any value that is not a multiple of 8 when using IPv6. The receiver MUST ensure that this field matches with the header offset computed from using the negotiated SA and MUST drop the packet in case it does not match. It might be conflicted according to these two definitions. The Padding field is 256 octets at most with the first octet holding the padding's length.The Hdrlen is also 8 bits and the whole WESP header is 256 octets at most. But the header fielder with 4 octets more than the Padding field. So the padding field SHOULD be any length<252. Thanks, Min Huang Sat, 21 Nov 2009 05:54:33 +0530, Jack Kohn wrote: >I support this as well. > >Jack > >On Fri, Nov 20, 2009 at 10:34 PM, Grewal, Ken wrote: >> I support this change to ensure future compatibility with the base draft. >> >> As Yaron indicates, the extension header size is as per the current draft >> and we are just adding some semantics to the pad field. >> >> >> >> There is also minimal textual change in the document. >> >> >> >> Thanks, >> >> - Ken >> >> >> >> From: ipsec-bounces at ietf.org [mailto:ipsec-bounces at ietf.org] On Behalf Of >> Yaron Sheffer >> Sent: Tuesday, November 17, 2009 11:30 PM >> To: IPsecme WG >> Subject: [IPsec] Ensuring future extensibility for WESP >> >> >> >> Hi, >> >> >> >> The recent draft on extending WESP which was presented in Hiroshima, >> explains why the current WESP is *not* extensible, and we would need a new >> version number if we are to add any extensions in the future. >> >> >> >> It is up to the WG to decide whether or not we want to adopt the draft, >> given that many people were skeptical about the specific extensions >> proposed. But regardless of that, it would be a mistake to publish WESP >> today with no facility for extensibility. After consulting with Pasi (the >> draft is at a very late stage, having been through IESG review), I would >> like to make a simple proposal to add this extensibility, with (almost) no >> change to the current draft. This will leave us with future options, at >> virtually no cost. I am basically just changing the semantics of the Padding >> field. Specifically: >> >> >> >> 1. Rename IPv6Padding to "Padding (Reserved for Future Use)", and allow it >> to be any length <256, subject to the IPv4 and IPv6 alignment constraints. >> >> 2. If P=1 (Padding Present flag), the first octet of the Padding field will >> hold the padding's length. [Hardware implementations can check that it is 4 >> for IPv6, otherwise move the packet to the slow path]. All other Padding >> octets are sent as zero, and ignored by the receiver. >> >> >> >> Note that there are barely any changes on the wire, as long as we don't have >> extensions. In particular the length remains unchanged. >> >> >> >> Thanks, >> > > Yaron From paul.hoffman@vpnc.org Sat Nov 28 07:32:49 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F22FE3A6894 for ; Sat, 28 Nov 2009 07:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.012 X-Spam-Level: X-Spam-Status: No, score=-6.012 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhj0OFy056Qp for ; Sat, 28 Nov 2009 07:32:48 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id A96353A67F1 for ; Sat, 28 Nov 2009 07:32:48 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nASFWdvK090124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Nov 2009 08:32:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <19211.60135.834509.954897@fireball. kivinen.iki.fi><19213.9738.693741.41 0069@fireball.kivinen.iki.fi><19214. 26055.878779.973603@fireball.kivinen.iki.fi><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0341@il-ex01.ad.checkpoin t.com> <4A045CD937B940C08E6E32600C6EA52C@trustworks.com> Date: Sat, 28 Nov 2009 07:32:38 -0800 To: "Valery Smyslov" , "IPsecme WG" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 15:32:50 -0000 At 11:11 PM +0300 11/27/09, Valery Smyslov wrote: >Hi Paul, > >please, see inline. > >>>2. IANA registry already contains some very specific entries (like, for >>>example, >>> those that came from RFC4595) and their number will be increasing. I >>>think, >>> those numbers would confuse some implementers, who might be thinking >>> that they need to support all of them. >> >>If a developer does not know how to read the IANA tables, we are all in trouble. Nothing in the tables says "you must implement every thing in these tables", of course. >> >>Are you proposing that we get rid of the IANA registry altogether, or we hide it from developers? > >Not, of course. > >>If not, how do you rectify this with your concern about confusion? > >For someone, who spent quite a lot of time working in this area, it is not >difficult fo figure out what is really important and what is not. But, I think, >a newcomer could be confused by a long list of all possible numbers. This answer is inconsistent, and that's the crux of the issue I have with your concern. We very much want developers to look at the IANA registry; it's the only way for them to know definitively what values will cause interoperability. Yet you say things like "a newcomer could be confused by a long list of all possible numbers". You can't have it both ways. >>>4. Some entries in Diffie-Hellman Group Transform IDs table do not really >>>assign >>> individual numbers, but instead point to other documens, even to RFC4306 >>>itself, >>> where the numbers are assigned. >> >>Again, I am concerned that you think we should get rid of the IANA registry. That is not how the IETF works. > >No, you didn't get the point. I meant that Diffie-Hellman Group Transform IDs table >in two cases doesn't assign individual numbers, just ranges. For example: > >1-2 Defined in Appendix B [RFC4306] >14-18 Defined in [RFC3526] [RFC3526] > >So, in first case it just points back to RFC4306 Appendix B, where the actual >numbers (what is 1 and what is 2) are assigned. Probably it may (and must) >be changed, but in its current form it's ridiculos - you went to IANA for >real numbers and have found only pointer back to RFC4306 where you >just have come from... These are the full definition of the semantics of the groups. How would you change this? >>>What about EAP Message format and magic numbers? Remove and just reference RFC3748 (or IANA entry for EAP)? >> >>No, those were left in because they came from an RFC, not from a particular IANA registry where the names match what we have in IKEv2bis. > >EAP numbers listed in RFC4306 might also be changed in future, >so from your logic it's better just to point to >http://www.iana.org/assignments/eap-numbers, right? Yes, but *only* if the names and numbers we use in this document match those exactly *and* the WG is willing to cede change control to the EAP methods we use to the IANA registry that we do not have input to. So far, the WG hasn't said they want to do that, so I don't presume to make that change. >>>I think, removing all magic numbers from the RFC would make implementing >>>less convinient >> >>Yes. >> >>>and more error-prone >> >>No. > >I don't agree with you. Remember, when IKEv2 was being developed, >one of the motivations for single self-contained document was complaint >from implementers that having 3 RFC (2408, 2409, 2407) for IKEv1 >was very inconvinient and provoked confusions that led to interoperability >problems. Correct. >Now you suggest to make IKEv2 not self-contained again. Correct, because we have already made many changes to the values that developers need to know. >Of course, I understand that IANA registry is not another RFC, but >I still prefer single self-contained document for core protocol. Of course, but your preference is at odds with the preference of someone reading the document needing to understand the context for the values. >If you need extensions - go to IANA and look for added numbers, >but core protocol must be implementable reading as few sources, >as possible, preferrably one. Seriously: how hard is "two"? Any serious developer can go look at a second URL to get the values. >>>, so I strongly support either "do >>>nothing" >>>approach, or Tero's suggestion. >> >>This is completely inconsistent. Tero's approach would lead you to need the IANA registry to implement IKEv2. > >Tero's approach is a compromise. You will need the IANA only for >few types of magic numbers, most of which don't affect protocol >logic. I can leave with it. This seems inconsistent to me ("it's OK to need a second file for some things but not others"). >>>Those numbers won't change, so their >>>presence must not hurt, >> >>This is probably incorrect. In many WGs, when errors are found in old definitions, the error is corrected *and a new value is assigned*. That is the only way to assure interoperability. > >As far as I understand, in this case new RFC must be issued, >which will obsolete current one, won't it? If so, no contradiction. That is not true. The new RFC can update just a portion of the old one. That is how this is normally handled in the IETF. >>>just will make implementing of base protocol more >>>convinient. >> >>The goal of our work is clarity and interoperability, not convenience, particularly when the inconvenience is remedied by one extra lookup. > >Just out of curiosity: is such approach (removing magic numbers from RFC >completely) widely used in IETF? I do not know if our situation has ever happened in the IETF for a major protocol. I will ask around and report back on that. --Paul Hoffman, Director --VPN Consortium From yaronf@checkpoint.com Sat Nov 28 08:43:17 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606B93A679C for ; Sat, 28 Nov 2009 08:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.232 X-Spam-Level: X-Spam-Status: No, score=-3.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZk2YIoKEJt9 for ; Sat, 28 Nov 2009 08:43:16 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id BBC673A63C9 for ; Sat, 28 Nov 2009 08:43:15 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nASGh3Go024830; Sat, 28 Nov 2009 18:43:03 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 28 Nov 2009 18:43:09 +0200 From: Yaron Sheffer To: Min Huang Date: Sat, 28 Nov 2009 18:43:06 +0200 Thread-Topic: [IPsec] Ensuring future extensibility for WESP Thread-Index: AcpwERxLgpIkjGkuTrSRqgDiJxEEPwAOIPjw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0364@il-ex01.ad.checkpoint.com> References: <000401ca7011$1cafaaf0$619a1b0a@china.huawei.com> In-Reply-To: <000401ca7011$1cafaaf0$619a1b0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Ensuring future extensibility for WESP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 16:43:17 -0000 Hi Min, Thanks for your (correct) comment. Yaron > -----Original Message----- > From: Min Huang [mailto:huangmin@huaweisymantec.com] > Sent: Saturday, November 28, 2009 11:57 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Ensuring future extensibility for WESP >=20 >=20 > I like this as well. > This is the minimal change to add extensilibity to WESP. >=20 > Howerver, there is a small problem here. > As Yaron suggested: > >2. If P=3D1 (Padding Present flag), the first octet of the Padding field > will > > hold the padding's length. [Hardware implementations can check that it > is > 4 > > for IPv6, otherwise move the packet to the slow path]. All other Paddin= g > > octets are sent as zero, and ignored by the receiver. >=20 > According to draft-ietf-ipsecme-traffic-visibility-10,Section 2, Page 6 > HdrLen, 8 bits: Offset from the beginning of the WESP header to > the beginning of the Rest of Payload Data (i.e., past the IV, if > present) within the encapsulated ESP header, in octets. HdrLen > MUST be set to zero when using ESP with encryption. When using > integrity-only ESP, the following HdrLen values are invalid: any > value less than 12; any value that is not a multiple of 4; any > value that is not a multiple of 8 when using IPv6. The receiver > MUST ensure that this field matches with the header offset > computed from using the negotiated SA and MUST drop the packet > in case it does not match. >=20 > It might be conflicted according to these two definitions. > The Padding field is 256 octets at most with the first octet holding the > padding's > length.The Hdrlen is also 8 bits and the whole WESP header is 256 octets > at > most. > But the header fielder with 4 octets more than the Padding field. > So the padding field SHOULD be any length<252. >=20 > Thanks, > Min Huang >=20 >=20 > Sat, 21 Nov 2009 05:54:33 +0530, Jack Kohn wrote= : > >I support this as well. > > > >Jack > > > >On Fri, Nov 20, 2009 at 10:34 PM, Grewal, Ken > wrote: > >> I support this change to ensure future compatibility with the base > draft. > >> > >> As Yaron indicates, the extension header size is as per the current > draft > >> and we are just adding some semantics to the pad field. > >> > >> > >> > >> There is also minimal textual change in the document. > >> > >> > >> > >> Thanks, > >> > >> - Ken > >> > >> > >> > >> From: ipsec-bounces at ietf.org [mailto:ipsec-bounces at ietf.org] On > Behalf Of > >> Yaron Sheffer > >> Sent: Tuesday, November 17, 2009 11:30 PM > >> To: IPsecme WG > >> Subject: [IPsec] Ensuring future extensibility for WESP > >> > >> > >> > >> Hi, > >> > >> > >> > >> The recent draft on extending WESP which was presented in Hiroshima, > >> explains why the current WESP is *not* extensible, and we would need a > new > >> version number if we are to add any extensions in the future. > >> > >> > >> > >> It is up to the WG to decide whether or not we want to adopt the draft= , > >> given that many people were skeptical about the specific extensions > >> proposed. But regardless of that, it would be a mistake to publish WES= P > >> today with no facility for extensibility. After consulting with Pasi > (the > >> draft is at a very late stage, having been through IESG review), I > would > >> like to make a simple proposal to add this extensibility, with (almost= ) > no > >> change to the current draft. This will leave us with future options, a= t > >> virtually no cost. I am basically just changing the semantics of the > Padding > >> field. Specifically: > >> > >> > >> > >> 1. Rename IPv6Padding to "Padding (Reserved for Future Use)", and allo= w > it > >> to be any length <256, subject to the IPv4 and IPv6 alignment > constraints. > >> > >> 2. If P=3D1 (Padding Present flag), the first octet of the Padding fie= ld > will > >> hold the padding's length. [Hardware implementations can check that it > is > 4 > >> for IPv6, otherwise move the packet to the slow path]. All other > Padding > >> octets are sent as zero, and ignored by the receiver. > >> > >> > >> > >> Note that there are barely any changes on the wire, as long as we don'= t > have > >> extensions. In particular the length remains unchanged. > >> > >> > >> > >> Thanks, > >> > > > Yaron >=20 >=20 >=20 > Scanned by Check Point Total Security Gateway. From yaronf@checkpoint.com Sun Nov 29 09:22:43 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E4863A6838 for ; Sun, 29 Nov 2009 09:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.52 X-Spam-Level: X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KtPYe7+UMTJ for ; Sun, 29 Nov 2009 09:22:42 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 4C84A3A6946 for ; Sun, 29 Nov 2009 09:22:42 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nATHMYGo025785 for ; Sun, 29 Nov 2009 19:22:34 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 29 Nov 2009 19:22:40 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Sun, 29 Nov 2009 19:22:27 +0200 Thread-Topic: IPsecME rechartering Thread-Index: AcpxEjOEDv+RzyfzSGyTQH2RfLSW5g== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04ED@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] IPsecME rechartering X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 17:22:43 -0000 Hi everyone, =20 The following 7 messages request your input regarding the activities that w= ere proposed for the next phase of the IPsecME WG. This is an open process,= and we specifically request that you reply to the mailing list, rather tha= n privately, whether you are committing to review/author a draft or on the = contrary, arguing why the working group should not work on it. Also, please limit your commitment to what's reasonable - we will be chasin= g you to review those drafts! Please reply separately for each proposal, ke= eping its name in the title. We are asking for your replies by Monday, Dec.= 7. If you already committed to review/participate in any proposals during the = Hiroshima meeting, or if you're a current author, you don't have to resend = (you may want to check the meeting minutes for correctness, http://tools.ie= tf.org/wg/ipsecme/minutes). Based on these inputs, Paul, Pasi and I will ev= aluate which of the proposals has enough interest to work on. =20 Thanks, Yaron From yaronf@checkpoint.com Sun Nov 29 09:22:46 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE2E43A6970 for ; Sun, 29 Nov 2009 09:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6j8WPv9K9JF for ; Sun, 29 Nov 2009 09:22:46 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id D71903A6916 for ; Sun, 29 Nov 2009 09:22:44 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nATHMbGo025794 for ; Sun, 29 Nov 2009 19:22:37 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 29 Nov 2009 19:22:43 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Sun, 29 Nov 2009 19:18:31 +0200 Thread-Topic: Proposed work item: EAP-only authentication in IKEv2 Thread-Index: AcpxEw2BkfQRvohJSsu1ldV7KkNLtw== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Proposed work item: EAP-only authentication in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 17:22:46 -0000 This draft proposes an IKEv2 extension to allow mutual EAP-based authentica= tion in IKEv2, eliminating the need for one of the peers to present a certi= ficate. This applies to a small number of key-generating EAP methods that a= llow mutual authentication. =A0 Proposed starting point: http://tools.ietf.org/id/draft-eronen-ipsec-ikev2-= eap-auth-07.txt. =A0 Please reply to the list: =A0 - If this proposal is accepted as a WG work item, are you committing to rev= iew multiple versions of the draft? - Are you willing to contribute text to the draft? - Would you like to co-author it? =A0 Please also reply to the list if: =A0 - You believe this is NOT a reasonable activity for the WG to spend time on= . =A0 If this is the case, please explain your position. Do not explore the fine = technical details (which will change anyway, once the WG gets hold of the d= raft); instead explain why this is uninteresting for the WG or for the indu= stry at large. Also, please mark the title clearly (e.g. "DES40-export in I= Psec - NO!"). From yaronf@checkpoint.com Sun Nov 29 09:25:41 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 770323A693C for ; Sun, 29 Nov 2009 09:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzM2ao-1JZBG for ; Sun, 29 Nov 2009 09:25:40 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 56A2A3A6916 for ; Sun, 29 Nov 2009 09:25:40 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nATHMbGq025794 for ; Sun, 29 Nov 2009 19:22:38 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 29 Nov 2009 19:22:43 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Sun, 29 Nov 2009 19:21:14 +0200 Thread-Topic: Proposed work item: Childless IKE SA Thread-Index: AcpxFGNxZr/+l4aORQq0dtIEtoKGIw== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Proposed work item: Childless IKE SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 17:25:41 -0000 This draft proposes an IKEv2 extension to allow the setup of an IKE SA with= no Child SA, a situation which is currently disallowed by the protocol. Proposed starting point: http://tools.ietf.org/id/draft-nir-ipsecme-childle= ss-01.txt. =A0 Please reply to the list: =A0 - If this proposal is accepted as a WG work item, are you committing to rev= iew multiple versions of the draft? - Are you willing to contribute text to the draft? - Would you like to co-author it? =A0 Please also reply to the list if: =A0 - You believe this is NOT a reasonable activity for the WG to spend time on= . =A0 If this is the case, please explain your position. Do not explore the fine = technical details (which will change anyway, once the WG gets hold of the d= raft); instead explain why this is uninteresting for the WG or for the indu= stry at large. Also, please mark the title clearly (e.g. "DES40-export in I= Psec - NO!"). From yaronf@checkpoint.com Sun Nov 29 09:25:42 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20E43A6946 for ; Sun, 29 Nov 2009 09:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdZDHwvF87OJ for ; Sun, 29 Nov 2009 09:25:42 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 873363A6916 for ; Sun, 29 Nov 2009 09:25:41 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nATHMbGs025794 for ; Sun, 29 Nov 2009 19:22:38 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 29 Nov 2009 19:22:43 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Sun, 29 Nov 2009 19:20:42 +0200 Thread-Topic: Proposed work item: IKEv2 password authentication (SPSK) Thread-Index: AcpxFfJDmBgkALGBQJKj2A/3q2uc3w== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 17:25:42 -0000 This draft proposes a particular method for mutual authentication of IKEv2 = peers using a short, low quality shared secret (a.k.a. "password"). The pro= posal is to embed this method in the IKE exchange, rather than use EAP. Proposed starting point: http://tools.ietf.org/id/draft-harkins-ipsecme-sps= k-auth-00.txt. =A0 Please reply to the list: =A0 - If this proposal is accepted as a WG work item, are you committing to rev= iew multiple versions of the draft? - Are you willing to contribute text to the draft? - Would you like to co-author it? =A0 Please also reply to the list if: =A0 - You believe this is NOT a reasonable activity for the WG to spend time on= . =A0 If this is the case, please explain your position. Do not explore the fine = technical details (which will change anyway, once the WG gets hold of the d= raft); instead explain why this is uninteresting for the WG or for the indu= stry at large. Also, please mark the title clearly (e.g. "DES40-export in I= Psec - NO!"). From yaronf@checkpoint.com Sun Nov 29 09:25:43 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE10C3A6976 for ; Sun, 29 Nov 2009 09:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3fNdP3JpSPs for ; Sun, 29 Nov 2009 09:25:43 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id AA5AB3A693C for ; Sun, 29 Nov 2009 09:25:42 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nATHMbGp025794 for ; Sun, 29 Nov 2009 19:22:37 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 29 Nov 2009 19:22:43 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Sun, 29 Nov 2009 19:18:59 +0200 Thread-Topic: Proposed work item: Failure detection in IKEv2 Thread-Index: AcpxE9dTLhKQolEdTcq7ATWAonsg0g== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EF@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Proposed work item: Failure detection in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 17:25:44 -0000 This work item proposes an IKEv2 extension to allow an IKE peer to quickly = and securely detect that its opposite peer has lost state. This is claimed = to be quicker than the current method, which is based on time outs. Proposed starting point: http://tools.ietf.org/id/draft-nir-ike-qcd-05.txt = or http://tools.ietf.org/html/draft-detienne-ikev2-recovery-03. =A0 Please reply to the list: =A0 - If this proposal is accepted as a WG work item, are you committing to rev= iew multiple versions of the draft? - Are you willing to contribute text to the draft? - Would you like to co-author it? =A0 Please also reply to the list if: =A0 - You believe this is NOT a reasonable activity for the WG to spend time on= . =A0 If this is the case, please explain your position. Do not explore the fine = technical details (which will change anyway, once the WG gets hold of the d= raft); instead explain why this is uninteresting for the WG or for the indu= stry at large. Also, please mark the title clearly (e.g. "DES40-export in I= Psec - NO!"). From yaronf@checkpoint.com Sun Nov 29 09:25:45 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5452228B797 for ; Sun, 29 Nov 2009 09:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERZdrttDj55F for ; Sun, 29 Nov 2009 09:25:44 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id D17443A68A0 for ; Sun, 29 Nov 2009 09:25:43 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nATHMbGu025794 for ; Sun, 29 Nov 2009 19:22:39 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 29 Nov 2009 19:22:43 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Sun, 29 Nov 2009 19:18:38 +0200 Thread-Topic: Proposed work item: Labelled IPsec Thread-Index: AcpxF8eF5k3BH9Q8QySjmaMChzM61A== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Proposed work item: Labelled IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 17:25:45 -0000 This work item proposes to extend IKEv2 (and IKEv1) so as to allow IPsec to= be used in environments that require Mandatory Access Control. It is envis= ioned that this will be used by modern high-security operating systems, tha= t go beyond the currently supported Multilevel Security (MLS). Proposed starting point: http://tools.ietf.org/html/draft-jml-ipsec-ikev2-s= ecurity-context-01 and http://tools.ietf.org/html/draft-jml-ipsec-ikev1-sec= urity-context-01. =A0 Please reply to the list: =A0 - If this proposal is accepted as a WG work item, are you committing to rev= iew multiple versions of the draft? - Are you willing to contribute text to the draft? - Would you like to co-author it? =A0 Please also reply to the list if: =A0 - You believe this is NOT a reasonable activity for the WG to spend time on= . =A0 If this is the case, please explain your position. Do not explore the fine = technical details (which will change anyway, once the WG gets hold of the d= raft); instead explain why this is uninteresting for the WG or for the indu= stry at large. Also, please mark the title clearly (e.g. "DES40-export in I= Psec - NO!"). From yaronf@checkpoint.com Sun Nov 29 09:40:41 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4D03A692B for ; Sun, 29 Nov 2009 09:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4xbgMb6OgWC for ; Sun, 29 Nov 2009 09:40:40 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 5DF303A67F3 for ; Sun, 29 Nov 2009 09:40:40 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nATHMbGt025794 for ; Sun, 29 Nov 2009 19:22:39 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 29 Nov 2009 19:22:43 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Sun, 29 Nov 2009 19:20:55 +0200 Thread-Topic: Proposed work item: WESP extensibility Thread-Index: AcpxFkxGdx4Es24CRa+VhZZQCynYUg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3ilex01adche_" MIME-Version: 1.0 Subject: [IPsec] Proposed work item: WESP extensibility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 17:40:41 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3ilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This draft proposes an extensibility framework for WESP, as well as several= specific extensions. Proposed starting point: http://tools.ietf.org/id/draft-montenegro-ipsecme-= wesp-extensions-00.txt. Please reply to the list: - If this proposal is accepted as a WG work item, are you committing to rev= iew multiple versions of the draft? - Are you willing to contribute text to the draft? - Would you like to co-author it? Please also reply to the list if: - You believe this is NOT a reasonable activity for the WG to spend time on= . If this is the case, please explain your position. Do not explore the fine = technical details (which will change anyway, once the WG gets hold of the d= raft); instead explain why this is uninteresting for the WG or for the indu= stry at large. Also, please mark the title clearly (e.g. "DES40-export in I= Psec - NO!"). --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3ilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This draft proposes an extensibility framework for WESP, as well as several specific extensions.

 

Proposed starting point: http://tools.ietf.org/id/draft-montenegro-ipsecme-wesp-extensions-00.txt.

 

Please reply to the list:

 

- If this proposal is accepted as a WG work item, are you committin= g to review multiple versions of the draft?

- Are you willing to contribute text to the draft?

- Would you like to co-author it?

 

Please also reply to the list if:

 

- You believe this is NOT a reasonable activity for the WG to spend time on.

 

If this is the case, please explain your position. Do not explore t= he fine technical details (which will change anyway, once the WG gets hold of = the draft); instead explain why this is uninteresting for the WG or for the industry at large. Also, please mark the title clearly (e.g. "DES40-ex= port in IPsec - NO!").

 

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3ilex01adche_-- From yaronf@checkpoint.com Sun Nov 29 09:40:45 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468483A697F for ; Sun, 29 Nov 2009 09:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGfQp6LrkVFX for ; Sun, 29 Nov 2009 09:40:42 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 30B6E3A67F3 for ; Sun, 29 Nov 2009 09:40:41 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nATHMbGr025794 for ; Sun, 29 Nov 2009 19:22:38 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 29 Nov 2009 19:22:43 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Sun, 29 Nov 2009 19:19:14 +0200 Thread-Topic: Proposed work item: IKE/IPsec high availability and load sharing Thread-Index: AcpxFU/ljJSUH80YTuKL0trw0IS+Ag== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F1@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F1ilex01adche_" MIME-Version: 1.0 Subject: [IPsec] Proposed work item: IKE/IPsec high availability and load sharing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 17:40:45 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F1ilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This work item will define the problem statement and requirements for a sol= ution that allows interoperable HA/LS device groups. Mixed-vendor clusters = are specifically out of scope; but single-vendor clusters should be fully i= nteroperable with other vendors' devices or clusters. The main challenge is= to overcome the strict use of sequence numbers in both IPsec and IKE, in H= A and LS scenarios. Following the Hiroshima discussion, the WI is initially= focused on defining the problem, rather than a particular solution. Proposed starting point: http://tools.ietf.org/id/draft-nir-ipsecme-ipsecha= -00.txt. Please reply to the list: - If this proposal is accepted as a WG work item, are you committing to rev= iew multiple versions of the draft? - Are you willing to contribute text to the draft? - Would you like to co-author it? Please also reply to the list if: - You believe this is NOT a reasonable activity for the WG to spend time on= . If this is the case, please explain your position. Do not explore the fine = technical details (which will change anyway, once the WG gets hold of the d= raft); instead explain why this is uninteresting for the WG or for the indu= stry at large. Also, please mark the title clearly (e.g. "DES40-export in I= Psec - NO!"). --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F1ilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This work item will define the problem statement and requirements f= or a solution that allows interoperable HA/LS device groups. Mixed-vendor cluste= rs are specifically out of scope; but single-vendor clusters should be fully interoperable with other vendors’ devices or clusters. The main chall= enge is to overcome the strict use of sequence numbers in both IPsec and IKE, in= HA and LS scenarios. Following the Hiroshima discussion, the WI is initially focused on defining the problem, rather tha= n a particular solution.

 

Proposed starting point: http://tools.ietf.org/id/draft-nir-ipsecme-ipsecha-00.txt.

 

Please reply to the list:

 

- If this proposal is accepted as a WG work item, are you committin= g to review multiple versions of the draft?

- Are you willing to contribute text to the draft?

- Would you like to co-author it?

 

Please also reply to the list if:

 

- You believe this is NOT a reasonable activity for the WG to spend time on.

 

If this is the case, please explain your position. Do not explore t= he fine technical details (which will change anyway, once the WG gets hold of = the draft); instead explain why this is uninteresting for the WG or for the industry at large. Also, please mark the title clearly (e.g. "DES40-ex= port in IPsec - NO!").

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F1ilex01adche_-- From svanru@gmail.com Sun Nov 29 13:19:21 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1F9B3A6924 for ; Sun, 29 Nov 2009 13:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdfzuVJW8Kye for ; Sun, 29 Nov 2009 13:19:19 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 10A2F3A6901 for ; Sun, 29 Nov 2009 13:19:18 -0800 (PST) Received: by bwz23 with SMTP id 23so2188825bwz.29 for ; Sun, 29 Nov 2009 13:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=z4xFSE7Vyjee4xXxnn8cteArga8Q2c/e1pAuIuttMk4=; b=rXZ8rvm2HBkWdXcqgDErFfmsNQ9jIkDYhfTpB6jnx0ifim4wGWOzDcVQQZzoxZtfgM cqLYTsnigtH2rC0eMZWTgJygfy/t8g50enM7ptrREC6HjqrmcPsr+ZDB9G30Z4a++58N gSEuOk5nEbAr0SKdBF38nWHlkLyiOeM+mdY4E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=WGA3247b8yIm1UgvA9lm3wT9zcDy5DO3n+tSGy/R6JS4fytazeYlwg6klXmoeJ7dBj nUQ0JYniqKDBlUwOqT20DFRYgaGLvOjNvL5MxFsnQami3t4lWKTxFvI5O0wawA0hmZXp YCffGWgxpJKdwY2uvPEfhGZbynhjgdGkYmdnU= Received: by 10.204.34.73 with SMTP id k9mr3660223bkd.45.1259529547825; Sun, 29 Nov 2009 13:19:07 -0800 (PST) Received: from chichi (ppp85-140-119-176.pppoe.mtu-net.ru [85.140.119.176]) by mx.google.com with ESMTPS id 13sm958791bwz.6.2009.11.29.13.19.05 (version=SSLv3 cipher=RC4-MD5); Sun, 29 Nov 2009 13:19:05 -0800 (PST) Message-ID: <9195EB81DDEB4A6996DDE00700C9552F@chichi> From: "Valery Smyslov" To: "IPsecme WG" , "Paul Hoffman" References: <19211.60135.834509.954897@fireball. kivinen.iki.fi><19213.9738.693741.41 0069@fireball.kivinen.iki.fi><19214. 26055.878779.973603@fireball.kivinen.iki.fi><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0341@il-ex01.ad.checkpoin t.com> <4A045CD937B940C08E6E32600C6EA52C@trustworks.com> Date: Mon, 30 Nov 2009 00:19:04 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 21:19:21 -0000 >>For someone, who spent quite a lot of time working in this area, it is not >>difficult fo figure out what is really important and what is not. But, I >>think, >>a newcomer could be confused by a long list of all possible numbers. > > This answer is inconsistent, and that's the crux of the issue I have with > your > concern. We very much want developers to look at the IANA registry; > it's the only way for them to know definitively what values will cause > interoperability. Yet you say things like "a newcomer could be confused > by a long list of all possible numbers". You can't have it both ways. You probably speaks about "ideal" developers. I speak about real people. I've seen a few cases when people implemented a bunch of really unnecessary things just because "it was in standard". >>No, you didn't get the point. I meant that Diffie-Hellman Group Transform >>IDs table >>in two cases doesn't assign individual numbers, just ranges. For example: >> >>1-2 Defined in Appendix B [RFC4306] >>14-18 Defined in [RFC3526] [RFC3526] >> >>So, in first case it just points back to RFC4306 Appendix B, where the >>actual >>numbers (what is 1 and what is 2) are assigned. Probably it may (and must) >>be changed, but in its current form it's ridiculos - you went to IANA for >>real numbers and have found only pointer back to RFC4306 where you >>just have come from... > > These are the full definition of the semantics of the groups. How would > you change this? Currently exact groups for numbers 1, 2, 14, 15, 16, 17 and 16 are not defined in IANA. For me this is inconsistent. Either change two abovementioned lines to: 1 768-Bit MODP Group [RFC4306] 2 1024-Bit MODP Group [RFC4306] 14 2048-Bit MODP Group [RFC3526] 15 3072-Bit MODP Group [RFC3526] 16 4096-Bit MODP Group [RFC3526] 17 6144-Bit MODP Group [RFC3526] 18 8192-Bit MODP Group [RFC3526] or, if you think that current situation is OK, then why no to change other tables in the same fashion and leave all numbers in the RFC. Just for example: Value Next Payload Type Notation Reference -------- ------------------------------- --------- --------- 0 No Next Payload [RFC4306] 1-32 Reserved [RFC4306] 33-48 Defined in [RFC4306] [RFC4306] 49-127 Unassigned [RFC4306] 128-255 Private use [RFC4306] At least this will made things consistent. >>EAP numbers listed in RFC4306 might also be changed in future, >>so from your logic it's better just to point to >>http://www.iana.org/assignments/eap-numbers, right? > > Yes, but *only* if the names and numbers we use in this document match > those exactly > *and* the WG is willing to cede change control to the EAP methods we use > to the IANA > registry that we do not have input to. So far, the WG hasn't said they > want to do that, > so I don't presume to make that change. I fail to understand your logic here. You seem to want to have ability to change already assigned numbers in IKEv2 in the future (and for this purpose remove them from RFC), but at the same time you seem to presume that other groups will not ever change their numbers. By the way, at least one RFC outside ipsecme WG (I mean RFC5106, EAP-IKEv2) has already listed some of IKEv2 magic numbers (payload types) and has already presumed that they won't change. >>Now you suggest to make IKEv2 not self-contained again. > > Correct, because we have already made many changes to the values that > developers need to know. Those new values could be listed in IKEv2bis RFC, which will update RFC4306. >>Of course, I understand that IANA registry is not another RFC, but >>I still prefer single self-contained document for core protocol. > > Of course, but your preference is at odds with the preference of someone > reading the document needing to understand the context for the values. I fail to understand how removing values from the RFC will help understanding the context for them. >>If you need extensions - go to IANA and look for added numbers, >>but core protocol must be implementable reading as few sources, >>as possible, preferrably one. > > Seriously: how hard is "two"? Any serious developer can go look at > a second URL to get the values. It's not hard, but what for? I see some drawbacks and I don't see how it will help interoperability. >>Tero's approach is a compromise. You will need the IANA only for >>few types of magic numbers, most of which don't affect protocol >>logic. I can leave with it. > > This seems inconsistent to me ("it's OK to need a second file for some > things but not others"). I didn't say I like it. I said I can bear it. Tero has suggested removing values for Transform IDs only. Those values mostly are "external" to IKEv2 logic, it just "transfers" them between network, policy module, ipsec module and crypto module. Theoretically they should not affect IKEv2 itself (*). That's why I can bear removing them. (*) Unfortunately, they do affect: AEAD algorithms require special handling in construction proposals. But this is another story. I've been thinking that introducing a new Transform type for AEAD algorithms instead of reusing Encryption Algorithm Transform would probably have made protocol simpler and cleaner, but that was that. >>As far as I understand, in this case new RFC must be issued, >>which will obsolete current one, won't it? If so, no contradiction. > > That is not true. The new RFC can update just a portion of the old one. > That is how this is normally handled in the IETF. In any case base RFC will be updated. And the first thing one must do before implementing any protocol is to find most recent RFC for it, including all updates and erratas. This is natural way to go, and if one starts implementing old RFC, then even if you manage to force him to go to IANA for numbers, I doubt if he will get interoperable product. >>Just out of curiosity: is such approach (removing magic numbers from RFC >>completely) widely used in IETF? > > I do not know if our situation has ever happened in the IETF for a major > protocol. > I will ask around and report back on that. OK, thank you. Regards, Smyslov Valery. From paul.hoffman@vpnc.org Sun Nov 29 13:39:51 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3011D3A69E1 for ; Sun, 29 Nov 2009 13:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.014 X-Spam-Level: X-Spam-Status: No, score=-6.014 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kif16akW-4H6 for ; Sun, 29 Nov 2009 13:39:49 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 6E6173A6927 for ; Sun, 29 Nov 2009 13:39:49 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nATLdc8C073392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Nov 2009 14:39:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <9195EB81DDEB4A6996DDE00700C9552F@chichi> References: <19211.60135.834509.954897@fireball. kivinen.iki.fi><19213.9738.693741.41 0069@fireball.kivinen.iki.fi><19214. 26055.878779.973603@fireball.kivinen.iki.fi><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0341@il-ex01.ad.checkpoin t.com> <4A045CD937B940C08E6E32600C6EA52C@trustworks.com> <9195EB81DDEB4A6996DDE00700C9552F@chichi> Date: Sun, 29 Nov 2009 13:39:36 -0800 To: "Valery Smyslov" , "IPsecme WG" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2009 21:39:51 -0000 At 12:19 AM +0300 11/30/09, Valery Smyslov wrote: >>>For someone, who spent quite a lot of time working in this area, it is not >>>difficult fo figure out what is really important and what is not. But, I think, >>>a newcomer could be confused by a long list of all possible numbers. >> >>This answer is inconsistent, and that's the crux of the issue I have with your >>concern. We very much want developers to look at the IANA registry; >>it's the only way for them to know definitively what values will cause >>interoperability. Yet you say things like "a newcomer could be confused >>by a long list of all possible numbers". You can't have it both ways. > >You probably speaks about "ideal" developers. I speak about real people. >I've seen a few cases when people implemented a bunch of really >unnecessary things just because "it was in standard". We still agree, and your answer is still inconsistent. If you worry about those type of developers, then you must want to get rid of the IANA registry, because that is what is giving them the silly ideas. >Currently exact groups for numbers 1, 2, 14, 15, 16, 17 and 16 are not defined in IANA. >For me this is inconsistent. Either change two abovementioned lines to: > >1 768-Bit MODP Group [RFC4306] >2 1024-Bit MODP Group [RFC4306] > >14 2048-Bit MODP Group [RFC3526] >15 3072-Bit MODP Group [RFC3526] >16 4096-Bit MODP Group [RFC3526] >17 6144-Bit MODP Group [RFC3526] >18 8192-Bit MODP Group [RFC3526] Sorry, I misunderstood what you were saying. Yes, that is a good suggestion; I'll make it happen. >>>EAP numbers listed in RFC4306 might also be changed in future, >>>so from your logic it's better just to point to >>>http://www.iana.org/assignments/eap-numbers, right? >> >>Yes, but *only* if the names and numbers we use in this document match those exactly >>*and* the WG is willing to cede change control to the EAP methods we use to the IANA >>registry that we do not have input to. So far, the WG hasn't said they want to do that, >>so I don't presume to make that change. > >I fail to understand your logic here. You seem to want to have ability to change >already assigned numbers in IKEv2 in the future (and for this purpose remove >them from RFC), but at the same time you seem to presume that other >groups will not ever change their numbers. I do not presume that. I presume that this WG is not concerned about it; otherwise, we would have created our own IANA registry for the EAP values we use. We didn't. >I fail to understand how removing values from the RFC will help >understanding the context for them. The context for the values is "they are assigned and maintained by IANA". It is not "they came from this RFC". You may not like that, but that's how the IETF works. >>>If you need extensions - go to IANA and look for added numbers, >>>but core protocol must be implementable reading as few sources, >>>as possible, preferrably one. >> >>Seriously: how hard is "two"? Any serious developer can go look at >>a second URL to get the values. > >It's not hard, but what for? I see some drawbacks and I don't see >how it will help interoperability. Again: it helps interoperability if developers look in the IANA registry at the time of coding and see changes have been made to what they thought was true based only on reading an RFC. >>>Tero's approach is a compromise. You will need the IANA only for >>>few types of magic numbers, most of which don't affect protocol >>>logic. I can leave with it. >> >>This seems inconsistent to me ("it's OK to need a second file for some things but not others"). > >I didn't say I like it. I said I can bear it. Tero has suggested removing >values for Transform IDs only. Those values mostly are "external" to >IKEv2 logic, it just "transfers" them between network, policy module, >ipsec module and crypto module. Theoretically they should not affect >IKEv2 itself (*). That's why I can bear removing them. > >(*) Unfortunately, they do affect: AEAD algorithms require special >handling in construction proposals. But this is another story. >I've been thinking that introducing a new Transform type for >AEAD algorithms instead of reusing Encryption Algorithm Transform >would probably have made protocol simpler and cleaner, but that was that. Your second paragraph is a shining example of why this should have been done in RFC 4306, and why we should not presume that what we do in IKEv2bis will be held constant. >>>As far as I understand, in this case new RFC must be issued, >>>which will obsolete current one, won't it? If so, no contradiction. >> >>That is not true. The new RFC can update just a portion of the old one. >>That is how this is normally handled in the IETF. > >In any case base RFC will be updated. And the first thing one must do before >implementing any protocol is to find most recent RFC for it, including >all updates and erratas. This is natural way to go, and if one starts >implementing old RFC, then even if you manage to force him to go >to IANA for numbers, I doubt if he will get interoperable product. The IANA registry lists the current RFCs. Do you not think that is enough clue? --Paul Hoffman, Director --VPN Consortium From kent@bbn.com Sun Nov 29 16:49:12 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910E63A6A08 for ; Sun, 29 Nov 2009 16:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOb+3s5nHTVH for ; Sun, 29 Nov 2009 16:49:11 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 9FA463A6A07 for ; Sun, 29 Nov 2009 16:49:11 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[12.236.246.158]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NEuRs-0005Kr-Ay; Sun, 29 Nov 2009 19:49:04 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 29 Nov 2009 19:48:43 -0500 To: Jack Kohn From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] WESP - Roadmap Ahead X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 00:49:12 -0000 Jack, Thanks for describing the additional selection criteria that must be employed to avoid the problem I cited. Given this more complete description of the selection criteria, I am not convinced that that is a significant benefit for using WESP in this context. - Whether using WESP or just ESP-NULL, the router needs to determine that the packet is addressed to it. This means looking for either a unicast address (per interface?) or a multicast address. I thought that the traffic of interest would arrive on a multicast address. If so, then this is a very easy check. - Traffic other than OSPF can be addressed to the router, but I'm not sure what other traffic would be multicast. For unicast traffic addressed to the router, if some of that is protected using ESP with confidentiality, then the address check might have to be extended to include a source address as well. - There is an assumption that the OPSFv3 traffic is (ultimately) protected using ESP-NULL. The next check that you described, i.e., looking for a few bits that indicate whether the payload is OSPF and appears to be a HELLO or ACK, is the real focus of this thread. There appears to be a couple of cases: - If all multicast traffic directed to the router and protected using ESP is ESP-NULL, then WESP seems to help ONLY if there are algorithms being used for different SAs, AND if those algorithms result in different offsets for the start of the ESP-NULL payload. It's not clear that this is a realistic case. But, in this case, using WESP could avoid the need to check the SPI in the packet. What's not clear is whether checking for WESP and extracting the offset info is faster than matching against a set of SPIs. - if some multicast traffic directed to the router is protected with ESP with confidentiality, in addition to the ESP-NULL OSPF traffic, then one would need to check SPI values to differentiate between these two classes of traffic. So, the question of whether we have one multicast SA for this traffic, or potentially a lot of these SAs is potentially relevant. As I mentioned in my previous message, this is not completely clear to me from 4552. You didn't respond to that part of my message, so I don't know if that means you find the RFC unclear on this point as well, or if you didn't think it mattered to this discussion. Well, if appears to matter, if one believes that the number is substantial. So, the bottom line appears to be that WESP might be better than just using ESP-NULL, depending on the number of multicast SAs that terminate at the router, that make use of ESP, and maybe whether the ones that use ESP make use of different integrity algorithms that result in different offsets. That is a lot of IFs for which we have yet to get an answer. In any case, as I noted earlier, because of the use of manual keying in this context, selecting a subset of packets for out-of-order processing does not impose any burden on the IPsec for the remaining packets, so all of the comments about that issue were red herrings. Steve From kent@bbn.com Sun Nov 29 17:05:47 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85E623A6A0C for ; Sun, 29 Nov 2009 17:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OOfiUwJvzuR for ; Sun, 29 Nov 2009 17:05:46 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id B4FFB3A689C for ; Sun, 29 Nov 2009 17:05:46 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[12.236.246.158]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NEuhu-0005Xu-BF; Sun, 29 Nov 2009 20:05:38 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> Date: Sun, 29 Nov 2009 19:59:35 -0500 To: Yaron Sheffer From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Proposed work item: Labelled IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 01:05:47 -0000 I think that there has been insufficient discussion of whether those who wish to make use of IPsec to enforce mandatory access controls require the facilities described by the folks who have proposed this. At the WG meeting 2 weeks ago I made two observations: - possible use of CIPSO for carrying labels had not been fully discussed - use of tunnel mode to protect such labels in the inner header did not appear to have been considered I think it is incumbent on those who wish to pursue this work to provide more persuasive arguments. It also seems appropriate to have a discussion of whether mandatory, label-based controls are sufficiently mainstream to warrant bringing them back into IPsec at this time, or whether this is more of a research topic. Steve From kent@bbn.com Sun Nov 29 17:05:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF56F28C0E1 for ; Sun, 29 Nov 2009 17:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXNuyUxIL-Ua for ; Sun, 29 Nov 2009 17:05:51 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id D618928C0DD for ; Sun, 29 Nov 2009 17:05:51 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[12.236.246.158]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NEui0-0005Xu-Bh; Sun, 29 Nov 2009 20:05:44 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> Date: Sun, 29 Nov 2009 20:04:59 -0500 To: Yaron Sheffer From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Proposed work item: WESP extensibility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 01:05:52 -0000 I am opposed to pursing this work at this time. The ongoing discussion on the list suggests that the arguments put forth for WESP use in the OSPFv3 context, the first concrete proposal outside of the middlebox inspection context that motivated WESP, have not been validated. The presentation in Hiroshima listed a variety of possible use cases, without providing any detailed analysis, and at least one such case was considered and rejected by the IPSEC WG on at least two occasions. My recollection is that Pasi agreed with my suggestion that at least 2 or 3 valid use cases need to be thoroughly vetted before the WG pursue this as a new work item. Steve From svanru@gmail.com Mon Nov 30 00:30:44 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17A583A6A1A for ; Mon, 30 Nov 2009 00:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, XMAILER_MIMEOLE_OL_7533E=0.513] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cntVEnTpEEC for ; Mon, 30 Nov 2009 00:30:43 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id D05AE3A67A3 for ; Mon, 30 Nov 2009 00:30:42 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so825788eyf.51 for ; Mon, 30 Nov 2009 00:30:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:references :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=B3kHoEqsGWhc0pp1nOYGYBbMhTF6b63zfh/5sRv3U4w=; b=xNJ6XV1wUFPrl4CDaqHOn0J4QK5QL3hxMu1VMuCsEsM8GABNKKkMarYi1DErsCcpFm P7xlTHrR7zVd3EV6lu6EgizMGkplSwIPFwtnvp65nvrujOHet0lOolck4PZ6HSEl2l9J y0JHLIhGUQ9xjIDKTRiyMrQ+Y/CZiOR7NJKAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=B1KiI9ppHbSc4zrJDpiD6eGOgltO3VmZgjNe/TR0kEg5IOcRY/vfjdqXbQ8Bk/vy40 PSnut2FKLlWlHEntvq60ryYXfG35hP/BF39unKpMsMhicaZjgps4qz/VHvtGyftPt9y0 H722VsaZJl+GPSJ0j/7NkU7EIrIscY+qlaMB8= Received: by 10.213.23.195 with SMTP id s3mr4185076ebb.5.1259569830351; Mon, 30 Nov 2009 00:30:30 -0800 (PST) Received: from svanpc ([82.138.51.4]) by mx.google.com with ESMTPS id 13sm2426132ewy.1.2009.11.30.00.30.28 (version=SSLv3 cipher=RC4-MD5); Mon, 30 Nov 2009 00:30:29 -0800 (PST) Message-ID: <7ACC151B796B45278F225762C0DE4BE4@trustworks.com> From: "Valery Smyslov" To: "IPsecme WG" , "Paul Hoffman" References: <19211.60135.834509.954897@fireball. kivinen.iki.fi><19213.9738.693741.41 0069@fireball.kivinen.iki.fi><19214. 26055.878779.973603@fireball.kivinen.iki.fi><7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0341@il-ex01.ad.checkpoin t.com> <4A045CD937B940C08E6E32600C6EA52C@trustworks.com> <9195EB81DDEB4A6996DDE00700C9552F@chichi> Date: Mon, 30 Nov 2009 11:30:27 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4963.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 08:30:44 -0000 > >You probably speaks about "ideal" developers. I speak about real people. > >I've seen a few cases when people implemented a bunch of really > >unnecessary things just because "it was in standard". > > We still agree, and your answer is still inconsistent. If you worry about > those type of developers, then you must want to get rid of the IANA registry, > because that is what is giving them the silly ideas. No, I didn't mean that. I meant that the simpler description of the protocol is, the better implementation is (usually) developed by an average person. In this context adding one more step in the process of developing may (and, I think, will) lead to increasing number of non-ineroperable implementations. I suspect, you may get just the opposite results than you expects. > >I fail to understand how removing values from the RFC will help > >understanding the context for them. > > The context for the values is "they are assigned and maintained by IANA". > It is not "they came from this RFC". You may not like that, but that's how the IETF works. IANA doesn't assign any number by its own will - there must be request for that number and a corresponding RFC. And if this is a change to existing number, then this new RFC must either update base RFC or make it obsolete. Is it right? And even laziest developer will start implementing from finding the most recent RFC, updates and errata. > >It's not hard, but what for? I see some drawbacks and I don't see > >how it will help interoperability. > > Again: it helps interoperability if developers look in the IANA registry at the time > of coding and see changes have been made to what they thought was true based > only on reading an RFC. Those changes don't come from IANA itself, they come from updating RFC. And it is this RFC, which developer starts implementing from, not IANA. And only after finding this RFC he/she will usually go to IANA. And making changes to already assigned values must be as rare as possible, because it automatically makes existing implementations non-compliant. On the other hand, adding new values usually doen't affect base protocol. > >In any case base RFC will be updated. And the first thing one must do before > >implementing any protocol is to find most recent RFC for it, including > >all updates and erratas. This is natural way to go, and if one starts > >implementing old RFC, then even if you manage to force him to go > >to IANA for numbers, I doubt if he will get interoperable product. > > The IANA registry lists the current RFCs. Do you not think that is enough clue? No. RFC Editor Search Engine gives much more information regarding current status of RFC, existence of updates and errata. IANA is best for looking for protocol extensions, but it gives only current snapshot of the situation. If some values were changed, IANA wouldn't keep old references, and if you want to keep your product interoperable with previous versions, IANA won't help you. And if you remove number values from RFC, keepeng new products interoperable with previous in case of changing some assigned values will become next to impossible - you just will have no sources for old numbers. Regards, Smyslov Valery. From kivinen@iki.fi Mon Nov 30 04:00:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A91993A6862 for ; Mon, 30 Nov 2009 04:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPPizSAz9nGi for ; Mon, 30 Nov 2009 04:00:51 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A6D9328C0E0 for ; Mon, 30 Nov 2009 04:00:48 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAUC0YNl006741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Nov 2009 14:00:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAUC0XcL010962; Mon, 30 Nov 2009 14:00:33 +0200 (EET) 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: <19219.46049.696782.749893@fireball.kivinen.iki.fi> Date: Mon, 30 Nov 2009 14:00:33 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <19211.60135.834509.954897@fireball. kivinen.iki.fi> <19213.9738.693741.41 0069@fireball.kivinen.iki.fi> <19214. 26055.878779.973603@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0341@il-ex01.ad.checkpoin t.com> <4A045CD937B940C08E6E32600C6EA52C@trustworks.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 19 min X-Total-Time: 20 min Cc: IPsecme WG , Valery Smyslov Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 12:00:52 -0000 Paul Hoffman writes: > If a developer does not know how to read the IANA tables, we are all > in trouble. Nothing in the tables says "you must implement every > thing in these tables", of course. Then we are already in trouble. There is lots of developers who do not know about the IANA tables, they just grab the RFCs (without knowing about the IETF) and start to implement them. Not all developers follow IETF work, and quite a lot of developers do not know how IETF work, and what is the relation between IETF and IANA and so on. Also I do not think developers NEED to know the this kind of things, it should be enough for them to grab the documents and implement them. I do not think it is mandatory for them to understand what different IANA registration procedures mean. There is also lots of developers who do not know the difference between Informational RFC and Standard track RFC, and if they see numbers in the IANA registry they will think they should implement all of them. > I am now deeply concerned with this WG's relationship to the IANA > registry. We are not talking about the developers who are working on this WG. The whole world is not this WG, there is other people out there. Also I myself do find extra unnecessary indirections very annoying, and if possible, I try to avoid those. > >3. Sometimes there might be difficulties in matching names from RFC > >with IANA entries. For example, IANA registry has an entry named > >ENCR_AES-CCM_8, but in RFC5282 this algorithm is called > >AEAD_AES_128_CCM_SHORT_8. Are you sure these names reference the > >same algorithm? I prefer to check their IDs in RFC and in IANA > >registry. > > This is a bug in the IANA registry that needs to be fixed. It is not really a bug in IANA registry, as RFC4106 use those names, and it did allocate them. It is bug in the RFC5282, which should have used the same names for the same algorithms. On the other hand the rfc5282 do have table mapping the names it uses to the ENCR identifier numbers, and it DOES NOT have IANA actions for the Encryption Transform identifiers table, as those numbers have already been allocated before. > It is not related to the values being in the RFC. Tero has spent a > lot of time trying to fix the registry, but clearly we need more > effort here. I will certainly make sure that the names in the > registry match those in RFC 4306, and that the exact names are used > in IKEv2bis. On of the problems is the RFC4106 which predates IKEv2, which means it used completely different naming scheme than what was used in the rest of the documents, i.e. their algorithms do not have ENCR_* format, but is just text. I do not think we change that anymore. > >4. Some entries in Diffie-Hellman Group Transform IDs table do not > >really assign individual numbers, but instead point to other > >documens, even to RFC4306 itself, where the numbers are assigned. > > Again, I am concerned that you think we should get rid of the IANA > registry. That is not how the IETF works. I do not think anybody proposed to get rid of the IANA registry. I think everybody agreed that yes, we should have pointer to the IANA registry. But as those numbers are never going to change, they should also be listed here. > >Those numbers won't change, so their > >presence must not hurt, > > This is probably incorrect. In many WGs, when errors are found in > old definitions, the error is corrected *and a new value is > assigned*. That is the only way to assure interoperability. Which means they existing numbers are not going to change. There may be new numbers meaning almost same thing (but with fixed semantics), but the old number can only mean exactly what was meant at the time the RFC was written. > >just will make implementing of base protocol more > >convinient. > > The goal of our work is clarity and interoperability, not > convenience, particularly when the inconvenience is remedied by one > extra lookup. Extra lookup which WILL cause more bugs, which means implementations are not interoperable. -- kivinen@iki.fi From kivinen@iki.fi Mon Nov 30 04:20:59 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6B6A3A6A4F for ; Mon, 30 Nov 2009 04:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyZtsWZBeDs2 for ; Mon, 30 Nov 2009 04:20:58 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3B93A686B for ; Mon, 30 Nov 2009 04:20:57 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAUCKnZo010532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Nov 2009 14:20:49 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAUCKmkx000079; Mon, 30 Nov 2009 14:20:48 +0200 (EET) 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: <19219.47264.428637.287552@fireball.kivinen.iki.fi> Date: Mon, 30 Nov 2009 14:20:48 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <19211.60135.834509.954897@fireball. kivinen.iki.fi> <19213.9738.693741.41 0069@fireball.kivinen.iki.fi> <19214. 26055.878779.973603@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0341@il-ex01.ad.checkpoin t.com> <4A045CD937B940C08E6E32600C6EA52C@trustworks.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 13 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 12:20:59 -0000 Valery Smyslov writes: > >> What about EAP Message format and magic numbers? Remove and just > >> reference RFC3748 (or IANA entry for EAP)? > > > > No, those were left in because they came from an RFC, not from a > > particular IANA registry where the names match what we have in IKEv2bis. > > EAP numbers listed in RFC4306 might also be changed in future, > so from your logic it's better just to point to > http://www.iana.org/assignments/eap-numbers, right? This is good example of confision what happens when you point to external iana registry. In RFC4306 we have "Nak (Response only)". If you look to the iana registry for eap, you cannot find that one. You do find "Legacy Nak". Are those two same? As both tables have also the number 2 associated to the code, you know they are same. Reading RFC3748 you notice that it uses both "Nak" and "Legacy Nak". > I don't agree with you. Remember, when IKEv2 was being developed, > one of the motivations for single self-contained document was complaint > from implementers that having 3 RFC (2408, 2409, 2407) for IKEv1 > was very inconvinient and provoked confusions that led to interoperability > problems. Now you suggest to make IKEv2 not self-contained again. > Of course, I understand that IANA registry is not another RFC, but > I still prefer single self-contained document for core protocol. > If you need extensions - go to IANA and look for added numbers, > but core protocol must be implementable reading as few sources, > as possible, preferrably one. I completely agree on that. -- kivinen@iki.fi From kivinen@iki.fi Mon Nov 30 04:43:30 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004893A6A60 for ; Mon, 30 Nov 2009 04:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4q3StpnkhM0 for ; Mon, 30 Nov 2009 04:43:29 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B9D973A677D for ; Mon, 30 Nov 2009 04:43:28 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAUChGXu029808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Nov 2009 14:43:16 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAUChEtc006394; Mon, 30 Nov 2009 14:43:14 +0200 (EET) 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: <19219.48610.784911.946017@fireball.kivinen.iki.fi> Date: Mon, 30 Nov 2009 14:43:14 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <9195EB81DDEB4A6996DDE00700C9552F@chichi> References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 13 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Diffie-Hellman group transform IDs IANA registry (was #123: ...) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 12:43:30 -0000 Now talking only about the Tranform Type 4 - Diffie-Hellman Group Transform IDs IANA registry. Valery Smyslov writes: > Currently exact groups for numbers 1, 2, 14, 15, 16, 17 and 16 are not > defined in IANA. > For me this is inconsistent. Either change two abovementioned lines to: > > 1 768-Bit MODP Group [RFC4306] > 2 1024-Bit MODP Group [RFC4306] > > 14 2048-Bit MODP Group [RFC3526] > 15 3072-Bit MODP Group [RFC3526] > 16 4096-Bit MODP Group [RFC3526] > 17 6144-Bit MODP Group [RFC3526] > 18 8192-Bit MODP Group [RFC3526] Hmm... I think the IANA registry should really list these out, instead of using range to reference to the RFCs. I think we should fix the IANA registry so the group names will match the section / appendix names in the appropriate RFCs and where there would not be any range allocations. The resulting IANA registry would be like this: ---------------------------------------------------------------------- Registry Name: Transform Type 4 - Diffie-Hellman Group Transform IDs Reference: [RFC4306] Registration Procedures: Expert Review Registry: Number Name Reference ------------ ---------------------------------- --------- 0 NONE [RFC4306] 1 Group 1 - 768 Bit MODP Group [RFC4306] 2 Group 2 - 1024 Bit MODP Group [RFC4306] 3-4 Reserved [RFC4306] 5 1536-bit MODP Group [RFC3526] 6-13 Unassigned [RFC4306] 14 2048-bit MODP Group [RFC3526] 15 3072-bit MODP Group [RFC3526] 16 4096-bit MODP Group [RFC3526] 17 6144-bit MODP Group [RFC3526] 18 8192-bit MODP Group [RFC3526] 19 256-bit random ECP group [RFC4753] 20 384-bit random ECP group [RFC4753] 21 521-bit random ECP group [RFC4753] 22 1024-bit MODP Group with 160-bit [RFC5114] Prime Order Subgroup 23 2048-bit MODP Group with 224-bit [RFC5114] Prime Order Subgroup 24 2048-bit MODP Group with 256-bit [RFC5114] Prime Order Subgroup 25 192-bit Random ECP Group [RFC5114] 26 224-bit Random ECP Group [RFC5114] 27-1023 Unassigned [RFC4306] 1024-65535 Private use [RFC4306] ---------------------------------------------------------------------- Unless anybody objects, I will be requesting IANA to make the change next week. -- kivinen@iki.fi From wierbows@us.ibm.com Mon Nov 30 06:02:55 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1093A6923 for ; Mon, 30 Nov 2009 06:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGXcqUdcsrcZ for ; Mon, 30 Nov 2009 06:02:54 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id A26183A68B9 for ; Mon, 30 Nov 2009 06:02:54 -0800 (PST) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e3.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id nAUDrtpV012722 for ; Mon, 30 Nov 2009 08:53:55 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nAUE2daS1847330 for ; Mon, 30 Nov 2009 09:02:39 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nAUE2Hul020893 for ; Mon, 30 Nov 2009 09:02:17 -0500 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nAUE2HGi020887 for ; Mon, 30 Nov 2009 09:02:17 -0500 In-Reply-To: <19219.47264.428637.287552@fireball.kivinen.iki.fi> References: <19211.60135.834509.954897@fireball. kivinen.iki.fi> <19213.9738.693741.41 0069@fireball.kivinen.iki.fi> <19214. 26055.878779.973603@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0341@il-ex01.ad.checkpoin t.com> <4A045CD937B940C08E6E32600C6EA52C@trustworks.com> <19219.47264.428637.287552@fireball.kivinen.iki.fi> X-KeepSent: F40E49A8:BE618ACC-8525767E:004CD857; type=4; name=$KeepSent To: IPsecme WG X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Mon, 30 Nov 2009 09:02:10 -0500 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 11/30/2009 09:02:17 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFCEDDFDF5EC78f9e8a93df938690918c0ABBFCEDDFDF5EC7" Content-Disposition: inline Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 14:02:55 -0000 --0__=0ABBFCEDDFDF5EC78f9e8a93df938690918c0ABBFCEDDFDF5EC7 Content-type: text/plain; charset=US-ASCII >> I don't agree with you. Remember, when IKEv2 was being developed, >> one of the motivations for single self-contained document was complaint >> from implementers that having 3 RFC (2408, 2409, 2407) for IKEv1 >> was very inconvinient and provoked confusions that led to interoperability >> problems. Now you suggest to make IKEv2 not self-contained again. >> Of course, I understand that IANA registry is not another RFC, but >> I still prefer single self-contained document for core protocol. >> If you need extensions - go to IANA and look for added numbers, >> but core protocol must be implementable reading as few sources, >> as possible, preferrably one. > >I completely agree on that. I also agree with Valery and Tero. Dave Wierbowski --0__=0ABBFCEDDFDF5EC78f9e8a93df938690918c0ABBFCEDDFDF5EC7 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

>> I don't agree with you. Remember, when IKEv2 was being developed,
>> one of the motivations for single self-contained document was complaint
>> from implementers that having 3 RFC (2408, 2409, 2407) for IKEv1
>> was very inconvinient and provoked confusions that led to interoperability
>> problems. Now you suggest to make IKEv2 not self-contained again.
>> Of course, I understand that IANA registry is not another RFC, but
>> I still prefer single self-contained document for core protocol.
>> If you need extensions - go to IANA and look for added numbers,
>> but core protocol must be implementable reading as few sources,
>> as possible, preferrably one.
>
>I completely agree on that.

I also agree with Valery and Tero.

Dave Wierbowski




--0__=0ABBFCEDDFDF5EC78f9e8a93df938690918c0ABBFCEDDFDF5EC7-- From root@core3.amsl.com Mon Nov 30 07:15:02 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7EAAF28C122; Mon, 30 Nov 2009 07:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091130151502.7EAAF28C122@core3.amsl.com> Date: Mon, 30 Nov 2009 07:15:01 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-esp-null-heuristics-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 15:15:02 -0000 --NextPart 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 : Heuristics for Detecting ESP-NULL packets Author(s) : T. Kivinen, D. McDonald Filename : draft-ietf-ipsecme-esp-null-heuristics-03.txt Pages : 36 Date : 2009-11-30 This document describes a set of heuristics for distinguishing IPsec ESP-NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. These heuristics can be used on intermediate devices, like traffic analyzers, and deep inspection engines, to quickly decide whether given packet flow is interesting or not. Use of these heuristics does not require any changes made on existing RFC4303 compliant IPsec hosts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-esp-null-heuristics-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-esp-null-heuristics-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-30070937.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Nov 30 08:15:04 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1DC8128C12A; Mon, 30 Nov 2009 08:15:03 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091130161504.1DC8128C12A@core3.amsl.com> Date: Mon, 30 Nov 2009 08:15:04 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 16:15:05 -0000 --NextPart 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 : Wrapped ESP for Traffic Visibility Author(s) : K. Grewal, et al. Filename : draft-ietf-ipsecme-traffic-visibility-11.txt Pages : 15 Date : 2009-11-30 This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on the Encapsulating Security Payload (ESP) [RFC4303], and is designed to allow intermediate devices to (1) ascertain if data confidentiality is being employed within ESP and if not, (2) inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec ESP standard, there is no way to differentiate between encrypted and unencrypted payloads by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate integrity-only ESP from ESP-encrypted packets, without compromising on the security provided by ESP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-traffic-visibility-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-30081315.I-D@ietf.org> --NextPart-- From paul.hoffman@vpnc.org Mon Nov 30 09:34:58 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D099E3A6ADA for ; Mon, 30 Nov 2009 09:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEjZqgHfhqtz for ; Mon, 30 Nov 2009 09:34:58 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 139A93A6971 for ; Mon, 30 Nov 2009 09:34:58 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-109-47.dhcp.cruzio.com [63.249.109.47]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nAUHYlnA043695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Nov 2009 10:34:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19219.48610.784911.946017@fireball.kivinen.iki.fi> References: <19219.48610.784911.946017@fireball.kivinen.iki.fi> Date: Mon, 30 Nov 2009 09:34:47 -0800 To: Tero Kivinen , "Valery Smyslov" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] Diffie-Hellman group transform IDs IANA registry (was #123: ...) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 17:34:58 -0000 At 2:43 PM +0200 11/30/09, Tero Kivinen wrote: >Unless anybody objects, I will be requesting IANA to make the change >next week. Not only do I not object, I thank you for doing something I volunteered to do. --Paul Hoffman, Director --VPN Consortium From dharkins@lounge.org Mon Nov 30 15:06:23 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E413728C156 for ; Mon, 30 Nov 2009 15:06:23 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-uABkRR4YWW for ; Mon, 30 Nov 2009 15:06:23 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 0E6CB28C148 for ; Mon, 30 Nov 2009 15:06:23 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id EB5D81022407E; Mon, 30 Nov 2009 15:06:15 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 30 Nov 2009 15:06:16 -0800 (PST) Message-ID: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.co m> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> Date: Mon, 30 Nov 2009 15:06:16 -0800 (PST) From: "Dan Harkins" To: "Yaron Sheffer" 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 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 23:06:24 -0000 Hello, I do not believe this is a reasonable activity to spend WG time on. The reason is that for this proposal to be useful for more than a small, specific, edge condition the following must apply: - both sides MUST implement both client- and server-side EAP state machines. - both sides MUST possess the shared secret. And in that case EAP encapsulation of the underlying key exchange would be completely pointless and extraneous, would double the number of messages required to complete the exchange, and would increase the amount of security-critical code. More work for no benefit...not a good idea. In addition, EAP-only authentication increases potential insecurity, where an external EAP server can authenticate any identity an IKEv2 gateway wants to claim-- the "lying NAS problem". Authentication depends on a verifiable identity and if one side can claim any identity it chooses then the mutual authentication properties of IKE cannot be met. Even if one believes that the small, specific, edge condition is really important there is an alternative to address that case, one that can also address other peer-to-peer, subnet-to-subnet, and tranport mode, use cases. That is the "Secure PSK authentication" option as defined in draft-harkins-ipsecme-spsk-auth-00.txt. It seems to me that EAP-only authentication in IKEv2: 1. does not solve a general problem; 2. solves the specific problem it is aimed at poorly-- doubling of the number of messages, requiring writing and testing of new state EAP state machines that are, otherwise, unnecessary; and, 3. is insecure (unless something used nowhere today is employed: EAP channel bindings). To provide the benefits of EAP-only authentication-- certificate-less mutual authentication based only on a password-- it would be much better to support the inclusion of "Secure PSK authentication" as a work item. That work item will not only address the small use case that EAP-only authentication is aimed at, it will also address other peer-to-peer, subnet-to-subnet, and transport-mode use cases. And it will do so in a manner that ensures security. regards, Dan. On Sun, November 29, 2009 9:18 am, Yaron Sheffer wrote: > This draft proposes an IKEv2 extension to allow mutual EAP-based > authentication in IKEv2, eliminating the need for one of the peers to > present a certificate. This applies to a small number of key-generating > EAP methods that allow mutual authentication. >   > Proposed starting point: > http://tools.ietf.org/id/draft-eronen-ipsec-ikev2-eap-auth-07.txt. >   > Please reply to the list: >   > - If this proposal is accepted as a WG work item, are you committing to > review multiple versions of the draft? > - Are you willing to contribute text to the draft? > - Would you like to co-author it? >   > Please also reply to the list if: >   > - You believe this is NOT a reasonable activity for the WG to spend time > on. >   > If this is the case, please explain your position. Do not explore the fine > technical details (which will change anyway, once the WG gets hold of the > draft); instead explain why this is uninteresting for the WG or for the > industry at large. Also, please mark the title clearly (e.g. "DES40-export > in IPsec - NO!"). > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From dharkins@lounge.org Mon Nov 30 15:16:16 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58213A697D for ; Mon, 30 Nov 2009 15:16:16 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SY8uSFlqFaLu for ; Mon, 30 Nov 2009 15:16:15 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id B7DD63A6847 for ; Mon, 30 Nov 2009 15:16:15 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 7FD841022407E; Mon, 30 Nov 2009 15:16:08 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 30 Nov 2009 15:16:08 -0800 (PST) Message-ID: <24a859db202868361dcaff4fe54ee1f1.squirrel@www.trepanning.net> In-Reply-To: <19219.48610.784911.946017@fireball.kivinen.iki.fi> References: <19219.48610.784911.946017@fireball.kivinen.iki.fi> Date: Mon, 30 Nov 2009 15:16:08 -0800 (PST) From: "Dan Harkins" To: "Tero Kivinen" 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 Cc: IPsecme WG , Valery Smyslov , Paul Hoffman Subject: Re: [IPsec] Diffie-Hellman group transform IDs IANA registry (was #123: ...) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 23:16:16 -0000 Hi Tero, Groups 1 and 2 were defined in RFC 2409 and repeating them in a subsequent RFC does not change that. I suggest leaving the reference to RFC 2409 for groups 1 and 2 (and 3 and 4 for that matter) that currently exists today at http://www.iana.org/assignments/ipsec-registry, as of 2315 GMT on 30 November 2009, aka "right now". regards, Dan. On Mon, November 30, 2009 4:43 am, Tero Kivinen wrote: > Now talking only about the Tranform Type 4 - Diffie-Hellman Group > Transform IDs IANA registry. > > Valery Smyslov writes: >> Currently exact groups for numbers 1, 2, 14, 15, 16, 17 and 16 are not >> defined in IANA. >> For me this is inconsistent. Either change two abovementioned lines to: >> >> 1 768-Bit MODP Group [RFC4306] >> 2 1024-Bit MODP Group [RFC4306] >> >> 14 2048-Bit MODP Group [RFC3526] >> 15 3072-Bit MODP Group [RFC3526] >> 16 4096-Bit MODP Group [RFC3526] >> 17 6144-Bit MODP Group [RFC3526] >> 18 8192-Bit MODP Group [RFC3526] > > Hmm... I think the IANA registry should really list these out, instead > of using range to reference to the RFCs. > > I think we should fix the IANA registry so the group names will match > the section / appendix names in the appropriate RFCs and where there > would not be any range allocations. The resulting IANA registry would > be like this: > ---------------------------------------------------------------------- > Registry Name: Transform Type 4 - Diffie-Hellman Group Transform IDs > Reference: [RFC4306] > Registration Procedures: Expert Review > > Registry: > Number Name Reference > ------------ ---------------------------------- --------- > 0 NONE [RFC4306] > 1 Group 1 - 768 Bit MODP Group [RFC4306] > 2 Group 2 - 1024 Bit MODP Group [RFC4306] > 3-4 Reserved [RFC4306] > 5 1536-bit MODP Group [RFC3526] > 6-13 Unassigned [RFC4306] > 14 2048-bit MODP Group [RFC3526] > 15 3072-bit MODP Group [RFC3526] > 16 4096-bit MODP Group [RFC3526] > 17 6144-bit MODP Group [RFC3526] > 18 8192-bit MODP Group [RFC3526] > 19 256-bit random ECP group [RFC4753] > 20 384-bit random ECP group [RFC4753] > 21 521-bit random ECP group [RFC4753] > 22 1024-bit MODP Group with 160-bit [RFC5114] > Prime Order Subgroup > 23 2048-bit MODP Group with 224-bit [RFC5114] > Prime Order Subgroup > 24 2048-bit MODP Group with 256-bit [RFC5114] > Prime Order Subgroup > 25 192-bit Random ECP Group [RFC5114] > 26 224-bit Random ECP Group [RFC5114] > 27-1023 Unassigned [RFC4306] > 1024-65535 Private use [RFC4306] > ---------------------------------------------------------------------- > > Unless anybody objects, I will be requesting IANA to make the change > next week. > > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From dharkins@lounge.org Mon Nov 30 15:35:11 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FDDE28C133 for ; Mon, 30 Nov 2009 15:35:11 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eC3cXd7U2MVw for ; Mon, 30 Nov 2009 15:35:10 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 7F8D43A67E9 for ; Mon, 30 Nov 2009 15:35:10 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E3BE31022407E; Mon, 30 Nov 2009 15:35:02 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 30 Nov 2009 15:35:03 -0800 (PST) Message-ID: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.co m> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.com> Date: Mon, 30 Nov 2009 15:35:03 -0800 (PST) From: "Dan Harkins" To: "Yaron Sheffer" 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 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 23:35:11 -0000 Hello, As can be inferred by my previous posting on EAP-only authentication, I favor this particular method for mutual authentication. I believe this is a general purpose exchange, useful for more than the narrow focus of EAP-only, does not require extraneous encapsulations or unnecessary code (ala EAP-only), and is secure regardless of its use (unlike EAP-only). I am committed to working on this as a WG work item. I agree to continue contributing to the text and (co-)authoring the text. I solicit help, and support, from those who are interested in this task. regards, Dan. On Sun, November 29, 2009 9:20 am, Yaron Sheffer wrote: > This draft proposes a particular method for mutual authentication of IKEv2 > peers using a short, low quality shared secret (a.k.a. "password"). The > proposal is to embed this method in the IKE exchange, rather than use EAP. > > Proposed starting point: > http://tools.ietf.org/id/draft-harkins-ipsecme-spsk-auth-00.txt. >   > Please reply to the list: >   > - If this proposal is accepted as a WG work item, are you committing to > review multiple versions of the draft? > - Are you willing to contribute text to the draft? > - Would you like to co-author it? >   > Please also reply to the list if: >   > - You believe this is NOT a reasonable activity for the WG to spend time > on. >   > If this is the case, please explain your position. Do not explore the fine > technical details (which will change anyway, once the WG gets hold of the > draft); instead explain why this is uninteresting for the WG or for the > industry at large. Also, please mark the title clearly (e.g. "DES40-export > in IPsec - NO!"). > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From yaronf@checkpoint.com Mon Nov 30 22:47:20 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80CB63A6857 for ; Mon, 30 Nov 2009 22:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cghnk96S-edH for ; Mon, 30 Nov 2009 22:47:19 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 31EFF3A6834 for ; Mon, 30 Nov 2009 22:47:18 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nB16l9Gq023917; Tue, 1 Dec 2009 08:47:10 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 1 Dec 2009 08:47:16 +0200 From: Yaron Sheffer To: Dan Harkins Date: Tue, 1 Dec 2009 08:46:59 +0200 Thread-Topic: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO Thread-Index: AcpyFcNWtnITD+o3R4Omn2hAN3inxQAOOflQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 06:47:20 -0000 Hi everyone, [WG co-chair hat off] I believe this effort is misguided, and would be a waste of the WG time. EAP was added to IKEv2 to provide "legacy" (a.k.a. password) authentication= . In the past it did not do it very well, but this is changing. We should i= mprove the use of EAP in IKEv2, rather than replacing it by a homebrew solu= tion. Specifically, the following EAP methods can be used today (or in the near f= uture) for mutual password-based auth: - Dan's own EAP-PWD, http://tools.ietf.org/html/draft-harkins-emu-eap-pwd-1= 2 - My EAP-EKE, http://tools.ietf.org/html/draft-sheffer-emu-eap-eke-03 - The long expired EAP-SRP, http://tools.ietf.org/html/draft-ietf-pppext-ea= p-srp-03 - A rumored EAP method based on the PAK protocol (http://tools.ietf.org/htm= l/draft-brusilovsky-pak-10) Embedding one of these methods as the single way to do mutual auth in IKE s= imply doesn't make sense. In addition, SPSK (which is equivalent to EAP-PWD) is a novel crypto protoc= ol. It has had by far the least crypto review than the other three protocol= s. IMHO, this working group should NOT be developing new cryptographic prot= ocols. This is not where our expertise lies. Lastly, one of the major criticisms with IKEv1 was the number of protocol m= odes. And here we are, with a proposal to add another mode to IKEv2. Doesn'= t seem like a good idea to me. Thanks, Yaron > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Tuesday, December 01, 2009 1:35 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication > (SPSK) >=20 >=20 > Hello, >=20 > As can be inferred by my previous posting on EAP-only authentication, > I favor this particular method for mutual authentication. >=20 > I believe this is a general purpose exchange, useful for more than the > narrow focus of EAP-only, does not require extraneous encapsulations or > unnecessary code (ala EAP-only), and is secure regardless of its use > (unlike EAP-only). >=20 > I am committed to working on this as a WG work item. I agree to continu= e > contributing to the text and (co-)authoring the text. I solicit help, and > support, from those who are interested in this task. >=20 > regards, >=20 > Dan. >=20 > On Sun, November 29, 2009 9:20 am, Yaron Sheffer wrote: > > This draft proposes a particular method for mutual authentication of > IKEv2 > > peers using a short, low quality shared secret (a.k.a. "password"). The > > proposal is to embed this method in the IKE exchange, rather than use > EAP. > > > > Proposed starting point: > > http://tools.ietf.org/id/draft-harkins-ipsecme-spsk-auth-00.txt. > > > > Please reply to the list: > > > > - If this proposal is accepted as a WG work item, are you committing to > > review multiple versions of the draft? > > - Are you willing to contribute text to the draft? > > - Would you like to co-author it? > > > > Please also reply to the list if: > > > > - You believe this is NOT a reasonable activity for the WG to spend tim= e > > on. > > > > If this is the case, please explain your position. Do not explore the > fine > > technical details (which will change anyway, once the WG gets hold of > the > > draft); instead explain why this is uninteresting for the WG or for the > > industry at large. Also, please mark the title clearly (e.g. "DES40- > export > > in IPsec - NO!"). > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > >=20 >=20 >=20 > Scanned by Check Point Total Security Gateway. From yaronf@checkpoint.com Mon Nov 30 22:47:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495C43A6B07 for ; Mon, 30 Nov 2009 22:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9BMn1Btpl6Z for ; Mon, 30 Nov 2009 22:47:24 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 8F77C3A6B02 for ; Mon, 30 Nov 2009 22:47:23 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nB16l9Gp023917; Tue, 1 Dec 2009 08:47:10 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 1 Dec 2009 08:47:16 +0200 From: Yaron Sheffer To: Dan Harkins Date: Tue, 1 Dec 2009 08:47:15 +0200 Thread-Topic: [IPsec] Proposed work item: EAP-only authentication in IKEv2 Thread-Index: AcpyEb9IC7pRZflCTFeqecHbJFfF2gAOboxA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DC@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 06:47:25 -0000 Hello Dan, [WG co-chair hat off] EAP-only authentication is a small IKE extension that does not change the e= xisting IKE architecture; neither does it change many of the extant impleme= ntations. Given the right EAP methods, it would provide us exactly what EAP= was supposed to provide from day one: mutual non-PKI authentication. And the solution is generic: any suitable EAP method can be deployed, so im= plementors can make their own security/interoperability/IPR/simplicity trad= eoffs, instead of having one specific authentication method mandated. To address your specific concerns: - The case of client-to-gateway authentication happens to be one of the top= use cases of IKE/IPsec. Certainly not a "small use case". I'm not saying t= hat EAP-only auth is limited to this use case, but it certainly solves it w= ell. - It would depend very much on the specific product/scenario whether "both = client and server state machines" need to be implemented. Specifically this= is incorrect for client-to-gateway. - EAP as you well know is a 3-party protocol, it is not necessarily termina= ted on the IKE peer. So it is incorrect to say that "both sides MUST posses= s the shared secret" - exactly the right parties will need to: the client a= nd the authentication server. - EAP-only auth can also be applied to scenarios where no Auth Server is de= ployed. However in these cases both peers would indeed need a full EAP impl= ementation. - The EAP community is (very slowly) coming to terms with EAP channel bindi= ngs. While this is not provided by your EAP-PWD (and I hope this is fixed b= efore publication), EAP-EKE has been extended to add this capability. Thanks, Yaron > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Tuesday, December 01, 2009 1:06 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2 >=20 >=20 > Hello, >=20 > I do not believe this is a reasonable activity to spend WG time on. > The reason is that for this proposal to be useful for more than a > small, specific, edge condition the following must apply: >=20 > - both sides MUST implement both client- and server-side EAP state > machines. > - both sides MUST possess the shared secret. >=20 > And in that case EAP encapsulation of the underlying key exchange would > be completely pointless and extraneous, would double the number of > messages required to complete the exchange, and would increase the amount > of security-critical code. More work for no benefit...not a good idea. >=20 > In addition, EAP-only authentication increases potential insecurity, > where an external EAP server can authenticate any identity an IKEv2 > gateway wants to claim-- the "lying NAS problem". Authentication depends > on a verifiable identity and if one side can claim any identity it choose= s > then the mutual authentication properties of IKE cannot be met. >=20 > Even if one believes that the small, specific, edge condition is really > important there is an alternative to address that case, one that can also > address other peer-to-peer, subnet-to-subnet, and tranport mode, use > cases. That is the "Secure PSK authentication" option as defined in > draft-harkins-ipsecme-spsk-auth-00.txt. >=20 > It seems to me that EAP-only authentication in IKEv2: >=20 > 1. does not solve a general problem; > 2. solves the specific problem it is aimed at poorly-- doubling of > the number of messages, requiring writing and testing of new > state EAP state machines that are, otherwise, unnecessary; and, > 3. is insecure (unless something used nowhere today is employed: EAP > channel bindings). >=20 > To provide the benefits of EAP-only authentication-- certificate-less > mutual authentication based only on a password-- it would be much better > to support the inclusion of "Secure PSK authentication" as a work item. > That work item will not only address the small use case that EAP-only > authentication is aimed at, it will also address other peer-to-peer, > subnet-to-subnet, and transport-mode use cases. And it will do so in a > manner that ensures security. >=20 > regards, >=20 > Dan. >=20 > On Sun, November 29, 2009 9:18 am, Yaron Sheffer wrote: > > This draft proposes an IKEv2 extension to allow mutual EAP-based > > authentication in IKEv2, eliminating the need for one of the peers to > > present a certificate. This applies to a small number of key-generating > > EAP methods that allow mutual authentication. > > > > Proposed starting point: > > http://tools.ietf.org/id/draft-eronen-ipsec-ikev2-eap-auth-07.txt. > > > > Please reply to the list: > > > > - If this proposal is accepted as a WG work item, are you committing to > > review multiple versions of the draft? > > - Are you willing to contribute text to the draft? > > - Would you like to co-author it? > > > > Please also reply to the list if: > > > > - You believe this is NOT a reasonable activity for the WG to spend tim= e > > on. > > > > If this is the case, please explain your position. Do not explore the > fine > > technical details (which will change anyway, once the WG gets hold of > the > > draft); instead explain why this is uninteresting for the WG or for the > > industry at large. Also, please mark the title clearly (e.g. "DES40- > export > > in IPsec - NO!"). > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > >=20 >=20 >=20 > Scanned by Check Point Total Security Gateway. From mcins1@gmail.com Mon Nov 30 23:11:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B02828C1B4 for ; Mon, 30 Nov 2009 23:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gmh4E-cIHm2 for ; Mon, 30 Nov 2009 23:11:25 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 359433A6B07 for ; Mon, 30 Nov 2009 23:11:25 -0800 (PST) Received: by yxe30 with SMTP id 30so9832141yxe.29 for ; Mon, 30 Nov 2009 23:11:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=13P5G94YxZdPlFWWTY4nr+hppF7y0P2nMme0VvWpd3I=; b=c232I/+WKslOv6PwHLzmKcCP8YjVe4bIAw6+0jq/padQHMGirOxld7C3sQkuSYcyvz Oin/P9MFN0qs4mMkewJwKlo4q5+PAUU/Y46dhd1FQLYPGtyAEdmcEYdN5skzWdlOOe0M y/bmTFKSDbcVXNq/gq4VnWwlJK6AD73lG7Y64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=c8dBbB6861juj/QHNs0cQ23EXMMShPjAwyocfj7PWbv6S3vJeM4mBtFYMbmhkWBaZQ 5kdEn+47EMxhE/uPDofPTa3jiSkKVKiMY28SbToe9xomeblxdO3FEhso2sOmSAtiBMRt 6XGsPHxkbwEDJep+eMxQXR9NiM/FGhTr45wIY= MIME-Version: 1.0 Received: by 10.90.37.37 with SMTP id k37mr7725276agk.64.1259651473089; Mon, 30 Nov 2009 23:11:13 -0800 (PST) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.com> From: Matthew Cini Sarreo Date: Tue, 1 Dec 2009 08:10:53 +0100 Message-ID: <99043b4a0911302310v7f2edf00l8d210b1d1e7d14a8@mail.gmail.com> To: Yaron Sheffer , ipsec@ietf.org Content-Type: multipart/alternative; boundary=0016362835829824530479a576e3 Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 07:11:27 -0000 --0016362835829824530479a576e3 Content-Type: text/plain; charset=ISO-8859-1 >From a developer point of view, I share the same opinion as Yaron about this issue. Instead of creating new solutions, I personally think that it would be better to offer guidlines on how to implement current solutions (i.e EAP) and provide documents targeting implementers. This would create less confusion and keep IKEv2 a clean, easy to understand and use protocol. Regards, Matthew 2009/12/1 Yaron Sheffer > Hi everyone, > > [WG co-chair hat off] > > I believe this effort is misguided, and would be a waste of the WG time. > > EAP was added to IKEv2 to provide "legacy" (a.k.a. password) > authentication. In the past it did not do it very well, but this is > changing. We should improve the use of EAP in IKEv2, rather than replacing > it by a homebrew solution. > > Specifically, the following EAP methods can be used today (or in the near > future) for mutual password-based auth: > > - Dan's own EAP-PWD, > http://tools.ietf.org/html/draft-harkins-emu-eap-pwd-12 > - My EAP-EKE, http://tools.ietf.org/html/draft-sheffer-emu-eap-eke-03 > - The long expired EAP-SRP, > http://tools.ietf.org/html/draft-ietf-pppext-eap-srp-03 > - A rumored EAP method based on the PAK protocol ( > http://tools.ietf.org/html/draft-brusilovsky-pak-10) > > Embedding one of these methods as the single way to do mutual auth in IKE > simply doesn't make sense. > > In addition, SPSK (which is equivalent to EAP-PWD) is a novel crypto > protocol. It has had by far the least crypto review than the other three > protocols. IMHO, this working group should NOT be developing new > cryptographic protocols. This is not where our expertise lies. > > Lastly, one of the major criticisms with IKEv1 was the number of protocol > modes. And here we are, with a proposal to add another mode to IKEv2. > Doesn't seem like a good idea to me. > > Thanks, > Yaron > > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@lounge.org] > > Sent: Tuesday, December 01, 2009 1:35 > > To: Yaron Sheffer > > Cc: ipsec@ietf.org > > Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication > > (SPSK) > > > > > > Hello, > > > > As can be inferred by my previous posting on EAP-only authentication, > > I favor this particular method for mutual authentication. > > > > I believe this is a general purpose exchange, useful for more than the > > narrow focus of EAP-only, does not require extraneous encapsulations or > > unnecessary code (ala EAP-only), and is secure regardless of its use > > (unlike EAP-only). > > > > I am committed to working on this as a WG work item. I agree to > continue > > contributing to the text and (co-)authoring the text. I solicit help, and > > support, from those who are interested in this task. > > > > regards, > > > > Dan. > > > > On Sun, November 29, 2009 9:20 am, Yaron Sheffer wrote: > > > This draft proposes a particular method for mutual authentication of > > IKEv2 > > > peers using a short, low quality shared secret (a.k.a. "password"). The > > > proposal is to embed this method in the IKE exchange, rather than use > > EAP. > > > > > > Proposed starting point: > > > http://tools.ietf.org/id/draft-harkins-ipsecme-spsk-auth-00.txt. > > > > > > Please reply to the list: > > > > > > - If this proposal is accepted as a WG work item, are you committing to > > > review multiple versions of the draft? > > > - Are you willing to contribute text to the draft? > > > - Would you like to co-author it? > > > > > > Please also reply to the list if: > > > > > > - You believe this is NOT a reasonable activity for the WG to spend > time > > > on. > > > > > > If this is the case, please explain your position. Do not explore the > > fine > > > technical details (which will change anyway, once the WG gets hold of > > the > > > draft); instead explain why this is uninteresting for the WG or for the > > > industry at large. Also, please mark the title clearly (e.g. "DES40- > > export > > > in IPsec - NO!"). > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > > Scanned by Check Point Total Security Gateway. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0016362835829824530479a576e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >From a developer point of view, I share the same opinion as Yaron about thi= s issue. Instead of creating new solutions, I personally think that it woul= d be better to offer guidlines on how to implement current solutions (i.e E= AP) and provide documents targeting implementers. This would create less co= nfusion and keep IKEv2 a clean, easy to understand and use protocol.

Regards,
Matthew

2009/12/1 Yaron S= heffer <yaron= f@checkpoint.com>
Hi everyone,

[WG co-chair hat off]

I believe this effort is misguided, and would be a waste of the WG time.
EAP was added to IKEv2 to provide "legacy" (a.k.a. password) auth= entication. In the past it did not do it very well, but this is changing. W= e should improve the use of EAP in IKEv2, rather than replacing it by a hom= ebrew solution.

Specifically, the following EAP methods can be used today (or in the near f= uture) for mutual password-based auth:

- Dan's own EAP-PWD, http://tools.ietf.org/html/draft-harkin= s-emu-eap-pwd-12
- My EAP-EKE, http://tools.ietf.org/html/draft-sheffer-emu-eap-e= ke-03
- The long expired EAP-SRP, http://tools.ietf.org/html/draft-iet= f-pppext-eap-srp-03
- A rumored EAP method based on the PAK protocol (http://tools.ietf.= org/html/draft-brusilovsky-pak-10)

Embedding one of these methods as the single way to do mutual auth in IKE s= imply doesn't make sense.

In addition, SPSK (which is equivalent to EAP-PWD) is a novel crypto protoc= ol. It has had by far the least crypto review than the other three protocol= s. IMHO, this working group should NOT be developing new cryptographic prot= ocols. This is not where our expertise lies.

Lastly, one of the major criticisms with IKEv1 was the number of protocol m= odes. And here we are, with a proposal to add another mode to IKEv2. Doesn&= #39;t seem like a good idea to me.

Thanks,
=A0 =A0 =A0 =A0Yaron


> -----Original Message-----
> From: Dan Harkins [mailto:dhark= ins@lounge.org]
> Sent: Tuesday, December 01, 2009 1:35
> To: Yaron Sheffer
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication=
> (SPSK)
>
>
> =A0 Hello,
>
> =A0 As can be inferred by my previous posting on EAP-only authenticati= on,
> I favor this particular method for mutual authentication.
>
> =A0 I believe this is a general purpose exchange, useful for more than= the
> narrow focus of EAP-only, does not require extraneous encapsulations o= r
> unnecessary code (ala EAP-only), and is secure regardless of its use > (unlike EAP-only).
>
> =A0 I am committed to working on this as a WG work item. I agree to co= ntinue
> contributing to the text and (co-)authoring the text. I solicit help, = and
> support, from those who are interested in this task.
>
> =A0 regards,
>
> =A0 Dan.
>
> On Sun, November 29, 2009 9:20 am, Yaron Sheffer wrote:
> > This draft proposes a particular method for mutual authentication= of
> IKEv2
> > peers using a short, low quality shared secret (a.k.a. "pass= word"). The
> > proposal is to embed this method in the IKE exchange, rather than= use
> EAP.
> >
> > Proposed starting point:
> > http://tools.ietf.org/id/draft-harkins-ipsecme= -spsk-auth-00.txt.
> >
> > Please reply to the list:
> >
> > - If this proposal is accepted as a WG work item, are you committ= ing to
> > review multiple versions of the draft?
> > - Are you willing to contribute text to the draft?
> > - Would you like to co-author it?
> >
> > Please also reply to the list if:
> >
> > - You believe this is NOT a reasonable activity for the WG to spe= nd time
> > on.
> >
> > If this is the case, please explain your position. Do not explore= the
> fine
> > technical details (which will change anyway, once the WG gets hol= d of
> the
> > draft); instead explain why this is uninteresting for the WG or f= or the
> > industry at large. Also, please mark the title clearly (e.g. &quo= t;DES40-
> export
> > in IPsec - NO!").
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
>
>
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--0016362835829824530479a576e3--