From dharkins@lounge.org Tue Dec 1 00:19: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 59FA728C1AF for ; Tue, 1 Dec 2009 00:19:36 -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 iopwngIdHu6i for ; Tue, 1 Dec 2009 00:19:35 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 184D13A6908 for ; Tue, 1 Dec 2009 00:19:35 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 7E9B71022407E; Tue, 1 Dec 2009 00:19:27 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 1 Dec 2009 00:19:27 -0800 (PST) Message-ID: <402d5ea50fcadec3d66a41f63fd1b9df.squirrel@www.trepanning.net> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.co m> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.com> Date: Tue, 1 Dec 2009 00:19:27 -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" , Dan Harkins 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 08:19:36 -0000 Yaron, It is important for you to state what problem you're trying to solve. That problem is, simply, password-only authentication. To bring up the motivation for adding EAP to IKEv2 is quite irrelevant since EAP in IKEv2 today involves server-side authentication using a certificate. You want to do password authentication in IKE. Period. Full stop. And to do that you want to add a pointless encapsulation. And you want to do it with twice as many messages. And you want to require each side to implement both the client- and server-side state machines for this "solution" to be useful in the use cases defined in IKEv2. It seems to me that you need to justify why such EXTRA work is necessary when a simpler way of solving your problem is available. Don't just say "it doesn't make sense", justify why you are proposing more, extraneous work. Furthermore, I would be very interested in why you feel that a WG in the Security Area of the IETF is not the place to define cryptographic protocols and that it would be more appropriate for a WG in the Security Area to just use a protocol from the Network Area with protocols defined as individual submissions. Dan. On Mon, November 30, 2009 10:46 pm, Yaron Sheffer wrote: > 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 > From dharkins@lounge.org Tue Dec 1 00:50: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 4DE953A6B10 for ; Tue, 1 Dec 2009 00:50:18 -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 4DljjFj-p50G for ; Tue, 1 Dec 2009 00:50:17 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 3521C3A6A16 for ; Tue, 1 Dec 2009 00:50:17 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D25A4102240AE; Tue, 1 Dec 2009 00:50:09 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 1 Dec 2009 00:50:09 -0800 (PST) Message-ID: <445d0a3a99ded36b29f606239ce9a3b6.squirrel@www.trepanning.net> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DC@il-ex01.ad.checkpoint.co m> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DC@il-ex01.ad.checkpoint.com> Date: Tue, 1 Dec 2009 00:50:09 -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" , Dan Harkins 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 08:50:18 -0000 Hi Yaron, On Mon, November 30, 2009 10:47 pm, Yaron Sheffer wrote: > Hello Dan, > > [WG co-chair hat off] > > EAP-only authentication is a small IKE extension that does not change the > existing IKE architecture; neither does it change many of the extant > implementations. Given the right EAP methods, it would provide us exactly > what EAP was supposed to provide from day one: mutual non-PKI > authentication. I don't know where you came up with the idea that EAP was supposed to provide us with mutual non-PKI authentication from day one. It was designed for PPP and the trust model for which it was designed is DRAMATICALLY DIFFERENT than the trust model used for IKE. > And the solution is generic: any suitable EAP method can be deployed, so > implementors can make their own security/interoperability/IPR/simplicity > tradeoffs, instead of having one specific authentication method mandated. Please do not overstate your proposal. The only type of EAP method that is suitable is one in which a password, and only a password, is the authentication credential, and each side possesses that credential. Any other EAP method can quite happily be handled in IKEv2 today, no need for new EAP-only authentication proposals. > 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 that EAP-only auth is limited to this use case, but it certainly > solves it well. I don't want to get in a case of dueling marketing departments but let's just say we disagree. Site-to-site IKE/IPsec is large, transport-only IKE/IPsec is less so, and the that became the UMA market put a serious dent in client-to-gateway IKEv2. But I will agree with you that client-to-gateway IKE/IPsec using IKEv1 and insecure proprietary hacks is also quite large today. And hopefully you will agree that it would be good to provide a _secure_ solution to that market. I will take issue with your statement about limited use of EAP-only auth. It really is limited. What you are proposing is for one, and only one, use case of IKEv2. And what you are proposing is more complicated than just solving it directly in IKE. You have failed to justify the increased complexity and decreased utility. > - 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 > terminated on the IKE peer. So it is incorrect to say that "both sides > MUST possess the shared secret" - exactly the right parties will need to: > the client and the authentication server. Actually EAP is a 2-party protocol that, for optimization reasons, has become viewed as a 3-party protocol. And therein lies the problem. Both sides will need to possess the shared secret for this proposal to be applicable to all use cases of IKEv2. Note that a simpler proposal that solves the exact problem you're trying to solve is applicable to all use cases of IKEv2. You have to decide whether your proposal has limited applicability or whether it requires unnecessary implementation of EAP state machines, you can't have both. I'm sure you will agree that encapsulating messages in EAP buys nothing and doubling the number of messages also buys nothing. But they both cost something. Again, we have cost with no gain with your proposal but less cost and more gain with mine. And now the security problem: an IKEv2 gateway can claim ANY identity during EAP-only authentication. That has serious implications with the security claims of IKE. If password-based authentication is provided as part of IKE this security problem goes away. > - EAP-only auth can also be applied to scenarios where no Auth Server is > deployed. However in these cases both peers would indeed need a full EAP > implementation. > > - The EAP community is (very slowly) coming to terms with EAP channel > bindings. While this is not provided by your EAP-PWD (and I hope this is > fixed before publication), EAP-EKE has been extended to add this > capability. Very slowly being the operative words. And this disclaimer also nullifies your previous statement of this being a "generic solution". It really only applies to EAP methods that are password-only and have some extra capability above-and-beyond EAP. On the other hand, we could have all this with less complexity by going with draft-harkins-ipsecme-spsk-auth. It's a choice of more complexity, less utility, and less security OR less complexity, more utility and more security. I don't understand why you want to go with the former. Dan. From dharkins@lounge.org Tue Dec 1 01:00: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 9A9FF28C1C1 for ; Tue, 1 Dec 2009 01:00:53 -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 23lfwfwbZEVp for ; Tue, 1 Dec 2009 01:00:52 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 989BF28C0E9 for ; Tue, 1 Dec 2009 01:00:52 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 5E1BA1022407E; Tue, 1 Dec 2009 01:00:45 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 1 Dec 2009 01:00:45 -0800 (PST) Message-ID: In-Reply-To: <99043b4a0911302310v7f2edf00l8d210b1d1e7d14a8@mail.gmail.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.com> <99043b4a0911302310v7f2edf00l8d210b1d1e7d14a8@mail.gmail.com> Date: Tue, 1 Dec 2009 01:00:45 -0800 (PST) From: "Dan Harkins" To: "Matthew Cini Sarreo" 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) - 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 09:00:53 -0000 Hi Matthew, Please take a look at both proposals. There is no proposal to simply offer guidelines. Both of them are "new solutions" and modify the IKE exchange. One uses NOTIFY messages to indicate the new exchange and the other uses the critical bit to indicate the new exchange. I would be interested in your opinion as a developer which is better-- NOTIFY or critical bit-- and why. As a developer, I do not believe it is better to double the number of messages needed to do a key exchange, and do not believe it is better to require pointless encapsulations of a key exchange. If you disagree I would also be interested in knowing why. Dan. On Mon, November 30, 2009 11:10 pm, Matthew Cini Sarreo wrote: > 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 >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From martin@strongswan.org Tue Dec 1 01:27: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 A76453A67FB for ; Tue, 1 Dec 2009 01:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556] 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 ILfcwYqGqyn5 for ; Tue, 1 Dec 2009 01:27:32 -0800 (PST) Received: from zaes.ch (zaes.ch [213.133.111.41]) by core3.amsl.com (Postfix) with ESMTP id CB8C03A67F4 for ; Tue, 1 Dec 2009 01:27:31 -0800 (PST) Received: from [152.96.15.212] by zaes.ch with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NFPJa-0005jo-Jh; Tue, 01 Dec 2009 10:46:34 +0100 From: Martin Willi To: Dan Harkins In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 01 Dec 2009 10:27:12 +0100 Message-ID: <1259659632.573.49.camel@martin> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit X-RPR-Rewrite: reverse-path rewritten by zaes.ch 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 09:27:32 -0000 Hi Dan, > 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. EAP authentication was not primarily included in IKEv2 to implement some kind of password authentication on top if IKEv2, but to reuse existing EAP methods and infrastructure. The most demanding user of IKEv2 currently is the mobile/telco industry; There are several specs in 3GPP and 3GPP2 using it. Many of them have chosen IKEv2 because they can use their existing EAP-AKA/SIM infrastructure for authentication. > It seems to me that EAP-only authentication in IKEv2: > 1. does not solve a general problem; It does. It allows to omit public key authentication in cases where mutual EAP authentication is sufficient. I'm aware of at least one 3GPP2 spec that already uses EAP-AKA/TLS only authentication, but does not follow this draft. I really see a need for this WG item. > 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 If you're just talking about password authentication, yes. But this allows IKEv2 to work in existing infrastructures (EAP over RADIUS/DIAMETER). We currently see a strong demand for such solutions. > To provide the benefits of EAP-only authentication [...] it would be > much better to support the inclusion of "Secure PSK authentication" as > a work item. Implementing password authentication on top of EAP may be one reason for this draft, but there are several others. And the separated EAP layer allows you to forward authentication to an existing AAA server. Further, many vendors already have generic EAP support. Implementing PSK authentication on top of it is probably simpler and more flexible than integrating it in IKEv2 directly. Best regards Martin From kivinen@iki.fi Tue Dec 1 02:04:14 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 BFE0D28C0CE for ; Tue, 1 Dec 2009 02:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 MwMQ8dTDJMJj for ; Tue, 1 Dec 2009 02:04:13 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 97D8C3A6B24 for ; Tue, 1 Dec 2009 02:04:12 -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 nB1A40Y2020095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Dec 2009 12:04:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nB1A3xBG018299; Tue, 1 Dec 2009 12:03: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: <19220.59918.999535.4773@fireball.kivinen.iki.fi> Date: Tue, 1 Dec 2009 12:03:58 +0200 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <24a859db202868361dcaff4fe54ee1f1.squirrel@www.trepanning.net> References: <19219.48610.784911.946017@fireball.kivinen.iki.fi> <24a859db202868361dcaff4fe54ee1f1.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min 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: Tue, 01 Dec 2009 10:04:14 -0000 Dan Harkins writes: > Groups 1 and 2 were defined in RFC 2409 and repeating them in a > subsequent RFC does not change that. RFC2409 has been obsoleted, so I do not want to refer to that, as people will then go to the RFC2409 and notice that it has been obsoleted by RFC4306, and will go to there and find the groups from RFC4306 appendix B.1 and B.2. The groups are same, so it does not really matter which document is referenced. > 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". I am NOT going to touch ipsec-registry. That is IKEv1 stuff that is already obsoleted, and there is no point of doing anything for that (and no need, as it does nto have range allocations). I am talking about IKEv2 registry (http://www.iana.org/assignments/ikev2-parameters) and there the references were already for RFC4306, not to RFC2409 (and it does not have groups 3 and 4 at all, those are not defined for IKEv2). -- kivinen@iki.fi From dharkins@lounge.org Tue Dec 1 02:16: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 CD4913A6927 for ; Tue, 1 Dec 2009 02:16:19 -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 IZauG4VPLgWN for ; Tue, 1 Dec 2009 02:16:18 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id C3B1F3A68CC for ; Tue, 1 Dec 2009 02:16:18 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9B4B51022407E; Tue, 1 Dec 2009 02:16:10 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 1 Dec 2009 02:16:11 -0800 (PST) Message-ID: <6f7de6090df965fc0884fd4c48096739.squirrel@www.trepanning.net> In-Reply-To: <1259659632.573.49.camel@martin> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> <1259659632.573.49.camel@martin> Date: Tue, 1 Dec 2009 02:16:11 -0800 (PST) From: "Dan Harkins" To: "Martin Willi" 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" , Dan Harkins 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 10:16:19 -0000 Hi Martin, On Tue, December 1, 2009 1:27 am, Martin Willi wrote: > Hi Dan, > >> 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. > > EAP authentication was not primarily included in IKEv2 to implement some > kind of password authentication on top if IKEv2, but to reuse existing > EAP methods and infrastructure. I understand. I'm not talking about EAP authentication in IKEv2 today. Please, don't misunderstand me. I'm not proposing to do away with EAP authentication in IKEv2, I'm proposing a more efficient, more secure, and simpler way of doing password-only authentication in IKEv2. > The most demanding user of IKEv2 currently is the mobile/telco industry; > There are several specs in 3GPP and 3GPP2 using it. Many of them have > chosen IKEv2 because they can use their existing EAP-AKA/SIM > infrastructure for authentication. > >> It seems to me that EAP-only authentication in IKEv2: >> 1. does not solve a general problem; > > It does. It allows to omit public key authentication in cases where > mutual EAP authentication is sufficient. I'm aware of at least one 3GPP2 > spec that already uses EAP-AKA/TLS only authentication, but does not > follow this draft. I really see a need for this WG item. I guess I was just saying that certificate-less, password-based authentication is not general. It's specific to the problem of authenticating with only a password and no certificate. If 3GPP2 has a need for authentication with only a password and no certificate please take a look at EAP-pwd! That will, apparently, solve your problem. If it doesn't then the singular use of EAP-only IKEv2 authentication will not either. Furthermore, doing pointless encapsulations and doubling of messages does not really seem to solve _any_ problem. Keep in mind that IKE/IPsec is, fundamentally, a peer-to-peer protocol. While your client-server application is a very valid use case, it is not the only one and it is important to solve problems generally, with utility to all use cases, if possible. >> 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 > > If you're just talking about password authentication, yes. But this > allows IKEv2 to work in existing infrastructures (EAP over > RADIUS/DIAMETER). We currently see a strong demand for such solutions. IKEv2 already works in such infrastructure. Yes, I'm talking about password authentication. That's the only use for EAP-only authentication in IKEv2. Any other EAP authentication can already be handled in IKEv2 today. I'm glad you have a strong desire for using existing EAP authentication of IKEv2. But please understand that that is not what the topic under discussion is. >> To provide the benefits of EAP-only authentication [...] it would be >> much better to support the inclusion of "Secure PSK authentication" as >> a work item. > > Implementing password authentication on top of EAP may be one reason for > this draft, but there are several others. And the separated EAP layer > allows you to forward authentication to an existing AAA server. > Further, many vendors already have generic EAP support. Implementing PSK > authentication on top of it is probably simpler and more flexible than > integrating it in IKEv2 directly. Please tell me what other reasons there are for this draft. This draft solves one problem only-- using only a password to authenticate, with both sides requiring plaintext access to the password-- and that problem can be solved more simply and more securely than EAP-only, and in a way that is applicable to all use cases of IKE. Note that the EAP methods being used to justify EAP-only authentication in IKEv2 (the ones mentioned by the Yaron) DO NOT allow for forwarding of authentication to a AAA server. Other EAP methods might but, as I stated earlier, those are already handled today in IKEv2. The benefit you want to apply to this proposal is not valid and what you seem to be requiring is already provided for. Dan. From yaronf@checkpoint.com Tue Dec 1 03:38: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 33A493A681C for ; Tue, 1 Dec 2009 03:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 8U+Y3GCBH6ur for ; Tue, 1 Dec 2009 03:38:39 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id A931A3A6826 for ; Tue, 1 Dec 2009 03:38:38 -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 nB1BcRGo004752; Tue, 1 Dec 2009 13:38:27 +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 13:38:33 +0200 From: Yaron Sheffer To: Dan Harkins , Matthew Cini Sarreo Date: Tue, 1 Dec 2009 13:38:25 +0200 Thread-Topic: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO Thread-Index: AcpyZMuVvub+6q0YRKK33fjeCzG4OQAFTQBw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0772@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.com> <99043b4a0911302310v7f2edf00l8d210b1d1e7d14a8@mail.gmail.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 11:38:40 -0000 Hi Dan, I'm sorry, but you are misstating the difference between the proposals. One= is adding a notification and eliminating one existing (certificate) check;= the other is adding an IKE mode, and changing the protocol state machine i= n the process. Regardless of all the other pros and cons, the proposals are clearly not co= mparable as far as changing the protocol. Thanks, Yaron > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Tuesday, December 01, 2009 11:01 > To: Matthew Cini Sarreo > Cc: Yaron Sheffer; ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication > (SPSK) - NO >=20 >=20 > Hi Matthew, >=20 > Please take a look at both proposals. There is no proposal to simply > offer guidelines. Both of them are "new solutions" and modify the IKE > exchange. One uses NOTIFY messages to indicate the new exchange and the > other uses the critical bit to indicate the new exchange. I would be > interested in your opinion as a developer which is better-- NOTIFY or > critical bit-- and why. >=20 > As a developer, I do not believe it is better to double the number > of messages needed to do a key exchange, and do not believe it is better > to require pointless encapsulations of a key exchange. If you disagree I > would also be interested in knowing why. >=20 > Dan. >=20 > On Mon, November 30, 2009 11:10 pm, Matthew Cini Sarreo wrote: > > 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 spen= d > >> 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 fo= r > >> 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 > >> > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > >=20 >=20 >=20 > Scanned by Check Point Total Security Gateway. From kivinen@iki.fi Tue Dec 1 03:53: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 BF5133A688A for ; Tue, 1 Dec 2009 03:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 nHWLPMma3GRO for ; Tue, 1 Dec 2009 03:53:08 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9E66D3A684E for ; Tue, 1 Dec 2009 03:53:07 -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 nB1BqqDD019486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Dec 2009 13:52:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nB1Bqqve020638; Tue, 1 Dec 2009 13:52: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: <19221.915.979017.29111@fireball.kivinen.iki.fi> Date: Tue, 1 Dec 2009 13:52:51 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: "ipsec@ietf.org" , Dan Harkins 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 11:53:08 -0000 Yaron Sheffer writes: > 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. EAP can really only be used in the client / server situation. Using EAP to protect site to site, or host to host traffic is very hard, because of the assymetric properties of the EAP. Because if this I do think there is use for having secure password protocol in the IKEv2 without using EAP. As an additional note, I also think there is use for EAP methods you list below, as those can be used when there is clear client / server distinction just like in the remote access case. Btw, this same applies to the EAP only authentication, i.e. it has uses when there is clear client / server distinction, i.e. it is not competing with this one, but it provides similar properties for those cases where we really have client and server, and where we do have existing infrastructure (for example using EAP-SIM or EAP-AKA in the GSM or 3GPP environments). -- kivinen@iki.fi From alper.yegin@yegin.org Tue Dec 1 04:29: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 B01273A68C2 for ; Tue, 1 Dec 2009 04:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.792 X-Spam-Level: X-Spam-Status: No, score=-0.792 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 3SQcStDhImlz for ; Tue, 1 Dec 2009 04:29:42 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id E6F553A6891 for ; Tue, 1 Dec 2009 04:29:41 -0800 (PST) Received: from LENOVO (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LuwOn-1OF0mu1nH7-0107sJ; Tue, 01 Dec 2009 07:29:24 -0500 From: "Alper Yegin" To: "'Yaron Sheffer'" , References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> Date: Tue, 1 Dec 2009 14:29:19 +0200 Message-ID: <043201ca7281$ea426d50$bec747f0$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpxFGNxZr/+l4aORQq0dtIEtoKGIwBbRWqQ Content-Language: en-us X-Provags-ID: V01U2FsdGVkX18/sR4LEj4Ier/fYj5+1/2ELoKN31pejj1a7by +QvmmybnClGT/vnFDULQjyJ3AVFFRpejt5YulBqZE4eDuUvosV 7rz+iXxcxm9Afv2kjUIJA== Subject: Re: [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: Tue, 01 Dec 2009 12:29:42 -0000 One of the (or main?) motivations of this proposal is to turn IKEv2 into "EAP-based network access authentication protocol". RFC 5191 is designed for that purpose, and I'm not sure if we need to twist a protocol for the same purpose. > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Yaron Sheffer > Sent: Sunday, November 29, 2009 7:21 PM > To: ipsec@ietf.org > Subject: [IPsec] Proposed work item: Childless IKE SA > > 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- > childless-01.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 kivinen@iki.fi Tue Dec 1 04:29: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 795793A69FD for ; Tue, 1 Dec 2009 04:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 z4CpBIMW6UBF for ; Tue, 1 Dec 2009 04:29:58 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 946383A68C2 for ; Tue, 1 Dec 2009 04:29:55 -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 nB1CTeFS021740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Dec 2009 14:29:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nB1CTe2h024532; Tue, 1 Dec 2009 14:29: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: <19221.3124.9627.247011@fireball.kivinen.iki.fi> Date: Tue, 1 Dec 2009 14:29:40 +0200 From: Tero Kivinen To: Matthew Cini Sarreo In-Reply-To: <99043b4a0911302310v7f2edf00l8d210b1d1e7d14a8@mail.gmail.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.com> <99043b4a0911302310v7f2edf00l8d210b1d1e7d14a8@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 35 min 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 12:29:59 -0000 Matthew Cini Sarreo writes: > 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. I think it would be much more complicated to try to turn EAP from client / server protocol to symmetric protocol, than to add new exchange to IKEv2. Note, that I do not comment anything about how the current SPKS draft is done, as I have not really read it, but I think we should add secure password protocol to the IKEv2 and not use EAP for that when using symmetric site to site, or host to host scenarios. If we had that clean secure password protocol, then we could leave out EAP in some environments, which would make protocol implementation much easier. Looking at the state machine of IKE_AUTH in our own implementation, EAP causes most of the complexity (mostly because EAP is open ended). On the other hand if we add multiple authentication support to the state machine pictures, then that is even more complex than EAP... Good thing with SPSK is that it is alternative for all other authentication modes, i.e. adds one to the shared key-shared key, shared key-public key, public key-shared key, and EAP-public key list. I.e. it does not multiply the test cases but just adds one to the list of current authentication modes, raising it from 4 to 5. EAP only authentication mode raises it by one more. Multiple authentication support raises it to power of n (depending how many different authentication rounds you support)... -- kivinen@iki.fi From ynir@checkpoint.com Tue Dec 1 04: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 015E828C0F4 for ; Tue, 1 Dec 2009 04:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.054 X-Spam-Level: X-Spam-Status: No, score=-3.054 tagged_above=-999 required=5 tests=[AWL=0.545, 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 m88oo2Ww0uIH for ; Tue, 1 Dec 2009 04:42:58 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id C949128C0EE for ; Tue, 1 Dec 2009 04:42:57 -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 nB1CgmGo005961; Tue, 1 Dec 2009 14:42:48 +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 14:42:55 +0200 From: Yoav Nir To: Alper Yegin Date: Tue, 1 Dec 2009 14:42:44 +0200 Thread-Topic: [IPsec] Proposed work item: Childless IKE SA Thread-Index: Acpyg80HypT+MFdeS7Spcc+xOGILRg== Message-ID: <6F892B93-1B06-44DE-852F-A7C2F2799717@checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <043201ca7281$ea426d50$bec747f0$@yegin@yegin.org> In-Reply-To: <043201ca7281$ea426d50$bec747f0$@yegin@yegin.org> 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: 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: Tue, 01 Dec 2009 12:42:59 -0000 There were several motivations listed for childless IKE SAs. - remote access, where you create an IKE SA when the user wants to connect= , and only create child SAs in response to traffic - authentication only over a physically secure network (not necessarily EA= P, but I think this is the use case you referred to) - Location awareness (as in the SecureBeacon draft) - Some "weird" uses such as liveness checks without IPsec, NAT detection, = etc. On Dec 1, 2009, at 2:29 PM, Alper Yegin wrote: > One of the (or main?) motivations of this proposal is to turn IKEv2 into > "EAP-based network access authentication protocol". RFC 5191 is designed > for that purpose, and I'm not sure if we need to twist a protocol for the > same purpose. >=20 >=20 >=20 >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Yaron Sheffer >> Sent: Sunday, November 29, 2009 7:21 PM >> To: ipsec@ietf.org >> Subject: [IPsec] Proposed work item: Childless IKE SA >>=20 >> 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. >>=20 >> Proposed starting point: http://tools.ietf.org/id/draft-nir-ipsecme- >> childless-01.txt. >>=20 >> Please reply to the list: >>=20 >> - 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? >>=20 >> Please also reply to the list if: >>=20 >> - You believe this is NOT a reasonable activity for the WG to spend >> time on. >>=20 >> 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 > _______________________________________________ > 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 Tue Dec 1 05:09: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 DA87D28C525 for ; Tue, 1 Dec 2009 05:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 WFoKTzewv-lv for ; Tue, 1 Dec 2009 05:09:34 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 7DDCF28CEF0 for ; Tue, 1 Dec 2009 05:03:50 -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 nB1D3YDS024528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Dec 2009 15:03:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nB1D3YN2018820; Tue, 1 Dec 2009 15:03:34 +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: <19221.5158.22224.351908@fireball.kivinen.iki.fi> Date: Tue, 1 Dec 2009 15:03:34 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0772@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.com> <99043b4a0911302310v7f2edf00l8d210b1d1e7d14a8@mail.gmail.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0772@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 18 min Cc: "ipsec@ietf.org" , Matthew Cini Sarreo , Dan Harkins 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 13:09:36 -0000 Yaron Sheffer writes: > I'm sorry, but you are misstating the difference between the > proposals. One is adding a notification and eliminating one existing > (certificate) check; the other is adding an IKE mode, and changing > the protocol state machine in the process. Not true. Both are adding new IKEv2 authentication mode. In EAP only authentication the EAP_ONLY_AUTHENTICATION notify also makes it so that server DOES NOT need to have certificate and public key, meaning it does not send it s first AUTH payload in message 4. The main benefit from this is that the server DOES NOT need to have private key. (at least in draft-eronen-ipsec-ikev2-eap-auth-07.txt) We currently already have 4 authentication modes. Client Server 1) Shared key Shared key 2) Public key Shared key 3) Shared key Public key 4) EAP Public key EAP only will add one more: 5) mutual-EAP mutual-EAP and SPSK will add one more: 6) Password Password > Regardless of all the other pros and cons, the proposals are clearly > not comparable as far as changing the protocol. The changes required for EAP only might be smaller, but testing effort for both of them is same, except EAP only really requires you to test with all supported mutual key generating EAP methods (and also test with others and make sure they are not accepted). One thing I think most of you are missing is that their usage scenarios are COMPLETELY different. EAP-only can be used when there is clear client-server setup, existing EAP infrastructure (for example EAP-SIM or EAP-AKA), and where there is no certificates or shared keys in use at all. This setup is asymmetric, one party (the user) always initiates the connection. SPSK cannot be used in such setup, as there is no password it can find. SPSK can be used when there is requirement for host to host (or site to site) connection, where either end can initiate traffic and exchanges and where entities still want to use passwords instead of public keys to authenticate. Shared keys could be used there, but in most setups the shared keys used in those scenarios are not strong enough to be resistant against dictionary attacks. EAP-only cannot be used there as this is not client-server setup. In these setup the authentication needs to be symmetric. For this reason I do not think we need to decide to take on or the other, we can take both as I do see use for both of them. If I would need to select one, I would select SPSK, as that is something which cannot be done by IKEv2 now. EAP-only is an optimization (both in protocol level, and especially in adminstrative level) for the existing EAP-Public key authentication. -- kivinen@iki.fi From yaronf@checkpoint.com Tue Dec 1 05:19: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 A29D728C252 for ; Tue, 1 Dec 2009 05:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 4HrOp2HRqrp7 for ; Tue, 1 Dec 2009 05:19:01 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 00F2C28C6C1 for ; Tue, 1 Dec 2009 05:17:56 -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 nB1DHkGo023902; Tue, 1 Dec 2009 15:17:47 +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 15:17:53 +0200 From: Yaron Sheffer To: Tero Kivinen Date: Tue, 1 Dec 2009 15:17:46 +0200 Thread-Topic: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO Thread-Index: AcpyhraLy/4VdhPqRciMduHmRdF3xQAASCqw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E07A1@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.com> <99043b4a0911302310v7f2edf00l8d210b1d1e7d14a8@mail.gmail.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0772@il-ex01.ad.checkpoint.com> <19221.5158.22224.351908@fireball.kivinen.iki.fi> In-Reply-To: <19221.5158.22224.351908@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: "ipsec@ietf.org" , Matthew Cini Sarreo , Dan Harkins 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 13:19:02 -0000 Hi Tero, I think you are too quick to dismiss the option of using EAP-only for site-= to-site and transport deployments, where the EAP state machine is embedded = into the IKE endpoint. For people who already have client-side EAP, this is= not adding a lot. It's not as efficient as tailor-made password authentica= tion in IKE, but OTOH it is much more generic. Thanks, Yaron > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Tuesday, December 01, 2009 15:04 > To: Yaron Sheffer > Cc: Dan Harkins; Matthew Cini Sarreo; ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication > (SPSK) - NO >=20 > Yaron Sheffer writes: > > I'm sorry, but you are misstating the difference between the > > proposals. One is adding a notification and eliminating one existing > > (certificate) check; the other is adding an IKE mode, and changing > > the protocol state machine in the process. >=20 > Not true. >=20 > Both are adding new IKEv2 authentication mode. >=20 > In EAP only authentication the EAP_ONLY_AUTHENTICATION notify also > makes it so that server DOES NOT need to have certificate and public > key, meaning it does not send it s first AUTH payload in message 4. >=20 > The main benefit from this is that the server DOES NOT need to have > private key. >=20 > (at least in draft-eronen-ipsec-ikev2-eap-auth-07.txt) >=20 > We currently already have 4 authentication modes. >=20 > Client Server > 1) Shared key Shared key > 2) Public key Shared key > 3) Shared key Public key > 4) EAP Public key >=20 > EAP only will add one more: >=20 > 5) mutual-EAP mutual-EAP >=20 > and SPSK will add one more: >=20 > 6) Password Password >=20 > > Regardless of all the other pros and cons, the proposals are clearly > > not comparable as far as changing the protocol. >=20 > The changes required for EAP only might be smaller, but testing effort > for both of them is same, except EAP only really requires you to test > with all supported mutual key generating EAP methods (and also test > with others and make sure they are not accepted). >=20 > One thing I think most of you are missing is that their usage > scenarios are COMPLETELY different. >=20 > EAP-only can be used when there is clear client-server setup, existing > EAP infrastructure (for example EAP-SIM or EAP-AKA), and where there > is no certificates or shared keys in use at all. This setup is > asymmetric, one party (the user) always initiates the connection. SPSK > cannot be used in such setup, as there is no password it can find. >=20 > SPSK can be used when there is requirement for host to host (or site > to site) connection, where either end can initiate traffic and > exchanges and where entities still want to use passwords instead of > public keys to authenticate. Shared keys could be used there, but in > most setups the shared keys used in those scenarios are not strong > enough to be resistant against dictionary attacks. EAP-only cannot be > used there as this is not client-server setup. In these setup the > authentication needs to be symmetric. >=20 > For this reason I do not think we need to decide to take on or the > other, we can take both as I do see use for both of them. >=20 > If I would need to select one, I would select SPSK, as that is > something which cannot be done by IKEv2 now. >=20 > EAP-only is an optimization (both in protocol level, and especially in > adminstrative level) for the existing EAP-Public key authentication. > -- > kivinen@iki.fi >=20 > Scanned by Check Point Total Security Gateway. From kivinen@iki.fi Tue Dec 1 05:33: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 D85D428C2AA for ; Tue, 1 Dec 2009 05:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 I6DFsvsWzXfE for ; Tue, 1 Dec 2009 05:33:27 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 0CBCA28C3D3 for ; Tue, 1 Dec 2009 05:24: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 nB1DOISl020528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Dec 2009 15:24:18 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nB1DOIh3010434; Tue, 1 Dec 2009 15:24: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: <19221.6402.228166.814800@fireball.kivinen.iki.fi> Date: Tue, 1 Dec 2009 15:24:18 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 15 min Subject: [IPsec] New issue: INTERNAL_ADDRESS_FAILURE error and how to continue. 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 13:33:29 -0000 The section 1.2 says that if we get INTERNAL_ADDRESS_FAILURE then the IKE SA stays up, but the child SA is not created. It does not say anything what should happen on the initiator if it actually did require address by policy. I think we have two options: 1) Tear down the IKE SA (by sending DELETE payload inside INFORMATIONAL exchange) and try again after suitable timeout. 2) Keep the existing IKE SA up, but retry the configuration payload exchange again after suitable timeout by starting new INFORMATIONAL exchange and putting same configuration payloads in it. I think we might want mention something about this in the section 1.2, or section 3.15.4 Address Assignment Failures. Most likely the section 3.15.4 is better, but we might want to add forward reference from section 1.2 to there. Section 3.15.4 do explain how the responder can behave in different situations, but it does not cover what initiator should do. Perhaps adding following paragraph to the end of 3.15.4 would help: ---------------------------------------------------------------------- If the initiator does not receive the IP address(es) required by its policy, it MAY keep the IKE SA up and retry the configuration payload (as separate INFORMATIONAL exchange) after suitable timeout, or it MAY also tear down the IKE SA (by sending DELETE payload inside separate INFORMATIONAL exchange) and retry IKE SA from the beginning after some longer timeout. The timeout should not be too short (especially if the IKE SA is started from the beginning), as these error situations will only be fixed when more entries are returned to the address pool of the responder, thus it will not be fixed in seconds, but more likely it takes several minutes. -- kivinen@iki.fi From denghui02@gmail.com Tue Dec 1 05:35: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 0583528C244 for ; Tue, 1 Dec 2009 05:35:04 -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 DsnQ+i9hN7oB for ; Tue, 1 Dec 2009 05:35:03 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 0D38F28C2BF for ; Tue, 1 Dec 2009 05:27:58 -0800 (PST) Received: by pzk6 with SMTP id 6so3472637pzk.29 for ; Tue, 01 Dec 2009 05:27:48 -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=PtwMOF0AbtQrGzhxJ7vbMJZvdBC7q8YZAy/yl0EYBe0=; b=IID2SiUhRpC9Z1XpdvlOwieMyJSWxJOvzP3Q4ZOvT8uYX8cuhynGR3qg2ejKMkfvoo IBtAMLsFTsM5LcIhttiwbrrhICIQhjfnUylj5In4pRD6L2Vne77U1CFb+vL/Wtclp52m pKDTHoBqoksSScw7WMi9cSWA1sGtn5EUqvbeM= 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=agJwJdIEVhnu24e8HRw9REY4dIC+ShzzxPRvh3rj286QB0ndwz01dOOOOjgnaVveSW WAu2K/egTxPAJ4SQXXpWHulW7yBSZgPB3KQZO7WhRx4RDcrQkhLtmjANECI2lvUF0SKX UpI2hBRQrs8uZF94vTB3ok0cOH8lH1GcWR37w= MIME-Version: 1.0 Received: by 10.140.187.11 with SMTP id k11mr360526rvf.197.1259674068029; Tue, 01 Dec 2009 05:27:48 -0800 (PST) In-Reply-To: <6F892B93-1B06-44DE-852F-A7C2F2799717@checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <6F892B93-1B06-44DE-852F-A7C2F2799717@checkpoint.com> Date: Tue, 1 Dec 2009 21:27:48 +0800 Message-ID: <1d38a3350912010527w30a6779cycd0cfad5d628e596@mail.gmail.com> From: Hui Deng To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" , Alper Yegin Subject: Re: [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: Tue, 01 Dec 2009 13:35:04 -0000 During the last 3GPP SA3 meeting, such requirement about HNB has also been approved as well. thanks -Hui 2009/12/1 Yoav Nir : > There were several motivations listed for childless IKE SAs. > =A0- remote access, where you create an IKE SA when the user wants to con= nect, and only create child SAs in response to traffic > =A0- authentication only over a physically secure network (not necessaril= y EAP, but I think this is the use case you referred to) > =A0- Location awareness (as in the SecureBeacon draft) > =A0- Some "weird" uses such as liveness checks without IPsec, NAT detecti= on, etc. > > > On Dec 1, 2009, at 2:29 PM, Alper Yegin wrote: > >> One of the (or main?) motivations of this proposal is to turn IKEv2 into >> "EAP-based network access authentication protocol". =A0RFC 5191 is desig= ned >> for that purpose, and I'm not sure if we need to twist a protocol for th= e >> same purpose. >> >> >> >>> -----Original Message----- >>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >>> Of Yaron Sheffer >>> Sent: Sunday, November 29, 2009 7:21 PM >>> To: ipsec@ietf.org >>> Subject: [IPsec] Proposed work item: Childless IKE SA >>> >>> 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- >>> childless-01.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 >> >> _______________________________________________ >> 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 > From kivinen@iki.fi Tue Dec 1 05:35: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 B980828C2C3 for ; Tue, 1 Dec 2009 05:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 dP018j90cZoj for ; Tue, 1 Dec 2009 05:35:47 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 3418A28C3FC for ; Tue, 1 Dec 2009 05:29:25 -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 nB1DTAPe018155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Dec 2009 15:29:10 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nB1DTARk025044; Tue, 1 Dec 2009 15:29:10 +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: <19221.6694.57191.182648@fireball.kivinen.iki.fi> Date: Tue, 1 Dec 2009 15:29:10 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min Subject: [IPsec] New issue: inconsistency in the section 2.9 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 13:35:47 -0000 The section 2.9 has text which says: ---------------------------------------------------------------------- 2.9. Traffic Selector Negotiation ... Since the two endpoints may be configured by different people, the incompatibility may persist for an extended period even in the absence of errors. It also allows for intentionally different configurations, as when one end is configured to tunnel all addresses and depends on the other end to have the up-to-date list. ... ... This case will occur only when the initiator and responder are configured differently from one another. If the initiator and responder agree on the granularity of tunnels, the initiator will never request a tunnel wider than the responder will accept. Such misconfigurations should be recorded in error logs. ---------------------------------------------------------------------- So the first part says that traffic selectors may be different on initiator's and responder's policy and that such a configuration may be intentional. Then the second part calls such configuration misconfigurations and require such events to be logged. This is bit inconsistent, and I think the second part should be modified so that the last sentence is removed, or rephrased. -- kivinen@iki.fi From kivinen@iki.fi Tue Dec 1 05:55: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 AA7713A6808 for ; Tue, 1 Dec 2009 05:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 MEifh+o4Wu16 for ; Tue, 1 Dec 2009 05:55:06 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 106983A6783 for ; Tue, 1 Dec 2009 05:55:05 -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 nB1DspYL023226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Dec 2009 15:54:51 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nB1DsoGw023366; Tue, 1 Dec 2009 15:54:50 +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: <19221.8234.750024.497905@fireball.kivinen.iki.fi> Date: Tue, 1 Dec 2009 15:54:50 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <349076FF-487D-4B6C-91EB-1E845B2303F6@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 23 min X-Total-Time: 24 min Cc: IPsecme WG , Yoav Nir 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, 01 Dec 2009 13:55:07 -0000 Paul Hoffman writes: > 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. There is one problem with the current text for this traffic selector negotiation. If the initiator has policy that says (I only use one end of traffic selectors as that is enough for this example): 192.0.2.0 - 192.0.2.255 PROTECT and responder has policy that says: 192.0.2.128 - 192.0.2.255 PROTECT Now when initiator gets packet form the network that has address of 192.0.2.5, it will match its policy and it will start creating new IKE SA and Child SA. It sends traffic selectors having content of: TS(TCP:80-80, 192.0.2.5 - 192.0.2.5) TS(0:0-65535, 192.0.2.0 - 192.0.2.255) The responder will see those and starts following the rules in the section 2.9. ---------------------------------------------------------------------- The responder performs the narrowing as follows: o If the responder's policy does not allow it to accept any part of the proposed traffic selectors, it responds with TS_UNACCEPTABLE. o If the responder's policy allows the entire set of traffic covered by TSi and TSr, no narrowing is necessary, and the responder can return the same TSi and TSr values. o 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. In this example above, the responder might respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and IP protocols. o If the responder's policy does not allow it to accept the first selector of TSi and TSr, the responder narrows to an acceptable subset of TSi and TSr. ---------------------------------------------------------------------- 1) The responder's policy do allow some part of the traffic selectors, so it does not send TS_UNACCEPTABLE. 2) Responder's policy does not allow entire set of traffic, so it cannot return full set. 3) Responder's policy does not allow first traffic selector, so it cannot narrow it down to that. 4) So it gets to this last rule and narrows traffic selectors down to acceptable subset of initiators set, i.e resulting traffic selector will be: TS(0:0-65535, 192.0.2.128 - 192.0.2.255) Now when initiator gets this it installs the Child SA as normally. The created SA is useless for triggering packet, so it cannot send the packet over that SA, and most likely it will throw that packet away. When the next packet coming having same address comes in, it most likely triggers new child SA exchange with same results. After a few hundred packets the initiator and responder have 100 overlapping Child SAs which all are completely useless for any traffic. Responder cannot do anything, as it is completely valid to create multiple overlapping Child SAs, as this is required for the QoS. Initiator might try to do something smart and for example disable the trigger rule for next n minutes when it started creating Child SA, so it will not trigger again, but at some point it do want to enable the trigger again, just in case the other end has fixed its configuration. All of this is caused because of the final rule saying: o If the responder's policy does not allow it to accept the first selector of TSi and TSr, the responder narrows to an acceptable subset of TSi and TSr. If that would not be there, then the responder would return TS_UNACCEPTABLE to the initiators Child SA create exchange, which would prevent creating extra Child SAs. This final rule is NOT in the RFC4306 in triggering packet case, it was only there in case there was no triggering packet (of course there is no text explaining how do you know if the first traffic selector is triggering packet or not). I suggest that we add text explaining what it means when there is triggering packet and modify the last rule to be: o If the initiator's first TSi and TSr are not from triggering packet (i.e. they are ranges), then if the responder's policy does not allow it to accept the first selector of TSi and TSr, the responder narrows to an acceptable subset of TSi and TSr. And the text to explain what triggering packet is should be added before paragraph above: To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first traffic selector in each of TSi and TSr a very specific traffic selector including the addresses in the packet triggering the request. This kind of triggering packet can be detected because it exactly match one IP address, protocol and port. In the example, the initiator would include in TSi two traffic selectors: the first containing the address range (192.0.1.43 - 192.0.1.43) and the source port and IP protocol from the packet and the second containing (192.0.1.0 - 192.0.1.255) with all ports and IP protocols. The initiator would similarly include two traffic selectors in TSr. If the initiator creates the Child SA pair not in response to an arriving packet, but rather, say, upon startup, then there may be no specific addresses the initiator prefers for the initial tunnel over any other. In that case, the first values in TSi and TSr will be ranges rather than specific values. (Added text "This kind of triggering packet can be detected because it exactly match one IP address, protocol and port." in the middle, and changed the final "can be ranges" to "will be ranges". -- kivinen@iki.fi From danmcd@sun.com Tue Dec 1 06:40: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 E93423A6A0C for ; Tue, 1 Dec 2009 06:40:17 -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 iq5auMUMyNZg for ; Tue, 1 Dec 2009 06:40:17 -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 282E43A69E7 for ; Tue, 1 Dec 2009 06:40:17 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB1Ee9pm013193 for ; Tue, 1 Dec 2009 14:40:09 GMT Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.4) with ESMTP id nB1Ee9sQ010006 for ; Tue, 1 Dec 2009 09:40:09 -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 nB1Ee81T010258 for ; Tue, 1 Dec 2009 09:40:08 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB1Ee8CQ010257 for ipsec@ietf.org; Tue, 1 Dec 2009 09:40:08 -0500 (EST) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Tue, 1 Dec 2009 09:40:08 -0500 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20091201144008.GI10121@kebe.East.Sun.COM> References: <19221.6402.228166.814800@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19221.6402.228166.814800@fireball.kivinen.iki.fi> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [IPsec] New issue: INTERNAL_ADDRESS_FAILURE error and how to continue. 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 14:40:18 -0000 On Tue, Dec 01, 2009 at 03:24:18PM +0200, Tero Kivinen wrote: > The section 1.2 says that if we get INTERNAL_ADDRESS_FAILURE then the > IKE SA stays up, but the child SA is not created. It does not say > anything what should happen on the initiator if it actually did > require address by policy. Interactions like these show the hazards in integrating address configuration into a key exchange protocol. But since we've already thrown in with this since the days of MODE-CFG in IKEv1... > Perhaps adding following paragraph to the end of 3.15.4 would help: > ---------------------------------------------------------------------- > If the initiator does not receive the IP address(es) required by its > policy, it MAY keep the IKE SA up and retry the configuration > payload (as separate INFORMATIONAL exchange) after suitable timeout, > or it MAY also tear down the IKE SA (by sending DELETE payload > inside separate INFORMATIONAL exchange) and retry IKE SA from the > beginning after some longer timeout. The timeout should not be too > short (especially if the IKE SA is started from the beginning), as > these error situations will only be fixed when more entries are > returned to the address pool of the responder, thus it will not be > fixed in seconds, but more likely it takes several minutes. This is definitely the right idea. And the responder should already be able to react to either initiator choice (try with existing IKE SA, or deal with new IKE SA). Dan From paul.hoffman@vpnc.org Tue Dec 1 11:04: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 39B4E3A6965 for ; Tue, 1 Dec 2009 11:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.029, 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 EI9Jbq0GvSyC for ; Tue, 1 Dec 2009 11:04:10 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2283A3A6964 for ; Tue, 1 Dec 2009 11:04: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 nB1J41s9080246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Dec 2009 12:04:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19220.59918.999535.4773@fireball.kivinen.iki.fi> References: <19219.48610.784911.946017@fireball.kivinen.iki.fi> <24a859db202868361dcaff4fe54ee1f1.squirrel@www.trepanning.net> <19220.59918.999535.4773@fireball.kivinen.iki.fi> Date: Tue, 1 Dec 2009 10:55:41 -0800 To: Tero Kivinen , "Dan Harkins" 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: Tue, 01 Dec 2009 19:04:11 -0000 At 12:03 PM +0200 12/1/09, Tero Kivinen wrote: >Dan Harkins writes: >> Groups 1 and 2 were defined in RFC 2409 and repeating them in a >> subsequent RFC does not change that. > >RFC2409 has been obsoleted, so I do not want to refer to that, as >people will then go to the RFC2409 and notice that it has been >obsoleted by RFC4306, and will go to there and find the groups from >RFC4306 appendix B.1 and B.2. Fully agree. It does not matter where something was defined first. >I am NOT going to touch ipsec-registry. That is IKEv1 stuff that is >already obsoleted, and there is no point of doing anything for that >(and no need, as it does nto have range allocations). > >I am talking about IKEv2 registry >(http://www.iana.org/assignments/ikev2-parameters) and there the >references were already for RFC4306, not to RFC2409 (and it does not >have groups 3 and 4 at all, those are not defined for IKEv2). There may be a good reason for someone to touch the IKEv1 registry, but that should be done as a separate work item. --Paul Hoffman, Director --VPN Consortium From dharkins@lounge.org Tue Dec 1 12:04: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 7A44028C100 for ; Tue, 1 Dec 2009 12:04:22 -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 BX0VYIIljXKm for ; Tue, 1 Dec 2009 12:04:21 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 479D53A6976 for ; Tue, 1 Dec 2009 12:04:21 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 06A901022407E; Tue, 1 Dec 2009 12:04:14 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 1 Dec 2009 12:04:14 -0800 (PST) Message-ID: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E07A1@il-ex01.ad.checkpoint.co m> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.com> <99043b4a0911302310v7f2edf00l8d210b1d1e7d14a8@mail.gmail.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0772@il-ex01.ad.checkpoint.com> <19221.5158.22224.351908@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E07A1@il-ex01.ad.checkpoint.com> Date: Tue, 1 Dec 2009 12:04:14 -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" , Matthew Cini Sarreo , Tero Kivinen 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 20:04:22 -0000 Hi Yaron, EAP is a client/server protocol. If either side can initiate the exchange (necessary for site-to-site and transport) then each side will be required to implement BOTH the EAP client and EAP server state machines. "[P]eople who already have client-side EAP" will need to add server-side EAP to their IPsec client implementation and people who have server-side EAP today will need to add client- side EAP to their gateway implementation. You say it's "not adding a lot"; I disagree. Having written an EAP implementation (as well as 802.1x and several EAP methods) I can tell you it's a good sized chunk of code that needs testing and debugging. Doing what you propose means: 1. no AAA server for off-load is possible since both sides need to possess the shared secret and there is no AAA server in the world that can _initiate_ EAP. 2. the EAP encapsulation serves no purpose since the conversation is just between the two peers. 3. it takes twice as many messages. 4. it involves a pointless exchange of identities which brings up further complexity in the case when the identity in the EAP exchange differs from the one in the IKE exchange. You'll need to check, what do you do and why? All this added complexity to a security product for what gain? Nothing. For the other use case-- true client/server-- the EAP-only proposal also has a security issue since the server can claim any identity it chooses and the AAA server terminating EAP will "authenticate" it. So for 2 uses cases it's pointless complexity and for the other use case it's got a security problem. Why is this a good idea? Because "this is not adding a lot"? That's like saying that dirt doesn't taste that bad without explaining why someone would want to eat dirt in the first place. Dan. On Tue, December 1, 2009 5:17 am, Yaron Sheffer wrote: > Hi Tero, > > I think you are too quick to dismiss the option of using EAP-only for > site-to-site and transport deployments, where the EAP state machine is > embedded into the IKE endpoint. For people who already have client-side > EAP, this is not adding a lot. It's not as efficient as tailor-made > password authentication in IKE, but OTOH it is much more generic. > > Thanks, > Yaron > >> -----Original Message----- >> From: Tero Kivinen [mailto:kivinen@iki.fi] >> Sent: Tuesday, December 01, 2009 15:04 >> To: Yaron Sheffer >> Cc: Dan Harkins; Matthew Cini Sarreo; ipsec@ietf.org >> Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication >> (SPSK) - NO >> >> Yaron Sheffer writes: >> > I'm sorry, but you are misstating the difference between the >> > proposals. One is adding a notification and eliminating one existing >> > (certificate) check; the other is adding an IKE mode, and changing >> > the protocol state machine in the process. >> >> Not true. >> >> Both are adding new IKEv2 authentication mode. >> >> In EAP only authentication the EAP_ONLY_AUTHENTICATION notify also >> makes it so that server DOES NOT need to have certificate and public >> key, meaning it does not send it s first AUTH payload in message 4. >> >> The main benefit from this is that the server DOES NOT need to have >> private key. >> >> (at least in draft-eronen-ipsec-ikev2-eap-auth-07.txt) >> >> We currently already have 4 authentication modes. >> >> Client Server >> 1) Shared key Shared key >> 2) Public key Shared key >> 3) Shared key Public key >> 4) EAP Public key >> >> EAP only will add one more: >> >> 5) mutual-EAP mutual-EAP >> >> and SPSK will add one more: >> >> 6) Password Password >> >> > Regardless of all the other pros and cons, the proposals are clearly >> > not comparable as far as changing the protocol. >> >> The changes required for EAP only might be smaller, but testing effort >> for both of them is same, except EAP only really requires you to test >> with all supported mutual key generating EAP methods (and also test >> with others and make sure they are not accepted). >> >> One thing I think most of you are missing is that their usage >> scenarios are COMPLETELY different. >> >> EAP-only can be used when there is clear client-server setup, existing >> EAP infrastructure (for example EAP-SIM or EAP-AKA), and where there >> is no certificates or shared keys in use at all. This setup is >> asymmetric, one party (the user) always initiates the connection. SPSK >> cannot be used in such setup, as there is no password it can find. >> >> SPSK can be used when there is requirement for host to host (or site >> to site) connection, where either end can initiate traffic and >> exchanges and where entities still want to use passwords instead of >> public keys to authenticate. Shared keys could be used there, but in >> most setups the shared keys used in those scenarios are not strong >> enough to be resistant against dictionary attacks. EAP-only cannot be >> used there as this is not client-server setup. In these setup the >> authentication needs to be symmetric. >> >> For this reason I do not think we need to decide to take on or the >> other, we can take both as I do see use for both of them. >> >> If I would need to select one, I would select SPSK, as that is >> something which cannot be done by IKEv2 now. >> >> EAP-only is an optimization (both in protocol level, and especially in >> adminstrative level) for the existing EAP-Public key authentication. >> -- >> kivinen@iki.fi >> >> Scanned by Check Point Total Security Gateway. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From Pasi.Eronen@nokia.com Tue Dec 1 12:51: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 C2B6B3A68EE for ; Tue, 1 Dec 2009 12:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.51 X-Spam-Level: X-Spam-Status: No, score=-6.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 bCK3vZHwCaYh for ; Tue, 1 Dec 2009 12:51:01 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 5D56528C11F for ; Tue, 1 Dec 2009 12:51:01 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nB1KogiR009148; Tue, 1 Dec 2009 14:50:53 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 22:50:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 22:50:40 +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, 1 Dec 2009 21:50:39 +0100 From: To: , Date: Tue, 1 Dec 2009 21:50:38 +0100 Thread-Topic: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis Thread-Index: Acpt7d8qR47OKD8FQfyLvemojJB1XQE2QXkQ Message-ID: <808FD6E27AD4884E94820BC333B2DB774F311EB022@NOK-EUMSG-01.mgdnok.nokia.com> References: <19211.60135.834509.954897@fireball.kivinen.iki.fi> <19213.9738.693741.410069@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 X-OriginalArrivalTime: 01 Dec 2009 20:50:40.0425 (UTC) FILETIME=[F133E990:01CA72C7] 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, 01 Dec 2009 20:51:02 -0000 Paul Hoffman wrote: > - Add [IKEV2IANA] to the Normative References; it will point to the > URL of the IANA registry. I don't like the idea of splitting the normative content of RFC 4306 to two different places.=20 An informative reference would be very useful (and probably some of the tables may contain stuff that could be just removed). But if I'm writing code to send an IDi payload of type ID_FQDN, the numbers for "IDi" and "ID_FQDN" should be in this RFC (either=20 somewhere near the text that describes IDi and ID_FQDN, or in=20 a table -- that doesn't matter very much). Best regards, Pasi From yaronf@checkpoint.com Tue Dec 1 13:29: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 87A6E3A679C for ; Tue, 1 Dec 2009 13:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 9G3PhEC0hEJT for ; Tue, 1 Dec 2009 13:29:23 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 0AD693A685E for ; Tue, 1 Dec 2009 13:29:22 -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 nB1LTBGo009101; Tue, 1 Dec 2009 23:29:12 +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 23:29:18 +0200 From: Yaron Sheffer To: Dan Harkins Date: Tue, 1 Dec 2009 23:29:10 +0200 Thread-Topic: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO Thread-Index: AcpywXqfoVDNdyHATQqL3S/X+VSSLQABkJ7Q Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0832@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.com> <99043b4a0911302310v7f2edf00l8d210b1d1e7d14a8@mail.gmail.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0772@il-ex01.ad.checkpoint.com> <19221.5158.22224.351908@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E07A1@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" , Matthew, Cini Sarreo , Tero Kivinen 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 21:29:24 -0000 Hi Dan, I will not argue about the implementation complexity. Such arguments are us= eless in general, and I certainly cannot argue with your first-hand experie= nce. But EAP does solve, perfectly, the client-to-server use case. The password = can be offloaded to AAA or not, depending on security and performance consi= derations. And multiple choices are available for the authentication method= , depending on various criteria like performance, IPR, security strength an= d others. To repeat what I'd already said, the "lying NAS" problem can be easily solv= ed with channel bindings, and will (eventually) be solved. Adding a few pro= tected fields to any particular EAP method is not a big deal. Thanks, Yaron > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Tuesday, December 01, 2009 22:04 > To: Yaron Sheffer > Cc: Tero Kivinen; ipsec@ietf.org; Matthew Cini Sarreo > Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication > (SPSK) - NO >=20 >=20 > Hi Yaron, >=20 > EAP is a client/server protocol. If either side can initiate the > exchange (necessary for site-to-site and transport) then each side > will be required to implement BOTH the EAP client and EAP server > state machines. "[P]eople who already have client-side EAP" will > need to add server-side EAP to their IPsec client implementation > and people who have server-side EAP today will need to add client- > side EAP to their gateway implementation. You say it's "not adding a > lot"; I disagree. Having written an EAP implementation (as well as > 802.1x and several EAP methods) I can tell you it's a good sized > chunk of code that needs testing and debugging. >=20 > Doing what you propose means: >=20 > 1. no AAA server for off-load is possible since both sides need > to possess the shared secret and there is no AAA server in > the world that can _initiate_ EAP. > 2. the EAP encapsulation serves no purpose since the conversation > is just between the two peers. > 3. it takes twice as many messages. > 4. it involves a pointless exchange of identities which brings up > further complexity in the case when the identity in the EAP > exchange differs from the one in the IKE exchange. You'll need > to check, what do you do and why? >=20 > All this added complexity to a security product for what gain? Nothing. > For the other use case-- true client/server-- the EAP-only proposal > also has a security issue since the server can claim any identity it > chooses and the AAA server terminating EAP will "authenticate" it. >=20 > So for 2 uses cases it's pointless complexity and for the other use > case it's got a security problem. Why is this a good idea? Because > "this is not adding a lot"? That's like saying that dirt doesn't taste > that bad without explaining why someone would want to eat dirt in the > first place. >=20 > Dan. >=20 > On Tue, December 1, 2009 5:17 am, Yaron Sheffer wrote: > > Hi Tero, > > > > I think you are too quick to dismiss the option of using EAP-only for > > site-to-site and transport deployments, where the EAP state machine is > > embedded into the IKE endpoint. For people who already have client-side > > EAP, this is not adding a lot. It's not as efficient as tailor-made > > password authentication in IKE, but OTOH it is much more generic. > > > > Thanks, > > Yaron > > > >> -----Original Message----- > >> From: Tero Kivinen [mailto:kivinen@iki.fi] > >> Sent: Tuesday, December 01, 2009 15:04 > >> To: Yaron Sheffer > >> Cc: Dan Harkins; Matthew Cini Sarreo; ipsec@ietf.org > >> Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication > >> (SPSK) - NO > >> > >> Yaron Sheffer writes: > >> > I'm sorry, but you are misstating the difference between the > >> > proposals. One is adding a notification and eliminating one existing > >> > (certificate) check; the other is adding an IKE mode, and changing > >> > the protocol state machine in the process. > >> > >> Not true. > >> > >> Both are adding new IKEv2 authentication mode. > >> > >> In EAP only authentication the EAP_ONLY_AUTHENTICATION notify also > >> makes it so that server DOES NOT need to have certificate and public > >> key, meaning it does not send it s first AUTH payload in message 4. > >> > >> The main benefit from this is that the server DOES NOT need to have > >> private key. > >> > >> (at least in draft-eronen-ipsec-ikev2-eap-auth-07.txt) > >> > >> We currently already have 4 authentication modes. > >> > >> Client Server > >> 1) Shared key Shared key > >> 2) Public key Shared key > >> 3) Shared key Public key > >> 4) EAP Public key > >> > >> EAP only will add one more: > >> > >> 5) mutual-EAP mutual-EAP > >> > >> and SPSK will add one more: > >> > >> 6) Password Password > >> > >> > Regardless of all the other pros and cons, the proposals are clearly > >> > not comparable as far as changing the protocol. > >> > >> The changes required for EAP only might be smaller, but testing effort > >> for both of them is same, except EAP only really requires you to test > >> with all supported mutual key generating EAP methods (and also test > >> with others and make sure they are not accepted). > >> > >> One thing I think most of you are missing is that their usage > >> scenarios are COMPLETELY different. > >> > >> EAP-only can be used when there is clear client-server setup, existing > >> EAP infrastructure (for example EAP-SIM or EAP-AKA), and where there > >> is no certificates or shared keys in use at all. This setup is > >> asymmetric, one party (the user) always initiates the connection. SPSK > >> cannot be used in such setup, as there is no password it can find. > >> > >> SPSK can be used when there is requirement for host to host (or site > >> to site) connection, where either end can initiate traffic and > >> exchanges and where entities still want to use passwords instead of > >> public keys to authenticate. Shared keys could be used there, but in > >> most setups the shared keys used in those scenarios are not strong > >> enough to be resistant against dictionary attacks. EAP-only cannot be > >> used there as this is not client-server setup. In these setup the > >> authentication needs to be symmetric. > >> > >> For this reason I do not think we need to decide to take on or the > >> other, we can take both as I do see use for both of them. > >> > >> If I would need to select one, I would select SPSK, as that is > >> something which cannot be done by IKEv2 now. > >> > >> EAP-only is an optimization (both in protocol level, and especially in > >> adminstrative level) for the existing EAP-Public key authentication. > >> -- > >> kivinen@iki.fi > >> > >> Scanned by Check Point Total Security Gateway. > > _______________________________________________ > > 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 Tue Dec 1 14:00: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 8672E3A68F7 for ; Tue, 1 Dec 2009 14:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.046, 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 M475lOkBOgoU for ; Tue, 1 Dec 2009 14:00:25 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 4FF8A3A68DD for ; Tue, 1 Dec 2009 14:00: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 nB1M0GGo017190; Wed, 2 Dec 2009 00:00:16 +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, 2 Dec 2009 00:00:22 +0200 From: Yaron Sheffer To: Martin Willi , Dan Harkins Date: Wed, 2 Dec 2009 00:00:17 +0200 Thread-Topic: [IPsec] Proposed work item: EAP-only authentication in IKEv2 Thread-Index: AcpyaIRWIQ4urbQ5RnaiyydyPG4qewAaETgA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0834@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> <1259659632.573.49.camel@martin> In-Reply-To: <1259659632.573.49.camel@martin> 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 22:00:26 -0000 Hi Martin, If you (or anybody else) support EAP-only auth (or any of the other 6 draft= s), please commit to review it assuming it becomes a WG document. *This* wa= s the main point of this discussion thread: we cannot make progress without= committed editors and reviewers. Thanks, and apologies for picking on you :-) Yaron > -----Original Message----- > From: Martin Willi [mailto:martin@strongswan.org] > Sent: Tuesday, December 01, 2009 11:27 > To: Dan Harkins > Cc: Yaron Sheffer; ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2 >=20 > Hi Dan, >=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. >=20 > EAP authentication was not primarily included in IKEv2 to implement some > kind of password authentication on top if IKEv2, but to reuse existing > EAP methods and infrastructure. >=20 > The most demanding user of IKEv2 currently is the mobile/telco industry; > There are several specs in 3GPP and 3GPP2 using it. Many of them have > chosen IKEv2 because they can use their existing EAP-AKA/SIM > infrastructure for authentication. >=20 > > It seems to me that EAP-only authentication in IKEv2: > > 1. does not solve a general problem; >=20 > It does. It allows to omit public key authentication in cases where > mutual EAP authentication is sufficient. I'm aware of at least one 3GPP2 > spec that already uses EAP-AKA/TLS only authentication, but does not > follow this draft. I really see a need for this WG item. >=20 > > 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 >=20 > If you're just talking about password authentication, yes. But this > allows IKEv2 to work in existing infrastructures (EAP over > RADIUS/DIAMETER). We currently see a strong demand for such solutions. >=20 > > To provide the benefits of EAP-only authentication [...] it would be > > much better to support the inclusion of "Secure PSK authentication" as > > a work item. >=20 > Implementing password authentication on top of EAP may be one reason for > this draft, but there are several others. And the separated EAP layer > allows you to forward authentication to an existing AAA server. > Further, many vendors already have generic EAP support. Implementing PSK > authentication on top of it is probably simpler and more flexible than > integrating it in IKEv2 directly. >=20 > Best regards > Martin >=20 >=20 > Scanned by Check Point Total Security Gateway. From rsjenwar@gmail.com Tue Dec 1 17:46: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 1B0AA3A6926 for ; Tue, 1 Dec 2009 17:46:28 -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 2p022Bi3pkqM for ; Tue, 1 Dec 2009 17:46:27 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id A7EEE3A679F for ; Tue, 1 Dec 2009 17:46:26 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so1285792eyf.51 for ; Tue, 01 Dec 2009 17:46:14 -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:cc:content-type; bh=5LQe4f1D4RQIex/EQoE+5cjTTxtfXzXg1A5TMsIxtQQ=; b=pEZzQKHO743kheN5xPKgh+AMYr2dWZB1rDu/2AJfR+xjiWuoskpahHmyOOfqsCM4b3 AVj58ty6OuCiJ0cWkRKcWDL9iNpF2znFOLWjLsItBuZ5WxpfjRPnEC2STUMh9DcD3NRT Bnj28JdVoX0IbTu/3IUv+U+xnsSejw1cK8FxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=G+cOX/o721u7q3CaX/BNdj58+tj0owQcb/C8bo6LQQA1+lTGV3bxjsKi+9DQ1pjhYz Kl4eapBhsL+ibP82qjN79Ifgt0qgaEluxdn7+LXn2T+4UiAmjJO3gP8NYAXIs2BacfhZ sc94oWCWzZmY2ZP+L4gt9QixAW61sJnAM44lo= MIME-Version: 1.0 Received: by 10.216.89.200 with SMTP id c50mr2188392wef.137.1259718373880; Tue, 01 Dec 2009 17:46:13 -0800 (PST) Date: Wed, 2 Dec 2009 07:16:13 +0530 Message-ID: <7ccecf670912011746uf252b88w9955f22162d03a8a@mail.gmail.com> From: Raj Singh To: Yaron Sheffer Content-Type: multipart/alternative; boundary=0016e6d7e34531346e0479b50a13 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Proposed work item: IKE/IPsec high availability and load sharing - YES 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, 02 Dec 2009 01:46:28 -0000 --0016e6d7e34531346e0479b50a13 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Team, According to me, High Availability needs protocol level support from IKEv2 due to windowing and sequence numbers in IPsec. This will enhance performance and avoid proprietary versions of different vendors. Here we can discuss various problem and solution of IPsec and HA, which surely needs some attention. Also, Kalyani presented a solution syncing-up of IKE message id in internal meeting. That can be a good starting point. I would like to review and co-author this draft. Regards, Raj On Sun, Nov 29, 2009 at 10:49 PM, Yaron Sheffer wrot= e: > This work item will define the problem statement and requirements for a > solution that allows interoperable HA/LS device groups. Mixed-vendor > clusters are specifically out of scope; but single-vendor clusters should= be > fully interoperable with other vendors=E2=80=99 devices or clusters. The = main > challenge 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 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 > 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 fin= e > 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-expor= t > in IPsec - NO!"). > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --0016e6d7e34531346e0479b50a13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Team,

According to me, High Availability needs protoc= ol level support from IKEv2 due to windowing and sequence numbers in IPsec.=
This will enhance performance and avoid=C2=A0proprietary=C2=A0ve= rsions of different vendors. Here we can discuss various problem and soluti= on of IPsec and HA, which surely needs some attention.
Also, Kalyani presented a solution=C2=A0syncing-up=C2=A0of IKE message= id in internal meeting. That can be a good starting point.
I wou= ld like to review and co-author this draft.

Regard= s,
Raj

On Sun, Nov 29, 2009 at 10:49 PM= , Yaron Sheffer <yaronf@checkpoint.com> wrote:

T= his work item will define the problem statement and requirements for 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=E2=80=99 devices or clusters. The main cha= llenge 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.

= =C2=A0

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

= =C2=A0

P= lease reply to the list:

= =C2=A0

-= 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?

= =C2=A0

P= lease also reply to the list if:

= =C2=A0

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

= =C2=A0

I= f 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-ex= port in IPsec - NO!").


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


--0016e6d7e34531346e0479b50a13-- From rsjenwar@gmail.com Tue Dec 1 17:59: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 E363D3A686E for ; Tue, 1 Dec 2009 17:59:57 -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 HUvM7YOr0TKe for ; Tue, 1 Dec 2009 17:59:57 -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 D32703A6781 for ; Tue, 1 Dec 2009 17:59:56 -0800 (PST) Received: by ewy6 with SMTP id 6so578952ewy.29 for ; Tue, 01 Dec 2009 17:59:45 -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:cc:content-type; bh=uwzn/ztS3kqtWKmfMHbZPbyTGzeoWw0itQjr5hM0DZM=; b=p+1Sh8FP2wZB6XWfoKEFGmuNv6q7+L32QdFQeqgOv6NXFkXjHhC+JFjTdULYy4Jv48 msmS4goM36CYcW4e1AwhPB7NIo2FhKuQTFIGbGr1T5G45DVufU/Gcn157lEPaAX96Va9 92dmPLAL7GlO4F7bVDb3sD99t9lOt/n4juX9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=DCN3zNDL63HXsFupUPnBcEVRoMYGtV+DNlhWCfQbuLGV2oNE9xv/cuZCi/ZBSuaIJh c32yN6LbG9xvPbG2p59IZd7t8O9QqfK0026iHV1b2RY8XVwuOWeQCVJZlnndvbwbpz9H 1iA4UVqK1dcU1UuQCD4lo50DcTVqFb/O2Xwdc= MIME-Version: 1.0 Received: by 10.216.88.140 with SMTP id a12mr2325694wef.157.1259719184739; Tue, 01 Dec 2009 17:59:44 -0800 (PST) Date: Wed, 2 Dec 2009 07:29:44 +0530 Message-ID: <7ccecf670912011759h2985280cnf4799c585fb87694@mail.gmail.com> From: Raj Singh To: Yaron Sheffer Content-Type: multipart/alternative; boundary=0016e6d7eb4685ee270479b53a32 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Proposed work item: Failure detection in IKEv2 - YES 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, 02 Dec 2009 01:59:58 -0000 --0016e6d7eb4685ee270479b53a32 Content-Type: text/plain; charset=UTF-8 Hi Team, According to me, we need to support this draft as WG item as it appears to enhance the failure detection time. Currently, there are many scenarios, in which we detect and delete stale SA only by max. re-transmits. I would like to review this draft. Regards, Raj 2009/11/29 Yaron Sheffer > 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.txtor > http://tools.ietf.org/html/draft-detienne-ikev2-recovery-03. > > 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 > --0016e6d7eb4685ee270479b53a32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Team,

According to me, we need to support this draft = as WG item as it appears to enhance the failure detection time.
C= urrently, there are many scenarios, in which we detect and delete stale SA = only by max. re-transmits.
I would like to review this draft.

Regards,
Raj

2009/11/29 Yaron Sheffer <yaronf@checkpoi= nt.com>
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, whic= h 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.
=C2=A0
Please reply to the list:
=C2=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?
=C2=A0
Please also reply to the list if:
=C2=A0
- You believe this is NOT a reasonable activity for the WG to spend time on= .
=C2=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 IPsec - NO!").
_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--0016e6d7eb4685ee270479b53a32-- From mcins1@gmail.com Tue Dec 1 23:19: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 912FA3A67F7 for ; Tue, 1 Dec 2009 23:19:20 -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 kcgP0dpxfDRR for ; Tue, 1 Dec 2009 23:19:19 -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 3D1113A67B0 for ; Tue, 1 Dec 2009 23:19:19 -0800 (PST) Received: by ywh15 with SMTP id 15so5062478ywh.5 for ; Tue, 01 Dec 2009 23:19:08 -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=geTfVKdgAyJuCP3+ecSn1jCMOFRul9wDllqsl+X0/IM=; b=gG6hFkQ1DvK8UUbz14aYzXOJGKqXZkQxNNMTxArjiP8zCgYwTGysfBjn3E5noZQgGQ GaX2e38Cs59dpJDFS5e81c7qR7Js4LrNPmKs3SA2dBiX8TaztU1RPJ9wdsysJIJCy+mM uLwi1wXTUOmTFSK33gt1zEYh/8BFHDs4ZX7mU= 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=iCf0k1dbsfQOH/BHfJzzN/pdPW6GbHm2N4FU5HTkfU9XGZkepM8ZYGx22LzwSZGWb6 VJRaG0qVtV7CGM7j8SoeCkLnNtJKXbNiKpVqO5GTjvFs51PX/VBxJHVWaMyMlZ+smpKH QpiJL3eoxKn0o/Onjs+FUd4A2QMLO/iwg0i24= MIME-Version: 1.0 Received: by 10.90.253.16 with SMTP id a16mr9604147agi.3.1259738348646; Tue, 01 Dec 2009 23:19:08 -0800 (PST) In-Reply-To: <7ccecf670912011759h2985280cnf4799c585fb87694@mail.gmail.com> References: <7ccecf670912011759h2985280cnf4799c585fb87694@mail.gmail.com> From: Matthew Cini Sarreo Date: Wed, 2 Dec 2009 08:18:47 +0100 Message-ID: <99043b4a0912012318o27ec5eddy1bdfdc86a20bda9b@mail.gmail.com> To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=001636284e4ac7f12c0479b9b0a8 Subject: Re: [IPsec] Proposed work item: Failure detection in IKEv2 - YES 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, 02 Dec 2009 07:19:20 -0000 --001636284e4ac7f12c0479b9b0a8 Content-Type: text/plain; charset=ISO-8859-1 Hello all, I myself do not like the current method for detecting that a peer has lost state (generally this means waiting for a number of retransmits, whom each of which has a time out). In my opinion this would be a good item for the WG to work on and would enhance IKEv2. I would like to review the draft. If time permits, I would be interested to contribute text, but I cannot say that for sure right now. Regards, Matt 2009/12/2 Raj Singh > Hi Team, > > According to me, we need to support this draft as WG item as it appears to > enhance the failure detection time. > Currently, there are many scenarios, in which we detect and delete stale SA > only by max. re-transmits. > I would like to review this draft. > > Regards, > Raj > > 2009/11/29 Yaron Sheffer > >> 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. >> >> 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 >> > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --001636284e4ac7f12c0479b9b0a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello all,

I myself do not like the current method for detecting tha= t a peer has lost state (generally this means waiting for a number of retra= nsmits, whom each of which has a time out). In my opinion this would be a g= ood item for the WG to work on and would enhance IKEv2. I would like to rev= iew the draft. If time permits, I would be interested to contribute text, b= ut I cannot say that for sure right now.

Regards,
Matt

2009/12/2 Raj Singh = <rsjenwar@gmail.= com>
Hi Team,

According to me, we need to support this draft = as WG item as it appears to enhance the failure detection time.
C= urrently, there are many scenarios, in which we detect and delete stale SA = only by max. re-transmits.
I would like to review this draft.

Regards,
Raj

2009/11/29 Yaron Sheffer <yaronf@checkpoint.com>
This work item pr= oposes an IKEv2 extension to allow an IKE peer to quickly and securely dete= ct that its opposite peer has lost state. This is claimed to be quicker tha= n 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 IPsec - NO!").
_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec


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


--001636284e4ac7f12c0479b9b0a8-- From yaronf@checkpoint.com Wed Dec 2 00:31: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 2A5B13A6A73 for ; Wed, 2 Dec 2009 00:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 h2SRyKOqXBbo for ; Wed, 2 Dec 2009 00:31:26 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id AAFCE3A6A6C for ; Wed, 2 Dec 2009 00:31: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 nB28VDGp006174; Wed, 2 Dec 2009 10:31:16 +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, 2 Dec 2009 10:31:20 +0200 From: Yaron Sheffer To: Dan Harkins Date: Wed, 2 Dec 2009 10:31:19 +0200 Thread-Topic: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO Thread-Index: AcpyXwYMm4++7XALR+ySTez+dGUrlgAx16OA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E08A5@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.com> <402d5ea50fcadec3d66a41f63fd1b9df.squirrel@www.trepanning.net> In-Reply-To: <402d5ea50fcadec3d66a41f63fd1b9df.squirrel@www.trepanning.net> 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: Wed, 02 Dec 2009 08:31:27 -0000 Hi Dan, Responding to your last point: The alternatives for EAP-PWD (a.k.a. SPSK), namely EKE, SRP and PAK, have a= ll been published outside the IETF and peer-reviewed by the relevant commun= ity: cryptographers, mainly of the academic kind. I highly appreciate the e= xpertise we have at the IPsecME WG and at the CFRG. But if we're adding a n= ew security mechanism to a major IETF security protocol, this level of expe= rtise is insufficient. Anything we do will STILL need to be reviewed by CFR= G - both EAP-EKE and EAP-PWD have had holes punched into them by these peop= le. But it would be irresponsible to ONLY have this limited level of review= . Regarding the process at the EMU side of the house, I share your frustratio= n... Thanks, Yaron > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Tuesday, December 01, 2009 10:19 > To: Yaron Sheffer > Cc: Dan Harkins; ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication > (SPSK) - NO >=20 >=20 > Yaron, >=20 > It is important for you to state what problem you're trying to solve. > That problem is, simply, password-only authentication. To bring up the > motivation for adding EAP to IKEv2 is quite irrelevant since EAP in IKEv2 > today involves server-side authentication using a certificate. >=20 > You want to do password authentication in IKE. Period. Full stop. And t= o > do that you want to add a pointless encapsulation. And you want to do it > with twice as many messages. And you want to require each side to > implement > both the client- and server-side state machines for this "solution" to > be useful in the use cases defined in IKEv2. >=20 > It seems to me that you need to justify why such EXTRA work is necessar= y > when a simpler way of solving your problem is available. Don't just say > "it doesn't make sense", justify why you are proposing more, extraneous > work. >=20 > Furthermore, I would be very interested in why you feel that a WG in > the Security Area of the IETF is not the place to define cryptographic > protocols and that it would be more appropriate for a WG in the Security > Area to just use a protocol from the Network Area with protocols defined > as individual submissions. >=20 > Dan. >=20 > On Mon, November 30, 2009 10:46 pm, Yaron Sheffer wrote: > > 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 thre= e > > 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 o= r > >> 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 us= e > >> 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 th= e > >> fine > >> > technical details (which will change anyway, once the WG gets hold o= f > >> 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 > > >=20 >=20 >=20 > Scanned by Check Point Total Security Gateway. From martin@strongswan.org Wed Dec 2 01:47: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 B7BE728C17B for ; Wed, 2 Dec 2009 01:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556] 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 vhkRkp-rhsJe for ; Wed, 2 Dec 2009 01:47:48 -0800 (PST) Received: from zaes.ch (zaes.ch [213.133.111.41]) by core3.amsl.com (Postfix) with ESMTP id 370DA28C184 for ; Wed, 2 Dec 2009 01:47:28 -0800 (PST) Received: from 193-180.60-188.cust.bluewin.ch ([188.60.180.193] helo=[192.168.1.33]) by zaes.ch with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NFm6X-0000Lq-QW; Wed, 02 Dec 2009 11:06:37 +0100 From: Martin Willi To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 02 Dec 2009 10:47:16 +0100 Message-ID: <1259747236.13376.9.camel@martin> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit X-RPR-Rewrite: reverse-path rewritten by zaes.ch 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: Wed, 02 Dec 2009 09:47:49 -0000 Hi Yaron, > - 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? I'm willing to review and contribute text to the EAP-only work item. We probably start on implementing the draft soon, so I'll have some feedback from the front... Regards Martin From alper.yegin@yegin.org Wed Dec 2 05:49: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 0BB9728C1C0 for ; Wed, 2 Dec 2009 05:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 3YktOXs+XsDC for ; Wed, 2 Dec 2009 05:49:41 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 197E23A689F for ; Wed, 2 Dec 2009 05:49:41 -0800 (PST) Received: from LENOVO (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LcAaz-1Nx70k1UDF-00jYYX; Wed, 02 Dec 2009 08:49:32 -0500 From: "Alper Yegin" To: "'Hui Deng'" , "'Yoav Nir'" References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <6F892B93-1B06-44DE-852F-A7C2F2799717@checkpoint.com> <1d38a3350912010527w30a6779cycd0cfad5d628e596@mail.gmail.com> In-Reply-To: <1d38a3350912010527w30a6779cycd0cfad5d628e596@mail.gmail.com> Date: Wed, 2 Dec 2009 15:49:25 +0200 Message-ID: <052e01ca7356$4637e390$d2a7aab0$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acpyi0i/N3LCpR+fQPKGKh8TGOh7fwAyt2Dg Content-Language: en-us X-Provags-ID: V01U2FsdGVkX18JueGSz+ZI0Fl6Wmol/Uulw2GqgMAXxH4Ei5F CXzU3WxJpbSKW7vcXgADVdekjASccNgVgKqOAs7/lX3H3LrABQ 2FK804RrMGD3aZ1S/iBIQ== Cc: ipsec@ietf.org Subject: Re: [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: Wed, 02 Dec 2009 13:49:42 -0000 Hi Hui, Are all 4 motivations below part of 3gpp discussion? Alper =20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Hui Deng > Sent: Tuesday, December 01, 2009 3:28 PM > To: Yoav Nir > Cc: ipsec@ietf.org; Alper Yegin > Subject: Re: [IPsec] Proposed work item: Childless IKE SA >=20 > During the last 3GPP SA3 meeting, such requirement about HNB has also > been approved as well. >=20 > thanks >=20 > -Hui >=20 > 2009/12/1 Yoav Nir : > > There were several motivations listed for childless IKE SAs. > > =A0- remote access, where you create an IKE SA when the user wants = to > connect, and only create child SAs in response to traffic > > =A0- authentication only over a physically secure network (not > necessarily EAP, but I think this is the use case you referred to) > > =A0- Location awareness (as in the SecureBeacon draft) > > =A0- Some "weird" uses such as liveness checks without IPsec, NAT > detection, etc. > > > > > > On Dec 1, 2009, at 2:29 PM, Alper Yegin wrote: > > > >> One of the (or main?) motivations of this proposal is to turn IKEv2 > into > >> "EAP-based network access authentication protocol". =A0RFC 5191 is > designed > >> for that purpose, and I'm not sure if we need to twist a protocol > for the > >> same purpose. > >> > >> > >> > >>> -----Original Message----- > >>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > >>> Of Yaron Sheffer > >>> Sent: Sunday, November 29, 2009 7:21 PM > >>> To: ipsec@ietf.org > >>> Subject: [IPsec] Proposed work item: Childless IKE SA > >>> > >>> 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- > >>> childless-01.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 > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From mcins1@gmail.com Wed Dec 2 07:33: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 017B53A6878 for ; Wed, 2 Dec 2009 07:33:41 -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 IX9GqY-VQ5ZI for ; Wed, 2 Dec 2009 07:33:39 -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 7C98628C184 for ; Wed, 2 Dec 2009 07:33:39 -0800 (PST) Received: by ywh15 with SMTP id 15so267206ywh.5 for ; Wed, 02 Dec 2009 07:33:28 -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=fha490t/Sk1JMYrkBKRUQYLm2PTrYS+zM5aYbObzu10=; b=ruUaUk/PX7xoR4YpJA5OwqjU7+FOLqwgzVEHAZHS0//SP3PgL2Xfs2+w6TCJzKsNj4 d0aZNNmJ5rDtp8Gklker6MIJImH5fbtPA/BnP+U3ZrDiJVP5sVMP5UKwVt2nICZD3AfF N6iAQkjPi31DAO/ws14byJDHvO9M+wDPO/7WI= 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=k5uUrFiVBhy19g5gQyS5TGlhkMXiGSVqcTSVAbAAKrym9EOfpWqZhQW94KMXjYPIzM n1eWWX48DYfla8WggzbV7EtV8UC40boAB+QBhCf2lVSATOOx5KpBO5xMCI2DfSHabbcE TMvnaaYC2SsEr0mLKNA8V+eCAHrfYHyKP22/s= MIME-Version: 1.0 Received: by 10.91.21.6 with SMTP id y6mr424980agi.11.1259768008245; Wed, 02 Dec 2009 07:33:28 -0800 (PST) In-Reply-To: <201312521538385754@unknownmsgid> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <6F892B93-1B06-44DE-852F-A7C2F2799717@checkpoint.com> <1d38a3350912010527w30a6779cycd0cfad5d628e596@mail.gmail.com> <201312521538385754@unknownmsgid> From: Matthew Cini Sarreo Date: Wed, 2 Dec 2009 16:33:08 +0100 Message-ID: <99043b4a0912020733w528f20c0s9ba4a0402e2e6950@mail.gmail.com> To: Yoav Nir , ipsec@ietf.org Content-Type: multipart/alternative; boundary=0016e640cc82a183360479c0984c Subject: Re: [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: Wed, 02 Dec 2009 15:33:41 -0000 --0016e640cc82a183360479c0984c Content-Type: text/plain; charset=ISO-8859-1 Hello Yoav, This seems to be very interesting, I like it due to the first motivation you mentioned. I would be ready to review if this is accepted as a WG item. If some of the motivations are already tackled, it would be wise to check if making additions to IKEv2 tackling those motivations would be worth while. Regards, Matt 2009/12/2 Alper Yegin > Hi Hui, > > Are all 4 motivations below part of 3gpp discussion? > > Alper > > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > > Of Hui Deng > > Sent: Tuesday, December 01, 2009 3:28 PM > > To: Yoav Nir > > Cc: ipsec@ietf.org; Alper Yegin > > Subject: Re: [IPsec] Proposed work item: Childless IKE SA > > > > During the last 3GPP SA3 meeting, such requirement about HNB has also > > been approved as well. > > > > thanks > > > > -Hui > > > > 2009/12/1 Yoav Nir : > > > There were several motivations listed for childless IKE SAs. > > > - remote access, where you create an IKE SA when the user wants to > > connect, and only create child SAs in response to traffic > > > - authentication only over a physically secure network (not > > necessarily EAP, but I think this is the use case you referred to) > > > - Location awareness (as in the SecureBeacon draft) > > > - Some "weird" uses such as liveness checks without IPsec, NAT > > detection, etc. > > > > > > > > > On Dec 1, 2009, at 2:29 PM, Alper Yegin wrote: > > > > > >> One of the (or main?) motivations of this proposal is to turn IKEv2 > > into > > >> "EAP-based network access authentication protocol". RFC 5191 is > > designed > > >> for that purpose, and I'm not sure if we need to twist a protocol > > for the > > >> same purpose. > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > > Behalf > > >>> Of Yaron Sheffer > > >>> Sent: Sunday, November 29, 2009 7:21 PM > > >>> To: ipsec@ietf.org > > >>> Subject: [IPsec] Proposed work item: Childless IKE SA > > >>> > > >>> 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- > > >>> childless-01.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 > > >> > > >> _______________________________________________ > > >> 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 > > > > > _______________________________________________ > > 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 > --0016e640cc82a183360479c0984c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Yoav,

This seems to be very interesting, I like it due to the = first motivation you mentioned. I would be ready to review if this is accep= ted as a WG item.

If some of the motivations are already tackled, it= would be wise to check if making additions to IKEv2 tackling those motivat= ions would be worth while.

Regards,
Matt


2009/12/2 Alper = Yegin <alper.= yegin@yegin.org>
Hi Hui,

Are all 4 motivations below part of 3gpp discussion?

Alper


> -----Original Message-----
> From: ipsec-bounces@ietf.org= [mailto:ipsec-bounces@ietf.o= rg] On Behalf
> Of Hui Deng
> Sent: Tuesday, December 01, 2009 3:28 PM
> To: Yoav Nir
> Cc: ipsec@ietf.org; Alper Yegin<= br> > Subject: Re: [IPsec] Proposed work item: Childless IKE SA
>
> During the last 3GPP SA3 meeting, such requirement about HNB has also<= br> > been approved as well.
>
> thanks
>
> -Hui
>
> 2009/12/1 Yoav Nir <ynir@che= ckpoint.com>:
> > There were several motivations listed for childless IKE SAs.
> > =A0- remote access, where you create an IKE SA when the user want= s to
> connect, and only create child SAs in response to traffic
> > =A0- authentication only over a physically secure network (not > necessarily EAP, but I think this is the use case you referred to)
> > =A0- Location awareness (as in the SecureBeacon draft)
> > =A0- Some "weird" uses such as liveness checks without = IPsec, NAT
> detection, etc.
> >
> >
> > On Dec 1, 2009, at 2:29 PM, Alper Yegin wrote:
> >
> >> One of the (or main?) motivations of this proposal is to turn= IKEv2
> into
> >> "EAP-based network access authentication protocol".= =A0RFC 5191 is
> designed
> >> for that purpose, and I'm not sure if we need to twist a = protocol
> for the
> >> same purpose.
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: ipsec-bou= nces@ietf.org [mailto:ipsec-b= ounces@ietf.org] On
> Behalf
> >>> Of Yaron Sheffer
> >>> Sent: Sunday, November 29, 2009 7:21 PM
> >>> To: ipsec@ietf.org<= br> > >>> Subject: [IPsec] Proposed work item: Childless IKE SA
> >>>
> >>> This draft proposes an IKEv2 extension to allow the setup= of an IKE
> SA
> >>> with no Child SA, a situation which is currently disallow= ed by the
> >>> protocol.
> >>>
> >>> Proposed starting point: http://tools.ietf.org/id/draft-nir- > ipsecme-
> >>> childless-01.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 W= G 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 th= e 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 cl= early
> (e.g.
> >>> "DES40-export in IPsec - NO!").
> >>> _______________________________________________
> >>> 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
> >>
> >> Scanned by Check Point Total Security Gateway.
> >
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

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

--0016e640cc82a183360479c0984c-- From dharkins@lounge.org Wed Dec 2 11:12: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 53E8E3A6A3F for ; Wed, 2 Dec 2009 11:12:29 -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 ZuZEQ-oplqol for ; Wed, 2 Dec 2009 11:12:20 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id A62083A6A3B for ; Wed, 2 Dec 2009 11:12:17 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id BEEE9102240AE; Wed, 2 Dec 2009 11:12:09 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 2 Dec 2009 11:12:09 -0800 (PST) Message-ID: <97858d5d3b9dfd340aad35cf7e8aec50.squirrel@www.trepanning.net> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E08A5@il-ex01.ad.checkpoint.co m> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.com> <402d5ea50fcadec3d66a41f63fd1b9df.squirrel@www.trepanning.net> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E08A5@il-ex01.ad.checkpoint.com> Date: Wed, 2 Dec 2009 11:12:09 -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) - 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: Wed, 02 Dec 2009 19:12:30 -0000 Hi Yaron, The technology underlying SPSK is not patented, EKE, SRP and PAK are all patented. Patents are a drag. In addition, EKE has the additional problem that it requires specialized MODP groups-- it can't use the ones in the IKE registry-- and I don't believe it can be used with elliptic curve groups at all. SPSK can use any MODP or ECP group in the registry, just like IKE. SPSK is a natural fit. The technology underlying SPSK was published outside the IETF. Check out the references in the draft. It is being reviewed in the academic community right now. I'm sorry you don't don't feel that the IETF/IRTF has the expertise to do crypto but, once again, I disagree. Dan. On Wed, December 2, 2009 12:31 am, Yaron Sheffer wrote: > Hi Dan, > > Responding to your last point: > > The alternatives for EAP-PWD (a.k.a. SPSK), namely EKE, SRP and PAK, have > all been published outside the IETF and peer-reviewed by the relevant > community: cryptographers, mainly of the academic kind. I highly > appreciate the expertise we have at the IPsecME WG and at the CFRG. But if > we're adding a new security mechanism to a major IETF security protocol, > this level of expertise is insufficient. Anything we do will STILL need to > be reviewed by CFRG - both EAP-EKE and EAP-PWD have had holes punched into > them by these people. But it would be irresponsible to ONLY have this > limited level of review. > > Regarding the process at the EMU side of the house, I share your > frustration... > > Thanks, > Yaron > >> -----Original Message----- >> From: Dan Harkins [mailto:dharkins@lounge.org] >> Sent: Tuesday, December 01, 2009 10:19 >> To: Yaron Sheffer >> Cc: Dan Harkins; ipsec@ietf.org >> Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication >> (SPSK) - NO >> >> >> Yaron, >> >> It is important for you to state what problem you're trying to solve. >> That problem is, simply, password-only authentication. To bring up the >> motivation for adding EAP to IKEv2 is quite irrelevant since EAP in >> IKEv2 >> today involves server-side authentication using a certificate. >> >> You want to do password authentication in IKE. Period. Full stop. And >> to >> do that you want to add a pointless encapsulation. And you want to do it >> with twice as many messages. And you want to require each side to >> implement >> both the client- and server-side state machines for this "solution" to >> be useful in the use cases defined in IKEv2. >> >> It seems to me that you need to justify why such EXTRA work is >> necessary >> when a simpler way of solving your problem is available. Don't just say >> "it doesn't make sense", justify why you are proposing more, extraneous >> work. >> >> Furthermore, I would be very interested in why you feel that a WG in >> the Security Area of the IETF is not the place to define cryptographic >> protocols and that it would be more appropriate for a WG in the Security >> Area to just use a protocol from the Network Area with protocols defined >> as individual submissions. >> >> Dan. >> >> On Mon, November 30, 2009 10:46 pm, Yaron Sheffer wrote: >> > 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 >> > >> >> >> >> Scanned by Check Point Total Security Gateway. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From yaronf@checkpoint.com Wed Dec 2 11:43: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 5CE1E3A6403 for ; Wed, 2 Dec 2009 11:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 VHf-lF6m4DPM for ; Wed, 2 Dec 2009 11:43:00 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id A91E43A6784 for ; Wed, 2 Dec 2009 11:42: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 nB2JgkGo026256; Wed, 2 Dec 2009 21:42:46 +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, 2 Dec 2009 21:42:53 +0200 From: Yaron Sheffer To: Dan Harkins Date: Wed, 2 Dec 2009 21:42:51 +0200 Thread-Topic: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO Thread-Index: Acpzg19EE3dq3bpNSnyDy5Vj7ic1rAAAa01w Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E09E0@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.com> <402d5ea50fcadec3d66a41f63fd1b9df.squirrel@www.trepanning.net> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E08A5@il-ex01.ad.checkpoint.com> <97858d5d3b9dfd340aad35cf7e8aec50.squirrel@www.trepanning.net> In-Reply-To: <97858d5d3b9dfd340aad35cf7e8aec50.squirrel@www.trepanning.net> 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: Wed, 02 Dec 2009 19:43:01 -0000 Hi Dan, I actually think the patent situation plays against SPSK, rather than in it= s favor. But I will say no more. Patent *discussions* are a drag. My person= al opinion is that patents should have the lowest priority in this decision= . As you know, it is trivial to generate MODP groups that will work well with= EKE, and whether you use the existing registry or not is a minor detail. F= or ECC groups, admittedly we don't have a solution yet. I'm glad to hear that SPSK is being reviewed by cryptographers, and would b= e happy to read an analysis. Publishing it at a more crypto-oriented venue = would also help in soliciting more and better reviews. Thanks, Yaron > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Wednesday, December 02, 2009 21:12 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication > (SPSK) - NO >=20 >=20 > Hi Yaron, >=20 > The technology underlying SPSK is not patented, EKE, SRP and PAK > are all patented. Patents are a drag. >=20 > In addition, EKE has the additional problem that it requires > specialized MODP groups-- it can't use the ones in the IKE registry-- > and I don't believe it can be used with elliptic curve groups at all. > SPSK can use any MODP or ECP group in the registry, just like IKE. > SPSK is a natural fit. >=20 > The technology underlying SPSK was published outside the IETF. > Check out the references in the draft. It is being reviewed in the > academic community right now. I'm sorry you don't don't feel that > the IETF/IRTF has the expertise to do crypto but, once again, I > disagree. >=20 > Dan. >=20 > On Wed, December 2, 2009 12:31 am, Yaron Sheffer wrote: > > Hi Dan, > > > > Responding to your last point: > > > > The alternatives for EAP-PWD (a.k.a. SPSK), namely EKE, SRP and PAK, > have > > all been published outside the IETF and peer-reviewed by the relevant > > community: cryptographers, mainly of the academic kind. I highly > > appreciate the expertise we have at the IPsecME WG and at the CFRG. But > if > > we're adding a new security mechanism to a major IETF security protocol= , > > this level of expertise is insufficient. Anything we do will STILL need > to > > be reviewed by CFRG - both EAP-EKE and EAP-PWD have had holes punched > into > > them by these people. But it would be irresponsible to ONLY have this > > limited level of review. > > > > Regarding the process at the EMU side of the house, I share your > > frustration... > > > > Thanks, > > Yaron > > > >> -----Original Message----- > >> From: Dan Harkins [mailto:dharkins@lounge.org] > >> Sent: Tuesday, December 01, 2009 10:19 > >> To: Yaron Sheffer > >> Cc: Dan Harkins; ipsec@ietf.org > >> Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication > >> (SPSK) - NO > >> > >> > >> Yaron, > >> > >> It is important for you to state what problem you're trying to solve= . > >> That problem is, simply, password-only authentication. To bring up the > >> motivation for adding EAP to IKEv2 is quite irrelevant since EAP in > >> IKEv2 > >> today involves server-side authentication using a certificate. > >> > >> You want to do password authentication in IKE. Period. Full stop. An= d > >> to > >> do that you want to add a pointless encapsulation. And you want to do > it > >> with twice as many messages. And you want to require each side to > >> implement > >> both the client- and server-side state machines for this "solution" to > >> be useful in the use cases defined in IKEv2. > >> > >> It seems to me that you need to justify why such EXTRA work is > >> necessary > >> when a simpler way of solving your problem is available. Don't just sa= y > >> "it doesn't make sense", justify why you are proposing more, extraneou= s > >> work. > >> > >> Furthermore, I would be very interested in why you feel that a WG in > >> the Security Area of the IETF is not the place to define cryptographic > >> protocols and that it would be more appropriate for a WG in the > Security > >> Area to just use a protocol from the Network Area with protocols > defined > >> as individual submissions. > >> > >> Dan. > >> > >> On Mon, November 30, 2009 10:46 pm, Yaron Sheffer wrote: > >> > 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-0= 3 > >> > - 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 i= n > >> 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 tha= n > >> the > >> >> narrow focus of EAP-only, does not require extraneous encapsulation= s > >> or > >> >> unnecessary code (ala EAP-only), and is secure regardless of its us= e > >> >> (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 hol= d > >> 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 > >> > > >> > >> > >> > >> Scanned by Check Point Total Security Gateway. > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > >=20 >=20 >=20 > Scanned by Check Point Total Security Gateway. From kent@bbn.com Wed Dec 2 15: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 28C0728C0DC for ; Wed, 2 Dec 2009 15:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 3MI8ijW9Ah1l for ; Wed, 2 Dec 2009 15:44:41 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6D2843A68D9 for ; Wed, 2 Dec 2009 15:44:41 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.28.167.12]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NFys3-0003SK-Cc for ipsec@ietf.org; Wed, 02 Dec 2009 18:44:32 -0500 Mime-Version: 1.0 Message-Id: Date: Wed, 2 Dec 2009 18:44:29 -0500 To: ipsec@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [IPsec] password auth methods debate 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, 02 Dec 2009 23:44:42 -0000 Folks, I think there is merit to pursing both the EAP-based and the SPSK-based password authentication proposals as WG items. My rationale is: - EAP-based methods are well-suited to client-server interactions and to enterprise environments that already use RADIUS/DIAMATER. Unfortunately, these methods seem ill-suited to peer communications, and IPsec is a peer communication architecture, so having only these methods available for password-based auth seems inappropriate. Also, Dan has indicated that there are IP clams associated with the specific methods that have been cited, which makes me leery of relying too heavily in them. - a generic password-based scheme seems desirable for peer (cs. client-server) contexts, and if such schemes are IP-free, so much the better. However, enterprise use of IPsec is primarily for road warriors, and thus is a client-server context, and there is a strong preference for a RADIUS/DIAMATER compatibility in this context. So, i see a benefit in this WG pursuing both work items. Steve From smoonen@us.ibm.com Wed Dec 2 17:42: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 DA9853A6358; Wed, 2 Dec 2009 17:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.023 X-Spam-Level: X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=0.575, 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 kWcZcSVbJhne; Wed, 2 Dec 2009 17:42:55 -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 C66083A69A0; Wed, 2 Dec 2009 17:42:55 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e31.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nB31ZON8005727; Wed, 2 Dec 2009 18:35:24 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id nB31ghAC144206; Wed, 2 Dec 2009 18:42:43 -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 nB31geQ4018712; Wed, 2 Dec 2009 18:42:40 -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 nB31gerI018709; Wed, 2 Dec 2009 18:42:40 -0700 In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F1@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F1@il-ex01.ad.checkpoint.com> To: Yaron Sheffer MIME-Version: 1.0 X-KeepSent: A5154CD1:BBD49654-85257681:0008C726; 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 12/02/2009 08:36:03 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 12/02/2009 08:36:03 PM, Serialize complete at 12/02/2009 08:36:03 PM, S/MIME Sign failed at 12/02/2009 08:36:03 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 12/02/2009 18:42:39, Serialize complete at 12/02/2009 18:42:39 Message-ID: Date: Wed, 2 Dec 2009 20:42:38 -0500 Content-Type: multipart/alternative; boundary="=_alternative 0008CB8785257681_=" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [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: Thu, 03 Dec 2009 01:42:56 -0000 This is a multipart message in MIME format. --=_alternative 0008CB8785257681_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SWYgdGhpcyBwcm9wb3NhbCBpcyBhY2NlcHRlZCwgSSBjb21taXQgdG8gcmV2aWV3IGl0Lg0KDQpT Y290dCBNb29uZW4gKHNtb29uZW5AdXMuaWJtLmNvbSkNCnovT1MgQ29tbXVuaWNhdGlvbnMgU2Vy dmVyIFRDUC9JUCBEZXZlbG9wbWVudA0KaHR0cDovL3d3dy5saW5rZWRpbi5jb20vaW4vc21vb25l bg0KDQoNCg0KRnJvbToNCllhcm9uIFNoZWZmZXIgPHlhcm9uZkBjaGVja3BvaW50LmNvbT4NClRv Og0KImlwc2VjQGlldGYub3JnIiA8aXBzZWNAaWV0Zi5vcmc+DQpEYXRlOg0KMTEvMjkvMjAwOSAx Mjo0MSBQTQ0KU3ViamVjdDoNCltJUHNlY10gUHJvcG9zZWQgd29yayBpdGVtOiBJS0UvSVBzZWMg aGlnaCBhdmFpbGFiaWxpdHkgYW5kIGxvYWQgc2hhcmluZw0KDQoNCg0KVGhpcyB3b3JrIGl0ZW0g d2lsbCBkZWZpbmUgdGhlIHByb2JsZW0gc3RhdGVtZW50IGFuZCByZXF1aXJlbWVudHMgZm9yIGEg DQpzb2x1dGlvbiB0aGF0IGFsbG93cyBpbnRlcm9wZXJhYmxlIEhBL0xTIGRldmljZSBncm91cHMu IE1peGVkLXZlbmRvciANCmNsdXN0ZXJzIGFyZSBzcGVjaWZpY2FsbHkgb3V0IG9mIHNjb3BlOyBi dXQgc2luZ2xlLXZlbmRvciBjbHVzdGVycyBzaG91bGQgDQpiZSBmdWxseSBpbnRlcm9wZXJhYmxl IHdpdGggb3RoZXIgdmVuZG9yc+KAmSBkZXZpY2VzIG9yIGNsdXN0ZXJzLiBUaGUgbWFpbiANCmNo YWxsZW5nZSBpcyB0byBvdmVyY29tZSB0aGUgc3RyaWN0IHVzZSBvZiBzZXF1ZW5jZSBudW1iZXJz IGluIGJvdGggSVBzZWMgDQphbmQgSUtFLCBpbiBIQSBhbmQgTFMgc2NlbmFyaW9zLiBGb2xsb3dp bmcgdGhlIEhpcm9zaGltYSBkaXNjdXNzaW9uLCB0aGUgDQpXSSBpcyBpbml0aWFsbHkgZm9jdXNl ZCBvbiBkZWZpbmluZyB0aGUgcHJvYmxlbSwgcmF0aGVyIHRoYW4gYSBwYXJ0aWN1bGFyIA0Kc29s dXRpb24uDQogDQpQcm9wb3NlZCBzdGFydGluZyBwb2ludDogDQpodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaWQvZHJhZnQtbmlyLWlwc2VjbWUtaXBzZWNoYS0wMC50eHQuDQogDQpQbGVhc2UgcmVwbHkg dG8gdGhlIGxpc3Q6DQogDQotIElmIHRoaXMgcHJvcG9zYWwgaXMgYWNjZXB0ZWQgYXMgYSBXRyB3 b3JrIGl0ZW0sIGFyZSB5b3UgY29tbWl0dGluZyB0byANCnJldmlldyBtdWx0aXBsZSB2ZXJzaW9u cyBvZiB0aGUgZHJhZnQ/DQotIEFyZSB5b3Ugd2lsbGluZyB0byBjb250cmlidXRlIHRleHQgdG8g dGhlIGRyYWZ0Pw0KLSBXb3VsZCB5b3UgbGlrZSB0byBjby1hdXRob3IgaXQ/DQogDQpQbGVhc2Ug YWxzbyByZXBseSB0byB0aGUgbGlzdCBpZjoNCiANCi0gWW91IGJlbGlldmUgdGhpcyBpcyBOT1Qg YSByZWFzb25hYmxlIGFjdGl2aXR5IGZvciB0aGUgV0cgdG8gc3BlbmQgdGltZSANCm9uLg0KIA0K SWYgdGhpcyBpcyB0aGUgY2FzZSwgcGxlYXNlIGV4cGxhaW4geW91ciBwb3NpdGlvbi4gRG8gbm90 IGV4cGxvcmUgdGhlIGZpbmUgDQp0ZWNobmljYWwgZGV0YWlscyAod2hpY2ggd2lsbCBjaGFuZ2Ug YW55d2F5LCBvbmNlIHRoZSBXRyBnZXRzIGhvbGQgb2YgdGhlIA0KZHJhZnQpOyBpbnN0ZWFkIGV4 cGxhaW4gd2h5IHRoaXMgaXMgdW5pbnRlcmVzdGluZyBmb3IgdGhlIFdHIG9yIGZvciB0aGUgDQpp bmR1c3RyeSBhdCBsYXJnZS4gQWxzbywgcGxlYXNlIG1hcmsgdGhlIHRpdGxlIGNsZWFybHkgKGUu Zy4gIkRFUzQwLWV4cG9ydCANCmluIElQc2VjIC0gTk8hIikuX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCklQc2VjIG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCg0KDQoN Cg== --=_alternative 0008CB8785257681_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklmIHRoaXMgcHJvcG9zYWwgaXMg YWNjZXB0ZWQsIEkgY29tbWl0DQp0byByZXZpZXcgaXQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpTY290dCBNb29uZW4gKHNtb29uZW5AdXMuaWJtLmNv bSk8YnI+DQp6L09TIENvbW11bmljYXRpb25zIFNlcnZlciBUQ1AvSVAgRGV2ZWxvcG1lbnQ8YnI+ DQo8L2ZvbnQ+PGEgaHJlZj1odHRwOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9zbW9vbmVuPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5odHRwOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9zbW9v bmVuPC9mb250PjwvYT4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1z ZXJpZiI+RnJvbTo8L2ZvbnQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPllh cm9uIFNoZWZmZXIgJmx0O3lhcm9uZkBjaGVja3BvaW50LmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlm Ij5Ubzo8L2ZvbnQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O2lw c2VjQGlldGYub3JnJnF1b3Q7ICZsdDtpcHNlY0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlm Ij5EYXRlOjwvZm9udD4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MTEvMjkv MjAwOSAxMjo0MSBQTTwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPjxmb250IHNpemU9MSBj b2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPlN1YmplY3Q6PC9mb250Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bSVBzZWNdIFByb3Bvc2VkIHdvcmsgaXRlbTogSUtF L0lQc2VjDQpoaWdoIGF2YWlsYWJpbGl0eSBhbmQgbG9hZCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtzaGFyaW5nPC9mb250PjwvdGFibGU+DQo8YnI+DQo8aHIgbm9zaGFkZT4NCjxicj4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlRoaXMgd29yayBpdGVtIHdp bGwgZGVmaW5lIHRoZSBwcm9ibGVtDQpzdGF0ZW1lbnQgYW5kIHJlcXVpcmVtZW50cyBmb3IgYSBz b2x1dGlvbiB0aGF0IGFsbG93cyBpbnRlcm9wZXJhYmxlIEhBL0xTDQpkZXZpY2UgZ3JvdXBzLiBN aXhlZC12ZW5kb3IgY2x1c3RlcnMgYXJlIHNwZWNpZmljYWxseSBvdXQgb2Ygc2NvcGU7IGJ1dA0K c2luZ2xlLXZlbmRvciBjbHVzdGVycyBzaG91bGQgYmUgZnVsbHkgaW50ZXJvcGVyYWJsZSB3aXRo IG90aGVyIHZlbmRvcnPigJkNCmRldmljZXMgb3IgY2x1c3RlcnMuIFRoZSBtYWluIGNoYWxsZW5n ZSBpcyB0byBvdmVyY29tZSB0aGUgc3RyaWN0IHVzZSBvZg0Kc2VxdWVuY2UgbnVtYmVycyBpbiBi b3RoIElQc2VjIGFuZCBJS0UsIGluIEhBIGFuZCBMUyBzY2VuYXJpb3MuIEZvbGxvd2luZw0KdGhl IEhpcm9zaGltYSBkaXNjdXNzaW9uLCB0aGUgV0kgaXMgaW5pdGlhbGx5IGZvY3VzZWQgb24gZGVm aW5pbmcgdGhlIHByb2JsZW0sDQpyYXRoZXIgdGhhbiBhIHBhcnRpY3VsYXIgc29sdXRpb24uPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+UHJvcG9zZWQgc3RhcnRpbmcgcG9p bnQ6IDwvZm9udD48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtbmlyLWlw c2VjbWUtaXBzZWNoYS0wMC50eHQiPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+aHR0 cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LW5pci1pcHNlY21lLWlwc2VjaGEtMDAudHh0PC9m b250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPi48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5QbGVhc2UgcmVwbHkgdG8gdGhlIGxpc3Q6PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+LSBJZiB0aGlzIHByb3Bvc2FsIGlzIGFjY2Vw dGVkIGFzIGENCldHIHdvcmsgaXRlbSwgYXJlIHlvdSBjb21taXR0aW5nIHRvIHJldmlldyBtdWx0 aXBsZSB2ZXJzaW9ucyBvZiB0aGUgZHJhZnQ/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+LSBBcmUgeW91IHdpbGxpbmcgdG8gY29udHJpYnV0ZSB0ZXh0DQp0byB0 aGUgZHJhZnQ/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+LSBX b3VsZCB5b3UgbGlrZSB0byBjby1hdXRob3IgaXQ/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+UGxlYXNlIGFsc28gcmVwbHkgdG8gdGhlIGxpc3QgaWY6PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+LSBZb3UgYmVsaWV2ZSB0aGlzIGlzIE5PVCBhIHJl YXNvbmFibGUNCmFjdGl2aXR5IGZvciB0aGUgV0cgdG8gc3BlbmQgdGltZSBvbi48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5JZiB0aGlzIGlzIHRoZSBjYXNlLCBwbGVhc2Ug ZXhwbGFpbg0KeW91ciBwb3NpdGlvbi4gRG8gbm90IGV4cGxvcmUgdGhlIGZpbmUgdGVjaG5pY2Fs IGRldGFpbHMgKHdoaWNoIHdpbGwgY2hhbmdlDQphbnl3YXksIG9uY2UgdGhlIFdHIGdldHMgaG9s ZCBvZiB0aGUgZHJhZnQpOyBpbnN0ZWFkIGV4cGxhaW4gd2h5IHRoaXMgaXMNCnVuaW50ZXJlc3Rp bmcgZm9yIHRoZSBXRyBvciBmb3IgdGhlIGluZHVzdHJ5IGF0IGxhcmdlLiBBbHNvLCBwbGVhc2Ug bWFyaw0KdGhlIHRpdGxlIGNsZWFybHkgKGUuZy4gJnF1b3Q7REVTNDAtZXhwb3J0IGluIElQc2Vj IC0gTk8hJnF1b3Q7KS48L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklQc2VjIG1haWxpbmcgbGlzdDxicj4N CklQc2VjQGlldGYub3JnPGJyPg0KPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYzwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQg c2l6ZT0yPjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPg0K --=_alternative 0008CB8785257681_=-- From smoonen@us.ibm.com Wed Dec 2 17:42: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 EB3093A69A0; Wed, 2 Dec 2009 17:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.138 X-Spam-Level: X-Spam-Status: No, score=-6.138 tagged_above=-999 required=5 tests=[AWL=0.460, 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 8QjIkv66UTWU; Wed, 2 Dec 2009 17:42:55 -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 C38083A680A; Wed, 2 Dec 2009 17:42:55 -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 nB31bPg9018773; Wed, 2 Dec 2009 18:37:25 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id nB31ghwr249916; Wed, 2 Dec 2009 18:42:43 -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 nB31geSl018708; Wed, 2 Dec 2009 18:42:40 -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 nB31ge2S018702; Wed, 2 Dec 2009 18:42:40 -0700 In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> To: Yaron Sheffer MIME-Version: 1.0 X-KeepSent: AE22183D:FC5DD5C7-85257681:0008AB37; 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 12/02/2009 08:35:26 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 12/02/2009 08:35:26 PM, Serialize complete at 12/02/2009 08:35:26 PM, S/MIME Sign failed at 12/02/2009 08:35:26 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 12/02/2009 18:42:39, Serialize complete at 12/02/2009 18:42:39 Message-ID: Date: Wed, 2 Dec 2009 20:42:38 -0500 Content-Type: multipart/alternative; boundary="=_alternative 0008BCD385257681_=" Cc: "ipsec@ietf.org" , ipsec-bounces@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: Thu, 03 Dec 2009 01:42:57 -0000 This is a multipart message in MIME format. --=_alternative 0008BCD385257681_= Content-Type: text/plain; charset="US-ASCII" If this proposal is accepted, I commit to review it. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Yaron Sheffer To: "ipsec@ietf.org" Date: 11/29/2009 12:26 PM Subject: [IPsec] Proposed work item: Labelled IPsec 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 envisioned that this will be used by modern high-security operating systems, that go beyond the currently supported Multilevel Security (MLS). Proposed starting point: http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-context-01 and http://tools.ietf.org/html/draft-jml-ipsec-ikev1-security-context-01. 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 --=_alternative 0008BCD385257681_= Content-Type: text/html; charset="US-ASCII"
If this proposal is accepted, I commit to review it.

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


From: Yaron Sheffer <yaronf@checkpoint.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Date: 11/29/2009 12:26 PM
Subject: [IPsec] Proposed work item: Labelled IPsec




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 envisioned that this will be used by modern high-security operating systems, that go beyond the currently supported Multilevel Security (MLS).

Proposed starting point: http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-context-01 and http://tools.ietf.org/html/draft-jml-ipsec-ikev1-security-context-01.
 
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

--=_alternative 0008BCD385257681_=-- From smoonen@us.ibm.com Wed Dec 2 17:42: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 036313A680A; Wed, 2 Dec 2009 17:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=0.383, 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 2uXV5lPdY-Aw; Wed, 2 Dec 2009 17:42:55 -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 C59013A699E; Wed, 2 Dec 2009 17:42:55 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nB31bG3K030104; Wed, 2 Dec 2009 18:37:16 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id nB31gh8k159748; Wed, 2 Dec 2009 18:42:43 -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 nB31geR4018705; Wed, 2 Dec 2009 18:42:40 -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 nB31ge2R018702; Wed, 2 Dec 2009 18:42:40 -0700 In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EF@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EF@il-ex01.ad.checkpoint.com> To: Yaron Sheffer MIME-Version: 1.0 X-KeepSent: F5A9DCE7:F9E144D6-85257681:0008943B; 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 12/02/2009 08:34:03 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 12/02/2009 08:34:03 PM, Serialize complete at 12/02/2009 08:34:03 PM, S/MIME Sign failed at 12/02/2009 08:34:03 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 12/02/2009 18:42:39, Serialize complete at 12/02/2009 18:42:39 Message-ID: Date: Wed, 2 Dec 2009 20:42:38 -0500 Content-Type: multipart/alternative; boundary="=_alternative 00089C6985257681_=" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [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: Thu, 03 Dec 2009 01:42:57 -0000 This is a multipart message in MIME format. --=_alternative 00089C6985257681_= Content-Type: text/plain; charset="US-ASCII" If this proposal is accepted I commit to review it. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Yaron Sheffer To: "ipsec@ietf.org" Date: 11/29/2009 12:26 PM Subject: [IPsec] Proposed work item: Failure detection in IKEv2 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. 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 --=_alternative 00089C6985257681_= Content-Type: text/html; charset="US-ASCII"
If this proposal is accepted I commit to review it.


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


From: Yaron Sheffer <yaronf@checkpoint.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Date: 11/29/2009 12:26 PM
Subject: [IPsec] Proposed work item: Failure detection in IKEv2




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.
 
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

--=_alternative 00089C6985257681_=-- From manav.bhatia@alcatel-lucent.com Wed Dec 2 18:28: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 5880E3A6926 for ; Wed, 2 Dec 2009 18:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.751, 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 T8uNRF8OOHqn for ; Wed, 2 Dec 2009 18:28:12 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by core3.amsl.com (Postfix) with ESMTP id A30793A6872 for ; Wed, 2 Dec 2009 18:28:12 -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 nB32S1Gt010128; Wed, 2 Dec 2009 20:28: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 nB32RxY3009309; Wed, 2 Dec 2009 20:28:01 -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 nB32XaBx014915; Thu, 3 Dec 2009 10:33:37 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 3 Dec 2009 07:57:58 +0530 From: "Bhatia, Manav (Manav)" To: Yaron Sheffer , "ipsec@ietf.org" Date: Thu, 3 Dec 2009 07:56:42 +0530 Thread-Topic: Proposed work item: WESP extensibility - YES Thread-Index: AcpxFkxGdx4Es24CRa+VhZZQCynYUgCqA6+w Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB3120E55@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> In-Reply-To: <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: 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 Subject: Re: [IPsec] Proposed work item: WESP extensibility - YES 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, 03 Dec 2009 02:28:13 -0000 [mail snipped] > - If this proposal is accepted as a WG work item,=20 > are you committing to review multiple versions of the draft? Yes > - Are you willing to contribute text to the draft? Yes > - Would you like to co-author it? Yes I believe the OAM extension described in the draft is useful and I would li= ke to see this discussed further in the WG. Cheers, Manav From denghui02@gmail.com Thu Dec 3 06:47: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 1CC8728C16C for ; Thu, 3 Dec 2009 06:47:15 -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 f5oVcrZ-guFE for ; Thu, 3 Dec 2009 06:47:14 -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 17EBC28C169 for ; Thu, 3 Dec 2009 06:47:14 -0800 (PST) Received: by pwi5 with SMTP id 5so409261pwi.29 for ; Thu, 03 Dec 2009 06:47:03 -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=34Uyp57O778O0xARzsLF0TDXSj+JawQfZOE1Fp/njqg=; b=LPK3e1y+AFZygmlszl9w+GrIMqMoxytDKeQDLAQAhOKN97bTdpwSi5i3NspCjvyGep WhD07FXDCOL4OVp6UmG0rDiq9G3XAftHugz8xzh1vvrrCAf4sS9vkA/vmx0GzQGN0Hly 4UDL4ddTAlwZsfvz0jxTRa3Vgw6tfb1cPFwIc= 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=FaOBTw2awemWnGyGDzLJFSzRWvGU8lonTTJqBA426bSpsbRIMmuCLgmMHFuO2SzELg 8PibHEc5Wlm9I277a9g9h94DI7IpS17Yasmy7T+Dy3GNMyemE+VIcIqlG2iqdQQRSnnH +3A+5YthawJdlAOgr0MzkGOPyrhOqpD/sHfSY= MIME-Version: 1.0 Received: by 10.140.178.7 with SMTP id a7mr112393rvf.43.1259851623158; Thu, 03 Dec 2009 06:47:03 -0800 (PST) In-Reply-To: <201312521538385754@unknownmsgid> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <6F892B93-1B06-44DE-852F-A7C2F2799717@checkpoint.com> <1d38a3350912010527w30a6779cycd0cfad5d628e596@mail.gmail.com> <201312521538385754@unknownmsgid> Date: Thu, 3 Dec 2009 22:47:03 +0800 Message-ID: <1d38a3350912030647l2c1db5f2u2440fb0ceef02a54@mail.gmail.com> From: Hui Deng To: Alper Yegin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [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: Thu, 03 Dec 2009 14:47:15 -0000 Hi, Alper Not all of them. -Hui 2009/12/2 Alper Yegin : > Hi Hui, > > Are all 4 motivations below part of 3gpp discussion? > > Alper > > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Hui Deng >> Sent: Tuesday, December 01, 2009 3:28 PM >> To: Yoav Nir >> Cc: ipsec@ietf.org; Alper Yegin >> Subject: Re: [IPsec] Proposed work item: Childless IKE SA >> >> During the last 3GPP SA3 meeting, such requirement about HNB has also >> been approved as well. >> >> thanks >> >> -Hui >> >> 2009/12/1 Yoav Nir : >> > There were several motivations listed for childless IKE SAs. >> > =A0- remote access, where you create an IKE SA when the user wants to >> connect, and only create child SAs in response to traffic >> > =A0- authentication only over a physically secure network (not >> necessarily EAP, but I think this is the use case you referred to) >> > =A0- Location awareness (as in the SecureBeacon draft) >> > =A0- Some "weird" uses such as liveness checks without IPsec, NAT >> detection, etc. >> > >> > >> > On Dec 1, 2009, at 2:29 PM, Alper Yegin wrote: >> > >> >> One of the (or main?) motivations of this proposal is to turn IKEv2 >> into >> >> "EAP-based network access authentication protocol". =A0RFC 5191 is >> designed >> >> for that purpose, and I'm not sure if we need to twist a protocol >> for the >> >> same purpose. >> >> >> >> >> >> >> >>> -----Original Message----- >> >>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >> Behalf >> >>> Of Yaron Sheffer >> >>> Sent: Sunday, November 29, 2009 7:21 PM >> >>> To: ipsec@ietf.org >> >>> Subject: [IPsec] Proposed work item: Childless IKE SA >> >>> >> >>> 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- >> >>> childless-01.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 >> >> >> >> _______________________________________________ >> >> 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 >> > >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From alper.yegin@yegin.org Thu Dec 3 06:54: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 41EFD3A6A36 for ; Thu, 3 Dec 2009 06:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.531 X-Spam-Level: X-Spam-Status: No, score=-0.531 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_SORBS_WEB=0.619] 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 Facz5jAq-era for ; Thu, 3 Dec 2009 06:54:12 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 5389A3A684A for ; Thu, 3 Dec 2009 06:54:12 -0800 (PST) Received: from LENOVO (dsl.static.85-105-43069.ttnet.net.tr [85.105.168.61]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MXrmZ-1NaEnh2VT5-00WpRz; Thu, 03 Dec 2009 09:54:02 -0500 From: "Alper Yegin" To: "'Hui Deng'" References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <6F892B93-1B06-44DE-852F-A7C2F2799717@checkpoint.com> <1d38a3350912010527w30a6779cycd0cfad5d628e596@mail.gmail.com> <201312521538385754@unknownmsgid> <1d38a3350912030647l2c1db5f2u2440fb0ceef02a54@mail.gmail.com> In-Reply-To: <1d38a3350912030647l2c1db5f2u2440fb0ceef02a54@mail.gmail.com> Date: Thu, 3 Dec 2009 16:53:55 +0200 Message-ID: <067601ca7428$7348dfb0$59da9f10$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp0J31opI7O7OFkSNKUwUY4+OAjWAAANr2w Content-Language: en-us X-Provags-ID: V01U2FsdGVkX18caev3qrX/M6IGewH13BktAOB7zW8+ZWvZzWs TlWRqqUdKOqmoZQN5cchw+mKkYQjtqLeWCFOO/vek1mHMzONpH XJWHTZ8F86mNsNmH/p2PQ== Cc: ipsec@ietf.org, 'Yoav Nir' Subject: Re: [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: Thu, 03 Dec 2009 14:54:13 -0000 Hi Hui, I think it'd also be very useful if you indicate which ones are. Thanks. Alper > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Hui Deng > Sent: Thursday, December 03, 2009 4:47 PM > To: Alper Yegin > Cc: ipsec@ietf.org; Yoav Nir > Subject: Re: [IPsec] Proposed work item: Childless IKE SA >=20 > Hi, Alper >=20 > Not all of them. >=20 > -Hui >=20 > 2009/12/2 Alper Yegin : > > Hi Hui, > > > > Are all 4 motivations below part of 3gpp discussion? > > > > Alper > > > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > >> Of Hui Deng > >> Sent: Tuesday, December 01, 2009 3:28 PM > >> To: Yoav Nir > >> Cc: ipsec@ietf.org; Alper Yegin > >> Subject: Re: [IPsec] Proposed work item: Childless IKE SA > >> > >> During the last 3GPP SA3 meeting, such requirement about HNB has > also > >> been approved as well. > >> > >> thanks > >> > >> -Hui > >> > >> 2009/12/1 Yoav Nir : > >> > There were several motivations listed for childless IKE SAs. > >> > =A0- remote access, where you create an IKE SA when the user = wants > to > >> connect, and only create child SAs in response to traffic > >> > =A0- authentication only over a physically secure network (not > >> necessarily EAP, but I think this is the use case you referred to) > >> > =A0- Location awareness (as in the SecureBeacon draft) > >> > =A0- Some "weird" uses such as liveness checks without IPsec, NAT > >> detection, etc. > >> > > >> > > >> > On Dec 1, 2009, at 2:29 PM, Alper Yegin wrote: > >> > > >> >> One of the (or main?) motivations of this proposal is to turn > IKEv2 > >> into > >> >> "EAP-based network access authentication protocol". =A0RFC 5191 = is > >> designed > >> >> for that purpose, and I'm not sure if we need to twist a = protocol > >> for the > >> >> same purpose. > >> >> > >> >> > >> >> > >> >>> -----Original Message----- > >> >>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > >> Behalf > >> >>> Of Yaron Sheffer > >> >>> Sent: Sunday, November 29, 2009 7:21 PM > >> >>> To: ipsec@ietf.org > >> >>> Subject: [IPsec] Proposed work item: Childless IKE SA > >> >>> > >> >>> 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- > >> >>> childless-01.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 > >> >> > >> >> _______________________________________________ > >> >> 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 > >> > > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From briansw@microsoft.com Thu Dec 3 09:16: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 20D3B3A6801 for ; Thu, 3 Dec 2009 09:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 41Dinc7MKwZ3 for ; Thu, 3 Dec 2009 09:16:50 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 790403A6811 for ; Thu, 3 Dec 2009 09:16:50 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 3 Dec 2009 09:17:10 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Thu, 3 Dec 2009 09:16:28 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Thu, 3 Dec 2009 09:16:26 -0800 From: Brian Swander To: "ipsec@ietf.org" Thread-Topic: Proposed work item: WESP extensibility Thread-Index: AcpxFkxGdx4Es24CRa+VhZZQCynYUgDJeQXA Date: Thu, 3 Dec 2009 17:16:25 +0000 Message-ID: <5E38DBF64E732C4C98512C53E1B14DDC2999E319@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_5E38DBF64E732C4C98512C53E1B14DDC2999E319TK5EX14MBXW653w_" MIME-Version: 1.0 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: Thu, 03 Dec 2009 17:16:57 -0000 --_000_5E38DBF64E732C4C98512C53E1B14DDC2999E319TK5EX14MBXW653w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (Apologies if this is a dupe. I sent it out yesterday, but it still hasn't= shown up on the list yet, so I figured I better resend from a different ac= count). Here is another WESP extension that we are interested in. Packet Contents Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (PC) | Length | ContentType |Data (variable)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data(variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: PacketContents (PC) option identifier (value TBD) Length: 2 octets ContentType: type of the packet contents description Data: depends on the ContentType The purpose of this option is to exchange information about the contents of= the payload data to intermediaries (network infrastructure). This can be used = both with full payload encryption or with just integrity. When the entire payload data is encrypted, some intermediaries, for instance packet filtere= rs and deep content inspectors, lose the ability to perform their function. With this extension, the end host can append the PacketContents option to describe the contents of the packet for the benefit of intermediary devices= . There are many possible uses for this. For instance, the endhost could hav= e a classification scheme that maps HTTP to 1, LDAP to 2, SMB to this class o= f server to 3, SMB to another class of server to 4, etc. Hence there needn'= t be direct information disclosure of the encrypted data types to an attacker who didn't have access to the policy. Another possible use would be to expose the full URL for the request by dup= licating it into the option. An example of a use for this with integrity only encapsulation is to flag t= hings that are difficult to deduce by an intermediary. For instance, RPC c= ommonly runs on dynamic ports. So we can flag the RPC packets with a speci= fic tag. Clearly this puts trust in the end-system to apply the correct markings. B= ut in a fully encrypted end-to-end environment, the intermediaries must tru= st the end systems somewhat anyway. And for integrity-only mode, these mark= ings could be treated as hints to aid parsing. brian From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Sunday, November 29, 2009 9:21 AM To: ipsec@ietf.org Subject: [IPsec] Proposed work item: WESP extensibility 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_5E38DBF64E732C4C98512C53E1B14DDC2999E319TK5EX14MBXW653w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(Apologies if this is a dupe.  I sent it out yesterday,= but it still hasn’t shown up on the list yet, so I figured I better resend f= rom a different account).

 

Here is another WESP extension that we are interested in.  
Packet Contents Option

   0            &n= bsp;      1            &n= bsp;      2            &n= bsp;      3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
   |  Type (PC)    |    Length     |  ContentType  |Data (variable)|<= br>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
   |            &n= bsp;         Data(variable)          &= nbsp;           &nbs= p;    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+=

  Type: PacketContents (PC) option identifier (value TBD)
  Length: 2 octets
  ContentType:  type of the packet contents description
  Data: depends on the ContentType

The purpose of this option is to exchange information about the contents of the=
payload data to intermediaries (network infrastructure).  This can be = used both
with full payload encryption or with just integrity.   When the entire 
payload data is encrypted, some intermediaries, for instance packet filterers 
and deep content inspectors, lose the ability to perform their function. With this extension, the end host can append the PacketContents option to  
describe the contents of the packet for the benefit of intermediary devices= .
 
There are many possible uses for this.  For instance, the endhost coul= d have 
a classification scheme that maps HTTP to 1, LDAP to 2, SMB to this class of 
server to 3, SMB to another class of server to 4, etc.   Hence th= ere needn't
be direct information disclosure of the encrypted data types to an attacker who didn't have access to the policy.
 
Another possible use would be to expose the full URL for the request by duplicating 
it into the option.
 
An example of a use for this with integrity only encapsulation is to flag thin= gs that are difficult to deduce by an intermediary.  For instance, RPC commonly runs on dynamic ports.  So we can flag the= RPC packets with a specific tag.
 
Clearly this puts trust in the end-system to apply the correct markings.  But = in a fully encrypted end-to-end environment, the intermediaries must trust = the end systems somewhat anyway. And for integrity-only mode, these markin= gs could be treated as hints to aid parsing.
 
 
brian

 

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Yaron Sheffer
Sent: Sunday, November 29, 2009 9:21 AM
To: ipsec@ietf.org
Subject: [IPsec] Proposed work item: WESP extensibility

 

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, a= re you committing to review multiple versions of the draft?

- Are you willing to contribute text to the draft?<= o:p>

- 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 g= ets 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!").

 

--_000_5E38DBF64E732C4C98512C53E1B14DDC2999E319TK5EX14MBXW653w_-- From sheila.frankel@nist.gov Thu Dec 3 09:38: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 AADFD28C150 for ; Thu, 3 Dec 2009 09:38:52 -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 9nMABY86Y4Po for ; Thu, 3 Dec 2009 09:38:51 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id A30C43A67FA for ; Thu, 3 Dec 2009 09:38:51 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id nB3HcSXI021707; Thu, 3 Dec 2009 12:38:28 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Thu, 3 Dec 2009 12:38:16 -0500 From: "Frankel, Sheila E." To: "ipsec@ietf.org" Date: Thu, 3 Dec 2009 12:38:28 -0500 Thread-Topic: Resolving Roadmap Issue #111 Thread-Index: Acp0P2xMCNQlGFUBRvSUWotgntlJYA== Message-ID: 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_D7A0423E5E193F40BE6E94126930C493078C30306BMBCLUSTERxcha_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: "suresh.krishnan@ericsson.com" , Paul Hoffman , Tero Kivinen Subject: [IPsec] Resolving Roadmap Issue #111 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, 03 Dec 2009 17:38:52 -0000 --_000_D7A0423E5E193F40BE6E94126930C493078C30306BMBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If there are no further comments, this issue will be closed. Issue #111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3? =3D=3D> As a result of Tero's comments, added #2 below and revised #3. #1 = and #4 remain unchanged from the previous email sent to the list. Proposed changes to Roadmap doc: 1) Add text to section 5.4 (Combined Mode Algorithms) Additional text (unchanged from previous email): Some IKEv1 implementations have added the capability to negotiate combined mode algorithms for use in IPsec SAs; these implementations do not include the capability to use combined mode algorithms to protect IKE SAs. Since combined mode algorithms are not a feature of IPsec-v2, these IKEv1 implementations are used in conjunction with IPsec-v3. IANA numbers for combined mode algorithms have been added to the IKEv1 regist= ry. 2) Add text to section 5.3.4 (RFC 4543, The use of GMAC in IPsec ESP and AH= ): (added since previous email) AES-GMAC cannot be used by IKEv2 to protect its own SAs, since IKEv2 traffic requires encryption. 3) Change IKEv2 requirements level Requirements levels for AES-GMAC: old IKEv2 - optional new IKEv2 - N/A 4) Move RFC 4543 to section on combined mode algorithms, since it has 2 ver= sions: classic integ prot and also combined mode --_000_D7A0423E5E193F40BE6E94126930C493078C30306BMBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If there are no furthe= r comments, this issue will be closed.

 

Issue #111: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3?

 

=3D=3D> As a result= of Tero's comments, added #2 below and revised #3.  #1 and #4 remain unchanged f= rom the previous email sent to the list.

 

Proposed changes to Ro= admap doc:

 

1) Add text to section= 5.4 (Combined Mode Algorithms)

 

Additional text (uncha= nged from previous email):

   Some IKEv= 1 implementations have added the capability to negotiate

   combined = mode algorithms for use in IPsec SAs; these implementations

   do not in= clude the capability to use combined mode algorithms to protect=

   IKE SAs. = Since combined mode algorithms are not a feature of IPsec-v2,

   these IKE= v1 implementations are used in conjunction with IPsec-v3.  IANA

   numbers f= or combined mode algorithms have been added to the IKEv1 registry.<= /span>

 

2) Add text to section= 5.3.4 (RFC 4543, The use of GMAC in IPsec ESP and AH):

   &nbs= p;  (added since previous email)

   AES-GMAC = cannot be used by IKEv2 to protect its own SAs, since IKEv2

   traffic requires encryption.

 

3) Change IKEv2 requir= ements level

   &nbs= p;    Requirements levels for AES-GMAC:

   &nbs= p;            old IKEv2 - optional

   &nbs= p;            new IKEv2 - N/A

 

4) Move RFC 4543 to se= ction on combined mode algorithms, since it has 2 versions: classic integ prot an= d also combined mode

 

 

--_000_D7A0423E5E193F40BE6E94126930C493078C30306BMBCLUSTERxcha_-- From sheila.frankel@nist.gov Thu Dec 3 09:41: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 8005728C199 for ; Thu, 3 Dec 2009 09:41:41 -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 tk8LUikWRAnb for ; Thu, 3 Dec 2009 09:41:40 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 5179428C150 for ; Thu, 3 Dec 2009 09:41:40 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id nB3HfFnM002867; Thu, 3 Dec 2009 12:41:15 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Thu, 3 Dec 2009 12:41:14 -0500 From: "Frankel, Sheila E." To: "ipsec@ietf.org" Date: Thu, 3 Dec 2009 12:41:14 -0500 Thread-Topic: Resolving Roadmap Issue #112 Thread-Index: Acp0P88hKXZ31uD/TH6U9RyUWNlrVw== Message-ID: 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_D7A0423E5E193F40BE6E94126930C493078C30306CMBCLUSTERxcha_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: Yaron, "suresh.krishnan@ericsson.com" , Tero Kivinen , Paul Hoffman Subject: [IPsec] Resolving Roadmap Issue #112 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, 03 Dec 2009 17:41:41 -0000 --_000_D7A0423E5E193F40BE6E94126930C493078C30306CMBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If there are no further comments, this issue will be closed. Issue #112: Truncation of SHA-1 ICVs =3D=3D> Several people commented that the non-truncated versions of HMAC-SH= A-1 and HMAC-MD5 are only intended to be used for Fibre Channel traffic. Th= us, IKEv2 can only negotiate these versions for that use, but not for IKEv2= or IPsec-v3 SAs. The revised text (below) reflects these comments. Proposed change to Roadmap doc: Add text to Section 5.3 (Integrity-Protection Algorithms) Additional text (revised since previous email): Some of these algorithms generate a fixed-length ICV, which is truncated when it is included in an IPsec-protected packet. For example, standard HMAC-SHA-1 generates a 160-bit ICV, which is truncated to 96 bits when i= t is used to provide integrity-protection to an ESP or AH packet. The individual RFC descriptions mention those algorithms that are truncated. When these algorithms are used to protect IKEv2 SAs, they are also truncated. For IKEv1, HMAC-SHA-1 and HMAC-MD5 are negotiated by requesti= ng the hash algorithms SHA-1 and MD5, respectively; these algorithms are no= t truncated when used to protect an IKEv1 SA. For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry contains values for both the truncated version a= nd the standard non-truncated version; thus, IKEv2 has the capability to negotiate either version of the algorithm. However, only the truncated version is used for IKEv2 SAs and for IPsec SAs. The non-truncated versi= on is reserved for use by the Fibre Channel protocol [RFC4595]. For the oth= er algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC and HMAC-RIPEMD), o= nly the truncated version can be used for both IKEv2 and IPsec-v3 SAs. --_000_D7A0423E5E193F40BE6E94126930C493078C30306CMBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If there are no furthe= r comments, this issue will be closed.

 

Issue #112: Truncation= of SHA-1 ICVs

 

=3D=3D> Several peo= ple commented that the non-truncated versions of HMAC-SHA-1 and HMAC-MD5 are on= ly intended to be used for Fibre Channel traffic. Thus, IKEv2 can only negotia= te these versions for that use, but not for IKEv2 or IPsec-v3 SAs. The revised text (below) reflects these comments.

 

Proposed change to Roa= dmap doc:

 

Add text to Section 5.= 3 (Integrity-Protection Algorithms)

 

Additional text (revis= ed since previous email):

   Some of t= hese algorithms generate a fixed-length ICV, which is truncated

   when it i= s included in an IPsec-protected packet. For example, standard

   HMAC-SHA-= 1 generates a 160-bit ICV, which is truncated to 96 bits when it=

   is used t= o provide integrity-protection to an ESP or AH packet. The

   individua= l RFC descriptions mention those algorithms that are truncated.=

   When thes= e algorithms are used to protect IKEv2 SAs, they are also

   truncated= . For IKEv1, HMAC-SHA-1 and HMAC-MD5 are negotiated by requesting

   the hash = algorithms SHA-1 and MD5, respectively; these algorithms are not

   truncated= when used to protect an IKEv1 SA. For HMAC-SHA-1 and HMAC-MD5, =

   the IKEv2= IANA registry contains values for both the truncated version and

   the stand= ard non-truncated version; thus, IKEv2 has the capability to =

   negotiate= either version of the algorithm.  However, only the truncated

   version i= s used for IKEv2 SAs and for IPsec SAs. The non-truncated version <= /p>

   is reserv= ed for use by the Fibre Channel protocol [RFC4595]. For the other

   algorithm= s (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC and HMAC-RIPEMD), only

   the trunc= ated version can be used for both IKEv2 and IPsec-v3 SAs.

 

 

--_000_D7A0423E5E193F40BE6E94126930C493078C30306CMBCLUSTERxcha_-- From sheila.frankel@nist.gov Thu Dec 3 09:43: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 CE02F28C192 for ; Thu, 3 Dec 2009 09:43:05 -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 S6vXwXXGB+2S for ; Thu, 3 Dec 2009 09:43:04 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 802E928C190 for ; Thu, 3 Dec 2009 09:43:04 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id nB3HgfgJ030707; Thu, 3 Dec 2009 12:42:41 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Thu, 3 Dec 2009 12:42:41 -0500 From: "Frankel, Sheila E." To: "ipsec@ietf.org" Date: Thu, 3 Dec 2009 12:42:40 -0500 Thread-Topic: Resolving Roadmap Issue #114 Thread-Index: Acp0QAJgtTl41raORXSDtOUqzOycVw== Message-ID: 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_D7A0423E5E193F40BE6E94126930C493078C303072MBCLUSTERxcha_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: "suresh.krishnan@ericsson.com" , Paul Hoffman , Tero Kivinen Subject: [IPsec] Resolving Roadmap Issue #114 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, 03 Dec 2009 17:43:05 -0000 --_000_D7A0423E5E193F40BE6E94126930C493078C303072MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Issue #114: Expired drafts, especially BEET =3D=3D> Tero and Yaron suggested wording changes. The 2nd paragraph below c= ontains those changes. #114: Expired drafts, especially BEET Proposed changes to Roadmap doc: Add text to the introductory section for IKEv1, Section 4.1.1: Additional text (revised since last email): IKE is the preferred key management protocol for IPsec. It is used for peer authentication; to negotiate, modify and delete SAs; and to negotiate authenticated keying material for use within those SAs. The standard peer authentication methods used by IKEv1 (pre-shared secret keys and digital certificates) had several shortcomings related to use of IKEv1 to enable remote user authentication to a corporate VPN: it could not leverage the use of legacy authentication systems (e.g. RADIUS databases) to authenticate a remote user to a security gateway; and it could not be used to configure remote users with network addresses or other information needed in order to access the internal network. Several Internet Drafts were written to address these problems: Extended Authentication withn IKE (XAUTH) (draft-beaulieu-ike-xauth and its predecessor draft-ietf-ipsra-isakmp-xauth) and The ISAKMP Configurat= ion Method (draft-dukes-ike-mode-cfg and its predecessor draft-ietf-ipsec-is= akmp- mode-cfg). These drafts did not progress to RFC status due to security flaws and other problems related to these solutions. However, many curre= nt IKEv1 implementations incorporate aspects of these solutions to facilita= te remote user access to corporate VPNs. These solutions were not standardi= zed, and different implementations implemented different versions. Thus, ther= e is no assurance that the implementations adhere fully to the suggested solutions, or that one implementation can interoperate with others that claim to incorporate the same features. Furthermore, these solutions hav= e known security issues. Thus, use of these solutions is not recommended. --_000_D7A0423E5E193F40BE6E94126930C493078C303072MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Issue #114: Expired dr= afts, especially BEET

 

=3D=3D> Tero and Ya= ron suggested wording changes. The 2nd paragraph below contains those changes.<= o:p>

 

#114: Expired drafts, especially BEET

 

Proposed changes to Ro= admap doc:

 

Add text to the introd= uctory section for IKEv1, Section 4.1.1:

 

Additional text (revis= ed since last email):

 

   IKE is th= e preferred key management protocol for IPsec. It is used for

   peer auth= entication; to negotiate, modify and delete SAs;  and to

   negotiate= authenticated keying material for use within those SAs.  The

   standard = peer authentication methods used by IKEv1 (pre-shared secret <= /font>

   keys and = digital certificates) had several shortcomings related to use

   of IKEv1 = to enable remote user authentication to a corporate VPN: it

   could not= leverage the use of legacy authentication systems (e.g. RADIUS =

   databases= ) to authenticate a remote user to a security gateway; and it =

   could not= be used to configure remote users with network addresses or <= /p>

   other inf= ormation needed in order to access the internal network.

 

   Several I= nternet Drafts were written to address these problems:

   Extended = Authentication withn IKE (XAUTH) (draft-beaulieu-ike-xauth and

   its prede= cessor draft-ietf-ipsra-isakmp-xauth) and The ISAKMP Configuration

   Method (draft-dukes-ike-mode-cfg and its predecessor draft-ietf-ipsec-isakmp-=

   mode-cfg)= .  These drafts did not progress to RFC status due to security

   flaws and= other problems related to these solutions. However, many current =

   IKEv1 imp= lementations incorporate aspects of these solutions to facilitate

   remote us= er access to corporate VPNs. These solutions were not standardized,

   and diffe= rent implementations implemented different versions. Thus, there

   is no ass= urance that the implementations adhere fully to the suggested

   solutions= , or that one implementation can interoperate with others that <= /p>

   claim to = incorporate the same features. Furthermore, these solutions have <= /p>

   known sec= urity issues. Thus, use of these solutions is not recommended.

 

--_000_D7A0423E5E193F40BE6E94126930C493078C303072MBCLUSTERxcha_-- From sheila.frankel@nist.gov Thu Dec 3 09:44: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 763F628C103 for ; Thu, 3 Dec 2009 09:44:21 -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 Vx1p-TwkMQiN for ; Thu, 3 Dec 2009 09:44:20 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 47C193A672F for ; Thu, 3 Dec 2009 09:44:20 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id nB3HhvSB030837; Thu, 3 Dec 2009 12:43:57 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Thu, 3 Dec 2009 12:43:57 -0500 From: "Frankel, Sheila E." To: "ipsec@ietf.org" Date: Thu, 3 Dec 2009 12:43:56 -0500 Thread-Topic: Resolving Roadmap Issue #115 Thread-Index: Acp0QC/0oNgwjEPWRDG4KHZwND2fVA== Message-ID: 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_D7A0423E5E193F40BE6E94126930C493078C303077MBCLUSTERxcha_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: "suresh.krishnan@ericsson.com" , Paul Hoffman , Tero Kivinen Subject: [IPsec] Resolving Roadmap Issue #115 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, 03 Dec 2009 17:44:21 -0000 --_000_D7A0423E5E193F40BE6E94126930C493078C303077MBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If there are no further comments, this issue will be closed. Issue #115: Camellia req levels for IKEv2 =3D=3D> Tero commented that this was fine with him. Proposed changes to Roadmap doc: 1) Change IKEv2 requirement level for Camellia-CBC from undefined (no RFC) to optional 2) Add text to Section 5.2.6 (RFC 4312, The Camellia Cipher Algorithm and I= ts Use with IPsec) Current text: [RFC5529] describes the use of the Camellia block cipher algorithm in conjunction with several different modes of operation. It describes the use of Camellia in Cipher Block Chaining (CBC) mode and Counter (CTR) mode as an encryption algorithm within ESP. It also describes the use of Camellia in Counter with CBC-MAC (CCM) mode as a combined mode algorithm in ESP. This document defines how to use IKEv2 to generate keying material for a Camellia ESP SA; it does not define how to use Camellia within IKEv2 to protect an IKEv2 SA's traffic. Additional text: However, this RFC, in conjunction with IKEv2's generalized description of block mode encryption, provide enough detail to allow the use of Camellia-CBC algorithms within IKEv2. Current text (continued): All three modes can use keys of length 128-bits, 192-bits or 256-bits. [RFC5529] includes IANA values for use in IKEv2 and IPsec-v3. A single IANA value is defined for each Camellia mode, so IKEv2 negotiations need to specify the keysize. --_000_D7A0423E5E193F40BE6E94126930C493078C303077MBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If there are no further comments, this issue wil= l be closed.

 

Issue #115: Camellia r= eq levels for IKEv2

 

=3D=3D> Tero commen= ted that this was fine with him.

 

Proposed changes to Ro= admap doc:

 

1) Change IKEv2 requir= ement level for Camellia-CBC from undefined (no RFC)

   &nbs= p;            to opt= ional

 

2) Add text to Section= 5.2.6 (RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec)=

 

Current text:

   [RFC5529]= describes the use of the Camellia block cipher algorithm in

   conjuncti= on with several different modes of operation.  It describes

   the use o= f Camellia in Cipher Block Chaining (CBC) mode and Counter

   (CTR) mod= e as an encryption algorithm within ESP.  It also describes<= /font>

   the use o= f Camellia in Counter with CBC-MAC (CCM) mode as a combined

   mode algo= rithm in ESP.  This document defines how to use IKEv2 to

   generate = keying material for a Camellia ESP SA; it does not define

   how to us= e Camellia within IKEv2 to protect an IKEv2 SA's traffic.

 

Additional text:<= /o:p>

   However, = this RFC, in conjunction with IKEv2's generalized description

   of block = mode encryption, provide enough detail to allow the use of

   Camellia-= CBC algorithms within IKEv2.

 

Current text (continue= d):

   All three= modes can use keys of length 128-bits, 192-bits or

   256-bits.= [RFC5529] includes IANA values for use in IKEv2 and

   IPsec-v3.=   A single IANA value is defined for each Camellia mode, so

   IKEv2 neg= otiations need to specify the keysize.

 

--_000_D7A0423E5E193F40BE6E94126930C493078C303077MBCLUSTERxcha_-- From sheila.frankel@nist.gov Thu Dec 3 10:42: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 186193A67A5 for ; Thu, 3 Dec 2009 10:42:07 -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 8sqPC2nqQwAO for ; Thu, 3 Dec 2009 10:42:06 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 7B26A3A6359 for ; Thu, 3 Dec 2009 10:42:05 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id nB3Ifd4k009355; Thu, 3 Dec 2009 13:41:39 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Thu, 3 Dec 2009 13:41:26 -0500 From: "Frankel, Sheila E." To: "ipsec@ietf.org" Date: Thu, 3 Dec 2009 13:41:38 -0500 Thread-Topic: Suggested solution to Roadmap Issue #113: Use of AES-XCBC in IKE Thread-Index: Acp0SD9IkoveMfI3R+uRlaHzqp66kg== Message-ID: 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_D7A0423E5E193F40BE6E94126930C493078C42EE4CMBCLUSTERxcha_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: "suresh.krishnan@ericsson.com" , Paul Hoffman , Tero Kivinen Subject: [IPsec] Suggested solution to Roadmap Issue #113: Use of AES-XCBC in IKE 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, 03 Dec 2009 18:42:07 -0000 --_000_D7A0423E5E193F40BE6E94126930C493078C42EE4CMBCLUSTERxcha_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is an initial attempt to resolve Issue #113. We would appreciate comme= nts/suggestions/alternate approaches. #113: Use of AES-XCBC in IKE Currently, the Req levels are SHOULD for IKEv1 (based on RFC4109) and opti= onal for IKEv2. The Req levels for AES-XCBC-PRF are SHOULD (based on RFC410= 9) and SHOULD+ for IKEv2 (RFC4307) This leaves us with 2 questions: 1) If there is no IANA value for AES-XCBC in IKEv1, how can RFC4109 recomm= end (SHOULD) its use? 2) If AES-XCBC and AES-XCBC-PRF can be used in IKEv1, what should be propo= sed? What should you propose if you want AES-XCBC for both a PRF and an int= egrity-protection algorithm in IKEv1? Proposed change to Roadmap doc: Add text to Section 5.5 - Pseudo-Random Functions (PRFs): For each IKEv2 SA, the peers negotiate both a PRF algorithm and an integrity-protection algorithm; the former is used to generate keying material and other values, and the latter is used to provide protection to the IKE SA's traffic. IKEv1's approach is more complicated. IKEv1 [RFC2409] does not specify any PRF algorithms. For each IKEv1 SA, the peers agree on an unkeyed hash function (e.g., SHA-1). IKEv1 uses the HMAC version of this function to generate keying material and to provide integrity protection for the IKE SA. If the peers want to use a PRF that is not an HMAC variant (e.g., AES-XCBC-PRF-128), they must negotiate both a PRF and a hash function. If AES-XCBC-PRF-128 is the negotiated PRF, then IKEv1 would use AES-XCBC-PRF-128 (not truncated) as a PRF and AES-XCBC-MAC-96 (truncated) for integrity-protection. The negotiated hash algorithm would be used for example when generating the NAT-D [RFC3947] payloads. If an IKEv1 proposal includes a PRF algorithm but not a hash, it must be rejected, as specified in [RFC2409]. NOTE: This solution would require adding an IANA value to the iana-ipsec-re= gistry for AES-XCBC-PRF-128 --_000_D7A0423E5E193F40BE6E94126930C493078C42EE4CMBCLUSTERxcha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is an initial att= empt to resolve Issue #113. We would appreciate comments/suggestions/alternate approaches.

 

#113: Use of AES-XCBC = in IKE

 

 Currently, the R= eq levels are SHOULD for IKEv1 (based on RFC4109) and optional for IKEv2. The Req lev= els for AES-XCBC-PRF are SHOULD (based on RFC4109) and SHOULD+ for IKEv2 (RFC43= 07)

 

 This leaves us w= ith 2 questions:

 1) If there is n= o IANA value for AES-XCBC in IKEv1, how can RFC4109 recommend (SHOULD) its use?

 2) If AES-XCBC a= nd AES-XCBC-PRF can be used in IKEv1, what should be proposed? What should you propose if you want AES-XCBC for both a PRF and an integrity-protection algorithm in IKEv1?

 

Proposed change to Roa= dmap doc:

 

Add text to Section 5.= 5 - Pseudo-Random Functions (PRFs):

 

For each IKEv2 SA, the= peers negotiate both a PRF algorithm and an

integrity-protection algorithm; the former is used to generate keying <= /p>

material and other val= ues, and the latter is used to provide protection

to the IKE SA's traffi= c.

 

IKEv1's approach is mo= re complicated.  IKEv1 [RFC2409] does not specify

any PRF algorithms. Fo= r each IKEv1 SA, the peers agree on an unkeyed

hash function (e.g., S= HA-1). IKEv1 uses the HMAC version of this function

to generate keying mat= erial and to provide integrity protection for the

IKE SA.  If the p= eers want to use a PRF that is not an HMAC variant (e.g.,

AES-XCBC-PRF-128), the= y must negotiate both a PRF and a hash function.

If AES-XCBC-PRF-128 is= the negotiated PRF, then IKEv1 would use

AES-XCBC-PRF-128 (not truncated) as a PRF and AES-XCBC-MAC-96 (truncated)

for integrity-protecti= on.  The negotiated hash algorithm would be used

for example when gener= ating the NAT-D [RFC3947] payloads.  If an IKEv1

proposal includes a PR= F algorithm but not a hash, it must be rejected,

as specified in [RFC24= 09].

 

NOTE: This solution wo= uld require adding an IANA value to the iana-ipsec-registry for AES-XCBC-PRF-12= 8

 

 

--_000_D7A0423E5E193F40BE6E94126930C493078C42EE4CMBCLUSTERxcha_-- From huangmin@huaweisymantec.com Thu Dec 3 18:14: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 F32A83A68C6 for ; Thu, 3 Dec 2009 18:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.067 X-Spam-Level: X-Spam-Status: No, score=0.067 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 w+jYS+ktS10T for ; Thu, 3 Dec 2009 18:14:16 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 26C743A685D for ; Thu, 3 Dec 2009 18:14:16 -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 <0KU300ICYVJ9DO60@hstga02-in.huaweisymantec.com> for ipsec@ietf.org; Fri, 04 Dec 2009 10:13:57 +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 <0KU30013IVJ8ZE10@hstml02-in.huaweisymantec.com> for ipsec@ietf.org; Fri, 04 Dec 2009 10:13:57 +0800 (CST) From: Min Huang To: Yaron Sheffer Date: Fri, 04 Dec 2009 10:13:56 +0800 Message-id: <002801ca7487$6f385450$619a1b0a@china.huawei.com> X-Mailer: Microsoft Office Outlook 11 Thread-index: Acp0h27DI+Eoljg9Q9Oi4q2qNonIYw== X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: ipsec@ietf.org Subject: Re: [IPsec] Proposed work item: WESP extensibility - YES 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, 04 Dec 2009 02:14:17 -0000 I would like to review further versions of this draft and be interested in contributing text. regards, Min On Sun, 29 Nov 2009 19:18:59 +0200, Yaron Sheffer wrote: 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 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!"). From huangmin@huaweisymantec.com Thu Dec 3 18:15: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 AB5083A68A0 for ; Thu, 3 Dec 2009 18:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.074 X-Spam-Level: X-Spam-Status: No, score=-0.074 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 HNdu0vt-6O7j for ; Thu, 3 Dec 2009 18:15:12 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id C78E03A67B4 for ; Thu, 3 Dec 2009 18:15:11 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from hstml01-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 <0KU300IDLVKTDO60@hstga02-in.huaweisymantec.com> for ipsec@ietf.org; Fri, 04 Dec 2009 10:14:53 +0800 (CST) Received: from h00104745 ([10.27.154.97]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KU300K7FVKSN310@hstml01-in.huaweisymantec.com> for ipsec@ietf.org; Fri, 04 Dec 2009 10:14:53 +0800 (CST) From: Min Huang To: Yaron Sheffer Date: Fri, 04 Dec 2009 10:14:52 +0800 Message-id: <002901ca7487$90921460$619a1b0a@china.huawei.com> X-Mailer: Microsoft Office Outlook 11 Thread-index: Acp0h5A1cu86mojgTiCfhjJkLSnVqg== X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: ipsec@ietf.org Subject: Re: [IPsec] Proposed work item: Failure detection in IKEv2 - YES 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, 04 Dec 2009 02:15:12 -0000 I am interested in discussing on this topic further. I would like to review this draft. regards, Min Sun, 29 Nov 2009 19:18:59 +0200, Yaron Sheffer wrote: 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. 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!"). From kohn.jack@gmail.com Thu Dec 3 18:20:14 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 6240E3A6403 for ; Thu, 3 Dec 2009 18:20:14 -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 u9uFbSkqxqyN for ; Thu, 3 Dec 2009 18:20:12 -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 4451C3A67A2 for ; Thu, 3 Dec 2009 18:20:12 -0800 (PST) Received: by ywh15 with SMTP id 15so2045110ywh.5 for ; Thu, 03 Dec 2009 18:20:01 -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=kTp7uA4ZuEClgAypjxHNEpY2j40P95EPYLmDK0FaSN4=; b=oxRB4PZB3Ug6DyRU/r1nMd6ASXQF2+ODO4R8K8E9M25pr22WM3W8E6hhaTMVuss4Zy M8Mh6JKTGOrVtkHQcKjkkX4w2gtlPwiwqJRk0OZcGrKm7OXla3FTrtlXgj/UU/8sRS5r f0wdBO/oL5NrlwubMvmje80tvzEEVXI/+LX9w= 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=m9Nb5iqPZCxoCgEyA6bXsGyyxSKcr71Vl1pUWBtlP8xvTYAUxiOD+z9sUZ0AhwEyj7 lAivyKHKP37Pmdpd28QTaSg2XCUrjazOX2koZxNZH4A7IS1ip/M8pywxSWZVXr97k5K4 LyBZXMMTO0A50UHQ2PM0nZ0ZGTBFFMOnrgNj8= MIME-Version: 1.0 Received: by 10.91.50.29 with SMTP id c29mr3832490agk.63.1259893200788; Thu, 03 Dec 2009 18:20:00 -0800 (PST) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> Date: Fri, 4 Dec 2009 07:50:00 +0530 Message-ID: From: Jack Kohn To: Yaron Sheffer Content-Type: text/plain; charset=ISO-8859-1 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: Fri, 04 Dec 2009 02:20:14 -0000 I will be interested in reviewing this and might also contribute some text to the draft. Jack On Sun, Nov 29, 2009 at 10:50 PM, Yaron Sheffer wrote: > 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 > 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 mcr@marajade.sandelman.ca Thu Dec 3 19:08: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 9B53D3A6957 for ; Thu, 3 Dec 2009 19:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 KOcRBcFCi6YI for ; Thu, 3 Dec 2009 19:08:48 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id C7A3F3A6403 for ; Thu, 3 Dec 2009 19:08:48 -0800 (PST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 7B161342F4 for ; Thu, 3 Dec 2009 22:01:25 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 838F94E855 for ; Thu, 3 Dec 2009 22:08:39 -0500 (EST) Delivery-Date: Thu Dec 3 22:05:09 2009 X-Original-To: mcr@sandelman.ca Delivered-To: mcr@sandelman.ca Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by lox.sandelman.ca (Postfix) with ESMTP id A8C5E37B77 for ; Thu, 3 Dec 2009 22:05:09 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id E76DE342F1 for ; Thu, 3 Dec 2009 21:57:50 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 4E20B4E855 for ; Thu, 3 Dec 2009 22:05:04 -0500 (EST) Message-ID: <4B187C60.6040307@sandelman.ca> Date: Thu, 03 Dec 2009 22:05:04 -0500 From: Michael Richardson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090706 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: "mcr@sandelman.ca >> Michael Richardson" References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Resent-To: ipsec@core3.amsl.com Resent-Date: Thu, 03 Dec 2009 22:08:39 -0500 Resent-Message-ID: <21431.1259896119@marajade.sandelman.ca> Resent-From: Michael Richardson 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: Fri, 04 Dec 2009 03:08:49 -0000 Yaron Sheffer wrote: > 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 envisioned that this will be used by modern high-security operating systems, that go beyond the currently supported Multilevel Security (MLS). > > Proposed starting point: http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-context-01 and http://tools.ietf.org/html/draft-jml-ipsec-ikev1-security-context-01. > > Please reply to the list: I have no interest in this work. I am not convinced that this work has very broad interest. I think that in most cases, this work can be done with vendor extensions until it is finished, at which point an Informational RFC could ask for IANA assigned values, and be published. I am unclear if this work has any mainstream value without an IPsec API. From mcr@marajade.sandelman.ca Thu Dec 3 19:09: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 478813A6968 for ; Thu, 3 Dec 2009 19:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 0i5qeSEu70io for ; Thu, 3 Dec 2009 19:09:04 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 2A02D3A695F for ; Thu, 3 Dec 2009 19:09:04 -0800 (PST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id C872A342EB for ; Thu, 3 Dec 2009 22:01:40 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id C2F934E855 for ; Thu, 3 Dec 2009 22:08:54 -0500 (EST) Prev-Resent: Thu, 03 Dec 2009 22:08:39 -0500 Prev-Resent: "ipsec@core3.amsl.com " Delivery-Date: Thu Dec 3 22:05:09 2009 X-Original-To: mcr@sandelman.ca Delivered-To: mcr@sandelman.ca Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by lox.sandelman.ca (Postfix) with ESMTP id A8C5E37B77 for ; Thu, 3 Dec 2009 22:05:09 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id E76DE342F1 for ; Thu, 3 Dec 2009 21:57:50 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 4E20B4E855 for ; Thu, 3 Dec 2009 22:05:04 -0500 (EST) Message-ID: <4B187C60.6040307@sandelman.ca> Date: Thu, 03 Dec 2009 22:05:04 -0500 From: Michael Richardson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090706 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: "mcr@sandelman.ca >> Michael Richardson" References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Resent-To: ipsec@ietf.org Resent-Date: Thu, 03 Dec 2009 22:08:54 -0500 Resent-Message-ID: <21446.1259896134@marajade.sandelman.ca> Resent-From: Michael Richardson 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: Fri, 04 Dec 2009 03:09:04 -0000 Yaron Sheffer wrote: > 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 envisioned that this will be used by modern high-security operating systems, that go beyond the currently supported Multilevel Security (MLS). > > Proposed starting point: http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-context-01 and http://tools.ietf.org/html/draft-jml-ipsec-ikev1-security-context-01. > > Please reply to the list: I have no interest in this work. I am not convinced that this work has very broad interest. I think that in most cases, this work can be done with vendor extensions until it is finished, at which point an Informational RFC could ask for IANA assigned values, and be published. I am unclear if this work has any mainstream value without an IPsec API. From mcr@sandelman.ca Thu Dec 3 19:17: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 EC4323A6950 for ; Thu, 3 Dec 2009 19:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 t7RFDhjAlzQk for ; Thu, 3 Dec 2009 19:17:43 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 386963A6403 for ; Thu, 3 Dec 2009 19:17:43 -0800 (PST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id E42D8342F8 for ; Thu, 3 Dec 2009 22:10:19 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 8EB144E855 for ; Thu, 3 Dec 2009 22:17:33 -0500 (EST) Message-ID: <4B187F4D.6020006@sandelman.ca> Date: Thu, 03 Dec 2009 22:17:33 -0500 From: Michael Richardson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090706 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: ipsec@ietf.org References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 04 Dec 2009 03:17:44 -0000 Yaron Sheffer wrote: > 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. > I am not interested in any further extensions to WESP. In particular, I think we are creating mechanisms in advance of problems. From mcr@sandelman.ca Thu Dec 3 19:17: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 28DAA3A699A for ; Thu, 3 Dec 2009 19:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, 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 PLS+7PZcy4Dj for ; Thu, 3 Dec 2009 19:17:58 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 0AC693A6968 for ; Thu, 3 Dec 2009 19:17:58 -0800 (PST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 8C7DB342F5 for ; Thu, 3 Dec 2009 22:10:34 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 30B854E855 for ; Thu, 3 Dec 2009 22:17:48 -0500 (EST) Message-ID: <4B187F5C.6050102@sandelman.ca> Date: Thu, 03 Dec 2009 22:17:48 -0500 From: Michael Richardson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090706 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: ipsec@ietf.org References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F1@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F1@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [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: Fri, 04 Dec 2009 03:17:58 -0000 Yaron Sheffer wrote: > This work item will define the problem statement and requirements for a > solution that allows interoperable HA/LS device groups. Mixed-vendor > clusters are specifically out of scope; but single-vendor clusters > should be fully interoperable with other vendors’ devices or clusters. > The main challenge 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 > than a particular solution. > > > > Proposed starting point: > http://tools.ietf.org/id/draft-nir-ipsecme-ipsecha-00.txt. > > > > Please reply to the list: It is interesting work, and may well be valuable. It is not a priority to me, and I would not have time to work on it. I might read a WG FC, and I might respond to threads, if I came across them. From mcr@sandelman.ca Thu Dec 3 19:18: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 D2E213A68B4 for ; Thu, 3 Dec 2009 19:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.72 X-Spam-Level: X-Spam-Status: No, score=-1.72 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 vukt3QlDtERk for ; Thu, 3 Dec 2009 19:18:27 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 2CBF13A6814 for ; Thu, 3 Dec 2009 19:18:27 -0800 (PST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id DCFA2342F3 for ; Thu, 3 Dec 2009 22:11:03 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id E9A9B4E855 for ; Thu, 3 Dec 2009 22:18:17 -0500 (EST) Message-ID: <4B187F79.9080809@sandelman.ca> Date: Thu, 03 Dec 2009 22:18:17 -0500 From: Michael Richardson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090706 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: ipsec@ietf.org References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EF@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EF@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [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: Fri, 04 Dec 2009 03:18:27 -0000 Yaron Sheffer wrote: > 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. > > Please reply to the list: I will review multiple versions of this document, and I will contribute text. I think this is an important problem, although I am not convinced that qcd-05 is the right mechanism. I am open to being convinced. From mcr@sandelman.ca Thu Dec 3 19: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 8AA5C3A6814 for ; Thu, 3 Dec 2009 19:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 ZYY6q+x0GNSb for ; Thu, 3 Dec 2009 19:18:41 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 7C6F43A69A4 for ; Thu, 3 Dec 2009 19:18:40 -0800 (PST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id DF1C8342EB for ; Thu, 3 Dec 2009 22:11:16 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id D0E514E855 for ; Thu, 3 Dec 2009 22:18:30 -0500 (EST) Message-ID: <4B187F86.9030503@sandelman.ca> Date: Thu, 03 Dec 2009 22:18:30 -0500 From: Michael Richardson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090706 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: ipsec@ietf.org References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [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: Fri, 04 Dec 2009 03:18:42 -0000 Yaron Sheffer wrote: > 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-childless-01.txt. > > Please reply to the list: I believe that this is a useful extension to IKEv2. I am willing to review drafts, and I might co-author. In particular, I would like to be able to negotiate IKEv2, specifically so that I can send a DELETE. Alternatively, I would like to negotiate a non-SA for some traffic selector. I mention this, because I'm not sure that the reasons for CHILDLESS are the same for different people, and therefore, we may be trying to use a hammer on a screw. From mcr@sandelman.ca Thu Dec 3 19:18: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 AE64E3A698F for ; Thu, 3 Dec 2009 19:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 qw2H92JJ3jn9 for ; Thu, 3 Dec 2009 19:18:58 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 061B73A68E8 for ; Thu, 3 Dec 2009 19:18:58 -0800 (PST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id B84C0342EB for ; Thu, 3 Dec 2009 22:11:34 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id C1D954E855 for ; Thu, 3 Dec 2009 22:18:48 -0500 (EST) Message-ID: <4B187F98.5040608@sandelman.ca> Date: Thu, 03 Dec 2009 22:18:48 -0500 From: Michael Richardson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090706 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: ipsec@ietf.org References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 04 Dec 2009 03:18:58 -0000 Dan Harkins wrote: > 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, Does it double, or does it really just "n+1", which is doubling if the rest of the protocol has "n=1"? I also wonder if this is really a sufficiently compelling reason to have two sets of code. > 3. is insecure (unless something used nowhere today is employed: EAP > channel bindings). We can, and must solve this. From mcr@sandelman.ca Thu Dec 3 19:19: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 613B33A69A0 for ; Thu, 3 Dec 2009 19:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.779 X-Spam-Level: X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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-SuTLq6P9Dj for ; Thu, 3 Dec 2009 19:19:14 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id BA1A73A6814 for ; Thu, 3 Dec 2009 19:19:14 -0800 (PST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 67796342F5 for ; Thu, 3 Dec 2009 22:11:51 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 7B50A4E855 for ; Thu, 3 Dec 2009 22:19:05 -0500 (EST) Message-ID: <4B187FA9.3040206@sandelman.ca> Date: Thu, 03 Dec 2009 22:19:05 -0500 From: Michael Richardson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090706 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: ipsec@ietf.org References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F2@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E06DD@il-ex01.ad.checkpoint.com> <99043b4a0911302310v7f2edf00l8d210b1d1e7d14a8@mail.gmail.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0772@il-ex01.ad.checkpoint.com> <19221.5158.22224.351908@fireball.kivinen.iki.fi> In-Reply-To: <19221.5158.22224.351908@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 04 Dec 2009 03:19:15 -0000 Tero Kivinen wrote: > SPSK can be used when there is requirement for host to host (or site > to site) connection, where either end can initiate traffic and > exchanges and where entities still want to use passwords instead of > public keys to authenticate. Shared keys could be used there, but in > most setups the shared keys used in those scenarios are not strong > enough to be resistant against dictionary attacks. EAP-only cannot be > used there as this is not client-server setup. In these setup the > authentication needs to be symmetric. > > For this reason I do not think we need to decide to take on or the > other, we can take both as I do see use for both of them. > > If I would need to select one, I would select SPSK, as that is > something which cannot be done by IKEv2 now. > > EAP-only is an optimization (both in protocol level, and especially in > adminstrative level) for the existing EAP-Public key authentication. I concur with Tero's analysis and I agree that I would prefer to solve the problem that SPSK solves. From mcr@sandelman.ca Thu Dec 3 19:19: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 4E3713A6946 for ; Thu, 3 Dec 2009 19:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 QXnI8nEZzR-J for ; Thu, 3 Dec 2009 19:19:51 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 62F273A68B4 for ; Thu, 3 Dec 2009 19:19:51 -0800 (PST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 0365B342F3 for ; Thu, 3 Dec 2009 22:12:28 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 14A7B4E855 for ; Thu, 3 Dec 2009 22:19:42 -0500 (EST) Message-ID: <4B187FCE.3020005@sandelman.ca> Date: Thu, 03 Dec 2009 22:19:42 -0500 From: Michael Richardson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090706 Lightning/0.9 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: ipsec@ietf.org References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 04 Dec 2009 03:19:52 -0000 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: I believe that this item is a lower priority than SPSK. I would like to find a way to find a compromise, but recent discussion suggests to me that it isn't possible. Those who want an EAP method can do that work in EMU. From yaronf@checkpoint.com Thu Dec 3 22:32: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 C8B773A69B9 for ; Thu, 3 Dec 2009 22:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 AOK3iMc-58la for ; Thu, 3 Dec 2009 22:32:55 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id A24DE3A681E for ; Thu, 3 Dec 2009 22:32:53 -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 nB46WhGo029167; Fri, 4 Dec 2009 08:32:43 +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, 4 Dec 2009 08:32:53 +0200 From: Yaron Sheffer To: Michael Richardson , "ipsec@ietf.org" Date: Fri, 4 Dec 2009 08:32:51 +0200 Thread-Topic: [IPsec] Proposed work item: EAP-only authentication in IKEv2 Thread-Index: Acp0kKlPACZUAIbFRFSeLXHsRZ1r8QAGnh5g Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0B4C@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> <4B187FCE.3020005@sandelman.ca> In-Reply-To: <4B187FCE.3020005@sandelman.ca> 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] 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: Fri, 04 Dec 2009 06:32:55 -0000 To clarify: we don't want "an EAP method". We would like to slightly extend= IKEv2 to use existing, and future, EAP methods that fit the bill. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Michael Richardson > Sent: Friday, December 04, 2009 5:20 > To: ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2 >=20 > 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: >=20 > I believe that this item is a lower priority than SPSK. > I would like to find a way to find a compromise, but recent discussion > suggests to me that it isn't possible. Those who want an EAP method can > do that work in EMU. >=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 kivinen@iki.fi Fri Dec 4 01:30: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 2AF443A6948 for ; Fri, 4 Dec 2009 01:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 Cj-WzF0r4V29 for ; Fri, 4 Dec 2009 01:30:16 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id AE5BC3A67F5 for ; Fri, 4 Dec 2009 01:30: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 nB49TwmO015336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Dec 2009 11:29:58 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nB49TuZ2013076; Fri, 4 Dec 2009 11:29:56 +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: <19224.54932.526889.724647@fireball.kivinen.iki.fi> Date: Fri, 4 Dec 2009 11:29:56 +0200 From: Tero Kivinen To: "Frankel, Sheila E." In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: "ipsec@ietf.org" , "suresh.krishnan@ericsson.com" , Paul Hoffman Subject: [IPsec] Resolving Roadmap Issue #114 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, 04 Dec 2009 09:30:17 -0000 Frankel, Sheila E. writes: > Issue #114: Expired drafts, especially BEET ... > Several Internet Drafts were written to address these problems: > Extended Authentication withn IKE (XAUTH) (draft-beaulieu-ike-xauth and > its predecessor draft-ietf-ipsra-isakmp-xauth) and The ISAKMP Configuration > Method (draft-dukes-ike-mode-cfg and its predecessor draft-ietf-ipsec-isakmp- > mode-cfg). These drafts did not progress to RFC status due to security > flaws and other problems related to these solutions. However, many current > IKEv1 implementations incorporate aspects of these solutions to facilitate > remote user access to corporate VPNs. These solutions were not standardized, > and different implementations implemented different versions. Thus, there > is no assurance that the implementations adhere fully to the suggested > solutions, or that one implementation can interoperate with others that > claim to incorporate the same features. Furthermore, these solutions have > known security issues. Thus, use of these solutions is not recommended. Perhaps we should add some kind of advertisement here by changing the last sentence to: "All of those problems and security issues have been solved in the IKEv2, thus use of these non-standardized IKEv1 solutions is not recommended." I.e. provide the a solution to the problem (use IKEv2) in addition to just saying that "do not use them". -- kivinen@iki.fi From kivinen@iki.fi Fri Dec 4 02:36: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 737443A691F for ; Fri, 4 Dec 2009 02:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 r1qELDWyw22l for ; Fri, 4 Dec 2009 02:35:59 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1C9523A6906 for ; Fri, 4 Dec 2009 02:35:58 -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 nB4AZh54015637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Dec 2009 12:35:43 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nB4AZgaW017052; Fri, 4 Dec 2009 12:35:42 +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: <19224.58878.21816.495315@fireball.kivinen.iki.fi> Date: Fri, 4 Dec 2009 12:35:42 +0200 From: Tero Kivinen To: "Frankel, Sheila E." 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: "ipsec@ietf.org" , "suresh.krishnan@ericsson.com" , Paul Hoffman Subject: [IPsec] Suggested solution to Roadmap Issue #113: Use of AES-XCBC in IKE 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, 04 Dec 2009 10:36:00 -0000 Frankel, Sheila E. writes: > This is an initial attempt to resolve Issue #113. We would > appreciate comments/suggestions/alternate approaches. > > #113: Use of AES-XCBC in IKE > > Currently, the Req levels are SHOULD for IKEv1 (based on RFC4109) > and optional for IKEv2. The Req levels for AES-XCBC-PRF are SHOULD > (based on RFC4109) and SHOULD+ for IKEv2 (RFC4307) > > This leaves us with 2 questions: > 1) If there is no IANA value for AES-XCBC in IKEv1, how can RFC4109 > recommend (SHOULD) its use? > 2) If AES-XCBC and AES-XCBC-PRF can be used in IKEv1, what should > be proposed? What should you propose if you want AES-XCBC for both > a PRF and an integrity-protection algorithm in IKEv1? I would say as we are talking here about the obsoleted IKEv1 protocol, and these problems have already been solved in the IKEv2, there is no need to do anything for IKEv1 registries. As nobody has yet to noticed that there is no number of AES-XCBC PRF for IKEv1, I assume nobody has implemented it. If it has not been implemented, then I do not think vendors will add implementation of it to the obsoleted IKEv1 protocol, thus there will never be implementations for it. Usually the hash/mac functions used to protect IKEv1 SA do not matter that much to users, they only care what algorithms are used in the IPsec SAs. Currently AES-XCBC-MAC-96 can be used in those contexts fine both in IKEv1 and IKEv2, thus there is no problem there. There is no need to get AES-XCBC PRF to work when protecting IKEv1 SAs. > Proposed change to Roadmap doc: > > Add text to Section 5.5 - Pseudo-Random Functions (PRFs): > > For each IKEv2 SA, the peers negotiate both a PRF algorithm and an > integrity-protection algorithm; the former is used to generate keying > material and other values, and the latter is used to provide protection > to the IKE SA's traffic. > > IKEv1's approach is more complicated. IKEv1 [RFC2409] does not specify > any PRF algorithms. For each IKEv1 SA, the peers agree on an unkeyed > hash function (e.g., SHA-1). IKEv1 uses the HMAC version of this function > to generate keying material and to provide integrity protection for the > IKE SA. Up to this it is fine. > If the peers want to use a PRF that is not an HMAC variant (e.g., > AES-XCBC-PRF-128), they must negotiate both a PRF and a hash function. But I would remove all of these, and simply say that: Currently there is no PRF functions defined for IKEv1, thus only PRFs which can be used are the HMAC versions of the unkeyed hash functions. AES-XCBC-PRF-128 could be defined also in IKEv1, but as there is no IANA number allocated for it, currently it cannot be used in IKEv1. > If AES-XCBC-PRF-128 is the negotiated PRF, then IKEv1 would use > AES-XCBC-PRF-128 (not truncated) as a PRF and AES-XCBC-MAC-96 (truncated) > for integrity-protection. The negotiated hash algorithm would be used > for example when generating the NAT-D [RFC3947] payloads. If an IKEv1 > proposal includes a PRF algorithm but not a hash, it must be rejected, > as specified in [RFC2409]. This text above, is something that should be in the RFC specifying the PRF, not in this document, as it mostly seems to be clarification to the RFC2409. I do not think this document can add this kind of almost normative text for any other documents.. > NOTE: This solution would require adding an IANA value to the > iana-ipsec-registry for AES-XCBC-PRF-128 If nobody has cared about using AES-XCBC-PRF-128 in protecting the IKEv1 SA for 6 (or 11) years, I do not think people will start using it now, thus I suggest we just say it cannot be used. -- kivinen@iki.fi From mglt.ietf@gmail.com Fri Dec 4 06:44: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 5644E28C130 for ; Fri, 4 Dec 2009 06:44:16 -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 bquo8e6YyrQb for ; Fri, 4 Dec 2009 06:44:15 -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 896AD3A6A2E for ; Fri, 4 Dec 2009 06:44:13 -0800 (PST) Received: by fxm5 with SMTP id 5so2521973fxm.28 for ; Fri, 04 Dec 2009 06:44:01 -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:content-type; bh=4GUF+EcEs2YE7/hX/yX8Y0ZCUVhpKHZbEufV+zaCMSs=; b=soSQO9RwjIrCMnuJ+/xNQgIzD87mZafkli3bN4aHhE/fs6dEDMyPtobKtS6opR+v12 P78xKy96qpP9V+FTqSfs/N7jXSYiFLwn6B6ZGwRxl8+aG2KO02zyFQYXlLPNsAERLKB7 O8lnC14cgZqjE73V7EW85jJNSWpvnTYRIjyaY= 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 :content-type; b=Yne4SW0N3sfAZVzHHjk0jjKQHM+trgn9zo7gsn/G7HQQXb2yWDUxWnhiDKxy6OTmqy JuxKatsUxfiak1qqlw4PwguqnAtyG3OYST4WkpkyCBOGVahGnT+F4dWEv+C4ss2/9zZA OJpaRJFR2V6v8fV6Xq8h+6DM7u24sjYFnsH7k= MIME-Version: 1.0 Received: by 10.103.76.21 with SMTP id d21mr1026623mul.78.1259937841384; Fri, 04 Dec 2009 06:44:01 -0800 (PST) In-Reply-To: <4B187F4D.6020006@sandelman.ca> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> <4B187F4D.6020006@sandelman.ca> Date: Fri, 4 Dec 2009 15:44:01 +0100 Message-ID: <51eafbcb0912040644j35f73e3cgd708ddfdfdcbded5@mail.gmail.com> From: Daniel Migault To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=0016e65aeea4798bf10479e82392 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: Fri, 04 Dec 2009 14:44:16 -0000 --0016e65aeea4798bf10479e82392 Content-Type: text/plain; charset=ISO-8859-1 I am interested in WESP Extension and would like to co-author it. Our interest in WESP extensions are to ease IPsec deployment within Intranet security AND Middle Boxes. We expect WESP would be able to provide Network administrators information related on IPsec and Middleboxes interactions. Regards, Daniel > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --0016e65aeea4798bf10479e82392 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am interested in WESP Extension and would like to co-author it. Our inter= est in WESP extensions are to ease IPsec deployment within Intranet securit= y AND Middle Boxes. We expect WESP would be able to provide Network adminis= trators information related on IPsec and Middleboxes interactions.

Regards,
Daniel =A0
__________= _____________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec



--
Daniel Miga= ult
Orange Labs -- Security
+33 6 70 72 69 58
--0016e65aeea4798bf10479e82392-- From paul.hoffman@vpnc.org Fri Dec 4 08:12:31 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 9874D3A693D for ; Fri, 4 Dec 2009 08:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.019 X-Spam-Level: X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=0.027, 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 44WwBSjkhTIm for ; Fri, 4 Dec 2009 08:12:30 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 563443A6A16 for ; Fri, 4 Dec 2009 08:12:28 -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 nB4Fx80d084460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Dec 2009 08:59:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19224.54932.526889.724647@fireball.kivinen.iki.fi> References: <19224.54932.526889.724647@fireball.kivinen.iki.fi> Date: Fri, 4 Dec 2009 07:59:06 -0800 To: "Frankel, Sheila E." From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Resolving Roadmap Issue #114 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, 04 Dec 2009 16:12:31 -0000 At 11:29 AM +0200 12/4/09, Tero Kivinen wrote: >Perhaps we should add some kind of advertisement here by changing the >last sentence to: > >"All of those problems and security issues have been solved in the >IKEv2, thus use of these non-standardized IKEv1 solutions is not >recommended." > >I.e. provide the a solution to the problem (use IKEv2) in addition to >just saying that "do not use them". Yes, that is an appropriate advertisement in the right place in the doc. --Paul Hoffman, Director --VPN Consortium From latten@austin.ibm.com Fri Dec 4 10:25: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 52A213A67FA for ; Fri, 4 Dec 2009 10:25:34 -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 v0qUwLt9GY1P for ; Fri, 4 Dec 2009 10:25:33 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 2068D3A67AC for ; Fri, 4 Dec 2009 10:25:30 -0800 (PST) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e33.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nB4IMTQM031731 for ; Fri, 4 Dec 2009 11:22:29 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nB4IP0P9177958 for ; Fri, 4 Dec 2009 11:25:00 -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 nB4BEkCd022699 for ; Fri, 4 Dec 2009 04:14:46 -0700 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d03av02.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nB4BEkXc022677; Fri, 4 Dec 2009 04:14:46 -0700 Received: from [9.41.41.43] (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id nB4IOwMn047672; Fri, 4 Dec 2009 12:24:58 -0600 From: Joy Latten To: Stephen Kent In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> Content-Type: text/plain Date: Fri, 04 Dec 2009 12:09:50 -0600 Message-Id: <1259950190.2717.270.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit 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 Reply-To: latten@austin.ibm.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:25:34 -0000 On Sun, 2009-11-29 at 19:59 -0500, Stephen Kent wrote: > 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 The drafts do mention IPSO/CIPSO. They also acknowledge that FIPS-188 describe the use of free form tags that would allow additional security attributes. However, there is nothing protecting the data and heading, including the security context. Nor is anything preserving or protecting the bindings between the data and security context. Only IPSO is a standard and it was designed to support security labels used by DoD. Yes, I agree, tunnel mode could be used to protect the data, header, security context and thus bindings. However, it seem useful that, if you are going to deploy IPsec in a MAC environment, it included a mechanism to handle labels too. The method described in the labeled ipsec drafts was originally designed using ikev1. Perhaps thru further discussion this method could be refined and improved upon for ikev2. > 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. > I believe they are becoming more mainstream. For example, SELinux and Simplified Mandatory Access Control (SMACK) in Linux Operating System and Mandatory Integrity Control in Windows Vista. However, I am also inclined to agree that at this time it could be argued to be more a research topic. regards, Joy From danmcd@sun.com Fri Dec 4 10:40:14 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 D96A53A698C for ; Fri, 4 Dec 2009 10:40:14 -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 QdShegsGomz3 for ; Fri, 4 Dec 2009 10:40:14 -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 0D3033A6839 for ; Fri, 4 Dec 2009 10:40:14 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB4IdnlO022172; Fri, 4 Dec 2009 18:39:49 GMT Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB4IdnSv020727; Fri, 4 Dec 2009 13:39:49 -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 nB4IdkB9018082; Fri, 4 Dec 2009 13:39:46 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB4Idkh0018081; Fri, 4 Dec 2009 13:39:46 -0500 (EST) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Fri, 4 Dec 2009 13:39:46 -0500 From: Dan McDonald To: Joy Latten Message-ID: <20091204183946.GH17842@kebe.East.Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <1259950190.2717.270.camel@faith.austin.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1259950190.2717.270.camel@faith.austin.ibm.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.20 (2009-06-14) 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: Fri, 04 Dec 2009 18:40:15 -0000 On Fri, Dec 04, 2009 at 12:09:50PM -0600, Joy Latten wrote: > I believe they are becoming more mainstream. For example, SELinux and > Simplified Mandatory Access Control (SMACK) in Linux Operating System > and Mandatory Integrity Control in Windows Vista. You forgot OpenSolaris Trusted Extensions (and their brand-new IPsec support): http://hub.opensolaris.org/bin/view/Project+txipsec/ The page needs an update, because the bits are now available for use. The bigger point being missed by this thread, I think, is that it seems that any work in multi-level security needs to deal with successful interoperability. If it doesn't, there's little point in documenting a single-platform solution as part of a working group's output. Dan From paul.hoffman@vpnc.org Fri Dec 4 11:05: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 1E3A23A6A4F for ; Fri, 4 Dec 2009 11:05:00 -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 OiF+bovxYQs4 for ; Fri, 4 Dec 2009 11:04:59 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 863753A6A3E for ; Fri, 4 Dec 2009 11:04: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 nB4IAA77098510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Dec 2009 11:10:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19224.58878.21816.495315@fireball.kivinen.iki.fi> References: <19224.58878.21816.495315@fireball.kivinen.iki.fi> Date: Fri, 4 Dec 2009 10:10:09 -0800 To: Tero Kivinen , "Frankel, Sheila E." From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" , "suresh.krishnan@ericsson.com" Subject: Re: [IPsec] Suggested solution to Roadmap Issue #113: Use of AES-XCBC in IKE 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, 04 Dec 2009 19:05:00 -0000 At 12:35 PM +0200 12/4/09, Tero Kivinen wrote: >I would say as we are talking here about the obsoleted IKEv1 protocol, >and these problems have already been solved in the IKEv2, there is no >need to do anything for IKEv1 registries. Agree. >There is no need to get AES-XCBC PRF to work when protecting IKEv1 >SAs. Agree. > > Proposed change to Roadmap doc: >> >> Add text to Section 5.5 - Pseudo-Random Functions (PRFs): >> >> For each IKEv2 SA, the peers negotiate both a PRF algorithm and an >> integrity-protection algorithm; the former is used to generate keying >> material and other values, and the latter is used to provide protection >> to the IKE SA's traffic. >> >> IKEv1's approach is more complicated. IKEv1 [RFC2409] does not specify >> any PRF algorithms. For each IKEv1 SA, the peers agree on an unkeyed >> hash function (e.g., SHA-1). IKEv1 uses the HMAC version of this function >> to generate keying material and to provide integrity protection for the >> IKE SA. > >Up to this it is fine. > >> If the peers want to use a PRF that is not an HMAC variant (e.g., >> AES-XCBC-PRF-128), they must negotiate both a PRF and a hash function. > >But I would remove all of these, and simply say that: > > Currently there is no PRF functions defined for IKEv1, thus only > PRFs which can be used are the HMAC versions of the unkeyed hash > functions. AES-XCBC-PRF-128 could be defined also in IKEv1, but as > there is no IANA number allocated for it, currently it cannot be > used in IKEv1. Partially agree. I would remove the proposed sentence and add nothing. There is no reason to go into detail about what we don't intend to do. > > If AES-XCBC-PRF-128 is the negotiated PRF, then IKEv1 would use > > AES-XCBC-PRF-128 (not truncated) as a PRF and AES-XCBC-MAC-96 (truncated) > > for integrity-protection. The negotiated hash algorithm would be used > > for example when generating the NAT-D [RFC3947] payloads. If an IKEv1 > > proposal includes a PRF algorithm but not a hash, it must be rejected, > > as specified in [RFC2409]. > >This text above, is something that should be in the RFC specifying the >PRF, not in this document, as it mostly seems to be clarification to >the RFC2409. I do not think this document can add this kind of almost >normative text for any other documents.. Very strongly agree. And the fact that it has not been asked for before now says that even thinking about it is unnecessary. > > NOTE: This solution would require adding an IANA value to the >> iana-ipsec-registry for AES-XCBC-PRF-128 > >If nobody has cared about using AES-XCBC-PRF-128 in protecting the >IKEv1 SA for 6 (or 11) years, I do not think people will start using >it now, thus I suggest we just say it cannot be used. A sentence that says "Therefore PRFs that are not HMACs cannot currently be used" sums up the current state of affairs succinctly --Paul Hoffman, Director --VPN Consortium From Nicolas.Williams@sun.com Fri Dec 4 11: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 EF6243A6A42 for ; Fri, 4 Dec 2009 11:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.861 X-Spam-Level: X-Spam-Status: No, score=-5.861 tagged_above=-999 required=5 tests=[AWL=0.185, 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 v5cZYcYVwz-K for ; Fri, 4 Dec 2009 11:05:47 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 331713A686C for ; Fri, 4 Dec 2009 11:05:47 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB4J5a8u006529 for ; Fri, 4 Dec 2009 19:05:36 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nB4J5anx023368 for ; Fri, 4 Dec 2009 12:05:36 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nB4IkM8I009627; Fri, 4 Dec 2009 12:46:22 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB4IkLMl009626; Fri, 4 Dec 2009 12:46:21 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 4 Dec 2009 12:46:21 -0600 From: Nicolas Williams To: Dan McDonald Message-ID: <20091204184621.GO773@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <1259950190.2717.270.camel@faith.austin.ibm.com> <20091204183946.GH17842@kebe.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091204183946.GH17842@kebe.East.Sun.COM> User-Agent: Mutt/1.5.7i Cc: "ipsec@ietf.org" , Joy Latten 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: Fri, 04 Dec 2009 19:05:48 -0000 On Fri, Dec 04, 2009 at 01:39:46PM -0500, Dan McDonald wrote: > The bigger point being missed by this thread, I think, is that it > seems that any work in multi-level security needs to deal with > successful interoperability. If it doesn't, there's little point in > documenting a single-platform solution as part of a working group's > output. +1. The proposed work item is, at first glance anyways, too SELinux- specific. Note that SMACK encodes its labels as CIPSO labels, so a scheme that uses CIPSO can possibly be used in SMACK and non-SMACK environments, and possibly even be mixed. In any case, there have been lengthy threads elsewhere (saag, IIRC) about MAC interoperability. Some options to consider: - implicit labeling - derived from CERTs - derived from IDs - derived from network addresses - negotiated labeling - requires a DOI negotiation of some sort - each node asserts one, or more, or a range of labels (SMACK, for example, doesn't support the notion of label ranges) and the peers evaluate and narrow the assertion according to policy and produce All I see in the proposed work item is single label assertions. That strikes me as insufficient. Nico -- From root@core3.amsl.com Fri Dec 4 12: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 AA1C13A672E; Fri, 4 Dec 2009 12: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: <20091204200001.AA1C13A672E@core3.amsl.com> Date: Fri, 4 Dec 2009 12:00:01 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-aes-ctr-ikev2-04.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: Fri, 04 Dec 2009 20: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-04.txt Pages : 16 Date : 2009-12-4 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-04.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-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-4115454.I-D@ietf.org> --NextPart-- From dharkins@lounge.org Fri Dec 4 12:44: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 EFB043A6954 for ; Fri, 4 Dec 2009 12:44:05 -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 F4iC+52912FV for ; Fri, 4 Dec 2009 12:44:05 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 169E53A63C9 for ; Fri, 4 Dec 2009 12:44:05 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id CD962102240AE; Fri, 4 Dec 2009 12:43:55 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 4 Dec 2009 12:43:55 -0800 (PST) Message-ID: <2f0d03efe2821829e89f06264d75f60b.squirrel@www.trepanning.net> In-Reply-To: <4B187F98.5040608@sandelman.ca> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> <4B187F98.5040608@sandelman.ca> Date: Fri, 4 Dec 2009 12:43:55 -0800 (PST) From: "Dan Harkins" To: "Michael Richardson" 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: Fri, 04 Dec 2009 20:44:06 -0000 Hi Michael, On Thu, December 3, 2009 7:18 pm, Michael Richardson wrote: > Dan Harkins wrote: >> 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, > > Does it double, or does it really just "n+1", which is doubling if the > rest of the protocol has "n=1"? I also wonder if this is really a > sufficiently compelling reason to have two sets of code. For the proposed EAP methods, EAP-EKE and EAP-PWD, it really is double. I don't think it's possible to do the kind of exchange that's required-- mutual authentication, key generation-- in n=1 messages. If you look at the SPSK draft, it is doing essentially the same exchange as EAP-PWD and doing it in 6 messages total. If you do EAP-only plus EAP-PWD (or EAP-only plus EAP-EKE, doesn't matter) it's 12 messages total. >> 3. is insecure (unless something used nowhere today is employed: >> EAP >> channel bindings). > > We can, and must solve this. We can and we must. That's the easy part :-) The hard part is coming up with a way to do it. One of the big problems with EAP is that it is a completely underspecified shim. That's why every EAP method needs to roll-its-own identity exchange (the identity obtained by EAP is not suitable for authentication purposes) and roll-its-own fragmentation/reassembly code. So the obvious, and in my opinion wrong, solution for channel bindings is to just have each EAP method roll-its-own security capabilities negotiation plus definition of TLV message exchange and a cryptographic protection of that TLV message exchange as a way to solve channel bindings. Another option is to have it done generally as some sort of extension to EAP that every EAP method can "inherit". But mention that and people who wear hats start saying what can and cannot be done and what's in a charter and blah blah blah. Keep in mind, though, that however channel bindings gets solved, it is only going to further increase the number of messages necessary to get what you can get in SPSK in 6, and only 6, messages :-) Dan. From yaronf@checkpoint.com Fri Dec 4 12:53: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 430733A68AB for ; Fri, 4 Dec 2009 12:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 mBihn5GCPsqJ for ; Fri, 4 Dec 2009 12:53:35 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 0560E3A6892 for ; Fri, 4 Dec 2009 12:53:34 -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 nB4KjrGo013689; Fri, 4 Dec 2009 22:45:53 +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, 4 Dec 2009 22:46:03 +0200 From: Yaron Sheffer To: Nicolas Williams , Dan McDonald Date: Fri, 4 Dec 2009 22:46:02 +0200 Thread-Topic: [IPsec] Proposed work item: Labelled IPsec Thread-Index: Acp1FM4wblp1ShhGSZWLUwjxZudJJQADQLdg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0B6E@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <1259950190.2717.270.camel@faith.austin.ibm.com> <20091204183946.GH17842@kebe.East.Sun.COM> <20091204184621.GO773@Sun.COM> In-Reply-To: <20091204184621.GO773@Sun.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" , Joy Latten 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: Fri, 04 Dec 2009 20:53:36 -0000 Please remember that it is up to the WG to define the work item. The I-D is= just a possible starting point, so if there's strong interest in this area= , you may wish to reach consensus on a charter item - and to convince the r= est of us that enough people are interested. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Nicolas Williams > Sent: Friday, December 04, 2009 20:46 > To: Dan McDonald > Cc: ipsec@ietf.org; Joy Latten > Subject: Re: [IPsec] Proposed work item: Labelled IPsec >=20 > On Fri, Dec 04, 2009 at 01:39:46PM -0500, Dan McDonald wrote: > > The bigger point being missed by this thread, I think, is that it > > seems that any work in multi-level security needs to deal with > > successful interoperability. If it doesn't, there's little point in > > documenting a single-platform solution as part of a working group's > > output. >=20 > +1. >=20 > The proposed work item is, at first glance anyways, too SELinux- > specific. >=20 > Note that SMACK encodes its labels as CIPSO labels, so a scheme that > uses CIPSO can possibly be used in SMACK and non-SMACK environments, and > possibly even be mixed. >=20 > In any case, there have been lengthy threads elsewhere (saag, IIRC) > about MAC interoperability. >=20 > Some options to consider: >=20 > - implicit labeling > - derived from CERTs > - derived from IDs > - derived from network addresses > - negotiated labeling > - requires a DOI negotiation of some sort > - each node asserts one, or more, or a range of labels (SMACK, for > example, doesn't support the notion of label ranges) and the peers > evaluate and narrow the assertion according to policy and produce >=20 > All I see in the proposed work item is single label assertions. That > strikes me as insufficient. >=20 > Nico > -- > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From Nicolas.Williams@sun.com Fri Dec 4 14:38: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 F12523A6A6E for ; Fri, 4 Dec 2009 14:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.872 X-Spam-Level: X-Spam-Status: No, score=-5.872 tagged_above=-999 required=5 tests=[AWL=0.174, 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 re1-7sAC7-YP for ; Fri, 4 Dec 2009 14:38:03 -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 92B1A3A6A66 for ; Fri, 4 Dec 2009 14:38:02 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB4MbrbZ001718 for ; Fri, 4 Dec 2009 22:37:53 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nB4MbqwX017979 for ; Fri, 4 Dec 2009 15:37:53 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nB4MB9Lr009841; Fri, 4 Dec 2009 16:11:09 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB4MB857009840; Fri, 4 Dec 2009 16:11:08 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 4 Dec 2009 16:11:08 -0600 From: Nicolas Williams To: Yaron Sheffer Message-ID: <20091204221108.GZ773@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <1259950190.2717.270.camel@faith.austin.ibm.com> <20091204183946.GH17842@kebe.East.Sun.COM> <20091204184621.GO773@Sun.COM> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0B6E@il-ex01.ad.checkpoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0B6E@il-ex01.ad.checkpoint.com> User-Agent: Mutt/1.5.7i Cc: "ipsec@ietf.org" , Joy Latten , Dan McDonald 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: Fri, 04 Dec 2009 22:38:04 -0000 On Fri, Dec 04, 2009 at 10:46:02PM +0200, Yaron Sheffer wrote: > Please remember that it is up to the WG to define the work item. The > I-D is just a possible starting point, so if there's strong interest > in this area, you may wish to reach consensus on a charter item - and > to convince the rest of us that enough people are interested. Yes, but that's not how the original message in this thread was worded: | 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. True, you might interpret "the draft" to mean "the WG draft" as opposed to "the starting point" I-D given in that e-mail, but it wasn't sufficiently clear. Now that you've clarified, my answers are: - I am willing to review multiple versions of a WG I-D on labelled IPsec, and to contribute text. - I am not willing to co-author. - I do believe that labelled IPsec via IKE extensions is a reasonable activity for the WG. However, I do not believe the the proposed starting point is appropriate as is. I believe that an appropriate labelled-IPsec-via- IKE-extensions work item should address interoperability, which means at a minimum that for explicit labelling in IKE we should have a DOI agreement sub-protocol (i.e., both peers must understand that they have a common DOI or that they don't). I'm also interested in proposals that do CERT-based implicit labelling, but such proposals are probably more appropriately pursued elsewhere (e.g., PKIX WG). Nico -- From tarun.ahuja@cavium.com Sun Dec 6 19:30: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 DD2703A6984 for ; Sun, 6 Dec 2009 19:30:29 -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 h2AFLSoij-5x for ; Sun, 6 Dec 2009 19:30:28 -0800 (PST) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 1CD763A67E9 for ; Sun, 6 Dec 2009 19:30:27 -0800 (PST) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA04.westchester.pa.mail.comcast.net with comcast id E0LC1d0070cZkys543WKBZ; Mon, 07 Dec 2009 03:30:19 +0000 Received: from [192.168.2.2] ([99.17.206.106]) by OMTA10.westchester.pa.mail.comcast.net with comcast id E3W51d0092JFn9P3W3W8Cv; Mon, 07 Dec 2009 03:30:17 +0000 Message-ID: <4B1C76BD.3040402@cavium.com> Date: Sun, 06 Dec 2009 19:30:05 -0800 From: Tarun Ahuja User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Proposed work item: WESP extensibility - YES 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, 07 Dec 2009 03:30:30 -0000 WESP already helps middleboxes and the options for in-band monitoring, error notification, etc are valuable. Additional options proposed by Brian look interesting and should be considered. For now I commit to reviewing but might also contribute some text to the draft, as time permits. From rahul.bharadhwaj@gmail.com Sun Dec 6 20:50: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 5E8E43A68D3 for ; Sun, 6 Dec 2009 20:50:04 -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 yLSfrdxVe4ts for ; Sun, 6 Dec 2009 20:50:03 -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 664F33A6847 for ; Sun, 6 Dec 2009 20:50:03 -0800 (PST) Received: by bwz23 with SMTP id 23so3324376bwz.29 for ; Sun, 06 Dec 2009 20:49:50 -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=mzMcC0oMmGueXJWgyl0eCvwvYRH1rVYqAvnh+qf9Ol4=; b=HVRm5TSNTLDdV/uGAQuBy2MjVqLBR+S427vRmmopPVCzw+Ot+YmJWrwxqqGwh+QxR1 Gd+xo7fQY4yU3NGPtY02ZVvdK9+tfyzjHTjCtHOOWkWznHh2/+C0E6eBM7JWGJE7npTG Ub2J5ZIK5SIpZI7jELjRRGyfOtImVV/MFgZS8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=lanwK9t3Sj8ROPQwTXqOK8lJF3QUqZIkLHbCqqDUGMFKyKAms/ipTHxIkR7EnnTZqF zvU7ZRPU/NjM5z/8oesYF5a1Mr3fJicoHsWBEGFdnCVNXV34KUpL/0WC2iozynlQyolI PFGy0oP+I+3J1UiGIHTWX19MYhayGJqRS7LrM= MIME-Version: 1.0 Received: by 10.204.21.4 with SMTP id h4mr6501839bkb.58.1260161389953; Sun, 06 Dec 2009 20:49:49 -0800 (PST) Date: Mon, 7 Dec 2009 10:19:49 +0530 Message-ID: <53944c010912062049m1e1fe12k46e427fce0139a7@mail.gmail.com> From: rahul bharadhwaj To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=00032555817e02032b047a1c30d9 Subject: [IPsec] regarding aes-xcbc-mac 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, 07 Dec 2009 04:52:41 -0000 --00032555817e02032b047a1c30d9 Content-Type: text/plain; charset=ISO-8859-1 Hi All i want to test the aes-xcbc-mac functioanlity in a proprietory ipsec controller and have a doubt with the output i get. Though i get a stabled mac outputs for specified inputs, the mac value do not match with RFC test vectors. inputs: hash key: 0x000102030405060708090a0b0c0d0e0f Messge: 0x000102030405060708090a0b0c0d0e0f register settings for load_initial_hash and final_has are set to 1 The mac result i get from hardware is 93f3aeb403600d315507af1f2b948c75 which is different from RFC test vector. Could anyone tell/guess what could be missing possibly in my settings and let me know if any other details required. Thanks --00032555817e02032b047a1c30d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi All

i want to test the aes-xcbc-mac functioanlity in a proprietory ipsec con= troller and have a doubt with the output i get.
Though i get a stabled m= ac outputs for specified inputs, the mac value do not match with RFC test v= ectors.

inputs:
hash key: 0x000102030405060708090a0b0c0d0e0f
Messge: 0x000102030405= 060708090a0b0c0d0e0f
register settings for load_initial_hash and final_has are set to 1

The mac result i get from hardware is 93f3aeb403600d315507af1f2b948c75 w= hich is different from RFC test vector.

Could anyone tell/guess what could be missing=A0possibly in my=A0setting= s and let me know if any other details required.

Thanks

=A0

--00032555817e02032b047a1c30d9-- From mauricio.sanchez@hp.com Sun Dec 6 22:53: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 152EC28C10E for ; Sun, 6 Dec 2009 22:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.598 X-Spam-Level: X-Spam-Status: No, score=-105.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, 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 mc0Gle3mvU9c for ; Sun, 6 Dec 2009 22:53:42 -0800 (PST) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by core3.amsl.com (Postfix) with ESMTP id E791F28C0D0 for ; Sun, 6 Dec 2009 22:53:41 -0800 (PST) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTPS id C94E01C289 for ; Mon, 7 Dec 2009 06:53:31 +0000 (UTC) Received: from G5W0323.americas.hpqcorp.net (16.228.8.68) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 7 Dec 2009 06:53:09 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0323.americas.hpqcorp.net ([16.228.8.68]) with mapi; Mon, 7 Dec 2009 06:53:09 +0000 From: "Sanchez, Mauricio (ProCurve)" To: "ipsec@ietf.org" Date: Mon, 7 Dec 2009 06:53:08 +0000 Thread-Topic: Support for WESP extensions Thread-Index: Acp3CR8/MSdAstLNTp2T/7JVPFPqZA== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C51B0B37A15@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_9BC2F7926B33FE4AB10D69891D58FC1C51B0B37A15GVW0671EXCame_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [IPsec] Support for WESP extensions 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, 07 Dec 2009 06:53:43 -0000 --_004_9BC2F7926B33FE4AB10D69891D58FC1C51B0B37A15GVW0671EXCame_ Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C51B0B37A15GVW0671EXCame_" --_000_9BC2F7926B33FE4AB10D69891D58FC1C51B0B37A15GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I hereby voice support for WESP extensions draft (in response to email note= d below). My answers to questions posed: - If this proposal is accepted as a WG work item, are you committing to rev= iew multiple versions of the draft? Yes. - Are you willing to contribute text to the draft? Yes, as part of review process. - Would you like to co-author it? No. Cheers, MS -------------------------------------------- Mauricio Sanchez Chief Security Architect HP ProCurve Networking Hewlett-Packard 8000 Foothills Blvd. M/S 5541 Roseville, CA 95747 tel: 916.785.1910 fax: 916.785.1749 mauricio.sanchez@hp.com [cid:image001.jpg@01CA74ED.F3AE2D70] -------------------------------------------- From: Yaron Sheffer Subject: [IPsec] Proposed work item: WESP extensibility To: "ipsec@ietf.org" Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.c= om> Content-Type: text/plain; charset=3D"us-ascii" 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_9BC2F7926B33FE4AB10D69891D58FC1C51B0B37A15GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I hereby voice support for WESP extensions draft (i= n response to email noted below).

 

My answers to questions posed:

 

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

Yes.

 

- Are you willing to contribute text to the draft?<= o:p>

Yes, as part of review process.

 

- Would you like to co-author it?

No.

 

Cheers,

MS

 

--------------------------------------------
Mauricio Sanchez

Chief Security Architect


HP ProCurve Networking
He= wlett-Packard
8000 Foothills Blvd.

M/S 5541
Roseville, CA 95747

tel: 916.785.1910
fax: 916.785.1749
mauricio.sanchez@hp.com=

3D"HP_ProCurve_Logo_Black[MS=

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

 

 

 

 

 

 =

 

From: Yaron Sheffer <yaronf@checkpoint.com>

Subject: [IPsec] Proposed work item: WESP extensibi= lity

To: "ipsec@ietf.org" <ipsec@ietf.org&g= t;

Message-ID:

      <7F9A6D26EB51614F= BF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com>

     

Content-Type: text/plain; charset=3D"us-ascii&= quot;

 

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, a= re you committing to review multiple versions of the draft?

 

- Are you willing to contribute text to the draft?<= o:p>

 

- 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 g= ets 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!").

 

 

--_000_9BC2F7926B33FE4AB10D69891D58FC1C51B0B37A15GVW0671EXCame_-- --_004_9BC2F7926B33FE4AB10D69891D58FC1C51B0B37A15GVW0671EXCame_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=3111; creation-date="Mon, 07 Dec 2009 06:53:07 GMT"; modification-date="Mon, 07 Dec 2009 06:53:07 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/wAALCABvANIBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKK4rxL8VvDnhjVX0y5+03FzGB5ot0BEZPOCSRzWR/wvfwv/AM+epf8AftP/AIql X46+GWYKtlqRYnAAiXJ/8eroJfiFpcXiay8O/Zbxr+8SNtgRcRbhnD88EDk1lal8ZNA0q9mtriw1 P91I0fmeQAr4OMjJGRVP/he/hf8A589S/wC/af8AxVH/AAvfwv8A8+epf9+0/wDiq6Xwz8QNC8VW d1cWMkqNaLumimTDqvqME5Fauka3bawJfISRGiPKyDHqM8fQ1avruOwsLi8lDGO3iaVgvUhRk4/K uZ0n4j6VqdzZwzWOpacL8gWk13b7YpyegVgSMmuuorA8QeMLDQLmGx8m5v8AUZxuisrOPzJSv94j oB7mm6L4sbVNS/s670PU9LuDGZE+1RDY4GM4YEjPPSuhooooooooooor5W+If/JQNb/6+3rnoYpJ 5khiQvJIwVFUcsTwBX0d4G+Hul+C9IGo6jHFNqQjMk87jIhAGSqemPXvXMfCmCTxP461vxjcqSqs Uhz2L9vwQAfjXrl3Z2t9A0F5bxXETDBSVAwP4GvDvin8MINCgbXtCjK2W7Fxb5z5OTwy/wCznjHb +XldeofAeNJfEupxyKGR7EhlPQjete42OmWmnBxaxbN+NxLEk46DJqv4l/5FfVf+vKb/ANANcD4c 0nxH4m8OeGrW9tLOx0ixMF0JlmMk0+wfKAMYXPerNj4x8RtpOpeJL+SzTS9Mnni+zRRHzLkqSq/M T8vJUfgas3mreN/D+lr4i1WbTbmyXa91YwxFXhjYgfK+fmIz3qz4I8q78V+LL6XDXn21YlZvvLAE BQD0B/pW94t1S40TwpqWp2gQz2sBkj3jK5HqKoan4gvbS58LxxCLbqs4S4yvbyy3y+nNZHh/VvGf iSG9vYbrT7a3tZ7i3hjMBZp2XIUk54AO0e+DSL4+vL7StDSzSKPUruR/t6OpItkhz5xxnrkcfWsT /hZWryWX9uxanpflFt66N5LmYx5xjzP7+OfSvVbedbm2iuEBCyoHAI5wRmpaKKKKKK+VviH/AMlA 1v8A6+3rQ+ElhHqHxE08SgFYA82D6qpx+uK9e+MGvf2N4GngjfbPqDC3TB52nlj+Qx+NeTTeH202 /wDC+jaZLcQ6xfIk906SkBC7ZQYHQhRk1v65cReL/ilfrd3Ex0bRLZzOY5Cu5YxzyO5c4rT+DmkT 6t4d197t5W0++Jto4Hcso4O4jPf5gM+1eMTRmGZ4jyUYqfwNen/AP/katR/68v8A2da96qrqlmdR 0q7sQ/lm5geIORnbuUjOPxqDQNLbRfD9hpbSiY2kCRGQLjdgYzjtWVpvgyCDwtf6Bfz/AGmG+mmk dkXaVEjbhjryPX2rMfwZ4j1G1i0fWvEcVzo0TLvSK22T3CKchXbOMcDJHWtDWfCFzJrA13w9qf8A ZWpGMRTZj8yG4QdA6+o7EVEPDHiDV7e7t/EmvxTW9zbPALaztvLQFv4ySSSR2FQ6Z4P106ppVxr2 tW95b6MD9ljgtzGztt2hnJPUD0rb8L6C3h3TJrN7gTmS6ln3BduN7FsfhmquneC9O0/xNq2tqoZ9 TQI0ZHCZ+/j/AHjgn6VlWfg7xNptumj6f4njg0eJ/wB0wts3MaZzsDZx7ZxXbgYAGc47mloooooo r5W+If8AyUDW/wDr7epfhtrMWh+PNNu52CQu5hkY9FDjbn8yK9R8eeHNa8XfELSLQ6fP/YlmV824 42HJ3P8AoAv1rIhtNW0zxP4j8e67p0tmlpA/2BZscu3yRgfQYH41yOixaxL4N1K20/Q9TurzWp0D 3aQExmJSSQG9S3XtXtmlW8HgD4bILkqhsbQyTf7UpGSPxY4FfMMjtLI0jfeYkn6mvUPgH/yNWo/9 eX/s6171VLWbqSx0W+vIceZb28kibhkZVSRn8qx/BXjOz8YaUJ418i9iVftNq33kJHBHqp6g1Jp2 uXd1451jRpBH9msreCSIhfmy4OcnPtXQ1maDrsHiCymureKSJYriS3IkxklGwTx2rToorl/HN/d2 EWiGzuZIDPq9vDJsON6HOVPsa2tYn1G10uabSbJL28XHlwPJ5YbkZ+btxmriFjGpdQrEDcAc4NOo ooooor5X+IilfiDrYYEH7Wx5rm69o+HvxitY7KHSfE8jRvEAkV7gsGXsH7g+/wCdT/GbXRqlloug aXKs51ORZwYzkOudqfgSSfwrtIdd8L+CdBttMutYtIvsMIiMayBnLAc/KMnJOa8a+JHxMl8YONPs Ee30qJ92H4eZh0Leg9B/kcDXqfwDVj4o1FgDtFngn0+da95rM8S/8ivq3/XlN/6Aa4zTfDFxe+DP D2vaFKtrrtnYRCOQ/cuE2jMUnqD2PaufbxXfSz+NdatLaaw1CKwtYpIpB80EgJRyPpkkGtGw8Pal p2o6RdafYS2JnmVLue41oTC9iYfP8p6tjkbfSqmieHXh8EajquiyXK6jp+qSzRL57kSLFIfkIzg5 XP1OKst8QbyLU5vF4jkfw7cRmxt48HPnKm9Wx7vuTNLpuiXV5rWm+GvEV/dCOaxfUrmJZ2Q3Vw78 oSDnagx8oqHXhJ4bj8UaBpV9cvp8ekrdIjTM7WkpcLtDE5AI5xmrPiLQo9A8OaHdWSz3uo3OqWks rT3DMbiQKxAyeFyTjio7m5e5+F2ua6+oTyavcuq3Y3MhtHWRR5Krn5Qv69a0RokHiX4i6vZ6nPdS WUFhbMLZLh0QuwPzHaR0wfzrF06e61Ww8O+Gr7UblNPn1C8gmkEpV5ViJ8uMv15/pW3p2l2vh/4r 2el6be3P2RtMllNnJcNIsTbhyMkkZx3r0Wiiiiue1zwH4Z8RXn2zVNLjmuMBTIrMhYDpnaRms3/h Ungj/oDf+R5P/iqP+FSeCP8AoDf+R5P/AIqtRvBPh99ZtdXawBu7NESBvMbEYQYUBc44rPuPhX4O u7mW5n0kvLM5d2M8mWYnJP3vWo/+FSeCP+gN/wCR5P8A4qj/AIVJ4I/6A3/keT/4qt3QfDGjeGYH h0exjtVkOXIJLN6ZJ5rWqK5tory1ltZ13xTIY3XOMqRgj8qZYWNvplhBY2kfl29ugjjTJO1RwBk1 DJo2nS3VzcyWcTSXcIguCV/1qDOAw79TWTpXgDw5o+oR31rZuZYc+QJZnkWHP9xWJArX0zSbLSLe S3sYfKjkleVl3E5Zjljz71EPD+lLpcWliyi+xwyCRIccBg28H/vrmma74a0rxHDHHqdt5jQtuilR ykkZ/wBlhgiq1r4K0Cz0a60mKx/0a9/4+S0jM83+85OT+dX73RbDUILSG6g8xLOVJoBuI2On3T74 qpd+EtEvpL957PJ1JVW7CuyiXacqSAcZ469au2+kWNrqdxqUMO26uY0jlfcTuVPujHTjNcx4p0fR 9L0CK0bw5cahpr3bTT/ZWYy2zNk+aoHzHn0PGayPB2lWM3jhNT0PTL62061snjlub5HD3ErsO78n AFel0UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUV//Z --_004_9BC2F7926B33FE4AB10D69891D58FC1C51B0B37A15GVW0671EXCame_-- From mcr@marajade.sandelman.ca Mon Dec 7 04:34: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 0C9EE3A680C for ; Mon, 7 Dec 2009 04:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 VUqji5wrhXkE for ; Mon, 7 Dec 2009 04:34:58 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id EA8483A67AE for ; Mon, 7 Dec 2009 04:34:57 -0800 (PST) Received: from sandelman.ottawa.on.ca (unknown [66.78.97.66]) by relay.sandelman.ca (Postfix) with ESMTPS id EB3B2342FA; Mon, 7 Dec 2009 07:27:44 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 710E14E854; Mon, 7 Dec 2009 07:34:34 -0500 (EST) From: Michael Richardson To: "Dan Harkins" In-Reply-To: <2f0d03efe2821829e89f06264d75f60b.squirrel@www.trepanning.net> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> <4B187F98.5040608@sandelman.ca> <2f0d03efe2821829e89f06264d75f60b.squirrel@www.trepanning.net> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 07 Dec 2009 07:34:34 -0500 Message-ID: <13045.1260189274@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca 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, 07 Dec 2009 12:34:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Dan" == Dan Harkins writes: >>> 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, >> Does it double, or does it really just "n+1", which is doubling >> if the rest of the protocol has "n=1"? I also wonder if this is >> really a sufficiently compelling reason to have two sets of code. Dan> For the proposed EAP methods, EAP-EKE and EAP-PWD, it really Dan> is double. I don't think it's possible to do the kind of Dan> exchange that's required-- mutual authentication, key Dan> generation-- in n=1 messages. Dan> If you look at the SPSK draft, it is doing essentially the Dan> same exchange as EAP-PWD and doing it in 6 messages total. If Dan> you do EAP-only plus EAP-PWD (or EAP-only plus EAP-EKE, doesn't Dan> matter) it's 12 messages total. Is this 6 messages, times 2 directions? Or just 6 messages. I can not quite see why the EAP encapsulation *doubles* the number of round trips. I can see how it might increase it by 1, due to need to do some EAP thing. Dan> One of the big problems with EAP is that it is a completely Dan> underspecified shim. That's why every EAP method needs to Dan> roll-its-own identity exchange (the identity obtained by EAP is Dan> not suitable for authentication purposes) and roll-its-own Yes, I completed understand this problem. I'm suggesting that if we care for channel bindings for EAP, that we (security people who care) need to solve this once and for all. Dan> Keep in mind, though, that however channel bindings gets Dan> solved, it is only going to further increase the number of Dan> messages necessary to get what you can get in SPSK in 6, and Dan> only 6, messages :-) Again, I do not know why it has to double the number of round trips. I see one extra round trip caused by the EAP-ID process, and then it's the same number both ways. Perhaps you can draw a time-sequence diagram for this to convince me? - -- ] 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 iQEVAwUBSxz2WICLcPvd0N1lAQInLQgAiLf0gKq8aHRAKq4r7oaAUXGYYqt9q3Kk g+KQYGjBrTmfXCEOYziSNonIN7XrjX4ePn7LHWk9AsWWh22y/esYF3Y5n4fkhktV an2SY9AE9CYz2PsXACZut2oRAM/YtHSeSnvvPbTzQ6i5bYoVeJqwthM4XIhpoFL1 6J9wY2owu1JzPI5KZeDDefbZscNjI7JVvHvI5deR8qtdykn2W2oOaxhaEEEpPY7p gIwkBIhFsnwSslF2sWUPmosDI/CTmo+KKFCa0QbXOP/D93raAgnNmKdDno9AwGjU FgAXkh/Z7102hkytkc64D6Lg7wU0fhxo+T+m5OkKV3RlfszjSQe9YA== =nC7X -----END PGP SIGNATURE----- From amjads@cisco.com Mon Dec 7 05:36: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 42A473A685A for ; Mon, 7 Dec 2009 05:36:42 -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 EU1dQ7RCb37L for ; Mon, 7 Dec 2009 05:36: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 92A393A6850 for ; Mon, 7 Dec 2009 05:36:41 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from syd-iport-1.cisco.com ([64.104.193.196]) by sj-iport-4.cisco.com with ESMTP; 07 Dec 2009 13:36:30 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAiUHEtAaHte/2dsb2JhbADCNJYRhDMEgWeBGg X-IronPort-AV: E=Sophos;i="4.47,355,1257120000"; d="scan'208,217";a="62628857" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by syd-iport-1.cisco.com with ESMTP; 07 Dec 2009 13:36:32 +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 nB7DaS43026615 for ; Mon, 7 Dec 2009 13:36:28 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); Mon, 7 Dec 2009 19:06:28 +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_01CA7742.47451EE2" Date: Mon, 7 Dec 2009 19:06:26 +0530 Message-ID: <1CFAB1B15A6C1142BD1FC07D1CA82AB2018B5FE3@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Childless IKE SA Thread-Index: Acp3QkZ8fYQNLoD9SaSaQzCc6N5KeQ== From: "Amjad Inamdar (amjads)" To: X-OriginalArrivalTime: 07 Dec 2009 13:36:28.0241 (UTC) FILETIME=[475E9C10:01CA7742] Subject: [IPsec] 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: Mon, 07 Dec 2009 13:36:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7742.47451EE2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe that this is a useful extension to IKEv2. I am willing to review drafts, and I might co-author. Thanks, -Amjad ------_=_NextPart_001_01CA7742.47451EE2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I believe that=20 this is a useful extension to IKEv2.
I am willing to review drafts, = and I=20 might co-author.
Thanks,
-Amjad
------_=_NextPart_001_01CA7742.47451EE2-- From mglt.ietf@gmail.com Mon Dec 7 07:27: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 2BA753A6837 for ; Mon, 7 Dec 2009 07:27:44 -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 k7uDezJIcNnU for ; Mon, 7 Dec 2009 07:27:43 -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 2CC433A6826 for ; Mon, 7 Dec 2009 07:27:42 -0800 (PST) Received: by bwz23 with SMTP id 23so3686431bwz.29 for ; Mon, 07 Dec 2009 07:27: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=HCeXuTQxg0CGvlDJGc0wRS7b+2yT4jUUHkH895PE9cA=; b=frTMRwTkwIUUELYSlrIOyAOlEkBGi+RdWup+8CuIyf0Nshgb32bE1W12A4acGLBR2A TM9CO/jJMEB6c6+dfZ2SgmSMjIdmX7Fcm2ZvY+CJ5iUkA1ukCkwSU/d5OfaqYGRCHE3S at6IMiG7tABnCBWo769euzDj2tNGcDR0AtHRY= 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=avp4FAEXC64p6ulBOTGsYE1WXYEk2M6c3qw9pLup3Jdw5wynrkr4qCiBSmTt5Gz2Em oFVDO/DhXFkZUk2bcpGE/2KSYGn6aiJPq19k8r0s94quGwFjkAthE0uoZhl0QVhYSkD+ B4hsc/LHazblreFPcBz9M2t8sEAliuiwkkags= MIME-Version: 1.0 Received: by 10.103.85.16 with SMTP id n16mr120557mul.97.1260199649825; Mon, 07 Dec 2009 07:27:29 -0800 (PST) In-Reply-To: <1CFAB1B15A6C1142BD1FC07D1CA82AB2018B5FE3@XMB-BGL-417.cisco.com> References: <1CFAB1B15A6C1142BD1FC07D1CA82AB2018B5FE3@XMB-BGL-417.cisco.com> Date: Mon, 7 Dec 2009 16:27:29 +0100 Message-ID: <51eafbcb0912070727r48d113e7q3cccb727d6c49c1a@mail.gmail.com> From: Daniel Migault To: "Amjad Inamdar (amjads)" Content-Type: multipart/alternative; boundary=0016e65c8db4795436047a2518c8 Cc: ipsec@ietf.org Subject: Re: [IPsec] 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: Mon, 07 Dec 2009 15:27:44 -0000 --0016e65c8db4795436047a2518c8 Content-Type: text/plain; charset=ISO-8859-1 I am also supporting this extension. I am at least willing to review drafts, probably add text. Regards, Daniel On Mon, Dec 7, 2009 at 2:36 PM, Amjad Inamdar (amjads) wrote: > I believe that this is a useful extension to IKEv2. > I am willing to review drafts, and I might co-author. > Thanks, > -Amjad > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --0016e65c8db4795436047a2518c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am also supporting this extension. I am at least willing to review drafts= , probably add text.
Regards,
Daniel

On Mon, Dec 7, 2009 at 2:36 PM, Amjad Inamdar (amjads) <amjads@cisco.com> wr= ote:
I believe that=20 this is a useful extension to IKEv2.
I am willing to review drafts, and = I=20 might co-author.
Thanks,
-Amjad

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




--
Daniel Migault
O= range Labs -- Security
+33 6 70 72 69 58
--0016e65c8db4795436047a2518c8-- From mglt.ietf@gmail.com Mon Dec 7 07:31: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 BFA883A6A69 for ; Mon, 7 Dec 2009 07:31:54 -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 YJmY-NhXQPcx for ; Mon, 7 Dec 2009 07:31:54 -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 7CB223A6A63 for ; Mon, 7 Dec 2009 07:31:53 -0800 (PST) Received: by bwz23 with SMTP id 23so3691017bwz.29 for ; Mon, 07 Dec 2009 07:31:40 -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=lqlAurrr7QdFpfN9q2iltkgzMZCoa852qeVBcXRs+Mg=; b=nqWv/QLJPVGFR5eeL+NzCA56bVuITX/+hwoRF7J97O93wS4KhKEil+7djMDPGzkpzA z7P9nNUkIBLh9zXEzRexW+u9a/U/3RgGeMjjid8wlsqyiS4qZlNjAqpm4ODtw/ZNNiiP j3R7+zIwgez5bRGPaOf1BfDnMvimQfap0dCZI= 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=m9KhwxP9/4RUYkbc4rxkk8znfogovqWXCPKDuQhSfFQDfPOSYr0t4ezzzg5C5t7LD1 eWNb2dBNDtcHw60SLiyiD+cmLX0+98X5MsimKl3qjnQ395tku/uAL3LV0HiUO9MEa0Oi XzPyC4yrLdhvIG2D4UON6QUTFgdvve/GRJQCo= MIME-Version: 1.0 Received: by 10.103.126.33 with SMTP id d33mr2238073mun.109.1260199899987; Mon, 07 Dec 2009 07:31:39 -0800 (PST) In-Reply-To: <4B187F5C.6050102@sandelman.ca> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F1@il-ex01.ad.checkpoint.com> <4B187F5C.6050102@sandelman.ca> Date: Mon, 7 Dec 2009 16:31:39 +0100 Message-ID: <51eafbcb0912070731w2c13d799va76a43f6b3bb6aa5@mail.gmail.com> From: Daniel Migault To: Michael Richardson Content-Type: multipart/alternative; boundary=0016e65b3ffc627d86047a252743 Cc: ipsec@ietf.org Subject: Re: [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: Mon, 07 Dec 2009 15:31:54 -0000 --0016e65b3ffc627d86047a252743 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I will also review this document. Regards, Daniel On Fri, Dec 4, 2009 at 4:17 AM, Michael Richardson wrote= : > Yaron Sheffer wrote: > >> This work item will define the problem statement and requirements for a >> solution that allows interoperable HA/LS device groups. Mixed-vendor >> clusters are specifically out of scope; but single-vendor clusters shoul= d be >> fully interoperable with other vendors=92 devices or clusters. The main >> challenge is to overcome the strict use of sequence numbers in both IPse= c >> and IKE, in HA 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: >> > > It is interesting work, and may well be valuable. > It is not a priority to me, and I would not have time to work on it. > I might read a WG FC, and I might respond to threads, if I came across > them. > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --=20 Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --0016e65b3ffc627d86047a252743 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I will also review this document.
Regards,
Daniel

On Fri, Dec 4, 2009 at 4:17 AM, Michael Richardson <mcr@sandelman.ca>= wrote:
Yaron Sheffer wrote:
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=92 devices or clusters. The main challenge = 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 initial= ly focused on defining the problem, rather than a particular solution.

=A0
Proposed starting point: http://tools.ietf.org/id/draft-nir-ip= secme-ipsecha-00.txt.

=A0
Please reply to the list:

It is interesting work, and may well be valuable.
It is not a priority to me, and I would not have time to work on it.
I might read a WG FC, and I might respond to threads, if I came across
them.




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



--
Daniel Miga= ult
Orange Labs -- Security
+33 6 70 72 69 58
--0016e65b3ffc627d86047a252743-- From latten@austin.ibm.com Mon Dec 7 08:25: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 80C403A6A7B for ; Mon, 7 Dec 2009 08:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.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 gbUEbwFZAp03 for ; Mon, 7 Dec 2009 08:25:46 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id 89AE33A68F7 for ; Mon, 7 Dec 2009 08:25:46 -0800 (PST) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id nB7GKjD8018025 for ; Mon, 7 Dec 2009 11:20:45 -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 nB7GPSPn1630386 for ; Mon, 7 Dec 2009 11:25:28 -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 nB7GPSrJ000403 for ; Mon, 7 Dec 2009 11:25:28 -0500 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nB7GPQBF032293 for ; Mon, 7 Dec 2009 11:25:27 -0500 Received: from [9.41.41.43] (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id nB7GPNUD034864; Mon, 7 Dec 2009 10:25:23 -0600 From: Joy Latten To: Nicolas Williams In-Reply-To: <20091204184621.GO773@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <1259950190.2717.270.camel@faith.austin.ibm.com> <20091204183946.GH17842@kebe.East.Sun.COM> <20091204184621.GO773@Sun.COM> Content-Type: text/plain Date: Mon, 07 Dec 2009 10:10:15 -0600 Message-Id: <1260202215.2717.300.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, serue@linux.vnet.ibm.com, gcwilson@us.ibm.com, tjaeger@cse.psu.edu Subject: Re: [IPsec] Proposed work item: Labelled IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: latten@austin.ibm.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 16:25:47 -0000 On Fri, 2009-12-04 at 12:46 -0600, Nicolas Williams wrote: > On Fri, Dec 04, 2009 at 01:39:46PM -0500, Dan McDonald wrote: > > The bigger point being missed by this thread, I think, is that it > > seems that any work in multi-level security needs to deal with > > successful interoperability. If it doesn't, there's little point in > > documenting a single-platform solution as part of a working group's > > output. > > +1. > > The proposed work item is, at first glance anyways, too SELinux- > specific. > > Note that SMACK encodes its labels as CIPSO labels, so a scheme that > uses CIPSO can possibly be used in SMACK and non-SMACK environments, and > possibly even be mixed. > Yes, I agree. Actually, we hoped the method we introduced was generic enough to accommodate both CIPSO and SMACK and any other MAC besides SELinux. We had hoped to do this by treating the security context as an opaque blob and introducing a DOI. I've actually discussed and collaborated about the "DOI" concept with Linux's CIPSO developer, and labeled nfs' developer. SMACK developer was included, but I do not recall if he said anything. We hoped that this "DOI" would not only be used by labeled IPsec, but CIPSO and others that use labels on the network. In a way, the "DOI" would help to identify the "mapping", thus perhaps allowing different MACs to talk to each other. Interoperability was and is a chief concern. However, I am sure the drafts most definitely can be improved upon. regards, Joy From latten@austin.ibm.com Mon Dec 7 08:29: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 D2DFF3A68A6 for ; Mon, 7 Dec 2009 08:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.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 o4woUcWMpoKx for ; Mon, 7 Dec 2009 08:29:09 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id E439A3A68EC for ; Mon, 7 Dec 2009 08:29:08 -0800 (PST) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e37.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nB7GRamB001926 for ; Mon, 7 Dec 2009 09:27:36 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nB7GScXP086864 for ; Mon, 7 Dec 2009 09:28:39 -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 nB7GSbY3029656 for ; Mon, 7 Dec 2009 09:28:37 -0700 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nB7GSbea029637; Mon, 7 Dec 2009 09:28:37 -0700 Received: from [9.41.41.43] (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id nB7GSaKI021004; Mon, 7 Dec 2009 10:28:36 -0600 From: Joy Latten To: Dan McDonald In-Reply-To: <20091204183946.GH17842@kebe.East.Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <1259950190.2717.270.camel@faith.austin.ibm.com> <20091204183946.GH17842@kebe.East.Sun.COM> Content-Type: text/plain Date: Mon, 07 Dec 2009 10:13:28 -0600 Message-Id: <1260202408.2717.303.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit 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 Reply-To: latten@austin.ibm.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 16:29:09 -0000 On Fri, 2009-12-04 at 13:39 -0500, Dan McDonald wrote: > On Fri, Dec 04, 2009 at 12:09:50PM -0600, Joy Latten wrote: > > > > > I believe they are becoming more mainstream. For example, SELinux and > > Simplified Mandatory Access Control (SMACK) in Linux Operating System > > and Mandatory Integrity Control in Windows Vista. > > You forgot OpenSolaris Trusted Extensions (and their brand-new IPsec > support): > > http://hub.opensolaris.org/bin/view/Project+txipsec/ > > The page needs an update, because the bits are now available for use. > My apologies. I am aware of this work. > The bigger point being missed by this thread, I think, is that it seems that > any work in multi-level security needs to deal with successful > interoperability. If it doesn't, there's little point in documenting a > single-platform solution as part of a working group's output. Yes, I agree. We may have missed the mark, but this was suppose to be a multi-platform solution. Interoperability was primary concern and reason to document. regards, Joy From briansw@microsoft.com Mon Dec 7 09: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 3FDDD3A6A8B for ; Mon, 7 Dec 2009 09:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 9DrGZhYcsVnS for ; Mon, 7 Dec 2009 09:23:24 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 382493A6A7E for ; Mon, 7 Dec 2009 09:23:24 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 7 Dec 2009 09:23:14 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Mon, 7 Dec 2009 09:23:14 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 7 Dec 2009 09:23:06 -0800 From: Brian Swander To: "ipsec@ietf.org" Thread-Topic: Proposed work item: WESP extensibility - YES Thread-Index: AQHKd2HvIhFS/EGXVkKpC00HSdY2jw== Date: Mon, 7 Dec 2009 17:23:04 +0000 Message-ID: <5E38DBF64E732C4C98512C53E1B14DDC299ACDA2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_5E38DBF64E732C4C98512C53E1B14DDC299ACDA2TK5EX14MBXW651w_" MIME-Version: 1.0 Subject: Re: [IPsec] Proposed work item: WESP extensibility - YES 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, 07 Dec 2009 17:23:28 -0000 --_000_5E38DBF64E732C4C98512C53E1B14DDC299ACDA2TK5EX14MBXW651w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am interested in WESP extensibility proceeding as a chartered work item. I will commit to reviewing the draft, and providing text. I don't need to= be a co-author. bs From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Sunday, November 29, 2009 9:21 AM To: ipsec@ietf.org Subject: [IPsec] Proposed work item: WESP extensibility 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_5E38DBF64E732C4C98512C53E1B14DDC299ACDA2TK5EX14MBXW651w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am interested in WESP extensibility proceeding as a charte= red work item.

 

I will commit to reviewing the draft, and providing text.&nb= sp;  I don’t need to be a co-author.

 

bs 

 

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Yaron Sheffer
Sent: Sunday, November 29, 2009 9:21 AM
To: ipsec@ietf.org
Subject: [IPsec] Proposed work item: WESP extensibility

 

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

 

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

 

Please reply to the list:

 

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

- Are you willing to contribute text to the draft?<= o:p>

- 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 g= ets 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!").

 

--_000_5E38DBF64E732C4C98512C53E1B14DDC299ACDA2TK5EX14MBXW651w_-- From kent@bbn.com Mon Dec 7 10:14: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 E60CA3A684E for ; Mon, 7 Dec 2009 10:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 O9HAA7xmGUJe for ; Mon, 7 Dec 2009 10:14:47 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 2EAB23A68DB for ; Mon, 7 Dec 2009 10:14:47 -0800 (PST) Received: from dhcp89-089-110.bbn.com ([128.89.89.110]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NHi6W-0007yK-9z; Mon, 07 Dec 2009 13:14:36 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <5E38DBF64E732C4C98512C53E1B14DDC2999E319@TK5EX14MBXW653.wingroup.windeplo y.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> <5E38DBF64E732C4C98512C53E1B14DDC2999E319@TK5EX14MBXW653.wingroup.windeplo y.ntdev.microsoft.com> Date: Mon, 7 Dec 2009 10:45:48 -0500 To: Brian Swander 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, 07 Dec 2009 18:14:48 -0000 Brian, I wasn't sure, form your brief description, whether you envisioned any crypto protection for this version of WESP. If not, then this added info is not protected and might be modified en route. This seems like a possibly dangerous feature, as it says that we are causing an intermediate system (e.g., a firewall) to make decisions on passing packets based on unauthenticated info. If the WESP data were protected it would raise questions about how we effect key distribution, and why this form of SA nesting is more attractive than the nested SA support that was pulled from IPsec as we went from 2401 to 4301. Steve From briansw@microsoft.com Mon Dec 7 10:25: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 024BA28C1D2 for ; Mon, 7 Dec 2009 10:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 5KSRWb0-yP+g for ; Mon, 7 Dec 2009 10:24:59 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id B1A9228C1AA for ; Mon, 7 Dec 2009 10:24:59 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 7 Dec 2009 10:24:49 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.0.639.20; Mon, 7 Dec 2009 10:24:49 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Mon, 7 Dec 2009 10:24:49 -0800 From: Brian Swander To: Stephen Kent Thread-Topic: [IPsec] Proposed work item: WESP extensibility Thread-Index: AQHKd2lYa0dZXBgdqEylx9vU1Rj7J5FZ5CBQ Date: Mon, 7 Dec 2009 18:24:48 +0000 Message-ID: <5E38DBF64E732C4C98512C53E1B14DDC299ACE4A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> <5E38DBF64E732C4C98512C53E1B14DDC2999E319@TK5EX14MBXW653.wingroup.windeplo y.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: 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, 07 Dec 2009 18:25:02 -0000 0 - option data does not change en-route. This option is included in the WESP ICV computation. We'll be using this flag, so this option will always be integrity protected= . I'm not sure what you mean by effecting key distribution. =20 In the integrity only case, the intermediaries can still see into the packe= t. In the fully encrypted ESP case, only the WESP extension will be visibl= e, and the intermediaries will have to trust the end systems to do the corr= ect marking. If that is not acceptable to a given deployment, the custome= r always has the policy option to disable this, and just have the end syste= ms send fully encrypted packets thru the now totally blind intermediaries l= ike we have today. bs -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Monday, December 07, 2009 7:46 AM To: Brian Swander Cc: ipsec@ietf.org Subject: Re: [IPsec] Proposed work item: WESP extensibility Brian, I wasn't sure, form your brief description, whether you envisioned=20 any crypto protection for this version of WESP. If not, then this=20 added info is not protected and might be modified en route. This=20 seems like a possibly dangerous feature, as it says that we are=20 causing an intermediate system (e.g., a firewall) to make decisions=20 on passing packets based on unauthenticated info. If the WESP data=20 were protected it would raise questions about how we effect key=20 distribution, and why this form of SA nesting is more attractive than=20 the nested SA support that was pulled from IPsec as we went from 2401=20 to 4301. Steve From jeanmichel.combes@gmail.com Mon Dec 7 10:40: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 44CD83A6808 for ; Mon, 7 Dec 2009 10:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 y6svadyqz0dP for ; Mon, 7 Dec 2009 10:40:33 -0800 (PST) Received: from mail-iw0-f201.google.com (mail-iw0-f201.google.com [209.85.223.201]) by core3.amsl.com (Postfix) with ESMTP id 59EDC3A6934 for ; Mon, 7 Dec 2009 10:40:33 -0800 (PST) Received: by iwn39 with SMTP id 39so2956806iwn.32 for ; Mon, 07 Dec 2009 10:40:20 -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=o8RZI0ytaSfGy2pGKsdZyc0nt/qmafD7TKW/DfJ6GK4=; b=pbF5YLFrRW06J6Eaz47B91+s0zcm3t4N+o1d18NuNwp98VtEMtUr/zVn4VTfkjcsIe Yn7HWfUvrdaS9hyoPXYlV6q80tkV6xPi2A44QBx3l6jQYxWTOgD+DD5w/5FqzJArmYhw W69DZeS+dfAreK+0hUek2y8AF60PaHIHTio5U= 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=Zvqz0OHuqx8V3ejlHnwUetdQIndF8lNTqHSBAx//yDB2n3jkFIJwr3OUMFB0YJTVWk ghpQyIAuSx10fJToFDQ2orQPlLwoHihjNxJBpmQvS3NYEAmdD6BveeBATsSdOviipO44 eqQ4srRhxQYntQl1hCLTNBrJUhJFH+ce+4+Wc= MIME-Version: 1.0 Received: by 10.231.122.139 with SMTP id l11mr28489ibr.53.1260211219998; Mon, 07 Dec 2009 10:40:19 -0800 (PST) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F1@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F1@il-ex01.ad.checkpoint.com> Date: Mon, 7 Dec 2009 19:40:19 +0100 Message-ID: <729b68be0912071040q90973b2o823c06eec4c2940b@mail.gmail.com> From: Jean-Michel Combes To: Yaron Sheffer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" Subject: Re: [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: Mon, 07 Dec 2009 18:40:34 -0000 Hi, After a discussion on the scope of this draft, I decided to change my opinion regarding what I said during the IETF meeting: now, I am ready to review the draft but no more to contribute to it. Best regards. JMC. 2009/11/29 Yaron Sheffer : > This work item will define the problem statement and requirements for a > solution that allows interoperable HA/LS device groups. Mixed-vendor > clusters are specifically out of scope; but single-vendor clusters should= be > fully interoperable with other vendors=92 devices or clusters. The main > challenge 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 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 > 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 fin= e > 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-expor= t > in IPsec - NO!"). > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > From kent@bbn.com Mon Dec 7 11:49: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 DFA6928C13A for ; Mon, 7 Dec 2009 11:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 qm7sZP9cOcEN for ; Mon, 7 Dec 2009 11:49:41 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 1385728C123 for ; Mon, 7 Dec 2009 11:49:41 -0800 (PST) Received: from dhcp89-089-110.bbn.com ([128.89.89.110]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NHjaM-0002Of-A2; Mon, 07 Dec 2009 14:49:30 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <5E38DBF64E732C4C98512C53E1B14DDC299ACE4A@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> <5E38DBF64E732C4C98512C53E1B14DDC2999E319@TK5EX14MBXW653.wingroup.windeplo y.ntdev.microsoft.com> <5E38DBF64E732C4C98512C53E1B14DDC299ACE4A@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> Date: Mon, 7 Dec 2009 14:43:07 -0500 To: Brian Swander 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, 07 Dec 2009 19:49:42 -0000 At 6:24 PM +0000 12/7/09, Brian Swander wrote: >0 - option data does not change en-route. This option is > included in the WESP ICV computation. > >We'll be using this flag, so this option will always be integrity protected. integrity protected for checking by the end system, but not verifiable by the intermediate system. >I'm not sure what you mean by effecting key distribution. what I meant was that the intermediate system cannot verify the WESP data. > In the integrity only case, the intermediaries can still see into >the packet. In the fully encrypted ESP case, only the WESP >extension will be visible, and the intermediaries will have to trust >the end systems to do the correct marking. And the end system will have to check another set of data, which may be complex. A while ago I noted a vulnerability in a prior version of WESP. Specifically, the (ultimate) recipient of the WESP packet has to verify that the Next Header and the HdrLen fields are consistent with the encapsulated content that it is processing. Othwewise, an attacker could change these fields to make the packet acceptable to an intermediate system but be different from what the recipient processes. This proposed extension would require that the recipient MUST also verify that the data being made available to intermediaries for packet inspection is consistent with the data being delivered as IPsec output. At the current level of specification, this additional processing is arbitrary. If I were a hardware IPsec vendor I would worry about the possible implications of this sort of facility. Steve From briansw@microsoft.com Mon Dec 7 11:51:14 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 3941228C1D3 for ; Mon, 7 Dec 2009 11:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Mk75powYsH1a for ; Mon, 7 Dec 2009 11:51:10 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id DABC43A67F7 for ; Mon, 7 Dec 2009 11:51:10 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 7 Dec 2009 11:51:00 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.0.639.20; Mon, 7 Dec 2009 11:50:54 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Mon, 7 Dec 2009 11:50:43 -0800 From: Brian Swander To: Stephen Kent Thread-Topic: [IPsec] Proposed work item: WESP extensibility Thread-Index: AQHKd2lYa0dZXBgdqEylx9vU1Rj7J5FZ5CBQgAAZK1A= Date: Mon, 7 Dec 2009 19:50:42 +0000 Message-ID: <5E38DBF64E732C4C98512C53E1B14DDC299ACFCE@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> <5E38DBF64E732C4C98512C53E1B14DDC2999E319@TK5EX14MBXW653.wingroup.windeplo y.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: 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, 07 Dec 2009 19:51:14 -0000 In case it wasn't clear for the earlier WESP discussions, we need this to a= lso work with simple transport mode: i.e. not just transport mode inside tu= nnels terminating at various infrastructure, and not just in tunnel mode. = =20 The transport nesting from 2401 doesn't give us what this extension proposa= l does. bs -----Original Message----- From: Brian Swander=20 Sent: Monday, December 07, 2009 10:25 AM To: 'Stephen Kent' Cc: ipsec@ietf.org Subject: RE: [IPsec] Proposed work item: WESP extensibility 0 - option data does not change en-route. This option is included in the WESP ICV computation. We'll be using this flag, so this option will always be integrity protected= . I'm not sure what you mean by effecting key distribution. =20 In the integrity only case, the intermediaries can still see into the packe= t. In the fully encrypted ESP case, only the WESP extension will be visibl= e, and the intermediaries will have to trust the end systems to do the corr= ect marking. If that is not acceptable to a given deployment, the custome= r always has the policy option to disable this, and just have the end syste= ms send fully encrypted packets thru the now totally blind intermediaries l= ike we have today. bs -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Monday, December 07, 2009 7:46 AM To: Brian Swander Cc: ipsec@ietf.org Subject: Re: [IPsec] Proposed work item: WESP extensibility Brian, I wasn't sure, form your brief description, whether you envisioned=20 any crypto protection for this version of WESP. If not, then this=20 added info is not protected and might be modified en route. This=20 seems like a possibly dangerous feature, as it says that we are=20 causing an intermediate system (e.g., a firewall) to make decisions=20 on passing packets based on unauthenticated info. If the WESP data=20 were protected it would raise questions about how we effect key=20 distribution, and why this form of SA nesting is more attractive than=20 the nested SA support that was pulled from IPsec as we went from 2401=20 to 4301. Steve From dharkins@lounge.org Mon Dec 7 12:01: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 DBA2C28B23E for ; Mon, 7 Dec 2009 12:01:32 -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 cJ-xcXc9ckPm for ; Mon, 7 Dec 2009 12:01:31 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 6D6FC3A684F for ; Mon, 7 Dec 2009 12:01:31 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4A5D6102240AE; Mon, 7 Dec 2009 12:01:21 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 7 Dec 2009 12:01:21 -0800 (PST) Message-ID: <0a6075be7b094d88bea559bc9355484b.squirrel@www.trepanning.net> In-Reply-To: <13045.1260189274@marajade.sandelman.ca> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> <4B187F98.5040608@sandelman.ca> <2f0d03efe2821829e89f06264d75f60b.squirrel@www.trepanning.net> <13045.1260189274@marajade.sandelman.ca> Date: Mon, 7 Dec 2009 12:01:21 -0800 (PST) From: "Dan Harkins" To: "Michael Richardson" 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, Dan Harkins 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, 07 Dec 2009 20:01:33 -0000 Hi Michael, Here's some figures from I-Ds to illustrate what I'm talking about. Some of the overhead is because both of these are technically client- server protocols but IKEv2 is initiated by the initiator/client and EAP is initiated by the responder/server (due to fact that it's design was for PPP and authentication begins after "link up" notification to the server-- a call is received at a modem bank, an 802.11 association completed, etc). Both of these end with a message from the responder/ server so to fit these things together it requires some overhead beyond a simple +1 message. Here's the IKEv2 message exchange for EAP-only from the I-D: Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni, [N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP)] --> <-- HDR, SAr1, KEr, Nr, [CERTREQ], [N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP)] HDR, SK { IDi, [IDr], SAi2, TSi, TSr, N(EAP_ONLY_AUTHENTICATION), [CP(CFG_REQUEST)] } --> <-- HDR, SK { IDr, EAP(Request) } HDR, SK { EAP(Response) } --> <-- HDR, SK { EAP(Request) } HDR, SK { EAP(Response) } --> <-- HDR, SK { EAP(Success) } HDR, SK { AUTH } --> <-- HDR, SK { AUTH, SAr2, TSi, TSr, [CP(CFG_REPLY] } Notice there are 3 messages for IKEv2 handling before the EAP stuff and then 2 more messages after the EAP stuff. So it's 5 plus whatever the EAP method adds. What the EAP method adds is indeterminate and depends on the particular EAP method used (it shows 5 but that's just an example). So let's plug in an EAP method that has been proposed for use in EAP-only, EAP-pwd (EAP-EKE has also been proposed but it is exactly the same). This is figure 2 from the EAP-pwd I-D (soon to be an RFC!): +--------+ +--------+ | | EAP-pwd-ID/Request | | | EAP |<------------------------------------| EAP | | peer | | server | | | EAP-pwd-ID/Response | | | |------------------------------------>| | | | | | | | EAP-pwd-Commit/Request | | | |<------------------------------------| | | | | | | | EAP-pwd-Commit/Response | | | |------------------------------------>| | | | | | | | EAP-pwd-Confirm/Request | | | |<------------------------------------| | | | | | | | EAP-pwd-Confirm/Response | | | |------------------------------------>| | | | | | | | EAP-Success | | | |<------------------------------------| | +--------+ +--------+ So you see this EAP method does 3 request-response exchanges then a success. That's 7 messages and 7 + 5 = 12 messages to do this exchange using the EAP-only technique. Here's the same underlying key exchange done in SPSK, figure 4 from the I-D: Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, Commit, [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, Commit, Confirm} HDR, SK {Confirm, AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr} That's 6 messages. So we have 6 messages for SPSK and 12 for EAP-only plus EAP method. A more uncharitable, but arguably accurate, way of looking at this is to note that the IKEv2 exchange, by itself, is 4 messages so SPSK only adds 2 while EAP-only plus an EAP method adds 8. So really EAP-only plus an EAP method is _4 times the number of messages_ of SPSK, not double. And any channel bindings solution necessary for EAP-only will just increase the number of messages. Dan. On Mon, December 7, 2009 4:34 am, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "Dan" == Dan Harkins writes: > >>> 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, > >> Does it double, or does it really just "n+1", which is doubling > >> if the rest of the protocol has "n=1"? I also wonder if this is > >> really a sufficiently compelling reason to have two sets of code. > > Dan> For the proposed EAP methods, EAP-EKE and EAP-PWD, it really > Dan> is double. I don't think it's possible to do the kind of > Dan> exchange that's required-- mutual authentication, key > Dan> generation-- in n=1 messages. > > Dan> If you look at the SPSK draft, it is doing essentially the > Dan> same exchange as EAP-PWD and doing it in 6 messages total. If > Dan> you do EAP-only plus EAP-PWD (or EAP-only plus EAP-EKE, doesn't > Dan> matter) it's 12 messages total. > > Is this 6 messages, times 2 directions? > Or just 6 messages. I can not quite see why the EAP encapsulation > *doubles* the number of round trips. I can see how it might increase it > by 1, due to need to do some EAP thing. > > Dan> One of the big problems with EAP is that it is a completely > Dan> underspecified shim. That's why every EAP method needs to > Dan> roll-its-own identity exchange (the identity obtained by EAP is > Dan> not suitable for authentication purposes) and roll-its-own > > Yes, I completed understand this problem. > I'm suggesting that if we care for channel bindings for EAP, that we > (security people who care) need to solve this once and for all. > > Dan> Keep in mind, though, that however channel bindings gets > Dan> solved, it is only going to further increase the number of > Dan> messages necessary to get what you can get in SPSK in 6, and > Dan> only 6, messages :-) > > Again, I do not know why it has to double the number of round trips. > I see one extra round trip caused by the EAP-ID process, and then it's > the same number both ways. > > Perhaps you can draw a time-sequence diagram for this to convince me? > > - -- > ] 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 > > iQEVAwUBSxz2WICLcPvd0N1lAQInLQgAiLf0gKq8aHRAKq4r7oaAUXGYYqt9q3Kk > g+KQYGjBrTmfXCEOYziSNonIN7XrjX4ePn7LHWk9AsWWh22y/esYF3Y5n4fkhktV > an2SY9AE9CYz2PsXACZut2oRAM/YtHSeSnvvPbTzQ6i5bYoVeJqwthM4XIhpoFL1 > 6J9wY2owu1JzPI5KZeDDefbZscNjI7JVvHvI5deR8qtdykn2W2oOaxhaEEEpPY7p > gIwkBIhFsnwSslF2sWUPmosDI/CTmo+KKFCa0QbXOP/D93raAgnNmKdDno9AwGjU > FgAXkh/Z7102hkytkc64D6Lg7wU0fhxo+T+m5OkKV3RlfszjSQe9YA== > =nC7X > -----END PGP SIGNATURE----- > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From Nicolas.Williams@sun.com Mon Dec 7 13:29: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 E384B28C1B7 for ; Mon, 7 Dec 2009 13:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.585 X-Spam-Level: X-Spam-Status: No, score=-5.585 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_72=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 HI3zEBy-qvfS for ; Mon, 7 Dec 2009 13:29:59 -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 32F423A67B0 for ; Mon, 7 Dec 2009 13:29:58 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB7LTlZs000043 for ; Mon, 7 Dec 2009 21:29:47 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nB7LTl3u012566 for ; Mon, 7 Dec 2009 14:29:47 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nB7L2skc001015; Mon, 7 Dec 2009 15:02:54 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB7L2oWW001014; Mon, 7 Dec 2009 15:02:50 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 7 Dec 2009 15:02:48 -0600 From: Nicolas Williams To: Joy Latten Message-ID: <20091207210247.GJ861@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <1259950190.2717.270.camel@faith.austin.ibm.com> <20091204183946.GH17842@kebe.East.Sun.COM> <20091204184621.GO773@Sun.COM> <1260202215.2717.300.camel@faith.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1260202215.2717.300.camel@faith.austin.ibm.com> User-Agent: Mutt/1.5.7i Cc: ipsec@ietf.org, serue@linux.vnet.ibm.com, gcwilson@us.ibm.com, tjaeger@cse.psu.edu 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, 07 Dec 2009 21:30:00 -0000 On Mon, Dec 07, 2009 at 10:10:15AM -0600, Joy Latten wrote: > > The proposed work item is, at first glance anyways, too SELinux- > > specific. > > > > Note that SMACK encodes its labels as CIPSO labels, so a scheme that > > uses CIPSO can possibly be used in SMACK and non-SMACK environments, and > > possibly even be mixed. > > Yes, I agree. > > Actually, we hoped the method we introduced was generic enough to > accommodate both CIPSO and SMACK and any other MAC besides SELinux. > We had hoped to do this by treating the security context as an opaque > blob and introducing a DOI. > > I've actually discussed and collaborated about the "DOI" concept with > Linux's CIPSO developer, and labeled nfs' developer. SMACK developer > was included, but I do not recall if he said anything. We hoped that > this "DOI" would not only be used by labeled IPsec, but CIPSO and others > that use labels on the network. In a way, the "DOI" would help > to identify the "mapping", thus perhaps allowing different MACs to talk > to each other. Interoperability was and is a chief concern. However, > I am sure the drafts most definitely can be improved upon. See the long threads on related topics on the SAAG and NFSv4 lists with subjects: - Common labeled security (comment on CALIPSO, labeled NFSv4) - Why the IETF should care about labeled?ne tworking (was:CIPSO implementations) - Secdir Review of draft-stjohns-sipso-05 I'm not sure what the best way forward is, but here are some thoughts: - A notification indicating what DOI(s) are supported by the sender might help. Not that I expect that any system will participate in multiple DOIs, but then, IIRC SMACK supports mappings of SMACK labels (which hijack a level in CIPSO) to non-SMACK CIPSO labels for interop, for example. This idea is probably not too farfetched. - A label type in addition to DOI. Not that I expect a single DOI to use multiple label types, but at least one can then parse the label payload according to the stated type rather than having to find the right type for the given DOI. - Text on the encodings of specific label types' labels. Particularly I think you need to have normative references to the relevant RFCs and other work for the 'core' label types. - Text on implicit labeling. Strictly speaking this is not necessary, since implicit labeling is a purely local matter. - Perhaps a notification indicating the label/label-range/set assigned by the sender to a given child SA. This would be useful for diagnostic purposes in all cases, particularly implicit labeling cases, but it should be strictly optional. Label ranges/sets would be used only for unnarrowed SAs, obviously. Narrowed SAs should have a single label. - Similarly, a notification indicating whether the sender understood the DOI asserted by the peer. - A separate I-D for adding labeling information to certificates. Nico -- From paul.moore@hp.com Mon Dec 7 13:38: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 C9F493A6915 for ; Mon, 7 Dec 2009 13:38:04 -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=[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 k3JMJ71aVs+W for ; Mon, 7 Dec 2009 13:38:03 -0800 (PST) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by core3.amsl.com (Postfix) with ESMTP id BAEA83A672E for ; Mon, 7 Dec 2009 13:38:03 -0800 (PST) Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g1t0027.austin.hp.com (Postfix) with ESMTP id 0DBF4382E5; Mon, 7 Dec 2009 21:37:53 +0000 (UTC) Received: from ldl (linux.corp.hp.com [15.11.146.101]) by g1t0039.austin.hp.com (Postfix) with ESMTP id 82FBF34002; Mon, 7 Dec 2009 21:37:52 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl (Postfix) with ESMTP id 6DD54CF000F; Mon, 7 Dec 2009 14:37:52 -0700 (MST) Received: from ldl ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcWmcJSKJ1aG; Mon, 7 Dec 2009 14:37:52 -0700 (MST) Received: from flek.localnet (squirrel.fc.hp.com [15.11.146.57]) by ldl (Postfix) with ESMTP id 317B5CF0007; Mon, 7 Dec 2009 14:37:52 -0700 (MST) From: Paul Moore Organization: Hewlett-Packard To: ipsec@ietf.org, latten@austin.ibm.com Date: Mon, 7 Dec 2009 16:37:50 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r2; KDE/4.3.4; i686; ; ) References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <20091204184621.GO773@Sun.COM> <1260202215.2717.300.camel@faith.austin.ibm.com> In-Reply-To: <1260202215.2717.300.camel@faith.austin.ibm.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912071637.50881.paul.moore@hp.com> Cc: Nicolas Williams , David Patrick Quigley , tjaeger@cse.psu.edu, gcwilson@us.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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, 07 Dec 2009 21:38:04 -0000 On Monday 07 December 2009 11:10:15 am Joy Latten wrote: > On Fri, 2009-12-04 at 12:46 -0600, Nicolas Williams wrote: > > On Fri, Dec 04, 2009 at 01:39:46PM -0500, Dan McDonald wrote: > > > The bigger point being missed by this thread, I think, is that it > > > seems that any work in multi-level security needs to deal with > > > successful interoperability. If it doesn't, there's little point in > > > documenting a single-platform solution as part of a working group's > > > output. > > > > +1. > > > > The proposed work item is, at first glance anyways, too SELinux- > > specific. > > > > Note that SMACK encodes its labels as CIPSO labels, so a scheme that > > uses CIPSO can possibly be used in SMACK and non-SMACK environments, and > > possibly even be mixed. > > Yes, I agree. > > Actually, we hoped the method we introduced was generic enough to > accommodate both CIPSO and SMACK and any other MAC besides SELinux. > We had hoped to do this by treating the security context as an opaque > blob and introducing a DOI. > > I've actually discussed and collaborated about the "DOI" concept with > Linux's CIPSO developer, and labeled nfs' developer. SMACK developer > was included, but I do not recall if he said anything. We hoped that > this "DOI" would not only be used by labeled IPsec, but CIPSO and others > that use labels on the network. In a way, the "DOI" would help > to identify the "mapping", thus perhaps allowing different MACs to talk > to each other. Interoperability was and is a chief concern. However, > I am sure the drafts most definitely can be improved upon. At the SELinux Developer's Summit a few months ago there was a bit of a general discussion about DOIs and label representation between myself (Linux labeled networking), Dave Quigley (labeled NFS, added to CC) and Casey Schaufler (SMACK, added to CC) as well as a few others. As could be expected, there still seems to be quite a bit of confusion around the best way to interoperate two different labeled security mechanisms. While I believe everyone agrees that tagging network security labels with a DOI is important, there seems to be little consensus beyond that (at least at the summit discussion). Since Dave has an immediate need, he is working on a solution for labeled NFS which uses three values: a format token, a DOI token, a variable length label blob. Arguably the format and DOI tokens could be combined but I understand the desire to keep things flexible at this point. It is my understanding that Dave plans to first support a CALIPSO-like format simply because it is well defined and the level/compartment-bitmap format seems to be easiest to internalize across the different labeled security mechanisms. I've mentioned all of this before, but my main fundamental concern with the proposed labeled IPsec spec is that not everyone who wants labeled networking wants IPsec. Look at the CALIPSO effort as an example, it was created because users needed a way to communicate security labels over the network but did not want or need IPsec (they already had security mechanisms in place and IPsec was seen as an unnecessary burden, especially for the smaller devices). What I would really like to see is a spec providing for a general security label to be assigned per-packet, similar to CALIPSO but without the reliance on MLS (imagine the FIPS-188 freeform tag). This way users who only need to labeling support are not required to go through the IPsec end node processing while those users who do not already have a fully trusted network can run IPsec on the untrusted links to secure the packet, the label and their binding. -- paul moore linux @ hp From turners@ieca.com Mon Dec 7 13:40: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 2348E28C208 for ; Mon, 7 Dec 2009 13:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.654 X-Spam-Level: X-Spam-Status: No, score=-2.654 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 75V7F+iLto3T for ; Mon, 7 Dec 2009 13:40:19 -0800 (PST) Received: from smtp100.biz.mail.re2.yahoo.com (smtp100.biz.mail.re2.yahoo.com [206.190.52.46]) by core3.amsl.com (Postfix) with SMTP id 1BE6828C1D5 for ; Mon, 7 Dec 2009 13:40:19 -0800 (PST) Received: (qmail 17854 invoked from network); 7 Dec 2009 21:40:06 -0000 Received: from pool-71-191-15-124.washdc.east.verizon.net (turners@71.191.15.124 with plain) by smtp100.biz.mail.re2.yahoo.com with SMTP; 07 Dec 2009 13:40:06 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: FwXORC4VM1naBteJmmGd3uL.pDhH8NKe.1_DLasJdq.0q0a.1u.UvyX1RCO6OAJXGMw2onmjjmvAUp2ddkD_VjFGSCer.5XhBjDxiQ6Kq0ju8.IxzQNdAsioIMGf5Nw28a.Y4OriVAKkIrbNyNMqIvK_nqhqBNtiW3q.MjhURvnosKhDDgyYNzlljfYoEds4LUs1IV7G_Ee4OkJpaO9t8PfVMxr1IyBjH5VhxKzdzsY6Q_WBjohWuNFpecTDWb_OzyprsFnt8nJVp_8VO0NE4w0xroDaVTTbkAzYYfEaqYDEQhING._7X_XcqPa_k7U0FAd7i1ah.0ofIaS9pWVfcJH9rX8K2CIEjMd0vbrFp_KK1XivHvpSBnOYF84PohEPSS5LtlC8y56S58Pg5sMtGFX8Ht0XanIhrltWBFf9jVffBNiHxS9qsmH2NRZg5EHgyquhP0HcwC0UUcp4tzNzvE2H.Mq3cj40FlcLzT9WmVD8NGfc9O_Wg0cDYES5SuL0AuXSPkG3JAdE2xnh8ZPIelkIyfndt6_AaPl8XE1emiq37PvV4rsmg20- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1D7635.5030200@ieca.com> Date: Mon, 07 Dec 2009 16:40:05 -0500 From: Sean Turner User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Nicolas Williams References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <1259950190.2717.270.camel@faith.austin.ibm.com> <20091204183946.GH17842@kebe.East.Sun.COM> <20091204184621.GO773@Sun.COM> <1260202215.2717.300.camel@faith.austin.ibm.com> <20091207210247.GJ861@Sun.COM> In-Reply-To: <20091207210247.GJ861@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, serue@linux.vnet.ibm.com, gcwilson@us.ibm.com, tjaeger@cse.psu.edu, Joy Latten 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, 07 Dec 2009 21:40:20 -0000 Nicolas Williams wrote: ...snip... > - A separate I-D for adding labeling information to certificates. Are you suggesting that you'd label a certificate? I suspect what you're talking about is including what labels a user/device supports and the clearance attribute in the RFC 3281 update (http://tools.ietf.org/html/draft-ietf-pkix-3281update-05) is defined for just such a purpose. spt From kent@bbn.com Mon Dec 7 13:43: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 EC8CB28C1DB for ; Mon, 7 Dec 2009 13:43:01 -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 EMUVouLmjwNV for ; Mon, 7 Dec 2009 13:43:01 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 401F228C0E4 for ; Mon, 7 Dec 2009 13:43:01 -0800 (PST) Received: from dhcp89-089-110.bbn.com ([128.89.89.110]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NHlM2-0005jz-A9; Mon, 07 Dec 2009 16:42:50 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <5E38DBF64E732C4C98512C53E1B14DDC299ACFCE@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> <5E38DBF64E732C4C98512C53E1B14DDC2999E319@TK5EX14MBXW653.wingroup.windeplo y.ntdev.microsoft.com> <5E38DBF64E732C4C98512C53E1B14DDC299ACFCE@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> Date: Mon, 7 Dec 2009 16:42:43 -0500 To: Brian Swander 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, 07 Dec 2009 21:43:02 -0000 At 7:50 PM +0000 12/7/09, Brian Swander wrote: >In case it wasn't clear for the earlier WESP discussions, we need >this to also work with simple transport mode: i.e. not just >transport mode inside tunnels terminating at various infrastructure, >and not just in tunnel mode. > >The transport nesting from 2401 doesn't give us what this extension >proposal does. > >bs Understood. And I agree that transport mode inside of a tunnel does not provide comparable functionality. Steve From kent@bbn.com Mon Dec 7 14:16: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 CF69B3A6782 for ; Mon, 7 Dec 2009 14:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 VYTvSJTev2h1 for ; Mon, 7 Dec 2009 14:16:42 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id F27653A63EB for ; Mon, 7 Dec 2009 14:16:41 -0800 (PST) Received: from dhcp89-089-110.bbn.com ([128.89.89.110]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NHlsb-0006f8-Aq; Mon, 07 Dec 2009 17:16:29 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <200912071637.50881.paul.moore@hp.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <20091204184621.GO773@Sun.COM> <1260202215.2717.300.camel@faith.austin.ibm.com> <200912071637.50881.paul.moore@hp.com> Date: Mon, 7 Dec 2009 17:16:26 -0500 To: Paul Moore From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Nicolas Williams , David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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, 07 Dec 2009 22:16:43 -0000 Paul, From your comments it seems as though an IP option would be preferable, as it is not IP-sec-specific, and it an be protected if needed, in the IPSec context, e.g., via tunneling. Steve From Nicolas.Williams@sun.com Mon Dec 7 14: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 A42FD3A6834 for ; Mon, 7 Dec 2009 14:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.89 X-Spam-Level: X-Spam-Status: No, score=-5.89 tagged_above=-999 required=5 tests=[AWL=0.156, 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 sJzWUZcDuig1 for ; Mon, 7 Dec 2009 14:25:41 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id C09F23A67B2 for ; Mon, 7 Dec 2009 14:25:41 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB7MPV8R015076 for ; Mon, 7 Dec 2009 22:25:31 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nB7MPVdm046246 for ; Mon, 7 Dec 2009 15:25:31 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nB7LpDeB001211; Mon, 7 Dec 2009 15:51:13 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB7LpBTb001210; Mon, 7 Dec 2009 15:51:12 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 7 Dec 2009 15:51:10 -0600 From: Nicolas Williams To: Paul Moore Message-ID: <20091207215110.GO861@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <20091204184621.GO773@Sun.COM> <1260202215.2717.300.camel@faith.austin.ibm.com> <200912071637.50881.paul.moore@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200912071637.50881.paul.moore@hp.com> User-Agent: Mutt/1.5.7i Cc: David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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, 07 Dec 2009 22:25:42 -0000 On Mon, Dec 07, 2009 at 04:37:50PM -0500, Paul Moore wrote: > At the SELinux Developer's Summit a few months ago there was a bit of a > general discussion about DOIs and label representation between myself (Linux > labeled networking), Dave Quigley (labeled NFS, added to CC) and Casey > Schaufler (SMACK, added to CC) as well as a few others. As could be expected, > there still seems to be quite a bit of confusion around the best way to > interoperate two different labeled security mechanisms. While I believe > everyone agrees that tagging network security labels with a DOI is important, > there seems to be little consensus beyond that (at least at the summit > discussion). Since Dave has an immediate need, he is working on a solution > for labeled NFS which uses three values: a format token, a DOI token, a > variable length label blob. Arguably the format and DOI tokens could be > combined but I understand the desire to keep things flexible at this point. > It is my understanding that Dave plans to first support a CALIPSO-like format > simply because it is well defined and the level/compartment-bitmap format > seems to be easiest to internalize across the different labeled security > mechanisms. I agree that {format, DOI, blob} is a good place to start. > I've mentioned all of this before, but my main fundamental concern with the > proposed labeled IPsec spec is that not everyone who wants labeled networking > wants IPsec. Look at the CALIPSO effort as an example, it was created because > users needed a way to communicate security labels over the network but did not > want or need IPsec (they already had security mechanisms in place and IPsec > was seen as an unnecessary burden, especially for the smaller devices). What > I would really like to see is a spec providing for a general security label to > be assigned per-packet, similar to CALIPSO but without the reliance on MLS > (imagine the FIPS-188 freeform tag). This way users who only need to labeling > support are not required to go through the IPsec end node processing while > those users who do not already have a fully trusted network can run IPsec on > the untrusted links to secure the packet, the label and their binding. But this is not a reason to oppose labelled IPsec. It's a reason to want an extended IP packet labelling standard. The two should support much the same semantics where possible, though IPsec can provide more functionality (e.g., derive labels from authentication elements). Nico -- From paul.moore@hp.com Mon Dec 7 14:26: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 C146D3A694E for ; Mon, 7 Dec 2009 14:26:19 -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=[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 t7v4s1vI0inN for ; Mon, 7 Dec 2009 14:26:18 -0800 (PST) Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) by core3.amsl.com (Postfix) with ESMTP id 576AD3A67B2 for ; Mon, 7 Dec 2009 14:26:18 -0800 (PST) Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com [16.228.8.142]) by g5t0007.atlanta.hp.com (Postfix) with ESMTP id 203CD14315; Mon, 7 Dec 2009 22:26:07 +0000 (UTC) Received: from ldl (linux.corp.hp.com [15.11.146.101]) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id 9EDD414024; Mon, 7 Dec 2009 22:26:06 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl (Postfix) with ESMTP id 5B35DCF000F; Mon, 7 Dec 2009 15:26:06 -0700 (MST) Received: from ldl ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UCf2TJdM7fb; Mon, 7 Dec 2009 15:26:06 -0700 (MST) Received: from flek.localnet (squirrel.fc.hp.com [15.11.146.57]) by ldl (Postfix) with ESMTP id E506FCF0007; Mon, 7 Dec 2009 15:26:05 -0700 (MST) From: Paul Moore Organization: Hewlett-Packard To: Stephen Kent Date: Mon, 7 Dec 2009 17:26:04 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r2; KDE/4.3.4; i686; ; ) References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <200912071637.50881.paul.moore@hp.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912071726.04604.paul.moore@hp.com> Cc: Nicolas Williams , David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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, 07 Dec 2009 22:26:20 -0000 On Monday 07 December 2009 05:16:26 pm Stephen Kent wrote: > Paul, > > From your comments it seems as though an IP option would be > preferable, as it is not IP-sec-specific, and it an be protected if > needed, in the IPSec context, e.g., via tunneling. Exactly. Since the option would be immutable it could also be protected with AH allowing for intermediate nodes to apply security policy based on the label. Although I do understand AH is falling out of favor. -- paul moore linux @ hp From Nicolas.Williams@sun.com Mon Dec 7 14: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 E84753A6837 for ; Mon, 7 Dec 2009 14:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.897 X-Spam-Level: X-Spam-Status: No, score=-5.897 tagged_above=-999 required=5 tests=[AWL=0.149, 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 jBPBZ5bG+GFi for ; Mon, 7 Dec 2009 14:40:33 -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 13CB03A67FB for ; Mon, 7 Dec 2009 14:40:32 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB7MeJuQ027759 for ; Mon, 7 Dec 2009 22:40:23 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nB7MeJnI054885 for ; Mon, 7 Dec 2009 15:40:19 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nB7LhWRV001205; Mon, 7 Dec 2009 15:43:32 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB7LhVdE001204; Mon, 7 Dec 2009 15:43:32 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 7 Dec 2009 15:43:30 -0600 From: Nicolas Williams To: Sean Turner Message-ID: <20091207214330.GN861@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <1259950190.2717.270.camel@faith.austin.ibm.com> <20091204183946.GH17842@kebe.East.Sun.COM> <20091204184621.GO773@Sun.COM> <1260202215.2717.300.camel@faith.austin.ibm.com> <20091207210247.GJ861@Sun.COM> <4B1D7635.5030200@ieca.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B1D7635.5030200@ieca.com> User-Agent: Mutt/1.5.7i Cc: ipsec@ietf.org, serue@linux.vnet.ibm.com, gcwilson@us.ibm.com, tjaeger@cse.psu.edu, Joy Latten 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, 07 Dec 2009 22:40:34 -0000 On Mon, Dec 07, 2009 at 04:40:05PM -0500, Sean Turner wrote: > Nicolas Williams wrote: > ...snip... > > - A separate I-D for adding labeling information to certificates. > > Are you suggesting that you'd label a certificate? I suspect what > you're talking about is including what labels a user/device supports and > the clearance attribute in the RFC 3281 update > (http://tools.ietf.org/html/draft-ietf-pkix-3281update-05) is defined > for just such a purpose. Ah, I didn't know that a clearance attribute existed already. Yes, that's exactly what I had in mind. (Incidentally, the I-D you mention has a referenced to X.501-1993, but it doesn't appear in the References sections.) Nico -- From paul.moore@hp.com Mon Dec 7 14:54: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 DD1E33A6957 for ; Mon, 7 Dec 2009 14:54:13 -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=[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 uCDnnKiZWVpk for ; Mon, 7 Dec 2009 14:54:13 -0800 (PST) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by core3.amsl.com (Postfix) with ESMTP id F13413A682B for ; Mon, 7 Dec 2009 14:54:12 -0800 (PST) Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g1t0029.austin.hp.com (Postfix) with ESMTP id 5B070380A9; Mon, 7 Dec 2009 22:54:02 +0000 (UTC) Received: from ldl (linux.corp.hp.com [15.11.146.101]) by g1t0039.austin.hp.com (Postfix) with ESMTP id 1FF7834055; Mon, 7 Dec 2009 22:54:02 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl (Postfix) with ESMTP id EA3F7CF0010; Mon, 7 Dec 2009 15:54:01 -0700 (MST) Received: from ldl ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah5JdYTI5Kby; Mon, 7 Dec 2009 15:54:01 -0700 (MST) Received: from flek.localnet (squirrel.fc.hp.com [15.11.146.57]) by ldl (Postfix) with ESMTP id 60516CF0007; Mon, 7 Dec 2009 15:54:01 -0700 (MST) From: Paul Moore Organization: Hewlett-Packard To: Nicolas Williams Date: Mon, 7 Dec 2009 17:53:59 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r2; KDE/4.3.4; i686; ; ) References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <200912071637.50881.paul.moore@hp.com> <20091207215110.GO861@Sun.COM> In-Reply-To: <20091207215110.GO861@Sun.COM> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912071753.59496.paul.moore@hp.com> Cc: David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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, 07 Dec 2009 22:54:14 -0000 On Monday 07 December 2009 04:51:10 pm Nicolas Williams wrote: > On Mon, Dec 07, 2009 at 04:37:50PM -0500, Paul Moore wrote: > > I've mentioned all of this before, but my main fundamental concern with > > the proposed labeled IPsec spec is that not everyone who wants labeled > > networking wants IPsec. Look at the CALIPSO effort as an example, it was > > created because users needed a way to communicate security labels over > > the network but did not want or need IPsec (they already had security > > mechanisms in place and IPsec was seen as an unnecessary burden, > > especially for the smaller devices). What I would really like to see is > > a spec providing for a general security label to be assigned per-packet, > > similar to CALIPSO but without the reliance on MLS (imagine the FIPS-188 > > freeform tag). This way users who only need to labeling support are not > > required to go through the IPsec end node processing while those users > > who do not already have a fully trusted network can run IPsec on the > > untrusted links to secure the packet, the label and their binding. > > But this is not a reason to oppose labelled IPsec. It's a reason to > want an extended IP packet labelling standard. Why spend the time and effort to develop two specifications (not to mention the actual implementations) when one IP option based labeling spec could solve both use cases at the same time? > The two should support much the same semantics where possible, though IPsec > can provide more functionality (e.g., derive labels from authentication > elements). I'm not exactly sure how you envision this working, but for the sake of argument lets say that for the certificate derived security labels node A sends a cert to node B as part of the IKE negotiation which node B then uses to derive a security label for the SA matching node A's traffic (indirectly labeling node A's traffic as it is received). This is an interesting scenario because it doesn't actually involve any security labels being transfered over the network, either via IKE or AH/ESP; in fact, if you implement it correctly you could probably achieve this today using a standard IPsec implementation on node A (only node B and its IPsec implementation need to be label aware). I hasn't thought about this too much until just now, but I would almost consider this case to be a method of fallback labeling; instead of deriving the security label from an IP address you derive it from an authentication token. Do you know of users who need to network peer security labels based on authentication tokens or are you simply posting this as an example? Also, do you see the need for user auth tokens, machine auth tokens or both? -- paul moore linux @ hp From danmcd@sun.com Mon Dec 7 15:20: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 BE6AA3A699E for ; Mon, 7 Dec 2009 15:20: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 8KJ5NK7EhdF6 for ; Mon, 7 Dec 2009 15:20:46 -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 2C86D3A6953 for ; Mon, 7 Dec 2009 15:20:46 -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 nB7NKaMw006909 for ; Mon, 7 Dec 2009 23:20:36 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 <0KUB003001U0EQ00@mail-amer.sun.com> for ipsec@ietf.org; Mon, 07 Dec 2009 16:20: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 <0KUB006SK267GDE0@mail-amer.sun.com>; Mon, 07 Dec 2009 16:20:35 -0700 (MST) Date: Mon, 07 Dec 2009 18:20:31 -0500 From: Dan McDonald In-reply-to: <200912071753.59496.paul.moore@hp.com> Sender: Dan.McDonald@sun.com To: Paul Moore Message-id: <20091207232031.GA6316@mactavish> Organization: Sun Microsystems, Inc. - Solaris Networking & Security References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <200912071637.50881.paul.moore@hp.com> <20091207215110.GO861@Sun.COM> <200912071753.59496.paul.moore@hp.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Nicolas Williams , David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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, 07 Dec 2009 23:20:47 -0000 On Mon, Dec 07, 2009 at 05:53:59PM -0500, Paul Moore wrote: > > But this is not a reason to oppose labelled IPsec. It's a reason to > > want an extended IP packet labelling standard. > > Why spend the time and effort to develop two specifications (not to mention > the actual implementations) when one IP option based labeling spec could solve > both use cases at the same time? Because sometimes you want to put sensitive traffic on public networks, without the overhead of tunnel mode (until we can get the world to go beyond 1500-byte datagrams, overhead IS a problem). IPsec SAs are perfect repositories for sensitivity information. And you can continue to use explicit labelling either to transit label-reading routers if you must. > I'm not exactly sure how you envision this working, but for the sake of > argument lets say that for the certificate derived security labels node A > sends a cert to node B as part of the IKE negotiation which node B then uses > to derive a security label for the SA matching node A's traffic (indirectly > labeling node A's traffic as it is received). This is an interesting scenario > because it doesn't actually involve any security labels being transfered over > the network, either via IKE or AH/ESP; in fact, if you implement it correctly > you could probably achieve this today using a standard IPsec implementation on > node A (only node B and its IPsec implementation need to be label aware). I > hasn't thought about this too much until just now, but I would almost consider > this case to be a method of fallback labeling; instead of deriving the > security label from an IP address you derive it from an authentication token. You could have PAD entries that set labels. We do that today in OpenSolaris. Dan From latten@austin.ibm.com Mon Dec 7 15:25: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 5D66D3A69FA for ; Mon, 7 Dec 2009 15:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.966 X-Spam-Level: X-Spam-Status: No, score=-4.966 tagged_above=-999 required=5 tests=[AWL=1.033, BAYES_00=-2.599, J_CHICKENPOX_72=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 gJEzPeuGCBm4 for ; Mon, 7 Dec 2009 15:25:23 -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 746C83A6A05 for ; Mon, 7 Dec 2009 15:25:23 -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 nB7NMm8g008719 for ; Mon, 7 Dec 2009 16:22:48 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nB7NP0TN039356 for ; Mon, 7 Dec 2009 16:25:00 -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 nB7NP0OQ003713 for ; Mon, 7 Dec 2009 16:25:00 -0700 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nB7NOxoe003664 for ; Mon, 7 Dec 2009 16:25:00 -0700 Received: from [9.41.41.43] (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id nB7NOx82030432; Mon, 7 Dec 2009 17:24:59 -0600 From: Joy Latten To: Nicolas Williams In-Reply-To: <20091207210247.GJ861@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <1259950190.2717.270.camel@faith.austin.ibm.com> <20091204183946.GH17842@kebe.East.Sun.COM> <20091204184621.GO773@Sun.COM> <1260202215.2717.300.camel@faith.austin.ibm.com> <20091207210247.GJ861@Sun.COM> Content-Type: text/plain Date: Mon, 07 Dec 2009 17:09:51 -0600 Message-Id: <1260227391.2717.319.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, serue@linux.vnet.ibm.com, gcwilson@us.ibm.com, tjaeger@cse.psu.edu Subject: Re: [IPsec] Proposed work item: Labelled IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: latten@austin.ibm.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 23:25:24 -0000 On Mon, 2009-12-07 at 15:02 -0600, Nicolas Williams wrote: > On Mon, Dec 07, 2009 at 10:10:15AM -0600, Joy Latten wrote: > > > The proposed work item is, at first glance anyways, too SELinux- > > > specific. > > > > > > Note that SMACK encodes its labels as CIPSO labels, so a scheme that > > > uses CIPSO can possibly be used in SMACK and non-SMACK environments, and > > > possibly even be mixed. > > > > Yes, I agree. > > > > Actually, we hoped the method we introduced was generic enough to > > accommodate both CIPSO and SMACK and any other MAC besides SELinux. > > We had hoped to do this by treating the security context as an opaque > > blob and introducing a DOI. > > > > I've actually discussed and collaborated about the "DOI" concept with > > Linux's CIPSO developer, and labeled nfs' developer. SMACK developer > > was included, but I do not recall if he said anything. We hoped that > > this "DOI" would not only be used by labeled IPsec, but CIPSO and others > > that use labels on the network. In a way, the "DOI" would help > > to identify the "mapping", thus perhaps allowing different MACs to talk > > to each other. Interoperability was and is a chief concern. However, > > I am sure the drafts most definitely can be improved upon. > > See the long threads on related topics on the SAAG and NFSv4 lists with > subjects: > > - Common labeled security (comment on CALIPSO, labeled NFSv4) > - Why the IETF should care about labeled?ne tworking (was:CIPSO > implementations) > - Secdir Review of draft-stjohns-sipso-05 Thanks for pointing this out. I was not aware of the threads and am finding them very interesting and informative. > > I'm not sure what the best way forward is, but here are some thoughts: > > - A notification indicating what DOI(s) are supported by the sender > might help. > Yes. The drafts suggest that by specifying the DOI as part of the SPD entry, that would identify the DOI to support for this traffic stream. > Not that I expect that any system will participate in multiple DOIs, > but then, IIRC SMACK supports mappings of SMACK labels (which hijack > a level in CIPSO) to non-SMACK CIPSO labels for interop, for example. > This idea is probably not too farfetched. > > - A label type in addition to DOI. > Ok. I originally perceived this as part of the DOI description, but I could understand wanting to separate for perhaps flexibility. > Not that I expect a single DOI to use multiple label types, but at > least one can then parse the label payload according to the stated > type rather than having to find the right type for the given DOI. > > - Text on the encodings of specific label types' labels. > > Particularly I think you need to have normative references to the > relevant RFCs and other work for the 'core' label types. > Yes, I agree, although I am unaware of any RFCs dealing with that yet. regards, Joy From paul.moore@hp.com Mon Dec 7 16: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 EF9713A6955 for ; Mon, 7 Dec 2009 16:01:08 -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=[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 Z0ulEY6IgN44 for ; Mon, 7 Dec 2009 16:01:08 -0800 (PST) Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by core3.amsl.com (Postfix) with ESMTP id CFAA53A6891 for ; Mon, 7 Dec 2009 16:01:07 -0800 (PST) Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g1t0026.austin.hp.com (Postfix) with ESMTP id 4EABDC0DD; Tue, 8 Dec 2009 00:00:57 +0000 (UTC) Received: from ldl (linux.corp.hp.com [15.11.146.101]) by g1t0039.austin.hp.com (Postfix) with ESMTP id F349D340C3; Mon, 7 Dec 2009 23:59:15 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl (Postfix) with ESMTP id D9BE5CF0011; Mon, 7 Dec 2009 16:59:15 -0700 (MST) Received: from ldl ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7kBtKO5oVtA; Mon, 7 Dec 2009 16:59:15 -0700 (MST) Received: from flek.localnet (squirrel.fc.hp.com [15.11.146.57]) by ldl (Postfix) with ESMTP id 640A2CF0007; Mon, 7 Dec 2009 16:59:15 -0700 (MST) From: Paul Moore Organization: Hewlett-Packard To: Dan McDonald Date: Mon, 7 Dec 2009 18:59:13 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r2; KDE/4.3.4; i686; ; ) References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <200912071753.59496.paul.moore@hp.com> <20091207232031.GA6316@mactavish> In-Reply-To: <20091207232031.GA6316@mactavish> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912071859.13780.paul.moore@hp.com> Cc: Nicolas Williams , David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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: Tue, 08 Dec 2009 00:01:09 -0000 On Monday 07 December 2009 06:20:31 pm Dan McDonald wrote: > On Mon, Dec 07, 2009 at 05:53:59PM -0500, Paul Moore wrote: > > > But this is not a reason to oppose labelled IPsec. It's a reason to > > > want an extended IP packet labelling standard. > > > > Why spend the time and effort to develop two specifications (not to > > mention the actual implementations) when one IP option based labeling > > spec could solve both use cases at the same time? > > Because sometimes you want to put sensitive traffic on public networks, > without the overhead of tunnel mode (until we can get the world to go > beyond 1500-byte datagrams, overhead IS a problem). It is worth noting that this does introduce a scalability concern in the case where a system communicates with another using a large number of security labels. It is only made worse on systems that have "rich" security labels which consist of more than just MLS attributes; e.g. SELinux labels contain user, role, type and MLS ranges, each unique combination represents a new label and in the case of labeled IPsec, a new SA. It is possible that a traditional, unlabeled IPsec configuration which would only use a single SA could potentially expand to several thousand SAs depending on the number of security labels in use for that particular policy. We've already seen issues related to this with SELinux. Also, on the topic of performance, labeled IPsec requires that the IPsec processing occur at the end node making it impossible to offload IPsec to a gateway. On small or heavily loaded systems this can quickly outweigh any advantages gained by decreased header sizes. > IPsec SAs are perfect repositories for sensitivity information. There is a subtle problem with using SAs for labeling that hasn't really been discussed in this forum and may not be immediate obvious. All of the labeled security mechanisms I've seen generate the packet/SA's security label from the application which generates the network traffic (the sender). The fact that IPsec SAs are not tightly bound to applications/senders, instead relying on the traffic selectors to match packets to the SA, can make things more difficult for security policy developers and security administrators. As an example, compare the security policy required for both CIPSO and labeled IPsec traffic on a SELinux system. > And you can continue to use explicit labelling either to transit label- > reading routers if you must. In which case you are now worse off since you have both the AH/ESP overhead as well as the security label overhead. > > I'm not exactly sure how you envision this working, but for the sake of > > argument lets say that for the certificate derived security labels node A > > sends a cert to node B as part of the IKE negotiation which node B then > > uses to derive a security label for the SA matching node A's traffic > > (indirectly labeling node A's traffic as it is received). This is an > > interesting scenario because it doesn't actually involve any security > > labels being transfered over the network, either via IKE or AH/ESP; in > > fact, if you implement it correctly you could probably achieve this today > > using a standard IPsec implementation on node A (only node B and its > > IPsec implementation need to be label aware). I hasn't thought about > > this too much until just now, but I would almost consider this case to be > > a method of fallback labeling; instead of deriving the security label > > from an IP address you derive it from an authentication token. > > You could have PAD entries that set labels. We do that today in > OpenSolaris. I apologize, but I'm not familiar with OpenSolaris's IPsec - do you use the pad to assign labels when none are present (the fallback case) or do you use it to limit the range of labels you will accept from a remote node? Based on your comment I suspect it is at least the former, I just wanted to clarify. -- paul moore linux @ hp From latten@austin.ibm.com Mon Dec 7 16:38: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 334283A68B1 for ; Mon, 7 Dec 2009 16:38:09 -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.925, 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 LtF4cxtE-qFo for ; Mon, 7 Dec 2009 16:38:08 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id F36A13A6839 for ; Mon, 7 Dec 2009 16:38:07 -0800 (PST) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e37.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nB80afv7024257 for ; Mon, 7 Dec 2009 17:36:41 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nB80brN2144184 for ; Mon, 7 Dec 2009 17:37:53 -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 nB80bqeW007072 for ; Mon, 7 Dec 2009 17:37:52 -0700 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nB80bqZK007056; Mon, 7 Dec 2009 17:37:52 -0700 Received: from [9.41.41.43] (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id nB80bpfS033854; Mon, 7 Dec 2009 18:37:51 -0600 From: Joy Latten To: Paul Moore In-Reply-To: <200912071637.50881.paul.moore@hp.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <20091204184621.GO773@Sun.COM> <1260202215.2717.300.camel@faith.austin.ibm.com> <200912071637.50881.paul.moore@hp.com> Content-Type: text/plain Date: Mon, 07 Dec 2009 18:22:43 -0600 Message-Id: <1260231763.2717.392.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit Cc: Nicolas Williams , David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com Subject: Re: [IPsec] Proposed work item: Labelled IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: latten@austin.ibm.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 00:38:09 -0000 On Mon, 2009-12-07 at 16:37 -0500, Paul Moore wrote: > On Monday 07 December 2009 11:10:15 am Joy Latten wrote: > > On Fri, 2009-12-04 at 12:46 -0600, Nicolas Williams wrote: > > > On Fri, Dec 04, 2009 at 01:39:46PM -0500, Dan McDonald wrote: > > > > The bigger point being missed by this thread, I think, is that it > > > > seems that any work in multi-level security needs to deal with > > > > successful interoperability. If it doesn't, there's little point in > > > > documenting a single-platform solution as part of a working group's > > > > output. > > > > > > +1. > > > > > > The proposed work item is, at first glance anyways, too SELinux- > > > specific. > > > > > > Note that SMACK encodes its labels as CIPSO labels, so a scheme that > > > uses CIPSO can possibly be used in SMACK and non-SMACK environments, and > > > possibly even be mixed. > > > > Yes, I agree. > > > > Actually, we hoped the method we introduced was generic enough to > > accommodate both CIPSO and SMACK and any other MAC besides SELinux. > > We had hoped to do this by treating the security context as an opaque > > blob and introducing a DOI. > > > > I've actually discussed and collaborated about the "DOI" concept with > > Linux's CIPSO developer, and labeled nfs' developer. SMACK developer > > was included, but I do not recall if he said anything. We hoped that > > this "DOI" would not only be used by labeled IPsec, but CIPSO and others > > that use labels on the network. In a way, the "DOI" would help > > to identify the "mapping", thus perhaps allowing different MACs to talk > > to each other. Interoperability was and is a chief concern. However, > > I am sure the drafts most definitely can be improved upon. > > At the SELinux Developer's Summit a few months ago there was a bit of a > general discussion about DOIs and label representation between myself (Linux > labeled networking), Dave Quigley (labeled NFS, added to CC) and Casey > Schaufler (SMACK, added to CC) as well as a few others. As could be expected, > there still seems to be quite a bit of confusion around the best way to > interoperate two different labeled security mechanisms. While I believe > everyone agrees that tagging network security labels with a DOI is important, > there seems to be little consensus beyond that (at least at the summit > discussion). Since Dave has an immediate need, he is working on a solution > for labeled NFS which uses three values: a format token, a DOI token, a > variable length label blob. Arguably the format and DOI tokens could be > combined but I understand the desire to keep things flexible at this point. > It is my understanding that Dave plans to first support a CALIPSO-like format > simply because it is well defined and the level/compartment-bitmap format > seems to be easiest to internalize across the different labeled security > mechanisms. > > I've mentioned all of this before, but my main fundamental concern with the > proposed labeled IPsec spec is that not everyone who wants labeled networking > wants IPsec. Look at the CALIPSO effort as an example, it was created because > users needed a way to communicate security labels over the network but did not > want or need IPsec (they already had security mechanisms in place and IPsec > was seen as an unnecessary burden, especially for the smaller devices). Yes, I have seen threads debating whether IPv6 should continue to mandate IPsec for the reasons you have stated. > What > I would really like to see is a spec providing for a general security label to > be assigned per-packet, similar to CALIPSO but without the reliance on MLS > (imagine the FIPS-188 freeform tag). This way users who only need to labeling > support are not required to go through the IPsec end node processing while > those users who do not already have a fully trusted network can run IPsec on > the untrusted links to secure the packet, the label and their binding. > Yes, I agree that not everyone wants to use IPsec and thus CIPSO would be a better option for them. Perhaps I am incorrect, but it seem possible that as MAC becomes more mainstream, the desire to communicate beyond the trusted network/environment will grow. Thus the need to use IPsec to protect the bindings. It just seem advantageous to me then that IPsec include a mechanism. Either way, as MAC goes more mainstream, I do think a standard solution addressing interoperability is needed. regards, Joy From Nicolas.Williams@sun.com Mon Dec 7 17:16: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 1D3A43A69BA for ; Mon, 7 Dec 2009 17:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.904 X-Spam-Level: X-Spam-Status: No, score=-5.904 tagged_above=-999 required=5 tests=[AWL=0.142, 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 E+Sr+Ix6Sfaj for ; Mon, 7 Dec 2009 17:16:01 -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 B8EBC3A6964 for ; Mon, 7 Dec 2009 17:15:59 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB81Fm9w006161 for ; Tue, 8 Dec 2009 01:15:48 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nB81FlvR022337 for ; Mon, 7 Dec 2009 18:15:48 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nB80fRBp001562; Mon, 7 Dec 2009 18:41:27 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB80fLHa001561; Mon, 7 Dec 2009 18:41:21 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 7 Dec 2009 18:41:21 -0600 From: Nicolas Williams To: Paul Moore Message-ID: <20091208004121.GC1516@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <200912071753.59496.paul.moore@hp.com> <20091207232031.GA6316@mactavish> <200912071859.13780.paul.moore@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200912071859.13780.paul.moore@hp.com> User-Agent: Mutt/1.5.7i Cc: Dan McDonald , David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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: Tue, 08 Dec 2009 01:16:02 -0000 On Mon, Dec 07, 2009 at 06:59:13PM -0500, Paul Moore wrote: > On Monday 07 December 2009 06:20:31 pm Dan McDonald wrote: > > On Mon, Dec 07, 2009 at 05:53:59PM -0500, Paul Moore wrote: > > > Why spend the time and effort to develop two specifications (not to > > > mention the actual implementations) when one IP option based labeling > > > spec could solve both use cases at the same time? > > > > Because sometimes you want to put sensitive traffic on public networks, > > without the overhead of tunnel mode (until we can get the world to go > > beyond 1500-byte datagrams, overhead IS a problem). > > It is worth noting that this does introduce a scalability concern in the case > where a system communicates with another using a large number of security > labels. It is only made worse on systems that have "rich" security labels > which consist of more than just MLS attributes; e.g. SELinux labels contain > user, role, type and MLS ranges, each unique combination represents a new > label and in the case of labeled IPsec, a new SA. It is possible that a > traditional, unlabeled IPsec configuration which would only use a single SA > could potentially expand to several thousand SAs depending on the number of > security labels in use for that particular policy. We've already seen issues > related to this with SELinux. For any discrete packet flow (say, a TCP connection), it makes no sense to have more than one label or clearance range. Thus at worst you end up with a narrowed SA pair (or two, during re-keys) per-flow. For protocols like NFS you'd have to do labelling in the protocol. I.e., for NFS you'd let IP/IPsec determine the labels/clearances of the client and server, and then the client and server would deal with labelling of files and user processes'/threads' actions. IOW, the number of SAs will be bounded by the number of concurrent, discrete packet flows, not by the number of labels. > Also, on the topic of performance, labeled IPsec requires that the IPsec > processing occur at the end node making it impossible to offload IPsec to a > gateway. On small or heavily loaded systems this can quickly outweigh any > advantages gained by decreased header sizes. I don't see why you believe this. > > IPsec SAs are perfect repositories for sensitivity information. > > There is a subtle problem with using SAs for labeling that hasn't really been > discussed in this forum and may not be immediate obvious. All of the labeled > security mechanisms I've seen generate the packet/SA's security label from the > application which generates the network traffic (the sender). The fact that > IPsec SAs are not tightly bound to applications/senders, instead relying on > the traffic selectors to match packets to the SA, can make things more > difficult for security policy developers and security administrators. As an > example, compare the security policy required for both CIPSO and labeled IPsec > traffic on a SELinux system. See RFC5660. See also the charter of the BTNS WG (though it's likely to be concluded before completing IPsec API work). Nico -- From turners@ieca.com Mon Dec 7 17:17: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 2BF3B28C0F6 for ; Mon, 7 Dec 2009 17:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 3XC5ro6tZNbd for ; Mon, 7 Dec 2009 17:17:08 -0800 (PST) Received: from smtp100.biz.mail.re2.yahoo.com (smtp100.biz.mail.re2.yahoo.com [206.190.52.46]) by core3.amsl.com (Postfix) with SMTP id 36B8B28C19C for ; Mon, 7 Dec 2009 17:17:08 -0800 (PST) Received: (qmail 13767 invoked from network); 8 Dec 2009 01:16:55 -0000 Received: from pool-96-241-2-70.washdc.east.verizon.net (turners@96.241.2.70 with plain) by smtp100.biz.mail.re2.yahoo.com with SMTP; 07 Dec 2009 17:16:55 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: uaL8Vf4VM1nYTpLf1qvs6cbTxga_PNzvNlW3ORCQxL2f0xDkKNx2aUkXqVqhia89FX4GUlQJw46BfKAhhGVNf0EPsg485w7ogRq3zc0zEttt1v_TkrDgJfMU15wmwfKb.gntfBun5Zajpa2tHoMJXJhCv6skJuxW.C3_2ix1WFhdXJTEq.pg4j7ZYDJ0DJyFOrZTio5fWpRKxlhFKsl3WY79ju64QfJC08Jf65Gp_JZUiRXvY_bxnvvarP4LSjDQ_NQY0NWcl2SPusn536eF9hEvg1XJurlDj667_km15SpvedBMHEyg5VvAxTYqo_s4L0gUIUN7TlDakSydUk.RkMMS.7jlfnT_CxZkX3N0NA0N7rUSI9lMd2Ro9lAfTHV56V0PTreq_YLsnwl6yRwCxR.d3s_ftZQJChX3szoYLN4TgzZ.OAyOeOiHqY7AAcsrGCqVmv2TI0irozIWHHA0udxC8m18QUfh5Kij.N5CqkIDZaHymoB8.0rYmUMbJBwY7Qm40YDCQPWFYNc6ZqKZunwa2jcSt1xIeQOEc93MoYrY7vP1Cg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1DA907.1050404@ieca.com> Date: Mon, 07 Dec 2009 20:16:55 -0500 From: Sean Turner User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Nicolas Williams References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <1259950190.2717.270.camel@faith.austin.ibm.com> <20091204183946.GH17842@kebe.East.Sun.COM> <20091204184621.GO773@Sun.COM> <1260202215.2717.300.camel@faith.austin.ibm.com> <20091207210247.GJ861@Sun.COM> <4B1D7635.5030200@ieca.com> <20091207214330.GN861@Sun.COM> In-Reply-To: <20091207214330.GN861@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, serue@linux.vnet.ibm.com, gcwilson@us.ibm.com, Joy Latten , tjaeger@cse.psu.edu 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: Tue, 08 Dec 2009 01:17:09 -0000 Nicolas Williams wrote: > On Mon, Dec 07, 2009 at 04:40:05PM -0500, Sean Turner wrote: >> Nicolas Williams wrote: >> ...snip... >>> - A separate I-D for adding labeling information to certificates. >> Are you suggesting that you'd label a certificate? I suspect what >> you're talking about is including what labels a user/device supports and >> the clearance attribute in the RFC 3281 update >> (http://tools.ietf.org/html/draft-ietf-pkix-3281update-05) is defined >> for just such a purpose. > > Ah, I didn't know that a clearance attribute existed already. Yes, > that's exactly what I had in mind. (Incidentally, the I-D you mention > has a referenced to X.501-1993, but it doesn't appear in the References > sections.) It's in AUTH48 and the RFC editors caught that. spt From latten@austin.ibm.com Mon Dec 7 17:21: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 BA15928C0F6 for ; Mon, 7 Dec 2009 17:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.339 X-Spam-Level: X-Spam-Status: No, score=-5.339 tagged_above=-999 required=5 tests=[AWL=1.260, 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 FxPpE7J33QtJ for ; Mon, 7 Dec 2009 17:21:08 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id A0DFA28C0ED for ; Mon, 7 Dec 2009 17:21:08 -0800 (PST) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e1.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id nB81IXBd024667 for ; Mon, 7 Dec 2009 20:18:33 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nB81KvPh1888340 for ; Mon, 7 Dec 2009 20:20:57 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nB81KvnU007112 for ; Mon, 7 Dec 2009 23:20:57 -0200 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nB81KtYo007035; Mon, 7 Dec 2009 23:20:56 -0200 Received: from [9.41.41.43] (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id nB81KqrR051068; Mon, 7 Dec 2009 19:20:52 -0600 From: Joy Latten To: Nicolas Williams In-Reply-To: <20091208004121.GC1516@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <200912071753.59496.paul.moore@hp.com> <20091207232031.GA6316@mactavish> <200912071859.13780.paul.moore@hp.com> <20091208004121.GC1516@Sun.COM> Content-Type: text/plain Date: Mon, 07 Dec 2009 19:05:44 -0600 Message-Id: <1260234344.2717.426.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit Cc: Paul Moore , David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com Subject: Re: [IPsec] Proposed work item: Labelled IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: latten@austin.ibm.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 01:21:09 -0000 On Mon, 2009-12-07 at 18:41 -0600, Nicolas Williams wrote: > On Mon, Dec 07, 2009 at 06:59:13PM -0500, Paul Moore wrote: > > On Monday 07 December 2009 06:20:31 pm Dan McDonald wrote: > > > On Mon, Dec 07, 2009 at 05:53:59PM -0500, Paul Moore wrote: > > > > Why spend the time and effort to develop two specifications (not to > > > > mention the actual implementations) when one IP option based labeling > > > > spec could solve both use cases at the same time? > > > > > > Because sometimes you want to put sensitive traffic on public networks, > > > without the overhead of tunnel mode (until we can get the world to go > > > beyond 1500-byte datagrams, overhead IS a problem). > > > > It is worth noting that this does introduce a scalability concern in the case > > where a system communicates with another using a large number of security > > labels. It is only made worse on systems that have "rich" security labels > > which consist of more than just MLS attributes; e.g. SELinux labels contain > > user, role, type and MLS ranges, each unique combination represents a new > > label and in the case of labeled IPsec, a new SA. It is possible that a > > traditional, unlabeled IPsec configuration which would only use a single SA > > could potentially expand to several thousand SAs depending on the number of > > security labels in use for that particular policy. We've already seen issues > > related to this with SELinux. > > For any discrete packet flow (say, a TCP connection), it makes no sense > to have more than one label or clearance range. Thus at worst you end > up with a narrowed SA pair (or two, during re-keys) per-flow. > > For protocols like NFS you'd have to do labelling in the protocol. > I.e., for NFS you'd let IP/IPsec determine the labels/clearances of the > client and server, and then the client and server would deal with > labelling of files and user processes'/threads' actions. > > IOW, the number of SAs will be bounded by the number of concurrent, > discrete packet flows, not by the number of labels. > I could be misunderstanding what you are saying, but I agree with Paul here. When using a MAC that employs labels using other security attributes in addition to the MLS attributes, there can be more than one SA-pair per flow. For example, SELinux uses user:role:type:mls-attributes. There can be a large number of "types" defined by MAC system for the type attribute. So, although mls-attributes may be the same for two different TCP connections, if the "type" is different, then that implies 2 different labels, one for each of the TCP connections. Thus an SA-pair is needed for each of the two TCP connections on the flow. regards, Joy From paul.moore@hp.com Mon Dec 7 19:52: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 CE3013A6806 for ; Mon, 7 Dec 2009 19:52:34 -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=[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 GhQUn13toBKc for ; Mon, 7 Dec 2009 19:52:33 -0800 (PST) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by core3.amsl.com (Postfix) with ESMTP id 9BAF63A63C9 for ; Mon, 7 Dec 2009 19:52:33 -0800 (PST) Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g1t0029.austin.hp.com (Postfix) with ESMTP id B9AD33816E; Tue, 8 Dec 2009 03:52:22 +0000 (UTC) Received: from ldl (linux.corp.hp.com [15.11.146.101]) by g1t0039.austin.hp.com (Postfix) with ESMTP id E88AD340F6; Tue, 8 Dec 2009 03:51:01 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl (Postfix) with ESMTP id CC2F1CF0010; Mon, 7 Dec 2009 20:51:01 -0700 (MST) Received: from ldl ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-53odOjZeDu; Mon, 7 Dec 2009 20:51:01 -0700 (MST) Received: from flek.localnet (squirrel.fc.hp.com [15.11.146.57]) by ldl (Postfix) with ESMTP id 8D919CF0007; Mon, 7 Dec 2009 20:51:01 -0700 (MST) From: Paul Moore Organization: Hewlett-Packard To: Nicolas Williams Date: Mon, 7 Dec 2009 22:51:00 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r2; KDE/4.3.4; i686; ; ) References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <200912071859.13780.paul.moore@hp.com> <20091208004121.GC1516@Sun.COM> In-Reply-To: <20091208004121.GC1516@Sun.COM> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912072251.00542.paul.moore@hp.com> Cc: Dan McDonald , David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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: Tue, 08 Dec 2009 03:52:34 -0000 On Monday 07 December 2009 07:41:21 pm Nicolas Williams wrote: > On Mon, Dec 07, 2009 at 06:59:13PM -0500, Paul Moore wrote: > > On Monday 07 December 2009 06:20:31 pm Dan McDonald wrote: > > > On Mon, Dec 07, 2009 at 05:53:59PM -0500, Paul Moore wrote: > > > > Why spend the time and effort to develop two specifications (not to > > > > mention the actual implementations) when one IP option based labeling > > > > spec could solve both use cases at the same time? > > > > > > Because sometimes you want to put sensitive traffic on public networks, > > > without the overhead of tunnel mode (until we can get the world to go > > > beyond 1500-byte datagrams, overhead IS a problem). > > > > It is worth noting that this does introduce a scalability concern in the > > case where a system communicates with another using a large number of > > security labels. It is only made worse on systems that have "rich" > > security labels which consist of more than just MLS attributes; e.g. > > SELinux labels contain user, role, type and MLS ranges, each unique > > combination represents a new label and in the case of labeled IPsec, a > > new SA. It is possible that a traditional, unlabeled IPsec configuration > > which would only use a single SA could potentially expand to several > > thousand SAs depending on the number of security labels in use for that > > particular policy. We've already seen issues related to this with > > SELinux. > > For any discrete packet flow (say, a TCP connection), it makes no sense > to have more than one label or clearance range. Thus at worst you end > up with a narrowed SA pair (or two, during re-keys) per-flow. > > For protocols like NFS you'd have to do labelling in the protocol. > I.e., for NFS you'd let IP/IPsec determine the labels/clearances of the > client and server, and then the client and server would deal with > labelling of files and user processes'/threads' actions. > > IOW, the number of SAs will be bounded by the number of concurrent, > discrete packet flows, not by the number of labels. I agree that it only makes sense to assign a single label to a discrete packet flow, no argument there. If you re-read what I wrote I wasn't talking about an individual connection/flow between two nodes but rather the general case of IPsec protected communications between two nodes. The point I'm trying to make is that labeled IPsec adds the flow's security label to the SA's traffic selector which has the potential to increase the number of SAs on the system by making the SAs more selective. For example, it is possible to configure a SPD such that all communication between two nodes is protected with a single SA; if labeled IPsec is used, the number of SAs in use would grow to equal the number security labels used in communications between the two nodes. If the two systems only communicate with label "Coke" then only a single SA is needed. However, if the two systems have two or more communication channels using with at least one channel using "Coke" and another using "Pepsi" then two SAs will need to be created to convey the two unique security labels. You can easily see how this example can be applied with finer grained SPDs as well. > > Also, on the topic of performance, labeled IPsec requires that the IPsec > > processing occur at the end node making it impossible to offload IPsec to > > a gateway. On small or heavily loaded systems this can quickly outweigh > > any advantages gained by decreased header sizes. > > I don't see why you believe this. What don't you understand, that labeled IPsec requires IPsec processing to occur at the end node or that requiring IPsec on small devices can incur more of a performance penalty than a separate labeling protocol? Perhaps I'm wrong about one of those statements, if I am I would appreciate help in understanding why. > > > IPsec SAs are perfect repositories for sensitivity information. > > > > There is a subtle problem with using SAs for labeling that hasn't really > > been discussed in this forum and may not be immediate obvious. All of > > the labeled security mechanisms I've seen generate the packet/SA's > > security label from the application which generates the network traffic > > (the sender). The fact that IPsec SAs are not tightly bound to > > applications/senders, instead relying on the traffic selectors to match > > packets to the SA, can make things more difficult for security policy > > developers and security administrators. As an example, compare the > > security policy required for both CIPSO and labeled IPsec traffic on a > > SELinux system. > > See RFC5660. See also the charter of the BTNS WG (though it's likely to > be concluded before completing IPsec API work). I just quickly skimmed RFC5660 and the BTNS charter so please correct me if I am misunderstanding things, but I don't see either the IPsec connection latching or BTNS charter having much impact on MAC security policies. Granted, the IPsec connection latching seems like an excellent idea but I'm fairly certain that systems which implement MAC using labeled security will still need to have MAC security policy in place to control (and provide the desired level of assurance) how IPsec SA based labeling is applied to network traffic; at least for implementations going through some form of security certification (I'm thinking Common Criteria). IPsec latching may make this easier but I don't see how it would remove the requirement on MAC control over the process or change the MAC security policy, the basics of the SA based labeling remain the same. -- paul moore linux @ hp From kivinen@iki.fi Tue Dec 8 03:26: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 E08E43A69DD for ; Tue, 8 Dec 2009 03:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 t6TRZlHLj0ik for ; Tue, 8 Dec 2009 03:26:10 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id BDE7E3A69D5 for ; Tue, 8 Dec 2009 03:26: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 nB8BPmJI028984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Dec 2009 13:25:48 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nB8BPlnd027527; Tue, 8 Dec 2009 13:25:47 +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: <19230.14267.109849.507396@fireball.kivinen.iki.fi> Date: Tue, 8 Dec 2009 13:25:47 +0200 From: Tero Kivinen To: Brian Swander In-Reply-To: <5E38DBF64E732C4C98512C53E1B14DDC299ACE4A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> <5E38DBF64E732C4C98512C53E1B14DDC2999E319@TK5EX14MBXW653.wingroup.windeplo y.ntdev.microsoft.com> <5E38DBF64E732C4C98512C53E1B14DDC299ACE4A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 9 min Cc: "ipsec@ietf.org" , Stephen Kent 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: Tue, 08 Dec 2009 11:26:11 -0000 Brian Swander writes: > 0 - option data does not change en-route. This option is > included in the WESP ICV computation. > > We'll be using this flag, so this option will always be integrity > protected. One of the things that disturb me here is that AH was not acceptable because of the complexity and because it didn't go through NATs, and now we are thinking of adding lots of complexity to the WESP (perhaps even more than what AH had by looking at some of the discussion). Perhaps it would be better to go back and say use AH instead, at least for that we would have some implementations and even when there is perhaps much less testing done on the AH than to ESP, it has still lots of more testing and experience than what we have from WESP... I still think that extending WESP in any ways is very bad idea, and if it is to be done, we need to first start from the exact scenarios where those extensions are needed, not make any generic framework or protocol document before we know what problems we are solving. This same thing was problematic for WESP. I am still not sure what problem we are solving, even when I am author of the another draft solving same "problems" than WESP. Every time someone starts discussing about the problems, it seems the problem is completely different... -- kivinen@iki.fi From danmcd@sun.com Tue Dec 8 06:36: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 DAB7428C144 for ; Tue, 8 Dec 2009 06:36:39 -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 JPuAiST8s9mM for ; Tue, 8 Dec 2009 06:36: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 1FE483A6860 for ; Tue, 8 Dec 2009 06:36: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 nB8EZwK9000718; Tue, 8 Dec 2009 14:35:58 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 nB8EZvcD024124; Tue, 8 Dec 2009 09:35:57 -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 nB8EZqWN026551; Tue, 8 Dec 2009 09:35:52 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB8EZmsK026550; Tue, 8 Dec 2009 09:35:48 -0500 (EST) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Tue, 8 Dec 2009 09:35:48 -0500 From: Dan McDonald To: Paul Moore Message-ID: <20091208143548.GS25500@kebe.East.Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <200912071753.59496.paul.moore@hp.com> <20091207232031.GA6316@mactavish> <200912071859.13780.paul.moore@hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200912071859.13780.paul.moore@hp.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.20 (2009-06-14) Cc: David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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: Tue, 08 Dec 2009 14:36:40 -0000 On Mon, Dec 07, 2009 at 06:59:13PM -0500, Paul Moore wrote: > > You could have PAD entries that set labels. We do that today in > > OpenSolaris. > > I apologize, but I'm not familiar with OpenSolaris's IPsec - do you use the > pad to assign labels when none are present (the fallback case) or do you > use it to limit the range of labels you will accept from a remote node? > Based on your comment I suspect it is at least the former, I just wanted to > clarify. Both. IKE will reject a peer that proposes a label outside the scope of a PAD entry's preferences. Dan From B22245@freescale.com Mon Dec 7 21:47: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 3E88A28C104 for ; Mon, 7 Dec 2009 21:47:40 -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 TSVC0zAiQtBr for ; Mon, 7 Dec 2009 21:47:39 -0800 (PST) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id 5B62428C103 for ; Mon, 7 Dec 2009 21:47:39 -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 nB85lIou010041 for ; Mon, 7 Dec 2009 22:47:18 -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 nB85lJT1013391 for ; Mon, 7 Dec 2009 23:47:20 -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: Tue, 8 Dec 2009 11:17:20 +0530 Message-ID: <402621A7D69DDA458D0E12F070D1E55F553A39@zin33exm29.fsl.freescale.net> In-Reply-To: <729b68be0912071040q90973b2o823c06eec4c2940b@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Proposed work item: IKE/IPsec high availability andload sharing Thread-Index: Acp3bMQApu0GnVu4Sy6RrnkUfQTYIAAXHbQw References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F1@il-ex01.ad.checkpoint.com> <729b68be0912071040q90973b2o823c06eec4c2940b@mail.gmail.com> From: "V Jyothi-B22245" To: "Jean-Michel Combes" , "Yaron Sheffer" X-Mailman-Approved-At: Tue, 08 Dec 2009 08:06:25 -0800 Cc: ipsec@ietf.org Subject: Re: [IPsec] Proposed work item: IKE/IPsec high availability andload 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: Tue, 08 Dec 2009 06:09:02 -0000 =20 Hi, I am willing to review multiple versions of the draft, contribute text and co-author it. Thanks Jyothi -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Jean-Michel Combes Sent: Tuesday, December 08, 2009 12:10 AM To: Yaron Sheffer Cc: ipsec@ietf.org Subject: Re: [IPsec] Proposed work item: IKE/IPsec high availability andload sharing Hi, After a discussion on the scope of this draft, I decided to change my opinion regarding what I said during the IETF meeting: now, I am ready to review the draft but no more to contribute to it. Best regards. JMC. 2009/11/29 Yaron Sheffer : > This work item will define the problem statement and requirements for=20 > a solution that allows interoperable HA/LS device groups. Mixed-vendor > clusters are specifically out of scope; but single-vendor clusters=20 > should be fully interoperable with other vendors' devices or clusters. > The main challenge is to overcome the strict use of sequence numbers=20 > in both IPsec and IKE, in HA and LS scenarios. Following the Hiroshima > discussion, the WI is initially focused on defining the problem,=20 > 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=20 > 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=20 > fine technical details (which will change anyway, once the WG gets=20 > hold of the draft); instead explain why this is uninteresting for the=20 > WG or for the industry at large. Also, please mark the title clearly=20 > (e.g. "DES40-export in IPsec - NO!"). > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From casey@schaufler-ca.com Mon Dec 7 20:26: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 7AA1F3A67E9 for ; Mon, 7 Dec 2009 20:26:16 -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, UNPARSEABLE_RELAY=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 pTf5fVBUGHcZ for ; Mon, 7 Dec 2009 20:26:15 -0800 (PST) Received: from smtp108.prem.mail.sp1.yahoo.com (smtp108.prem.mail.sp1.yahoo.com [98.136.44.63]) by core3.amsl.com (Postfix) with SMTP id 9293C3A67D1 for ; Mon, 7 Dec 2009 20:26:15 -0800 (PST) Received: (qmail 30110 invoked from network); 8 Dec 2009 04:26:03 -0000 Received: from c-76-102-151-19.hsd1.ca.comcast.net (casey@76.102.151.19 with plain) by smtp108.prem.mail.sp1.yahoo.com with SMTP; 07 Dec 2009 20:26:03 -0800 PST X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- X-YMail-OSG: OypSX.wVM1nw9G3WNq52uCXtgAFod0RvMqo_Ky3aq8.MkjO44jU3Hp017FoP2lir5uBhmTWemZ3w6N2Uu_67Afglhfcu05PoPIzIjSBlu92qP_Ct9bZhwJ6uEpzyFiXqHjq9Nmaf_OzO6MkFAqnuZCjlTggTnOCt4A2KERXy.X5D0hVTk0APv3ZJX4vias.2LPa4R0cB7khpx8Kk.fEPT5dI6UUmpzJrFhK3.SLNj0rAdgo97hCo6kSGiXlithdDNMVe68k0ZENuHXDD0c4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1DD559.2000601@schaufler-ca.com> Date: Mon, 07 Dec 2009 20:26:01 -0800 From: Casey Schaufler User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Paul Moore References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <20091204184621.GO773@Sun.COM> <1260202215.2717.300.camel@faith.austin.ibm.com> <200912071637.50881.paul.moore@hp.com> In-Reply-To: <200912071637.50881.paul.moore@hp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 08 Dec 2009 08:06:42 -0800 Cc: Nicolas Williams , David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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: Tue, 08 Dec 2009 04:26:16 -0000 Paul Moore wrote: > On Monday 07 December 2009 11:10:15 am Joy Latten wrote: > >> On Fri, 2009-12-04 at 12:46 -0600, Nicolas Williams wrote: >> >>> On Fri, Dec 04, 2009 at 01:39:46PM -0500, Dan McDonald wrote: >>> >>>> The bigger point being missed by this thread, I think, is that it >>>> seems that any work in multi-level security needs to deal with >>>> successful interoperability. If it doesn't, there's little point in >>>> documenting a single-platform solution as part of a working group's >>>> output. >>>> >>> +1. >>> >>> The proposed work item is, at first glance anyways, too SELinux- >>> specific. >>> >>> Note that SMACK encodes its labels as CIPSO labels, so a scheme that >>> uses CIPSO can possibly be used in SMACK and non-SMACK environments, and >>> possibly even be mixed. >>> >> Yes, I agree. >> >> Actually, we hoped the method we introduced was generic enough to >> accommodate both CIPSO and SMACK and any other MAC besides SELinux. >> We had hoped to do this by treating the security context as an opaque >> blob and introducing a DOI. >> >> I've actually discussed and collaborated about the "DOI" concept with >> Linux's CIPSO developer, and labeled nfs' developer. SMACK developer >> was included, but I do not recall if he said anything. We hoped that >> this "DOI" would not only be used by labeled IPsec, but CIPSO and others >> that use labels on the network. In a way, the "DOI" would help >> to identify the "mapping", thus perhaps allowing different MACs to talk >> to each other. Interoperability was and is a chief concern. However, >> I am sure the drafts most definitely can be improved upon. >> > > At the SELinux Developer's Summit a few months ago there was a bit of a > general discussion about DOIs and label representation between myself (Linux > labeled networking), Dave Quigley (labeled NFS, added to CC) and Casey > Schaufler (SMACK, added to CC) as well as a few others. As could be expected, > there still seems to be quite a bit of confusion around the best way to > interoperate two different labeled security mechanisms. While I believe > everyone agrees that tagging network security labels with a DOI is important, > there seems to be little consensus beyond that (at least at the summit > discussion). Since Dave has an immediate need, he is working on a solution > for labeled NFS which uses three values: a format token, a DOI token, a > variable length label blob. Arguably the format and DOI tokens could be > combined but I understand the desire to keep things flexible at this point. > It is my understanding that Dave plans to first support a CALIPSO-like format > simply because it is well defined and the level/compartment-bitmap format > seems to be easiest to internalize across the different labeled security > mechanisms. > > I've mentioned all of this before, but my main fundamental concern with the > proposed labeled IPsec spec is that not everyone who wants labeled networking > wants IPsec. I concur with Paul. IPsec is an expensive mechanism that requires an extensive support infrastructure. Yes, it's general. But if all you want is to pass MAC information about local processes as happens on embedded systems IPsec is a bad choice. This is an old discussion. Back in the late 1980's the choices were CIPSO and DNSIX. I don't think that anyone who was involved with the B1/CMW systems of that bygone era would argue that DNSIX was worth the costs. I really dislike unnecessary complexity and I believe that security is probably the last place that complexity should be tolerated. I understand the arguments for DNSIX/IPsec and just can't buy the cost/value proposition. > Look at the CALIPSO effort as an example, it was created because > users needed a way to communicate security labels over the network but did not > want or need IPsec (they already had security mechanisms in place and IPsec > was seen as an unnecessary burden, especially for the smaller devices). What > I would really like to see is a spec providing for a general security label to > be assigned per-packet, similar to CALIPSO but without the reliance on MLS > (imagine the FIPS-188 freeform tag). This way users who only need to labeling > support are not required to go through the IPsec end node processing while > those users who do not already have a fully trusted network can run IPsec on > the untrusted links to secure the packet, the label and their binding. > > From paul.moore@hp.com Tue Dec 8 06:37: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 23EEC28C151 for ; Tue, 8 Dec 2009 06:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, 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 4aziU1V9ssYi for ; Tue, 8 Dec 2009 06:37:48 -0800 (PST) Received: from g6t0185.atlanta.hp.com (g6t0185.atlanta.hp.com [15.193.32.62]) by core3.amsl.com (Postfix) with ESMTP id 55AE83A6884 for ; Tue, 8 Dec 2009 06:37:48 -0800 (PST) Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com [16.228.8.142]) by g6t0185.atlanta.hp.com (Postfix) with ESMTP id 5F4C52410C; Tue, 8 Dec 2009 14:37:36 +0000 (UTC) Received: from ldl (linux.corp.hp.com [15.11.146.101]) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id 8851514035; Tue, 8 Dec 2009 14:37:35 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl (Postfix) with ESMTP id 3F190CF0011; Tue, 8 Dec 2009 07:37:35 -0700 (MST) Received: from ldl ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEXt-ecA6rRb; Tue, 8 Dec 2009 07:37:35 -0700 (MST) Received: from flek.localnet (squirrel.fc.hp.com [15.11.146.57]) by ldl (Postfix) with ESMTP id 06CDACF0007; Tue, 8 Dec 2009 07:37:35 -0700 (MST) From: Paul Moore Organization: Hewlett-Packard To: Steven Bellovin Date: Tue, 8 Dec 2009 09:37:33 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r2; KDE/4.3.4; i686; ; ) References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <200912071726.04604.paul.moore@hp.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912080937.33769.paul.moore@hp.com> X-Mailman-Approved-At: Tue, 08 Dec 2009 08:06:54 -0800 Cc: Stephen Kent , Nicolas Williams , David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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: Tue, 08 Dec 2009 14:37:49 -0000 On Monday 07 December 2009 11:59:51 pm Steven Bellovin wrote: > On Dec 7, 2009, at 5:26 PM, Paul Moore wrote: > > On Monday 07 December 2009 05:16:26 pm Stephen Kent wrote: > >> Paul, > >> > >> From your comments it seems as though an IP option would be > >> preferable, as it is not IP-sec-specific, and it an be protected if > >> needed, in the IPSec context, e.g., via tunneling. > > > > Exactly. Since the option would be immutable it could also be protected > > with AH allowing for intermediate nodes to apply security policy based on > > the label. > > Not really, because the the intermediate nodes probably don't have the key > necessary to verify the label. Yes, my mistake. While the security label would be visible to intermediate nodes they would have no way to verify the integrity of the label. -- paul moore linux @ hp From smb@cs.columbia.edu Mon Dec 7 21:06: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 9AEF53A693D for ; Mon, 7 Dec 2009 21:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 9OL1ACBHZf1W for ; Mon, 7 Dec 2009 21:06:18 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 652993A6800 for ; Mon, 7 Dec 2009 21:06:18 -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 serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nB84xqRm004457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 7 Dec 2009 23:59:52 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: <200912071726.04604.paul.moore@hp.com> Date: Mon, 7 Dec 2009 23:59:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F4@il-ex01.ad.checkpoint.com> <200912071637.50881.paul.moore@hp.com> <200912071726.04604.paul.moore@hp.com> To: Paul Moore X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 X-Mailman-Approved-At: Tue, 08 Dec 2009 08:07:49 -0800 Cc: Stephen Kent , Nicolas Williams , David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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: Tue, 08 Dec 2009 05:06:20 -0000 On Dec 7, 2009, at 5:26 PM, Paul Moore wrote: > On Monday 07 December 2009 05:16:26 pm Stephen Kent wrote: >> Paul, >>=20 >> =46rom your comments it seems as though an IP option would be >> preferable, as it is not IP-sec-specific, and it an be protected if >> needed, in the IPSec context, e.g., via tunneling. >=20 > Exactly. Since the option would be immutable it could also be = protected with=20 > AH allowing for intermediate nodes to apply security policy based on = the=20 > label. Not really, because the the intermediate nodes probably don't have the = key necessary to verify the label. > Although I do understand AH is falling out of favor. I certainly hope so... --Steve Bellovin, http://www.cs.columbia.edu/~smb From B22237@freescale.com Tue Dec 8 09:40: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 009C73A68AD for ; Tue, 8 Dec 2009 09:40:34 -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 Ro8SJObMVIwE for ; Tue, 8 Dec 2009 09:40:30 -0800 (PST) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id 8F99E3A67A7 for ; Tue, 8 Dec 2009 09:40:30 -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 nB8He3Cw017235 for ; Tue, 8 Dec 2009 10:40:08 -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 nB8Hj2v0005413 for ; Tue, 8 Dec 2009 11:45:03 -0600 (CST) 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_01CA782D.779233DE" Date: Tue, 8 Dec 2009 23:09:58 +0530 Message-ID: <2E13B90533934A499FD727F9B353613C5160E5@zin33exm29.fsl.freescale.net> In-Reply-To: <51eafbcb0912070731w2c13d799va76a43f6b3bb6aa5@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Proposed work item: IKE/IPsec high availability andload sharing Thread-Index: Acp3Um0vgjSDO8YsRdmhjW3sU7T/1QA2rXNg References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F1@il-ex01.ad.checkpoint.com><4B187F5C.6050102@sandelman.ca> <51eafbcb0912070731w2c13d799va76a43f6b3bb6aa5@mail.gmail.com> From: "Murthy N Srinivas-B22237" To: "Daniel Migault" , "Michael Richardson" Cc: ipsec@ietf.org Subject: Re: [IPsec] Proposed work item: IKE/IPsec high availability andload 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: Tue, 08 Dec 2009 17:40:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA782D.779233DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to coauthor IKE/IPsec high availability and load sharing. Looks like a challenging and intereting problem. =20 =20 Thanks -ns murthy ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Daniel Migault Sent: Monday, December 07, 2009 9:02 PM To: Michael Richardson Cc: ipsec@ietf.org Subject: Re: [IPsec] Proposed work item: IKE/IPsec high availability andload sharing I will also review this document. Regards,=20 Daniel On Fri, Dec 4, 2009 at 4:17 AM, Michael Richardson wrote: Yaron Sheffer wrote: =09 This work item will define the problem statement and requirements for a solution that allows interoperable HA/LS device groups. Mixed-vendor clusters are specifically out of scope; but single-vendor clusters should be fully interoperable with other vendors' devices or clusters. The main challenge 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 than a particular solution. =09 =20 Proposed starting point: http://tools.ietf.org/id/draft-nir-ipsecme-ipsecha-00.txt. =09 =20 Please reply to the list: =09 It is interesting work, and may well be valuable. It is not a priority to me, and I would not have time to work on it. I might read a WG FC, and I might respond to threads, if I came across them.=20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =09 --=20 Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ------_=_NextPart_001_01CA782D.779233DE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I would like to coauthor IKE/IPsec high availability and load=20 sharing.
Looks like = a challenging=20 and intereting problem.
 
 
Thanks
-ns murthy


From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Daniel=20 Migault
Sent: Monday, December 07, 2009 9:02 PM
To: = Michael=20 Richardson
Cc: ipsec@ietf.org
Subject: Re: [IPsec] = Proposed=20 work item: IKE/IPsec high availability andload = sharing

I will also review this document.
Regards, =
Daniel

On Fri, Dec 4, 2009 at 4:17 AM, Michael = Richardson <mcr@sandelman.ca>=20 wrote:
Yaron Sheffer wrote:
This=20 work item will define the problem statement and requirements for a = solution=20 that allows interoperable HA/LS device groups. Mixed-vendor clusters = are=20 specifically out of scope; but single-vendor clusters should be = fully=20 interoperable with other vendors’ devices or clusters. The = main challenge is=20 to overcome the strict use of sequence numbers in both IPsec and = IKE, in HA=20 and LS scenarios. Following the Hiroshima discussion, the WI is = initially=20 focused on defining the problem, rather than a particular=20 solution.

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

 
Please=20 reply to the list:

It is interesting work, = and may=20 well be valuable.
It is not a priority to me, and I would not have = time to=20 work on it.
I might read a WG FC, and I might respond to threads, = if I came=20 across
them.




______________________________________________= _
IPsec=20 mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
=


--
Daniel Migault
Orange Labs -- Security
+33 = 6 70 72 69=20 58
------_=_NextPart_001_01CA782D.779233DE-- From B22237@freescale.com Tue Dec 8 09:42: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 F0FFF3A68AD for ; Tue, 8 Dec 2009 09:42:50 -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 YGOd0tEc+pwM for ; Tue, 8 Dec 2009 09:42:50 -0800 (PST) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id 2238D3A6827 for ; Tue, 8 Dec 2009 09:42:50 -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 nB8HgdeB017937 for ; Tue, 8 Dec 2009 10:42:39 -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 nB8HlcNl005481 for ; Tue, 8 Dec 2009 11:47:39 -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: Tue, 8 Dec 2009 23:12:36 +0530 Message-ID: <2E13B90533934A499FD727F9B353613C5160E8@zin33exm29.fsl.freescale.net> In-Reply-To: <4B187F86.9030503@sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Proposed work item: Childless IKE SA Thread-Index: Acp0kIWEOwovdbfIRRG55S3XS5TaPgDnTZrA References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <4B187F86.9030503@sandelman.ca> From: "Murthy N Srinivas-B22237" To: "Michael Richardson" , Subject: Re: [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: Tue, 08 Dec 2009 17:42:51 -0000 Hi Interested in coauthoring this draft. Thanks -ns murthy=20 -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Michael Richardson Sent: Friday, December 04, 2009 8:49 AM To: ipsec@ietf.org Subject: Re: [IPsec] Proposed work item: Childless IKE SA Yaron Sheffer wrote: > 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. >=20 > Proposed starting point: http://tools.ietf.org/id/draft-nir-ipsecme-childless-01.txt. > =20 > Please reply to the list: I believe that this is a useful extension to IKEv2. I am willing to review drafts, and I might co-author. In particular, I would like to be able to negotiate IKEv2, specifically so that I can send a DELETE. Alternatively, I would like to negotiate a non-SA for some traffic selector. I mention this, because I'm not sure that the reasons for CHILDLESS are the same for different people, and therefore, we may be trying to use a hammer on a screw. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From jtardo@broadcom.com Tue Dec 8 11:01: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 3092F3A6923 for ; Tue, 8 Dec 2009 11:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=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 yCKMGpxo2D2U for ; Tue, 8 Dec 2009 11:01:10 -0800 (PST) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 898483A68FB for ; Tue, 8 Dec 2009 11:01:10 -0800 (PST) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 08 Dec 2009 11:00:40 -0800 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Tue, 8 Dec 2009 11:00:10 -0800 From: "Joseph Tardo" To: "ipsec@ietf.org" Date: Tue, 8 Dec 2009 11:00:10 -0800 Thread-Topic: Proposed work item: WESP extensibility - YES Thread-Index: Acp3srebSyGwaTHERSW1z+Xfv4IscQAheJQw Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6816394EC41@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67007DB93J827264198-02-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6816394EC41SJEXCHCCR02co_ Subject: Re: [IPsec] Proposed work item: WESP extensibility - YES 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, 08 Dec 2009 19:01:11 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6816394EC41SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable In general I find the OA&M options useful and, if the work item is accepted= , would like to be a reviewer. Thanks, --Joe --_000_2C2F1EBA8050E74EA81502D5740B4BD6816394EC41SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
 
In genera= l I find=20 the OA&M options useful and, if the work item is accepted, would like t= o be=20 a reviewer.

Thanks,
--Joe
--_000_2C2F1EBA8050E74EA81502D5740B4BD6816394EC41SJEXCHCCR02co_-- From Jarrett.Lu@Sun.COM Tue Dec 8 15:30: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 DAD723A694E for ; Tue, 8 Dec 2009 15:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.445 X-Spam-Level: X-Spam-Status: No, score=-5.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_72=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 meY15VFxvopP for ; Tue, 8 Dec 2009 15:30:50 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by core3.amsl.com (Postfix) with ESMTP id C6C673A683D for ; Tue, 8 Dec 2009 15:30:48 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB8NUaSN012014 for ; Tue, 8 Dec 2009 15:30:36 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_0UBOajai6SGoBEED2mRuBg)" Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUC00800X820T00@fe-sfbay-09.sun.com> for ipsec@ietf.org; Tue, 08 Dec 2009 15:30:36 -0800 (PST) Received: from neteffect.Eng.Sun.COM ([unknown] [129.146.108.88]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUC00BY3XAY08B0@fe-sfbay-09.sun.com>; Tue, 08 Dec 2009 15:30:35 -0800 (PST) Date: Tue, 08 Dec 2009 15:31:17 -0800 From: Jarrett Lu Sender: Jarrett.Lu@Sun.COM To: latten@austin.ibm.com Message-id: <4B1EE1C5.3020807@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090910) Cc: David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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: Tue, 08 Dec 2009 23:30:52 -0000 This is a multi-part message in MIME format. --Boundary_(ID_0UBOajai6SGoBEED2mRuBg) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT > > Joy Latten wrote: > On Mon, 2009-12-07 at 15:02 -0600, Nicolas Williams wrote: > >> On Mon, Dec 07, 2009 at 10:10:15AM -0600, Joy Latten wrote: >> >>>> The proposed work item is, at first glance anyways, too SELinux- >>>> specific. >>>> >>>> Note that SMACK encodes its labels as CIPSO labels, so a scheme that >>>> uses CIPSO can possibly be used in SMACK and non-SMACK environments, and >>>> possibly even be mixed. >>>> >>> Yes, I agree. >>> >>> Actually, we hoped the method we introduced was generic enough to >>> accommodate both CIPSO and SMACK and any other MAC besides SELinux. >>> We had hoped to do this by treating the security context as an opaque >>> blob and introducing a DOI. >>> >>> I've actually discussed and collaborated about the "DOI" concept with >>> Linux's CIPSO developer, and labeled nfs' developer. SMACK developer >>> was included, but I do not recall if he said anything. We hoped that >>> this "DOI" would not only be used by labeled IPsec, but CIPSO and others >>> that use labels on the network. In a way, the "DOI" would help >>> to identify the "mapping", thus perhaps allowing different MACs to talk >>> to each other. Interoperability was and is a chief concern. However, >>> I am sure the drafts most definitely can be improved upon. >>> >> See the long threads on related topics on the SAAG and NFSv4 lists with >> subjects: >> >> - Common labeled security (comment on CALIPSO, labeled NFSv4) >> - Why the IETF should care about labeled?ne tworking (was:CIPSO >> implementations) >> - Secdir Review of draft-stjohns-sipso-05 >> > > Thanks for pointing this out. I was not aware of the threads and > am finding them very interesting and informative. > Without rehashing the statements made in above discussion threads, it's probably helpful to have a realistic interoperability expectation for labeled systems. Defining label formats and security mechanisms in various networking protocols is important. Consistent label interpretation and label policy enforcement are also key to labeled communication. Note the latter is mostly handled outside the protocols in this discussion. So in reality, only systems that implement same Mandatory Access Control (MAC) security models are likely to be able to inter-operate. A possible example is OpenSolaris FMAC and SELinux. The term "DOI" has been used in traditional MLS system for about two decades. In the MLS world, when systems use same DOI, it means they agree to the same label definition and MAC policy, and the systems are most likely under same administrative control (Note which policy is agreed upon is handled outside of a networking protocol). The label format is determined, i.e. it's CIPSO. In the current "Labeled IPsec" proposal, DOI is a Security Label Format Selector. I really think you ought to use a different name, calling it what it is and not be confused with MLS DOI. And use ISAMKP DOI when appropriate to avoid confusion. > >> I'm not sure what the best way forward is, but here are some thoughts: >> >> - A notification indicating what DOI(s) are supported by the sender >> might help. >> >> > Yes. The drafts suggest that by specifying the DOI as part of the SPD > entry, that would identify the DOI to support for this traffic stream. > > >> Not that I expect that any system will participate in multiple DOIs, >> but then, IIRC SMACK supports mappings of SMACK labels (which hijack >> a level in CIPSO) to non-SMACK CIPSO labels for interop, for example. >> This idea is probably not too farfetched. >> >> - A label type in addition to DOI. >> >> > Ok. I originally perceived this as part of the DOI description, but I > could understand wanting to separate for perhaps flexibility. > David Quigley and I had some offline conversation about this, as he has the same need for labeled NFSv4 work. The current thinking is to have a separate draft describing the need to set up an IANA registry and its content. Each entry consists at least the following fields: LABEL TYPE: A number to indicate label type, e.g. CIPSO, CALIPSO, SELinux security contex strings, etc. SUB FIELD: Used to aid label handling, e.g. SELinux could use it for policy version numbers; CIPSO could use it for tag type; LABEL FORMAT: pointers to reference docs on how labels should be parsed. Both Labeled IPsec and labeled NFSv4 (and any future label protocol extensions) can refer to this document. > >> Not that I expect a single DOI to use multiple label types, but at >> least one can then parse the label payload according to the stated >> type rather than having to find the right type for the given DOI. >> >> - Text on the encodings of specific label types' labels. >> >> Particularly I think you need to have normative references to the >> relevant RFCs and other work for the 'core' label types. >> >> > Yes, I agree, although I am unaware of any RFCs dealing with that yet. > There are more references for MLS labels (FIPS 188, CALIPSO draft, etc.) as they have a longer history. BTW, I don't think the label format specification has to be IETF RFCs. - Jarrett --Boundary_(ID_0UBOajai6SGoBEED2mRuBg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT 
Joy Latten wrote:
On Mon, 2009-12-07 at 15:02 -0600, Nicolas Williams wrote:
  
On Mon, Dec 07, 2009 at 10:10:15AM -0600, Joy Latten wrote:
  
The proposed work item is, at first glance anyways, too SELinux-
specific.

Note that SMACK encodes its labels as CIPSO labels, so a scheme that
uses CIPSO can possibly be used in SMACK and non-SMACK environments, and
possibly even be mixed.
      
Yes, I agree. 

Actually, we hoped the method we introduced was generic enough to 
accommodate both CIPSO and SMACK and any other MAC besides SELinux.
We had hoped to do this by treating the security context as an opaque
blob and introducing a DOI. 

I've actually discussed and collaborated about the "DOI" concept with
Linux's CIPSO developer, and labeled nfs' developer. SMACK developer
was included, but I do not recall if he said anything. We hoped that
this "DOI" would not only be used by labeled IPsec, but CIPSO and others
that use labels on the network. In a way, the "DOI" would help
to identify the "mapping", thus perhaps allowing  different MACs to talk
to each other. Interoperability was and is a chief concern. However, 
I am sure the drafts most definitely can be improved upon.
    
See the long threads on related topics on the SAAG and NFSv4 lists with
subjects:

 - Common labeled security (comment on CALIPSO, labeled NFSv4)
 - Why the IETF should care about labeled?ne tworking (was:CIPSO
   implementations)
 - Secdir Review of draft-stjohns-sipso-05
  

Thanks for pointing this out. I was not aware of the threads and
am finding them very interesting and informative.

Without rehashing the statements made in above discussion threads, it's probably helpful to have a realistic interoperability expectation for labeled systems. Defining label formats and security mechanisms in various networking protocols is important. Consistent label interpretation and label policy enforcement are also key to labeled communication. Note the latter is mostly handled outside the protocols in this discussion. So in reality, only systems that implement same Mandatory Access Control (MAC) security models are likely to be able to inter-operate. A possible example is OpenSolaris FMAC and SELinux.

The term "DOI" has been used in traditional MLS system for about two decades. In the MLS world, when systems use same DOI, it means they agree to the same label definition and MAC policy, and the systems are most likely under same administrative control (Note which policy is agreed upon is handled outside of a networking protocol). The label format is determined, i.e. it's CIPSO. In the current "Labeled IPsec" proposal, DOI is a Security Label Format Selector. I really think you ought to use a different name, calling it what it is and not be confused with MLS DOI. And use ISAMKP DOI when appropriate to avoid confusion.

  
I'm not sure what the best way forward is, but here are some thoughts:

 - A notification indicating what DOI(s) are supported by the sender
   might help.

  
Yes. The drafts suggest that by specifying the DOI as part of the SPD
entry, that would identify the DOI to support for this traffic stream.
 
  
   Not that I expect that any system will participate in multiple DOIs,
   but then, IIRC SMACK supports mappings of SMACK labels (which hijack
   a level in CIPSO) to non-SMACK CIPSO labels for interop, for example.
   This idea is probably not too farfetched.

 - A label type in addition to DOI.

  
Ok. I originally perceived this as part of the DOI description, but I 
could understand wanting to separate for perhaps flexibility.

David Quigley and I had some offline conversation about this, as he has the same need for labeled NFSv4 work. The current thinking is to have a separate draft describing the need to set up an IANA registry and its content. Each entry consists at least the following fields:
LABEL TYPE: A number to indicate label type, e.g.  CIPSO, CALIPSO, SELinux security contex strings, etc.
SUB FIELD: Used to aid label handling, e.g. SELinux could use it for policy version numbers; CIPSO could use it for tag type;
LABEL FORMAT: pointers to reference docs on how labels should be parsed.

Both Labeled IPsec and labeled NFSv4 (and any future label protocol extensions) can refer to this document.

  
   Not that I expect a single DOI to use multiple label types, but at
   least one can then parse the label payload according to the stated
   type rather than having to find the right type for the given DOI.

 - Text on the encodings of specific label types' labels.

   Particularly I think you need to have normative references to the
   relevant RFCs and other work for the 'core' label types.

  
Yes, I agree, although I am unaware of any RFCs dealing with that yet.

There are more references for MLS labels (FIPS 188, CALIPSO draft, etc.) as they have a longer history. BTW, I don't think the label format specification has to be IETF RFCs.

- Jarrett

--Boundary_(ID_0UBOajai6SGoBEED2mRuBg)-- From Nicolas.Williams@sun.com Tue Dec 8 18:19: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 51C073A692D for ; Tue, 8 Dec 2009 18:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.907 X-Spam-Level: X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=0.139, 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 RvkSGk3yo42z for ; Tue, 8 Dec 2009 18:19:47 -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 72A973A672F for ; Tue, 8 Dec 2009 18:19:46 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB92JZi6029248 for ; Wed, 9 Dec 2009 02:19:35 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nB92JZim030434 for ; Tue, 8 Dec 2009 19:19:35 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nB927jiJ002003; Tue, 8 Dec 2009 20:07:45 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB927jvx002002; Tue, 8 Dec 2009 20:07:45 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 8 Dec 2009 20:07:45 -0600 From: Nicolas Williams To: Michael Richardson Message-ID: <20091209020744.GF1516@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> <4B187F98.5040608@sandelman.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B187F98.5040608@sandelman.ca> User-Agent: Mutt/1.5.7i 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: Wed, 09 Dec 2009 02:19:48 -0000 On Thu, Dec 03, 2009 at 10:18:48PM -0500, Michael Richardson wrote: > Dan Harkins wrote: > > 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, > > Does it double, or does it really just "n+1", which is doubling if the > rest of the protocol has "n=1"? I also wonder if this is really a > sufficiently compelling reason to have two sets of code. > > > 3. is insecure (unless something used nowhere today is employed: EAP > > channel bindings). > > We can, and must solve this. It's not just EAP channel binding that you need, but EAP cryptographic binding. Remember: what EAP calls "channel binding" is very different from the meaning of "channel binding" used elsewhere (RFC5056 describes the difference in terminology); EAP cryptographic binding is closer to the more generic (IMO) meaning of channel binding. (Just trying to avoid confusion!) Nico -- From yaronf@checkpoint.com Tue Dec 8 22:12: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 8D72E3A6AC9 for ; Tue, 8 Dec 2009 22:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 ANFaG-XAemVx for ; Tue, 8 Dec 2009 22:12:29 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 233693A6986 for ; Tue, 8 Dec 2009 22:12: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 nB96CGGo020969; Wed, 9 Dec 2009 08:12:16 +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, 9 Dec 2009 08:12:26 +0200 From: Yaron Sheffer To: Nicolas Williams , Michael Richardson Date: Wed, 9 Dec 2009 08:12:25 +0200 Thread-Topic: [IPsec] Proposed work item: EAP-only authentication in IKEv2 Thread-Index: Acp4dhn2PAJTAt1+QG6XxiWS9Cd8wAAHw2TA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893E801@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com> <4B187F98.5040608@sandelman.ca> <20091209020744.GF1516@Sun.COM> In-Reply-To: <20091209020744.GF1516@Sun.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] 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: Wed, 09 Dec 2009 06:12:33 -0000 Hi Nico, If I understand you correctly, EAP crypto binding is what IKEv2 provides by= default, by including the EAP MSK into the IKE AUTH payload (RFC 4306, sec= . 2.16 and 2.15). I believe what Dan is discussing is enabling secure trans= mission of ID parameters over the EAP channel (sorry...), which is exactly = what RFC 5056 refers to as "EAP channel binding". Is there anything more th= at's needed? Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Nicolas Williams > Sent: Wednesday, December 09, 2009 4:08 > To: Michael Richardson > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2 >=20 > On Thu, Dec 03, 2009 at 10:18:48PM -0500, Michael Richardson wrote: > > Dan Harkins wrote: > > > 2. solves the specific problem it is aimed at poorly-- doubling o= f > > > the number of messages, requiring writing and testing of new > > > state EAP state machines that are, otherwise, unnecessary; and= , > > > > Does it double, or does it really just "n+1", which is doubling if the > > rest of the protocol has "n=3D1"? I also wonder if this is really a > > sufficiently compelling reason to have two sets of code. > > > > > 3. is insecure (unless something used nowhere today is employed: > EAP > > > channel bindings). > > > > We can, and must solve this. >=20 > It's not just EAP channel binding that you need, but EAP cryptographic > binding. Remember: what EAP calls "channel binding" is very different > from the meaning of "channel binding" used elsewhere (RFC5056 describes > the difference in terminology); EAP cryptographic binding is closer to > the more generic (IMO) meaning of channel binding. (Just trying to > avoid confusion!) >=20 > Nico > -- > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From Jarrett.Lu@Sun.COM Tue Dec 8 22:53: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 93B893A6ADF for ; Tue, 8 Dec 2009 22:53:30 -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 wLTyN5lFwU28 for ; Tue, 8 Dec 2009 22:53:29 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by core3.amsl.com (Postfix) with ESMTP id 8755B3A6ADD for ; Tue, 8 Dec 2009 22:53:26 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB96rFIV026473 for ; Tue, 8 Dec 2009 22:53:15 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUD00F00HFE7M00@fe-sfbay-09.sun.com> for ipsec@ietf.org; Tue, 08 Dec 2009 22:53:15 -0800 (PST) Received: from [192.168.1.55] ([unknown] [71.202.132.81]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUD0043VHSL20E0@fe-sfbay-09.sun.com>; Tue, 08 Dec 2009 22:53:14 -0800 (PST) Date: Tue, 08 Dec 2009 22:53:18 -0800 From: Jarrett Lu In-reply-to: <4B1F200F.6080105@schaufler-ca.com> Sender: Jarrett.Lu@Sun.COM To: Casey Schaufler Message-id: <4B1F495E.8060901@sun.com> References: <4B1EE1C5.3020807@sun.com> <4B1F200F.6080105@schaufler-ca.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Cc: David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, serue@linux.vnet.ibm.com Subject: Re: [IPsec] Proposed work item: Labelled IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jarrett.Lu@Sun.COM List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 06:53:30 -0000 Casey Schaufler wrote: > Jarrett Lu wrote: > >> Without rehashing the statements made in above discussion threads, >> it's probably helpful to have a realistic interoperability expectation >> for labeled systems. Defining label formats and security mechanisms in >> various networking protocols is important. >> > > This reflects the traditional viewpoint and is a major obstacle to > progress in the modern world. The modern reality is that two SELinux > systems installed with the same software from the same distribution > at the same time with configuration parameters that you might think > would be insignificant may well have policies with differences that > can not be reconciled in a network protocol. > > But it's worse than that. Static label formats (e.g. Bell & LaPadula) > are often cited as the downfall of the 1990's MLS systems. In the > rest of the OS the notion has been discarded. None of the current LSMs > use a structured label format, unless you want to argue that the > SELinux label format is structured, in which case you're likely to > hear that it is structured for flexibility. Networking is the final > hold-out for the archaic notion that labels should be inherently > meaningful. > > >> Consistent label interpretation and label policy enforcement are also >> key to labeled communication. >> > > This has never ever been true, not even once. You need look no > further than the level "Secret", which means something very different > in the US Department of Defense and in the Department of Energy. > The only case where a serious attempt was made was IPSO, which > had a classified mapping of DoD categories in the label. > Although your statements sound a lot different, I think we are actually in agreement for the most part, i.e. having a labeled networking protocol alone is insufficient for MAC system interoperability. For example, it's pointless if two systems can't agree on what "Secret" means. > >> Note the latter is mostly handled outside the protocols in this >> discussion. So in reality, only systems that implement same Mandatory >> Access Control (MAC) security models are likely to be able to >> inter-operate. A possible example is OpenSolaris FMAC and SELinux. >> > > This is also a common misconception. In truth, two SELinux systems are > no more likely to interact properly than a Trusted Solaris system and > one running UNICOS/MLS. > The bottom line is that the MAC systems should enforce the same policy in order for " interoperability" to make sense. How to ensure policy consistency across communicating systems is beyond Labeled IPsec, and is probably a burden on the system/network administrators. This comes back to my earlier point of having a realistic expectation of MAC system interoperability. > >> The term "DOI" has been used in traditional MLS system for about two >> decades. In the MLS world, when systems use same DOI, it means they >> agree to the same label definition and MAC policy, and the systems are >> most likely under same administrative control (Note which policy is >> agreed upon is handled outside of a networking protocol). The label >> format is determined, i.e. it's CIPSO. >> > > Actually, the TSIG definition only requires that the two be able > to work out their differences. They are not required to speak the > same dialect. > True. They need not be identical but must be consistent. > >> In the current "Labeled IPsec" proposal, DOI is a Security Label >> Format Selector. I really think you ought to use a different name, >> calling it what it is and not be confused with MLS DOI. And use ISAMKP >> DOI when appropriate to avoid confusion. >> > > Sure. > > >> David Quigley and I had some offline conversation about this, as he >> has the same need for labeled NFSv4 work. The current thinking is to >> have a separate draft describing the need to set up an IANA registry >> and its content. Each entry consists at least the following fields: >> LABEL TYPE: A number to indicate label type, e.g. CIPSO, CALIPSO, >> SELinux security contex strings, etc. >> SUB FIELD: Used to aid label handling, e.g. SELinux could use it for >> policy version numbers; CIPSO could use it for tag type; >> LABEL FORMAT: pointers to reference docs on how labels should be parsed. >> >> Both Labeled IPsec and labeled NFSv4 (and any future label protocol >> extensions) can refer to this document. >> > > Two systems, no matter how similar, will never be able to translate > formatted labels reliably. It only takes trivial changes to an SELinux > system for my_dog_has_no_nose_t to mean completely different things > on the two machines. > I don't think this is the problem we are trying to solve here. I believe we are trying to solve the problem of getting packet labels across the network with confidentiality and integrity protection. The security administrators need to make sure your dog_has_no_nose_t is same as my dog_has_nose_t on two systems. - Jarrett From denghui02@gmail.com Wed Dec 9 07:42: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 BDD633A6A14 for ; Wed, 9 Dec 2009 07:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 A442c6vLsVCR for ; Wed, 9 Dec 2009 07:42:23 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id B2A823A67DF for ; Wed, 9 Dec 2009 07:42:19 -0800 (PST) Received: by pzk6 with SMTP id 6so5571819pzk.29 for ; Wed, 09 Dec 2009 07:42:06 -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=BDCjwxfuCgroKr3atGt+KXNtXTFRCfj/IJ4YszcXHZY=; b=e34UrHS9bdMJxXiJdlf1eGQbbMckT6kbT2NU0wOwFMKOq9k7ptwC84h0NbZiviWW1f yBYdDAmPitXWDJHziAzzLH+rnga4efbg6ahyB491sY/p2OAIzbWy88CBpDV7ps3Tvnv5 hTw04AqG55+jKrhgIDOKQfdv2NVhVZjUTuSo4= 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=TaTWivnv8hLSO4folOgko/aBgJa0d22vVyxY3Pf+1Ss3o5xEsl03h1MamDDQ15O8rm RWx5R1Ru3b2iDLAPoTh5UjSem7BFkZOC1v0kAkyaJ76KD6nosjKY9CUj11rEutmtjZZM I3Y3FD3rMySuguSavDUGiZVG/MNVfRv7O/EDk= MIME-Version: 1.0 Received: by 10.141.131.11 with SMTP id i11mr308903rvn.299.1260373326608; Wed, 09 Dec 2009 07:42:06 -0800 (PST) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> Date: Wed, 9 Dec 2009 23:42:06 +0800 Message-ID: <1d38a3350912090742q1976ffefo85ef5e0e5627ec0b@mail.gmail.com> From: Hui Deng To: Yaron Sheffer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" Subject: Re: [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: Wed, 09 Dec 2009 15:42:24 -0000 would like to co-author, thanks -Hui 2009/11/30 Yaron Sheffer : > This draft proposes an IKEv2 extension to allow the setup of an IKE SA wi= th no Child SA, a situation which is currently disallowed by the protocol. > > Proposed starting point: http://tools.ietf.org/id/draft-nir-ipsecme-child= less-01.txt. > > Please reply to the list: > > - If this proposal is accepted as a WG work item, are you committing to r= eview 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 fin= e 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 in= dustry 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 paul.hoffman@vpnc.org Wed Dec 9 08:15: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 E6D4528C13D for ; Wed, 9 Dec 2009 08:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.961 X-Spam-Level: X-Spam-Status: No, score=-5.961 tagged_above=-999 required=5 tests=[AWL=0.085, 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 nlvyt5n6azDL for ; Wed, 9 Dec 2009 08:15:06 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 25B033A67E3 for ; Wed, 9 Dec 2009 08:15:05 -0800 (PST) Received: from [75.101.18.87] (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 nB9FwciB092178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Dec 2009 08:58:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04ED@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04ED@il-ex01.ad.checkpoint.com> Date: Wed, 9 Dec 2009 07:58:37 -0800 To: "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [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: Wed, 09 Dec 2009 16:15:11 -0000 A big thank you to everyone for their input. Yaron and I have compiled the responses, and are now in discussion with Pasi (wearing his AD hat) on how to proceed. We will get back to the WG when we have a plan, but it probably won't be for a week or so. --Paul Hoffman, Director --VPN Consortium From casey@schaufler-ca.com Tue Dec 8 19:57: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 553233A6A93 for ; Tue, 8 Dec 2009 19:57:19 -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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, UNPARSEABLE_RELAY=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 LhlC0zimD0Tx for ; Tue, 8 Dec 2009 19:57:18 -0800 (PST) Received: from smtp106.prem.mail.sp1.yahoo.com (smtp106.prem.mail.sp1.yahoo.com [98.136.44.61]) by core3.amsl.com (Postfix) with SMTP id 4A3AE3A6A76 for ; Tue, 8 Dec 2009 19:57:18 -0800 (PST) Received: (qmail 42679 invoked from network); 9 Dec 2009 03:57:06 -0000 Received: from c-76-102-151-19.hsd1.ca.comcast.net (casey@76.102.151.19 with plain) by smtp106.prem.mail.sp1.yahoo.com with SMTP; 08 Dec 2009 19:57:05 -0800 PST X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- X-YMail-OSG: I2SwyswVM1nfEwdXjOwBYHIbgi1AgX81oDaK7uDkneOUdAt101TRt_1HKxDpowezpI3_ghZYg.lfSZWhCZGemWUo.f7HiaTxKIbkZvfH4mqeBDznUnX1Jmza7X9UciRSFmAl2mvBrbqSKeDT8ZS0biQJ8tbEA2Hmij4uLMzu_8tQsQg_Fke3QTleKh2Tl7aD.ftJzP8UbHAuw4D0CYr8UMspHAGqN1wTb_caQldFBRBB5YKagsTlfs6rRkNrpgJI85WcfZCKCtbe0oWY8nrhSOczOKQeCsYVzgSNl_9PWdVicRjxsfsx6y8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1F200F.6080105@schaufler-ca.com> Date: Tue, 08 Dec 2009 19:57:03 -0800 From: Casey Schaufler User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jarrett Lu References: <4B1EE1C5.3020807@sun.com> In-Reply-To: <4B1EE1C5.3020807@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 09 Dec 2009 08:40:06 -0800 Cc: David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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: Wed, 09 Dec 2009 03:57:19 -0000 Jarrett Lu wrote: >> Joy Latten wrote: >> On Mon, 2009-12-07 at 15:02 -0600, Nicolas Williams wrote: >> >>> On Mon, Dec 07, 2009 at 10:10:15AM -0600, Joy Latten wrote: >>> >>>>> The proposed work item is, at first glance anyways, too SELinux- >>>>> specific. >>>>> >>>>> Note that SMACK encodes its labels as CIPSO labels, so a scheme that >>>>> uses CIPSO can possibly be used in SMACK and non-SMACK environments, and >>>>> possibly even be mixed. >>>>> >>>> Yes, I agree. >>>> >>>> Actually, we hoped the method we introduced was generic enough to >>>> accommodate both CIPSO and SMACK and any other MAC besides SELinux. >>>> We had hoped to do this by treating the security context as an opaque >>>> blob and introducing a DOI. >>>> >>>> I've actually discussed and collaborated about the "DOI" concept with >>>> Linux's CIPSO developer, and labeled nfs' developer. SMACK developer >>>> was included, but I do not recall if he said anything. We hoped that >>>> this "DOI" would not only be used by labeled IPsec, but CIPSO and others >>>> that use labels on the network. In a way, the "DOI" would help >>>> to identify the "mapping", thus perhaps allowing different MACs to talk >>>> to each other. Interoperability was and is a chief concern. However, >>>> I am sure the drafts most definitely can be improved upon. >>>> >>> See the long threads on related topics on the SAAG and NFSv4 lists with >>> subjects: >>> >>> - Common labeled security (comment on CALIPSO, labeled NFSv4) >>> - Why the IETF should care about labeled?ne tworking (was:CIPSO >>> implementations) >>> - Secdir Review of draft-stjohns-sipso-05 >>> >> >> Thanks for pointing this out. I was not aware of the threads and >> am finding them very interesting and informative. >> > > Without rehashing the statements made in above discussion threads, > it's probably helpful to have a realistic interoperability expectation > for labeled systems. Defining label formats and security mechanisms in > various networking protocols is important. This reflects the traditional viewpoint and is a major obstacle to progress in the modern world. The modern reality is that two SELinux systems installed with the same software from the same distribution at the same time with configuration parameters that you might think would be insignificant may well have policies with differences that can not be reconciled in a network protocol. But it's worse than that. Static label formats (e.g. Bell & LaPadula) are often cited as the downfall of the 1990's MLS systems. In the rest of the OS the notion has been discarded. None of the current LSMs use a structured label format, unless you want to argue that the SELinux label format is structured, in which case you're likely to hear that it is structured for flexibility. Networking is the final hold-out for the archaic notion that labels should be inherently meaningful. > Consistent label interpretation and label policy enforcement are also > key to labeled communication. This has never ever been true, not even once. You need look no further than the level "Secret", which means something very different in the US Department of Defense and in the Department of Energy. The only case where a serious attempt was made was IPSO, which had a classified mapping of DoD categories in the label. > Note the latter is mostly handled outside the protocols in this > discussion. So in reality, only systems that implement same Mandatory > Access Control (MAC) security models are likely to be able to > inter-operate. A possible example is OpenSolaris FMAC and SELinux. This is also a common misconception. In truth, two SELinux systems are no more likely to interact properly than a Trusted Solaris system and one running UNICOS/MLS. > > The term "DOI" has been used in traditional MLS system for about two > decades. In the MLS world, when systems use same DOI, it means they > agree to the same label definition and MAC policy, and the systems are > most likely under same administrative control (Note which policy is > agreed upon is handled outside of a networking protocol). The label > format is determined, i.e. it's CIPSO. Actually, the TSIG definition only requires that the two be able to work out their differences. They are not required to speak the same dialect. > In the current "Labeled IPsec" proposal, DOI is a Security Label > Format Selector. I really think you ought to use a different name, > calling it what it is and not be confused with MLS DOI. And use ISAMKP > DOI when appropriate to avoid confusion. Sure. > >> >>> I'm not sure what the best way forward is, but here are some thoughts: >>> >>> - A notification indicating what DOI(s) are supported by the sender >>> might help. >>> >>> >> Yes. The drafts suggest that by specifying the DOI as part of the SPD >> entry, that would identify the DOI to support for this traffic stream. >> >> >>> Not that I expect that any system will participate in multiple DOIs, >>> but then, IIRC SMACK supports mappings of SMACK labels (which hijack >>> a level in CIPSO) to non-SMACK CIPSO labels for interop, for example. >>> This idea is probably not too farfetched. >>> >>> - A label type in addition to DOI. >>> >>> >> Ok. I originally perceived this as part of the DOI description, but I >> could understand wanting to separate for perhaps flexibility. >> > > David Quigley and I had some offline conversation about this, as he > has the same need for labeled NFSv4 work. The current thinking is to > have a separate draft describing the need to set up an IANA registry > and its content. Each entry consists at least the following fields: > LABEL TYPE: A number to indicate label type, e.g. CIPSO, CALIPSO, > SELinux security contex strings, etc. > SUB FIELD: Used to aid label handling, e.g. SELinux could use it for > policy version numbers; CIPSO could use it for tag type; > LABEL FORMAT: pointers to reference docs on how labels should be parsed. > > Both Labeled IPsec and labeled NFSv4 (and any future label protocol > extensions) can refer to this document. Two systems, no matter how similar, will never be able to translate formatted labels reliably. It only takes trivial changes to an SELinux system for my_dog_has_no_nose_t to mean completely different things on the two machines. I stick by my claim that the right and only rational scheme is for each system to explicitly map the labels it understands from another system to local values, and vis versa. Any label without a mapping must be discarded unused. If you are brave and foolish you can say that the mapping is unity. > >> >>> Not that I expect a single DOI to use multiple label types, but at >>> least one can then parse the label payload according to the stated >>> type rather than having to find the right type for the given DOI. >>> >>> - Text on the encodings of specific label types' labels. >>> >>> Particularly I think you need to have normative references to the >>> relevant RFCs and other work for the 'core' label types. >>> >>> >> Yes, I agree, although I am unaware of any RFCs dealing with that yet. >> > > There are more references for MLS labels (FIPS 188, CALIPSO draft, > etc.) as they have a longer history. BTW, I don't think the label > format specification has to be IETF RFCs. Yeah, that would be bad. > > - Jarrett > From dpquigl@tycho.nsa.gov Wed Dec 9 07:30: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 49FE43A69F9 for ; Wed, 9 Dec 2009 07:30:54 -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 fqznxUOc8lav for ; Wed, 9 Dec 2009 07:30:53 -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 299DF3A69EE for ; Wed, 9 Dec 2009 07:30:52 -0800 (PST) Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id nB9FWZ84006302; Wed, 9 Dec 2009 15:32:35 GMT Received: from [144.51.25.2] (moss-terrapins [144.51.25.2]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id nB9FUDJ4029504; Wed, 9 Dec 2009 10:30:13 -0500 From: "David P. Quigley" To: Casey Schaufler In-Reply-To: <4B1F200F.6080105@schaufler-ca.com> References: <4B1EE1C5.3020807@sun.com> <4B1F200F.6080105@schaufler-ca.com> Content-Type: text/plain Organization: National Security Agency Date: Wed, 09 Dec 2009 10:21:30 -0500 Message-Id: <1260372090.2484.236.camel@moss-terrapins.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 09 Dec 2009 08:40:06 -0800 Cc: tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Jarrett Lu , serue@linux.vnet.ibm.com 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: Wed, 09 Dec 2009 15:30:54 -0000 On Tue, 2009-12-08 at 19:57 -0800, Casey Schaufler wrote: [snip] > > > > > The term "DOI" has been used in traditional MLS system for about two > > decades. In the MLS world, when systems use same DOI, it means they > > agree to the same label definition and MAC policy, and the systems are > > most likely under same administrative control (Note which policy is > > agreed upon is handled outside of a networking protocol). The label > > format is determined, i.e. it's CIPSO. > > Actually, the TSIG definition only requires that the two be able > to work out their differences. They are not required to speak the > same I think that this is a reasonable statement. [snip] > > > > David Quigley and I had some offline conversation about this, as he > > has the same need for labeled NFSv4 work. The current thinking is to > > have a separate draft describing the need to set up an IANA registry > > and its content. Each entry consists at least the following fields: > > LABEL TYPE: A number to indicate label type, e.g. CIPSO, CALIPSO, > > SELinux security contex strings, etc. > > SUB FIELD: Used to aid label handling, e.g. SELinux could use it for > > policy version numbers; CIPSO could use it for tag type; > > LABEL FORMAT: pointers to reference docs on how labels should be parsed. > > > > Both Labeled IPsec and labeled NFSv4 (and any future label protocol > > extensions) can refer to this document. > > Two systems, no matter how similar, will never be able to translate > formatted labels reliably. It only takes trivial changes to an SELinux > system for my_dog_has_no_nose_t to mean completely different things > on the two machines. > > I stick by my claim that the right and only rational scheme is for > each system to explicitly map the labels it understands from another > system to local values, and vis versa. Any label without a mapping > must be discarded unused. If you are brave and foolish you can say > that the mapping is unity. > I'm pretty sure this is what has been proposed from the beginning. I don't know where in our conversations at least that I've given you a different opinion. > > > >> > >>> Not that I expect a single DOI to use multiple label types, but at > >>> least one can then parse the label payload according to the stated > >>> type rather than having to find the right type for the given DOI. > >>> > >>> - Text on the encodings of specific label types' labels. > >>> > >>> Particularly I think you need to have normative references to the > >>> relevant RFCs and other work for the 'core' label types. > >>> > >>> > >> Yes, I agree, although I am unaware of any RFCs dealing with that yet. > >> > > > > There are more references for MLS labels (FIPS 188, CALIPSO draft, > > etc.) as they have a longer history. BTW, I don't think the label > > format specification has to be IETF RFCs. > > Yeah, that would be bad. I spoke with the people at IANA and I believe that we're going to go with a hybrid approach for the registry. It is going to be open standard meaning that the document that describes the format must be freely available and there will also be an expert review requirement. Dave From casey@schaufler-ca.com Wed Dec 9 08:22: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 D8CD13A6AA0 for ; Wed, 9 Dec 2009 08:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 iXiMpyOy677J for ; Wed, 9 Dec 2009 08:22:15 -0800 (PST) Received: from smtp104.prem.mail.sp1.yahoo.com (smtp104.prem.mail.sp1.yahoo.com [98.136.44.59]) by core3.amsl.com (Postfix) with SMTP id A9A683A6A6F for ; Wed, 9 Dec 2009 08:22:15 -0800 (PST) Received: (qmail 24944 invoked from network); 9 Dec 2009 16:22:03 -0000 Received: from c-76-102-151-19.hsd1.ca.comcast.net (casey@76.102.151.19 with plain) by smtp104.prem.mail.sp1.yahoo.com with SMTP; 09 Dec 2009 08:22:03 -0800 PST X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- X-YMail-OSG: e_Z79asVM1m1Huo59bOhPtjtonja7TcM6ID1N9o8nY1OcBGtUnkd0P0EVVUrqgH06xXXhmC_kxRMTpbm51B7mH4GN07Pr3hQsA4.khGPu1t05tGvJA0nFI_xB4K5NKNvnYTMjwDfSXEnfbantpN4RmL4uXm3NOTum3WSgZKoRFicDsYyXVGZ11um4WWgxAZcT87aaM5OF.D1KjgkIWTEI..Kr5H0aSiTnViFZODFBiqupb2PWGphiaiV85WKPOqetc9qhg9MVTuOHAPtyUk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B1FCEA7.90609@schaufler-ca.com> Date: Wed, 09 Dec 2009 08:21:59 -0800 From: Casey Schaufler User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jarrett.Lu@Sun.COM References: <4B1EE1C5.3020807@sun.com> <4B1F200F.6080105@schaufler-ca.com> <4B1F495E.8060901@sun.com> In-Reply-To: <4B1F495E.8060901@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 09 Dec 2009 08:40:06 -0800 Cc: David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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: Wed, 09 Dec 2009 16:22:17 -0000 Jarrett Lu wrote: > Casey Schaufler wrote: >> Jarrett Lu wrote: >> >>> Without rehashing the statements made in above discussion threads, >>> it's probably helpful to have a realistic interoperability expectation >>> for labeled systems. Defining label formats and security mechanisms in >>> various networking protocols is important. >>> >> >> This reflects the traditional viewpoint and is a major obstacle to >> progress in the modern world. The modern reality is that two SELinux >> systems installed with the same software from the same distribution >> at the same time with configuration parameters that you might think >> would be insignificant may well have policies with differences that >> can not be reconciled in a network protocol. >> >> But it's worse than that. Static label formats (e.g. Bell & LaPadula) >> are often cited as the downfall of the 1990's MLS systems. In the >> rest of the OS the notion has been discarded. None of the current LSMs >> use a structured label format, unless you want to argue that the >> SELinux label format is structured, in which case you're likely to >> hear that it is structured for flexibility. Networking is the final >> hold-out for the archaic notion that labels should be inherently >> meaningful. >> >> >>> Consistent label interpretation and label policy enforcement are also >>> key to labeled communication. >>> >> >> This has never ever been true, not even once. You need look no >> further than the level "Secret", which means something very different >> in the US Department of Defense and in the Department of Energy. >> The only case where a serious attempt was made was IPSO, which >> had a classified mapping of DoD categories in the label. >> > > Although your statements sound a lot different, I think we are > actually in agreement for the most part, i.e. having a labeled > networking protocol alone is insufficient for MAC system > interoperability. For example, it's pointless if two systems can't > agree on what "Secret" means. The subtle distinction begin that they don't need to agree what Secret means, but they must each know what to do with a Secret presented to them by the other. > >> >>> Note the latter is mostly handled outside the protocols in this >>> discussion. So in reality, only systems that implement same Mandatory >>> Access Control (MAC) security models are likely to be able to >>> inter-operate. A possible example is OpenSolaris FMAC and SELinux. >>> >> >> This is also a common misconception. In truth, two SELinux systems are >> no more likely to interact properly than a Trusted Solaris system and >> one running UNICOS/MLS. >> > > The bottom line is that the MAC systems should enforce the same policy > in order for " interoperability" to make sense. Nope. I disagree. Two wildly divergent policies can interoperate. I have seen it done. It is not pleasant to gaze upon, and there is lots of human overhead to set it up, but it does happen because in the real world it must. > How to ensure policy consistency across communicating systems is > beyond Labeled IPsec, and is probably a burden on the system/network > administrators. This comes back to my earlier point of having a > realistic expectation of MAC system interoperability. Yes, with this I can agree. > >> >>> The term "DOI" has been used in traditional MLS system for about two >>> decades. In the MLS world, when systems use same DOI, it means they >>> agree to the same label definition and MAC policy, and the systems are >>> most likely under same administrative control (Note which policy is >>> agreed upon is handled outside of a networking protocol). The label >>> format is determined, i.e. it's CIPSO. >> >> Actually, the TSIG definition only requires that the two be able >> to work out their differences. They are not required to speak the >> same dialect. >> > > True. They need not be identical but must be consistent. > >> >>> In the current "Labeled IPsec" proposal, DOI is a Security Label >>> Format Selector. I really think you ought to use a different name, >>> calling it what it is and not be confused with MLS DOI. And use ISAMKP >>> DOI when appropriate to avoid confusion. >>> >> >> Sure. >> >> >>> David Quigley and I had some offline conversation about this, as he >>> has the same need for labeled NFSv4 work. The current thinking is to >>> have a separate draft describing the need to set up an IANA registry >>> and its content. Each entry consists at least the following fields: >>> LABEL TYPE: A number to indicate label type, e.g. CIPSO, CALIPSO, >>> SELinux security contex strings, etc. >>> SUB FIELD: Used to aid label handling, e.g. SELinux could use it for >>> policy version numbers; CIPSO could use it for tag type; >>> LABEL FORMAT: pointers to reference docs on how labels should be >>> parsed. >>> >>> Both Labeled IPsec and labeled NFSv4 (and any future label protocol >>> extensions) can refer to this document. >>> >> >> Two systems, no matter how similar, will never be able to translate >> formatted labels reliably. It only takes trivial changes to an SELinux >> system for my_dog_has_no_nose_t to mean completely different things >> on the two machines. >> > > I don't think this is the problem we are trying to solve here. I > believe we are trying to solve the problem of getting packet labels > across the network with confidentiality and integrity protection. But once people start down that path they always start trying to dictate what the on-wire labels are going to contain. And that is what needs to get nipped in the bud. > The security administrators need to make sure your dog_has_no_nose_t > is same as my dog_has_nose_t on two systems. Can't be done reliably. > > > > - Jarrett > > From kivinen@iki.fi Wed Dec 9 09:19: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 2E29E28C1C0 for ; Wed, 9 Dec 2009 09:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 FShM2LQkxf3O for ; Wed, 9 Dec 2009 09:19:00 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C27BA28C19B for ; Wed, 9 Dec 2009 09:18: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 nB9HIhLI006406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Dec 2009 19:18:43 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nB9HIhl8011126; Wed, 9 Dec 2009 19:18: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: <19231.56307.207454.101616@fireball.kivinen.iki.fi> Date: Wed, 9 Dec 2009 19:18:43 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04ED@il-ex01.ad.checkpoint.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" Subject: Re: [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: Wed, 09 Dec 2009 17:19:05 -0000 Paul Hoffman writes: > A big thank you to everyone for their input. Yaron and I have > compiled the responses, and are now in discussion with Pasi (wearing > his AD hat) on how to proceed. We will get back to the WG when we > have a plan, but it probably won't be for a week or so. Would it be possible to summarize the responses to the list even before that, just so people can verify that their "review/contribute/co-author" information has been understood correctly? -- kivinen@iki.fi From briansw@microsoft.com Wed Dec 9 09:21:14 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 BEF0D28C1C8 for ; Wed, 9 Dec 2009 09:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Vu4M2ulykS86 for ; Wed, 9 Dec 2009 09:21:06 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 76B3B28C19D for ; Wed, 9 Dec 2009 09:21:06 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 9 Dec 2009 09:20:55 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.0.639.20; Wed, 9 Dec 2009 09:20:55 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 9 Dec 2009 09:20:55 -0800 From: Brian Swander To: Tero Kivinen Thread-Topic: [IPsec] Proposed work item: WESP extensibility Thread-Index: AQHKd2lYa0dZXBgdqEylx9vU1Rj7J5FZ5CBQgAGliYCAAW8aIA== Date: Wed, 9 Dec 2009 17:20:55 +0000 Message-ID: <5E38DBF64E732C4C98512C53E1B14DDC299B1529@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> <5E38DBF64E732C4C98512C53E1B14DDC2999E319@TK5EX14MBXW653.wingroup.windeplo y.ntdev.microsoft.com> <5E38DBF64E732C4C98512C53E1B14DDC299ACE4A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <19230.14267.109849.507396@fireball.kivinen.iki.fi> In-Reply-To: <19230.14267.109849.507396@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Stephen Kent 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: Wed, 09 Dec 2009 17:21:14 -0000 AH alone isn't good enough. We need solutions that also work with end-to-e= nd encryption. bs -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi]=20 Sent: Tuesday, December 08, 2009 3:26 AM To: Brian Swander Cc: Stephen Kent; ipsec@ietf.org Subject: Re: [IPsec] Proposed work item: WESP extensibility Brian Swander writes: > 0 - option data does not change en-route. This option is > included in the WESP ICV computation. >=20 > We'll be using this flag, so this option will always be integrity > protected.=20 One of the things that disturb me here is that AH was not acceptable because of the complexity and because it didn't go through NATs, and now we are thinking of adding lots of complexity to the WESP (perhaps even more than what AH had by looking at some of the discussion). Perhaps it would be better to go back and say use AH instead, at least for that we would have some implementations and even when there is perhaps much less testing done on the AH than to ESP, it has still lots of more testing and experience than what we have from WESP... I still think that extending WESP in any ways is very bad idea, and if it is to be done, we need to first start from the exact scenarios where those extensions are needed, not make any generic framework or protocol document before we know what problems we are solving. This same thing was problematic for WESP. I am still not sure what problem we are solving, even when I am author of the another draft solving same "problems" than WESP. Every time someone starts discussing about the problems, it seems the problem is completely different... --=20 kivinen@iki.fi From paul.moore@hp.com Wed Dec 9 09:32: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 A5FF028C122 for ; Wed, 9 Dec 2009 09:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.266 X-Spam-Level: X-Spam-Status: No, score=-106.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 OnIpegcHprA5 for ; Wed, 9 Dec 2009 09:31:59 -0800 (PST) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by core3.amsl.com (Postfix) with ESMTP id A7E3E3A68CC for ; Wed, 9 Dec 2009 09:31:59 -0800 (PST) Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g1t0029.austin.hp.com (Postfix) with ESMTP id 575993858E; Wed, 9 Dec 2009 17:31:48 +0000 (UTC) Received: from ldl (linux.corp.hp.com [15.11.146.101]) by g1t0039.austin.hp.com (Postfix) with ESMTP id C7F6E342A7; Wed, 9 Dec 2009 17:31:22 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl (Postfix) with ESMTP id A3072CF0019; Wed, 9 Dec 2009 10:31:22 -0700 (MST) Received: from ldl ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+Rqy-2mRVol; Wed, 9 Dec 2009 10:31:22 -0700 (MST) Received: from flek.localnet (squirrel.fc.hp.com [15.11.146.57]) by ldl (Postfix) with ESMTP id 69605CF0016; Wed, 9 Dec 2009 10:31:22 -0700 (MST) From: Paul Moore Organization: Hewlett-Packard To: ipsec@ietf.org Date: Wed, 9 Dec 2009 12:31:21 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r2; KDE/4.3.4; i686; ; ) References: <4B1EE1C5.3020807@sun.com> <4B1F200F.6080105@schaufler-ca.com> <1260372090.2484.236.camel@moss-terrapins.epoch.ncsc.mil> In-Reply-To: <1260372090.2484.236.camel@moss-terrapins.epoch.ncsc.mil> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912091231.21086.paul.moore@hp.com> Cc: "David P. Quigley" , tjaeger@cse.psu.edu, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , Jarrett Lu , serue@linux.vnet.ibm.com 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: Wed, 09 Dec 2009 17:32:00 -0000 On Wednesday 09 December 2009 10:21:30 am David P. Quigley wrote: > On Tue, 2009-12-08 at 19:57 -0800, Casey Schaufler wrote: > [snip] > > > > The term "DOI" has been used in traditional MLS system for about two > > > decades. In the MLS world, when systems use same DOI, it means they > > > agree to the same label definition and MAC policy, and the systems are > > > most likely under same administrative control (Note which policy is > > > agreed upon is handled outside of a networking protocol). The label > > > format is determined, i.e. it's CIPSO. > > > > Actually, the TSIG definition only requires that the two be able > > to work out their differences. They are not required to speak the > > same > > I think that this is a reasonable statement. > > [snip] > > > > David Quigley and I had some offline conversation about this, as he > > > has the same need for labeled NFSv4 work. The current thinking is to > > > have a separate draft describing the need to set up an IANA registry > > > and its content. Each entry consists at least the following fields: > > > LABEL TYPE: A number to indicate label type, e.g. CIPSO, CALIPSO, > > > SELinux security contex strings, etc. > > > SUB FIELD: Used to aid label handling, e.g. SELinux could use it for > > > policy version numbers; CIPSO could use it for tag type; > > > LABEL FORMAT: pointers to reference docs on how labels should be > > > parsed. > > > > > > Both Labeled IPsec and labeled NFSv4 (and any future label protocol > > > extensions) can refer to this document. > > > > Two systems, no matter how similar, will never be able to translate > > formatted labels reliably. It only takes trivial changes to an SELinux > > system for my_dog_has_no_nose_t to mean completely different things > > on the two machines. > > > > I stick by my claim that the right and only rational scheme is for > > each system to explicitly map the labels it understands from another > > system to local values, and vis versa. Any label without a mapping > > must be discarded unused. If you are brave and foolish you can say > > that the mapping is unity. > > I'm pretty sure this is what has been proposed from the beginning. I > don't know where in our conversations at least that I've given you a > different opinion. I agree with Casey and David. I think the only way we stand any chance of success is to develop a on-the-wire format that can be easily internalized by a variety of implementations. For example, I know CIPSO is far from the darling child of labeled networking, but due in large part to it's simple, MLS (level/compartment) format it is possible to interoperate between fairly different security models. I've personally used CIPSO to communicate between Trusted Solaris (that is traditional TSOL not FMAC) and SELinux as well as SELinux and Smack (interesting because Smack does not have inherent MLS specifics like TSOL and SELinux); I have not tried to interoperate between Smack and Trusted Solaris but I see no reason why it would fail. I will be the first to admit that these were simple test cases and there was definitely configuration on both required to reach this point, but it is possible. I hope to be able to do the same with CALIPSO when I finish the Linux implementation (only about 50% at present). It is partly because of this experience that I'm not entirely convinced a label format token is needed along with the DOI token and label blob. I currently believe that the best solution would be one that only specified the DOI and the label, in whatever representation seems "the best" given what we currently know. Specify in great detail what the on-the-wire format should look like and let the individual implementations worry about translating from their native format to the wire format. I suspect this will provide the highest level of interoperability and as a result, adoption. -- paul moore linux @ hp From paul.hoffman@vpnc.org Wed Dec 9 10:02: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 A0F123A6A18 for ; Wed, 9 Dec 2009 10:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.963 X-Spam-Level: X-Spam-Status: No, score=-5.963 tagged_above=-999 required=5 tests=[AWL=0.083, 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 u4ckCqfL-REY for ; Wed, 9 Dec 2009 10:02:33 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C8C363A6958 for ; Wed, 9 Dec 2009 10:02:33 -0800 (PST) Received: from [75.101.18.87] (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 nB9I2KpQ003754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Dec 2009 11:02:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19231.56307.207454.101616@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04ED@il-ex01.ad.checkpoint.com> <19231.56307.207454.101616@fireball.kivinen.iki.fi> Date: Wed, 9 Dec 2009 10:01:09 -0800 To: Tero Kivinen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" Subject: Re: [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: Wed, 09 Dec 2009 18:02:34 -0000 At 7:18 PM +0200 12/9/09, Tero Kivinen wrote: >Paul Hoffman writes: >> A big thank you to everyone for their input. Yaron and I have >> compiled the responses, and are now in discussion with Pasi (wearing >> his AD hat) on how to proceed. We will get back to the WG when we >> have a plan, but it probably won't be for a week or so. > >Would it be possible to summarize the responses to the list even >before that, just so people can verify that their >"review/contribute/co-author" information has been understood >correctly? I purposely didn't list names in our query to Pasi, only numbers; if he wants names, he is already reading the mailing list. The discussion between Yaron and Pasi and I will be about expected participation and interest and objections and WG dynamics and IESG interaction; the result of that discussion will be a proposed charter revision. That proposal comes to the WG for discussion before Pasi will take it to the IESG. --Paul Hoffman, Director --VPN Consortium From Jarrett.Lu@Sun.COM Wed Dec 9 11:14: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 AACB43A6AFC for ; Wed, 9 Dec 2009 11:14:45 -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 F+P8mk23+Sq4 for ; Wed, 9 Dec 2009 11:14:44 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by core3.amsl.com (Postfix) with ESMTP id 349763A6AFE for ; Wed, 9 Dec 2009 11:14:37 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB9JEOAY003084 for ; Wed, 9 Dec 2009 11:14:24 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUE00I00FEURY00@fe-sfbay-10.sun.com> for ipsec@ietf.org; Wed, 09 Dec 2009 11:14:24 -0800 (PST) Received: from [192.168.1.55] ([unknown] [71.202.132.81]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUE003VHG3XSM90@fe-sfbay-10.sun.com>; Wed, 09 Dec 2009 11:14:22 -0800 (PST) Date: Wed, 09 Dec 2009 11:14:31 -0800 From: Jarrett Lu In-reply-to: <4B1FCEA7.90609@schaufler-ca.com> Sender: Jarrett.Lu@Sun.COM To: Casey Schaufler Message-id: <4B1FF717.9000205@sun.com> References: <4B1EE1C5.3020807@sun.com> <4B1F200F.6080105@schaufler-ca.com> <4B1F495E.8060901@sun.com> <4B1FCEA7.90609@schaufler-ca.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Cc: David Patrick Quigley , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, serue@linux.vnet.ibm.com Subject: Re: [IPsec] Proposed work item: Labelled IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jarrett.Lu@Sun.COM List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 19:14:45 -0000 Casey Schaufler wrote: > Jarrett Lu wrote: > >> Casey Schaufler wrote: >> >>> Jarrett Lu wrote: >>> >>> >>>> Without rehashing the statements made in above discussion threads, >>>> it's probably helpful to have a realistic interoperability expectation >>>> for labeled systems. Defining label formats and security mechanisms in >>>> various networking protocols is important. >>>> >>>> >>> This reflects the traditional viewpoint and is a major obstacle to >>> progress in the modern world. The modern reality is that two SELinux >>> systems installed with the same software from the same distribution >>> at the same time with configuration parameters that you might think >>> would be insignificant may well have policies with differences that >>> can not be reconciled in a network protocol. >>> >>> But it's worse than that. Static label formats (e.g. Bell & LaPadula) >>> are often cited as the downfall of the 1990's MLS systems. In the >>> rest of the OS the notion has been discarded. None of the current LSMs >>> use a structured label format, unless you want to argue that the >>> SELinux label format is structured, in which case you're likely to >>> hear that it is structured for flexibility. Networking is the final >>> hold-out for the archaic notion that labels should be inherently >>> meaningful. >>> >>> >>> >>>> Consistent label interpretation and label policy enforcement are also >>>> key to labeled communication. >>>> >>>> >>> This has never ever been true, not even once. You need look no >>> further than the level "Secret", which means something very different >>> in the US Department of Defense and in the Department of Energy. >>> The only case where a serious attempt was made was IPSO, which >>> had a classified mapping of DoD categories in the label. >>> >>> >> Although your statements sound a lot different, I think we are >> actually in agreement for the most part, i.e. having a labeled >> networking protocol alone is insufficient for MAC system >> interoperability. For example, it's pointless if two systems can't >> agree on what "Secret" means. >> > > The subtle distinction begin that they don't need to agree what Secret > means, but they must each know what to do with a Secret presented to > them by the other. > > >>> >>> >>>> Note the latter is mostly handled outside the protocols in this >>>> discussion. So in reality, only systems that implement same Mandatory >>>> Access Control (MAC) security models are likely to be able to >>>> inter-operate. A possible example is OpenSolaris FMAC and SELinux. >>>> >>>> >>> This is also a common misconception. In truth, two SELinux systems are >>> no more likely to interact properly than a Trusted Solaris system and >>> one running UNICOS/MLS. >>> >>> >> The bottom line is that the MAC systems should enforce the same policy >> in order for " interoperability" to make sense. >> > > Nope. I disagree. Two wildly divergent policies can interoperate. I have > seen it done. It is not pleasant to gaze upon, and there is lots of > human overhead to set it up, but it does happen because in the real world > it must. > OK. The point I try to get across is that enforcing coherent label policies is another critical piece in MAC interoperability, and that piece is outside the scope of a labeled networking protocol. > >> How to ensure policy consistency across communicating systems is >> beyond Labeled IPsec, and is probably a burden on the system/network >> administrators. This comes back to my earlier point of having a >> realistic expectation of MAC system interoperability. >> > > Yes, with this I can agree. > >>> >>> Two systems, no matter how similar, will never be able to translate >>> formatted labels reliably. It only takes trivial changes to an SELinux >>> system for my_dog_has_no_nose_t to mean completely different things >>> on the two machines. >>> >>> >> I don't think this is the problem we are trying to solve here. I >> believe we are trying to solve the problem of getting packet labels >> across the network with confidentiality and integrity protection. >> > > But once people start down that path they always start trying to dictate > what the on-wire labels are going to contain. And that is what needs to > get nipped in the bud. > Right. Sometimes the bits matter :-) . I think we are still discussing how many ways a labeled opaque blob can be parsed. For example, if on-wire representation of a label is always CIPSO/CALIPSO, it's simpler as there is already a defined IP option number and no Label Format Selector is needed. This means label transformation overhead for non-MLS systems. > > >> The security administrators need to make sure your dog_has_no_nose_t >> is same as my dog_has_nose_t on two systems. >> > > Can't be done reliably. > Maybe true. But that's clearly out of scope of a labeled networking protocol. At end of the day, people who deploys this technology need to bear the responsibility for obtaining the right level of assurance that the systems are going to behave correctly. - Jarrett From paul.moore@hp.com Wed Dec 9 11:28: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 89CFF3A6A6A for ; Wed, 9 Dec 2009 11:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.313 X-Spam-Level: X-Spam-Status: No, score=-106.313 tagged_above=-999 required=5 tests=[AWL=0.286, 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 Xyj11iQJ8rNL for ; Wed, 9 Dec 2009 11:28:39 -0800 (PST) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by core3.amsl.com (Postfix) with ESMTP id EF04B3A6A44 for ; Wed, 9 Dec 2009 11:28:38 -0800 (PST) Received: from g4t0009.houston.hp.com (g4t0009.houston.hp.com [16.234.32.26]) by g4t0017.houston.hp.com (Postfix) with ESMTP id A7FC8381E3; Wed, 9 Dec 2009 19:28:27 +0000 (UTC) Received: from ldl (linux.corp.hp.com [15.11.146.101]) by g4t0009.houston.hp.com (Postfix) with ESMTP id 63A03C17B; Wed, 9 Dec 2009 19:28:27 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl (Postfix) with ESMTP id 4B9EFCF0019; Wed, 9 Dec 2009 12:28:27 -0700 (MST) Received: from ldl ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNpldyRmoqQn; Wed, 9 Dec 2009 12:28:27 -0700 (MST) Received: from flek.localnet (squirrel.fc.hp.com [15.11.146.57]) by ldl (Postfix) with ESMTP id 999D2CF0016; Wed, 9 Dec 2009 12:28:26 -0700 (MST) From: Paul Moore Organization: Hewlett-Packard To: "David P. Quigley" Date: Wed, 9 Dec 2009 14:28:25 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r2; KDE/4.3.4; i686; ; ) References: <4B1EE1C5.3020807@sun.com> <200912091231.21086.paul.moore@hp.com> <1260385564.2484.456.camel@moss-terrapins.epoch.ncsc.mil> In-Reply-To: <1260385564.2484.456.camel@moss-terrapins.epoch.ncsc.mil> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200912091428.25218.paul.moore@hp.com> Cc: tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , Jarrett Lu , serue@linux.vnet.ibm.com 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: Wed, 09 Dec 2009 19:28:40 -0000 On Wednesday 09 December 2009 02:06:04 pm David P. Quigley wrote: > On Wed, 2009-12-09 at 12:31 -0500, Paul Moore wrote: > > On Wednesday 09 December 2009 10:21:30 am David P. Quigley wrote: > > > On Tue, 2009-12-08 at 19:57 -0800, Casey Schaufler wrote: > > > [snip] > > > > > > > > The term "DOI" has been used in traditional MLS system for about > > > > > two decades. In the MLS world, when systems use same DOI, it means > > > > > they agree to the same label definition and MAC policy, and the > > > > > systems are most likely under same administrative control (Note > > > > > which policy is agreed upon is handled outside of a networking > > > > > protocol). The label format is determined, i.e. it's CIPSO. > > > > > > > > Actually, the TSIG definition only requires that the two be able > > > > to work out their differences. They are not required to speak the > > > > same > > > > > > I think that this is a reasonable statement. > > > > > > [snip] > > > > > > > > David Quigley and I had some offline conversation about this, as he > > > > > has the same need for labeled NFSv4 work. The current thinking is > > > > > to have a separate draft describing the need to set up an IANA > > > > > registry and its content. Each entry consists at least the > > > > > following fields: LABEL TYPE: A number to indicate label type, e.g. > > > > > CIPSO, CALIPSO, SELinux security contex strings, etc. > > > > > SUB FIELD: Used to aid label handling, e.g. SELinux could use it > > > > > for policy version numbers; CIPSO could use it for tag type; > > > > > LABEL FORMAT: pointers to reference docs on how labels should be > > > > > parsed. > > > > > > > > > > Both Labeled IPsec and labeled NFSv4 (and any future label protocol > > > > > extensions) can refer to this document. > > > > > > > > Two systems, no matter how similar, will never be able to translate > > > > formatted labels reliably. It only takes trivial changes to an > > > > SELinux system for my_dog_has_no_nose_t to mean completely different > > > > things on the two machines. > > > > > > > > I stick by my claim that the right and only rational scheme is for > > > > each system to explicitly map the labels it understands from another > > > > system to local values, and vis versa. Any label without a mapping > > > > must be discarded unused. If you are brave and foolish you can say > > > > that the mapping is unity. > > > > > > I'm pretty sure this is what has been proposed from the beginning. I > > > don't know where in our conversations at least that I've given you a > > > different opinion. > > > > I agree with Casey and David. I think the only way we stand any chance > > of success is to develop a on-the-wire format that can be easily > > internalized by a variety of implementations. For example, I know CIPSO > > is far from the darling child of labeled networking, but due in large > > part to it's simple, MLS (level/compartment) format it is possible to > > interoperate between fairly different security models. I've personally > > used CIPSO to communicate between Trusted Solaris (that is traditional > > TSOL not FMAC) and SELinux as well as SELinux and Smack (interesting > > because Smack does not have inherent MLS specifics like TSOL and > > SELinux); I have not tried to interoperate between Smack and Trusted > > Solaris but I see no reason why it would fail. I will be the first to > > admit that these were simple test cases and there was definitely > > configuration on both required to reach this point, but it is possible. > > > > I hope to be able to do the same with CALIPSO when I finish the Linux > > implementation (only about 50% at present). > > > > It is partly because of this experience that I'm not entirely convinced a > > label format token is needed along with the DOI token and label blob. I > > currently believe that the best solution would be one that only specified > > the DOI and the label, in whatever representation seems "the best" given > > what we currently know. Specify in great detail what the on-the-wire > > format should look like and let the individual implementations worry > > about translating from their native format to the wire format. I suspect > > this will provide the highest level of interoperability and as a result, > > adoption. > > I don't think its realistic to develop a single on the wire format for > labels. Well, I've seen it work so I know it is possible, I guess it all comes down to what we decide "realistic" really means. > I'm pretty sure this has been tried in the past and has failed. I've actually seen very little discussion about why single format labeling protocols have failed (or rather was it the systems that failed, causing the protocols to fail as a result) and unfortunately I wasn't involved in that space at the time so I have no personal history. I think a good first step to arriving at a new protocol is to understand what went wrong in the past and why it went wrong. It is important to note I'm talking about adoption, implementation and interoperability; I'm not talking about what went wrong between the IETF and TSIG (although based on what I've learned I suspect there is some overlap here). > I also think its not very reasonable to have the DOI incorporate both > the format of the label and the policy authority/identifier. I think this is secondary to the single vs multiple wire format question. If you only have a single wire format then a label format token is a bit silly, however, if you want to support multiple label formats then you might as well include some sort of format specifier. -- paul moore linux @ hp From Jarrett.Lu@Sun.COM Wed Dec 9 11:31: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 237B128C1AB for ; Wed, 9 Dec 2009 11:31:22 -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 ZVmab6CB5Mo5 for ; Wed, 9 Dec 2009 11:31:21 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by core3.amsl.com (Postfix) with ESMTP id 2B45D28C1B6 for ; Wed, 9 Dec 2009 11:31:21 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB9JVA74017491 for ; Wed, 9 Dec 2009 11:31:10 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUE00700GNGYU00@fe-sfbay-10.sun.com> for ipsec@ietf.org; Wed, 09 Dec 2009 11:31:10 -0800 (PST) Received: from [192.168.1.55] ([unknown] [71.202.132.81]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUE003CJGVUSMF0@fe-sfbay-10.sun.com>; Wed, 09 Dec 2009 11:31:06 -0800 (PST) Date: Wed, 09 Dec 2009 11:31:16 -0800 From: Jarrett Lu In-reply-to: <200912091231.21086.paul.moore@hp.com> Sender: Jarrett.Lu@Sun.COM To: Paul Moore Message-id: <4B1FFB04.4000803@sun.com> References: <4B1EE1C5.3020807@sun.com> <4B1F200F.6080105@schaufler-ca.com> <1260372090.2484.236.camel@moss-terrapins.epoch.ncsc.mil> <200912091231.21086.paul.moore@hp.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Cc: "David P. Quigley" , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com Subject: Re: [IPsec] Proposed work item: Labelled IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jarrett.Lu@Sun.COM List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 19:31:22 -0000 Paul Moore wrote: > > I agree with Casey and David. I think the only way we stand any chance of > success is to develop a on-the-wire format that can be easily internalized by > a variety of implementations. For example, I know CIPSO is far from the > darling child of labeled networking, but due in large part to it's simple, MLS > (level/compartment) format it is possible to interoperate between fairly > different security models. I've personally used CIPSO to communicate between > Trusted Solaris (that is traditional TSOL not FMAC) and SELinux as well as > SELinux and Smack (interesting because Smack does not have inherent MLS > specifics like TSOL and SELinux); I have not tried to interoperate between > Smack and Trusted Solaris but I see no reason why it would fail. I will be > the first to admit that these were simple test cases and there was definitely > configuration on both required to reach this point, but it is possible. > > I hope to be able to do the same with CALIPSO when I finish the Linux > implementation (only about 50% at present). > > It is partly because of this experience that I'm not entirely convinced a > label format token is needed along with the DOI token and label blob. I > currently believe that the best solution would be one that only specified the > DOI and the label, in whatever representation seems "the best" given what we > currently know. Specify in great detail what the on-the-wire format should > look like and let the individual implementations worry about translating from > their native format to the wire format. I suspect this will provide the > highest level of interoperability and as a result, adoption. > This sounds as too ambitious to me. Even if this can be done for all known label formats in use today, how would we know it will map well for some new labels in future? - Jarrett From paul.hoffman@vpnc.org Wed Dec 9 11:42: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 65D093A68E6 for ; Wed, 9 Dec 2009 11:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.965 X-Spam-Level: X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=0.081, 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 e5EzPxH+04ve for ; Wed, 9 Dec 2009 11:42:08 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 891EB3A688D for ; Wed, 9 Dec 2009 11:42:08 -0800 (PST) Received: from [75.101.18.87] (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 nB9JfteE012668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Dec 2009 12:41:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4B1FFB04.4000803@sun.com> References: <4B1EE1C5.3020807@sun.com> <4B1F200F.6080105@schaufler-ca.com> <1260372090.2484.236.camel@moss-terrapins.epoch.ncsc.mil> <200912091231.21086.paul.moore@hp.com> <4B1FFB04.4000803@sun.com> Date: Wed, 9 Dec 2009 11:41:54 -0800 To: ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" 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: Wed, 09 Dec 2009 19:42:09 -0000 It is very clear that there is no common understanding among the participants on this thread. I propose that we cut this off for now until we can figure out what to do with the proposed work item. --Paul Hoffman, Director --VPN Consortium From alper.yegin@yegin.org Wed Dec 9 11:46: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 1971928C1AB for ; Wed, 9 Dec 2009 11:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 qNrwroWaPUkG for ; Wed, 9 Dec 2009 11:46:38 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 4540E3A6B01 for ; Wed, 9 Dec 2009 11:46:38 -0800 (PST) Received: from LENOVO (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0M5uoD-1O29KJ1D2n-00xTY0; Wed, 09 Dec 2009 14:46:19 -0500 From: "Alper Yegin" To: "'Hui Deng'" , "'Yaron Sheffer'" References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <1d38a3350912090742q1976ffefo85ef5e0e5627ec0b@mail.gmail.com> In-Reply-To: <1d38a3350912090742q1976ffefo85ef5e0e5627ec0b@mail.gmail.com> Date: Wed, 9 Dec 2009 21:46:14 +0200 Message-ID: <023f01ca7908$480951b0$d81bf510$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp45i8C/t8EyUn9RhOZYYnFTb++MAAIM+8w Content-Language: en-us X-Provags-ID: V01U2FsdGVkX199qvSbxGWlTa22xJ1ctnHeX0Wo3QMwut4h9Rw buRTVVTSsLef14dBroXkt5YVU7UqFxyZk+3lUF/JHMpdXsbj4u mOUvIulR5UyLYy4Eq/QjA== Cc: ipsec@ietf.org Subject: Re: [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: Wed, 09 Dec 2009 19:46:39 -0000 Hi Hui, You named 3GPP as a consumer of this, acknowledged that 3GPP is not behind all of the requirements, but you didn't respond to my question about which one of the requirements are coming from 3GPP. I object to this work, because it intends to create yet another network access authentication protocol out of IKEv2. As you know, PANA is designed for that purpose. IETF community needs to understand why PANA does not fit the need, and why we need to turn IKEv2 into a general-purpose network access authentication protocol. (IKE needs to get in line with the other similar proposals, such as hacking up DHCP into access authentication protocol, and even HTTP. I guess everyone has his/her favorite protocol to hack.) Similar questions arise for the other motivations. "Liveness checking", and "NAT detection".... Turning IKEv2 into a dedicated protocol for these purposes is likely to grow IKE in many unintended directions. Alper > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Hui Deng > Sent: Wednesday, December 09, 2009 5:42 PM > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: Childless IKE SA > > would like to co-author, thanks > > -Hui > > 2009/11/30 Yaron Sheffer : > > 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- > childless-01.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 > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From paul.moore@hp.com Wed Dec 9 11:49: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 0CD7928C1CA for ; Wed, 9 Dec 2009 11:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.349 X-Spam-Level: X-Spam-Status: No, score=-104.349 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, 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 iS6pp2BLiy7I for ; Wed, 9 Dec 2009 11:49:04 -0800 (PST) Received: from g6t0184.atlanta.hp.com (g6t0184.atlanta.hp.com [15.193.32.61]) by core3.amsl.com (Postfix) with ESMTP id E3D863A6B05 for ; Wed, 9 Dec 2009 11:49:03 -0800 (PST) Received: from g5t0029.atlanta.hp.com (g5t0029.atlanta.hp.com [16.228.8.141]) by g6t0184.atlanta.hp.com (Postfix) with ESMTP id 1A178C577; Wed, 9 Dec 2009 19:48:52 +0000 (UTC) Received: from ldl (linux.corp.hp.com [15.11.146.101]) by g5t0029.atlanta.hp.com (Postfix) with ESMTP id 6E0812014D; Wed, 9 Dec 2009 19:48:51 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl (Postfix) with ESMTP id 3B179CF0019; Wed, 9 Dec 2009 12:48:51 -0700 (MST) Received: from ldl ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sbsiW0zS7h0; Wed, 9 Dec 2009 12:48:51 -0700 (MST) Received: from flek.localnet (squirrel.fc.hp.com [15.11.146.57]) by ldl (Postfix) with ESMTP id B46ACCF0016; Wed, 9 Dec 2009 12:48:50 -0700 (MST) From: Paul Moore Organization: Hewlett-Packard To: Jarrett.Lu@sun.com Date: Wed, 9 Dec 2009 14:48:49 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r2; KDE/4.3.4; i686; ; ) References: <4B1EE1C5.3020807@sun.com> <200912091231.21086.paul.moore@hp.com> <4B1FFB04.4000803@sun.com> In-Reply-To: <4B1FFB04.4000803@sun.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912091448.49587.paul.moore@hp.com> Cc: "David P. Quigley" , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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: Wed, 09 Dec 2009 19:49:05 -0000 On Wednesday 09 December 2009 02:31:16 pm Jarrett Lu wrote: > Paul Moore wrote: > > I agree with Casey and David. I think the only way we stand any chance > > of success is to develop a on-the-wire format that can be easily > > internalized by a variety of implementations. For example, I know CIPSO > > is far from the darling child of labeled networking, but due in large > > part to it's simple, MLS (level/compartment) format it is possible to > > interoperate between fairly different security models. I've personally > > used CIPSO to communicate between Trusted Solaris (that is traditional > > TSOL not FMAC) and SELinux as well as SELinux and Smack (interesting > > because Smack does not have inherent MLS specifics like TSOL and > > SELinux); I have not tried to interoperate between Smack and Trusted > > Solaris but I see no reason why it would fail. I will be the first to > > admit that these were simple test cases and there was definitely > > configuration on both required to reach this point, but it is possible. > > > > I hope to be able to do the same with CALIPSO when I finish the Linux > > implementation (only about 50% at present). > > > > It is partly because of this experience that I'm not entirely convinced a > > label format token is needed along with the DOI token and label blob. I > > currently believe that the best solution would be one that only specified > > the DOI and the label, in whatever representation seems "the best" given > > what we currently know. Specify in great detail what the on-the-wire > > format should look like and let the individual implementations worry > > about translating from their native format to the wire format. I suspect > > this will provide the highest level of interoperability and as a result, > > adoption. > > This sounds as too ambitious to me. Even if this can be done for all known > label formats in use today, how would we know it will map well for some new > labels in future? We don't, well not unless your crystal ball works a lot better than mine :) I'm concerned that if we devote too much effort into making the protocol completely future-proof we will end up sacrificing capability with the implementations we have today (or can envision). Beyond the interoperability concerns over multiple label formats, one of my main concerns is that a protocol with multiple formats is almost surely going to be rejected/ignored by the intermediate hop vendors as it is too difficult to put in an ASIC. One of the lessons I learned during the CALIPSO review process was that one of the reasons CIPSO failed was due to the different label formats, aka CIPSO "tag types", which made it difficult for intermediate node vendors to parse and apply security policy quickly. Nothing last forever, especially when technology is concerned, there is always another revision (and another ... and another). I understand that we need to design the protocol to be flexible but in this case I think we need to approach flexibility with some restraint. -- paul moore linux @ hp From dpquigl@tycho.nsa.gov Wed Dec 9 11:56: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 2F7093A6B0C for ; Wed, 9 Dec 2009 11:56:18 -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 XSQ6NfvB1WEC for ; Wed, 9 Dec 2009 11:56:17 -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 228803A6B09 for ; Wed, 9 Dec 2009 11:56:17 -0800 (PST) Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id nB9Jw2h4008669; Wed, 9 Dec 2009 19:58:02 GMT Received: from [144.51.25.2] (moss-terrapins [144.51.25.2]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id nB9JtiVi013786; Wed, 9 Dec 2009 14:55:44 -0500 From: "David P. Quigley" To: Paul Moore In-Reply-To: <200912091448.49587.paul.moore@hp.com> References: <4B1EE1C5.3020807@sun.com> <200912091231.21086.paul.moore@hp.com> <4B1FFB04.4000803@sun.com> <200912091448.49587.paul.moore@hp.com> Content-Type: text/plain Organization: National Security Agency Date: Wed, 09 Dec 2009 14:47:00 -0500 Message-Id: <1260388020.2484.514.camel@moss-terrapins.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit Cc: tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , Jarrett.Lu@sun.com, serue@linux.vnet.ibm.com 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: Wed, 09 Dec 2009 19:56:18 -0000 On Wed, 2009-12-09 at 14:48 -0500, Paul Moore wrote: > On Wednesday 09 December 2009 02:31:16 pm Jarrett Lu wrote: > > Paul Moore wrote: > > > I agree with Casey and David. I think the only way we stand any chance > > > of success is to develop a on-the-wire format that can be easily > > > internalized by a variety of implementations. For example, I know CIPSO > > > is far from the darling child of labeled networking, but due in large > > > part to it's simple, MLS (level/compartment) format it is possible to > > > interoperate between fairly different security models. I've personally > > > used CIPSO to communicate between Trusted Solaris (that is traditional > > > TSOL not FMAC) and SELinux as well as SELinux and Smack (interesting > > > because Smack does not have inherent MLS specifics like TSOL and > > > SELinux); I have not tried to interoperate between Smack and Trusted > > > Solaris but I see no reason why it would fail. I will be the first to > > > admit that these were simple test cases and there was definitely > > > configuration on both required to reach this point, but it is possible. > > > > > > I hope to be able to do the same with CALIPSO when I finish the Linux > > > implementation (only about 50% at present). > > > > > > It is partly because of this experience that I'm not entirely convinced a > > > label format token is needed along with the DOI token and label blob. I > > > currently believe that the best solution would be one that only specified > > > the DOI and the label, in whatever representation seems "the best" given > > > what we currently know. Specify in great detail what the on-the-wire > > > format should look like and let the individual implementations worry > > > about translating from their native format to the wire format. I suspect > > > this will provide the highest level of interoperability and as a result, > > > adoption. > > > > This sounds as too ambitious to me. Even if this can be done for all known > > label formats in use today, how would we know it will map well for some new > > labels in future? > > We don't, well not unless your crystal ball works a lot better than mine :) > > I'm concerned that if we devote too much effort into making the protocol > completely future-proof we will end up sacrificing capability with the > implementations we have today (or can envision). Beyond the interoperability > concerns over multiple label formats, one of my main concerns is that a > protocol with multiple formats is almost surely going to be rejected/ignored > by the intermediate hop vendors as it is too difficult to put in an ASIC. One > of the lessons I learned during the CALIPSO review process was that one of the > reasons CIPSO failed was due to the different label formats, aka CIPSO "tag > types", which made it difficult for intermediate node vendors to parse and > apply security policy quickly. > > Nothing last forever, especially when technology is concerned, there is always > another revision (and another ... and another). I understand that we need to > design the protocol to be flexible but in this case I think we need to > approach flexibility with some restraint. > I spoke with Ran at the IETF in San Francisco and he told me that router vendors will definitely not approve of having to do string comparisons to apply security policy. This means the only label formats that you're going to be able to get the intermediate hop vendors to approve of are strictly things like CALIPSO. They want to be able to do a quick integer and bitmask comparison. Having to parse a string and pass it to a policy decisions engine doesn't seem to be acceptable. Dave From root@core3.amsl.com Wed Dec 9 12:00: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 EE4733A6884; Wed, 9 Dec 2009 12: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: <20091209200001.EE4733A6884@core3.amsl.com> Date: Wed, 9 Dec 2009 12:00:01 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2bis-06.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, 09 Dec 2009 20:00: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 : Internet Key Exchange Protocol: IKEv2 Author(s) : C. Kaufman, et al. Filename : draft-ietf-ipsecme-ikev2bis-06.txt Pages : 153 Date : 2009-12-09 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). It replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 12, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-06.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-ikev2bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-09114838.I-D@ietf.org> --NextPart-- From Jarrett.Lu@Sun.COM Wed Dec 9 12:29: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 DBDC228C19E for ; Wed, 9 Dec 2009 12:29: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 owyj0BdZ4J2u for ; Wed, 9 Dec 2009 12:29:05 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by core3.amsl.com (Postfix) with ESMTP id 1DD3A3A68C4 for ; Wed, 9 Dec 2009 12:29:04 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB9KSrLc010773 for ; Wed, 9 Dec 2009 12:28:53 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUE00J00JDZOU00@fe-sfbay-09.sun.com> for ipsec@ietf.org; Wed, 09 Dec 2009 12:28:53 -0800 (PST) Received: from [192.168.1.55] ([unknown] [71.202.132.81]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUE006T2JK41R40@fe-sfbay-09.sun.com>; Wed, 09 Dec 2009 12:28:53 -0800 (PST) Date: Wed, 09 Dec 2009 12:29:03 -0800 From: Jarrett Lu In-reply-to: <200912091448.49587.paul.moore@hp.com> Sender: Jarrett.Lu@Sun.COM To: Paul Moore Message-id: <4B20088F.40607@sun.com> References: <4B1EE1C5.3020807@sun.com> <200912091231.21086.paul.moore@hp.com> <4B1FFB04.4000803@sun.com> <200912091448.49587.paul.moore@hp.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Cc: "David P. Quigley" , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com Subject: Re: [IPsec] Proposed work item: Labelled IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jarrett.Lu@Sun.COM List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 20:29:06 -0000 Paul Moore wrote: > On Wednesday 09 December 2009 02:31:16 pm Jarrett Lu wrote: > >> Paul Moore wrote: >> >>> I agree with Casey and David. I think the only way we stand any chance >>> of success is to develop a on-the-wire format that can be easily >>> internalized by a variety of implementations. For example, I know CIPSO >>> is far from the darling child of labeled networking, but due in large >>> part to it's simple, MLS (level/compartment) format it is possible to >>> interoperate between fairly different security models. I've personally >>> used CIPSO to communicate between Trusted Solaris (that is traditional >>> TSOL not FMAC) and SELinux as well as SELinux and Smack (interesting >>> because Smack does not have inherent MLS specifics like TSOL and >>> SELinux); I have not tried to interoperate between Smack and Trusted >>> Solaris but I see no reason why it would fail. I will be the first to >>> admit that these were simple test cases and there was definitely >>> configuration on both required to reach this point, but it is possible. >>> >>> I hope to be able to do the same with CALIPSO when I finish the Linux >>> implementation (only about 50% at present). >>> >>> It is partly because of this experience that I'm not entirely convinced a >>> label format token is needed along with the DOI token and label blob. I >>> currently believe that the best solution would be one that only specified >>> the DOI and the label, in whatever representation seems "the best" given >>> what we currently know. Specify in great detail what the on-the-wire >>> format should look like and let the individual implementations worry >>> about translating from their native format to the wire format. I suspect >>> this will provide the highest level of interoperability and as a result, >>> adoption. >>> >> This sounds as too ambitious to me. Even if this can be done for all known >> label formats in use today, how would we know it will map well for some new >> labels in future? >> > > We don't, well not unless your crystal ball works a lot better than mine :) > > I'm concerned that if we devote too much effort into making the protocol > completely future-proof we will end up sacrificing capability with the > implementations we have today (or can envision). Actually I was advocating the opposite of "devoting too much future-proof effort". How about not going that route at all? The Label Format Selector idea is quite extensible. For any new label in future, you need to publish a Label Format Spec, get an INAN registry, add new parsing capability in the system, and you are done. There is little to change in the protocol itself. > Beyond the interoperability > concerns over multiple label formats, one of my main concerns is that a > protocol with multiple formats is almost surely going to be rejected/ignored > by the intermediate hop vendors as it is too difficult to put in an ASIC. One > of the lessons I learned during the CALIPSO review process was that one of the > reasons CIPSO failed was due to the different label formats, aka CIPSO "tag > types", which made it difficult for intermediate node vendors to parse and > apply security policy quickly. > I could be wrong here. I thought the opaque blob is passed as pay load in IKE exchange, not as IP option in the header. - Jarrett From kent@bbn.com Wed Dec 9 13:20: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 546F03A6B0B for ; Wed, 9 Dec 2009 13:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, 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 inc0vLtAMMwN for ; Wed, 9 Dec 2009 13:20:13 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 769A33A6967 for ; Wed, 9 Dec 2009 13:19:58 -0800 (PST) Received: from dhcp89-089-170.bbn.com ([128.89.89.170]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NITwn-0004OM-AR; Wed, 09 Dec 2009 16:19:45 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <5E38DBF64E732C4C98512C53E1B14DDC299B1529@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> <5E38DBF64E732C4C98512C53E1B14DDC2999E319@TK5EX14MBXW653.wingroup.windeplo y.ntdev.microsoft.com> <5E38DBF64E732C4C98512C53E1B14DDC299ACE4A@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> <19230.14267.109849.507396@fireball.kivinen.iki.fi> <5E38DBF64E732C4C98512C53E1B14DDC299B1529@TK5EX14MBXW651.wingroup.windeplo y.ntdev.microsoft.com> Date: Wed, 9 Dec 2009 16:19:43 -0500 To: Brian Swander 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: Wed, 09 Dec 2009 21:20:17 -0000 At 5:20 PM +0000 12/9/09, Brian Swander wrote: >AH alone isn't good enough. We need solutions that also work with >end-to-end encryption. > >bs > I think you are saying that it is a goal of those who are proposing the WESP extension work item to move beyond the original, stated goals of WESP, and provide middleboxes the ability to examine purported contents of encrypted packets. I will observe that this notion suggests copying portions of plaintext that is being encrypted into a WESP extension header, which is close to the partial encryption proposals that the IPSEC Wg rejected on multiple occasions, for secruity reasons. I also note that my last two e-mail exchanges with Jack Kohn did not elicit a clarification of the one vs. many SAs issue that was raised in the context of OSPFv3 use of IPsec, as part of the justification for using WESP there. Absent a definitive statement that this context requires a lot of SAs, the arguments put forth about the need for ESP in that context are moot. Steve From denghui02@gmail.com Wed Dec 9 21:29: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 358883A6851 for ; Wed, 9 Dec 2009 21:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 K5El7adwT7aG for ; Wed, 9 Dec 2009 21:29:34 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 3FF373A6806 for ; Wed, 9 Dec 2009 21:29:34 -0800 (PST) Received: by pzk6 with SMTP id 6so6076414pzk.29 for ; Wed, 09 Dec 2009 21:29:21 -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=RRxHQzrMEV4EZkcfvR3hGKM1zAf5+UK5eZmLC+C5M6c=; b=jzBaIlSvprDFKqoEsVy26Li40jSEJ7x5QQZ4qKvSNIot0lrO6ot7YuG/hthYnz4fRg gc0zT1kkSioKzT7fR8C6OKdadPplnz3CEcZ0En62nqhwJi5A0SpN/8l+/farThq+COpn rzhoet68YnxxdDvPepoaIuCxZW1IC6bRgWg20= 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=T4g0xX0tCaXLvBgcnrRkRHd8qLkZturvN775FBNzsSbLzINgU42cLwmTDigafKFLqD /mOi16pWyv5eXK8rKkgb84BaD7VO2yzw7ow95Lq2jIW7W769kkvxO8bWGaVDXl8B7tmX f1rykp64FVUPzZmDvgC/4ix1+S5Z/Xsykd9L0= MIME-Version: 1.0 Received: by 10.141.188.19 with SMTP id q19mr956108rvp.164.1260422960592; Wed, 09 Dec 2009 21:29:20 -0800 (PST) In-Reply-To: <8104339512286448538@unknownmsgid> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <1d38a3350912090742q1976ffefo85ef5e0e5627ec0b@mail.gmail.com> <8104339512286448538@unknownmsgid> Date: Thu, 10 Dec 2009 13:29:20 +0800 Message-ID: <1d38a3350912092129v4b4d6f77pc5114e72284ea8da@mail.gmail.com> From: Hui Deng To: Alper Yegin Content-Type: text/plain; charset=ISO-8859-1 Cc: ipsec@ietf.org Subject: Re: [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: Thu, 10 Dec 2009 05:29:35 -0000 Hi, Alper I think previous Yoav's reply already answered you, so confused why you ask again, if you want me repeat, I could copy Yoav's reply to you here. - authentication only over a physically secure network (not necessarily EAP, but I think this is the use case you referred to) I am not convinced why vendor need implement two security mechanism to one product, just because the second one need some market to use it. -Hui 2009/12/10 Alper Yegin : > Hi Hui, > > You named 3GPP as a consumer of this, acknowledged that 3GPP is not behind > all of the requirements, but you didn't respond to my question about which > one of the requirements are coming from 3GPP. > > > I object to this work, because it intends to create yet another network > access authentication protocol out of IKEv2. As you know, PANA is designed > for that purpose. IETF community needs to understand why PANA does not fit > the need, and why we need to turn IKEv2 into a general-purpose network > access authentication protocol. (IKE needs to get in line with the other > similar proposals, such as hacking up DHCP into access authentication > protocol, and even HTTP. I guess everyone has his/her favorite protocol to > hack.) > > Similar questions arise for the other motivations. "Liveness checking", and > "NAT detection".... Turning IKEv2 into a dedicated protocol for these > purposes is likely to grow IKE in many unintended directions. > > Alper > > > > > > > > > > > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Hui Deng >> Sent: Wednesday, December 09, 2009 5:42 PM >> To: Yaron Sheffer >> Cc: ipsec@ietf.org >> Subject: Re: [IPsec] Proposed work item: Childless IKE SA >> >> would like to co-author, thanks >> >> -Hui >> >> 2009/11/30 Yaron Sheffer : >> > 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- >> childless-01.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 >> > >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From ynir@checkpoint.com Wed Dec 9 22:07: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 A9D873A6859 for ; Wed, 9 Dec 2009 22:07:18 -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 QfPvTGhltxSa for ; Wed, 9 Dec 2009 22:07:17 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 6FE2A3A695C for ; Wed, 9 Dec 2009 22:07:17 -0800 (PST) X-CheckPoint: {4B208F79-10008-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 65B3F29C004; Thu, 10 Dec 2009 08:07:05 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 42F8429C002; Thu, 10 Dec 2009 08:07:05 +0200 (IST) X-CheckPoint: {4B208F79-10000-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBA675T7015262; Thu, 10 Dec 2009 08:07: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; Thu, 10 Dec 2009 08:07:15 +0200 From: Yoav Nir To: Alper Yegin Date: Thu, 10 Dec 2009 08:07:02 +0200 Thread-Topic: [IPsec] Proposed work item: Childless IKE SA Thread-Index: Acp5XwWgekL+O1BvT9ulLA92xsED1Q== Message-ID: <3824040C-7D40-4B46-B430-AE87D6729A19@checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <1d38a3350912090742q1976ffefo85ef5e0e5627ec0b@mail.gmail.com> <023f01ca7908$480951b0$d81bf510$@yegin@yegin.org> In-Reply-To: <023f01ca7908$480951b0$d81bf510$@yegin@yegin.org> 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: Hui Deng , "ipsec@ietf.org" Subject: Re: [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: Thu, 10 Dec 2009 06:07:18 -0000 Hi Alper. The "Do phase 1 first, and phase 2 as traffic demands it" motivation is fro= m the remote access VPN domain (though may be useful for others). The "Do only phase 1, because we don't need encryption and MAC, just peer a= uthentication" motivation is from the 3GPP (though it could be useful for o= thers) The "Do only phase 1 to discover if we're in or out of the secure network (= then do phase 2 if we're out)" motivation is also mostly a remote access VP= N thing. The other motivations were from suggestions by others, and will be hashed o= ut (or taken out of the document) should this become a WG document. Hope this helps Yoav On Dec 9, 2009, at 9:46 PM, Alper Yegin wrote: > Hi Hui, >=20 > You named 3GPP as a consumer of this, acknowledged that 3GPP is not behin= d > all of the requirements, but you didn't respond to my question about whic= h > one of the requirements are coming from 3GPP. >=20 >=20 > I object to this work, because it intends to create yet another network > access authentication protocol out of IKEv2. As you know, PANA is designe= d > for that purpose. IETF community needs to understand why PANA does not fi= t > the need, and why we need to turn IKEv2 into a general-purpose network > access authentication protocol. (IKE needs to get in line with the other > similar proposals, such as hacking up DHCP into access authentication > protocol, and even HTTP. I guess everyone has his/her favorite protocol t= o > hack.) >=20 > Similar questions arise for the other motivations. "Liveness checking", a= nd > "NAT detection".... Turning IKEv2 into a dedicated protocol for these > purposes is likely to grow IKE in many unintended directions. >=20 > Alper From alper.yegin@yegin.org Thu Dec 10 00:04: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 D39AD3A68FA for ; Thu, 10 Dec 2009 00:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.993 X-Spam-Level: X-Spam-Status: No, score=-0.993 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 f88XX-MeFH9Y for ; Thu, 10 Dec 2009 00:04:41 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 284163A6A79 for ; Thu, 10 Dec 2009 00:04:18 -0800 (PST) Received: from LENOVO (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Lu77W-1O2Bs7293O-011dzn; Thu, 10 Dec 2009 03:04:06 -0500 From: "Alper Yegin" To: "'Hui Deng'" References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <1d38a3350912090742q1976ffefo85ef5e0e5627ec0b@mail.gmail.com> <8104339512286448538@unknownmsgid> <1d38a3350912092129v4b4d6f77pc5114e72284ea8da@mail.gmail.com> In-Reply-To: <1d38a3350912092129v4b4d6f77pc5114e72284ea8da@mail.gmail.com> Date: Thu, 10 Dec 2009 10:04:03 +0200 Message-ID: <02c301ca796f$5a899fe0$0f9cdfa0$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp5WbnQ+AkECD6SRsqQMSH1sqIwfAAE9H6w Content-Language: en-us X-Provags-ID: V01U2FsdGVkX18tN7Z2q1Radr95fZ6vVwy6lI8opwRBfMI1iTv 0XXkkp6W5GzD0//800XjEnwIQrvnUECUF1qt9ASLOYkCmRxmT+ Of4txmc991Jupo+9MopHg== Cc: ipsec@ietf.org Subject: Re: [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: Thu, 10 Dec 2009 08:04:42 -0000 Hi Hui, > I am not convinced why vendor need implement two security mechanism to > one product, > just because the second one need some market to use it. Unfortunately, protocol classification is more granular than that. You don't identify one protocol as "security protocol" and make it serve all security related purposes: access authentication, IPsec SA establishment, transport-layer security, application-layer security, mobility signaling security, etc. etc. Obviously, you need several distinct protocols for these things. So, saying we have IKEv2, and we'll twist and turn it into some other protocol for some other purpose may make sense when you are looking at things from within the box (that implements IKEv2), but it does not make sense when you are looking from outside the box (like from IETF perspective). Your proposal is for turning IKEv2 into an EAP transport for generic network access authentication. It requires taking some stuff out, twisting some stuff, and adding stuff. It's technically doable, but "IETF" needs to be convinced why it needs to reinvent PANA by taking IKEv2 as the baseline. Alper > > -Hui > > 2009/12/10 Alper Yegin : > > Hi Hui, > > > > You named 3GPP as a consumer of this, acknowledged that 3GPP is not > behind > > all of the requirements, but you didn't respond to my question about > which > > one of the requirements are coming from 3GPP. > > > > > > I object to this work, because it intends to create yet another > network > > access authentication protocol out of IKEv2. As you know, PANA is > designed > > for that purpose. IETF community needs to understand why PANA does > not fit > > the need, and why we need to turn IKEv2 into a general-purpose > network > > access authentication protocol. (IKE needs to get in line with the > other > > similar proposals, such as hacking up DHCP into access authentication > > protocol, and even HTTP. I guess everyone has his/her favorite > protocol to > > hack.) > > > > Similar questions arise for the other motivations. "Liveness > checking", and > > "NAT detection".... Turning IKEv2 into a dedicated protocol for these > > purposes is likely to grow IKE in many unintended directions. > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf > >> Of Hui Deng > >> Sent: Wednesday, December 09, 2009 5:42 PM > >> To: Yaron Sheffer > >> Cc: ipsec@ietf.org > >> Subject: Re: [IPsec] Proposed work item: Childless IKE SA > >> > >> would like to co-author, thanks > >> > >> -Hui > >> > >> 2009/11/30 Yaron Sheffer : > >> > 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- > >> childless-01.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 > >> > > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > From alper.yegin@yegin.org Thu Dec 10 00:13: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 23E973A6A82 for ; Thu, 10 Dec 2009 00:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.003 X-Spam-Level: X-Spam-Status: No, score=-1.003 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 AMpkU2Rl+NzE for ; Thu, 10 Dec 2009 00:13:17 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id BE5AB3A6A7E for ; Thu, 10 Dec 2009 00:13:16 -0800 (PST) Received: from LENOVO (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MPW1p-1NNKyb10PB-004Ywt; Thu, 10 Dec 2009 03:12:57 -0500 From: "Alper Yegin" To: "'Yoav Nir'" References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <1d38a3350912090742q1976ffefo85ef5e0e5627ec0b@mail.gmail.com> <023f01ca7908$480951b0$d81bf510$@yegin@yegin.org> <3824040C-7D40-4B46-B430-AE87D6729A19@checkpoint.com> In-Reply-To: <3824040C-7D40-4B46-B430-AE87D6729A19@checkpoint.com> Date: Thu, 10 Dec 2009 10:12:54 +0200 Message-ID: <02c401ca7970$974303d0$c5c90b70$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp5XwWgekL+O1BvT9ulLA92xsED1QAEH2cA Content-Language: en-us X-Provags-ID: V01U2FsdGVkX19FCzZFowIyXz5L/nF1Ec5HBzNQt2bK+BChmh3 jqPgStzZe1H1CDuMVHo0xirKThRwWSFBrfISsNePRLnWY9XqY6 zy+9WyaG/xJqsVuoXB3Ew== Cc: 'Hui Deng' , ipsec@ietf.org Subject: Re: [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: Thu, 10 Dec 2009 08:13:19 -0000 Hello Yoav, I'm particularly concerned about reinventing the wheel aspect with your second bullet, as I elaborated in response to Hui in my previous email. As for the other motivations, I'm not sure the savings are worth the effort. Imho.... Alper > The "Do phase 1 first, and phase 2 as traffic demands it" motivation is > from the remote access VPN domain (though may be useful for others). > > The "Do only phase 1, because we don't need encryption and MAC, just > peer authentication" motivation is from the 3GPP (though it could be > useful for others) > > The "Do only phase 1 to discover if we're in or out of the secure > network (then do phase 2 if we're out)" motivation is also mostly a > remote access VPN thing. > > The other motivations were from suggestions by others, and will be > hashed out (or taken out of the document) should this become a WG > document. > > Hope this helps > > Yoav > > On Dec 9, 2009, at 9:46 PM, Alper Yegin wrote: > > > Hi Hui, > > > > You named 3GPP as a consumer of this, acknowledged that 3GPP is not > behind > > all of the requirements, but you didn't respond to my question about > which > > one of the requirements are coming from 3GPP. > > > > > > I object to this work, because it intends to create yet another > network > > access authentication protocol out of IKEv2. As you know, PANA is > designed > > for that purpose. IETF community needs to understand why PANA does > not fit > > the need, and why we need to turn IKEv2 into a general-purpose > network > > access authentication protocol. (IKE needs to get in line with the > other > > similar proposals, such as hacking up DHCP into access authentication > > protocol, and even HTTP. I guess everyone has his/her favorite > protocol to > > hack.) > > > > Similar questions arise for the other motivations. "Liveness > checking", and > > "NAT detection".... Turning IKEv2 into a dedicated protocol for these > > purposes is likely to grow IKE in many unintended directions. > > > > Alper From yaronf@checkpoint.com Thu Dec 10 01:05: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 0458B3A677C for ; Thu, 10 Dec 2009 01:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037, 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 bTbdnjZ55JuE for ; Thu, 10 Dec 2009 01:04:54 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 69EEC3A6A7D for ; Thu, 10 Dec 2009 01:04:53 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBA94fT7012839 for ; Thu, 10 Dec 2009 11:04:41 +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, 10 Dec 2009 11:04:52 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Thu, 10 Dec 2009 11:04:39 +0200 Thread-Topic: Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) Thread-Index: Acp5d837IM8BJDTwTNKETE/OClgs7g== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@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_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0Cilex01adche_" MIME-Version: 1.0 Subject: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) 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, 10 Dec 2009 09:05:00 -0000 --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0Cilex01adche_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is to begin a 4 week working group last call for draft-ietf-ipsecme-ik= ev2bis-06. The target status for this document is Proposed Standard, obsole= ting RFC 4306 and RFC 4718. Please send your comments to the ipsec list by Jan. 5, 2010, as follow-ups = to this message. This is a large document, and arguably the most important document this WG = is entrusted with. The LC period is longer than usual but will include vaca= tion time for most of us. Nevertheless, please make an effort to review the= entire document, or at least large portions of it. Feel free to post multi= ple partial reviews. In this particular case, we are starting the review with a few open issues<= http://trac.tools.ietf.org/wg/ipsecme/trac/query?status=3Dnew&status=3Dassi= gned&status=3Dreopened&component=3Ddraft-ietf-ipsecme-ikev2bis>. We will ma= ke an effort to close them during the WG LC period. As a reminder regarding the document's scope (and our constraints while rev= iewing it), I will quote from my mail of Aug. 2008: General: The goal of the IKEv2 bis document is to clarify the protocol. The= goal is not to extend it. Specifically: * The document will combine RFC 4306 (IKEv2) and RFC 4718 (IKEv2 clarificat= ions), but no other RFCs. * The document will add clarifications based on the community's deployment = experience. * It is OK to correct minor technical errors and contradictions in the sour= ce documents. Any such corrections will be pointed out explicitly - prefera= bly in an appendix (so that people using the old documents can scan it to d= iscover problem areas). * The document will not add any "nice to have" extensions, no matter how mu= ch technical sense they make. Please clearly indicate the position of any issue in the Internet Draft, an= d if possible provide alternative text. Please also indicate the nature or = severity of the error or correction, e.g. major technical, minor technical,= nit, so that we can quickly judge the extent of problems with the document= . The document can be accessed here: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-06 Thanks, Yaron --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0Cilex01adche_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is to begin a 4 w= eek working group last call for draft-ietf-ipsecme-ikev2bis-06. The target stat= us for this document is Proposed Standard, obsoleting RFC 4306 and RFC 4718.

 

Please send your comme= nts to the ipsec list by Jan. 5, 2010, as follow-ups to this message.

 

This is a large docume= nt, and arguably the most important document this WG is entrusted with. The LC period is longer than usual but will include vacation time for most of us. Nevertheless, please make an effort to review the entire document, or at le= ast large portions of it. Feel free to post multiple partial reviews.

 

In this particular cas= e, we are starting the review with a few open issues. We will make an effort to close them during the WG LC period.

 

As a reminder regardin= g the document’s scope (and our constraints while reviewing it), I will quo= te from my mail of Aug. 2008:

 

General: = The goal of the IKEv2 bis document is to clarify the protocol. = The goal is not to extend it. Specifically:

 


<=
font
size=3D2 color=3Dblack face=3D"Courier New">*
The document will combine RFC 4306 (IKEv2) and RFC 4718 (IKEv2 =
clarifications),
but no other RFCs.



<=
font
size=3D2 color=3Dblack face=3D"Courier New">*
The document will add clarifications based on the community's=
 =
deployment
experience.



<=
font
size=3D2 color=3Dblack face=3D"Courier New">*
It is OK to correct minor technical errors and contradictions in the=
 =
source
documents. Any such corrections will be pointed out explicitly - =
preferably
in an appendix (so that people using the old documents can =
scan
it to discover problem areas).



<=
font
size=3D2 color=3Dblack face=3D"Courier New">*
The document will not add any "nice to have" extensions, no matte=
r
how=
 much
technical sense they make.



 



Please clearly indicat=
e the
position of any issue in the Internet Draft, and if possible provide altern=
ative
text. Please also indicate the nature or severity of the error or correctio=
n,
e.g. major technical, minor technical, nit, so that we can quickly judge th=
e
extent of problems with the document.



 



The document can be ac=
cessed
here:



 



http://t=
ools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-06



 



Thanks,



   &nbs=
p;  Yaron
--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0Cilex01adche_-- From kivinen@iki.fi Thu Dec 10 01:29: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 7D5593A6A95 for ; Thu, 10 Dec 2009 01:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 3sA4OseAr98A for ; Thu, 10 Dec 2009 01:29:47 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 4FE4B3A6A90 for ; Thu, 10 Dec 2009 01:29:47 -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 nBA9TQqD010433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 11:29:26 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBA9TOkc012822; Thu, 10 Dec 2009 11:29: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: <19232.49012.698408.649973@fireball.kivinen.iki.fi> Date: Thu, 10 Dec 2009 11:29:24 +0200 From: Tero Kivinen To: Brian Swander In-Reply-To: <5E38DBF64E732C4C98512C53E1B14DDC299B1529@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F3@il-ex01.ad.checkpoint.com> <5E38DBF64E732C4C98512C53E1B14DDC2999E319@TK5EX14MBXW653.wingroup.windeplo y.ntdev.microsoft.com> <5E38DBF64E732C4C98512C53E1B14DDC299ACE4A@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <19230.14267.109849.507396@fireball.kivinen.iki.fi> <5E38DBF64E732C4C98512C53E1B14DDC299B1529@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 5 min Cc: "ipsec@ietf.org" , Stephen Kent 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: Thu, 10 Dec 2009 09:29:48 -0000 Brian Swander writes: > AH alone isn't good enough. We need solutions that also work with > end-to-end encryption. Then we are not talking about ESP-NULL traffic anymore, thus it falls outside the scope of our WESP charter: - A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. The starting points for this work item are draft-grewal-ipsec-traffic-visibility and draft-hoffman- esp-null-protocol. WESP is not meant to be used for encrypted traffic, it was designed to be used to detect encrypted ESP packets from ESP-NULL packets. -- kivinen@iki.fi From paul.hoffman@vpnc.org Thu Dec 10 08:15: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 C87F83A6A99 for ; Thu, 10 Dec 2009 08:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.222 X-Spam-Level: X-Spam-Status: No, score=-5.222 tagged_above=-999 required=5 tests=[AWL=-0.665, 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 WTB837BE6QDl for ; Thu, 10 Dec 2009 08:15: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 C1DE13A6882 for ; Thu, 10 Dec 2009 08:15:33 -0800 (PST) Received: from [75.101.18.87] (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 nBAGFK27032320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Dec 2009 09:15:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 10 Dec 2009 08:15:20 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] #126: Is ikev2bis section 1.7 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, 10 Dec 2009 16:15:38 -0000 Section 1.7 lists notable changes from RFC 4106. Those of us making those changes may have forgotten to also update section 1.7. As you are doing the WG LC review of the ikev2bis document, if you come across anything that you think is a notable change to IKEv2, please check if it is listed in section 1.7; if it is not, please reply on this thread. Thanks! --Paul Hoffman, Director --VPN Consortium From dpquigl@tycho.nsa.gov Wed Dec 9 11:15: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 DE5EE3A6ADD for ; Wed, 9 Dec 2009 11:15:37 -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 fukke0C3g1u2 for ; Wed, 9 Dec 2009 11:15:36 -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 E692E3A6841 for ; Wed, 9 Dec 2009 11:15:35 -0800 (PST) Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id nB9JH5h4015980; Wed, 9 Dec 2009 19:17:05 GMT Received: from [144.51.25.2] (moss-terrapins [144.51.25.2]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id nB9JElH3011264; Wed, 9 Dec 2009 14:14:47 -0500 From: "David P. Quigley" To: Paul Moore In-Reply-To: <200912091231.21086.paul.moore@hp.com> References: <4B1EE1C5.3020807@sun.com> <4B1F200F.6080105@schaufler-ca.com> <1260372090.2484.236.camel@moss-terrapins.epoch.ncsc.mil> <200912091231.21086.paul.moore@hp.com> Content-Type: text/plain Organization: National Security Agency Date: Wed, 09 Dec 2009 14:06:04 -0500 Message-Id: <1260385564.2484.456.camel@moss-terrapins.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 10 Dec 2009 08:24:08 -0800 Cc: tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , Jarrett Lu , serue@linux.vnet.ibm.com 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: Wed, 09 Dec 2009 19:15:38 -0000 On Wed, 2009-12-09 at 12:31 -0500, Paul Moore wrote: > On Wednesday 09 December 2009 10:21:30 am David P. Quigley wrote: > > On Tue, 2009-12-08 at 19:57 -0800, Casey Schaufler wrote: > > [snip] > > > > > > The term "DOI" has been used in traditional MLS system for about two > > > > decades. In the MLS world, when systems use same DOI, it means they > > > > agree to the same label definition and MAC policy, and the systems are > > > > most likely under same administrative control (Note which policy is > > > > agreed upon is handled outside of a networking protocol). The label > > > > format is determined, i.e. it's CIPSO. > > > > > > Actually, the TSIG definition only requires that the two be able > > > to work out their differences. They are not required to speak the > > > same > > > > I think that this is a reasonable statement. > > > > [snip] > > > > > > David Quigley and I had some offline conversation about this, as he > > > > has the same need for labeled NFSv4 work. The current thinking is to > > > > have a separate draft describing the need to set up an IANA registry > > > > and its content. Each entry consists at least the following fields: > > > > LABEL TYPE: A number to indicate label type, e.g. CIPSO, CALIPSO, > > > > SELinux security contex strings, etc. > > > > SUB FIELD: Used to aid label handling, e.g. SELinux could use it for > > > > policy version numbers; CIPSO could use it for tag type; > > > > LABEL FORMAT: pointers to reference docs on how labels should be > > > > parsed. > > > > > > > > Both Labeled IPsec and labeled NFSv4 (and any future label protocol > > > > extensions) can refer to this document. > > > > > > Two systems, no matter how similar, will never be able to translate > > > formatted labels reliably. It only takes trivial changes to an SELinux > > > system for my_dog_has_no_nose_t to mean completely different things > > > on the two machines. > > > > > > I stick by my claim that the right and only rational scheme is for > > > each system to explicitly map the labels it understands from another > > > system to local values, and vis versa. Any label without a mapping > > > must be discarded unused. If you are brave and foolish you can say > > > that the mapping is unity. > > > > I'm pretty sure this is what has been proposed from the beginning. I > > don't know where in our conversations at least that I've given you a > > different opinion. > > I agree with Casey and David. I think the only way we stand any chance of > success is to develop a on-the-wire format that can be easily internalized by > a variety of implementations. For example, I know CIPSO is far from the > darling child of labeled networking, but due in large part to it's simple, MLS > (level/compartment) format it is possible to interoperate between fairly > different security models. I've personally used CIPSO to communicate between > Trusted Solaris (that is traditional TSOL not FMAC) and SELinux as well as > SELinux and Smack (interesting because Smack does not have inherent MLS > specifics like TSOL and SELinux); I have not tried to interoperate between > Smack and Trusted Solaris but I see no reason why it would fail. I will be > the first to admit that these were simple test cases and there was definitely > configuration on both required to reach this point, but it is possible. > > I hope to be able to do the same with CALIPSO when I finish the Linux > implementation (only about 50% at present). > > It is partly because of this experience that I'm not entirely convinced a > label format token is needed along with the DOI token and label blob. I > currently believe that the best solution would be one that only specified the > DOI and the label, in whatever representation seems "the best" given what we > currently know. Specify in great detail what the on-the-wire format should > look like and let the individual implementations worry about translating from > their native format to the wire format. I suspect this will provide the > highest level of interoperability and as a result, adoption. > I don't think its realistic to develop a single on the wire format for labels. I'm pretty sure this has been tried in the past and has failed. I also think its not very reasonable to have the DOI incorporate both the format of the label and the policy authority/identifier. Dave From casey@schaufler-ca.com Wed Dec 9 13:43: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 3A4713A6937 for ; Wed, 9 Dec 2009 13:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 ZZVrYq2t7Bdi for ; Wed, 9 Dec 2009 13:43:08 -0800 (PST) Received: from smtp106.prem.mail.sp1.yahoo.com (smtp106.prem.mail.sp1.yahoo.com [98.136.44.61]) by core3.amsl.com (Postfix) with SMTP id 509883A67A5 for ; Wed, 9 Dec 2009 13:43:08 -0800 (PST) Received: (qmail 88304 invoked from network); 9 Dec 2009 21:42:55 -0000 Received: from c-76-102-151-19.hsd1.ca.comcast.net (casey@76.102.151.19 with plain) by smtp106.prem.mail.sp1.yahoo.com with SMTP; 09 Dec 2009 13:42:55 -0800 PST X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- X-YMail-OSG: FGBWVK4VM1mZMjy5WDV9tTarVUEVrLpciz.8qeeztrB10WAjCZqKAnBaywBjygoovyVDsKEYHcZSgONzw.wEqxCw7bSL2Su1TSdwb_VwaiB2J2Dmk8MnfhWfdEoEHBi9LanmuOmqKLuVhNdNCQ2DrYQfWXcjsK7Ua_RmH5GGo6KR8fgycNKotAfylfFDnZUF9D89LaFnBbhp5FDvMiTxc8TMGrvVAEAE5QyaY80jMOYEokumh9_jCyuhNFmGXXKXVe_dlxYbSdxXslS5XFJjd06aMmHesYydAc4Wfr0lbJ507.rExf3S94U- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B2019DC.3060908@schaufler-ca.com> Date: Wed, 09 Dec 2009 13:42:52 -0800 From: Casey Schaufler User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "David P. Quigley" References: <4B1EE1C5.3020807@sun.com> <200912091231.21086.paul.moore@hp.com> <4B1FFB04.4000803@sun.com> <200912091448.49587.paul.moore@hp.com> <1260388020.2484.514.camel@moss-terrapins.epoch.ncsc.mil> In-Reply-To: <1260388020.2484.514.camel@moss-terrapins.epoch.ncsc.mil> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 10 Dec 2009 08:24:08 -0800 Cc: Paul Moore , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Jarrett.Lu@sun.com, serue@linux.vnet.ibm.com 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: Wed, 09 Dec 2009 21:43:09 -0000 David P. Quigley wrote: > On Wed, 2009-12-09 at 14:48 -0500, Paul Moore wrote: > >> On Wednesday 09 December 2009 02:31:16 pm Jarrett Lu wrote: >> >>> Paul Moore wrote: >>> >>>> I agree with Casey and David. I think the only way we stand any chance >>>> of success is to develop a on-the-wire format that can be easily >>>> internalized by a variety of implementations. For example, I know CIPSO >>>> is far from the darling child of labeled networking, but due in large >>>> part to it's simple, MLS (level/compartment) format it is possible to >>>> interoperate between fairly different security models. I've personally >>>> used CIPSO to communicate between Trusted Solaris (that is traditional >>>> TSOL not FMAC) and SELinux as well as SELinux and Smack (interesting >>>> because Smack does not have inherent MLS specifics like TSOL and >>>> SELinux); I have not tried to interoperate between Smack and Trusted >>>> Solaris but I see no reason why it would fail. I will be the first to >>>> admit that these were simple test cases and there was definitely >>>> configuration on both required to reach this point, but it is possible. >>>> >>>> I hope to be able to do the same with CALIPSO when I finish the Linux >>>> implementation (only about 50% at present). >>>> >>>> It is partly because of this experience that I'm not entirely convinced a >>>> label format token is needed along with the DOI token and label blob. I >>>> currently believe that the best solution would be one that only specified >>>> the DOI and the label, in whatever representation seems "the best" given >>>> what we currently know. Specify in great detail what the on-the-wire >>>> format should look like and let the individual implementations worry >>>> about translating from their native format to the wire format. I suspect >>>> this will provide the highest level of interoperability and as a result, >>>> adoption. >>>> >>> This sounds as too ambitious to me. Even if this can be done for all known >>> label formats in use today, how would we know it will map well for some new >>> labels in future? >>> >> We don't, well not unless your crystal ball works a lot better than mine :) >> >> I'm concerned that if we devote too much effort into making the protocol >> completely future-proof we will end up sacrificing capability with the >> implementations we have today (or can envision). Beyond the interoperability >> concerns over multiple label formats, one of my main concerns is that a >> protocol with multiple formats is almost surely going to be rejected/ignored >> by the intermediate hop vendors as it is too difficult to put in an ASIC. One >> of the lessons I learned during the CALIPSO review process was that one of the >> reasons CIPSO failed was due to the different label formats, aka CIPSO "tag >> types", which made it difficult for intermediate node vendors to parse and >> apply security policy quickly. >> >> Nothing last forever, especially when technology is concerned, there is always >> another revision (and another ... and another). I understand that we need to >> design the protocol to be flexible but in this case I think we need to >> approach flexibility with some restraint. >> >> > > I spoke with Ran at the IETF in San Francisco and he told me that router > vendors will definitely not approve of having to do string comparisons > to apply security policy. The "router vendors" have always been the excuse for not getting IETF approval for security attribute protocols. They were the opponents to CIPSO the first time around, as Paul mentioned. This is ridiculous, since it is pretty well known that the OS that the "router vendors" all use is ... wait for it ... Linux! > This means the only label formats that you're > going to be able to get the intermediate hop vendors to approve of are > strictly things like CALIPSO. They want to be able to do a quick integer > and bitmask comparison. Sure, and I want the Moon on a stick. There is absolutely no reason why the "router vendors" can't figure out how to deal with blobs. Paul has given them ample examples of what needs doing. > Having to parse a string and pass it to a policy > decisions engine doesn't seem to be acceptable. > But they parse data and pass it to engines all the time anyway. It may well be the case that they don't see any market for it, but that is hardly a technical argument. > Dave > > > From paul.hoffman@vpnc.org Thu Dec 10 11:41: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 964CA3A67B5 for ; Thu, 10 Dec 2009 11:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.955 X-Spam-Level: X-Spam-Status: No, score=-5.955 tagged_above=-999 required=5 tests=[AWL=0.091, 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 vqIzOYnmIdLt for ; Thu, 10 Dec 2009 11:41:18 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B3A333A677E for ; Thu, 10 Dec 2009 11:41:16 -0800 (PST) Received: from [75.101.18.87] (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 nBAJf3Rc051906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 12:41:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19211.62111.964182.719403@fireball.kivinen.iki.fi> References: <19211.58760.146418.200791@fireball.kivinen.iki.fi> <19211.58760.146418.200791@fireball.kivinen.iki.fi> <19211.62111.964182.719403@fireball.kivinen.iki.fi> Date: Thu, 10 Dec 2009 11:41:01 -0800 To: Scott C Moonen , Tero Kivinen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG 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: Thu, 10 Dec 2009 19:41:19 -0000 At 9:34 AM -0500 11/24/09, Scott C Moonen wrote: > > > > 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) >...snip... > > 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. At 4:50 PM +0200 11/24/09, Tero Kivinen wrote: >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... Can either of you propose the new text? --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Thu Dec 10 11:53: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 634DF3A68E0 for ; Thu, 10 Dec 2009 11:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.957 X-Spam-Level: X-Spam-Status: No, score=-5.957 tagged_above=-999 required=5 tests=[AWL=0.089, 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 TmttsX4Lyaee for ; Thu, 10 Dec 2009 11:53:25 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id AD5D43A6841 for ; Thu, 10 Dec 2009 11:53:23 -0800 (PST) Received: from [75.101.18.87] (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 nBAJrAl9053100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Dec 2009 12:53:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19221.6402.228166.814800@fireball.kivinen.iki.fi> References: <19221.6402.228166.814800@fireball.kivinen.iki.fi> Date: Thu, 10 Dec 2009 11:53:09 -0800 To: ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] #124: INTERNAL_ADDRESS_FAILURE error and how to continue. 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, 10 Dec 2009 19:53:27 -0000 Dan McDonald has agreed to this addition; does anyone else have an opinion? --Paul Hoffman At 3:24 PM +0200 12/1/09, Tero Kivinen wrote: >The section 1.2 says that if we get INTERNAL_ADDRESS_FAILURE then the >IKE SA stays up, but the child SA is not created. It does not say >anything what should happen on the initiator if it actually did >require address by policy. > >I think we have two options: > >1) Tear down the IKE SA (by sending DELETE payload inside > INFORMATIONAL exchange) and try again after suitable timeout. > >2) Keep the existing IKE SA up, but retry the configuration payload > exchange again after suitable timeout by starting new INFORMATIONAL > exchange and putting same configuration payloads in it. > >I think we might want mention something about this in the section 1.2, >or section 3.15.4 Address Assignment Failures. > >Most likely the section 3.15.4 is better, but we might want to add >forward reference from section 1.2 to there. > >Section 3.15.4 do explain how the responder can behave in different >situations, but it does not cover what initiator should do. > >Perhaps adding following paragraph to the end of 3.15.4 would help: >---------------------------------------------------------------------- > If the initiator does not receive the IP address(es) required by its > policy, it MAY keep the IKE SA up and retry the configuration > payload (as separate INFORMATIONAL exchange) after suitable timeout, > or it MAY also tear down the IKE SA (by sending DELETE payload > inside separate INFORMATIONAL exchange) and retry IKE SA from the > beginning after some longer timeout. The timeout should not be too > short (especially if the IKE SA is started from the beginning), as > these error situations will only be fixed when more entries are > returned to the address pool of the responder, thus it will not be > fixed in seconds, but more likely it takes several minutes. >-- >kivinen@iki.fi >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Thu Dec 10 11:57: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 061623A688D for ; Thu, 10 Dec 2009 11:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.958 X-Spam-Level: X-Spam-Status: No, score=-5.958 tagged_above=-999 required=5 tests=[AWL=0.088, 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 u4YviyCUmm31 for ; Thu, 10 Dec 2009 11:57:26 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 304AA3A6841 for ; Thu, 10 Dec 2009 11:57:26 -0800 (PST) Received: from [75.101.18.87] (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 nBAJvCxM053356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 12:57:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19221.6694.57191.182648@fireball.kivinen.iki.fi> References: <19221.6694.57191.182648@fireball.kivinen.iki.fi> Date: Thu, 10 Dec 2009 11:57:10 -0800 To: Tero Kivinen , ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] #125: inconsistency in the section 2.9 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, 10 Dec 2009 19:57:27 -0000 Does anyone have an opinion on Tero's suggestion to remove the sentence? --Paul Hoffman At 3:29 PM +0200 12/1/09, Tero Kivinen wrote: >The section 2.9 has text which says: >---------------------------------------------------------------------- >2.9. Traffic Selector Negotiation > > ... Since the two endpoints may be configured by different > people, the incompatibility may persist for an extended period even > in the absence of errors. It also allows for intentionally different > configurations, as when one end is configured to tunnel all addresses > and depends on the other end to have the up-to-date list. > > ... > > ... This case > will occur only when the initiator and responder are configured > differently from one another. If the initiator and responder agree > on the granularity of tunnels, the initiator will never request a > tunnel wider than the responder will accept. Such misconfigurations > should be recorded in error logs. >---------------------------------------------------------------------- > >So the first part says that traffic selectors may be different on >initiator's and responder's policy and that such a configuration may >be intentional. > >Then the second part calls such configuration misconfigurations and >require such events to be logged. > >This is bit inconsistent, and I think the second part should be >modified so that the last sentence is removed, or rephrased. >-- >kivinen@iki.fi >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From sommerfeld@sun.com Thu Dec 10 11:57: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 C11A33A68C3 for ; Thu, 10 Dec 2009 11:57:51 -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 unsCg2lwiyUF for ; Thu, 10 Dec 2009 11:57:51 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 16CD83A67B5 for ; Thu, 10 Dec 2009 11:57:51 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBAJvGQn020216; Thu, 10 Dec 2009 19:57:16 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 nBAJvG4t007133; Thu, 10 Dec 2009 11:57:16 -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 nBAJvGsq020098; Thu, 10 Dec 2009 11:57:16 -0800 (PST) Received: (from sommerfeld@localhost) by thunk-west.local (8.14.3+Sun/8.14.3/Submit) id nBAJv8oZ020097; Thu, 10 Dec 2009 11:57:08 -0800 (PST) X-Authentication-Warning: thunk-west.local: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Jarrett.Lu@sun.com In-Reply-To: <4B20088F.40607@sun.com> References: <4B1EE1C5.3020807@sun.com> <200912091231.21086.paul.moore@hp.com> <4B1FFB04.4000803@sun.com> <200912091448.49587.paul.moore@hp.com> <4B20088F.40607@sun.com> Content-Type: text/plain; charset="ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Dec 2009 11:57:08 -0800 Message-ID: <1260475028.20004.50.camel@thunk-west> Mime-Version: 1.0 Cc: Paul Moore , "David P. Quigley" , tjaeger@cse.psu.edu, ipsec@ietf.org, gcwilson@us.ibm.com, latten@austin.ibm.com, Casey Schaufler , serue@linux.vnet.ibm.com 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: Thu, 10 Dec 2009 19:57:51 -0000 On Wed, 2009-12-09 at 12:29 -0800, Jarrett Lu wrote: > I could be wrong here. I thought the opaque blob is passed as pay load=20 > in IKE exchange, not as IP option in the header. There are multiple places where labels could appear on a packet by packet basis: a) explicitly in each packet outside encryption b) explicitly in each packet inside encryption c) implicitly (as an attribute of the security association) any router forwarding the packet which doesn't have the encryption key should not be able to tell the difference between (b) and (c). In all three cases, labels could also be part of the key management protocol; in case (c) that's the only place they appear in a wire protocol. when I implemented the labeled IPsec now in solaris development builds, I found that (c) was the simplest piece of the implementation -- there's no per-packet on-the-wire protocol change. I think labeled IPsec is a large enough problem space that it could keep an entire working group busy. - Bill From smoonen@us.ibm.com Thu Dec 10 11:59: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 08DC93A6954 for ; Thu, 10 Dec 2009 11:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.269 X-Spam-Level: X-Spam-Status: No, score=-6.269 tagged_above=-999 required=5 tests=[AWL=0.329, 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 urqCzeXxQlp6 for ; Thu, 10 Dec 2009 11:59:19 -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 AAD0A3A68E6 for ; Thu, 10 Dec 2009 11:59:19 -0800 (PST) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e38.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nBAJs8Yh022459 for ; Thu, 10 Dec 2009 12:54:08 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBAJwaZc072972 for ; Thu, 10 Dec 2009 12:58:39 -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 nBAJwa1a026221 for ; Thu, 10 Dec 2009 12:58:36 -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 nBAJwaqo026216; Thu, 10 Dec 2009 12:58:36 -0700 In-Reply-To: References: <19211.58760.146418.200791@fireball.kivinen.iki.fi> <19211.58760.146418.200791@fireball.kivinen.iki.fi> <19211.62111.964182.719403@fireball.kivinen.iki.fi> To: Paul Hoffman MIME-Version: 1.0 X-KeepSent: 4DC7CAF1:F3595147-85257688:006D486D; 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 12/10/2009 02:58:14 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 12/10/2009 02:58:14 PM, Serialize complete at 12/10/2009 02:58:14 PM, S/MIME Sign failed at 12/10/2009 02:58:14 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 12/10/2009 12:58:36, Serialize complete at 12/10/2009 12:58:36 Message-ID: Date: Thu, 10 Dec 2009 14:58:35 -0500 Content-Type: multipart/alternative; boundary="=_alternative 006DB3D085257688_=" Cc: IPsecme WG , Tero Kivinen 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: Thu, 10 Dec 2009 19:59:21 -0000 This is a multipart message in MIME format. --=_alternative 006DB3D085257688_= Content-Type: text/plain; charset="US-ASCII" > > > 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... > > Can either of you propose the new text? Here's a first shot. I think we can move the paragraph later on (starting with "SK_d, ...") adjacent to this paragraph to produce: The old and new IKE SA may have selected a different PRF. Because the rekeying exchange belongs to the old IKE SA, it is the old IKE SA's PRF that is used to generate SKEYSEED. SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as specified in Section 2.14, using SPIi, SPIr, Ni, and Nr from the new exchange, and using the new IKE SA's PRF. 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, Tero Kivinen Cc: IPsecme WG Date: 12/10/2009 02:41 PM Subject: Re: [IPsec] #121: Rekeying IKE SAs: KEr errors and PRF question At 9:34 AM -0500 11/24/09, Scott C Moonen wrote: > > > > 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) >...snip... > > 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. At 4:50 PM +0200 11/24/09, Tero Kivinen wrote: >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... Can either of you propose the new text? --Paul Hoffman, Director --VPN Consortium --=_alternative 006DB3D085257688_= Content-Type: text/html; charset="US-ASCII"
> > > 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...
>
> Can either of you propose the new text?

Here's a first shot.  I think we can move the paragraph later on (starting with "SK_d, ...") adjacent to this paragraph to produce:

   The old and new IKE SA may have selected a different PRF.  Because
   the rekeying exchange belongs to the old IKE SA, it is the old IKE
   SA's PRF that is used to generate SKEYSEED.

   SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as
   specified in Section 2.14, using SPIi, SPIr, Ni, and Nr from the new
   exchange, and using the new IKE SA's PRF.


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, Tero Kivinen <kivinen@iki.fi>
Cc: IPsecme WG <ipsec@ietf.org>
Date: 12/10/2009 02:41 PM
Subject: Re: [IPsec] #121: Rekeying IKE SAs: KEr errors and PRF question




At 9:34 AM -0500 11/24/09, Scott C Moonen wrote:
>
> > > 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)
>...snip...
> > 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.

At 4:50 PM +0200 11/24/09, Tero Kivinen wrote:
>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...

Can either of you propose the new text?

--Paul Hoffman, Director
--VPN Consortium

--=_alternative 006DB3D085257688_=-- From smoonen@us.ibm.com Thu Dec 10 12:13: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 610A73A659B; Thu, 10 Dec 2009 12:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[AWL=-1.712, 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 7dDiRb5Pvwq9; Thu, 10 Dec 2009 12:13:48 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by core3.amsl.com (Postfix) with ESMTP id D476C3A6889; Thu, 10 Dec 2009 12:13:47 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e39.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nBAK71dS027680; Thu, 10 Dec 2009 13:07:01 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBAKDExG050612; Thu, 10 Dec 2009 13:13:18 -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 nBAKDEJW012235; Thu, 10 Dec 2009 13:13:14 -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 nBAKDDx2012223; Thu, 10 Dec 2009 13:13:13 -0700 In-Reply-To: References: <19221.6694.57191.182648@fireball.kivinen.iki.fi> To: Paul Hoffman MIME-Version: 1.0 X-KeepSent: F51F5ABA:7F5C60F0-85257688:006EF1A8; 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 12/10/2009 03:12:49 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 12/10/2009 03:12:49 PM, Serialize complete at 12/10/2009 03:12:49 PM, S/MIME Sign failed at 12/10/2009 03:12:49 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 12/10/2009 13:13:13, Serialize complete at 12/10/2009 13:13:13 Message-ID: Date: Thu, 10 Dec 2009 15:13:12 -0500 Content-Type: multipart/alternative; boundary="=_alternative 006F09B885257688_=" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Tero Kivinen Subject: Re: [IPsec] #125: inconsistency in the section 2.9 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, 10 Dec 2009 20:13:49 -0000 This is a multipart message in MIME format. --=_alternative 006F09B885257688_= Content-Type: text/plain; charset="US-ASCII" I'm ok with removing the sentence. 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 , ipsec@ietf.org Date: 12/10/2009 03:00 PM Subject: Re: [IPsec] #125: inconsistency in the section 2.9 Does anyone have an opinion on Tero's suggestion to remove the sentence? --Paul Hoffman At 3:29 PM +0200 12/1/09, Tero Kivinen wrote: >The section 2.9 has text which says: >---------------------------------------------------------------------- >2.9. Traffic Selector Negotiation > > ... Since the two endpoints may be configured by different > people, the incompatibility may persist for an extended period even > in the absence of errors. It also allows for intentionally different > configurations, as when one end is configured to tunnel all addresses > and depends on the other end to have the up-to-date list. > > ... > > ... This case > will occur only when the initiator and responder are configured > differently from one another. If the initiator and responder agree > on the granularity of tunnels, the initiator will never request a > tunnel wider than the responder will accept. Such misconfigurations > should be recorded in error logs. >---------------------------------------------------------------------- > >So the first part says that traffic selectors may be different on >initiator's and responder's policy and that such a configuration may >be intentional. > >Then the second part calls such configuration misconfigurations and >require such events to be logged. > >This is bit inconsistent, and I think the second part should be >modified so that the last sentence is removed, or rephrased. >-- >kivinen@iki.fi >_______________________________________________ >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 006F09B885257688_= Content-Type: text/html; charset="US-ASCII"
I'm ok with removing the sentence.

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>, ipsec@ietf.org
Date: 12/10/2009 03:00 PM
Subject: Re: [IPsec] #125: inconsistency in the section 2.9




Does anyone have an opinion on Tero's suggestion to remove the sentence?

--Paul Hoffman

At 3:29 PM +0200 12/1/09, Tero Kivinen wrote:
>The section 2.9 has text which says:
>----------------------------------------------------------------------
>2.9.  Traffic Selector Negotiation
>
>   ... Since the two endpoints may be configured by different
>   people, the incompatibility may persist for an extended period even
>   in the absence of errors.  It also allows for intentionally different
>   configurations, as when one end is configured to tunnel all addresses
>   and depends on the other end to have the up-to-date list.
>
>   ...
>
>   ... This case
>   will occur only when the initiator and responder are configured
>   differently from one another.  If the initiator and responder agree
>   on the granularity of tunnels, the initiator will never request a
>   tunnel wider than the responder will accept.  Such misconfigurations
>   should be recorded in error logs.
>----------------------------------------------------------------------
>
>So the first part says that traffic selectors may be different on
>initiator's and responder's policy and that such a configuration may
>be intentional.
>
>Then the second part calls such configuration misconfigurations and
>require such events to be logged.
>
>This is bit inconsistent, and I think the second part should be
>modified so that the last sentence is removed, or rephrased.
>--
>kivinen@iki.fi
>_______________________________________________
>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 006F09B885257688_=-- From M.Vondemkamp@F5.com Thu Dec 10 12:42: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 0B2A13A6A4E for ; Thu, 10 Dec 2009 12:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] 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 raknnlgd8hvt for ; Thu, 10 Dec 2009 12:42:39 -0800 (PST) Received: from mail.f5.com (lists.f5.com [65.197.145.96]) by core3.amsl.com (Postfix) with ESMTP id E06F028C11C for ; Thu, 10 Dec 2009 12:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=M.Vondemkamp@f5.com; q=dns/txt; s=seattle; t=1260477748; x=1292013748; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Mark=20Vondemkamp=20 |Subject:=20Proposed=20work=20item:=20WESP=20extensibilit y=20-=20YES|Date:=20Thu,=2010=20Dec=202009=2012:41:06=20- 0800|Message-ID:=20|To:=20"ipsec@ietf.org"=20 |MIME-Version:=201.0; bh=dpDjBtETa1ywOgd14OrZEXjDN5ee9Nx2fVX37rcF8bE=; b=PIpmeVr8rJhkBto2bJqAeBZCH5M1jM1llyFM37KjA5nBtX3S4S3IB4wj S7DOBjZmQi6GnOKcWANyAHhbad96ohak72XlZ9pTd4dUt82rltrMYZEGq +SqmUelcBFvkjVO03A0A+bAou9cu9XnFVVJL4wArQLStr1JwCfTr6RHP3 E=; X-IronPort-AV: E=Sophos;i="4.47,377,1257120000"; d="gif'147?scan'147,208,217,147";a="8394547" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.240]) by mail.f5.com with ESMTP/TLS/RC4-MD5; 10 Dec 2009 20:42:27 +0000 Received: from exch11.olympus.f5net.com ([192.168.16.104]) by e2k7ca1.olympus.f5net.com ([192.168.16.101]) with mapi; Thu, 10 Dec 2009 12:42:27 -0800 From: Mark Vondemkamp To: "ipsec@ietf.org" Date: Thu, 10 Dec 2009 12:41:06 -0800 Thread-Topic: Proposed work item: WESP extensibility - YES Thread-Index: Acp52RjH+PW1ccDdTaeUBnQ1YDj9lw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_D3EAD5A419F7AA45AC864B43E1BF6D0F617715CB3Fexch11olympus_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [IPsec] Proposed work item: WESP extensibility - YES 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, 10 Dec 2009 20:42:40 -0000 --_004_D3EAD5A419F7AA45AC864B43E1BF6D0F617715CB3Fexch11olympus_ Content-Type: multipart/alternative; boundary="_000_D3EAD5A419F7AA45AC864B43E1BF6D0F617715CB3Fexch11olympus_" --_000_D3EAD5A419F7AA45AC864B43E1BF6D0F617715CB3Fexch11olympus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I support WESP Extensibility and commit as a reviewer. I think the capabili= ties for OAM (error notification, connectivity verification, monitoring) an= d the recently proposed option for payload content hints to the middleboxes= are valuable. Thank you, Mark Vondemkamp Mark Vondemkamp Director of Product Management, Security D 206.272.6039 M 425.367.7675 P 206.272.5555 F 206.272.5556 www.f5.com [cid:image001.gif@01CA7996.0AA41060] --_000_D3EAD5A419F7AA45AC864B43E1BF6D0F617715CB3Fexch11olympus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I support WESP Extens= ibility and commit as a reviewer. I think the capabilities for OAM (error notificat= ion, connectivity verification, monitoring) and the recently proposed option for payload content hints to the middleboxes are valuable.

 

Thank you,=

 

Mark Vondemkamp<= /o:p>

 

 

Mark Vondemkamp<= /p>

Director of Product Management, Security

= D

206.272.6039

M

425.367.7675

P

= 206.272.5555

F

206.272.5556

www.f5.com

 

 

--_000_D3EAD5A419F7AA45AC864B43E1BF6D0F617715CB3Fexch11olympus_-- --_004_D3EAD5A419F7AA45AC864B43E1BF6D0F617715CB3Fexch11olympus_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2877; creation-date="Thu, 10 Dec 2009 12:42:26 GMT"; modification-date="Thu, 10 Dec 2009 12:42:26 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhmAA3APcAAP////39/fz8/Pr7+/n5+vj4+ff3+Pb29/318/X29vT19fPz8/Ly8/rv7PHx 8vDx8e/w8Prs6e7v8O7u7+3t7vXs6vjr6Pnp5uzt7evs7Orr7Onp6vnl4efo6ebn6OXm5+/j4Pjh 3ePk5e3g3eLj5PXe2efh4Pbc1+Hi4+ne3Pba1d7g4d7f4Obc2/XY0+/Z1dzd3vDY1Oba1/TX0trc 3fXVz9nb3PTTzefV0djZ2+HV09fY2vTQytXX2PHQy+rSzvPOyNTV19PU1vLMxdLT1fLJwtnQz/HK xObLxtDR08/Q0uzIw83P0O/GwPHGwPHEvt3JxdXKyeDIxPHCvO/CvMnLzfDBuu3AudHGxMbIyuy+ uPC9t9vBvu+8te67tMTGyOm8tty+uuO7te64ssHDxey3sdK9uta8uMm+vL7Awu20ru2zrLy+wM25 tt22scO7u+ywquyuqLm7veWwqsu1stOxrcC1s+uppOmmoOmknumineigm6yuseiembmpqNKhneeb lsakoOaZlK2mpuaWkcmbl+WSjuCTj6+gntSWkrSdm9aSjZ+hpOSPi+SNicaUkOOKhaOXluKFgsqI hJOVmOGAfbiJhs6Df+B9etJ+e996eJuLit94dqOIhdR5dt52dMt6d950c4iKjN5ycd1wb6GAfd1u bpeAf9xra9xpaqt2c9toabVzcJp5dttmaNpkZnx+gNdkZot3ddlhZMVnZtlfY6NraNhcYbVmZNJc YNhZX4Zta9dVXHBxdJdmZNdSWoJnZdZOWK5YWL1TV9VKVpVaWHthYI5bWdVGVLNPUmNkZ8lJU9VF U9JEUtRDUrpKUNNBUZxQUI9UUqBPT5FTUnFcWpVSUZpRUKVMTolVU41UUqJOTqdLTYNVVNI9T3tW VKpJTK5GS9I5TXJVU7JCSsc6S2tUU8g5S7Y+Scs1Srk7SLw4R9EyS1VWWL80RsExRtAsSNAoR8Qs Rc8lRsclQ0dHScwhRM8eRMoeQ88bRM0ZQ80WQjc1NyMfIAAAAAAAACH5BAAHAP8ALAAAAACYADcA AAj/AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTAjkMGROnjyNI hAjlgXMDpc2bDjkUiXMHzx5AhBpBkoSJ0yhUqAgBwcm0KYcnXcas4amnDyFDQytxCmXKVS1do440 HVuyAZAnT6x0KQOnZx9BhhxJqqSJq1ddv4iRCkG2r0cVU5wIdrJFahw8b+POrdt1Fl5i0JDF8Uv5 IgIeXQIfOfJky5YnRYAAseJyMddVjvNCEwdPU+XXERFsUePFCtohIRoYRLDGdNevqlnb+wS7OMMu cdaM2TIkwsEA0AMcoSuIgPUSS5YQOhSr2T7ixsMX/7SC5w6cMScIIhjypIbu6AEEcaJincCBAwsW QICgQYYbEOIFqEIfeugBh3MEDcFTHn2UUQJ0RRTVQH335bdfBhl8QIIBARqHACAg3nGBQW35BJQh eKhBFyADtGiAAQoo4IADE2Co4SUdFqeGIYQAwsNBeJgISFxDFUVFiwO8GOOMNWZIwjCL5FjZBZA4 YogeCO3x01VYLfZJAy0OMUR2LzBpow7qJGOBlH7dIUmVWyAEIpdZaSVIizPcwkswzHjDDjzs5JJL JqCgQ84fbJKFwFxvLmUQB1y+NJdWoVjRIiCPrcbOPPvsQ88766ATjjCJjvUEJ5hgIokKB5XQiFB1 bv9FCpgDCPLLL33+ec8++MjjjjrkhMPND6Uy1cconDQCCF+7neDsCS5ECwgphCCZpAE+lHEIL/ro Q488oZIDDjaFFIuTJqZAFF0jqGxhrZIxPvDDIcu8A6yw27Birk0NvJJKRA1YMYortF4Lo4w0YpjI M8FiM801+6IERC2v8GAxQheoMWRcoaSSiiPvvpiffvx10AEXuICzTTTWjBCxSU/oUkstrriCUA2k 5IxUzbWMEXKMCjzwAAYbbCCCCEbg8vA1Urxc0h6/6CJzLQjdsDPPX1mA5IsGjHyhkyvQ0AbL1jTt 9Eh9BBMML1LDBx8Pr8Q9sy68SLI1vEEPjYHJKLD/YEMQllgjDRRnjwQIMsiozYvb0QFxy+N67qlG ffbhZyEEGHpwNAw5CIEGNdQQXnhIXnjjjDPEEMM4dEDw4rraagvShA9cLzkjBnt30DcNPRDBhC/Z iD76R06IIw400DCzunSwB4M48uL8SQwqkIAhNAUUFL15DkEkUUUr3bg8/EcRAGq8OAKkr376RSCO DPTR/zlPPp3aU44nYhT9we69M1FFJ90YX0iQEY94sIMd61ufE7zBQD/9CR7z2BWvvgWqddCCCyJY Aee6V4UvdKIVEEGBCLNAQhI6JAiiAEA/AMCHIDQkCCgYiASygJNP5CMf85jHCayFpCcc8IEQlOA+ /+zxLXeEKxzJ+AMMYNC/LJDhFIqACCUokQVKwKIeU3QICvigQgBkIYaUcGFCKKGMgSiDEjjBQ6f2 cQ/6UM46VChgPOxhj251Cx8UtNe9wKEyM+xACEroYBp2oQMpotGLZSwICWMIABQsUgIScOEKURDJ djDCkQOhIUEsCQA51AMAQciCGMUYSVBiUiCanKFASrlIL65SjAWJQDrw0a0rvNE6V7jhGnmVjjnU q4KGCse4sBENVXSPCU5kwy4ikkVEFsSKouAHCoLAD1H0oh8kLOMKqciHesAiC/VwoRzaoUhp8iML osBiPVKYyCyUURntSCQA2iGHTvbDhXyAhRUpwf8PasaQD71AiCfkQQ96XKEACC0A17TQKXw4lB7n WAIDxLCOcAWLG9yYxtJ8J8hIRNGQqJRnQUTBB1GkcJ7Z7CIVAaAMGpoUALBghEFE0Q9RoKAfEgCA BPqBgna+k4sDYQQsYNqOFPaingIRBSWUCoBeANUgJXCHO+QhCK4Z4D4HiEFB5cHVZYBgRg4ABTmC xcdtrMwaggtkMmVRAWYe0p0F6WY9sKgMpIoipdukYUsb+Ul+5LQgO52hPFvqU5ZqUiAo+GQ42yEB frBwrlgMQj0Cm5BMVHQRWD1AAjabgHd4FlS0AOsEUpAMPmKDmGTThi+QSQY2eFSGjHjqGN8qUhT/ 9BMASo2pQFoK17waViDtoERAD7JCcA4knMqIIVz3ukkrAgCLQ70nbtG4zqEmxALPQMcigKaAkS1g HeoIb3hxAEkJaKAOp9XoNa4Bumz4gYRsGMQyBwILZfRCpgppJlwHYltH8oMSnpQDI7DZWwCslBKX BMCAuUgJRg5khc9FIyU+2QtKSKAX7zysQBaMW37U856JRSNN63nIg4hhEUjw7gIYwOJhjHWs4ZgE 7oq2gUBEg2zSkEY2FCHIQVQjCgQRhX2tmxA+ABWFz7QvSTvZC1j0QpTsZKEL3ZnCIOCUpbDcrUCC gOFeuJDLZ0yhKLIMSmXkNAiJ5IOSuZgFx7JU/yEHACtYhfYAHEyCFqUFhzBaoL/90UEVxdDGMUrx hg6SYRPV8MMzYUHPjUBSp9JkCECbkk+HuCEMONgPBMpbXgyZtRAfCLUIl9iDHiTBf1+IhDHMsYmD wJAj1FQGP/CrkHSS+STRdPBCKqC0aQiDFax4hLDPQOwz3DgatrBEIOiABRv0jghvQMQpjDEOVguQ KRWwxDWOfez1XgOt4M5xNsadjW+YexzVtva1m1IIcLs73OImd7nPne5q2GHdZMGBLXKsjX73W97d CLi5v4HudMvCBPj2Sx2AR+6AO3zgBEe3OcyxCzQk/DVmKEU3ID7wgk+8GpsA8sWNAwVFlKIVwBpA NzBkcQpEiHzkMI+5zGdO85rb/OY4X0hAAAA7 --_004_D3EAD5A419F7AA45AC864B43E1BF6D0F617715CB3Fexch11olympus_-- From yaronf@checkpoint.com Thu Dec 10 13:22: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 6F3A63A690F for ; Thu, 10 Dec 2009 13:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 hvUPk8GNJaKH for ; Thu, 10 Dec 2009 13:22:34 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 7FF793A68C4 for ; Thu, 10 Dec 2009 13:22:33 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBALMLT7026929; Thu, 10 Dec 2009 23:22: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; Thu, 10 Dec 2009 23:22:32 +0200 From: Yaron Sheffer To: Paul Hoffman , "ipsec@ietf.org" Date: Thu, 10 Dec 2009 23:22:18 +0200 Thread-Topic: [IPsec] #124: INTERNAL_ADDRESS_FAILURE error and how to continue. Thread-Index: Acp50nVaH27wZZxrSc6q65XpxoOS9wADCUgQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EAEE@il-ex01.ad.checkpoint.com> References: <19221.6402.228166.814800@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] #124: INTERNAL_ADDRESS_FAILURE error and how to continue. 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, 10 Dec 2009 21:22:35 -0000 I think Tero's text is somewhat speculative in assuming that this error cas= e only results from exhaustion of the address pool - I'm sure there can be = other reasons. Otherwise the text is OK. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Thursday, December 10, 2009 21:53 > To: ipsec@ietf.org > Subject: Re: [IPsec] #124: INTERNAL_ADDRESS_FAILURE error and how to > continue. >=20 > Dan McDonald has agreed to this addition; does anyone else have an > opinion? >=20 > --Paul Hoffman >=20 > At 3:24 PM +0200 12/1/09, Tero Kivinen wrote: > >The section 1.2 says that if we get INTERNAL_ADDRESS_FAILURE then the > >IKE SA stays up, but the child SA is not created. It does not say > >anything what should happen on the initiator if it actually did > >require address by policy. > > > >I think we have two options: > > > >1) Tear down the IKE SA (by sending DELETE payload inside > > INFORMATIONAL exchange) and try again after suitable timeout. > > > >2) Keep the existing IKE SA up, but retry the configuration payload > > exchange again after suitable timeout by starting new INFORMATIONAL > > exchange and putting same configuration payloads in it. > > > >I think we might want mention something about this in the section 1.2, > >or section 3.15.4 Address Assignment Failures. > > > >Most likely the section 3.15.4 is better, but we might want to add > >forward reference from section 1.2 to there. > > > >Section 3.15.4 do explain how the responder can behave in different > >situations, but it does not cover what initiator should do. > > > >Perhaps adding following paragraph to the end of 3.15.4 would help: > >---------------------------------------------------------------------- > > If the initiator does not receive the IP address(es) required by its > > policy, it MAY keep the IKE SA up and retry the configuration > > payload (as separate INFORMATIONAL exchange) after suitable timeout, > > or it MAY also tear down the IKE SA (by sending DELETE payload > > inside separate INFORMATIONAL exchange) and retry IKE SA from the > > beginning after some longer timeout. The timeout should not be too > > short (especially if the IKE SA is started from the beginning), as > > these error situations will only be fixed when more entries are > > returned to the address pool of the responder, thus it will not be > > fixed in seconds, but more likely it takes several minutes. > >-- > >kivinen@iki.fi > >_______________________________________________ > >IPsec mailing list > >IPsec@ietf.org > >https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From paul.hoffman@vpnc.org Thu Dec 10 14:12: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 439633A6B5E for ; Thu, 10 Dec 2009 14:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.96 X-Spam-Level: X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=0.086, 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 voPDeuXd5zV3 for ; Thu, 10 Dec 2009 14:12:31 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 052FC3A6B5C for ; Thu, 10 Dec 2009 14:12:30 -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 nBAM0YIu064031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Dec 2009 15:00:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EAEE@il-ex01.ad.checkpoint.com> References: <19221.6402.228166.814800@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EAEE@il-ex01.ad.checkpoint.com> Date: Thu, 10 Dec 2009 14:00:32 -0800 To: From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] #124: INTERNAL_ADDRESS_FAILURE error and how to continue. 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, 10 Dec 2009 22:12:32 -0000 At 11:22 PM +0200 12/10/09, Yaron Sheffer wrote: >I think Tero's text is somewhat speculative in assuming that this error case only results from exhaustion of the address pool - I'm sure there can be other reasons. Otherwise the text is OK. Good point. Current: > The timeout should not be too > short (especially if the IKE SA is started from the beginning), as > these error situations will only be fixed when more entries are > returned to the address pool of the responder, thus it will not be > fixed in seconds, but more likely it takes several minutes. Proposed: > The timeout should not be too > short (especially if the IKE SA is started from the beginning) > In many cases, the cause of the errors is that the address pool of > the responder is depleted, and this can > only be fixed when more entries are > returned to the address pool of the responder. This is likely > to take several minutes. --Paul Hoffman, Director --VPN Consortium From smb@cs.columbia.edu Thu Dec 10 16:01: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 72E1D3A68BF for ; Thu, 10 Dec 2009 16:01:53 -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 ig4012g-MwcW for ; Thu, 10 Dec 2009 16:01:52 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id 4DFA33A688C for ; Thu, 10 Dec 2009 16:01:52 -0800 (PST) Received: from 35.sub-75-227-171.myvzw.com (35.sub-75-227-171.myvzw.com [75.227.171.35]) (user=smb2132 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nBB01bIX000181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 10 Dec 2009 19:01:39 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: <1260475028.20004.50.camel@thunk-west> Date: Thu, 10 Dec 2009 19:01:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B1EE1C5.3020807@sun.com> <200912091231.21086.paul.moore@hp.com> <4B1FFB04.4000803@sun.com> <200912091448.49587.paul.moore@hp.com> <4B20088F.40607@sun.com> <1260475028.20004.50.camel@thunk-west> To: Bill Sommerfeld X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 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: Fri, 11 Dec 2009 00:01:53 -0000 On Dec 10, 2009, at 2:57 PM, Bill Sommerfeld wrote: > On Wed, 2009-12-09 at 12:29 -0800, Jarrett Lu wrote: >> I could be wrong here. I thought the opaque blob is passed as pay = load=20 >> in IKE exchange, not as IP option in the header. >=20 > There are multiple places where labels could appear on a packet by > packet basis: >=20 > a) explicitly in each packet outside encryption > b) explicitly in each packet inside encryption > c) implicitly (as an attribute of the security association) >=20 > any router forwarding the packet which doesn't have the encryption key > should not be able to tell the difference between (b) and (c). >=20 > In all three cases, labels could also be part of the key management > protocol; in case (c) that's the only place they appear in a wire > protocol. >=20 > when I implemented the labeled IPsec now in solaris development = builds, > I found that (c) was the simplest piece of the implementation -- = there's > no per-packet on-the-wire protocol change. Yes. In fact, if I recall correctly, the WG explicitly agreed many = years ago, back when we adopted the IPsec v2 standards, that this was = our preferred approach. I also don't understand why why labels in the = cleartext portion do any more good than putting it in the SA, since = routers can't verify it without a lot of trouble. Having a security label between the host and and IPsec gateways is = another matter -- that would be interesting indeed. >=20 > I think labeled IPsec is a large enough problem space that it could = keep > an entire working group busy. Right -- and to what end? --Steve Bellovin, http://www.cs.columbia.edu/~smb From kivinen@iki.fi Fri Dec 11 05:36: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 0AA843A6A02 for ; Fri, 11 Dec 2009 05:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 m7RUW7LEtFle for ; Fri, 11 Dec 2009 05:36:07 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B7B2C3A69B9 for ; Fri, 11 Dec 2009 05:36: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 nBBDZoBe028501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Dec 2009 15:35:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBBDZnAE029120; Fri, 11 Dec 2009 15:35:49 +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: <19234.19125.98719.260656@fireball.kivinen.iki.fi> Date: Fri, 11 Dec 2009 15:35:49 +0200 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <19211.58760.146418.200791@fireball.kivinen.iki.fi> <19211.62111.964182.719403@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: IPsecme WG , 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: Fri, 11 Dec 2009 13:36:08 -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... > > > > Can either of you propose the new text? > > Here's a first shot. I think we can move the paragraph later on (starting > with "SK_d, ...") adjacent to this paragraph to produce: > > The old and new IKE SA may have selected a different PRF. Because > the rekeying exchange belongs to the old IKE SA, it is the old IKE > SA's PRF that is used to generate SKEYSEED. > > SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as > specified in Section 2.14, using SPIi, SPIr, Ni, and Nr from the new > exchange, and using the new IKE SA's PRF. That looks good. -- kivinen@iki.fi From kivinen@iki.fi Fri Dec 11 05:45: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 CBA043A6860 for ; Fri, 11 Dec 2009 05:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 w8fFTBcDhvDg for ; Fri, 11 Dec 2009 05:45:19 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B20413A6827 for ; Fri, 11 Dec 2009 05:45: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 nBBDj252028978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Dec 2009 15:45:02 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBBDj2VF024351; Fri, 11 Dec 2009 15:45:02 +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: <19234.19678.43340.610828@fireball.kivinen.iki.fi> Date: Fri, 11 Dec 2009 15:45:02 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EAEE@il-ex01.ad.checkpoint.com> References: <19221.6402.228166.814800@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EAEE@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Cc: "ipsec@ietf.org" , Paul Hoffman Subject: Re: [IPsec] #124: INTERNAL_ADDRESS_FAILURE error and how to continue. 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, 11 Dec 2009 13:45:20 -0000 Yaron Sheffer writes: > I think Tero's text is somewhat speculative in assuming that this > error case only results from exhaustion of the address pool - I'm > sure there can be other reasons. Otherwise the text is OK. Can you give me example what other error causes can cause this error notification? Do you think they require any other type of handling than what is listed in my text? Anyway we can change the text to be following if that is better: If the initiator does not receive the IP address(es) required by its policy, it MAY keep the IKE SA up and retry the configuration payload (as separate INFORMATIONAL exchange) after suitable timeout, or it MAY also tear down the IKE SA (by sending DELETE payload inside separate INFORMATIONAL exchange) and retry IKE SA from the beginning after some longer timeout. The timeout should not be too short (especially if the IKE SA is started from the beginning), as these error situations are not fixed quickly, thus timeout should likely be several minutes. For example address shortage problem will only be fixed when more entries are returned to the address pool of the responder when other clients disconnect or when responder is reconfigured with larger address pool. -- kivinen@iki.fi From yaronf@checkpoint.com Fri Dec 11 06:24: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 3C74B3A68A8 for ; Fri, 11 Dec 2009 06:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 JCsrju1amuZG for ; Fri, 11 Dec 2009 06:24:41 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 05BC23A6A1B for ; Fri, 11 Dec 2009 06:24:40 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBBEOST7023192; Fri, 11 Dec 2009 16:24:28 +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, 11 Dec 2009 16:24:39 +0200 From: Yaron Sheffer To: Tero Kivinen Date: Fri, 11 Dec 2009 16:24:27 +0200 Thread-Topic: [IPsec] #124: INTERNAL_ADDRESS_FAILURE error and how to continue. Thread-Index: Acp6aCyKVTUTZOmwTheS/EURrCEh/QABTXcg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EAF9@il-ex01.ad.checkpoint.com> References: <19221.6402.228166.814800@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EAEE@il-ex01.ad.checkpoint.com> <19234.19678.43340.610828@fireball.kivinen.iki.fi> In-Reply-To: <19234.19678.43340.610828@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: "ipsec@ietf.org" , Paul Hoffman Subject: Re: [IPsec] #124: INTERNAL_ADDRESS_FAILURE error and how to continue. 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, 11 Dec 2009 14:24:42 -0000 No, I don't have a good example. But the error code is not reserved specifi= cally for this situation, so I wouldn't want to imply that it is. Anyway, I'm OK with your text and also with the text that Paul proposed ear= lier. Thanks, Yaron > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Friday, December 11, 2009 15:45 > To: Yaron Sheffer > Cc: Paul Hoffman; ipsec@ietf.org > Subject: Re: [IPsec] #124: INTERNAL_ADDRESS_FAILURE error and how to > continue. >=20 > Yaron Sheffer writes: > > I think Tero's text is somewhat speculative in assuming that this > > error case only results from exhaustion of the address pool - I'm > > sure there can be other reasons. Otherwise the text is OK. >=20 > Can you give me example what other error causes can cause this error > notification? Do you think they require any other type of handling > than what is listed in my text? >=20 > Anyway we can change the text to be following if that is better: >=20 > If the initiator does not receive the IP address(es) required by its > policy, it MAY keep the IKE SA up and retry the configuration > payload (as separate INFORMATIONAL exchange) after suitable timeout, > or it MAY also tear down the IKE SA (by sending DELETE payload > inside separate INFORMATIONAL exchange) and retry IKE SA from the > beginning after some longer timeout. The timeout should not be too > short (especially if the IKE SA is started from the beginning), as > these error situations are not fixed quickly, thus timeout should > likely be several minutes. For example address shortage problem will > only be fixed when more entries are returned to the address pool of > the responder when other clients disconnect or when responder is > reconfigured with larger address pool. > -- > kivinen@iki.fi >=20 > Scanned by Check Point Total Security Gateway. From denghui02@gmail.com Fri Dec 11 06:43: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 53A0728B797 for ; Fri, 11 Dec 2009 06:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 RHADmr97O1PV for ; Fri, 11 Dec 2009 06:43:40 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 54AFB3A6778 for ; Fri, 11 Dec 2009 06:43:40 -0800 (PST) Received: by pzk6 with SMTP id 6so677929pzk.29 for ; Fri, 11 Dec 2009 06:43:26 -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=TEZB6ByKNrWwiayGzb0Q5uIxJRdKfrc99HdjTf5yZzg=; b=Z1wdcD9YSq4QhvwwaZ04dxzZC7Red5kqSzGOKqhJuipmDdtjs7s8LWA0OKaeilhN1O Ds1i4w1KFwhVsSSkodMwRdwjwwRDzkEwoAIhiQg/jKv+lOcwCYLAD3gxloCCqYJN9UH/ Wf5KwJRhQenun4q00aYdoR1dy4LiRLC0Aw0vs= 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=TtyRRmbjryhr4EAJd4wjSWzCg/fTgSRkMHK9+yaFw+vpwUmloyN3GJRP7M5P+Afg3c lyElf44yM7iB2VeQ9zm6kyYZ5ZVtu+1c5C6FTsFb2ewPQaNnFwkN+081Jm7DQZpm6ke5 Hx9oPVStnXedq5cUvriDo+O2SwbNfiuvnJ0sY= MIME-Version: 1.0 Received: by 10.141.108.11 with SMTP id k11mr899900rvm.237.1260542606285; Fri, 11 Dec 2009 06:43:26 -0800 (PST) In-Reply-To: <-4242183742059278883@unknownmsgid> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <1d38a3350912090742q1976ffefo85ef5e0e5627ec0b@mail.gmail.com> <8104339512286448538@unknownmsgid> <1d38a3350912092129v4b4d6f77pc5114e72284ea8da@mail.gmail.com> <-4242183742059278883@unknownmsgid> Date: Fri, 11 Dec 2009 22:43:26 +0800 Message-ID: <1d38a3350912110643r50796cfahdfcd02889fc2bdbd@mail.gmail.com> From: Hui Deng To: Alper Yegin Content-Type: text/plain; charset=ISO-8859-1 Cc: ipsec@ietf.org Subject: Re: [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: Fri, 11 Dec 2009 14:43:41 -0000 Hi Alper, It seems that your argument goes to 3GPP only not this new work item, then I would suggest that you propose your solution to 3GPP HNB. Back to your questions, the scenarios is that some user need this IKE/IPsec or other don't need IPsec for the first, and also could be upgraded to need IKE/IPsec, I also found you didn't classify different access authenticaiton protocol. this is not a granularity issue, how could your proposal to support this scenario and migration scenarios simultaneously? thanks -Hui 2009/12/10 Alper Yegin : > Hi Hui, > >> I am not convinced why vendor need implement two security mechanism to >> one product, >> just because the second one need some market to use it. > > Unfortunately, protocol classification is more granular than that. > You don't identify one protocol as "security protocol" and make it serve all > security related purposes: access authentication, IPsec SA establishment, > transport-layer security, application-layer security, mobility signaling > security, etc. etc. Obviously, you need several distinct protocols for these > things. > > So, saying we have IKEv2, and we'll twist and turn it into some other > protocol for some other purpose may make sense when you are looking at > things from within the box (that implements IKEv2), but it does not make > sense when you are looking from outside the box (like from IETF > perspective). > > Your proposal is for turning IKEv2 into an EAP transport for generic network > access authentication. It requires taking some stuff out, twisting some > stuff, and adding stuff. It's technically doable, but "IETF" needs to be > convinced why it needs to reinvent PANA by taking IKEv2 as the baseline. > > Alper > > > > > > > > > > > > > > > > > > > > > > >> >> -Hui >> >> 2009/12/10 Alper Yegin : >> > Hi Hui, >> > >> > You named 3GPP as a consumer of this, acknowledged that 3GPP is not >> behind >> > all of the requirements, but you didn't respond to my question about >> which >> > one of the requirements are coming from 3GPP. >> > >> > >> > I object to this work, because it intends to create yet another >> network >> > access authentication protocol out of IKEv2. As you know, PANA is >> designed >> > for that purpose. IETF community needs to understand why PANA does >> not fit >> > the need, and why we need to turn IKEv2 into a general-purpose >> network >> > access authentication protocol. (IKE needs to get in line with the >> other >> > similar proposals, such as hacking up DHCP into access authentication >> > protocol, and even HTTP. I guess everyone has his/her favorite >> protocol to >> > hack.) >> > >> > Similar questions arise for the other motivations. "Liveness >> checking", and >> > "NAT detection".... Turning IKEv2 into a dedicated protocol for these >> > purposes is likely to grow IKE in many unintended directions. >> > >> > Alper >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> -----Original Message----- >> >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >> Behalf >> >> Of Hui Deng >> >> Sent: Wednesday, December 09, 2009 5:42 PM >> >> To: Yaron Sheffer >> >> Cc: ipsec@ietf.org >> >> Subject: Re: [IPsec] Proposed work item: Childless IKE SA >> >> >> >> would like to co-author, thanks >> >> >> >> -Hui >> >> >> >> 2009/11/30 Yaron Sheffer : >> >> > 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- >> >> childless-01.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 >> >> > >> >> _______________________________________________ >> >> IPsec mailing list >> >> IPsec@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ipsec >> > >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> > > > From smoonen@us.ibm.com Fri Dec 11 13:10: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 6B4D228C0D9; Fri, 11 Dec 2009 13:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.12 X-Spam-Level: X-Spam-Status: No, score=-4.12 tagged_above=-999 required=5 tests=[AWL=-1.522, 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 f6az-RzORSyc; Fri, 11 Dec 2009 13:10:06 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by core3.amsl.com (Postfix) with ESMTP id 928A33A657C; Fri, 11 Dec 2009 13:10:05 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e39.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nBBL3IuN030697; Fri, 11 Dec 2009 14:03:18 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id nBBL9eaa245410; Fri, 11 Dec 2009 14:09:42 -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 nBBL9SAW001085; Fri, 11 Dec 2009 14:09:28 -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 nBBL9Sl6001082; Fri, 11 Dec 2009 14:09:28 -0700 In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> To: Yaron Sheffer MIME-Version: 1.0 X-KeepSent: 2D047654:2EA3D020-85257689:006421DF; 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 12/11/2009 04:09:04 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 12/11/2009 04:09:04 PM, Serialize complete at 12/11/2009 04:09:04 PM, S/MIME Sign failed at 12/11/2009 04:09:04 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 12/11/2009 14:09:28, Serialize complete at 12/11/2009 14:09:28 Message-ID: Date: Fri, 11 Dec 2009 16:09:26 -0500 Content-Type: multipart/alternative; boundary="=_alternative 0074301285257689_=" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) 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, 11 Dec 2009 21:10:11 -0000 This is a multipart message in MIME format. --=_alternative 0074301285257689_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSdtIG5vdCBkb25lIG15IHJldmlldywgYnV0IGhlcmUgYXJlIHRoZSBvYnNlcnZhdGlvbnMgLS0g YWxsIG1pbm9yIC0tIHRoYXQgDQpJJ3ZlIGdvdCBzbyBmYXI6DQoNClNlY3Rpb24gMS4yLCBwYXJh Z3JhcGggMiAtLSAidGhlIGlkZW50aXRpZXMgYXJlIGhpZGRlbiBmcm9tIA0KZWF2ZXNkcm9wcGVy cyIuICBJcyBpdCB3b3J0aCBub3RpbmcgdGhhdCBhIG1hbi1pbi10aGUtbWlkZGxlIGNvdWxkIA0K aW50cnVzaXZlbHkgZGlzY292ZXIgdGhlIGluaXRpYXRvcidzIGlkZW50aXR5Pw0KDQpTZWN0aW9u IDEuMy4xIC0tICJXaGVuIGFuIElLRSBTQSBpcyBub3QgY3JlYXRlZCwgdGhlIGVycm9yIG1lc3Nh Z2UgcmV0dXJuIA0KU0hPVUxEIE5PVCBiZSBlbmNyeXB0ZWQgYmVjYXVzZSB0aGUgb3RoZXIgcGFy dHkgd2lsbCBub3QgYmUgYWJsZSB0byANCmF1dGhlbnRpY2F0ZSB0aGF0IG1lc3NhZ2UuIiAgRmly c3QsIHRoaXMgc2VlbXMgb3V0IG9mIHBsYWNlLCBzaW5jZSB0aGlzIA0Kc2VjdGlvbiB0YWxrcyBh Ym91dCBDUkVBVEVfQ0hJTERfU0EgZm9yIENoaWxkIFNBcy4gIFNlY29uZCwgYXNzdW1pbmcgdGhp cyANCmlzIHRhbGtpbmcgYWJvdXQgSUtFX0FVVEgsIEkgdGhpbmsgdGhpcyBjb250cmFkaWN0cyB3 aGF0IHdlJ2QgZWFybGllciANCmFncmVlZCB0byAtLSBhbmQgd2hhdCBzZWN0aW9uIDEuMiBub3cg c2VlbXMgdG8gc3VnZ2VzdCAtLSBpbiB0aGF0IHRoZSANCklLRV9BVVRIIHJlc3BvbnNlIHNob3Vs ZCBub3JtYWxseSBiZSBlbmNyeXB0ZWQgYW5kIE1BQ2VkIGV2ZW4gb24gZmFpbHVyZS4NCg0KU2Vj dGlvbiAxLjMuMiAtLSAiTmV3IGluaXRpYXRvciBhbmQgcmVzcG9uZGVyIFNQSXMgYXJlIHN1cHBs aWVkIGluIHRoZSBTUEkgDQpmaWVsZHMgb2YgdGhlIFNBIHBheWxvYWQuIiAgSSB0aGluayB3ZSBz aG91bGQgY2hhbmdlIHRoaXMgdG8gcmVhZCAiQSBuZXcgDQppbml0aWF0b3IgU1BJIGlzIHN1cHBs aWVkIC4uLiIgIFBlcmhhcHMgd2Ugc2hvdWxkIGFkZCBzb21ldGhpbmcgYWJvdXQgdGhlIA0KcmVz cG9uZGVyIGNob29zaW5nIGFuIFNQSSB0byB0aGUgcGFyYWdyYXBoIGJlZ2lubmluZyAiVGhlIHJl c3BvbmRlciANCnJlcGxpZXMgLi4uIg0KDQpTZWN0aW9uIDIuOCAtLSBOb3RlIHRoYXQsIHdoZW4g cmVrZXlpbmcsIHRoZSBuZXcgQ2hpbGQgU0EgU0hPVUxEIE5PVCBoYXZlIA0KZGlmZmVyZW50IHRy YWZmaWMgc2VsZWN0b3JzIGFuZCBhbGdvcml0aG1zIHRoYW4gdGhlIG9sZCBvbmUuIiAgVGhpcyAN CnNlbnRlbmNlIGFwcGVhcnMgd2l0aGluIGEgcGFyYWdyYXBoIHRoYXQgaXMgb3RoZXJ3aXNlIGVu dGlyZWx5IGFib3V0IA0KcmVrZXlpbmcgSUtFIFNBcy4gIEkgdGhpbmsgaXQgc2hvdWxkIHByb2Jh Ymx5IGJlIG1vdmVkIHRvIHRoZSBlbmQgb2YgdGhlIA0KcHJlY2VkaW5nIHBhcmFncmFwaC4NCg0K U2VjdGlvbiAyLjIxLjIgLS0gV2UgbmVlZCB0byByZW1lbWJlciB0byByZW1vdmUgdGhlICJOT1RF IEZPUiBXRyANCkRJU0NVU1NJT04iLg0KDQoNClNjb3R0IE1vb25lbiAoc21vb25lbkB1cy5pYm0u Y29tKQ0Kei9PUyBDb21tdW5pY2F0aW9ucyBTZXJ2ZXIgVENQL0lQIERldmVsb3BtZW50DQpodHRw Oi8vd3d3LmxpbmtlZGluLmNvbS9pbi9zbW9vbmVuDQoNCg0KDQpGcm9tOg0KWWFyb24gU2hlZmZl ciA8eWFyb25mQGNoZWNrcG9pbnQuY29tPg0KVG86DQoiaXBzZWNAaWV0Zi5vcmciIDxpcHNlY0Bp ZXRmLm9yZz4NCkRhdGU6DQoxMi8xMC8yMDA5IDA0OjA1IEFNDQpTdWJqZWN0Og0KW0lQc2VjXSBX b3JraW5nIEdyb3VwIExDOiBkcmFmdC1pZXRmLWlwc2VjbWUtaWtldjJiaXMtMDYgKHllcywgSUtF djItYmlzISkNCg0KDQoNClRoaXMgaXMgdG8gYmVnaW4gYSA0IHdlZWsgd29ya2luZyBncm91cCBs YXN0IGNhbGwgZm9yIA0KZHJhZnQtaWV0Zi1pcHNlY21lLWlrZXYyYmlzLTA2LiBUaGUgdGFyZ2V0 IHN0YXR1cyBmb3IgdGhpcyBkb2N1bWVudCBpcyANClByb3Bvc2VkIFN0YW5kYXJkLCBvYnNvbGV0 aW5nIFJGQyA0MzA2IGFuZCBSRkMgNDcxOC4NCiANClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMg dG8gdGhlIGlwc2VjIGxpc3QgYnkgSmFuLiA1LCAyMDEwLCBhcyBmb2xsb3ctdXBzIA0KdG8gdGhp cyBtZXNzYWdlLg0KIA0KVGhpcyBpcyBhIGxhcmdlIGRvY3VtZW50LCBhbmQgYXJndWFibHkgdGhl IG1vc3QgaW1wb3J0YW50IGRvY3VtZW50IHRoaXMgV0cgDQppcyBlbnRydXN0ZWQgd2l0aC4gVGhl IExDIHBlcmlvZCBpcyBsb25nZXIgdGhhbiB1c3VhbCBidXQgd2lsbCBpbmNsdWRlIA0KdmFjYXRp b24gdGltZSBmb3IgbW9zdCBvZiB1cy4gTmV2ZXJ0aGVsZXNzLCBwbGVhc2UgbWFrZSBhbiBlZmZv cnQgdG8gDQpyZXZpZXcgdGhlIGVudGlyZSBkb2N1bWVudCwgb3IgYXQgbGVhc3QgbGFyZ2UgcG9y dGlvbnMgb2YgaXQuIEZlZWwgZnJlZSB0byANCnBvc3QgbXVsdGlwbGUgcGFydGlhbCByZXZpZXdz Lg0KIA0KSW4gdGhpcyBwYXJ0aWN1bGFyIGNhc2UsIHdlIGFyZSBzdGFydGluZyB0aGUgcmV2aWV3 IHdpdGggYSBmZXcgb3BlbiBpc3N1ZXMNCi4gV2Ugd2lsbCBtYWtlIGFuIGVmZm9ydCB0byBjbG9z ZSB0aGVtIGR1cmluZyB0aGUgV0cgTEMgcGVyaW9kLg0KIA0KQXMgYSByZW1pbmRlciByZWdhcmRp bmcgdGhlIGRvY3VtZW504oCZcyBzY29wZSAoYW5kIG91ciBjb25zdHJhaW50cyB3aGlsZSANCnJl dmlld2luZyBpdCksIEkgd2lsbCBxdW90ZSBmcm9tIG15IG1haWwgb2YgQXVnLiAyMDA4Og0KIA0K R2VuZXJhbDogVGhlIGdvYWwgb2YgdGhlIElLRXYyIGJpcyBkb2N1bWVudCBpcyB0byBjbGFyaWZ5 IHRoZSBwcm90b2NvbC4gDQpUaGUgZ29hbCBpcyBub3QgdG8gZXh0ZW5kIGl0LiBTcGVjaWZpY2Fs bHk6DQogDQoqIFRoZSBkb2N1bWVudCB3aWxsIGNvbWJpbmUgUkZDIDQzMDYgKElLRXYyKSBhbmQg UkZDIDQ3MTggKElLRXYyIA0KY2xhcmlmaWNhdGlvbnMpLCBidXQgbm8gb3RoZXIgUkZDcy4NCiog VGhlIGRvY3VtZW50IHdpbGwgYWRkIGNsYXJpZmljYXRpb25zIGJhc2VkIG9uIHRoZSBjb21tdW5p dHkncyBkZXBsb3ltZW50IA0KZXhwZXJpZW5jZS4NCiogSXQgaXMgT0sgdG8gY29ycmVjdCBtaW5v ciB0ZWNobmljYWwgZXJyb3JzIGFuZCBjb250cmFkaWN0aW9ucyBpbiB0aGUgDQpzb3VyY2UgZG9j dW1lbnRzLiBBbnkgc3VjaCBjb3JyZWN0aW9ucyB3aWxsIGJlIHBvaW50ZWQgb3V0IGV4cGxpY2l0 bHkgLSANCnByZWZlcmFibHkgaW4gYW4gYXBwZW5kaXggKHNvIHRoYXQgcGVvcGxlIHVzaW5nIHRo ZSBvbGQgZG9jdW1lbnRzIGNhbiBzY2FuIA0KaXQgdG8gZGlzY292ZXIgcHJvYmxlbSBhcmVhcyku DQoqIFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZGQgYW55ICJuaWNlIHRvIGhhdmUiIGV4dGVuc2lv bnMsIG5vIG1hdHRlciBob3cgDQptdWNoIHRlY2huaWNhbCBzZW5zZSB0aGV5IG1ha2UuDQogDQpQ bGVhc2UgY2xlYXJseSBpbmRpY2F0ZSB0aGUgcG9zaXRpb24gb2YgYW55IGlzc3VlIGluIHRoZSBJ bnRlcm5ldCBEcmFmdCwgDQphbmQgaWYgcG9zc2libGUgcHJvdmlkZSBhbHRlcm5hdGl2ZSB0ZXh0 LiBQbGVhc2UgYWxzbyBpbmRpY2F0ZSB0aGUgbmF0dXJlIA0Kb3Igc2V2ZXJpdHkgb2YgdGhlIGVy cm9yIG9yIGNvcnJlY3Rpb24sIGUuZy4gbWFqb3IgdGVjaG5pY2FsLCBtaW5vciANCnRlY2huaWNh bCwgbml0LCBzbyB0aGF0IHdlIGNhbiBxdWlja2x5IGp1ZGdlIHRoZSBleHRlbnQgb2YgcHJvYmxl bXMgd2l0aCANCnRoZSBkb2N1bWVudC4NCiANClRoZSBkb2N1bWVudCBjYW4gYmUgYWNjZXNzZWQg aGVyZToNCiANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBzZWNtZS1p a2V2MmJpcy0wNg0KIA0KVGhhbmtzLA0KICAgICAgWWFyb25fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KSVBzZWMgbWFpbGluZyBsaXN0DQpJUHNlY0BpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0KDQoNCg0K --=_alternative 0074301285257689_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkknbSBub3QgZG9uZSBteSByZXZp ZXcsIGJ1dCBoZXJlIGFyZQ0KdGhlIG9ic2VydmF0aW9ucyAtLSBhbGwgbWlub3IgLS0gdGhhdCBJ J3ZlIGdvdCBzbyBmYXI6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5TZWN0aW9uIDEuMiwgcGFyYWdyYXBoIDIgLS0gJnF1b3Q7dGhlDQppZGVudGl0aWVz IGFyZSBoaWRkZW4gZnJvbSBlYXZlc2Ryb3BwZXJzJnF1b3Q7LiAmbmJzcDtJcyBpdCB3b3J0aCBu b3RpbmcNCnRoYXQgYSBtYW4taW4tdGhlLW1pZGRsZSBjb3VsZCBpbnRydXNpdmVseSBkaXNjb3Zl ciB0aGUgaW5pdGlhdG9yJ3MgaWRlbnRpdHk/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5TZWN0aW9uIDEuMy4xIC0tICZxdW90O1doZW4gYW4gSUtFIFNB DQppcyBub3QgY3JlYXRlZCwgdGhlIGVycm9yIG1lc3NhZ2UgcmV0dXJuIFNIT1VMRCBOT1QgYmUg ZW5jcnlwdGVkIGJlY2F1c2UNCnRoZSBvdGhlciBwYXJ0eSB3aWxsIG5vdCBiZSBhYmxlIHRvIGF1 dGhlbnRpY2F0ZSB0aGF0IG1lc3NhZ2UuJnF1b3Q7ICZuYnNwO0ZpcnN0LA0KdGhpcyBzZWVtcyBv dXQgb2YgcGxhY2UsIHNpbmNlIHRoaXMgc2VjdGlvbiB0YWxrcyBhYm91dCBDUkVBVEVfQ0hJTERf U0ENCmZvciBDaGlsZCBTQXMuICZuYnNwO1NlY29uZCwgYXNzdW1pbmcgdGhpcyBpcyB0YWxraW5n IGFib3V0IElLRV9BVVRILCBJDQp0aGluayB0aGlzIGNvbnRyYWRpY3RzIHdoYXQgd2UnZCBlYXJs aWVyIGFncmVlZCB0byAtLSBhbmQgd2hhdCBzZWN0aW9uDQoxLjIgbm93IHNlZW1zIHRvIHN1Z2dl c3QgLS0gaW4gdGhhdCB0aGUgSUtFX0FVVEggcmVzcG9uc2Ugc2hvdWxkIG5vcm1hbGx5DQpiZSBl bmNyeXB0ZWQgYW5kIE1BQ2VkIGV2ZW4gb24gZmFpbHVyZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNlY3Rpb24gMS4zLjIgLS0gJnF1b3Q7TmV3IGlu aXRpYXRvcg0KYW5kIHJlc3BvbmRlciBTUElzIGFyZSBzdXBwbGllZCBpbiB0aGUgU1BJIGZpZWxk cyBvZiB0aGUgU0EgcGF5bG9hZC4mcXVvdDsNCiZuYnNwO0kgdGhpbmsgd2Ugc2hvdWxkIGNoYW5n ZSB0aGlzIHRvIHJlYWQgJnF1b3Q7QSBuZXcgaW5pdGlhdG9yIFNQSSBpcw0Kc3VwcGxpZWQgLi4u JnF1b3Q7ICZuYnNwO1BlcmhhcHMgd2Ugc2hvdWxkIGFkZCBzb21ldGhpbmcgYWJvdXQgdGhlIHJl c3BvbmRlcg0KY2hvb3NpbmcgYW4gU1BJIHRvIHRoZSBwYXJhZ3JhcGggYmVnaW5uaW5nICZxdW90 O1RoZSByZXNwb25kZXIgcmVwbGllcw0KLi4uJnF1b3Q7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TZWN0aW9uIDIuOCAtLSBOb3RlIHRoYXQsIHdoZW4g cmVrZXlpbmcsDQp0aGUgbmV3IENoaWxkIFNBIFNIT1VMRCBOT1QgaGF2ZSBkaWZmZXJlbnQgdHJh ZmZpYyBzZWxlY3RvcnMgYW5kIGFsZ29yaXRobXMNCnRoYW4gdGhlIG9sZCBvbmUuJnF1b3Q7ICZu YnNwO1RoaXMgc2VudGVuY2UgYXBwZWFycyB3aXRoaW4gYSBwYXJhZ3JhcGgNCnRoYXQgaXMgb3Ro ZXJ3aXNlIGVudGlyZWx5IGFib3V0IHJla2V5aW5nIElLRSBTQXMuICZuYnNwO0kgdGhpbmsgaXQg c2hvdWxkDQpwcm9iYWJseSBiZSBtb3ZlZCB0byB0aGUgZW5kIG9mIHRoZSBwcmVjZWRpbmcgcGFy YWdyYXBoLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ U2VjdGlvbiAyLjIxLjIgLS0gV2UgbmVlZCB0byByZW1lbWJlcg0KdG8gcmVtb3ZlIHRoZSAmcXVv dDtOT1RFIEZPUiBXRyBESVNDVVNTSU9OJnF1b3Q7LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KU2NvdHQgTW9vbmVuIChzbW9vbmVuQHVzLmli bS5jb20pPGJyPg0Kei9PUyBDb21tdW5pY2F0aW9ucyBTZXJ2ZXIgVENQL0lQIERldmVsb3BtZW50 PGJyPg0KPC9mb250PjxhIGhyZWY9aHR0cDovL3d3dy5saW5rZWRpbi5jb20vaW4vc21vb25lbj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aHR0cDovL3d3dy5saW5rZWRpbi5jb20vaW4v c21vb25lbjwvZm9udD48L2E+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNh bnMtc2VyaWYiPkZyb206PC9mb250Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5ZYXJvbiBTaGVmZmVyICZsdDt5YXJvbmZAY2hlY2twb2ludC5jb20mZ3Q7PC9mb250Pg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1z ZXJpZiI+VG86PC9mb250Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVv dDtpcHNlY0BpZXRmLm9yZyZxdW90OyAmbHQ7aXBzZWNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1z ZXJpZiI+RGF0ZTo8L2ZvbnQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjEy LzEwLzIwMDkgMDQ6MDUgQU08L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD48Zm9udCBzaXpl PTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5TdWJqZWN0OjwvZm9udD4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W0lQc2VjXSBXb3JraW5nIEdyb3VwIExDOiBk cmFmdC1pZXRmLWlwc2VjbWUtaWtldjJiaXMtMDYNCih5ZXMsICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO0lLRXYyLWJpcyEpPC9mb250PjwvdGFibGU+DQo8YnI+DQo8aHIgbm9zaGFkZT4NCjxi cj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlRoaXMgaXMgdG8g YmVnaW4gYSA0IHdlZWsgd29ya2luZyBncm91cA0KbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLWlw c2VjbWUtaWtldjJiaXMtMDYuIFRoZSB0YXJnZXQgc3RhdHVzIGZvciB0aGlzDQpkb2N1bWVudCBp cyBQcm9wb3NlZCBTdGFuZGFyZCwgb2Jzb2xldGluZyBSRkMgNDMwNiBhbmQgUkZDIDQ3MTguPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+UGxlYXNlIHNlbmQgeW91ciBjb21t ZW50cyB0byB0aGUgaXBzZWMNCmxpc3QgYnkgSmFuLiA1LCAyMDEwLCBhcyBmb2xsb3ctdXBzIHRv IHRoaXMgbWVzc2FnZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5UaGlz IGlzIGEgbGFyZ2UgZG9jdW1lbnQsIGFuZCBhcmd1YWJseQ0KdGhlIG1vc3QgaW1wb3J0YW50IGRv Y3VtZW50IHRoaXMgV0cgaXMgZW50cnVzdGVkIHdpdGguIFRoZSBMQyBwZXJpb2QgaXMNCmxvbmdl ciB0aGFuIHVzdWFsIGJ1dCB3aWxsIGluY2x1ZGUgdmFjYXRpb24gdGltZSBmb3IgbW9zdCBvZiB1 cy4gTmV2ZXJ0aGVsZXNzLA0KcGxlYXNlIG1ha2UgYW4gZWZmb3J0IHRvIHJldmlldyB0aGUgZW50 aXJlIGRvY3VtZW50LCBvciBhdCBsZWFzdCBsYXJnZQ0KcG9ydGlvbnMgb2YgaXQuIEZlZWwgZnJl ZSB0byBwb3N0IG11bHRpcGxlIHBhcnRpYWwgcmV2aWV3cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij5JbiB0aGlzIHBhcnRpY3VsYXIgY2FzZSwgd2UgYXJlIHN0YXJ0aW5n DQp0aGUgcmV2aWV3IHdpdGggYSBmZXcgPC9mb250PjxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xz LmlldGYub3JnL3dnL2lwc2VjbWUvdHJhYy9xdWVyeT9zdGF0dXM9bmV3JmFtcDtzdGF0dXM9YXNz aWduZWQmYW1wO3N0YXR1cz1yZW9wZW5lZCZhbXA7Y29tcG9uZW50PWRyYWZ0LWlldGYtaXBzZWNt ZS1pa2V2MmJpcyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1 Pm9wZW4NCmlzc3VlczwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+LiBXZSB3aWxsIG1ha2UgYW4gZWZmb3J0DQp0byBjbG9zZSB0aGVtIGR1cmluZyB0aGUgV0cg TEMgcGVyaW9kLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPkFzIGEgcmVt aW5kZXIgcmVnYXJkaW5nIHRoZSBkb2N1bWVudOKAmXMNCnNjb3BlIChhbmQgb3VyIGNvbnN0cmFp bnRzIHdoaWxlIHJldmlld2luZyBpdCksIEkgd2lsbCBxdW90ZSBmcm9tIG15IG1haWwNCm9mIEF1 Zy4gMjAwODo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5HZW5lcmFsOiBU aGUgZ29hbCBvZiB0aGUgSUtFdjIgYmlzDQpkb2N1bWVudCBpcyB0byBjbGFyaWZ5IHRoZSBwcm90 b2NvbC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlRoZSBnb2FsIGlzIG5vdCB0byBleHRlbmQgaXQu IFNwZWNpZmljYWxseTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4qIFRo ZSBkb2N1bWVudCB3aWxsIGNvbWJpbmUgUkZDIDQzMDYNCihJS0V2MikgYW5kIFJGQyA0NzE4IChJ S0V2MjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPiA8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5jbGFyaWZpY2F0aW9ucyksDQpidXQgbm8gb3RoZXIg UkZDcy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4qIFRoZSBk b2N1bWVudCB3aWxsIGFkZCBjbGFyaWZpY2F0aW9ucw0KYmFzZWQgb24gdGhlIGNvbW11bml0eSdz PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+IDwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPmRlcGxveW1lbnQNCmV4cGVyaWVuY2UuPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+KiBJdCBpcyBPSyB0byBjb3JyZWN0IG1p bm9yIHRlY2huaWNhbA0KZXJyb3JzIGFuZCBjb250cmFkaWN0aW9ucyBpbiB0aGU8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPnNvdXJjZSBkb2N1bWVudHMuIEFueSBzdWNoIGNvcnJlY3Rpb25zDQp3aWxs IGJlIHBvaW50ZWQgb3V0IGV4cGxpY2l0bHkgLTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291 cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+cHJlZmVy YWJseSBpbiBhbiBhcHBlbmRpeCAoc28gdGhhdA0KcGVvcGxlIHVzaW5nIHRoZSBvbGQgZG9jdW1l bnRzIGNhbjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+c2NhbiBpdCB0byBkaXNjb3ZlciBwcm9ibGVt IGFyZWFzKS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4qIFRo ZSBkb2N1bWVudCB3aWxsIG5vdCBhZGQgYW55ICZxdW90O25pY2UNCnRvIGhhdmUmcXVvdDsgZXh0 ZW5zaW9ucywgbm8gbWF0dGVyIGhvdzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBO ZXciPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+bXVjaCB0ZWNobmlj YWwgc2Vuc2UgdGhleSBtYWtlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PlBsZWFzZSBjbGVhcmx5IGluZGljYXRlIHRoZSBwb3NpdGlvbg0Kb2YgYW55IGlzc3VlIGluIHRo ZSBJbnRlcm5ldCBEcmFmdCwgYW5kIGlmIHBvc3NpYmxlIHByb3ZpZGUgYWx0ZXJuYXRpdmUNCnRl eHQuIFBsZWFzZSBhbHNvIGluZGljYXRlIHRoZSBuYXR1cmUgb3Igc2V2ZXJpdHkgb2YgdGhlIGVy cm9yIG9yIGNvcnJlY3Rpb24sDQplLmcuIG1ham9yIHRlY2huaWNhbCwgbWlub3IgdGVjaG5pY2Fs LCBuaXQsIHNvIHRoYXQgd2UgY2FuIHF1aWNrbHkganVkZ2UNCnRoZSBleHRlbnQgb2YgcHJvYmxl bXMgd2l0aCB0aGUgZG9jdW1lbnQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+VGhlIGRvY3VtZW50IGNhbiBiZSBhY2Nlc3NlZCBoZXJlOjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvZm9udD4NCjxicj48YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwc2VjbWUtaWtldjJiaXMtMDYiPjxm b250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+aHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHNlY21lLWlrZXYyYmlzLTA2PC91PjwvZm9u dD48L2E+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5UaGFua3MsPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgWWFy b248L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCklQc2VjIG1haWxpbmcgbGlzdDxicj4NCklQc2VjQGlldGYu b3JnPGJyPg0KPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwc2VjPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHNlYzwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4N CjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPg0K --=_alternative 0074301285257689_=-- From alper.yegin@yegin.org Fri Dec 11 14:30: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 2494D3A6807 for ; Fri, 11 Dec 2009 14:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.011 X-Spam-Level: X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 A4qiA8R8Pjx0 for ; Fri, 11 Dec 2009 14:30:10 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 592F13A68C6 for ; Fri, 11 Dec 2009 14:30:09 -0800 (PST) Received: from LENOVO (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MgdCx-1NfzMv0Lzz-00Nsqu; Fri, 11 Dec 2009 17:29:55 -0500 From: "Alper Yegin" To: "'Hui Deng'" References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <1d38a3350912090742q1976ffefo85ef5e0e5627ec0b@mail.gmail.com> <8104339512286448538@unknownmsgid> <1d38a3350912092129v4b4d6f77pc5114e72284ea8da@mail.gmail.com> <-4242183742059278883@unknownmsgid> <1d38a3350912110643r50796cfahdfcd02889fc2bdbd@mail.gmail.com> In-Reply-To: <1d38a3350912110643r50796cfahdfcd02889fc2bdbd@mail.gmail.com> Date: Sat, 12 Dec 2009 00:29:45 +0200 Message-ID: <007301ca7ab1$7608aac0$621a0040$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp6cExj8J8EzGs/Svu1gDlzdVRCSQAQA2NQ Content-Language: en-us X-Provags-ID: V01U2FsdGVkX18D2SdLMFD1eTq+xVyqog5Ygg92TqbuDmJc1ms kpKAz+gfdREf+ZN9PnQulefTOSWF1uB4iU2lVaE7TVf4ySghin czNnsqotQHj/Hy5c1YlIQ== Cc: ipsec@ietf.org Subject: Re: [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: Fri, 11 Dec 2009 22:30:12 -0000 Hi Hui, > Hi Alper, > > It seems that your argument goes to 3GPP only not this new work item, > then I would suggest that you propose your solution to 3GPP HNB. We are having this discussion in IETF right now. So, there is no point in telling us to go elsewhere. If the discussions is here, it is here. > Back to your questions, the scenarios is that some user need this > IKE/IPsec > or other don't need IPsec for the first, and also could be upgraded to > need IKE/IPsec, Is this a real scenario? I'd like to understand how a user moves from a non-IPsec to IPsec. > I also found you didn't classify different access authenticaiton > protocol. Could you please elaborate on what exactly you are asking about? > this is not a granularity issue, how could your proposal to support > this scenario and migration scenarios simultaneously? If you can explain to us what migration scenarios you have, we can discuss them. Thanks. Alper > > thanks > > -Hui > > 2009/12/10 Alper Yegin : > > Hi Hui, > > > >> I am not convinced why vendor need implement two security mechanism > to > >> one product, > >> just because the second one need some market to use it. > > > > Unfortunately, protocol classification is more granular than that. > > You don't identify one protocol as "security protocol" and make it > serve all > > security related purposes: access authentication, IPsec SA > establishment, > > transport-layer security, application-layer security, mobility > signaling > > security, etc. etc. Obviously, you need several distinct protocols > for these > > things. > > > > So, saying we have IKEv2, and we'll twist and turn it into some other > > protocol for some other purpose may make sense when you are looking > at > > things from within the box (that implements IKEv2), but it does not > make > > sense when you are looking from outside the box (like from IETF > > perspective). > > > > Your proposal is for turning IKEv2 into an EAP transport for generic > network > > access authentication. It requires taking some stuff out, twisting > some > > stuff, and adding stuff. It's technically doable, but "IETF" needs to > be > > convinced why it needs to reinvent PANA by taking IKEv2 as the > baseline. > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > >> -Hui > >> > >> 2009/12/10 Alper Yegin : > >> > Hi Hui, > >> > > >> > You named 3GPP as a consumer of this, acknowledged that 3GPP is > not > >> behind > >> > all of the requirements, but you didn't respond to my question > about > >> which > >> > one of the requirements are coming from 3GPP. > >> > > >> > > >> > I object to this work, because it intends to create yet another > >> network > >> > access authentication protocol out of IKEv2. As you know, PANA is > >> designed > >> > for that purpose. IETF community needs to understand why PANA does > >> not fit > >> > the need, and why we need to turn IKEv2 into a general-purpose > >> network > >> > access authentication protocol. (IKE needs to get in line with the > >> other > >> > similar proposals, such as hacking up DHCP into access > authentication > >> > protocol, and even HTTP. I guess everyone has his/her favorite > >> protocol to > >> > hack.) > >> > > >> > Similar questions arise for the other motivations. "Liveness > >> checking", and > >> > "NAT detection".... Turning IKEv2 into a dedicated protocol for > these > >> > purposes is likely to grow IKE in many unintended directions. > >> > > >> > Alper > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > >> Behalf > >> >> Of Hui Deng > >> >> Sent: Wednesday, December 09, 2009 5:42 PM > >> >> To: Yaron Sheffer > >> >> Cc: ipsec@ietf.org > >> >> Subject: Re: [IPsec] Proposed work item: Childless IKE SA > >> >> > >> >> would like to co-author, thanks > >> >> > >> >> -Hui > >> >> > >> >> 2009/11/30 Yaron Sheffer : > >> >> > 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- > >> >> childless-01.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 > >> >> > > >> >> _______________________________________________ > >> >> IPsec mailing list > >> >> IPsec@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/ipsec > >> > > >> > _______________________________________________ > >> > IPsec mailing list > >> > IPsec@ietf.org > >> > https://www.ietf.org/mailman/listinfo/ipsec > >> > > > > > From paul.hoffman@vpnc.org Fri Dec 11 15:35:14 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 177533A657C for ; Fri, 11 Dec 2009 15:35:14 -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 VtIY484Qba4V for ; Fri, 11 Dec 2009 15:35:13 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 4748A3A68AB for ; Fri, 11 Dec 2009 15:35:13 -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 nBBNZ0Ym089759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 11 Dec 2009 16:35:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 11 Dec 2009 15:34:59 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) 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, 11 Dec 2009 23:35:14 -0000 >Section 1.2, paragraph 2 -- "the identities are hidden from eavesdroppers". Is it worth noting that a man-in-the-middle could intrusively discover the initiator's identity? Added: (A man-in-the-middle who cannot complete the IKE_AUTH exchange can nonetheless see the identity of the initiator.) >Section 1.3.1 -- "When an IKE SA is not created, the error message return SHOULD NOT be encrypted because the other party will not be able to authenticate that message." First, this seems out of place, since this section talks about CREATE_CHILD_SA for Child SAs. Second, assuming this is talking about IKE_AUTH, I think this contradicts what we'd earlier agreed to -- and what section 1.2 now seems to suggest -- in that the IKE_AUTH response should normally be encrypted and MACed even on failure. Opening a new issue about this. >Section 1.3.2 -- "New initiator and responder SPIs are supplied in the SPI fields of the SA payload." I think we should change this to read "A new initiator SPI is supplied ..." Perhaps we should add something about the responder choosing an SPI to the paragraph beginning "The responder replies ..." In 1.3.2, changed "New initiator and responder SPIs are supplied in the SPI fields of the SA payload." to "A new initiator SPI is supplied in the SPI field of the SA payload." Also added "A new responder SPI is supplied in the SPI field of the SA payload." a few paragraphs down. >Section 2.8 -- Note that, when rekeying, the new Child SA SHOULD NOT have different traffic selectors and algorithms than the old one." This sentence appears within a paragraph that is otherwise entirely about rekeying IKE SAs. I think it should probably be moved to the end of the preceding paragraph. Good catch. >Section 2.21.2 -- We need to remember to remove the "NOTE FOR WG DISCUSSION". Done. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Fri Dec 11 15:46: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 B7FE43A6883 for ; Fri, 11 Dec 2009 15:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.967 X-Spam-Level: X-Spam-Status: No, score=-5.967 tagged_above=-999 required=5 tests=[AWL=0.079, 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 UB+V2zs0zDKR for ; Fri, 11 Dec 2009 15:46: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 01E373A67F6 for ; Fri, 11 Dec 2009 15:46:37 -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 nBBNkOOf090211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 11 Dec 2009 16:46:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 11 Dec 2009 15:46:23 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] #127: Should IKE_AUTH errors be encrypted? 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, 11 Dec 2009 23:46:38 -0000 Section 1.3.1 says "When an IKE SA is not created, the error message return SHOULD NOT be encrypted because the other party will not be able to authenticate that message." First, this seems out of place, since this section talks about CREATE_CHILD_SA for Child SAs. Second, assuming this is talking about IKE_AUTH, I think this contradicts what we'd earlier agreed to -- and what section 1.2 now seems to suggest -- in that the IKE_AUTH response should normally be encrypted and MACed even on failure. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Sat Dec 12 12:13: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 B57603A68D8 for ; Sat, 12 Dec 2009 12:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.039 X-Spam-Level: X-Spam-Status: No, score=-5.039 tagged_above=-999 required=5 tests=[AWL=-0.852, BAYES_20=-0.74, 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 RJ3Psu7-7VzR for ; Sat, 12 Dec 2009 12:13: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 C8C1B3A68D1 for ; Sat, 12 Dec 2009 12:13:18 -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 nBCKD4KI065611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 12 Dec 2009 13:13:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sat, 12 Dec 2009 12:13:03 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] #127: Should IKE_AUTH errors be encrypted? 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, 12 Dec 2009 20:13:21 -0000 At 3:46 PM -0800 12/11/09, Paul Hoffman wrote: >Section 1.3.1 says "When an IKE SA is not created, the error message return SHOULD NOT be encrypted because the other party will not be able to authenticate that message." First, this seems out of place, since this section talks about CREATE_CHILD_SA for Child SAs. Second, assuming this is talking about IKE_AUTH, I think this contradicts what we'd earlier agreed to -- and what section 1.2 now seems to suggest -- in that the IKE_AUTH response should normally be encrypted and MACed even on failure. Also note that the text in 2.21.2 (which has been mostly unchanged during the editing process) strongly indicates that the error is sent encrypted. --Paul Hoffman, Director --VPN Consortium From tamura.toshihiko@lab.ntt.co.jp Sun Dec 13 17:55: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 B364B3A67D8 for ; Sun, 13 Dec 2009 17:55:36 -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_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 OBG+gU6J5xL5 for ; Sun, 13 Dec 2009 17:55:35 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id B7B3D3A676A for ; Sun, 13 Dec 2009 17:55:35 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.14.3/8.14.3) with ESMTP id nBE1tLLi027829 for ; Mon, 14 Dec 2009 10:55:21 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id B13CD6CD3 for ; Mon, 14 Dec 2009 10:55:21 +0900 (JST) Received: from iml.m.ecl.ntt.co.jp (iml0.m.ecl.ntt.co.jp [129.60.5.150]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 9C0576CD1 for ; Mon, 14 Dec 2009 10:55:21 +0900 (JST) Received: from [127.0.0.1] (tamura-dell.nslab.ecl.ntt.co.jp [129.60.11.10]) by iml.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id nBE1tLaD007440 for ; Mon, 14 Dec 2009 10:55:21 +0900 (JST) Date: Mon, 14 Dec 2009 10:55:21 +0900 From: Toshihiko Tamura To: ipsec@ietf.org In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> Message-Id: <20091214102644.0234.DECD93FF@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.48.02 [ja] Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) 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, 14 Dec 2009 01:55:36 -0000 Hi, I want to check one point. At the last paragraph in Section 2.5, there is a mention of refering the figures in Section 2. Does it mean we should refer all fighres in Section 2? Or does it mistake section 2 for section 1? --------- 2.5. Version Numbers and Forward Compatibility /snip/ Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations SHOULD send the payloads defined in this specification in the order shown in the figures in Section 2; implementations MUST NOT reject as invalid a message with those payloads in any other order. --------- Regards, Toshihiko Tamura > This is to begin a 4 week working group last call for draft-ietf-ipsecme-ikev2bis-06. The target status for this document is Proposed Standard, obsoleting RFC 4306 and RFC 4718. > > Please send your comments to the ipsec list by Jan. 5, 2010, as follow-ups to this message. > > This is a large document, and arguably the most important document this WG is entrusted with. The LC period is longer than usual but will include vacation time for most of us. Nevertheless, please make an effort to review the entire document, or at least large portions of it. Feel free to post multiple partial reviews. > > In this particular case, we are starting the review with a few open issues. We will make an effort to close them during the WG LC period. > > As a reminder regarding the document's scope (and our constraints while reviewing it), I will quote from my mail of Aug. 2008: > > General: The goal of the IKEv2 bis document is to clarify the protocol. The goal is not to extend it. Specifically: > > > * The document will combine RFC 4306 (IKEv2) and RFC 4718 (IKEv2 clarifications), but no other RFCs. > * The document will add clarifications based on the community's deployment experience. > * It is OK to correct minor technical errors and contradictions in the source documents. Any such corrections will be pointed out explicitly - preferably in an appendix (so that people using the old documents can scan it to discover problem areas). > * The document will not add any "nice to have" extensions, no matter how much technical sense they make. > > Please clearly indicate the position of any issue in the Internet Draft, and if possible provide alternative text. Please also indicate the nature or severity of the error or correction, e.g. major technical, minor technical, nit, so that we can quickly judge the extent of problems with the document. > > The document can be accessed here: > > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-06 > > Thanks, > Yaron From paul.hoffman@vpnc.org Sun Dec 13 19: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 4B8193A697D for ; Sun, 13 Dec 2009 19:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.655 X-Spam-Level: X-Spam-Status: No, score=-4.655 tagged_above=-999 required=5 tests=[AWL=-1.209, BAYES_50=0.001, 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 YNZikid6Ql7d for ; Sun, 13 Dec 2009 19:24: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 88FB73A657C for ; Sun, 13 Dec 2009 19:24: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 nBE3OZD1069334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Dec 2009 20:24:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20091214102644.0234.DECD93FF@lab.ntt.co.jp> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> <20091214102644.0234.DECD93FF@lab.ntt.co.jp> Date: Sun, 13 Dec 2009 19:24:33 -0800 To: Toshihiko Tamura , ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) 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, 14 Dec 2009 03:24:50 -0000 At 10:55 AM +0900 12/14/09, Toshihiko Tamura wrote: >Hi, I want to check one point. >At the last paragraph in Section 2.5, there is a mention of refering >the figures in Section 2. >Does it mean we should refer all fighres in Section 2? >Or does it mistake section 2 for section 1? Good catch. It should say "...the order shown in the figures in Sections 1 and 2". We split some of the figures out of 2 into 1, but we still have ones that have payload orders in section 2. --Paul Hoffman, Director --VPN Consortium From kivinen@iki.fi Mon Dec 14 04:36: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 C73A03A68BD for ; Mon, 14 Dec 2009 04:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 g5KGEWBsEF8P for ; Mon, 14 Dec 2009 04:36:16 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B4A963A687D for ; Mon, 14 Dec 2009 04:36: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 nBECZvAu019098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Dec 2009 14:35:57 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBECZuFI020495; Mon, 14 Dec 2009 14:35:56 +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: <19238.12588.38575.664370@fireball.kivinen.iki.fi> Date: Mon, 14 Dec 2009 14:35:56 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 9 min Cc: IPsecme WG Subject: [IPsec] #127: Should IKE_AUTH errors be encrypted? 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, 14 Dec 2009 12:36:16 -0000 Paul Hoffman writes: > Section 1.3.1 says "When an IKE SA is not created, the error message > return SHOULD NOT be encrypted because the other party will not be > able to authenticate that message." First, this seems out of place, > since this section talks about CREATE_CHILD_SA for Child SAs. > Second, assuming this is talking about IKE_AUTH, I think this > contradicts what we'd earlier agreed to -- and what section 1.2 now > seems to suggest -- in that the IKE_AUTH response should normally be > encrypted and MACed even on failure. We already decided when handing ticket 9 (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/9) that the reply message should be encrypted. The text to 1.3.1 was changed in -03 version (Feb 26 2009), and that ticket 9 was opened by my http://www.ietf.org/mail-archive/web/ipsec/current/msg02953.html message much earlier and ticket 9 was closed after this change in 1.3.1 was added, so the text in the 1.3.1 was not just updated to reflect the change done because of ticket 9. I think it is ok to just update the 1.3.1 to match the section 1.2 and ticket 9 solution. -- kivinen@iki.fi From kivinen@iki.fi Mon Dec 14 04:49: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 04D1C3A659C for ; Mon, 14 Dec 2009 04:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 0i4V1R19esZl for ; Mon, 14 Dec 2009 04:49:25 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C7E953A6A0F for ; Mon, 14 Dec 2009 04:49: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 nBECnAQ2024900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Dec 2009 14:49:10 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBECn82x019841; Mon, 14 Dec 2009 14:49:08 +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: <19238.13380.918117.767719@fireball.kivinen.iki.fi> Date: Mon, 14 Dec 2009 14:49:08 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> <20091214102644.0234.DECD93FF@lab.ntt.co.jp> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 12 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) 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, 14 Dec 2009 12:49:26 -0000 Paul Hoffman writes: > At 10:55 AM +0900 12/14/09, Toshihiko Tamura wrote: > >Hi, I want to check one point. > >At the last paragraph in Section 2.5, there is a mention of refering > >the figures in Section 2. > >Does it mean we should refer all fighres in Section 2? > >Or does it mistake section 2 for section 1? > > Good catch. It should say "...the order shown in the figures in > Sections 1 and 2". We split some of the figures out of 2 into 1, but > we still have ones that have payload orders in section 2. In the RFC4306 most of the figures with payloads were in the section 1. Section only had Cookies, EAP and Configuration payload examples. Basic IKE_SA_INIT, IKE_AUTH CREATE_CHILD_SA, and INFORMATION exchange figures have always been in the section 1. This is the situation also now (i.e. draft-ietf-ipsecme-ikev2bis-06 still has the basic IKE_SA_INIT, IKE_AUTH CREATE_CHILD_SA, and INFORMATION exchange figures in section 1 and the only change is that we splitted one of those figures (CREATE_CHILD_SA) from one figure to 3 figures (creating new Child SA, rekeying IKE SA, rekeying Child SA). Section 2 never had any figures listing payload orders for example for CREATE_CHILD_SA exchange. So this bug has been in the document before the bis document, i.e. it was in the RFC4306. On the other hand as we now say that "implementations MUST NOT reject as invalid a message with those payloads in any other order." I do not think this is that big issue. Also the payload order is now only SHOULD not MUST anymore. BTW, I think that change is one of the significant changes we should list in the RFC4306, i.e. following the payload order of the figures in section 2 is no longer MUST, it is now SHOULD (and applies to figures in section 1 too). Also it is no longer a SHOULD that messages with different payload order than in those in figures in section 2. Now implementations MUST NOT reject messages bacause different payload orders. -- kivinen@iki.fi From mcins1@gmail.com Mon Dec 14 05:26: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 86D433A68BA for ; Mon, 14 Dec 2009 05:26:39 -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 sr5cJO1h5hPD for ; Mon, 14 Dec 2009 05:26:38 -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 2C0B63A68B4 for ; Mon, 14 Dec 2009 05:26:38 -0800 (PST) Received: by gxk28 with SMTP id 28so519453gxk.9 for ; Mon, 14 Dec 2009 05:26:22 -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=X8uy8m0wtlS/tHEcufVYRKkc5jEkrewfCOQ+AlvTeq8=; b=s/Er9HiiQd2D99rAQJvoXWxUelV38EJvRaprTcDaH9/tSUXkvUHJNgq/S2hphfrwsv S7YPHHK0Vj3XfjQedzZJBd76ofkyNqCKS4Z5rkLCJq+mnmOkeVdhyhQ+tDX4oYrrzAeo ndATwnKQAEBUmua71y3TZIiJyLrFeSc4nTnRY= 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=ZqlhY5uSZNhyNAnopeJt1mSELUdfXxfjbG1lwJ0j3O0FNmMW+70bxe3vNcqe5jizXW JW/mno1Vmu7J837/e0lra2vnJxyO1Th58Be6+5iIC8Krf6WYbyMD+9IyfG/Nj/28Y1hq yYhthx4zh5batBnIvNhqWVRAGTkMJ147/7O3s= MIME-Version: 1.0 Received: by 10.91.150.7 with SMTP id c7mr1874874ago.44.1260797181171; Mon, 14 Dec 2009 05:26:21 -0800 (PST) In-Reply-To: <19238.13380.918117.767719@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> <20091214102644.0234.DECD93FF@lab.ntt.co.jp> <19238.13380.918117.767719@fireball.kivinen.iki.fi> From: Matthew Cini Sarreo Date: Mon, 14 Dec 2009 14:26:01 +0100 Message-ID: <99043b4a0912140526y3e217649n67d19416e3c87ea8@mail.gmail.com> To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=0016e64f7ef61e286f047ab03818 Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) 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, 14 Dec 2009 13:26:39 -0000 --0016e64f7ef61e286f047ab03818 Content-Type: text/plain; charset=ISO-8859-1 Hello all, A minor technical note about Issue #22. Section 2.25, last paragraph reads: A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a request to rekey a Child SA that does not exist. A peer 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. The original text does not mention what the SPI should be (it is practially implied what it should be set to, but is still not mentioned in the text). Presumably one would set the this to be the SPI of the Child SA that caused the error (i.e the data for CHILD_SA_NOT_FOUND is the same as the SPI found inside the REKEY_SA notification). This way, the Initiator knows which rekeying attempt resulted in this error. I would propose to change this text to: A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a request to rekey a Child SA that does not exist. The SA that the initiator attempted to rekey is indicated by the SPI field in the Notify Payload, which is copied from the SPI field in the REYEY_SA notification. A peer 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. Regards, Matt 2009/12/14 Tero Kivinen > Paul Hoffman writes: > > At 10:55 AM +0900 12/14/09, Toshihiko Tamura wrote: > > >Hi, I want to check one point. > > >At the last paragraph in Section 2.5, there is a mention of refering > > >the figures in Section 2. > > >Does it mean we should refer all fighres in Section 2? > > >Or does it mistake section 2 for section 1? > > > > Good catch. It should say "...the order shown in the figures in > > Sections 1 and 2". We split some of the figures out of 2 into 1, but > > we still have ones that have payload orders in section 2. > > In the RFC4306 most of the figures with payloads were in the section > 1. Section only had Cookies, EAP and Configuration payload examples. > > Basic IKE_SA_INIT, IKE_AUTH CREATE_CHILD_SA, and INFORMATION exchange > figures have always been in the section 1. > > This is the situation also now (i.e. draft-ietf-ipsecme-ikev2bis-06 > still has the basic IKE_SA_INIT, IKE_AUTH CREATE_CHILD_SA, and > INFORMATION exchange figures in section 1 and the only change is that > we splitted one of those figures (CREATE_CHILD_SA) from one figure to > 3 figures (creating new Child SA, rekeying IKE SA, rekeying Child SA). > > Section 2 never had any figures listing payload orders for example for > CREATE_CHILD_SA exchange. > > So this bug has been in the document before the bis document, i.e. it > was in the RFC4306. > > On the other hand as we now say that "implementations MUST NOT reject > as invalid a message with those payloads in any other order." I do not > think this is that big issue. Also the payload order is now only > SHOULD not MUST anymore. > > BTW, I think that change is one of the significant changes we should > list in the RFC4306, i.e. following the payload order of the figures > in section 2 is no longer MUST, it is now SHOULD (and applies to > figures in section 1 too). > > Also it is no longer a SHOULD that messages with different payload > order than in those in figures in section 2. Now implementations MUST > NOT reject messages bacause different payload orders. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0016e64f7ef61e286f047ab03818 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello all,

A minor technical note about Issue #22. Section 2.25, last paragraph re= ads:

A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a request to rekey a Child SA that does not exist.=A0 A peer 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.

The original text does not mention what the SPI should be (it is practially implied what it should be set to, but is still not men= tioned in the text). Presumably one would set the this to be the SPI of the Child SA that caused the error (i.e the data for CHILD_SA_NOT_FOUND is the same as the SPI found inside the REKEY_SA notification). This way, the Initiator knows which rekeying attempt resulted in this error.

I would propose to change this text to:
A CHILD_SA_NOT_FOUND notificatio= n SHOULD be sent when a peer receives a request to rekey a Child SA that does not exist.=A0 The SA that the initiat= or attempted to rekey is indicated by the SPI field in the Notify Payload, = which is copied from the SPI field in the REYEY_SA notification. A peer tha= t 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.

Regards, Matt

2009/12/14 Tero Kivinen <kivinen@iki.f= i>
Paul Hoffman writes:
> At 10:55 AM +0900 12/14/09, Toshihiko Tamura wrote:
> >Hi, I want to check one point.
> >At the last paragraph in Section 2.5, there is a mention of referi= ng
> >the figures in Section 2.
> >Does it mean we should refer all fighres in Section 2?
> >Or does it mistake section 2 for section 1?
>
> Good catch. It should say "...the order shown in the figures in > Sections 1 and 2". We split some of the figures out of 2 into 1, = but
> we still have ones that have payload orders in section 2.

In the RFC4306 most of the figures with payloads were in the section<= br> 1. Section only had Cookies, EAP and Configuration payload examples.

Basic IKE_SA_INIT, IKE_AUTH CREATE_CHILD_SA, and INFORMATION exchange
figures have always been in the section 1.

This is the situation also now (i.e. draft-ietf-ipsecme-ikev2bis-06
still has the basic IKE_SA_INIT, IKE_AUTH CREATE_CHILD_SA, and
INFORMATION exchange figures in section 1 and the only change is that
we splitted one of those figures (CREATE_CHILD_SA) from one figure to
3 figures (creating new Child SA, rekeying IKE SA, rekeying Child SA).

Section 2 never had any figures listing payload orders for example for
CREATE_CHILD_SA exchange.

So this bug has been in the document before the bis document, i.e. it
was in the RFC4306.

On the other hand as we now say that "implementations MUST NOT reject<= br> as invalid a message with those payloads in any other order." I do not=
think this is that big issue. Also the payload order is now only
SHOULD not MUST anymore.

BTW, I think that change is one of the significant changes we should
list in the RFC4306, i.e. following the payload order of the figures
in section 2 is no longer MUST, it is now SHOULD (and applies to
figures in section 1 too).

Also it is no longer a SHOULD that messages with different payload
order than in those in figures in section 2. Now implementations MUST
NOT reject messages bacause different payload orders.
--
kivinen@iki.fi
_______________________________________________=
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--0016e64f7ef61e286f047ab03818-- From denghui02@gmail.com Mon Dec 14 07:35: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 96A4C3A68FB for ; Mon, 14 Dec 2009 07:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 gp3ggZSfqy8B for ; Mon, 14 Dec 2009 07:35:21 -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 7B4AF3A692A for ; Mon, 14 Dec 2009 07:35:21 -0800 (PST) Received: by pwi20 with SMTP id 20so2170965pwi.29 for ; Mon, 14 Dec 2009 07:35:05 -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=v4e/OdADlAN5i+pF5EeUtAej45UREOHWgIWGjKPGUtY=; b=jFPDuU5mWy8iUt3T32xgVYIe/KQQRSLD8LdXJ4ql8ms8bM+PkFHRQi4D93BtlMcKXX Jc25S99KtAtN3QEROXml8FWe0Yzqx+BQSQ947mCT66ePpHeJwfrW1ZXM6Udc7yC95e9O eJ6b4Kffl5RrDGo1HVlA3Ti/GLZCLAsq0mExk= 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=e07TAIoWDSM78lpJ+bUhBxn5Q04LJTKld1wGk4EkxlcKbhlBsESeycGvy/Xg+2K9h1 SwjSL35gTESahTC43snlwqCASEZC0ev8Vy31lbqdZyDnCeZ6WW2EiUyLq7FUuZZs7DK6 qQOzsrA2aRyArMMTdIGRZrOmrb0FDZn9hjvOM= MIME-Version: 1.0 Received: by 10.141.130.6 with SMTP id h6mr3406214rvn.265.1260804905076; Mon, 14 Dec 2009 07:35:05 -0800 (PST) In-Reply-To: <4381657317742816904@unknownmsgid> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <1d38a3350912090742q1976ffefo85ef5e0e5627ec0b@mail.gmail.com> <8104339512286448538@unknownmsgid> <1d38a3350912092129v4b4d6f77pc5114e72284ea8da@mail.gmail.com> <-4242183742059278883@unknownmsgid> <1d38a3350912110643r50796cfahdfcd02889fc2bdbd@mail.gmail.com> <4381657317742816904@unknownmsgid> Date: Mon, 14 Dec 2009 23:35:04 +0800 Message-ID: <1d38a3350912140735o2905d611g1b8b0c5483a9458e@mail.gmail.com> From: Hui Deng To: Alper Yegin Content-Type: text/plain; charset=ISO-8859-1 Cc: ipsec@ietf.org Subject: Re: [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: Mon, 14 Dec 2009 15:35:22 -0000 Hi Alper, 2009/12/12 Alper Yegin : > Hi Hui, > >> Hi Alper, >> >> It seems that your argument goes to 3GPP only not this new work item, >> then I would suggest that you propose your solution to 3GPP HNB. > > We are having this discussion in IETF right now. So, there is no point in > telling us to go elsewhere. If the discussions is here, it is here. > >> Back to your questions, the scenarios is that some user need this >> IKE/IPsec >> or other don't need IPsec for the first, and also could be upgraded to >> need IKE/IPsec, > > Is this a real scenario? I'd like to understand how a user moves from a > non-IPsec to IPsec. It is not handover case, it is just physical link sometime is securied enough sometime it is, and some user support this, other are not support this. > > >> I also found you didn't classify different access authenticaiton >> protocol. > > Could you please elaborate on what exactly you are asking about? I mean normally we won't do two different type authentication mechanism for the same device. > > >> this is not a granularity issue, how could your proposal to support >> this scenario and migration scenarios simultaneously? > > If you can explain to us what migration scenarios you have, we can discuss > them. Secenario above. thanks -Hui > > Thanks. > > Alper > > > > > >> >> thanks >> >> -Hui >> >> 2009/12/10 Alper Yegin : >> > Hi Hui, >> > >> >> I am not convinced why vendor need implement two security mechanism >> to >> >> one product, >> >> just because the second one need some market to use it. >> > >> > Unfortunately, protocol classification is more granular than that. >> > You don't identify one protocol as "security protocol" and make it >> serve all >> > security related purposes: access authentication, IPsec SA >> establishment, >> > transport-layer security, application-layer security, mobility >> signaling >> > security, etc. etc. Obviously, you need several distinct protocols >> for these >> > things. >> > >> > So, saying we have IKEv2, and we'll twist and turn it into some other >> > protocol for some other purpose may make sense when you are looking >> at >> > things from within the box (that implements IKEv2), but it does not >> make >> > sense when you are looking from outside the box (like from IETF >> > perspective). >> > >> > Your proposal is for turning IKEv2 into an EAP transport for generic >> network >> > access authentication. It requires taking some stuff out, twisting >> some >> > stuff, and adding stuff. It's technically doable, but "IETF" needs to >> be >> > convinced why it needs to reinvent PANA by taking IKEv2 as the >> baseline. >> > >> > Alper >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> >> >> -Hui >> >> >> >> 2009/12/10 Alper Yegin : >> >> > Hi Hui, >> >> > >> >> > You named 3GPP as a consumer of this, acknowledged that 3GPP is >> not >> >> behind >> >> > all of the requirements, but you didn't respond to my question >> about >> >> which >> >> > one of the requirements are coming from 3GPP. >> >> > >> >> > >> >> > I object to this work, because it intends to create yet another >> >> network >> >> > access authentication protocol out of IKEv2. As you know, PANA is >> >> designed >> >> > for that purpose. IETF community needs to understand why PANA does >> >> not fit >> >> > the need, and why we need to turn IKEv2 into a general-purpose >> >> network >> >> > access authentication protocol. (IKE needs to get in line with the >> >> other >> >> > similar proposals, such as hacking up DHCP into access >> authentication >> >> > protocol, and even HTTP. I guess everyone has his/her favorite >> >> protocol to >> >> > hack.) >> >> > >> >> > Similar questions arise for the other motivations. "Liveness >> >> checking", and >> >> > "NAT detection".... Turning IKEv2 into a dedicated protocol for >> these >> >> > purposes is likely to grow IKE in many unintended directions. >> >> > >> >> > Alper >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >> >> Behalf >> >> >> Of Hui Deng >> >> >> Sent: Wednesday, December 09, 2009 5:42 PM >> >> >> To: Yaron Sheffer >> >> >> Cc: ipsec@ietf.org >> >> >> Subject: Re: [IPsec] Proposed work item: Childless IKE SA >> >> >> >> >> >> would like to co-author, thanks >> >> >> >> >> >> -Hui >> >> >> >> >> >> 2009/11/30 Yaron Sheffer : >> >> >> > 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- >> >> >> childless-01.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 >> >> >> > >> >> >> _______________________________________________ >> >> >> IPsec mailing list >> >> >> IPsec@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > >> >> > _______________________________________________ >> >> > IPsec mailing list >> >> > IPsec@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/ipsec >> >> > >> > >> > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From paul.hoffman@vpnc.org Mon Dec 14 08:05: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 A14E63A6806 for ; Mon, 14 Dec 2009 08:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.935 X-Spam-Level: X-Spam-Status: No, score=-5.935 tagged_above=-999 required=5 tests=[AWL=0.111, 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 58+Q97bST3aK for ; Mon, 14 Dec 2009 08:05: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 DEA873A67E2 for ; Mon, 14 Dec 2009 08:05:47 -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 nBEG5WUn021752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Dec 2009 09:05:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19238.13380.918117.767719@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> <20091214102644.0234.DECD93FF@lab.ntt.co.jp> <19238.13380.918117.767719@fireball.kivinen.iki.fi> Date: Mon, 14 Dec 2009 08:05:30 -0800 To: Tero Kivinen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ipsec@ietf.org Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) 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, 14 Dec 2009 16:05:48 -0000 At 2:49 PM +0200 12/14/09, Tero Kivinen wrote: >BTW, I think that change is one of the significant changes we should >list in the RFC4306, i.e. following the payload order of the figures >in section 2 is no longer MUST, it is now SHOULD (and applies to >figures in section 1 too). Quite right. I remind people again of issue #126: Section 1.7 lists notable changes from RFC 4106. Those of us making those changes may have forgotten to also update section 1.7. I already updated section 1.7 for this change, but if people find other such "notable changes", please comment on the thread for #126. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Mon Dec 14 09:06: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 4A5383A68F4 for ; Mon, 14 Dec 2009 09:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.937 X-Spam-Level: X-Spam-Status: No, score=-5.937 tagged_above=-999 required=5 tests=[AWL=0.109, 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 UR75PiL07ZbA for ; Mon, 14 Dec 2009 09:06: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 69A353A67D1 for ; Mon, 14 Dec 2009 09:06:45 -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 nBEH6TB1027291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Dec 2009 10:06:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <99043b4a0912140526y3e217649n67d19416e3c87ea8@mail.gmail.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> <20091214102644.0234.DECD93FF@lab.ntt.co.jp> <19238.13380.918117.767719@fireball.kivinen.iki.fi> <99043b4a0912140526y3e217649n67d19416e3c87ea8@mail.gmail.com> Date: Mon, 14 Dec 2009 09:06:28 -0800 To: Matthew Cini Sarreo , ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] #22: Specifying the 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: Mon, 14 Dec 2009 17:06:46 -0000 At 2:26 PM +0100 12/14/09, Matthew Cini Sarreo wrote: >Hello all, > >A minor technical note about Issue #22. Section 2.25, last paragraph reads: > >A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a request to rekey a Child SA that does not exist. A peer 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. > >The original text does not mention what the SPI should be (it is practially implied what it should be set to, but is still not mentioned in the text). Presumably one would set the this to be the SPI of the Child SA that caused the error (i.e the data for CHILD_SA_NOT_FOUND is the same as the SPI found inside the REKEY_SA notification). This way, the Initiator knows which rekeying attempt resulted in this error. > >I would propose to change this text to: >A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a request to rekey a Child SA that does not exist. The SA that the initiator attempted to rekey is indicated by the SPI field in the Notify Payload, which is copied from the SPI field in the REYEY_SA notification. A peer 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. It is always good to make this kind of thing explicit. I will add this to the next draft. --Paul Hoffman, Director --VPN Consortium From smoonen@us.ibm.com Tue Dec 15 08:53: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 0C52F3A6AB8; Tue, 15 Dec 2009 08:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.968 X-Spam-Level: X-Spam-Status: No, score=-5.968 tagged_above=-999 required=5 tests=[AWL=0.630, 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 t9bIKjyFhzCf; Tue, 15 Dec 2009 08:53:48 -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 550BA3A6AA4; Tue, 15 Dec 2009 08:53:48 -0800 (PST) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e36.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nBFGp6gT021405; Tue, 15 Dec 2009 09:51:06 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBFGrGDc055122; Tue, 15 Dec 2009 09:53:20 -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 nBFGrCi7010385; Tue, 15 Dec 2009 09:53:13 -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 nBFGrCpj010382; Tue, 15 Dec 2009 09:53:12 -0700 In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> To: Yaron Sheffer MIME-Version: 1.0 X-KeepSent: 6739784F:A923DCE9-8525768C:0070A639; 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 12/15/2009 11:47:48 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 12/15/2009 11:47:48 AM, Serialize complete at 12/15/2009 11:47:48 AM, S/MIME Sign failed at 12/15/2009 11:47:48 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 12/15/2009 09:53:12, Serialize complete at 12/15/2009 09:53:12 Message-ID: Date: Tue, 15 Dec 2009 11:53:11 -0500 Content-Type: multipart/alternative; boundary="=_alternative 005C448C8525768D_=" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) 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, 15 Dec 2009 16:53:50 -0000 This is a multipart message in MIME format. --=_alternative 005C448C8525768D_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSd2ZSBmaW5pc2hlZCBteSByZWFkIHRocm91Z2ggdGhlIGRyYWZ0LiAgTm90ZSB0aGF0IEkgZGlk bid0IGdpdmUgbXVjaCANCnNjcnV0aW55IHRvIHRoZSBDb25maWcgb3IgRUFQIHBheWxvYWRzLCBi dXQgSSd2ZSByZWFkIG92ZXIgZXZlcnl0aGluZyANCmVsc2UuICBBIGZldyBtb3JlIGNvbW1lbnRz Og0KDQoxKSBUaGVyZSBhcmUgZXhjZXNzaXZlIHNwYWNlcyBvbiB0aGUgc2Vjb25kIGxpbmVzIG9m IHRoZXNlIGxpc3QgaXRlbXMgaW4gDQpzZWN0aW9uIDIuMjM6DQoNCiAgICAgLSBJZiB0aGUgc2Vy dmVyIGlzIGJlaGluZCBhIE5BVCwgc3Vic3RpdHV0ZSB0aGUgSVAgYWRkcmVzcyBpbiB0aGUNCiAg ICAgICBUU3IgIGVudHJpZXMgd2l0aCB0aGUgcmVtb3RlIGFkZHJlc3Mgb2YgdGhlIElLRSBTQS4N CiAgICAgICAgICBeDQoNCiAgICAgLSBJZiB0aGUgY2xpZW50IGlzIGJlaGluZCBhIE5BVCwgc3Vi c3RpdHV0ZSB0aGUgSVAgYWRkcmVzcyBpbiB0aGUNCiAgICAgICAgVFNpIGVudHJpZXMgd2l0aCB0 aGUgbG9jYWwgYWRkcmVzcyBvZiB0aGUgSUtFIFNBLg0KICAgICAgIF4NCg0KMikgSW4gc2VjdGlv biAzLjMsIHRoaXMgc2VudGVuY2U6ICJJZiBhbiBhbGdvcml0aG0gdGhhdCBjb21iaW5lcyANCmVu Y3J5cHRpb24gYW5kIGludGVncml0eSBwcm90ZWN0aW9uIGlzIHByb3Bvc2VkLCBpdCBNVVNUIGJl IHByb3Bvc2VkIGFzIGFuIA0KZW5jcnlwdGlvbiBhbGdvcml0aG0gYW5kIGFuIGludGVncml0eSBw cm90ZWN0aW9uIGFsZ29yaXRobSBNVVNUIE5PVCBiZSANCnByb3Bvc2VkLiIgc2VlbXMgdG8gYXBw bHkgdG8gYWxsIHByb3RvY29scywgaW5jbHVkaW5nIElLRSwgYW5kIGl0IGlzIG1vcmUgDQpzdHJp Y3QgdGhhbiB3aGF0IHdlJ2QgYWdyZWVkIHRvIGZvciB0aWNrZXQgIzEyMi4gIEl0IGlzIGFsc28g bW9yZSBzdHJpY3QgDQp0aGFuIHRoZSAiTUFZIiBpbiBzZWN0aW9uIDMuMy4zLiAgU3BlYWtpbmcg b2YgdGlja2V0ICMxMjIsIHRoZSB1cGRhdGVkIA0KdGV4dCBmb3IgdGhhdCB0aWNrZXQgaXMgc29t ZWhvdyBtaXNzaW5nIGluIHRoaXMgZHJhZnQuDQoNCjMpIEluIHNlY3Rpb24gMy42OiAiQ2VydGlm aWNhdGUgcGF5bG9hZHMgU0hPVUxEIGJlIGluY2x1ZGVkIGluIGFuIGV4Y2hhbmdlIA0KaWYgY2Vy dGlmaWNhdGVzIGFyZSBhdmFpbGFibGUgdG8gdGhlIHNlbmRlciB1bmxlc3MgdGhlIHBlZXIgaGFz IGluZGljYXRlZCANCmFuIGFiaWxpdHkgdG8gcmV0cmlldmUgdGhpcyBpbmZvcm1hdGlvbiBmcm9t IGVsc2V3aGVyZSB1c2luZyBhbiANCkhUVFBfQ0VSVF9MT09LVVBfU1VQUE9SVEVEIE5vdGlmeSBw YXlsb2FkLiIgIFRoaXMgc2VudGVuY2UgaXMgaW5jb2hlcmVudCANCi0tIEkgdGhpbmsgaWYgdGhl IEhUVFBfLi4uIG5vdGlmeSB3YXMgc2VudCB5b3UnZCBzdGlsbCBpbmNsdWRlIGEgDQpjZXJ0aWZp Y2F0ZSBwYXlsb2FkLCBpdCBqdXN0IHdvdWxkbid0IGhvbGQgYSBjZXJ0aWZpY2F0ZS4gIEknbSBw cm9iYWJseSANCm5vdCB0aGUgYmVzdCBwZXJzb24gdG8gc3VnZ2VzdCBhbHRlcm5hdGl2ZSB3b3Jk aW5nLCBidXQgcGVyaGFwcyBzb21ldGhpbmcgDQpsaWtlICJDZXJ0aWZpY2F0ZSBwYXlsb2FkcyBT SE9VTEQgYmUgdXNlZCB0byBzZW5kIGVudGlyZSBjZXJ0aWZpY2F0ZXMgaWYgDQp0aGV5IGFyZSAu Li4iDQoNCjQpIFNlY3Rpb24gMy4xMC4xIC0tIHdlIHNob3VsZCByZW1lbWJlciB0byByZW1vdmUg Int7IERlbW90ZWQgdGhlIFNIT1VMRCANCn19IiBiZWZvcmUgcHVibGljYXRpb24uDQoNCjUpIFNl Y3Rpb24gMy4xMy4xLCBleHRyYW5lb3VzIGNhcGl0YWxpemF0aW9uOg0KDQogICBvICBTZWxlY3Rv ciBMZW5ndGggLSBTcGVjaWZpZXMgdGhlIGxlbmd0aCBvZiB0aGlzIFRyYWZmaWMgU2VsZWN0b3IN CiAgICAgIFN1YnN0cnVjdHVyZSBpbmNsdWRpbmcgdGhlIGhlYWRlci4NCiAgICAgIF4NCg0KNikg U2VjdGlvbiAzLjEzLjEsIGNvdWxkIHByb2JhYmx5IHVzZSBhIGxpdHRsZSB0d2Vha2luZyB0byBy ZXBsYWNlIA0KcmVmZXJlbmNlcyB0byAiSUNNUCIgd2l0aCAiSUNNUCwgSUNNUHY2IGFuZCBNSVB2 NiIuICBBbHNvLCB0aGUgcGFyYWdyYXBoIA0KY29udGFpbmluZyAiVGhpcyBkb2N1bWVudCBkb2Vz IG5vdCBzcGVjaWZ5IGhvdyB0byByZXByZXNlbnQgdGhlICdNSCBUeXBlJyANCmZpZWxkIC4uLiIg YWN0dWFsbHkgZ29lcyBvbiB0byBzcGVjaWZ5IGp1c3QgdGhhdC4NCg0KNykgU2VjdGlvbiAzLjE0 LCAiVGhlIEVuY3J5cHRlZCBQYXlsb2FkLCBpZiBwcmVzZW50IGluIGEgbWVzc2FnZSwgTVVTVCBi ZSANCnRoZSBsYXN0IHBheWxvYWQgaW4gdGhlIG1lc3NhZ2UuICBPZnRlbiwgaXQgaXMgdGhlIG9u bHkgcGF5bG9hZCBpbiB0aGUgDQptZXNzYWdlLiIgIE91dCBvZiBjdXJpb3NpdHksIGRvIHdlIGtu b3cgb2YgYW55IGNhc2VzIHdoZXJlIHRoaXMgcGF5bG9hZCBpcyANCm5vdCB0aGUgb25seSBwYXls b2FkIGluIHRoZSBtZXNzYWdlPyAgSXQgc3RyaWtlcyBtZSBhcyBvZGQgdG8gYWxsb3cgZm9yIA0K c29tZSBwYXlsb2FkcyBwcmlvciB0byB0aGlzIG9uZSB0byBiZSBpbnRlZ3JpdHkgcHJvdGVjdGVk IGJ1dCBub3QgDQplbmNyeXB0ZWQuICBJIHN1cHBvc2Ugc2luY2UgUkZDIDQzMDYgYWxsb3dzIGl0 IHdlIGRvbid0IGhhdmUgYSBsb3Qgb2YgDQp3aWdnbGUgcm9vbSBoZXJlLg0KDQo4KSBTZWN0aW9u IDQsICJFdmVyeSBpbXBsZW1lbnRhdGlvbiBNVVNUIGJlIGNhcGFibGUgb2YgcmVzcG9uZGluZyB0 byBhbiANCklORk9STUFUSU9OQUwgZXhjaGFuZ2UsIGJ1dCBhIG1pbmltYWwgaW1wbGVtZW50YXRp b24gTUFZIHJlc3BvbmQgdG8gYW55IA0KSU5GT1JNQVRJT05BTCBtZXNzYWdlIHdpdGggYW4gZW1w dHkgSU5GT1JNQVRJT05BTCByZXBseS4iICBJcyB0aGF0IHRydWUgDQpldmVuIGlmIHRoZSBJTkZP Uk1BVElPTkFMIHJlcXVlc3QgY29udGFpbmVkIGEgRGVsZXRlIHBheWxvYWQgZm9yIGEgQ2hpbGQg DQpTQT8NCg0KOSkgQXBwZW5kaXggRCAtLSB3ZSBuZWVkIHRvIGZpbGwgdGhpcyBpbi4NCg0KDQpT Y290dCBNb29uZW4gKHNtb29uZW5AdXMuaWJtLmNvbSkNCnovT1MgQ29tbXVuaWNhdGlvbnMgU2Vy dmVyIFRDUC9JUCBEZXZlbG9wbWVudA0KaHR0cDovL3d3dy5saW5rZWRpbi5jb20vaW4vc21vb25l bg0KDQoNCg0KRnJvbToNCllhcm9uIFNoZWZmZXIgPHlhcm9uZkBjaGVja3BvaW50LmNvbT4NClRv Og0KImlwc2VjQGlldGYub3JnIiA8aXBzZWNAaWV0Zi5vcmc+DQpEYXRlOg0KMTIvMTAvMjAwOSAw NDowNSBBTQ0KU3ViamVjdDoNCltJUHNlY10gV29ya2luZyBHcm91cCBMQzogZHJhZnQtaWV0Zi1p cHNlY21lLWlrZXYyYmlzLTA2ICh5ZXMsIElLRXYyLWJpcyEpDQoNCg0KDQpUaGlzIGlzIHRvIGJl Z2luIGEgNCB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciANCmRyYWZ0LWlldGYtaXBz ZWNtZS1pa2V2MmJpcy0wNi4gVGhlIHRhcmdldCBzdGF0dXMgZm9yIHRoaXMgZG9jdW1lbnQgaXMg DQpQcm9wb3NlZCBTdGFuZGFyZCwgb2Jzb2xldGluZyBSRkMgNDMwNiBhbmQgUkZDIDQ3MTguDQog DQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBpcHNlYyBsaXN0IGJ5IEphbi4gNSwg MjAxMCwgYXMgZm9sbG93LXVwcyANCnRvIHRoaXMgbWVzc2FnZS4NCiANClRoaXMgaXMgYSBsYXJn ZSBkb2N1bWVudCwgYW5kIGFyZ3VhYmx5IHRoZSBtb3N0IGltcG9ydGFudCBkb2N1bWVudCB0aGlz IFdHIA0KaXMgZW50cnVzdGVkIHdpdGguIFRoZSBMQyBwZXJpb2QgaXMgbG9uZ2VyIHRoYW4gdXN1 YWwgYnV0IHdpbGwgaW5jbHVkZSANCnZhY2F0aW9uIHRpbWUgZm9yIG1vc3Qgb2YgdXMuIE5ldmVy dGhlbGVzcywgcGxlYXNlIG1ha2UgYW4gZWZmb3J0IHRvIA0KcmV2aWV3IHRoZSBlbnRpcmUgZG9j dW1lbnQsIG9yIGF0IGxlYXN0IGxhcmdlIHBvcnRpb25zIG9mIGl0LiBGZWVsIGZyZWUgdG8gDQpw b3N0IG11bHRpcGxlIHBhcnRpYWwgcmV2aWV3cy4NCiANCkluIHRoaXMgcGFydGljdWxhciBjYXNl LCB3ZSBhcmUgc3RhcnRpbmcgdGhlIHJldmlldyB3aXRoIGEgZmV3IG9wZW4gaXNzdWVzDQouIFdl IHdpbGwgbWFrZSBhbiBlZmZvcnQgdG8gY2xvc2UgdGhlbSBkdXJpbmcgdGhlIFdHIExDIHBlcmlv ZC4NCiANCkFzIGEgcmVtaW5kZXIgcmVnYXJkaW5nIHRoZSBkb2N1bWVudOKAmXMgc2NvcGUgKGFu ZCBvdXIgY29uc3RyYWludHMgd2hpbGUgDQpyZXZpZXdpbmcgaXQpLCBJIHdpbGwgcXVvdGUgZnJv bSBteSBtYWlsIG9mIEF1Zy4gMjAwODoNCiANCkdlbmVyYWw6IFRoZSBnb2FsIG9mIHRoZSBJS0V2 MiBiaXMgZG9jdW1lbnQgaXMgdG8gY2xhcmlmeSB0aGUgcHJvdG9jb2wuIA0KVGhlIGdvYWwgaXMg bm90IHRvIGV4dGVuZCBpdC4gU3BlY2lmaWNhbGx5Og0KIA0KKiBUaGUgZG9jdW1lbnQgd2lsbCBj b21iaW5lIFJGQyA0MzA2IChJS0V2MikgYW5kIFJGQyA0NzE4IChJS0V2MiANCmNsYXJpZmljYXRp b25zKSwgYnV0IG5vIG90aGVyIFJGQ3MuDQoqIFRoZSBkb2N1bWVudCB3aWxsIGFkZCBjbGFyaWZp Y2F0aW9ucyBiYXNlZCBvbiB0aGUgY29tbXVuaXR5J3MgZGVwbG95bWVudCANCmV4cGVyaWVuY2Uu DQoqIEl0IGlzIE9LIHRvIGNvcnJlY3QgbWlub3IgdGVjaG5pY2FsIGVycm9ycyBhbmQgY29udHJh ZGljdGlvbnMgaW4gdGhlIA0Kc291cmNlIGRvY3VtZW50cy4gQW55IHN1Y2ggY29ycmVjdGlvbnMg d2lsbCBiZSBwb2ludGVkIG91dCBleHBsaWNpdGx5IC0gDQpwcmVmZXJhYmx5IGluIGFuIGFwcGVu ZGl4IChzbyB0aGF0IHBlb3BsZSB1c2luZyB0aGUgb2xkIGRvY3VtZW50cyBjYW4gc2NhbiANCml0 IHRvIGRpc2NvdmVyIHByb2JsZW0gYXJlYXMpLg0KKiBUaGUgZG9jdW1lbnQgd2lsbCBub3QgYWRk IGFueSAibmljZSB0byBoYXZlIiBleHRlbnNpb25zLCBubyBtYXR0ZXIgaG93IA0KbXVjaCB0ZWNo bmljYWwgc2Vuc2UgdGhleSBtYWtlLg0KIA0KUGxlYXNlIGNsZWFybHkgaW5kaWNhdGUgdGhlIHBv c2l0aW9uIG9mIGFueSBpc3N1ZSBpbiB0aGUgSW50ZXJuZXQgRHJhZnQsIA0KYW5kIGlmIHBvc3Np YmxlIHByb3ZpZGUgYWx0ZXJuYXRpdmUgdGV4dC4gUGxlYXNlIGFsc28gaW5kaWNhdGUgdGhlIG5h dHVyZSANCm9yIHNldmVyaXR5IG9mIHRoZSBlcnJvciBvciBjb3JyZWN0aW9uLCBlLmcuIG1ham9y IHRlY2huaWNhbCwgbWlub3IgDQp0ZWNobmljYWwsIG5pdCwgc28gdGhhdCB3ZSBjYW4gcXVpY2ts eSBqdWRnZSB0aGUgZXh0ZW50IG9mIHByb2JsZW1zIHdpdGggDQp0aGUgZG9jdW1lbnQuDQogDQpU aGUgZG9jdW1lbnQgY2FuIGJlIGFjY2Vzc2VkIGhlcmU6DQogDQpodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWlwc2VjbWUtaWtldjJiaXMtMDYNCiANClRoYW5rcywNCiAgICAg IFlhcm9uX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklQ c2VjIG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXBzZWMNCg0KDQoNCg== --=_alternative 005C448C8525768D_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkndmUgZmluaXNoZWQgbXkgcmVh ZCB0aHJvdWdoIHRoZSBkcmFmdC4NCiZuYnNwO05vdGUgdGhhdCBJIGRpZG4ndCBnaXZlIG11Y2gg c2NydXRpbnkgdG8gdGhlIENvbmZpZyBvciBFQVAgcGF5bG9hZHMsDQpidXQgSSd2ZSByZWFkIG92 ZXIgZXZlcnl0aGluZyBlbHNlLiAmbmJzcDtBIGZldyBtb3JlIGNvbW1lbnRzOjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MSkgVGhlcmUgYXJlIGV4Y2Vz c2l2ZSBzcGFjZXMgb24gdGhlDQpzZWNvbmQgbGluZXMgb2YgdGhlc2UgbGlzdCBpdGVtcyBpbiBz ZWN0aW9uIDIuMjM6PC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZu YnNwOyAmbmJzcDstIElmIHRoZSBzZXJ2ZXIgaXMgYmVoaW5kIGEgTkFULA0Kc3Vic3RpdHV0ZSB0 aGUgSVAgYWRkcmVzcyBpbiB0aGU8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RTciAmbmJzcDtlbnRyaWVzIHdpdGgNCnRoZSByZW1v dGUgYWRkcmVzcyBvZiB0aGUgSUtFIFNBLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBePC9mb250PjwvdHQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7ICZuYnNwOy0gSWYgdGhlIGNsaWVu dCBpcyBiZWhpbmQgYSBOQVQsDQpzdWJzdGl0dXRlIHRoZSBJUCBhZGRyZXNzIGluIHRoZTwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFRTaSBlbnRyaWVzIHdpdGggdGhlIGxvY2FsDQphZGRyZXNzIG9mIHRoZSBJS0UgU0EuPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDte PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIp IEluIHNlY3Rpb24gMy4zLCB0aGlzIHNlbnRlbmNlOiAmcXVvdDtJZg0KYW4gYWxnb3JpdGhtIHRo YXQgY29tYmluZXMgZW5jcnlwdGlvbiBhbmQgaW50ZWdyaXR5IHByb3RlY3Rpb24gaXMgcHJvcG9z ZWQsDQppdCBNVVNUIGJlIHByb3Bvc2VkIGFzIGFuIGVuY3J5cHRpb24gYWxnb3JpdGhtIGFuZCBh biBpbnRlZ3JpdHkgcHJvdGVjdGlvbg0KYWxnb3JpdGhtIE1VU1QgTk9UIGJlIHByb3Bvc2VkLiZx dW90OyBzZWVtcyB0byBhcHBseSB0byBhbGwgcHJvdG9jb2xzLA0KaW5jbHVkaW5nIElLRSwgYW5k IGl0IGlzIG1vcmUgc3RyaWN0IHRoYW4gd2hhdCB3ZSdkIGFncmVlZCB0byBmb3IgdGlja2V0DQoj MTIyLiAmbmJzcDtJdCBpcyBhbHNvIG1vcmUgc3RyaWN0IHRoYW4gdGhlICZxdW90O01BWSZxdW90 OyBpbiBzZWN0aW9uDQozLjMuMy4gJm5ic3A7U3BlYWtpbmcgb2YgdGlja2V0ICMxMjIsIHRoZSB1 cGRhdGVkIHRleHQgZm9yIHRoYXQgdGlja2V0DQppcyBzb21laG93IG1pc3NpbmcgaW4gdGhpcyBk cmFmdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjMp IEluIHNlY3Rpb24gMy42OiAmcXVvdDtDZXJ0aWZpY2F0ZQ0KcGF5bG9hZHMgU0hPVUxEIGJlIGlu Y2x1ZGVkIGluIGFuIGV4Y2hhbmdlIGlmIGNlcnRpZmljYXRlcyBhcmUgYXZhaWxhYmxlDQp0byB0 aGUgc2VuZGVyIHVubGVzcyB0aGUgcGVlciBoYXMgaW5kaWNhdGVkIGFuIGFiaWxpdHkgdG8gcmV0 cmlldmUgdGhpcw0KaW5mb3JtYXRpb24gZnJvbSBlbHNld2hlcmUgdXNpbmcgYW4gSFRUUF9DRVJU X0xPT0tVUF9TVVBQT1JURUQgTm90aWZ5IHBheWxvYWQuJnF1b3Q7DQombmJzcDtUaGlzIHNlbnRl bmNlIGlzIGluY29oZXJlbnQgLS0gSSB0aGluayBpZiB0aGUgSFRUUF8uLi4gbm90aWZ5IHdhcw0K c2VudCB5b3UnZCBzdGlsbCBpbmNsdWRlIGEgY2VydGlmaWNhdGUgcGF5bG9hZCwgaXQganVzdCB3 b3VsZG4ndCBob2xkIGENCmNlcnRpZmljYXRlLiAmbmJzcDtJJ20gcHJvYmFibHkgbm90IHRoZSBi ZXN0IHBlcnNvbiB0byBzdWdnZXN0IGFsdGVybmF0aXZlDQp3b3JkaW5nLCBidXQgcGVyaGFwcyBz b21ldGhpbmcgbGlrZSAmcXVvdDtDZXJ0aWZpY2F0ZSBwYXlsb2FkcyBTSE9VTEQgYmUNCnVzZWQg dG8gc2VuZCBlbnRpcmUgY2VydGlmaWNhdGVzIGlmIHRoZXkgYXJlIC4uLiZxdW90OzwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+NCkgU2VjdGlvbiAzLjEw LjEgLS0gd2Ugc2hvdWxkIHJlbWVtYmVyDQp0byByZW1vdmUgJnF1b3Q7e3sgRGVtb3RlZCB0aGUg U0hPVUxEIH19JnF1b3Q7IGJlZm9yZSBwdWJsaWNhdGlvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjUpIFNlY3Rpb24gMy4xMy4xLCBleHRyYW5lb3Vz IGNhcGl0YWxpemF0aW9uOjwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNw OyAmbmJzcDtvICZuYnNwO1NlbGVjdG9yIExlbmd0aCAtIFNwZWNpZmllcyB0aGUNCmxlbmd0aCBv ZiB0aGlzIFRyYWZmaWMgU2VsZWN0b3I8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZuYnNwOyAmbmJzcDsgJm5ic3A7IFN1YnN0cnVjdHVyZSBpbmNsdWRpbmcgdGhlIGhlYWRlci48 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDsgJm5ic3A7IF48 L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Nikg U2VjdGlvbiAzLjEzLjEsIGNvdWxkIHByb2JhYmx5IHVzZQ0KYSBsaXR0bGUgdHdlYWtpbmcgdG8g cmVwbGFjZSByZWZlcmVuY2VzIHRvICZxdW90O0lDTVAmcXVvdDsgd2l0aCAmcXVvdDtJQ01QLA0K SUNNUHY2IGFuZCBNSVB2NiZxdW90Oy4gJm5ic3A7QWxzbywgdGhlIHBhcmFncmFwaCBjb250YWlu aW5nICZxdW90O1RoaXMNCmRvY3VtZW50IGRvZXMgbm90IHNwZWNpZnkgaG93IHRvIHJlcHJlc2Vu dCB0aGUgJ01IIFR5cGUnIGZpZWxkIC4uLiZxdW90Ow0KYWN0dWFsbHkgZ29lcyBvbiB0byBzcGVj aWZ5IGp1c3QgdGhhdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPjcpIFNlY3Rpb24gMy4xNCwgJnF1b3Q7VGhlIEVuY3J5cHRlZA0KUGF5bG9hZCwgaWYg cHJlc2VudCBpbiBhIG1lc3NhZ2UsIE1VU1QgYmUgdGhlIGxhc3QgcGF5bG9hZCBpbiB0aGUgbWVz c2FnZS4NCiZuYnNwO09mdGVuLCBpdCBpcyB0aGUgb25seSBwYXlsb2FkIGluIHRoZSBtZXNzYWdl LiZxdW90OyAmbmJzcDtPdXQgb2YNCmN1cmlvc2l0eSwgZG8gd2Uga25vdyBvZiBhbnkgY2FzZXMg d2hlcmUgdGhpcyBwYXlsb2FkIGlzIG5vdCB0aGUgb25seSBwYXlsb2FkDQppbiB0aGUgbWVzc2Fn ZT8gJm5ic3A7SXQgc3RyaWtlcyBtZSBhcyBvZGQgdG8gYWxsb3cgZm9yIHNvbWUgcGF5bG9hZHMg cHJpb3INCnRvIHRoaXMgb25lIHRvIGJlIGludGVncml0eSBwcm90ZWN0ZWQgYnV0IG5vdCBlbmNy eXB0ZWQuICZuYnNwO0kgc3VwcG9zZQ0Kc2luY2UgUkZDIDQzMDYgYWxsb3dzIGl0IHdlIGRvbid0 IGhhdmUgYSBsb3Qgb2Ygd2lnZ2xlIHJvb20gaGVyZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjgpIFNlY3Rpb24gNCwgJnF1b3Q7RXZlcnkgaW1wbGVt ZW50YXRpb24NCk1VU1QgYmUgY2FwYWJsZSBvZiByZXNwb25kaW5nIHRvIGFuIElORk9STUFUSU9O QUwgZXhjaGFuZ2UsIGJ1dCBhIG1pbmltYWwNCmltcGxlbWVudGF0aW9uIE1BWSByZXNwb25kIHRv IGFueSBJTkZPUk1BVElPTkFMIG1lc3NhZ2Ugd2l0aCBhbiBlbXB0eSBJTkZPUk1BVElPTkFMDQpy ZXBseS4mcXVvdDsgJm5ic3A7SXMgdGhhdCB0cnVlIGV2ZW4gaWYgdGhlIElORk9STUFUSU9OQUwg cmVxdWVzdCBjb250YWluZWQNCmEgRGVsZXRlIHBheWxvYWQgZm9yIGEgQ2hpbGQgU0E/PC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj45KSBBcHBlbmRpeCBE IC0tIHdlIG5lZWQgdG8gZmlsbCB0aGlzDQppbi48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNjb3R0IE1vb25lbiAoc21vb25lbkB1cy5pYm0u Y29tKTxicj4NCnovT1MgQ29tbXVuaWNhdGlvbnMgU2VydmVyIFRDUC9JUCBEZXZlbG9wbWVudDxi cj4NCjwvZm9udD48YSBocmVmPWh0dHA6Ly93d3cubGlua2VkaW4uY29tL2luL3Ntb29uZW4+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly93d3cubGlua2VkaW4uY29tL2luL3Nt b29uZW48L2ZvbnQ+PC9hPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5z LXNlcmlmIj5Gcm9tOjwvZm9udD4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ WWFyb24gU2hlZmZlciAmbHQ7eWFyb25mQGNoZWNrcG9pbnQuY29tJmd0OzwvZm9udD4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2Vy aWYiPlRvOjwvZm9udD4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7 aXBzZWNAaWV0Zi5vcmcmcXVvdDsgJmx0O2lwc2VjQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2Vy aWYiPkRhdGU6PC9mb250Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4xMi8x MC8yMDA5IDA0OjA1IEFNPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+PGZvbnQgc2l6ZT0x IGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+U3ViamVjdDo8L2ZvbnQ+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltJUHNlY10gV29ya2luZyBHcm91cCBMQzogZHJh ZnQtaWV0Zi1pcHNlY21lLWlrZXYyYmlzLTA2DQooeWVzLCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtJS0V2Mi1iaXMhKTwvZm9udD48L3RhYmxlPg0KPGJyPg0KPGhyIG5vc2hhZGU+DQo8YnI+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5UaGlzIGlzIHRvIGJl Z2luIGEgNCB3ZWVrIHdvcmtpbmcgZ3JvdXANCmxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1pcHNl Y21lLWlrZXYyYmlzLTA2LiBUaGUgdGFyZ2V0IHN0YXR1cyBmb3IgdGhpcw0KZG9jdW1lbnQgaXMg UHJvcG9zZWQgU3RhbmRhcmQsIG9ic29sZXRpbmcgUkZDIDQzMDYgYW5kIFJGQyA0NzE4LjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlBsZWFzZSBzZW5kIHlvdXIgY29tbWVu dHMgdG8gdGhlIGlwc2VjDQpsaXN0IGJ5IEphbi4gNSwgMjAxMCwgYXMgZm9sbG93LXVwcyB0byB0 aGlzIG1lc3NhZ2UuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+VGhpcyBp cyBhIGxhcmdlIGRvY3VtZW50LCBhbmQgYXJndWFibHkNCnRoZSBtb3N0IGltcG9ydGFudCBkb2N1 bWVudCB0aGlzIFdHIGlzIGVudHJ1c3RlZCB3aXRoLiBUaGUgTEMgcGVyaW9kIGlzDQpsb25nZXIg dGhhbiB1c3VhbCBidXQgd2lsbCBpbmNsdWRlIHZhY2F0aW9uIHRpbWUgZm9yIG1vc3Qgb2YgdXMu IE5ldmVydGhlbGVzcywNCnBsZWFzZSBtYWtlIGFuIGVmZm9ydCB0byByZXZpZXcgdGhlIGVudGly ZSBkb2N1bWVudCwgb3IgYXQgbGVhc3QgbGFyZ2UNCnBvcnRpb25zIG9mIGl0LiBGZWVsIGZyZWUg dG8gcG9zdCBtdWx0aXBsZSBwYXJ0aWFsIHJldmlld3MuPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+SW4gdGhpcyBwYXJ0aWN1bGFyIGNhc2UsIHdlIGFyZSBzdGFydGluZw0K dGhlIHJldmlldyB3aXRoIGEgZmV3IDwvZm9udD48YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5p ZXRmLm9yZy93Zy9pcHNlY21lL3RyYWMvcXVlcnk/c3RhdHVzPW5ldyZhbXA7c3RhdHVzPWFzc2ln bmVkJmFtcDtzdGF0dXM9cmVvcGVuZWQmYW1wO2NvbXBvbmVudD1kcmFmdC1pZXRmLWlwc2VjbWUt aWtldjJiaXMiPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5v cGVuDQppc3N1ZXM8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci Pi4gV2Ugd2lsbCBtYWtlIGFuIGVmZm9ydA0KdG8gY2xvc2UgdGhlbSBkdXJpbmcgdGhlIFdHIExD IHBlcmlvZC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5BcyBhIHJlbWlu ZGVyIHJlZ2FyZGluZyB0aGUgZG9jdW1lbnTigJlzDQpzY29wZSAoYW5kIG91ciBjb25zdHJhaW50 cyB3aGlsZSByZXZpZXdpbmcgaXQpLCBJIHdpbGwgcXVvdGUgZnJvbSBteSBtYWlsDQpvZiBBdWcu IDIwMDg6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+R2VuZXJhbDogVGhl IGdvYWwgb2YgdGhlIElLRXYyIGJpcw0KZG9jdW1lbnQgaXMgdG8gY2xhcmlmeSB0aGUgcHJvdG9j b2wuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5UaGUgZ29hbCBpcyBub3QgdG8gZXh0ZW5kIGl0LiBT cGVjaWZpY2FsbHk6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+KiBUaGUg ZG9jdW1lbnQgd2lsbCBjb21iaW5lIFJGQyA0MzA2DQooSUtFdjIpIGFuZCBSRkMgNDcxOCAoSUtF djI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4gPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Y2xhcmlmaWNhdGlvbnMpLA0KYnV0IG5vIG90aGVyIFJG Q3MuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+KiBUaGUgZG9j dW1lbnQgd2lsbCBhZGQgY2xhcmlmaWNhdGlvbnMNCmJhc2VkIG9uIHRoZSBjb21tdW5pdHknczwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9IkNvdXJpZXIgTmV3Ij5kZXBsb3ltZW50DQpleHBlcmllbmNlLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiogSXQgaXMgT0sgdG8gY29ycmVjdCBtaW5v ciB0ZWNobmljYWwNCmVycm9ycyBhbmQgY29udHJhZGljdGlvbnMgaW4gdGhlPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij5zb3VyY2UgZG9jdW1lbnRzLiBBbnkgc3VjaCBjb3JyZWN0aW9ucw0Kd2lsbCBi ZSBwb2ludGVkIG91dCBleHBsaWNpdGx5IC08L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJp ZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPnByZWZlcmFi bHkgaW4gYW4gYXBwZW5kaXggKHNvIHRoYXQNCnBlb3BsZSB1c2luZyB0aGUgb2xkIGRvY3VtZW50 cyBjYW48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPnNjYW4gaXQgdG8gZGlzY292ZXIgcHJvYmxlbSBh cmVhcykuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+KiBUaGUg ZG9jdW1lbnQgd2lsbCBub3QgYWRkIGFueSAmcXVvdDtuaWNlDQp0byBoYXZlJnF1b3Q7IGV4dGVu c2lvbnMsIG5vIG1hdHRlciBob3c8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3 Ij4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPm11Y2ggdGVjaG5pY2Fs IHNlbnNlIHRoZXkgbWFrZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5Q bGVhc2UgY2xlYXJseSBpbmRpY2F0ZSB0aGUgcG9zaXRpb24NCm9mIGFueSBpc3N1ZSBpbiB0aGUg SW50ZXJuZXQgRHJhZnQsIGFuZCBpZiBwb3NzaWJsZSBwcm92aWRlIGFsdGVybmF0aXZlDQp0ZXh0 LiBQbGVhc2UgYWxzbyBpbmRpY2F0ZSB0aGUgbmF0dXJlIG9yIHNldmVyaXR5IG9mIHRoZSBlcnJv ciBvciBjb3JyZWN0aW9uLA0KZS5nLiBtYWpvciB0ZWNobmljYWwsIG1pbm9yIHRlY2huaWNhbCwg bml0LCBzbyB0aGF0IHdlIGNhbiBxdWlja2x5IGp1ZGdlDQp0aGUgZXh0ZW50IG9mIHByb2JsZW1z IHdpdGggdGhlIGRvY3VtZW50LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PlRoZSBkb2N1bWVudCBjYW4gYmUgYWNjZXNzZWQgaGVyZTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHNlY21lLWlrZXYyYmlzLTA2Ij48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBzZWNtZS1pa2V2MmJpcy0wNjwvdT48L2ZvbnQ+ PC9hPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+VGhhbmtzLDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFlhcm9u PC9mb250Pjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpJUHNlYyBtYWlsaW5nIGxpc3Q8YnI+DQpJUHNlY0BpZXRmLm9y Zzxicj4NCjwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pcHNlYz48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXBzZWM8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8 L2ZvbnQ+PC90dD4NCjxicj4NCjxicj4NCg== --=_alternative 005C448C8525768D_=-- From paul.hoffman@vpnc.org Tue Dec 15 09:26: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 4E3953A68FA for ; Tue, 15 Dec 2009 09:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.958 X-Spam-Level: X-Spam-Status: No, score=-5.958 tagged_above=-999 required=5 tests=[AWL=0.088, 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 18llRoLdDDyK for ; Tue, 15 Dec 2009 09:26: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 48D803A6A9E for ; Tue, 15 Dec 2009 09:26:45 -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 nBFHQUns026030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Dec 2009 10:26:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> Date: Tue, 15 Dec 2009 09:26:25 -0800 To: "ipsec@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) 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, 15 Dec 2009 17:26:46 -0000 At 11:53 AM -0500 12/15/09, Scott C Moonen wrote: >I've finished my read through the draft. Many thanks for the careful review. So, who wants to match or exceed Scott's efforts? We need more eyes on this version of the document before it is ready for IETF Last Call. --Paul Hoffman, Director --VPN Consortium From alper.yegin@yegin.org Tue Dec 15 09:28: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 8A8AE3A688F for ; Tue, 15 Dec 2009 09:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 VGFJmHo7ZYFY for ; Tue, 15 Dec 2009 09:28:20 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 4432A3A67A3 for ; Tue, 15 Dec 2009 09:28:20 -0800 (PST) Received: from LENOVO ([216.123.155.200]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MX2ZI-1NWg1X2cGC-00WRYv; Tue, 15 Dec 2009 12:28:06 -0500 From: "Alper Yegin" To: "'Hui Deng'" References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <1d38a3350912090742q1976ffefo85ef5e0e5627ec0b@mail.gmail.com> <8104339512286448538@unknownmsgid> <1d38a3350912092129v4b4d6f77pc5114e72284ea8da@mail.gmail.com> <-4242183742059278883@unknownmsgid> <1d38a3350912110643r50796cfahdfcd02889fc2bdbd@mail.gmail.com> <4381657317742816904@unknownmsgid> <1d38a3350912140735o2905d611g1b8b0c5483a9458e@mail.gmail.com> In-Reply-To: <1d38a3350912140735o2905d611g1b8b0c5483a9458e@mail.gmail.com> Date: Tue, 15 Dec 2009 19:28:03 +0200 Message-ID: <008a01ca7dab$f6c6be20$e4543a60$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp80wIu8I881XiBTwG9n04DnXgJvQA15mqw Content-Language: en-us X-Provags-ID: V01U2FsdGVkX19pvE13enRzEq6GqbafGuQDJB0verFdXljsx2L k09YrVS0NFMyFVT0OQiDMD2+Y33KJpcW0xXe3pUIOe3BF2430e QvZKi/9PW+ABY0L380+PQ== Cc: ipsec@ietf.org Subject: Re: [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: Tue, 15 Dec 2009 17:28:21 -0000 Hello Hui, If the same box needs to be plugged into networks with different security characteristics, sure you need a stack that can handle all cases. Not sure how this relates to our discussion about hacking up IKEv2 vs using a proper protocol. > I mean normally we won't do two different type authentication > mechanism for the same device. There are different authentication procedures authenticating different entities for different purposes -- all on the same node. You cannot say I have one authentication for all purposes.... Use IKEv2 to "authenticate" IKE peers for establishing IPsec SA, use EAP/foo to "authenticate" subscriber and the access network for network access AAA, use Mobile IP to "authenticate" MN and HA for mobility binding, etc. etc.... The minute you intend to use one as a substitute of another (or all), you are entering the hacking domain.... Alper > -----Original Message----- > From: Hui Deng [mailto:denghui02@gmail.com] > Sent: Monday, December 14, 2009 5:35 PM > To: Alper Yegin > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: Childless IKE SA > > Hi Alper, > > 2009/12/12 Alper Yegin : > > Hi Hui, > > > >> Hi Alper, > >> > >> It seems that your argument goes to 3GPP only not this new work > item, > >> then I would suggest that you propose your solution to 3GPP HNB. > > > > We are having this discussion in IETF right now. So, there is no > point in > > telling us to go elsewhere. If the discussions is here, it is here. > > > > >> Back to your questions, the scenarios is that some user need this > >> IKE/IPsec > >> or other don't need IPsec for the first, and also could be upgraded > to > >> need IKE/IPsec, > > > > Is this a real scenario? I'd like to understand how a user moves from > a > > non-IPsec to IPsec. > It is not handover case, it is just physical link sometime is securied > enough > sometime it is, and some user support this, other are not support this. > > > > > > >> I also found you didn't classify different access authenticaiton > >> protocol. > > > > Could you please elaborate on what exactly you are asking about? > I mean normally we won't do two different type authentication > mechanism for the same device. > > > > > > >> this is not a granularity issue, how could your proposal to support > >> this scenario and migration scenarios simultaneously? > > > > If you can explain to us what migration scenarios you have, we can > discuss > > them. > Secenario above. > > thanks > > -Hui > > > > Thanks. > > > > Alper > > > > > > > > > > > >> > >> thanks > >> > >> -Hui > >> > >> 2009/12/10 Alper Yegin : > >> > Hi Hui, > >> > > >> >> I am not convinced why vendor need implement two security > mechanism > >> to > >> >> one product, > >> >> just because the second one need some market to use it. > >> > > >> > Unfortunately, protocol classification is more granular than that. > >> > You don't identify one protocol as "security protocol" and make it > >> serve all > >> > security related purposes: access authentication, IPsec SA > >> establishment, > >> > transport-layer security, application-layer security, mobility > >> signaling > >> > security, etc. etc. Obviously, you need several distinct protocols > >> for these > >> > things. > >> > > >> > So, saying we have IKEv2, and we'll twist and turn it into some > other > >> > protocol for some other purpose may make sense when you are > looking > >> at > >> > things from within the box (that implements IKEv2), but it does > not > >> make > >> > sense when you are looking from outside the box (like from IETF > >> > perspective). > >> > > >> > Your proposal is for turning IKEv2 into an EAP transport for > generic > >> network > >> > access authentication. It requires taking some stuff out, twisting > >> some > >> > stuff, and adding stuff. It's technically doable, but "IETF" needs > to > >> be > >> > convinced why it needs to reinvent PANA by taking IKEv2 as the > >> baseline. > >> > > >> > Alper > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> >> > >> >> -Hui > >> >> > >> >> 2009/12/10 Alper Yegin : > >> >> > Hi Hui, > >> >> > > >> >> > You named 3GPP as a consumer of this, acknowledged that 3GPP is > >> not > >> >> behind > >> >> > all of the requirements, but you didn't respond to my question > >> about > >> >> which > >> >> > one of the requirements are coming from 3GPP. > >> >> > > >> >> > > >> >> > I object to this work, because it intends to create yet another > >> >> network > >> >> > access authentication protocol out of IKEv2. As you know, PANA > is > >> >> designed > >> >> > for that purpose. IETF community needs to understand why PANA > does > >> >> not fit > >> >> > the need, and why we need to turn IKEv2 into a general-purpose > >> >> network > >> >> > access authentication protocol. (IKE needs to get in line with > the > >> >> other > >> >> > similar proposals, such as hacking up DHCP into access > >> authentication > >> >> > protocol, and even HTTP. I guess everyone has his/her favorite > >> >> protocol to > >> >> > hack.) > >> >> > > >> >> > Similar questions arise for the other motivations. "Liveness > >> >> checking", and > >> >> > "NAT detection".... Turning IKEv2 into a dedicated protocol for > >> these > >> >> > purposes is likely to grow IKE in many unintended directions. > >> >> > > >> >> > Alper > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On > >> >> Behalf > >> >> >> Of Hui Deng > >> >> >> Sent: Wednesday, December 09, 2009 5:42 PM > >> >> >> To: Yaron Sheffer > >> >> >> Cc: ipsec@ietf.org > >> >> >> Subject: Re: [IPsec] Proposed work item: Childless IKE SA > >> >> >> > >> >> >> would like to co-author, thanks > >> >> >> > >> >> >> -Hui > >> >> >> > >> >> >> 2009/11/30 Yaron Sheffer : > >> >> >> > 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- > >> >> >> childless-01.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 > >> >> >> > > >> >> >> _______________________________________________ > >> >> >> IPsec mailing list > >> >> >> IPsec@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/ipsec > >> >> > > >> >> > _______________________________________________ > >> >> > IPsec mailing list > >> >> > IPsec@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/ipsec > >> >> > > >> > > >> > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > From paul.hoffman@vpnc.org Tue Dec 15 10:55: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 B59263A688F for ; Tue, 15 Dec 2009 10:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.96 X-Spam-Level: X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=0.086, 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 O1Db+F0YcOKd for ; Tue, 15 Dec 2009 10:55:51 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B49D93A687E for ; Tue, 15 Dec 2009 10:55:51 -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 nBFItafY031954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Dec 2009 11:55:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> Date: Tue, 15 Dec 2009 10:54:46 -0800 To: Scott C Moonen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) 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, 15 Dec 2009 18:55:52 -0000 At 11:53 AM -0500 12/15/09, Scott C Moonen wrote: >1) There are excessive spaces on the second lines of these list items in section 2.23: Fixed. >2) In section 3.3, this sentence: "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." seems to apply to all protocols, including IKE, and it is more strict than what we'd agreed to for ticket #122. It is also more strict than the "MAY" in section 3.3.3. Speaking of ticket #122, the updated text for that ticket is somehow missing in this draft. #122 is being fixed in the next draft, not the current draft. In it, I removed the sentence you have a problem with. >3) In section 3.6: "Certificate payloads SHOULD be included in an exchange if certificates are available to the sender unless the peer has indicated an ability to retrieve this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload." This sentence is incoherent -- I think if the HTTP_... notify was sent you'd still include a certificate payload, it just wouldn't hold a certificate. I'm probably not the best person to suggest alternative wording, but perhaps something like "Certificate payloads SHOULD be used to send entire certificates if they are ..." This has been in the document for quite a while. If it is important to you, please open a new ticket for it and start a thread. >4) Section 3.10.1 -- we should remember to remove "{{ Demoted the SHOULD }}" before publication. Yarrgh. So much for my regexps. Removed. >5) Section 3.13.1, extraneous capitalization: > > o Selector Length - Specifies the length of this Traffic Selector > Substructure including the header. > ^ Fixed. >6) Section 3.13.1, could probably use a little tweaking to replace references to "ICMP" with "ICMP, ICMPv6 and MIPv6". Also, the paragraph containing "This document does not specify how to represent the 'MH Type' field ..." actually goes on to specify just that. Disagree. The WG has not even begun to think about ICMPv6 and MIPv6, so saying anything could lead readers to make assumptions that could end badly. >7) Section 3.14, "The Encrypted Payload, if present in a message, MUST be the last payload in the message. Often, it is the only payload in the message." Out of curiosity, do we know of any cases where this payload is not the only payload in the message? It strikes me as odd to allow for some payloads prior to this one to be integrity protected but not encrypted. I suppose since RFC 4306 allows it we don't have a lot of wiggle room here. Exactly. We don't need to prohibit it, just cast aspersions on it. >8) Section 4, "Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL reply." Is that true even if the INFORMATIONAL request contained a Delete payload for a Child SA? Opened as Issue #128, on which I will start a new thread. --Paul Hoffman, Director --VPN Consortium From Nicolas.Williams@sun.com Tue Dec 15 11: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 BBB4F3A6909 for ; Tue, 15 Dec 2009 11:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.084 X-Spam-Level: X-Spam-Status: No, score=-5.084 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] 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 u9aqZY0xR9IB for ; Tue, 15 Dec 2009 11:00:28 -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 9D4A33A68BC for ; Tue, 15 Dec 2009 11:00:28 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBFJ0Eb8016616 for ; Tue, 15 Dec 2009 19:00:14 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nBFJ0DTe053262 for ; Tue, 15 Dec 2009 12:00:13 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nBFIbhKN004849; Tue, 15 Dec 2009 12:37:43 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBFIbgHn004848; Tue, 15 Dec 2009 12:37:42 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 15 Dec 2009 12:37:42 -0600 From: Nicolas Williams To: Alper Yegin Message-ID: <20091215183742.GV1516@Sun.COM> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <1d38a3350912090742q1976ffefo85ef5e0e5627ec0b@mail.gmail.com> <023f01ca7908$480951b0$d81bf510$%yegin@yegin.org> <3824040C-7D40-4B46-B430-AE87D6729A19@checkpoint.com> <02c401ca7970$974303d0$c5c90b70$%yegin@yegin.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02c401ca7970$974303d0$c5c90b70$%yegin@yegin.org> User-Agent: Mutt/1.5.7i Cc: 'Hui Deng' , ipsec@ietf.org, 'Yoav Nir' Subject: Re: [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: Tue, 15 Dec 2009 19:00:29 -0000 On Thu, Dec 10, 2009 at 10:12:54AM +0200, Alper Yegin wrote: > > The "Do phase 1 first, and phase 2 as traffic demands it" motivation is > > from the remote access VPN domain (though may be useful for others). > > > > The "Do only phase 1, because we don't need encryption and MAC, just > > peer authentication" motivation is from the 3GPP (though it could be > > useful for others) > > > > The "Do only phase 1 to discover if we're in or out of the secure > > network (then do phase 2 if we're out)" motivation is also mostly a > > remote access VPN thing. > > > > The other motivations were from suggestions by others, and will be > > hashed out (or taken out of the document) should this become a WG > > document. > > I'm particularly concerned about reinventing the wheel aspect with your > second bullet, as I elaborated in response to Hui in my previous email. > > As for the other motivations, I'm not sure the savings are worth the effort. > Imho.... Suppose you want a combination of "peer authentication only" for some traffic and "peer authentication + ESP/AH" for other kinds of traffic (think of this as differentiated services). Then to use PANA for one and IPsec for the other seems silly. I don't see why an applicability statement should not suffice to prevent the scenario that you dislike (which I think is: IKEv2 displacing PANA where IKEv2 should be considered to not be applicable). But see below. The issue to settle here, as I see it, is: are there any uses of childless IKEv2 SAs that justify the work? Of the various use case scenarios given in the I-D the first is the most convincing, though the lack of childless IKEv2 SAs hardly seems problematic there. The last use case is very interesting, but very forward looking. The next to last use case is specific to an EAP method, thus not very interesting to this WG (IMO) except as a way to keep divergence between base spec and the EAP method to a minimum. The other use case scenarios seem to encroach on the applicability of PANA. Just based on that my support is lukewarm. Quite aside from that, I question the applicability statement that you seem to be making. PANA and IKEv2-with-childless-SAs seem roughly equivalent, with IKEv2 being more general. Why should we forbid use of the latter for network access control? Certainly having two such protocols is not exactly desirable, but it's not clear to me that PANA is the protocol that should win. What's really not desirable is non- interoperability, and that, I believe, we can achieve by making PANA the required to implement network access protocol. I don't see why we couldn't let IKEv2 have a go at displacing PANA in the marketplace. If there is support in the WG for it, so be it. Nico -- From paul.hoffman@vpnc.org Tue Dec 15 11:23: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 5C4003A67A6 for ; Tue, 15 Dec 2009 11:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.962 X-Spam-Level: X-Spam-Status: No, score=-5.962 tagged_above=-999 required=5 tests=[AWL=0.084, 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 s2KepMz65EKy for ; Tue, 15 Dec 2009 11:23:28 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 6F4713A677C for ; Tue, 15 Dec 2009 11:23:28 -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 nBFItafa031954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Dec 2009 11:55:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 15 Dec 2009 10:55:35 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Issue #128: Can implementations not reply fully to Deletes? 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, 15 Dec 2009 19:23:29 -0000 Section 1.4.1 says: Normally, the reply in the INFORMATIONAL exchange will contain delete payloads for the paired SAs going in the other direction. There is one exception. If by chance both ends of a set of SAs independently decide to close them, each may send a delete payload and the two requests may cross in the network. But, Section 4 (conformance requirements), says: Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL reply. What should we do? Changing the conformance requirement is pretty serious, but not telling the other side that you understand the Delete is also serious. --Paul Hoffman, Director --VPN Consortium From smoonen@us.ibm.com Tue Dec 15 11: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 700E23A6882 for ; Tue, 15 Dec 2009 11:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.025 X-Spam-Level: X-Spam-Status: No, score=-4.025 tagged_above=-999 required=5 tests=[AWL=-1.427, 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 zmfZmN+opB+r for ; Tue, 15 Dec 2009 11:29:22 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id D12443A67DF for ; Tue, 15 Dec 2009 11:29:21 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e37.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nBFJRjrN030221 for ; Tue, 15 Dec 2009 12:27:45 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBFJSv8x190310 for ; Tue, 15 Dec 2009 12:28:57 -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 nBFJSZwC020775 for ; Tue, 15 Dec 2009 12:28:35 -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 nBFJSZ0H020768; Tue, 15 Dec 2009 12:28:35 -0700 In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> To: Paul Hoffman MIME-Version: 1.0 X-KeepSent: C896E585:2F394ABD-8525768D:006A9DF8; 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 12/15/2009 02:28:15 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 12/15/2009 02:28:15 PM, Serialize complete at 12/15/2009 02:28:15 PM, S/MIME Sign failed at 12/15/2009 02:28:15 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 12/15/2009 12:28:35, Serialize complete at 12/15/2009 12:28:35 Message-ID: Date: Tue, 15 Dec 2009 14:28:34 -0500 Content-Type: multipart/alternative; boundary="=_alternative 006AF5048525768D_=" Cc: "ipsec@ietf.org" Subject: [IPsec] Certificate payloads and HTTP 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, 15 Dec 2009 19:29:23 -0000 This is a multipart message in MIME format. --=_alternative 006AF5048525768D_= Content-Type: text/plain; charset="US-ASCII" > >3) In section 3.6: "Certificate payloads SHOULD be included in an > > exchange if certificates are available to the sender unless the > > peer has indicated an ability to retrieve this information from > > elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload." > > This sentence is incoherent -- I think if the HTTP_... notify was > > sent you'd still include a certificate payload, it just wouldn't > > hold a certificate. I'm probably not the best person to suggest > > alternative wording, but perhaps something like "Certificate > > payloads SHOULD be used to send entire certificates if they are ..." > > This has been in the document for quite a while. If it is important to > you, please open a new ticket for it and start a thread. I'll defer to others who are more familiar with the certificate payload, 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: "ipsec@ietf.org" Date: 12/15/2009 01:55 PM Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) At 11:53 AM -0500 12/15/09, Scott C Moonen wrote: >1) There are excessive spaces on the second lines of these list items in section 2.23: Fixed. >2) In section 3.3, this sentence: "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." seems to apply to all protocols, including IKE, and it is more strict than what we'd agreed to for ticket #122. It is also more strict than the "MAY" in section 3.3.3. Speaking of ticket #122, the updated text for that ticket is somehow missing in this draft. #122 is being fixed in the next draft, not the current draft. In it, I removed the sentence you have a problem with. >3) In section 3.6: "Certificate payloads SHOULD be included in an exchange if certificates are available to the sender unless the peer has indicated an ability to retrieve this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload." This sentence is incoherent -- I think if the HTTP_... notify was sent you'd still include a certificate payload, it just wouldn't hold a certificate. I'm probably not the best person to suggest alternative wording, but perhaps something like "Certificate payloads SHOULD be used to send entire certificates if they are ..." This has been in the document for quite a while. If it is important to you, please open a new ticket for it and start a thread. >4) Section 3.10.1 -- we should remember to remove "{{ Demoted the SHOULD }}" before publication. Yarrgh. So much for my regexps. Removed. >5) Section 3.13.1, extraneous capitalization: > > o Selector Length - Specifies the length of this Traffic Selector > Substructure including the header. > ^ Fixed. >6) Section 3.13.1, could probably use a little tweaking to replace references to "ICMP" with "ICMP, ICMPv6 and MIPv6". Also, the paragraph containing "This document does not specify how to represent the 'MH Type' field ..." actually goes on to specify just that. Disagree. The WG has not even begun to think about ICMPv6 and MIPv6, so saying anything could lead readers to make assumptions that could end badly. >7) Section 3.14, "The Encrypted Payload, if present in a message, MUST be the last payload in the message. Often, it is the only payload in the message." Out of curiosity, do we know of any cases where this payload is not the only payload in the message? It strikes me as odd to allow for some payloads prior to this one to be integrity protected but not encrypted. I suppose since RFC 4306 allows it we don't have a lot of wiggle room here. Exactly. We don't need to prohibit it, just cast aspersions on it. >8) Section 4, "Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL reply." Is that true even if the INFORMATIONAL request contained a Delete payload for a Child SA? Opened as Issue #128, on which I will start a new thread. --Paul Hoffman, Director --VPN Consortium --=_alternative 006AF5048525768D_= Content-Type: text/html; charset="US-ASCII"
> >3) In section 3.6: "Certificate payloads SHOULD be included in an
> >   exchange if certificates are available to the sender unless the
> >   peer has indicated an ability to retrieve this information from
> >   elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload."
> >   This sentence is incoherent -- I think if the HTTP_... notify was
> >   sent you'd still include a certificate payload, it just wouldn't
> >   hold a certificate.  I'm probably not the best person to suggest
> >   alternative wording, but perhaps something like "Certificate
> >   payloads SHOULD be used to send entire certificates if they are ..."
>
> This has been in the document for quite a while. If it is important to
> you, please open a new ticket for it and start a thread.

I'll defer to others who are more familiar with the certificate payload,


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: "ipsec@ietf.org" <ipsec@ietf.org>
Date: 12/15/2009 01:55 PM
Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes,         IKEv2-bis!)




At 11:53 AM -0500 12/15/09, Scott C Moonen wrote:
>1) There are excessive spaces on the second lines of these list items in section 2.23:

Fixed.

>2) In section 3.3, this sentence: "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." seems to apply to all protocols, including IKE, and it is more strict than what we'd agreed to for ticket #122.  It is also more strict than the "MAY" in section 3.3.3.  Speaking of ticket #122, the updated text for that ticket is somehow missing in this draft.

#122 is being fixed in the next draft, not the current draft. In it, I removed the sentence you have a problem with.

>3) In section 3.6: "Certificate payloads SHOULD be included in an exchange if certificates are available to the sender unless the peer has indicated an ability to retrieve this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload."  This sentence is incoherent -- I think if the HTTP_... notify was sent you'd still include a certificate payload, it just wouldn't hold a certificate.  I'm probably not the best person to suggest alternative wording, but perhaps something like "Certificate payloads SHOULD be used to send entire certificates if they are ..."

This has been in the document for quite a while. If it is important to you, please open a new ticket for it and start a thread.

>4) Section 3.10.1 -- we should remember to remove "{{ Demoted the SHOULD }}" before publication.

Yarrgh. So much for my regexps. Removed.

>5) Section 3.13.1, extraneous capitalization:
>
>   o  Selector Length - Specifies the length of this Traffic Selector
>      Substructure including the header.
>      ^

Fixed.

>6) Section 3.13.1, could probably use a little tweaking to replace references to "ICMP" with "ICMP, ICMPv6 and MIPv6".  Also, the paragraph containing "This document does not specify how to represent the 'MH Type' field ..." actually goes on to specify just that.

Disagree. The WG has not even begun to think about ICMPv6 and MIPv6, so saying anything could lead readers to make assumptions that could end badly.

>7) Section 3.14, "The Encrypted Payload, if present in a message, MUST be the last payload in the message.  Often, it is the only payload in the message."  Out of curiosity, do we know of any cases where this payload is not the only payload in the message?  It strikes me as odd to allow for some payloads prior to this one to be integrity protected but not encrypted.  I suppose since RFC 4306 allows it we don't have a lot of wiggle room here.

Exactly. We don't need to prohibit it, just cast aspersions on it.

>8) Section 4, "Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL reply."  Is that true even if the INFORMATIONAL request contained a Delete payload for a Child SA?

Opened as Issue #128, on which I will start a new thread.

--Paul Hoffman, Director
--VPN Consortium

--=_alternative 006AF5048525768D_=-- From smoonen@us.ibm.com Tue Dec 15 11: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 8C2673A67DF for ; Tue, 15 Dec 2009 11:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=0.692, 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 WHJFjty0C9zx for ; Tue, 15 Dec 2009 11:29:22 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id D7B583A67F3 for ; Tue, 15 Dec 2009 11:29:21 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nBFJQ6Z9007240 for ; Tue, 15 Dec 2009 12:26:06 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBFJSvHW115480 for ; Tue, 15 Dec 2009 12:28:57 -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 nBFJSZC5020772 for ; Tue, 15 Dec 2009 12:28:35 -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 nBFJSZ0G020768; Tue, 15 Dec 2009 12:28:35 -0700 In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> To: Paul Hoffman MIME-Version: 1.0 X-KeepSent: 61CF63D7:BEE57F7B-8525768D:0068C432; 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 12/15/2009 02:24:29 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 12/15/2009 02:24:29 PM, Serialize complete at 12/15/2009 02:24:29 PM, S/MIME Sign failed at 12/15/2009 02:24:29 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 12/15/2009 12:28:35, Serialize complete at 12/15/2009 12:28:35 Message-ID: Date: Tue, 15 Dec 2009 14:28:33 -0500 Content-Type: multipart/alternative; boundary="=_alternative 006A9C968525768D_=" Cc: "ipsec@ietf.org" Subject: [IPsec] Traffic Selector and ICMPv6/MIPv6 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, 15 Dec 2009 19:29:23 -0000 This is a multipart message in MIME format. --=_alternative 006A9C968525768D_= Content-Type: text/plain; charset="US-ASCII" > >6) Section 3.13.1, could probably use a little tweaking to replace > > references to "ICMP" with "ICMP, ICMPv6 and MIPv6". Also, the > > paragraph containing "This document does not specify how to > > represent the 'MH Type' field ..." actually goes on to specify > > just that. > > Disagree. The WG has not even begun to think about ICMPv6 and MIPv6, > so saying anything could lead readers to make assumptions that could > end badly. But RFC 4301 already specifies this in section 4.4.1.1. Given this, I think it's incorrect to treat this as unspecified in ikev2bis: * If the Next Layer Protocol is a Mobility Header, . . . For IKE, the IPv6 Mobility Header message type (MH type) is placed in the most significant eight bits of the 16-bit local "port" selector. * If the Next Layer Protocol value is ICMP, . . . For IKE, the message type is placed in the most significant 8 bits of the 16-bit selector and the code is placed in the least significant 8 bits. . . . It's less clear that this addresses ICMPv6 than MIPv6, but but elsewhere in the document "ICMP" is explicitly used in a generic sense, and I think we're on pretty good ground for both. I'm aware of at least one implementation other than ours that uses both MH type and ICMPv6 type/code in this fashion in IKEv2. I'd be willing to work on alternative text for 3.13.1 if others agree, 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: "ipsec@ietf.org" Date: 12/15/2009 01:55 PM Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) At 11:53 AM -0500 12/15/09, Scott C Moonen wrote: >1) There are excessive spaces on the second lines of these list items in section 2.23: Fixed. >2) In section 3.3, this sentence: "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." seems to apply to all protocols, including IKE, and it is more strict than what we'd agreed to for ticket #122. It is also more strict than the "MAY" in section 3.3.3. Speaking of ticket #122, the updated text for that ticket is somehow missing in this draft. #122 is being fixed in the next draft, not the current draft. In it, I removed the sentence you have a problem with. >3) In section 3.6: "Certificate payloads SHOULD be included in an exchange if certificates are available to the sender unless the peer has indicated an ability to retrieve this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload." This sentence is incoherent -- I think if the HTTP_... notify was sent you'd still include a certificate payload, it just wouldn't hold a certificate. I'm probably not the best person to suggest alternative wording, but perhaps something like "Certificate payloads SHOULD be used to send entire certificates if they are ..." This has been in the document for quite a while. If it is important to you, please open a new ticket for it and start a thread. >4) Section 3.10.1 -- we should remember to remove "{{ Demoted the SHOULD }}" before publication. Yarrgh. So much for my regexps. Removed. >5) Section 3.13.1, extraneous capitalization: > > o Selector Length - Specifies the length of this Traffic Selector > Substructure including the header. > ^ Fixed. >6) Section 3.13.1, could probably use a little tweaking to replace references to "ICMP" with "ICMP, ICMPv6 and MIPv6". Also, the paragraph containing "This document does not specify how to represent the 'MH Type' field ..." actually goes on to specify just that. Disagree. The WG has not even begun to think about ICMPv6 and MIPv6, so saying anything could lead readers to make assumptions that could end badly. >7) Section 3.14, "The Encrypted Payload, if present in a message, MUST be the last payload in the message. Often, it is the only payload in the message." Out of curiosity, do we know of any cases where this payload is not the only payload in the message? It strikes me as odd to allow for some payloads prior to this one to be integrity protected but not encrypted. I suppose since RFC 4306 allows it we don't have a lot of wiggle room here. Exactly. We don't need to prohibit it, just cast aspersions on it. >8) Section 4, "Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL reply." Is that true even if the INFORMATIONAL request contained a Delete payload for a Child SA? Opened as Issue #128, on which I will start a new thread. --Paul Hoffman, Director --VPN Consortium --=_alternative 006A9C968525768D_= Content-Type: text/html; charset="US-ASCII"
> >6) Section 3.13.1, could probably use a little tweaking to replace
> >   references to "ICMP" with "ICMP, ICMPv6 and MIPv6".  Also, the
> >   paragraph containing "This document does not specify how to
> >   represent the 'MH Type' field ..." actually goes on to specify
> >   just that.
>
> Disagree. The WG has not even begun to think about ICMPv6 and MIPv6,
> so saying anything could lead readers to make assumptions that could
> end badly.

But RFC 4301 already specifies this in section 4.4.1.1.  Given this, I think it's incorrect to treat this as unspecified in ikev2bis:

         * If the Next Layer Protocol is a Mobility Header, . . .
           For IKE, the IPv6 Mobility Header
           message type (MH type) is placed in the most significant
           eight bits of the 16-bit local "port" selector.

         * If the Next Layer Protocol value is ICMP, . . .
           For IKE, the message type is placed in the most significant 8
           bits of the 16-bit selector and the code is placed in the
           least significant 8 bits. . . .

It's less clear that this addresses ICMPv6 than MIPv6, but but elsewhere in the document "ICMP" is explicitly used in a generic sense, and I think we're on pretty good ground for both.  I'm aware of at least one implementation other than ours that uses both MH type and ICMPv6 type/code in this fashion in IKEv2.

I'd be willing to work on alternative text for 3.13.1 if others agree,


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: "ipsec@ietf.org" <ipsec@ietf.org>
Date: 12/15/2009 01:55 PM
Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes,         IKEv2-bis!)




At 11:53 AM -0500 12/15/09, Scott C Moonen wrote:
>1) There are excessive spaces on the second lines of these list items in section 2.23:

Fixed.

>2) In section 3.3, this sentence: "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." seems to apply to all protocols, including IKE, and it is more strict than what we'd agreed to for ticket #122.  It is also more strict than the "MAY" in section 3.3.3.  Speaking of ticket #122, the updated text for that ticket is somehow missing in this draft.

#122 is being fixed in the next draft, not the current draft. In it, I removed the sentence you have a problem with.

>3) In section 3.6: "Certificate payloads SHOULD be included in an exchange if certificates are available to the sender unless the peer has indicated an ability to retrieve this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload."  This sentence is incoherent -- I think if the HTTP_... notify was sent you'd still include a certificate payload, it just wouldn't hold a certificate.  I'm probably not the best person to suggest alternative wording, but perhaps something like "Certificate payloads SHOULD be used to send entire certificates if they are ..."

This has been in the document for quite a while. If it is important to you, please open a new ticket for it and start a thread.

>4) Section 3.10.1 -- we should remember to remove "{{ Demoted the SHOULD }}" before publication.

Yarrgh. So much for my regexps. Removed.

>5) Section 3.13.1, extraneous capitalization:
>
>   o  Selector Length - Specifies the length of this Traffic Selector
>      Substructure including the header.
>      ^

Fixed.

>6) Section 3.13.1, could probably use a little tweaking to replace references to "ICMP" with "ICMP, ICMPv6 and MIPv6".  Also, the paragraph containing "This document does not specify how to represent the 'MH Type' field ..." actually goes on to specify just that.

Disagree. The WG has not even begun to think about ICMPv6 and MIPv6, so saying anything could lead readers to make assumptions that could end badly.

>7) Section 3.14, "The Encrypted Payload, if present in a message, MUST be the last payload in the message.  Often, it is the only payload in the message."  Out of curiosity, do we know of any cases where this payload is not the only payload in the message?  It strikes me as odd to allow for some payloads prior to this one to be integrity protected but not encrypted.  I suppose since RFC 4306 allows it we don't have a lot of wiggle room here.

Exactly. We don't need to prohibit it, just cast aspersions on it.

>8) Section 4, "Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty INFORMATIONAL reply."  Is that true even if the INFORMATIONAL request contained a Delete payload for a Child SA?

Opened as Issue #128, on which I will start a new thread.

--Paul Hoffman, Director
--VPN Consortium

--=_alternative 006A9C968525768D_=-- From paul.hoffman@vpnc.org Tue Dec 15 13:29: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 718E53A6919 for ; Tue, 15 Dec 2009 13:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.963 X-Spam-Level: X-Spam-Status: No, score=-5.963 tagged_above=-999 required=5 tests=[AWL=0.083, 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 vx8ECK6Drs5k for ; Tue, 15 Dec 2009 13:29: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 A1F693A67D3 for ; Tue, 15 Dec 2009 13:29:54 -0800 (PST) Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBFLTY7J042281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Dec 2009 14:29:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> Date: Tue, 15 Dec 2009 13:29:28 -0800 To: Scott C Moonen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" Subject: [IPsec] Issue #129: Traffic Selector and ICMPv6/MIPv6 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, 15 Dec 2009 21:29:55 -0000 At 2:28 PM -0500 12/15/09, Scott C Moonen wrote: >But RFC 4301 already specifies this in section 4.4.1.1. Given this, I think it's incorrect to treat this as unspecified in ikev2bis: > > * If the Next Layer Protocol is a Mobility Header, . . . > For IKE, the IPv6 Mobility Header > message type (MH type) is placed in the most significant > eight bits of the 16-bit local "port" selector. > > * If the Next Layer Protocol value is ICMP, . . . > For IKE, the message type is placed in the most significant 8 > bits of the 16-bit selector and the code is placed in the > least significant 8 bits. . . . > >It's less clear that this addresses ICMPv6 than MIPv6, but but elsewhere in the document "ICMP" is explicitly used in a generic sense, and I think we're on pretty good ground for both. I'm aware of at least one implementation other than ours that uses both MH type and ICMPv6 type/code in this fashion in IKEv2. > >I'd be willing to work on alternative text for 3.13.1 if others agree, The ticket is assigned to you. :-) --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Tue Dec 15 14:03: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 7135E3A6875 for ; Tue, 15 Dec 2009 14:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 PCNPSugJRZAF for ; Tue, 15 Dec 2009 14:03:53 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 3C29B3A6AFA for ; Tue, 15 Dec 2009 14:03:53 -0800 (PST) X-CheckPoint: {4B2806EB-10001-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id EC78829C005; Wed, 16 Dec 2009 00:03:38 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D59E529C002; Wed, 16 Dec 2009 00:03:38 +0200 (IST) X-CheckPoint: {4B2806EA-10000-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBFM3cT7027667; Wed, 16 Dec 2009 00:03: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; Wed, 16 Dec 2009 00:03:49 +0200 From: Yoav Nir To: Paul Hoffman , IPsecme WG Date: Wed, 16 Dec 2009 00:01:44 +0200 Thread-Topic: [IPsec] Issue #128: Can implementations not reply fully to Deletes? Thread-Index: Acp9vBbpXW3oTwl2RpGoxY1OQPeuGAAFhmKV Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A4EC57A@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] Issue #128: Can implementations not reply fully to Deletes? 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, 15 Dec 2009 22:03:54 -0000 Section 1.4.1 also says: "A node MAY refuse to accept incoming data on half-closed connections but MUST NOT unilaterally close them and reuse the SPIs." So if your peer is only responding with empty INFORMATIONAL responses to yo= ur deletes, you're going to accumulate more and more stale inbound SAs. O= ne of these statements has to go. ________________________________________ From: ipsec-bounces@ietf.org [ipsec-bounces@ietf.org] On Behalf Of Paul Hof= fman [paul.hoffman@vpnc.org] Sent: Tuesday, December 15, 2009 20:55 To: IPsecme WG Subject: [IPsec] Issue #128: Can implementations not reply fully to Deletes= ? Section 1.4.1 says: Normally, the reply in the INFORMATIONAL exchange will = contain delete payloads for the paired SAs going in the other direction. Th= ere is one exception. If by chance both ends of a set of SAs independently = decide to close them, each may send a delete payload and the two requests m= ay cross in the network. But, Section 4 (conformance requirements), says: Every implementation MUST = be capable of responding to an INFORMATIONAL exchange, but a minimal implem= entation MAY respond to any INFORMATIONAL message with an empty INFORMATION= AL reply. What should we do? Changing the conformance requirement is pretty serious, = but not telling the other side that you understand the Delete is also serio= us. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. From yaronf@checkpoint.com Tue Dec 15 14:18: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 1F68B3A6B11 for ; Tue, 15 Dec 2009 14:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 YcwTlgL6iMf5 for ; Tue, 15 Dec 2009 14:18:28 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 93F603A6894 for ; Tue, 15 Dec 2009 14:18:27 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBFMICT7029858; Wed, 16 Dec 2009 00:18:12 +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, 16 Dec 2009 00:18:23 +0200 From: Yaron Sheffer To: Yoav Nir , Paul Hoffman , IPsecme WG Date: Wed, 16 Dec 2009 00:15:02 +0200 Thread-Topic: [IPsec] Issue #128: Can implementations not reply fully to Deletes? Thread-Index: Acp9vBbpXW3oTwl2RpGoxY1OQPeuGAAFhmKVAAB26RU= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A82B@il-ex01.ad.checkpoint.com> References: , <006FEB08D9C6444AB014105C9AEB133FB36A4EC57A@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EC57A@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: Re: [IPsec] Issue #128: Can implementations not reply fully to Deletes? 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, 15 Dec 2009 22:18:29 -0000 This seems to prove that no such "minimal implementations" exist, because t= hey would leak memory like crazy. So we could simply say that INFORMATIONAL= messages containing DELETE payloads are an exception to the "you may retur= n an empty INFORMATIONAL" rule. Thanks, Yaron ________________________________________ From: ipsec-bounces@ietf.org [ipsec-bounces@ietf.org] On Behalf Of Yoav Nir= [ynir@checkpoint.com] Sent: Wednesday, December 16, 2009 12:01 AM To: Paul Hoffman; IPsecme WG Subject: Re: [IPsec] Issue #128: Can implementations not reply fully to Del= etes? Section 1.4.1 also says: "A node MAY refuse to accept incoming data on half-closed connections but MUST NOT unilaterally close them and reuse the SPIs." So if your peer is only responding with empty INFORMATIONAL responses to yo= ur deletes, you're going to accumulate more and more stale inbound SAs. O= ne of these statements has to go. ________________________________________ From: ipsec-bounces@ietf.org [ipsec-bounces@ietf.org] On Behalf Of Paul Hof= fman [paul.hoffman@vpnc.org] Sent: Tuesday, December 15, 2009 20:55 To: IPsecme WG Subject: [IPsec] Issue #128: Can implementations not reply fully to Deletes= ? Section 1.4.1 says: Normally, the reply in the INFORMATIONAL exchange will = contain delete payloads for the paired SAs going in the other direction. Th= ere is one exception. If by chance both ends of a set of SAs independently = decide to close them, each may send a delete payload and the two requests m= ay cross in the network. But, Section 4 (conformance requirements), says: Every implementation MUST = be capable of responding to an INFORMATIONAL exchange, but a minimal implem= entation MAY respond to any INFORMATIONAL message with an empty INFORMATION= AL reply. What should we do? Changing the conformance requirement is pretty serious, = but not telling the other side that you understand the Delete is also serio= us. --Paul Hoffman, Director --VPN Consortium _______________________________________________ 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 Scanned by Check Point Total Security Gateway. From rahul.bharadhwaj@gmail.com Tue Dec 15 20:36: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 385CB3A6968 for ; Tue, 15 Dec 2009 20:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.088, 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 xomVWMGr0jWb for ; Tue, 15 Dec 2009 20:36:39 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 6E04F3A63EC for ; Tue, 15 Dec 2009 20:36:39 -0800 (PST) Received: by iwn33 with SMTP id 33so453897iwn.29 for ; Tue, 15 Dec 2009 20:36: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=qjjeIti+gbyN/DrIxqQJIiYJqBnnFplBh2cUolb7KU4=; b=vElEymsEu7AxIYLSKiCh2NHsFRSUapc5Oz5LNl4lUj25kka97/GhZLkMfnH23bzLhS m88um50k6gAv+MKwsegCfOgHD6Nj4xdlw+kmaqkkFGKJ1OcBb1COV5PrHqzveGDcU1U+ LydqGbLbl1Lk/5SXFFttAZSv40gaVomiQBSe0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=boZJCnvtq/WgfOfZHp1cJqCFV+yYPdad2fap9N6rvU9XHzeMfehQfvdmfBKNOXn3Dw Nc/XHYz5BFXUpsNmU8uwDLtYQ56B1brEtafr16iv7XlaKGBgtjndqDod/vApQmvr+Raj z5HWdyg8/Ak9k5Su6Q8ILCgKW5g4W3Mtpm1+w= MIME-Version: 1.0 Received: by 10.231.120.136 with SMTP id d8mr513012ibr.14.1260938183214; Tue, 15 Dec 2009 20:36:23 -0800 (PST) Date: Wed, 16 Dec 2009 10:06:23 +0530 Message-ID: <53944c010912152036i4a758d0eu948dd6416a55b1cb@mail.gmail.com> From: rahul bharadhwaj To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=0016e644c18e7e860c047ad10c6e Subject: [IPsec] crypting with aes-xcbc-mac hashing 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, 16 Dec 2009 04:36:40 -0000 --0016e644c18e7e860c047ad10c6e Content-Type: text/plain; charset=ISO-8859-1 Hi all Could anyone let me know which crypt algo des/3des/aes should be used with aes-xcbc-mac hashing. As aes-xcbc-mac uses aes for authentication and integrity, is it correct to apply des for encryption or is there any restriction. Thanks in advance rb --0016e644c18e7e860c047ad10c6e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all

Could anyone let me know which crypt algo des/3des/aes should= be used=A0 with=A0 aes-xcbc-mac hashing.

As aes-xcbc-mac uses aes f= or authentication and integrity, is it correct to apply des for encryption = or is there any restriction.

Thanks in advance
rb
--0016e644c18e7e860c047ad10c6e-- From ynir@checkpoint.com Wed Dec 16 00:12: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 B30483A695B for ; Wed, 16 Dec 2009 00:12:34 -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 Mfi-hs9KWgjm for ; Wed, 16 Dec 2009 00:12:02 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id C7B763A695E for ; Wed, 16 Dec 2009 00:11:48 -0800 (PST) X-CheckPoint: {4B289560-10005-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 199F529C005; Wed, 16 Dec 2009 10:11:33 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 03F9729C002; Wed, 16 Dec 2009 10:11:33 +0200 (IST) X-CheckPoint: {4B289560-10000-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBG8BWT7022243; Wed, 16 Dec 2009 10:11:32 +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, 16 Dec 2009 10:11:43 +0200 From: Yoav Nir To: Yaron Sheffer Date: Wed, 16 Dec 2009 10:11:28 +0200 Thread-Topic: [IPsec] Issue #128: Can implementations not reply fully to Deletes? Thread-Index: Acp+J2bnX/AfyQXgRC6xJLEPn4oU5g== Message-ID: <6E4D02BC-0757-489A-B4C6-5BC487B68F25@checkpoint.com> References: , <006FEB08D9C6444AB014105C9AEB133FB36A4EC57A@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A82B@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A82B@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 Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #128: Can implementations not reply fully to Deletes? 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, 16 Dec 2009 08:12:34 -0000 I would actually rather remove the "MUST NOT unilaterally close them" and r= eplace it with "may unilaterally close them". But wait, there's something weird here. >From the PoV of any implementation, the SA pair is one inbound SA and one o= utbound SA. When you send a DELETE, you send it for the INBOUND SA. So I wa= s wrong - it's outbound SAs that you accumulate. If the peer does not close= the other end, you are left with a half-closed SA - just an outbound SA. = Surely closing that is easy - you just don't use it any more, so you might = as well delete it from your database - no leak on your end, and the minimal= implementation should take care of itself. So what's this text about "MAY refuse to accept incoming data"? There is n= o incoming data unless your peer misunderstood your DELETE payload. An INVA= LID_SPI notification might set them straight. On Dec 16, 2009, at 12:15 AM, Yaron Sheffer wrote: > This seems to prove that no such "minimal implementations" exist, because= they would leak memory like crazy. So we could simply say that INFORMATION= AL messages containing DELETE payloads are an exception to the "you may ret= urn an empty INFORMATIONAL" rule. >=20 > Thanks, > Yaron >=20 > ________________________________________ > From: ipsec-bounces@ietf.org [ipsec-bounces@ietf.org] On Behalf Of Yoav N= ir [ynir@checkpoint.com] > Sent: Wednesday, December 16, 2009 12:01 AM > To: Paul Hoffman; IPsecme WG > Subject: Re: [IPsec] Issue #128: Can implementations not reply fully to D= eletes? >=20 > Section 1.4.1 also says: >=20 > "A node MAY refuse to accept incoming data on half-closed > connections but MUST NOT unilaterally close them and reuse the SPIs." >=20 > So if your peer is only responding with empty INFORMATIONAL responses to = your deletes, you're going to accumulate more and more stale inbound SAs. = One of these statements has to go. > ________________________________________ > From: ipsec-bounces@ietf.org [ipsec-bounces@ietf.org] On Behalf Of Paul H= offman [paul.hoffman@vpnc.org] > Sent: Tuesday, December 15, 2009 20:55 > To: IPsecme WG > Subject: [IPsec] Issue #128: Can implementations not reply fully to Delet= es? >=20 > Section 1.4.1 says: Normally, the reply in the INFORMATIONAL exchange wil= l contain delete payloads for the paired SAs going in the other direction. = There is one exception. If by chance both ends of a set of SAs independentl= y decide to close them, each may send a delete payload and the two requests= may cross in the network. >=20 > But, Section 4 (conformance requirements), says: Every implementation MUS= T be capable of responding to an INFORMATIONAL exchange, but a minimal impl= ementation MAY respond to any INFORMATIONAL message with an empty INFORMATI= ONAL reply. >=20 > What should we do? Changing the conformance requirement is pretty serious= , but not telling the other side that you understand the Delete is also ser= ious. >=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. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From ynir@checkpoint.com Wed Dec 16 00:15: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 7B0953A6934 for ; Wed, 16 Dec 2009 00:15:43 -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.069, 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 X+Oi4Fx0gTR1 for ; Wed, 16 Dec 2009 00:15:42 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 34A163A67D9 for ; Wed, 16 Dec 2009 00:15:42 -0800 (PST) X-CheckPoint: {4B28964B-10004-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1FE3629C008; Wed, 16 Dec 2009 10:15:28 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 004DD29C002; Wed, 16 Dec 2009 10:15:27 +0200 (IST) X-CheckPoint: {4B28964A-10004-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBG8FRT7022723; Wed, 16 Dec 2009 10:15:27 +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, 16 Dec 2009 10:15:38 +0200 From: Yoav Nir To: rahul bharadhwaj Date: Wed, 16 Dec 2009 10:15:23 +0200 Thread-Topic: [IPsec] crypting with aes-xcbc-mac hashing Thread-Index: Acp+J/Ko1x646rjvThy9iH6C8c2x6A== Message-ID: <8E7653C0-DD15-45D9-B931-E76CBAD90FB1@checkpoint.com> References: <53944c010912152036i4a758d0eu948dd6416a55b1cb@mail.gmail.com> In-Reply-To: <53944c010912152036i4a758d0eu948dd6416a55b1cb@mail.gmail.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_8E7653C0DD1545D9B931E76CBAD90FB1checkpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] crypting with aes-xcbc-mac hashing 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, 16 Dec 2009 08:15:43 -0000 --_000_8E7653C0DD1545D9B931E76CBAD90FB1checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Dec 16, 2009, at 6:36 AM, rahul bharadhwaj wrote: Hi all Could anyone let me know which crypt algo des/3des/aes should be used with= aes-xcbc-mac hashing. As aes-xcbc-mac uses aes for authentication and integrity, is it correct to= apply des for encryption or is there any restriction. Thanks in advance rb Hi. We generally regard encryption and integrity to be orthogonal, so you can m= ix and match as you'd like as long as all algorithms are strong enough. Some have an aesthetic preference to match key strengths, so they wouldn't = use 56-bit DES with HMAC-SHA-512. But if your security requirements are fo= r 56-bit, there is no reason not to use DES. If you have more stringent requirements, either 3DES or AES would be good. = Usually AES is better performing, so you would usually prefer that. --_000_8E7653C0DD1545D9B931E76CBAD90FB1checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Dec 16, 2= 009, at 6:36 AM, rahul bharadhwaj wrote:

Hi all

Could anyone let me know= which crypt algo des/3des/aes should be used  with  aes-xcbc-mac= hashing.

As aes-xcbc-mac uses aes for authentication and integrity,= is it correct to apply des for encryption or is there any restriction.

Thanks in advance
rb

Hi.

We generally regard e= ncryption and integrity to be orthogonal, so you can mix and match as you'd= like as long as all algorithms are strong enough.

Some have an aesthetic preference to match key strengths, so they wouldn't= use 56-bit DES with HMAC-SHA-512.  But if your security requirements = are for 56-bit, there is no reason not to use DES.

If you have more stringent requirements, either 3DES or AES would be good.= Usually AES is better performing, so you would usually prefer that.<= div>
= --_000_8E7653C0DD1545D9B931E76CBAD90FB1checkpointcom_-- From kivinen@iki.fi Wed Dec 16 01:55: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 E79DF3A6851 for ; Wed, 16 Dec 2009 01:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 IwjWqDGHFNGU for ; Wed, 16 Dec 2009 01:55:03 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id AFEA93A68A4 for ; Wed, 16 Dec 2009 01:55:02 -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 nBG9sg1e028265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 11:54:42 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBG9sgQ2026364; Wed, 16 Dec 2009 11:54:42 +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: <19240.44642.169622.958175@fireball.kivinen.iki.fi> Date: Wed, 16 Dec 2009 11:54:42 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> <20091214102644.0234.DECD93FF@lab.ntt.co.jp> <19238.13380.918117.767719@fireball.kivinen.iki.fi> <99043b4a0912140526y3e217649n67d19416e3c87ea8@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 26 min Cc: ipsec@ietf.org, Matthew Cini Sarreo Subject: [IPsec] #22: Specifying the 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: Wed, 16 Dec 2009 09:55:04 -0000 Paul Hoffman writes: > At 2:26 PM +0100 12/14/09, Matthew Cini Sarreo wrote: > >Hello all, > > > >A minor technical note about Issue #22. Section 2.25, last paragraph reads: > > > >A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer > >receives a request to rekey a Child SA that does not exist. A peer > >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. > > > >The original text does not mention what the SPI should be (it is > >practially implied what it should be set to, but is still not > >mentioned in the text). Presumably one would set the this to be the > >SPI of the Child SA that caused the error (i.e the data for > >CHILD_SA_NOT_FOUND is the same as the SPI found inside the REKEY_SA > >notification). This way, the Initiator knows which rekeying attempt > >resulted in this error. For initiator it is clear already because this error notification is always used as reply to the CREATE_CHILD_SA request, i.e. initiator already matches this with the corresponding request by the message id fields. Because of this the SPI field is not necessarily needed. > >I would propose to change this text to: > >A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer > >receives a request to rekey a Child SA that does not exist. The SA > >that the initiator attempted to rekey is indicated by the SPI field > >in the Notify Payload, which is copied from the SPI field in the > >REYEY_SA notification. A peer 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. > > It is always good to make this kind of thing explicit. I will add > this to the next draft. This would be ok, but would not be enough. We also have text in the section 3.10 saying that only INVALID_SELECTORS and REKEY_SA has SPI field, so this new CHILD_SA_NOT_FOUND needs to be added to there too. We have decided the SPI is filled to the SPI field when it refers to EXISTING SPI. For example the INVALID_SPI notification does not fill the SPI field, as the SPI field refers to the SPI that is not known by the responder. See text in section 3.10 under Protocol ID. This is similar case, i.e. the responder of who gets the REKEY_SA notification with unknown SPI does not have Child SA with that SPI, thus SPI is unknown for him, and because of that I think it is better for NOT to fill in the SPI field of the CHILD_SA_NOT_FOUND error. As the exchange where this error refers to is clear from the context (it is reply to the rekey request), there is no need to include SPI anywhere. Because of that I suggest we do not add that text but instead add sentense saying: As CHILD_SA_NOT_FOUND error refers to unknown SPI from the responders point of view, it does not fill in the SPI field of the CHILD_SA_NOT_FOUND error notification. Instead it sets the protocol ID to zero and leaves SPI field empty. -- kivinen@iki.fi From kivinen@iki.fi Wed Dec 16 02: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 ED2D03A69A7 for ; Wed, 16 Dec 2009 02:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 ZoLvgz4+Y-2K for ; Wed, 16 Dec 2009 02: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 C00023A6811 for ; Wed, 16 Dec 2009 02: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 nBGA8vpL019974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 12:08:57 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBGA8ttH002368; Wed, 16 Dec 2009 12:08:55 +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: <19240.45495.584776.621419@fireball.kivinen.iki.fi> Date: Wed, 16 Dec 2009 12:08:55 +0200 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 6 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) 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, 16 Dec 2009 10:09:17 -0000 Scott C Moonen writes: > 7) Section 3.14, "The Encrypted Payload, if present in a message, MUST be > the last payload in the message. Often, it is the only payload in the > message." Out of curiosity, do we know of any cases where this payload is > not the only payload in the message? It strikes me as odd to allow for > some payloads prior to this one to be integrity protected but not > encrypted. I suppose since RFC 4306 allows it we don't have a lot of > wiggle room here. For example older versions of the resumption draft used constructs where the had Nonce and some notifications before the encrypted payload, so that those could be used to find the state which is then used to decrypt the rest of the packet. Current version of the resumption does not use that kind of thing anymore, but some future version might use. Anyways currently there is no need to support other payloads before encrypted payload and if implementation would support such it would need to be very careful to keep the encrypted and authenticated payloads and cleartext and not-authenticated payloads separate when parsing the message. > > 8) Section 4, "Every implementation MUST be capable of responding to an > INFORMATIONAL exchange, but a minimal implementation MAY respond to any > INFORMATIONAL message with an empty INFORMATIONAL reply." Is that true > even if the INFORMATIONAL request contained a Delete payload for a Child > SA? Yes. I.e. you can have minimal implementation which only supports exactly one IPsec SA and IKE SA and does not support rekeying or creating additional SAs using CREATE_CHILD_SA exchange. > 9) Appendix D -- we need to fill this in. I think that was moved to be section 1.7, so we should remove this appendix. -- kivinen@iki.fi From kivinen@iki.fi Wed Dec 16 02:42: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 131F53A68AC for ; Wed, 16 Dec 2009 02:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 rMjYMlaKbX-x for ; Wed, 16 Dec 2009 02:42:07 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E312D3A67DD for ; Wed, 16 Dec 2009 02:42: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 nBGAfkbr014981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 12:41:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBGAfjNF026668; Wed, 16 Dec 2009 12:41:45 +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: <19240.47465.10023.356436@fireball.kivinen.iki.fi> Date: Wed, 16 Dec 2009 12:41:45 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 31 min Cc: IPsecme WG Subject: [IPsec] Issue #128: Can implementations not reply fully to Deletes? 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, 16 Dec 2009 10:42:08 -0000 Paul Hoffman writes: > Section 1.4.1 says: Normally, the reply in the INFORMATIONAL > exchange will contain delete payloads for the paired SAs going in > the other direction. There is one exception. If by chance both ends > of a set of SAs independently decide to close them, each may send a > delete payload and the two requests may cross in the network. > > But, Section 4 (conformance requirements), says: Every > implementation MUST be capable of responding to an INFORMATIONAL > exchange, but a minimal implementation MAY respond to any > INFORMATIONAL message with an empty INFORMATIONAL reply. Support for deleting Child SAs is not required from minimal implementations. If you have implementation which does only support exactly one Child SA there is no point of deleting Child SAs separately, as there can be only one, and as it does not support CREATE_CHILD_SA exchanges, there is no way of creating new one. The conformance requirement will say that minimal implementation needs to send reply back to INFORMATIONAL exchange, but it can be empty, and that will leave the Child SA in half-closed state (which is allowed). Later when the SA is staying there for longer the other end will most likely notice the situation and clear it by restarting the IKE SAs (as explained in the 1.4.1). > What should we do? Changing the conformance requirement is pretty > serious, but not telling the other side that you understand the > Delete is also serious. So I do not think we need to do anything as minimal implementation is not required to understand delete notifications. -- kivinen@iki.fi From kivinen@iki.fi Wed Dec 16 02:54: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 448923A6804 for ; Wed, 16 Dec 2009 02:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 aNhyXP7mjVyx for ; Wed, 16 Dec 2009 02:54:57 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF513A688C for ; Wed, 16 Dec 2009 02:54: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 nBGAsd7I002450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 12:54:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBGAsdMf001378; Wed, 16 Dec 2009 12:54:39 +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: <19240.48239.23842.571746@fireball.kivinen.iki.fi> Date: Wed, 16 Dec 2009 12:54:39 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EC57A@il-ex01.ad.checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133FB36A4EC57A@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 12 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #128: Can implementations not reply fully to Deletes? 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, 16 Dec 2009 10:54:58 -0000 Yoav Nir writes: > Section 1.4.1 also says: > > "A node MAY refuse to accept incoming data on half-closed > connections but MUST NOT unilaterally close them and reuse the SPIs." > > So if your peer is only responding with empty INFORMATIONAL > responses to your deletes, you're going to accumulate more and more > stale inbound SAs. In which case you follow the text in 1.4.1 which says: If connection state becomes sufficiently messed up, a node MAY close the IKE SA; doing so will implicitly close all SAs negotiated under it. It can then rebuild the SAs it needs on a clean base under a new IKE SA. The response to a request that deletes the IKE SA is an empty Informational response. and that will fix the situation with minimal implementation. Also with minimal implementation you cannot really get more and more stale inbound SAs, as if implementation is so small it does not support Delete notifications, it most likely doesnot support more than one Child SA, i.e. it does not support CREATE_CHILD_SA (it will always reply with NO_ADDITIONAL_SAS to that), thus at most you get one extra SA. And as other end didn't understand the delete, it is not stale, as it will be working half-closed SAs, it is outbound SA for you and if you encrypt data and send it to the minimal implementation it will still decrypt, and process that packet. It will might even send reply back to your already closed inbound SA, but you will drop that as you have already deleted that half. > One of these statements has to go. Not really. Note, that I would expect all normal versions of the IPsec to support both CREATE_CHILD_SA and delete notifications, but we are talking now about the minimal requirements. I.e. if you have your battery powered garage door opener, who knows IKEv2 just enough to do IKE_SA_INIT (with exactly one set of crypto algorithms), IKE_AUTH (with preshared key and with one set of crypto algorithms and fixed traffic selectors). It only supports this exactly one Child SA, which it uses to send message saying "Open or Close the garage door" and after 30 seconds if no more buttons is pressed it will shutdown. As it does not support CREATE_CHILD_SA or INFORMATIONAL in any other way than sending NO_ADDITIONAL_SAS or empty reply back, it does not know how to process delete payloads at all. It even does not know how to delete the IKE SA, but that does not matter as it automatically goes away when it automatically turns itself off. It expects that your home area network server which acted as responder to its IPsec connection is smart enough to start DPD later and when garage door opener does not reply it will also delete the IKE SA from the server side. This kind of minimal implementations are not meant to be used in normal operations. -- kivinen@iki.fi From kivinen@iki.fi Wed Dec 16 03:04: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 049D33A6984 for ; Wed, 16 Dec 2009 03:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 f-YsyFTh6zQ8 for ; Wed, 16 Dec 2009 03: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 B31003A659C for ; Wed, 16 Dec 2009 03: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 nBGB4EmP027163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 13:04:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBGB4EwX029512; Wed, 16 Dec 2009 13:04: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: <19240.48814.362243.337597@fireball.kivinen.iki.fi> Date: Wed, 16 Dec 2009 13:04:14 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <6E4D02BC-0757-489A-B4C6-5BC487B68F25@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133FB36A4EC57A@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF887A82B@il-ex01.ad.checkpoint.com> <6E4D02BC-0757-489A-B4C6-5BC487B68F25@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 7 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #128: Can implementations not reply fully to Deletes? 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, 16 Dec 2009 11:04:34 -0000 Yoav Nir writes: > I would actually rather remove the "MUST NOT unilaterally close > them" and replace it with "may unilaterally close them". You MAY close the IKE SA and that will take care of the SAs. You MUST NOT unilaterally close them. > But wait, there's something weird here. > >From the PoV of any implementation, the SA pair is one inbound SA and >one outbound SA. When you send a DELETE, you send it for the INBOUND >SA. So I was wrong - it's outbound SAs that you accumulate. If the >peer does not close the other end, you are left with a half-closed SA >- just an outbound SA. Surely closing that is easy - you just don't >use it any more, so you might as well delete it from your database - >no leak on your end, and the minimal implementation should take care >of itself. In your example case that is true, but note that this paragraph is not restricted to inbound SAs. The paragraph starts with "Half-close ESP or AH connections are anomalous ..." which talks about Half-closed SAs in general. This means you can also have half-closed outbound SAs, i.e. the one where other end send delete notification, but for which you decided not to send delete reply back. > So what's this text about "MAY refuse to accept incoming data"? I.e. if you have received delete notification for your outbound SA, but you decided not send out delete notification back for your inbound SA (lets say there was some failure which meant you could not do it). Then that means you can refuse incoming packets on that SA as it is already in half-closed state. When your failure situation is resolved (lets say your crypto hardware board got stuck, and you needed to wait for your watchdog timer to reset it after 10 seconds), then you will notice you have half-closed SAs, and you start clearing the situation by either sending your end of the delete notification or by noticing that things are really messed up, and deleting the whole IKE SA and starting over. > There is no incoming data unless your peer misunderstood your DELETE > payload. An INVALID_SPI notification might set them straight. Depends which party you are. For half-closed SAs the one end has half-closed SA where they have only inbound SA and other party has only the outbound SA. I do not think there is any need to change any of those locations. -- kivinen@iki.fi From smoonen@us.ibm.com Wed Dec 16 04:40: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 7ADF63A6941 for ; Wed, 16 Dec 2009 04:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.96 X-Spam-Level: X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=0.638, 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 MHnmscrhUb0n for ; Wed, 16 Dec 2009 04:40:16 -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 235253A67A6 for ; Wed, 16 Dec 2009 04:40:16 -0800 (PST) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e34.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nBGCYOOs015310 for ; Wed, 16 Dec 2009 05:34:24 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBGCdqhL036888 for ; Wed, 16 Dec 2009 05:39:52 -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 nBGCdpWJ027031 for ; Wed, 16 Dec 2009 05:39:52 -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 nBGCdpmZ027021; Wed, 16 Dec 2009 05:39:51 -0700 In-Reply-To: <19240.45495.584776.621419@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> <19240.45495.584776.621419@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: 2EC91E03:CB3988FD-8525768E:0044B088; 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 12/16/2009 07:38:08 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 12/16/2009 07:38:08 AM, Serialize complete at 12/16/2009 07:38:08 AM, S/MIME Sign failed at 12/16/2009 07:38:08 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 12/16/2009 05:39:50, Serialize complete at 12/16/2009 05:39:50 Message-ID: Date: Wed, 16 Dec 2009 07:39:50 -0500 Content-Type: multipart/alternative; boundary="=_alternative 004569168525768E_=" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) 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, 16 Dec 2009 12:40:17 -0000 This is a multipart message in MIME format. --=_alternative 004569168525768E_= Content-Type: text/plain; charset="US-ASCII" > Current version of the resumption does not use that kind of thing > anymore, but some future version might use. Anyways currently there is > no need to support other payloads before encrypted payload and if > implementation would support such it would need to be very careful to > keep the encrypted and authenticated payloads and cleartext and > not-authenticated payloads separate when parsing the message. Actually, the Encrypted payload's ICV is calculated over the entire message, so -- interestingly -- any payloads outside of it are still authenticated, but not encrypted. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Scott C Moonen/Raleigh/IBM@IBMUS Cc: Yaron Sheffer , "ipsec@ietf.org" Date: 12/16/2009 05:09 AM Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) Scott C Moonen writes: > 7) Section 3.14, "The Encrypted Payload, if present in a message, MUST be > the last payload in the message. Often, it is the only payload in the > message." Out of curiosity, do we know of any cases where this payload is > not the only payload in the message? It strikes me as odd to allow for > some payloads prior to this one to be integrity protected but not > encrypted. I suppose since RFC 4306 allows it we don't have a lot of > wiggle room here. For example older versions of the resumption draft used constructs where the had Nonce and some notifications before the encrypted payload, so that those could be used to find the state which is then used to decrypt the rest of the packet. Current version of the resumption does not use that kind of thing anymore, but some future version might use. Anyways currently there is no need to support other payloads before encrypted payload and if implementation would support such it would need to be very careful to keep the encrypted and authenticated payloads and cleartext and not-authenticated payloads separate when parsing the message. > > 8) Section 4, "Every implementation MUST be capable of responding to an > INFORMATIONAL exchange, but a minimal implementation MAY respond to any > INFORMATIONAL message with an empty INFORMATIONAL reply." Is that true > even if the INFORMATIONAL request contained a Delete payload for a Child > SA? Yes. I.e. you can have minimal implementation which only supports exactly one IPsec SA and IKE SA and does not support rekeying or creating additional SAs using CREATE_CHILD_SA exchange. > 9) Appendix D -- we need to fill this in. I think that was moved to be section 1.7, so we should remove this appendix. -- kivinen@iki.fi --=_alternative 004569168525768E_= Content-Type: text/html; charset="US-ASCII"
> Current version of the resumption does not use that kind of thing
> anymore, but some future version might use. Anyways currently there is
> no need to support other payloads before encrypted payload and if
> implementation would support such it would need to be very careful to
> keep the encrypted and authenticated payloads and cleartext and
> not-authenticated payloads separate when parsing the message.

Actually, the Encrypted payload's ICV is calculated over the entire message, so -- interestingly -- any payloads outside of it are still authenticated, but not encrypted.


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: Scott C Moonen/Raleigh/IBM@IBMUS
Cc: Yaron Sheffer <yaronf@checkpoint.com>, "ipsec@ietf.org" <ipsec@ietf.org>
Date: 12/16/2009 05:09 AM
Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes,        IKEv2-bis!)




Scott C Moonen writes:
> 7) Section 3.14, "The Encrypted Payload, if present in a message, MUST be
> the last payload in the message.  Often, it is the only payload in the
> message."  Out of curiosity, do we know of any cases where this payload is
> not the only payload in the message?  It strikes me as odd to allow for
> some payloads prior to this one to be integrity protected but not
> encrypted.  I suppose since RFC 4306 allows it we don't have a lot of
> wiggle room here.

For example older versions of the resumption draft used constructs
where the had Nonce and some notifications before the encrypted
payload, so that those could be used to find  the state which is then
used to decrypt the rest of the packet.

Current version of the resumption does not use that kind of thing
anymore, but some future version might use. Anyways currently there is
no need to support other payloads before encrypted payload and if
implementation would support such it would need to be very careful to
keep the encrypted and authenticated payloads and cleartext and
not-authenticated payloads separate when parsing the message.

>
> 8) Section 4, "Every implementation MUST be capable of responding to an
> INFORMATIONAL exchange, but a minimal implementation MAY respond to any
> INFORMATIONAL message with an empty INFORMATIONAL reply."  Is that true
> even if the INFORMATIONAL request contained a Delete payload for a Child
> SA?

Yes.

I.e. you can have minimal implementation which only supports exactly
one IPsec SA and IKE SA and does not support rekeying or creating
additional SAs using CREATE_CHILD_SA exchange.

> 9) Appendix D -- we need to fill this in.

I think that was moved to be section 1.7, so we should remove this
appendix.
--
kivinen@iki.fi

--=_alternative 004569168525768E_=-- From B22245@freescale.com Wed Dec 16 01:06: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 B20173A67D8 for ; Wed, 16 Dec 2009 01:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033, 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 w4lReqP537OT for ; Wed, 16 Dec 2009 01:06:58 -0800 (PST) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id AB7B43A67B2 for ; Wed, 16 Dec 2009 01:06:58 -0800 (PST) Received: from az33smr01.freescale.net (az33smr01.freescale.net [10.64.34.199]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id nBG96YPn015942 for ; Wed, 16 Dec 2009 02:06:34 -0700 (MST) Received: from zin33exm29.fsl.freescale.net (zin33exm29.ap.freescale.net [10.232.192.28]) by az33smr01.freescale.net (8.13.1/8.13.0) with ESMTP id nBG9AuVK013048 for ; Wed, 16 Dec 2009 03:10:57 -0600 (CST) 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_01CA7E2F.0F7E2DA7" Date: Wed, 16 Dec 2009 14:36:30 +0530 Message-ID: <402621A7D69DDA458D0E12F070D1E55F553C65@zin33exm29.fsl.freescale.net> In-Reply-To: <53944c010912152036i4a758d0eu948dd6416a55b1cb@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] crypting with aes-xcbc-mac hashing Thread-Index: Acp+CVwlmUd7sn8DT8yfKad+h7VAMAAJYB5g References: <53944c010912152036i4a758d0eu948dd6416a55b1cb@mail.gmail.com> From: "V Jyothi-B22245" To: "rahul bharadhwaj" , X-Mailman-Approved-At: Wed, 16 Dec 2009 08:01:44 -0800 Subject: Re: [IPsec] crypting with aes-xcbc-mac hashing 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, 16 Dec 2009 09:06:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7E2F.0F7E2DA7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 There is no restriction. You can use any encryption algorithm with AES-XCBC =20 Regards Jyothi ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of rahul bharadhwaj Sent: Wednesday, December 16, 2009 10:06 AM To: ipsec@ietf.org Subject: [IPsec] crypting with aes-xcbc-mac hashing Hi all Could anyone let me know which crypt algo des/3des/aes should be used with aes-xcbc-mac hashing. As aes-xcbc-mac uses aes for authentication and integrity, is it correct to apply des for encryption or is there any restriction. Thanks in advance rb ------_=_NextPart_001_01CA7E2F.0F7E2DA7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
There is no restriction.
You can use any encryption algorithm with=20 AES-XCBC
 
Regards
Jyothi

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of rahul=20 bharadhwaj
Sent: Wednesday, December 16, 2009 10:06 = AM
To:=20 ipsec@ietf.org
Subject: [IPsec] crypting with aes-xcbc-mac=20 hashing

Hi all

Could anyone let me know which crypt algo = des/3des/aes=20 should be used  with  aes-xcbc-mac hashing.

As = aes-xcbc-mac=20 uses aes for authentication and integrity, is it correct to apply des = for=20 encryption or is there any restriction.

Thanks in=20 advance
rb
------_=_NextPart_001_01CA7E2F.0F7E2DA7-- From pete.mccann@motorola.com Wed Dec 16 08:23: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 C50D93A69E0; Wed, 16 Dec 2009 08:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 hf4+XFhrMFZO; Wed, 16 Dec 2009 08:23:31 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id B65B23A67DB; Wed, 16 Dec 2009 08:23:28 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1260980593!32105627!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14607 invoked from network); 16 Dec 2009 16:23:13 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Dec 2009 16:23:13 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id nBGGNDul005573; Wed, 16 Dec 2009 09:23:13 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id nBGGNC1l014532; Wed, 16 Dec 2009 10:23:12 -0600 (CST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id nBGGNCFO014524; Wed, 16 Dec 2009 10:23:12 -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: Wed, 16 Dec 2009 11:22:51 -0500 Message-ID: <274D46DDEB9F2244B2F1EA66B3FF54BC05FCF8C9@de01exm70.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART telechat review of draft-ietf-ipsecme-traffic-visibility-11 thread-index: AcpYyQ9lC3cgrSnQQZ2X8GGVnooQjgloiQFA From: "McCann Peter-A001034" To: , X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 16 Dec 2009 09:19:38 -0800 Cc: ipsec@ietf.org Subject: Re: [IPsec] Gen-ART telechat review of draft-ietf-ipsecme-traffic-visibility-11 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, 16 Dec 2009 16:23:32 -0000 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).=20 Please wait for direction from your document shepherd or AD before posting a new version of the draft.=20 Document: draft-ietf-ipsecme-traffic-visibility-11 Reviewer: Pete McCann Review Date: 16 Dec 2009 IESG Telechat date: 17 Dec 2009=20 Summary: Ready Major issues: none Minor issues: none Nits/editorial comments: none This version addresses my previous comment adequately. -Pete McCann Peter-A001034 wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html > ). =20 >=20 > Please resolve these comments along with any other Last Call comments > you may receive.=20 >=20 > Document: draft-ietf-ipsecme-traffic-visibility-09 > Reviewer: Pete McCann > Review Date: 2009-10-29 > IETF LC End Date: 2009-10-28 > IESG Telechat date: unknown >=20 > Summary: One minor issue to discuss >=20 > Major issues: none >=20 > Minor issues: >=20 > Section 2: > As can be seen, the WESP format extends the standard ESP header > by the first 4 octets for IPv4 and by 8 octets for IPv6. The > WESP header is integrity protected, along with all the fields > specified for ESP in RFC 4303. > Normally ESP wouldn't need to process encapsulation headers that > appear prior to the SPI. Won't this require modification of the ESP > implementation, possibly breaking its modularity? Would it be > problematic for certain algorithms to include this data? It might be > good to state that. =20 >=20 > Nits/editorial comments: none From paul.hoffman@vpnc.org Wed Dec 16 09:31: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 593123A6977 for ; Wed, 16 Dec 2009 09:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.967 X-Spam-Level: X-Spam-Status: No, score=-5.967 tagged_above=-999 required=5 tests=[AWL=0.079, 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 WmzgqshBd1S6 for ; Wed, 16 Dec 2009 09:31:05 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 679703A67A4 for ; Wed, 16 Dec 2009 09:31:05 -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 nBGHUmes020559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 10:30:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19240.44642.169622.958175@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> <20091214102644.0234.DECD93FF@lab.ntt.co.jp> <19238.13380.918117.767719@fireball.kivinen.iki.fi> <99043b4a0912140526y3e217649n67d19416e3c87ea8@mail.gmail.com> <19240.44642.169622.958175@fireball.kivinen.iki.fi> Date: Wed, 16 Dec 2009 09:30:47 -0800 To: Tero Kivinen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ipsec@ietf.org, Matthew Cini Sarreo Subject: Re: [IPsec] #22: Specifying the 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: Wed, 16 Dec 2009 17:31:06 -0000 At 11:54 AM +0200 12/16/09, Tero Kivinen wrote: >Paul Hoffman writes: >> At 2:26 PM +0100 12/14/09, Matthew Cini Sarreo wrote: >> >Hello all, >> > >> >A minor technical note about Issue #22. Section 2.25, last paragraph reads: >> > >> >A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer >> >receives a request to rekey a Child SA that does not exist. A peer >> >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. >> > >> >The original text does not mention what the SPI should be (it is >> >practially implied what it should be set to, but is still not >> >mentioned in the text). Presumably one would set the this to be the >> >SPI of the Child SA that caused the error (i.e the data for >> >CHILD_SA_NOT_FOUND is the same as the SPI found inside the REKEY_SA >> >notification). This way, the Initiator knows which rekeying attempt >> >resulted in this error. > >For initiator it is clear already because this error notification is >always used as reply to the CREATE_CHILD_SA request, i.e. initiator >already matches this with the corresponding request by the message id >fields. > >Because of this the SPI field is not necessarily needed. > >> >I would propose to change this text to: >> >A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer >> >receives a request to rekey a Child SA that does not exist. The SA >> >that the initiator attempted to rekey is indicated by the SPI field >> >in the Notify Payload, which is copied from the SPI field in the >> >REYEY_SA notification. A peer 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. >> >> It is always good to make this kind of thing explicit. I will add >> this to the next draft. > >This would be ok, but would not be enough. We also have text in the >section 3.10 saying that only INVALID_SELECTORS and REKEY_SA has SPI >field, so this new CHILD_SA_NOT_FOUND needs to be added to there too. > >We have decided the SPI is filled to the SPI field when it refers to >EXISTING SPI. For example the INVALID_SPI notification does not fill >the SPI field, as the SPI field refers to the SPI that is not known by >the responder. See text in section 3.10 under Protocol ID. > >This is similar case, i.e. the responder of who gets the REKEY_SA >notification with unknown SPI does not have Child SA with that SPI, >thus SPI is unknown for him, and because of that I think it is better >for NOT to fill in the SPI field of the CHILD_SA_NOT_FOUND error. As >the exchange where this error refers to is clear from the context (it >is reply to the rekey request), there is no need to include SPI >anywhere. This all seems like a compelling argument. However: >Because of that I suggest we do not add that text but instead add >sentense saying: > > As CHILD_SA_NOT_FOUND error refers to unknown SPI from the > responders point of view, it does not fill in the SPI field of the > CHILD_SA_NOT_FOUND error notification. Instead it sets the protocol > ID to zero and leaves SPI field empty. If the sender of the CREATE_CHILD_SA is going to match the response by the Message ID, then I do not see why we should make the new rule about the values for the protocol ID and SPI. I would have thought that you were going to suggest something like: Because the CHILD_SA_NOT_FOUND error refers to an SPI that the responder does not recognize, it does not know what to fill in for the SPI field of the error. Therefore, the initiator SHOULD ignore the SPI field in the response and instead base its actions on the Message ID. --Paul Hoffman, Director --VPN Consortium From smoonen@us.ibm.com Wed Dec 16 10:30: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 105BB3A689F; Wed, 16 Dec 2009 10:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.005 X-Spam-Level: X-Spam-Status: No, score=-4.005 tagged_above=-999 required=5 tests=[AWL=-1.407, 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 yMQN6izSQGTu; Wed, 16 Dec 2009 10:30:45 -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 D943C3A69F1; Wed, 16 Dec 2009 10:30:44 -0800 (PST) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e9.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id nBGINgL8024146; Wed, 16 Dec 2009 13:23:42 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBGIUIPc044876; Wed, 16 Dec 2009 13:30:19 -0500 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 nBGIU9F3002360; Wed, 16 Dec 2009 11:30:09 -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 nBGIU96K002353; Wed, 16 Dec 2009 11:30:09 -0700 In-Reply-To: <274D46DDEB9F2244B2F1EA66B3FF54BC05FCF8C9@de01exm70.ds.mot.com> References: <274D46DDEB9F2244B2F1EA66B3FF54BC05FCF8C9@de01exm70.ds.mot.com> To: "McCann Peter-A001034" MIME-Version: 1.0 X-KeepSent: 3B7F1645:F8289043-8525768E:0062768D; 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 12/16/2009 01:29:09 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 12/16/2009 01:29:09 PM, Serialize complete at 12/16/2009 01:29:09 PM, S/MIME Sign failed at 12/16/2009 01:29:10 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 12/16/2009 11:30:08, Serialize complete at 12/16/2009 11:30:08 Message-ID: Date: Wed, 16 Dec 2009 13:30:07 -0500 Content-Type: multipart/alternative; boundary="=_alternative 00658C098525768E_=" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, gen-art@ietf.org, draft-ietf-ipsecme-traffic-visibility.all@tools.ietf.org Subject: [IPsec] WESP and combined-mode 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, 16 Dec 2009 18:30:47 -0000 This is a multipart message in MIME format. --=_alternative 00658C098525768E_= Content-Type: text/plain; charset="US-ASCII" Peter, your comment below made me go back and re-read the draft. Section 2.2 of this draft makes this statement: In the diagrams below, "WESP ICV" refers to the ICV computation as modified by this specification. Namely, the ESP ICV computation is augmented to include the four octets that constitute the WESP header. Otherwise, the ICV computation is as specified by ESP [RFC4303]. In general I wonder if this paragraph should be beefed up a bit. Tables 1 and 2 of RFC 4303 go into specific detail as to the order in which things are included in the ICV calculation, and simply saying "augmented" leaves some ambiguity as to where the WESP data appears. This paragraph should also probably say "four or eight" instead of "four". Finally, I wonder if the document should go into even more detail on how the WESP header is authenticated for combined-mode algorithms. Typically those algorithms have "additional authentication data", and I wonder if we should document specifically how the WESP header appears in the AAD for currently specified algorithms, and also document the expectation that future combined-mode RFCs should explicitly mention how a WESP header would appear in their AAD. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: "McCann Peter-A001034" To: , Cc: ipsec@ietf.org Date: 12/16/2009 12:20 PM Subject: Re: [IPsec] Gen-ART telechat review of draft-ietf-ipsecme-traffic-visibility-11 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ipsecme-traffic-visibility-11 Reviewer: Pete McCann Review Date: 16 Dec 2009 IESG Telechat date: 17 Dec 2009 Summary: Ready Major issues: none Minor issues: none Nits/editorial comments: none This version addresses my previous comment adequately. -Pete McCann Peter-A001034 wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html > ). > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-ipsecme-traffic-visibility-09 > Reviewer: Pete McCann > Review Date: 2009-10-29 > IETF LC End Date: 2009-10-28 > IESG Telechat date: unknown > > Summary: One minor issue to discuss > > Major issues: none > > Minor issues: > > Section 2: > As can be seen, the WESP format extends the standard ESP header > by the first 4 octets for IPv4 and by 8 octets for IPv6. The > WESP header is integrity protected, along with all the fields > specified for ESP in RFC 4303. > Normally ESP wouldn't need to process encapsulation headers that > appear prior to the SPI. Won't this require modification of the ESP > implementation, possibly breaking its modularity? Would it be > problematic for certain algorithms to include this data? It might be > good to state that. > > Nits/editorial comments: none _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 00658C098525768E_= Content-Type: text/html; charset="US-ASCII"
Peter, your comment below made me go back and re-read the draft.  Section 2.2 of this draft makes this statement:

   In the diagrams below, "WESP ICV" refers to the ICV computation as
   modified by this specification. Namely, the ESP ICV computation is
   augmented to include the four octets that constitute the WESP header.
   Otherwise, the ICV computation is as specified by ESP [RFC4303].

In general I wonder if this paragraph should be beefed up a bit.  Tables 1 and 2 of RFC 4303 go into specific detail as to the order in which things are included in the ICV calculation, and simply saying "augmented" leaves some ambiguity as to where the WESP data appears.  This paragraph should also probably say "four or eight" instead of "four".  Finally, I wonder if the document should go into even more detail on how the WESP header is authenticated for combined-mode algorithms.  Typically those algorithms have "additional authentication data", and I wonder if we should document specifically how the WESP header appears in the AAD for currently specified algorithms, and also document the expectation that future combined-mode RFCs should explicitly mention how a WESP header would appear in their AAD.


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


From: "McCann Peter-A001034" <pete.mccann@motorola.com>
To: <gen-art@ietf.org>, <draft-ietf-ipsecme-traffic-visibility.all@tools.ietf.org>
Cc: ipsec@ietf.org
Date: 12/16/2009 12:20 PM
Subject: Re: [IPsec] Gen-ART telechat review of        draft-ietf-ipsecme-traffic-visibility-11




I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> ).

Please wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-ietf-ipsecme-traffic-visibility-11
Reviewer: Pete McCann
Review Date: 16 Dec 2009
IESG Telechat date: 17 Dec 2009

Summary: Ready

Major issues: none
Minor issues: none
Nits/editorial comments: none

This version addresses my previous comment adequately.

-Pete



McCann Peter-A001034 wrote:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> ).  
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-ipsecme-traffic-visibility-09
> Reviewer: Pete McCann
> Review Date: 2009-10-29
> IETF LC End Date: 2009-10-28
> IESG Telechat date: unknown
>
> Summary: One minor issue to discuss
>
> Major issues: none
>
> Minor issues:
>
> Section 2:
>    As can be seen, the WESP format extends the standard ESP header
>    by the first 4 octets for IPv4 and by 8 octets for IPv6. The
>    WESP header is integrity protected, along with all the fields
>    specified for ESP in RFC 4303.
> Normally ESP wouldn't need to process encapsulation headers that
> appear prior to the SPI.  Won't this require modification of the ESP
> implementation, possibly breaking its modularity?  Would it be
> problematic for certain algorithms to include this data? It might be
> good to state that.  
>
> Nits/editorial comments: none

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

--=_alternative 00658C098525768E_=-- From pete.mccann@motorola.com Wed Dec 16 10:45: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 80C793A6833; Wed, 16 Dec 2009 10:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.849 X-Spam-Level: X-Spam-Status: No, score=-6.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 u5yKeN3GCV0u; Wed, 16 Dec 2009 10:45:56 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id C50333A6A19; Wed, 16 Dec 2009 10:45:55 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1260989140!37407212!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30413 invoked from network); 16 Dec 2009 18:45:40 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Dec 2009 18:45:40 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id nBGIjeWV008127; Wed, 16 Dec 2009 11:45:40 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id nBGIjeP7022294; Wed, 16 Dec 2009 12:45:40 -0600 (CST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id nBGIjdvK022290; Wed, 16 Dec 2009 12:45:39 -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: Wed, 16 Dec 2009 13:45:18 -0500 Message-ID: <274D46DDEB9F2244B2F1EA66B3FF54BC05FCF9AC@de01exm70.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WESP and combined-mode algorithms thread-index: Acp+fdZ2TzlKeZE5S22IQlhgTHk/dwAAQeJw References: <274D46DDEB9F2244B2F1EA66B3FF54BC05FCF8C9@de01exm70.ds.mot.com> From: "McCann Peter-A001034" To: "Scott C Moonen" X-CFilter-Loop: Reflected Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, gen-art@ietf.org, draft-ietf-ipsecme-traffic-visibility.all@tools.ietf.org Subject: Re: [IPsec] WESP and combined-mode 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, 16 Dec 2009 18:45:57 -0000 Hi, Scott, Your comments make sense; I had assumed that "augmented" meant=20 that the bytes would be logically prepended to the existing ESP data before the ICV was calculated, and that this notion was well-defined wrt existing ESP ICV methods. I am not as familiar with the combined mode AAD and how that works, so I'd defer to your and the authors' judgement on whether additional specification is needed. I do agree that the "four" should be changed. We should also keep in mind the UDP encapsulation described in section 2.1, which adds a header of 16 bytes, so we could say, "four, eight, or sixteen". -Pete Scott C Moonen wrote: > Peter, your comment below made me go back and re-read the draft.=20 > Section 2.2 of this draft makes this statement:=20 >=20 > In the diagrams below, "WESP ICV" refers to the ICV computation as > modified by this specification. Namely, the ESP ICV computation is > augmented to include the four octets that constitute the WESP > header. Otherwise, the ICV computation is as specified by ESP > [RFC4303].=20 >=20 > In general I wonder if this paragraph should be beefed up a bit.=20 > Tables 1 and 2 of RFC 4303 go into specific detail as to the order in > which things are included in the ICV calculation, and simply saying > "augmented" leaves some ambiguity as to where the WESP data appears.=20 > This paragraph should also probably say "four or eight" instead of > "four". Finally, I wonder if the document should go into even more > detail on how the WESP header is authenticated for combined-mode > algorithms. Typically those algorithms have "additional > authentication data", and I wonder if we should document specifically > how the WESP header appears in the AAD for currently specified > algorithms, and also document the expectation that future > combined-mode RFCs should explicitly mention how a WESP header would > appear in their AAD. =20 >=20 >=20 > Scott Moonen (smoonen@us.ibm.com) > z/OS Communications Server TCP/IP Development > http://www.linkedin.com/in/smoonen > =20 >=20 >=20 >=20 > From: "McCann Peter-A001034" > To: , > =20 > Cc: ipsec@ietf.org > Date: 12/16/2009 12:20 PM > Subject: Re: [IPsec] Gen-ART telechat review of =20 > draft-ietf-ipsecme-traffic-visibility-11=20 >=20 > ________________________________ >=20 >=20 >=20 >=20 > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html > > > ). =20 >=20 > Please wait for direction from your document shepherd or AD before > posting a new version of the draft.=20 >=20 > Document: draft-ietf-ipsecme-traffic-visibility-11 > Reviewer: Pete McCann > Review Date: 16 Dec 2009 > IESG Telechat date: 17 Dec 2009 >=20 > Summary: Ready >=20 > Major issues: none > Minor issues: none > Nits/editorial comments: none >=20 > This version addresses my previous comment adequately. >=20 > -Pete >=20 >=20 >=20 > McCann Peter-A001034 wrote: >> I have been selected as the General Area Review Team (Gen-ART) >> reviewer for this draft (for background on Gen-ART, please see >> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html >> >> > > ). =20 >>=20 >> Please resolve these comments along with any other Last Call comments >> you may receive. >>=20 >> Document: draft-ietf-ipsecme-traffic-visibility-09 >> Reviewer: Pete McCann >> Review Date: 2009-10-29 >> IETF LC End Date: 2009-10-28 >> IESG Telechat date: unknown >>=20 >> Summary: One minor issue to discuss >>=20 >> Major issues: none >>=20 >> Minor issues: >>=20 >> Section 2: >> As can be seen, the WESP format extends the standard ESP header >> by the first 4 octets for IPv4 and by 8 octets for IPv6. The >> WESP header is integrity protected, along with all the fields >> specified for ESP in RFC 4303. >> Normally ESP wouldn't need to process encapsulation headers that >> appear prior to the SPI. Won't this require modification of the ESP >> implementation, possibly breaking its modularity? Would it be >> problematic for certain algorithms to include this data? It might be >> good to state that. >>=20 >> Nits/editorial comments: none >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > =20 From wierbows@us.ibm.com Wed Dec 16 12:32: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 4B7C63A681A; Wed, 16 Dec 2009 12:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-1.999, 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 yR2NhFchDzun; Wed, 16 Dec 2009 12:32:09 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id B0FE53A6882; Wed, 16 Dec 2009 12:32:08 -0800 (PST) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id nBGKQclk013705; Wed, 16 Dec 2009 15:26:38 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBGKVj6J118176; Wed, 16 Dec 2009 15:31:47 -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 nBGKVi3f020711; Wed, 16 Dec 2009 15:31:44 -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 nBGKVisi020695; Wed, 16 Dec 2009 15:31:44 -0500 In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> X-KeepSent: FE4B8F17:5EBD99C2-8525768E:00702000; type=4; name=$KeepSent To: Paul Hoffman X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Wed, 16 Dec 2009 15:31:42 -0500 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 12/16/2009 15:31:44 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) 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, 16 Dec 2009 20:32:10 -0000 Paul, I haven't matched Scott's efforts, but I do have some comments: Comment #1: Section 1.2 (The Initial Exchanges) has the following sentence, which was also in RFC 4306. Payloads that may optionally appear will be shown in brackets, such as [CERTREQ], indicate that optionally a certificate request payload can be included. This wording seems awkward to me. I suggest changing "indicate" to "indicating" as below: Payloads that may optionally appear will be shown in brackets, such as [CERTREQ], indicating that optionally a certificate request payload can be included. Comment # 2: Section 1.7 (Differences Between RFC 4306 and This Document) states: The protocol described in this document retains the same major version number (2) and minor version number (0) as was used in RFC 4306. That is, the version number is *not* changed from RFC 4306. Section 2.5 (Version Numbers and Forward Compatibility) states The minor version number indicates new capabilities, and MUST be ignored by a node with a smaller minor version number, but used for informational purposes by the node with the larger minor version number. For example, it might indicate the ability to process a newly defined notification message. The node with the larger minor version number would simply note that its correspondent would not be able to understand that message and therefore would not send it. New notifies have been added to the bis draft. Is a bump in the minor number warranted? Is there a down side to bumping the minor number? Comment # 3: Section 2.8.1 Simultaneous Child SA rekeying states: To B, it looks like A is trying to rekey an SA that no longer exists; thus, B responds to the request with something non-fatal such as NO_PROPOSAL_CHOSEN. <-- send resp1: N(NO_PROPOSAL_CHOSEN) recv resp1 <-- When A receives this error, it already knows there was simultaneous rekeying, so it can ignore the error message. Section 2.25.1 Exchange Collisions states: A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a request to rekey a Child SA that does not exist. A peer 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. This seems to be inconsistent. I suspect that the text in section 2.8.1 should be updated to show CHILD_SA_NOT_FOUND sent instead of NO_PROPOSAL_CHOSEN. Comment #4: Section 2.8.2 Simultaneous IKE SA Rekeying states: If only one peer detects a simultaneous rekey, redundant SAs are not created. In this case, when the peer that did not notice the simultaneous rekey gets the request to rekey the IKE SA that it has already successfully rekeyed, it MUST return TEMPORARY_FAILURE because it is an IKE SA that it is currently trying to close (whether or not it has already sent the delete notification for the SA). Section 2.25.2 (Collisions While Rekeying or Closing IKE SAs) states: If a peer receives a request to close an IKE SA that it is currently trying to close, it SHOULD reply as usual, and forget about its own close request. Based on the text in Section 2.25.2 it seems that perhaps the MUST in Section 2.8.2 is really a SHOULD. Comment #5 In section Section 2.8.2 Simultaneous IKE SA Rekeying I suggest we start a new paragraph at the sentence: If only one peer detects a simultaneous rekey, redundant SAs are not created. Comment #6 Section 2.25.2 (Collisions While Rekeying or Closing IKE SAs) states: If the peer that did notice the simultaneous rekey gets the delete request from the other peer for the old IKE SA, it knows that the other peer did not detect the simultaneous rekey, and the first peer can forget its own rekey attempt. However, there is a twist to the other case where one rekeying finishes first: Host A Host B ------------------------------------------------------------------- send req1: SA(..,SPIa1,..),Ni1,.. --> <-- send req2: SA(..,SPIb1,..),Ni2,.. --> recv req1 <-- send resp1: SA(..,SPIb2,..),Nr2,.. recv resp1 <-- send req3: D() --> --> recv req3 At this point, host B sees a request to close the IKE_SA. There's not much more to do than to reply as usual. However, at this point host B should stop retransmitting req2, since once host A receives resp3, it will delete all the state associated with the old IKE_SA and will not be able to reply to it. <-- send resp3: () I suggest the sentence, "However, there is a twist to the other case where one rekeying finishes first: " be deleted. The sample flow that follows it is just a more detailed description of the sentence that proceeds it. The sentence made sense at one time, but not anynore. Comment 7: Section 2.23 (Nat Traversal) has the following sequence of text: o The recipient of either the NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied value to a SHA-1 hash of the SPIs, source IP address, and port, and if they don't match it SHOULD enable NAT traversal. In the case of a mismatching NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the connection attempt if NAT traversal is not supported. In the case of a mismatching NAT_DETECTION_DESTINATION_IP hash, it means that the system receiving the NAT_DETECTION_DESTINATION_IP payload is behind a NAT and that system SHOULD start sending keepalive packets as defined in [UDPENCAPS]; alternately, it MAY reject the connection attempt if NAT traversal is not supported. o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches the expected value of the source IP and port found from the IP header of the packet containing the payload, it means that the system sending those payloads is behind NAT (i.e., someone along the route changed the source address of the original packet to match the address of the NAT box). In this case, the system receiving the payloads should allow dynamic update of the other systems' IP address, as described later. o If the NAT_DETECTION_DESTINATION_IP payload received does not match the hash of the destination IP and port found from the IP header of the packet containing the payload, it means that the system receiving the NAT_DETECTION_DESTINATION_IP payload is behind a NAT. In this case, that system SHOULD start sending keepalive packets as explained in [UDPENCAPS]. The first bullet says, "In the case of a mismatching NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the connection attempt if NAT traversal is not supported." This is slightly inaccurate when multiple NAT_DETECTION_SOURCEIP payloads are sent. I think it should be reworded to say, "In the case there is a mismatch of the NAT_DETECTION_SOURCE_IP hash in each NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY reject the connection attempt if NAT traversal is not supported. Also, the third bullet seems to already be covered by the last sentence in the first bullet. Is the third bullet really necessary?. Comment 8: Section 2.23 (Nat Traversal) I thought it was decided that one should be able to float to port 4500 (or even start out on port 4500) even if there is no NAT. That is is not clear from 2.23. Should floating even when a NAT is not detected be mentioned in 2.23? Comment 9: I agree with Scott Moonen's comment that in Section 3.6 the sentence "Certificate payloads SHOULD be included in an exchange if certificates are available to the sender unless the peer has indicated an ability to retrieve this information from elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload." Does not seem to make sense. Certificate payloads are still sent when the HTTP_CERT_LOOKUP_SUPPORTED Notify payload. is received. I've seen Paul's response that a new ticket should be opened if this is important. I think it is and will open a new ticket once I figure how to. Comment 10 In Section 3.7 (Certificate Request Payload) I still find the relationship between the cert encoding type and the HTTP_CERT_LOOKUP_SUPPORTED notify to be poorly explained. Perhaps there is no relationship, but it seems as if there should be. For example, what should take precedence the case where the cert encoding type is "Hash and URL of X.509 certificate" and no HTTP_CERT_LOOKUP_SUPPORTED notify was sent or in the case where the cert encoding type is "X..509 certificate" and a HTTP_CERT_LOOKUP_SUPPORTED notify was sent? Dave Wierbowski From: Paul Hoffman To: "ipsec@ietf.org" Date: 12/15/2009 12:28 PM Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) Sent by: ipsec-bounces@ietf.org At 11:53 AM -0500 12/15/09, Scott C Moonen wrote: >I've finished my read through the draft. Many thanks for the careful review. So, who wants to match or exceed Scott's efforts? We need more eyes on this version of the document before it is ready for IETF Last Call. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Wed Dec 16 14:46: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 D21323A6A8F; Wed, 16 Dec 2009 14:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.885 X-Spam-Level: X-Spam-Status: No, score=-4.885 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 Wk9EvcLbxdDr; Wed, 16 Dec 2009 14:46:10 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 69FB53A6875; Wed, 16 Dec 2009 14:46: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 nBGMjsCI039769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Dec 2009 15:45:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> Date: Wed, 16 Dec 2009 14:45:50 -0800 To: David Wierbowski From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) 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, 16 Dec 2009 22:46:11 -0000 At 3:31 PM -0500 12/16/09, David Wierbowski wrote: >I haven't matched Scott's efforts, but I do have some comments: Many thanks! >Comment #1: > >Section 1.2 (The Initial Exchanges) has the following sentence, which was >also in RFC 4306. > > Payloads that may optionally appear will be shown in brackets, > such as [CERTREQ], indicate that optionally a certificate request > payload can be included. > >This wording seems awkward to me. I suggest changing "indicate" to >"indicating" as below: > > Payloads that may optionally appear will be shown in brackets, > such as [CERTREQ], indicating that optionally a certificate request > payload can be included. Got it. >Comment # 2: > >Section 1.7 (Differences Between RFC 4306 and This Document) states: > > The protocol described in this document retains the same major > version number (2) and minor version number (0) as was used in RFC > 4306. That is, the version number is *not* changed from RFC 4306. > >Section 2.5 (Version Numbers and Forward Compatibility) states > > The minor > version number indicates new capabilities, and MUST be ignored by a > node with a smaller minor version number, but used for informational > purposes by the node with the larger minor version number. For > example, it might indicate the ability to process a newly defined > notification message. The node with the larger minor version number > would simply note that its correspondent would not be able to > understand that message and therefore would not send it. > >New notifies have been added to the bis draft. Is a bump in the minor >number warranted? Is there a down side to bumping the minor number? Opened as Issue #130. >Comment # 3: > >Section 2.8.1 Simultaneous Child SA rekeying states: > > To B, it looks like A is trying to rekey an SA that no longer exists; > thus, B responds to the request with something non-fatal such as > NO_PROPOSAL_CHOSEN. > > <-- send resp1: N(NO_PROPOSAL_CHOSEN) > recv resp1 <-- > > When A receives this error, it already knows there was simultaneous > rekeying, so it can ignore the error message. > >Section 2.25.1 Exchange Collisions states: > > A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives > a request to rekey a Child SA that does not exist. A peer 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. > >This seems to be inconsistent. I suspect that the text in section 2.8.1 >should be updated to show CHILD_SA_NOT_FOUND sent instead of >NO_PROPOSAL_CHOSEN. Agree. It is clear from "such as" that the NO_PROPOSAL_CHOSEN is not the definitive answer. >Comment #4: > >Section 2.8.2 Simultaneous IKE SA Rekeying states: > > If only one peer detects a simultaneous rekey, redundant SAs > are not created. In this case, when the peer that did not notice the > simultaneous rekey gets the request to rekey the IKE SA that it has > already successfully rekeyed, it MUST return TEMPORARY_FAILURE > because it is an IKE SA that it is currently trying to close (whether > or not it has already sent the delete notification for the SA). > >Section 2.25.2 (Collisions While Rekeying or Closing IKE SAs) states: > > If a peer receives a request to close an IKE SA that it is > currently trying to close, it SHOULD reply as usual, and forget about > its own close request. > >Based on the text in Section 2.25.2 it seems that perhaps the MUST in >Section 2.8.2 is really a SHOULD. I'm not convinced which needs to be changed. Opened as issue #131. >Comment #5 > >In section Section 2.8.2 Simultaneous IKE SA Rekeying I suggest we start a >new paragraph at the sentence: > > If only one peer detects a simultaneous rekey, redundant SAs > are not created. Done. > > >Comment #6 > >Section 2.25.2 (Collisions While Rekeying or Closing IKE SAs) states: > If > the peer that did notice the simultaneous rekey gets the delete > request from the other peer for the old IKE SA, it knows that the > other peer did not detect the simultaneous rekey, and the first peer > can forget its own rekey attempt. > > However, there is a twist to the other case where one rekeying > finishes first: > > Host A Host B > ------------------------------------------------------------------- > send req1: > SA(..,SPIa1,..),Ni1,.. --> > <-- send req2: SA(..,SPIb1,..),Ni2,.. > --> recv req1 > <-- send resp1: SA(..,SPIb2,..),Nr2,.. > recv resp1 <-- > send req3: D() --> > --> recv req3 > > At this point, host B sees a request to close the IKE_SA. There's > not much more to do than to reply as usual. However, at this point > host B should stop retransmitting req2, since once host A receives > resp3, it will delete all the state associated with the old IKE_SA > and will not be able to reply to it. > > <-- send resp3: () > >I suggest the sentence, "However, there is a twist to the other case where >one rekeying finishes first: " be deleted. The sample flow that follows it >is just a more detailed description of the sentence that proceeds it. The >sentence made sense at one time, but not anynore. Done. > >Comment 7: > >Section 2.23 (Nat Traversal) has the following sequence of text: > > o The recipient of either the NAT_DETECTION_SOURCE_IP or > NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied > value to a SHA-1 hash of the SPIs, source IP address, and port, > and if they don't match it SHOULD enable NAT traversal. In the > case of a mismatching NAT_DETECTION_SOURCE_IP hash, the recipient > MAY reject the connection attempt if NAT traversal is not > supported. In the case of a mismatching > NAT_DETECTION_DESTINATION_IP hash, it means that the system > receiving the NAT_DETECTION_DESTINATION_IP payload is behind a NAT > and that system SHOULD start sending keepalive packets as defined > in [UDPENCAPS]; alternately, it MAY reject the connection attempt > if NAT traversal is not supported. > > o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches > the expected value of the source IP and port found from the IP > header of the packet containing the payload, it means that the > system sending those payloads is behind NAT (i.e., someone along > the route changed the source address of the original packet to > match the address of the NAT box). In this case, the system > receiving the payloads should allow dynamic update of the other > systems' IP address, as described later. > > o If the NAT_DETECTION_DESTINATION_IP payload received does not > match the hash of the destination IP and port found from the IP > header of the packet containing the payload, it means that the > system receiving the NAT_DETECTION_DESTINATION_IP payload is > behind a NAT. In this case, that system SHOULD start sending > keepalive packets as explained in [UDPENCAPS]. > >The first bullet says, "In the case of a mismatching >NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the connection >attempt if NAT traversal is not supported." This is slightly inaccurate >when multiple NAT_DETECTION_SOURCEIP payloads are sent. I think it should >be reworded to say, "In the case there is a mismatch of the >NAT_DETECTION_SOURCE_IP hash in each NAT_DETECTION_SOURCE_IP payloads >received, the recipient MAY reject the connection attempt if NAT traversal >is not supported. Good catch; done. > >Also, the third bullet seems to already be covered by the last sentence in >the first bullet. Is the third bullet really necessary?. Agree. > >Comment 8: > >Section 2.23 (Nat Traversal) I thought it was decided that one should be >able to float to port 4500 (or even start out on port 4500) even if there >is no NAT. That is is not clear from 2.23. Should floating even when a >NAT is not detected be mentioned in 2.23? The beginning of the 7th paragraph already says "An initiator can float to port 4500, regardless whether or not there is NAT, even at the beginning of IKE.". > >Comment 9: > >I agree with Scott Moonen's comment that in Section 3.6 the sentence >"Certificate payloads SHOULD be included in an exchange if certificates are >available to the sender unless the peer has indicated an ability to >retrieve this information from elsewhere using an >HTTP_CERT_LOOKUP_SUPPORTED Notify payload." Does not seem to make sense. >Certificate payloads are still sent when the HTTP_CERT_LOOKUP_SUPPORTED >Notify payload. is received. I've seen Paul's response that a new ticket >should be opened if this is important. I think it is and will open a new >ticket once I figure how to. Whoops; Yaron and I may have never told the WG how to. - Go to - Click "Login" to log in if you already have a password; if not, click "Get Passwd" in the thin left column to get a password. - After you log in, there will be a "New Ticket" choice to the right of "View Tickets". - If you mess up your first attempt, just keep changing it until it is right. (I typically forget to set the "Component" to "draft-ietf-ipsec-ikev2bis"...) - When it looks the way you want, send a new message to the mailing list with the ticket number in the subject, such as "Issue #567: Short description of the issue". Including the "#567" will make my job *much* easier. > >Comment 10 > >In Section 3.7 (Certificate Request Payload) I still find the relationship >between the cert encoding type and the HTTP_CERT_LOOKUP_SUPPORTED notify to >be poorly explained. Perhaps there is no relationship, but it seems as if >there should be. For example, what should take precedence the case where >the cert encoding type is "Hash and URL of X.509 certificate" and no >HTTP_CERT_LOOKUP_SUPPORTED notify was sent or in the case where the cert >encoding type is "X..509 certificate" and a HTTP_CERT_LOOKUP_SUPPORTED >notify was sent? That's a good candidate for testing your new issue-opening skills. :-) --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Wed Dec 16 14:53: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 52AC83A6AA0 for ; Wed, 16 Dec 2009 14:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.955 X-Spam-Level: X-Spam-Status: No, score=-5.955 tagged_above=-999 required=5 tests=[AWL=0.091, 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 ECpqpVSEoq4C for ; Wed, 16 Dec 2009 14:53:24 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 9F9F63A67EB for ; Wed, 16 Dec 2009 14:53:24 -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 nBGMjsCM039769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Dec 2009 15:45:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 16 Dec 2009 14:29:35 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Issue #131: Returning TEMPORARY_FAILURE: MUST or SHOULD? 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, 16 Dec 2009 22:53:25 -0000 Section 2.8.2 Simultaneous IKE SA Rekeying states: If only one peer detects a simultaneous rekey, redundant SAs are not created. In this case, when the peer that did not notice the simultaneous rekey gets the request to rekey the IKE SA that it has already successfully rekeyed, it MUST return TEMPORARY_FAILURE because it is an IKE SA that it is currently trying to close (whether or not it has already sent the delete notification for the SA). Section 2.25.2 (Collisions While Rekeying or Closing IKE SAs) states: If a peer receives a request to close an IKE SA that it is currently trying to close, it SHOULD reply as usual, and forget about its own close request. Based on the text in Section 2.25.2 it seems that perhaps the MUST in Section 2.8.2 is really a SHOULD. Or, based on the text in 2.8.2, the SHOULD in 2.25.2 should be a MUST. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Wed Dec 16 14:53: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 93C773A67EB for ; Wed, 16 Dec 2009 14:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.956 X-Spam-Level: X-Spam-Status: No, score=-5.956 tagged_above=-999 required=5 tests=[AWL=0.090, 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 VPjJHSgv3x3A for ; Wed, 16 Dec 2009 14:53:24 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D31983A6A9F for ; Wed, 16 Dec 2009 14:53:24 -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 nBGMjsCK039769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Dec 2009 15:45:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 16 Dec 2009 14:21:28 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Issue #130: Do we need to bump the minor version number? 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, 16 Dec 2009 22:53:25 -0000 Section 1.7 (Differences Between RFC 4306 and This Document) states: The protocol described in this document retains the same major version number (2) and minor version number (0) as was used in RFC 4306. That is, the version number is *not* changed from RFC 4306. Section 2.5 (Version Numbers and Forward Compatibility) states The minor version number indicates new capabilities, and MUST be ignored by a node with a smaller minor version number, but used for informational purposes by the node with the larger minor version number. For example, it might indicate the ability to process a newly defined notification message. The node with the larger minor version number would simply note that its correspondent would not be able to understand that message and therefore would not send it. New notifies have been added to the bis draft. Is a bump in the minor number warranted? Is there a down side to bumping the minor number? --Paul Hoffman, Director --VPN Consortium From wwwrun@core3.amsl.com Wed Dec 16 14:59:45 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 239373A6AA1; Wed, 16 Dec 2009 14:59:44 -0800 (PST) From: Russ Housley To: iesg@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091216225945.239373A6AA1@core3.amsl.com> Date: Wed, 16 Dec 2009 14:59:45 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 16 Dec 2009 22:59:45 -0000 Discuss: The primary motivation for this work is to allow a middlebox to peek into integrity protected (but not encrypted) IPsec packets. Some integrity-check algorithms use an IV, a middlebox cannot alway know where the payload starts. Unlike the IPsec peer that negotiated the algorithm in the IKE exchange, the middlebox does not know which integrity-check algorithm is in use, and thus doe s not know if an IV is present or how long it might be. The document allows the encapsulation of encrypted IPsec traffic. Why? I cannot see the justification for the use if WESP at all if the IPsec traffic is encrypted. The document says: > > ... by preserving the body of the existing ESP packet format, a > compliant implementation can simply add in the new header, without > needing to change the body of the packet. > The figures in Section 2.2.1 and 2.2.2 show otherwise. The ESP ICV is replaced by a WESP ICV. ESP processing is changed, and I cannot see the justification for it. This is explained by: > > In the diagrams below, "WESP ICV" refers to the ICV computation as > modified by this specification. Namely, the ESP ICV computation is > augmented to include the four octets that constitute the WESP header. > Otherwise, the ICV computation is as specified by ESP [RFC4303]. > So, in fact, WESP is not an optional encapsulation of ESP. It is an alternative to ESP with some duplicated fields (such as Next Header) and pointers into the actual integrity-protected payload. When talking about IKEv2 negotiation, the document says: > > The notification, USE_WESP_MODE (value TBD) MAY be included in a > request message that also includes an SA payload requesting a > CHILD_SA using ESP. > USE_WESP_MODE MUST be included if one wants to use WESP, right? The use of MAY here leads me to think that there are other ways to select the use of WESP in the IKEv2 exchange. From kohn.jack@gmail.com Wed Dec 16 15:33: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 934E03A6AB9; Wed, 16 Dec 2009 15:33:33 -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 rub5nmzTnqxN; Wed, 16 Dec 2009 15:33:32 -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 A52DC3A67AF; Wed, 16 Dec 2009 15:33:32 -0800 (PST) Received: by ywh15 with SMTP id 15so1622692ywh.5 for ; Wed, 16 Dec 2009 15:33: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 :content-transfer-encoding; bh=VqVqpO2mDB8Lyk3GPwoyGGNRbnf+qK813e6k0ZRC01g=; b=J+Cc02fxLuPWztm6Wic1v9IKUVl+0DhnloYXzUeyMRx5IW3CS3FzrCUpdavqmmjq53 XhrhS/TNQFI5gXMnENJR62D1pZsYb1b0dS61EzVAJ+0tEoHJNoY9bn2PjBsQcQMlHwYW KEKxHbptKbJPFXynZSuNp6HxcfFYjcekSuYAE= 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=AUYhz6KHz4O4wI+HVv0r73YEI6XlVUxzQKEwvpKE03wATqb6oZJL8FOr5WX9U5HXH6 BAo9Oewd/VpG4lFpYM+gty+Hg1HvdvxqdlsqAOh6awEN73YXmbSB0ytZ1LIL/6pNYrQu 09HeeCxP0mqp8TCtd/O1ecmQ6mFTgWf1kKfgc= MIME-Version: 1.0 Received: by 10.90.40.17 with SMTP id n17mr2000037agn.16.1261006394197; Wed, 16 Dec 2009 15:33:14 -0800 (PST) In-Reply-To: <20091216225945.239373A6AA1@core3.amsl.com> References: <20091216225945.239373A6AA1@core3.amsl.com> Date: Thu, 17 Dec 2009 05:03:14 +0530 Message-ID: From: Jack Kohn To: Russ Housley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, iesg@ietf.org Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 16 Dec 2009 23:33:33 -0000 My two bits on this and I'll let the authors/chairs explain in detail .. On Thu, Dec 17, 2009 at 4:29 AM, Russ Housley wrote: > Discuss: > =A0The primary motivation for this work is to allow a middlebox to peek > =A0into integrity protected (but not encrypted) IPsec packets. Some > =A0integrity-check algorithms use an IV, a middlebox cannot alway know > =A0where the payload starts. =A0Unlike the IPsec peer that negotiated the > =A0algorithm in the IKE exchange, the middlebox does not know which > =A0integrity-check algorithm is in use, and thus doe s not know if an IV > =A0is present or how long it might be. > > =A0The document allows the encapsulation of encrypted IPsec traffic. > =A0Why? =A0I cannot see the justification for the use if WESP at all if > =A0the IPsec traffic is encrypted. This was discussed and i think the idea was not to limit WESP for just ESP-NULL. One does not lose anything by defining WESP for encrypted packets (besides the additional bytes in the header). However, by keeping provisions for this, we are free to define other extensions which might later work for encrypted packets. I think its a good idea to keep WESP flexible and see how it evolves in the wild. In the worst case, no one would use it for encrypted packets .. Jack > From kohn.jack@gmail.com Wed Dec 16 15:45: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 D152C3A6AD3; Wed, 16 Dec 2009 15:45:48 -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 JWwmEkq0phGU; Wed, 16 Dec 2009 15:45:48 -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 EF1513A6AA6; Wed, 16 Dec 2009 15:45:47 -0800 (PST) Received: by ywh15 with SMTP id 15so1632197ywh.5 for ; Wed, 16 Dec 2009 15:45: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 :content-transfer-encoding; bh=BiO1Ws8wTS4LgCDxpoHHOZNBy9FhO0/K5mX+wN60C2k=; b=mZyv8gzXlvxGPtP0N9LC06h0z5NnAe4ZfphjgQVtyFFf1ncD1zkW/18Ya1oLKeY42T bmAw0muoyNBWOLQSz8x6cnJ/CfAkJj0Y8EL5gn1GzpttpfqrHJIz1RvC1uSS22b9ivEH qum3lrb7Gk7s4Mg9itHyH1/YBGwVX9w0XfGFI= 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=DTp4T3hWjB5dY3bTtIqFsyVoUZl3E2aVSnJQ4dMYKeEUBnVaalJLH8MgxU1rf1LZEf pVKllC2AAmCV8p0RHawZuCtZ0a5hum3OyPL2fDVKyAXTPi/JITpR/tESLPZGrLHNlKek Y2aqqJ+ncnLewuvCvOK00S03D5bzam2Wu3Xlg= MIME-Version: 1.0 Received: by 10.91.18.39 with SMTP id v39mr1897303agi.66.1261007130189; Wed, 16 Dec 2009 15:45:30 -0800 (PST) In-Reply-To: <20091216225945.239373A6AA1@core3.amsl.com> References: <20091216225945.239373A6AA1@core3.amsl.com> Date: Thu, 17 Dec 2009 05:15:30 +0530 Message-ID: From: Jack Kohn To: Russ Housley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, iesg@ietf.org Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 16 Dec 2009 23:45:48 -0000 > =A0> > =A0So, in fact, WESP is not an optional encapsulation of ESP. =A0It is an > =A0alternative to ESP with some duplicated fields (such as Next Header) > =A0and pointers into the actual integrity-protected payload. > Actually, the name "Wrapped ESP" (WESP) is a misnomer. :) It may have been envisaged as a wrapper over ESP, but given how it has evolved (computing ICV, etc) , its more than just a mere wrapper and is actually an alternative to ESP (as you rightly point out). However, i see no issues with this. In fact, i see this as another reason why the spec should allow WESP to be used for encryption also. Jack From g_e_montenegro@yahoo.com Wed Dec 16 16:01: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 2D10F3A6ADA for ; Wed, 16 Dec 2009 16:01:52 -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 kWUrp6hdiWr6 for ; Wed, 16 Dec 2009 16:01:51 -0800 (PST) Received: from web82602.mail.mud.yahoo.com (web82602.mail.mud.yahoo.com [68.142.201.119]) by core3.amsl.com (Postfix) with SMTP id 5132B3A6ABC for ; Wed, 16 Dec 2009 16:01:51 -0800 (PST) Received: (qmail 30219 invoked by uid 60001); 17 Dec 2009 00:01:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1261008094; bh=4gsbV53pVzP/QapZNInYoZqdjF8348BJ2xo0PCbQDEU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6D6D4xeeqrzo0qFssyW+ac1yD6bxp/SyYS3lIYoV1iKCrVqTd1mnZKSDD9gKG69d2O0dI7f3nPk3TfiEm/4X/vWqAcE3LD8i/zo6Z7M0fhEMBoZol43zWycrE6Sx2CQbbgJ2kJ6OSLlCYWQI9UiXaraQx8fPsmHNci/sqNfLWo8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BiezE99SKe6lc1ukX1heeuxs3r593RVwovnWXSt/pkLkkNnY3aiKXXZeg6NMYVymbtXsWvZPmL/OWSz+Kec8xDTL4MGfSY8meOdVADgn15BNjT7wzvJhElXl04cNE5W9NtCnj9VdluxE7IPBEJfyhCZLBPzN/xMS8oOaMIyKXSY=; Message-ID: <807561.30127.qm@web82602.mail.mud.yahoo.com> X-YMail-OSG: SEcJDn0VM1krBmLKYMlvreijwLp1aILd24UKiDmCFSAA0rMQOOEV.cDje63JhLTiI19pK7htSeohkEw73FAT4XMX4VcVaSb2VqaS3jie5kfPm9C30jZhC5tJ3HSMdLJ2WBUqgLAZKW4hmCXeTAxa.HseBMG71p_f0TvBCtIAFpU9_2s5SA6RweF48A9ML_mx3daP8u5QZINS85A7QP_mjCvziCUuK2kkvYZQHqVWWdy1IvrEYG6XuaDTXwDykcAzCertu9bzRWn231fVmvpaXQHYVIDLXk9yuPWDwcQfnWnhLl8McXtrQAiLDLm0rscLJwLPc36mGsYFwYxBckdrBsqGWSTK5dTplgZcHkW8 Received: from [131.107.0.69] by web82602.mail.mud.yahoo.com via HTTP; Wed, 16 Dec 2009 16:01:34 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 References: <20091216225945.239373A6AA1@core3.amsl.com> Date: Wed, 16 Dec 2009 16:01:34 -0800 (PST) From: gabriel montenegro To: Jack Kohn , Russ Housley In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, iesg@ietf.org Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 17 Dec 2009 00:01:52 -0000 As I recall, folks expressed that if one were to use WESP for ESP-NULL, it = would be good to be able to use it for encryption as well to be able to use= a consistent packet format.=0A=0AThis was issue 84:=0Ahttp://trac.tools.ie= tf.org/wg/ipsecme/trac/ticket/84=0A=0ADiscussed at IETF 74 and 75 as well a= s on the list:=0Ahttp://tools.ietf.org/wg/ipsecme/minutes?item=3Dminutes74.= html=0Ahttp://tools.ietf.org/wg/ipsecme/minutes?item=3Dminutes75.html=0A=0A= And (just saw Jack's other message), yes "wrapped" does not correctly descr= ibe it any more=0Agiven changes to the ICV calculation.=0A=0AGabriel=0A=0A-= ---- Original Message ----=0A> From: Jack Kohn =0A> To= : Russ Housley =0A> Cc: ipsec@ietf.org; iesg@ietf.org= =0A> Sent: Wed, December 16, 2009 3:33:14 PM=0A> Subject: Re: [IPsec] DISCU= SS: draft-ietf-ipsecme-traffic-visibility=0A> =0A> My two bits on this and = I'll let the authors/chairs explain in detail ..=0A> =0A> On Thu, Dec 17, 2= 009 at 4:29 AM, Russ Housley wrote:=0A> > Discuss:=0A> > =A0The primary mot= ivation for this work is to allow a middlebox to peek=0A> > =A0into integri= ty protected (but not encrypted) IPsec packets. Some=0A> > =A0integrity-che= ck algorithms use an IV, a middlebox cannot alway know=0A> > =A0where the p= ayload starts. =A0Unlike the IPsec peer that negotiated the=0A> > =A0algori= thm in the IKE exchange, the middlebox does not know which=0A> > =A0integri= ty-check algorithm is in use, and thus doe s not know if an IV=0A> > =A0is = present or how long it might be.=0A> >=0A> > =A0The document allows the enc= apsulation of encrypted IPsec traffic.=0A> > =A0Why? =A0I cannot see the ju= stification for the use if WESP at all if=0A> > =A0the IPsec traffic is enc= rypted.=0A> =0A> This was discussed and i think the idea was not to limit W= ESP for just=0A> ESP-NULL. One does not lose anything by defining WESP for = encrypted=0A> packets (besides the additional bytes in the header). However= , by=0A> keeping provisions for this, we are free to define other extension= s=0A> which might later work for encrypted packets.=0A> =0A> I think its a = good idea to keep WESP flexible and see how it evolves=0A> in the wild. In = the worst case, no one would use it for encrypted=0A> packets ..=0A> =0A> J= ack=0A> >=0A> _______________________________________________=0A> IPsec mai= ling list=0A> IPsec@ietf.org=0A> https://www.ietf.org/mailman/listinfo/ipse= c=0A From danmcd@sun.com Wed Dec 16 18:35: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 5DEBE3A6B0C; Wed, 16 Dec 2009 18:35:17 -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 F5kQV7aFypMS; Wed, 16 Dec 2009 18:35:16 -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 49C093A6B09; Wed, 16 Dec 2009 18:35:16 -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 nBH2Z1Pc016191; Thu, 17 Dec 2009 02:35:01 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 <0KUR00K00YZVYF00@mail-amer.sun.com>; Wed, 16 Dec 2009 19:35:01 -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 <0KUR002A4Z6APCE0@mail-amer.sun.com>; Wed, 16 Dec 2009 19:35:01 -0700 (MST) Date: Wed, 16 Dec 2009 21:34:58 -0500 From: Dan McDonald In-reply-to: <20091216225945.239373A6AA1@core3.amsl.com> Sender: Dan.McDonald@sun.com To: Russ Housley Message-id: <20091217023458.GA23757@mactavish> Organization: Sun Microsystems, Inc. - Solaris Networking & Security References: <20091216225945.239373A6AA1@core3.amsl.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: ipsec@ietf.org, iesg@ietf.org Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 17 Dec 2009 02:35:17 -0000 On Wed, Dec 16, 2009 at 02:59:45PM -0800, Russ Housley wrote: > The document allows the encapsulation of encrypted IPsec traffic. > Why? I cannot see the justification for the use if WESP at all if > the IPsec traffic is encrypted. Because THE MAN told 'em to do it! :) Seriously though, I agree with Russ -- it makes little to no sense to expose privacy-protected fields. If you're worried about traffic shaping, just put all ESP/WESP/whatever packets in the lowest priority bucket. Any other reason that springs to mind simply defeats the purpose of privacy-protection. Dan From yaronf@checkpoint.com Wed Dec 16 22:59: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 360513A6AE6; Wed, 16 Dec 2009 22:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO5YdAJNBM5k; Wed, 16 Dec 2009 22:59:49 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 0697A3A6AA1; Wed, 16 Dec 2009 22:59:48 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBH6xXT7009541; Thu, 17 Dec 2009 08:59:33 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 17 Dec 2009 08:59:44 +0200 From: Yaron Sheffer To: Dan McDonald , Russ Housley Date: Thu, 17 Dec 2009 08:59:43 +0200 Thread-Topic: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Thread-Index: Acp+wZPVMldVJfJ9TDCA89JsfHGihgAJDSmQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> In-Reply-To: <20091217023458.GA23757@mactavish> 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" , "iesg@ietf.org" Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 17 Dec 2009 06:59:50 -0000 Hi Dan I agree with you regarding some of the proposals that have been floating ar= ound re: exposing bits and pieces of encrypted data. I disagree though that WESP should not be used for encrypted data: - It is simpler for implementations and architecturally cleaner for WESP to= support both flavors. - WESP provides for (secure) extensibility, which unfortunately we have not= had with ESP. Indeed we should be wise about picking such extensions. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of D= an McDonald Sent: Thursday, December 17, 2009 4:35 To: Russ Housley Cc: ipsec@ietf.org; iesg@ietf.org Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility On Wed, Dec 16, 2009 at 02:59:45PM -0800, Russ Housley wrote: > The document allows the encapsulation of encrypted IPsec traffic. > Why? I cannot see the justification for the use if WESP at all if > the IPsec traffic is encrypted. Because THE MAN told 'em to do it! :) Seriously though, I agree with Russ -- it makes little to no sense to expos= e privacy-protected fields. If you're worried about traffic shaping, just pu= t all ESP/WESP/whatever packets in the lowest priority bucket. Any other reason that springs to mind simply defeats the purpose of privacy-protectio= n. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. From kivinen@iki.fi Thu Dec 17 02:33: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 B73EC3A6B15 for ; Thu, 17 Dec 2009 02:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 If8KtHP4hZrm for ; Thu, 17 Dec 2009 02:33:27 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 7F4E43A68A4 for ; Thu, 17 Dec 2009 02:33: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 nBHAX794004724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 12:33:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBHAX6TB005481; Thu, 17 Dec 2009 12:33:06 +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: <19242.2274.595309.759259@fireball.kivinen.iki.fi> Date: Thu, 17 Dec 2009 12:33:06 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> <20091214102644.0234.DECD93FF@lab.ntt.co.jp> <19238.13380.918117.767719@fireball.kivinen.iki.fi> <99043b4a0912140526y3e217649n67d19416e3c87ea8@mail.gmail.com> <19240.44642.169622.958175@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 12 min Cc: ipsec@ietf.org, Matthew Cini Sarreo Subject: Re: [IPsec] #22: Specifying the 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: Thu, 17 Dec 2009 10:33:28 -0000 Paul Hoffman writes: > This all seems like a compelling argument. However: > > >Because of that I suggest we do not add that text but instead add > >sentense saying: > > > > As CHILD_SA_NOT_FOUND error refers to unknown SPI from the > > responders point of view, it does not fill in the SPI field of the > > CHILD_SA_NOT_FOUND error notification. Instead it sets the protocol > > ID to zero and leaves SPI field empty. > > If the sender of the CREATE_CHILD_SA is going to match the response > by the Message ID, then I do not see why we should make the new rule > about the values for the protocol ID and SPI. I would have thought > that you were going to suggest something like: That is not a new rule, that is standard rule for the Notification payloads. If you do not have existing SPI then you put Protocol ID to zero and do not fill in the SPI field. I.e. section 7.8 of the RFC4718. I originally thought that we do not need to put anything there as I expected everybody to understand that as we do not have valid SA then we do not fill in the SPI field, but as people might interpret this differently I think we need some text. > Because the CHILD_SA_NOT_FOUND error refers to an SPI that the > responder does not recognize, it does not know what to fill in for > the SPI field of the error. Therefore, the initiator SHOULD ignore > the SPI field in the response and instead base its actions on the > Message ID. I think it is better to mandate actions of the one who creates the Notication payload, not the one who receives it. So I would leave the last sentence away and only keep the first one, but as someone commented that actually responder do know about the SPI, as the SPI was sent to him in the REKEY_SA notification, so he could copy it from there to this error. Because if this I think it is better to be more explicit: Because the CHILD_SA_NOT_FOUND error refers to an SPI that the responder does not recognize, it does not fill in SPI in the CHILD_SA_NOT_FOUND error notification. I do not think we need anything to express how initiator can know which of his requests failed when he gets error response back to one of them... It should be clear for everybody that if your request gets error response back, it was that request that failed. -- kivinen@iki.fi From yaronf@checkpoint.com Thu Dec 17 02:58: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 353033A69B2 for ; Thu, 17 Dec 2009 02:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 gOvQtQk+rz3A for ; Thu, 17 Dec 2009 02:58:48 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id F0C7F3A67DD for ; Thu, 17 Dec 2009 02:58:47 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBHAwRT7013697; Thu, 17 Dec 2009 12:58:27 +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, 17 Dec 2009 12:58:38 +0200 From: Yaron Sheffer To: Paul Hoffman , IPsecme WG Date: Thu, 17 Dec 2009 12:58:26 +0200 Thread-Topic: [IPsec] Issue #130: Do we need to bump the minor version number? Thread-Index: Acp+opvYdkTf+Xd0SK6/dq0UQ2mQGwAZD4dQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F139@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] Issue #130: Do we need to bump the minor version number? 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, 17 Dec 2009 10:58:49 -0000 Or else, we could remove the sentence "For example, it might indicate the a= bility to process a newly defined notification message." I thinking bumping= the minor version number would be extremely risky. We know that everybody = can ignore unknown notifications. We don't know that everybody can deal cor= rectly with version number, simply because this has been tested less freque= ntly. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of P= aul Hoffman Sent: Thursday, December 17, 2009 0:21 To: IPsecme WG Subject: [IPsec] Issue #130: Do we need to bump the minor version number? Section 1.7 (Differences Between RFC 4306 and This Document) states: The protocol described in this document retains the same major version number (2) and minor version number (0) as was used in RFC 4306. That is, the version number is *not* changed from RFC 4306. Section 2.5 (Version Numbers and Forward Compatibility) states The minor version number indicates new capabilities, and MUST be ignored by a node with a smaller minor version number, but used for informational purposes by the node with the larger minor version number. For example, it might indicate the ability to process a newly defined notification message. The node with the larger minor version number would simply note that its correspondent would not be able to understand that message and therefore would not send it. New notifies have been added to the bis draft. Is a bump in the minor number warranted? Is there a down side to bumping the minor number? --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. From kivinen@iki.fi Thu Dec 17 03:39: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 5EE293A6944; Thu, 17 Dec 2009 03:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 bS4H3GzqeNWZ; Thu, 17 Dec 2009 03:39:08 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 712E43A6924; Thu, 17 Dec 2009 03:39:07 -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 nBHBcm5q007510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 13:38:48 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBHBckT0006941; Thu, 17 Dec 2009 13:38: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: <19242.6214.841069.877511@fireball.kivinen.iki.fi> Date: Thu, 17 Dec 2009 13:38:46 +0200 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 33 min X-Total-Time: 62 min Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org, Paul Hoffman Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) 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, 17 Dec 2009 11:39:09 -0000 David Wierbowski writes: > Comment # 2: > > Section 1.7 (Differences Between RFC 4306 and This Document) states: > > The protocol described in this document retains the same major > version number (2) and minor version number (0) as was used in RFC > 4306. That is, the version number is *not* changed from RFC 4306. > > Section 2.5 (Version Numbers and Forward Compatibility) states > > The minor > version number indicates new capabilities, and MUST be ignored by a > node with a smaller minor version number, but used for informational > purposes by the node with the larger minor version number. For > example, it might indicate the ability to process a newly defined > notification message. The node with the larger minor version number > would simply note that its correspondent would not be able to > understand that message and therefore would not send it. > > New notifies have been added to the bis draft. Is a bump in the minor > number warranted? Is there a down side to bumping the minor number? Even if we add new notifies, that does not need we MUST increment the minor version number. It just say we might want to do it. For error notifications (which were the ones we are adding) this is not that important as the 3.10.1 is quite clear that the corresponding request has failed entirely when you get error notification back. This means it does not matter which error other end sends (old or new) the recipient of it still knows the request failed. It would be different if other end would need to know whether other end supports new notifications before > Comment # 3: > > Section 2.8.1 Simultaneous Child SA rekeying states: > > To B, it looks like A is trying to rekey an SA that no longer exists; > thus, B responds to the request with something non-fatal such as > NO_PROPOSAL_CHOSEN. > > <-- send resp1: N(NO_PROPOSAL_CHOSEN) > recv resp1 <-- > > When A receives this error, it already knows there was simultaneous > rekeying, so it can ignore the error message. > > Section 2.25.1 Exchange Collisions states: > > A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives > a request to rekey a Child SA that does not exist. A peer 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. > > This seems to be inconsistent. I suspect that the text in section 2.8.1 > should be updated to show CHILD_SA_NOT_FOUND sent instead of > NO_PROPOSAL_CHOSEN. Yes. Not all the old sections were properly updated yet. I try to go them through soon to verify they are correct. > Comment #4: > > Section 2.8.2 Simultaneous IKE SA Rekeying states: > > If only one peer detects a simultaneous rekey, redundant SAs > are not created. In this case, when the peer that did not notice the > simultaneous rekey gets the request to rekey the IKE SA that it has > already successfully rekeyed, it MUST return TEMPORARY_FAILURE > because it is an IKE SA that it is currently trying to close (whether > or not it has already sent the delete notification for the SA). > > Section 2.25.2 (Collisions While Rekeying or Closing IKE SAs) states: > > If a peer receives a request to close an IKE SA that it is > currently trying to close, it SHOULD reply as usual, and forget about > its own close request. > > Based on the text in Section 2.25.2 it seems that perhaps the MUST in > Section 2.8.2 is really a SHOULD. We need to think what will happen if someone does not follow the rule. For example those two cases are not same (in 2.8.2 incoming message is IKE SA rekey and in 2.25.2 it is IKE SA delete) also what happens if the MUST/SHOULD is not followed is different. In the 2.8.2 if other end does not send TEMPORARY_FAILURE but instead replies normally that will cause there to be simultanous IKE SA rekey, which will mean that both ends need to look up the nonces and decide which of the exchanges won. As the end who decided not to send TEMPORARY_FAILURE was the one who decided this, he should be able to cope with that if he decided to do that. For the other end this just looks like normal simultaneous rekey, thus it will process it as normally. This means nothing bad happens even if someone does not follow the "MUST return TEMPORARY_FAILURE", thus we can safely change it to "SHOULD return TEMPORARY_FAILURE", so I agree your proposal to change it to SHOULD. I will try to go these things through also when I am going through the new text, i.e. check where (if anywhere) we need to have MUST, and where we can have SHOULD (or even MAY). > Comment 7: > > Section 2.23 (Nat Traversal) has the following sequence of text: > > o The recipient of either the NAT_DETECTION_SOURCE_IP or > NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied > value to a SHA-1 hash of the SPIs, source IP address, and port, > and if they don't match it SHOULD enable NAT traversal. In the > case of a mismatching NAT_DETECTION_SOURCE_IP hash, the recipient > MAY reject the connection attempt if NAT traversal is not > supported. In the case of a mismatching > NAT_DETECTION_DESTINATION_IP hash, it means that the system > receiving the NAT_DETECTION_DESTINATION_IP payload is behind a NAT > and that system SHOULD start sending keepalive packets as defined > in [UDPENCAPS]; alternately, it MAY reject the connection attempt > if NAT traversal is not supported. > > o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches > the expected value of the source IP and port found from the IP > header of the packet containing the payload, it means that the > system sending those payloads is behind NAT (i.e., someone along > the route changed the source address of the original packet to > match the address of the NAT box). In this case, the system > receiving the payloads should allow dynamic update of the other > systems' IP address, as described later. > > o If the NAT_DETECTION_DESTINATION_IP payload received does not > match the hash of the destination IP and port found from the IP > header of the packet containing the payload, it means that the > system receiving the NAT_DETECTION_DESTINATION_IP payload is > behind a NAT. In this case, that system SHOULD start sending > keepalive packets as explained in [UDPENCAPS]. > > The first bullet says, "In the case of a mismatching > NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the connection > attempt if NAT traversal is not supported." This is slightly inaccurate > when multiple NAT_DETECTION_SOURCEIP payloads are sent. I think it should > be reworded to say, "In the case there is a mismatch of the > NAT_DETECTION_SOURCE_IP hash in each NAT_DETECTION_SOURCE_IP payloads > received, the recipient MAY reject the connection attempt if NAT traversal > is not supported. > > Also, the third bullet seems to already be covered by the last sentence in > the first bullet. Is the third bullet really necessary?. I think we should keep the third bullet, but remove the last sentence of the first bullet and change the first bullet to be: o The recipient of either the NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied value to a SHA-1 hash of the SPIs, source IP address, and port, and if they don't match it SHOULD enable NAT traversal or it MAY reject the connection attempt if NAT traversal is not allowed by policy. Anyways it is bit funny to say we can reject the connection attempt if NAT traversal is not supported, but if the end was able to parse NAT_DETECTION_*_IP notifications it does have at least partial NAT traversal support, so I think it is better to say "if NAT traversal is not allowed by policy." > Comment 8: > > Section 2.23 (Nat Traversal) I thought it was decided that one should be > able to float to port 4500 (or even start out on port 4500) even if there > is no NAT. That is is not clear from 2.23. Should floating even when a > NAT is not detected be mentioned in 2.23? Isn't this clear enough: An initiator can float to port 4500, regardless whether or not there is NAT, even at the beginning of IKE. When either side is using port 4500, sending with UDP encapsulation is not required, but understanding received packets with UDP encapsulation is required. UDP encapsulation MUST NOT be done on port 500. If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP encapsulated and non-UDP encapsulated packets at any time. Either side can decide whether or not to use UDP encapsulation irrespective of the choice made by the other side. However, if a NAT is detected, both devices MUST send UDP encapsulated packets. > Comment 10 > > In Section 3.7 (Certificate Request Payload) I still find the relationship > between the cert encoding type and the HTTP_CERT_LOOKUP_SUPPORTED notify to > be poorly explained. Perhaps there is no relationship, but it seems as if > there should be. For example, what should take precedence the case where > the cert encoding type is "Hash and URL of X.509 certificate" and no > HTTP_CERT_LOOKUP_SUPPORTED notify was sent or in the case where the cert > encoding type is "X..509 certificate" and a HTTP_CERT_LOOKUP_SUPPORTED > notify was sent? I would think they mean about the same, but not exactly. I.e. if you request Hash and URL of X.509 certificate that clearly indicates you support fetching stuff from URL and also X.509 certificates, and it also indicates you would want certificates in the Hash and URL format. If you request X.509 certificate and send also HTTP_CERT_LOOKUP_SUPPORTED that means that you support X.509 certificates, and you also support http lookups, and you prefer getting certificates using Hash and URL format, but you also accept the other end to send them in X.509 format if it cannot do Hash and URL. Note, that also in the first case if other end getting Hash and URL of X.509 certificate request cannot do Hash and URL, it can still send the certificates inband using X.509 as certificate request payloads are just hints: The intent is not to prevent communication through the strict adherence of selection of a certificate based on CERTREQ, when an alternate certificate could be selected by the sender that would still enable the recipient to successfully validate and trust it through trust conveyed by cross-certification, CRLs, or other out-of- band configured means. Thus, the processing of a CERTREQ should be seen as a suggestion for a certificate to select, not a mandated one. If no certificates exist, then the CERTREQ is ignored. This is not an error condition of the protocol. There may be cases where there is a preferred CA sent in the CERTREQ, but an alternate might be acceptable (perhaps after prompting a human operator). -- kivinen@iki.fi From kivinen@iki.fi Thu Dec 17 04:04: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 020EC3A68C4; Thu, 17 Dec 2009 04:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 HIbzXstXHdo6; Thu, 17 Dec 2009 04:04:12 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id BE3623A69D6; Thu, 17 Dec 2009 04:04: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 nBHC3q8X028522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 14:03:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBHC3pWK004311; Thu, 17 Dec 2009 14:03:51 +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: <19242.7719.715250.335841@fireball.kivinen.iki.fi> Date: Thu, 17 Dec 2009 14:03:51 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> References: <20091217023458.GA23757@mactavish> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 14 min Cc: "ipsec@ietf.org" , Russ Housley , "iesg@ietf.org" , Dan McDonald Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 17 Dec 2009 12:04:13 -0000 Yaron Sheffer writes: > I agree with you regarding some of the proposals that have been > floating around re: exposing bits and pieces of encrypted data. I am really concerned about some of those late proposals for WESP extensions, and if someone would have mentioned any of those earlier when we were discussing whether WESP should allow encrypted ESP also, I would have been even more against allowing encrypted WESP. > I disagree though that WESP should not be used for encrypted data: > > - It is simpler for implementations and architecturally cleaner for > WESP to support both flavors. It does make more complexity for the middle boxes as they need to cope with both encrypted WESP and ESP-NULL WESP, thus they still cannot use just the WESP protocol number to indicate this packet is clear text. Now they also need to check the bit in the header, and if we add more extensions to WESP, they need to start doing even more processing etc, and quite soon WESP is more complex than what AH is now. > - WESP provides for (secure) extensibility, which unfortunately we > have not had with ESP. Indeed we should be wise about picking such > extensions. ESP is extensible, but it just requires out of band communication to negotiate those extensions. We currently already have ESP extesions like extended sequence numbers (ESN), Explicit Congestion Notification (ECN), Traffic Flow Confidentiality (TFC), and Combined mode algorithms. Those were added after initial ESP was created, and they are negotiated using IKEv2 (or some other method). ESP does not offer extensibility that can be done without out of band communication, and as that out of band communication is normally encrypted (inside IKEv2) that means middle boxes cannot process it. I do not think WESP should be used as generic extensible ESP. That was not what the ipsecme wg was chartered to do. We were chartered to do: - A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. The starting points for this work item are draft-grewal-ipsec-traffic-visibility and draft-hoffman- esp-null-protocol. -- kivinen@iki.fi From kivinen@iki.fi Thu Dec 17 04:20: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 28DFA3A6935 for ; Thu, 17 Dec 2009 04:20:58 -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 HWhDkzyCeMIW for ; Thu, 17 Dec 2009 04:20:55 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 5DAB628C0E3 for ; Thu, 17 Dec 2009 04:20:55 -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 nBHCKY3T009544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 14:20:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBHCKXdE010172; Thu, 17 Dec 2009 14:20: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: <19242.8721.338478.28735@fireball.kivinen.iki.fi> Date: Thu, 17 Dec 2009 14:20:33 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F139@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F139@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #130: Do we need to bump the minor version number? 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, 17 Dec 2009 12:20:58 -0000 Yaron Sheffer writes: > Or else, we could remove the sentence "For example, it might > indicate the ability to process a newly defined notification > message." That is example what changing minor number might mean. All current conforming implementations already know how to process our newly defined error notifications (they assume exchange failed), thus there is no need to update minor number, as there is no new ability needed for implementations to process those notifications. There is no reason to change that text. It does not require us to do something, it is just example. > I thinking bumping the minor version number would be > extremely risky. We know that everybody can ignore unknown > notifications. We don't know that everybody can deal correctly with > version number, simply because this has been tested less frequently. Agree on that. -- kivinen@iki.fi From rfgraveman@gmail.com Thu Dec 17 04:41: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 80F003A69DF for ; Thu, 17 Dec 2009 04:41:21 -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 f26NuuMdjzgn for ; Thu, 17 Dec 2009 04:41:20 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id A40113A683B for ; Thu, 17 Dec 2009 04:41:20 -0800 (PST) Received: by iwn33 with SMTP id 33so1415271iwn.29 for ; Thu, 17 Dec 2009 04:41:03 -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=uyTfI1vgRYCAdXIEvdqC+G3/LyWl0X5MGmv8gUM2ONM=; b=Hcze6AHXyIyNZnQxOffIWxVIDmJtvSARFGyU4ot1qe9+/gsFYcJHsUtpft66n8ledr koYI2gsTzVB/VTrmu0uCkbQfq5VtcyfVJctTrThHNSnhQ1VFZRWl8v5s8M0lDankouOJ NQB2c5sdPA3v9dflUq10ZDOkbwWFZempmvXt0= 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=RxPO0kWqQUNntPUe4P/lx+lm96gzVtpkWR4PTX5U944Z+VgMdRFJ4PmoQn+aWugBOX 0Jj79HEo3zJl+pl3KecNR1wmg+vsZoCwbBQpxZ3DhJjgjkpVmc/FZbxb1G7Mofzj5CKr ex/9+GEe4v7fIKxBJidUQ8uk7tuz57APYgzJY= MIME-Version: 1.0 Received: by 10.231.123.41 with SMTP id n41mr347356ibr.46.1261053663466; Thu, 17 Dec 2009 04:41:03 -0800 (PST) In-Reply-To: <19242.8721.338478.28735@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F139@il-ex01.ad.checkpoint.com> <19242.8721.338478.28735@fireball.kivinen.iki.fi> Date: Thu, 17 Dec 2009 07:41:03 -0500 Message-ID: <45c8c21a0912170441m53e72109id422607a45187763@mail.gmail.com> From: Richard Graveman To: Tero Kivinen Content-Type: text/plain; charset=ISO-8859-1 Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #130: Do we need to bump the minor version number? 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, 17 Dec 2009 12:41:21 -0000 I think the criterion should be: Would a reasonable and correct implementation need to have an IF statement, e.g., if(minor_number == 1) ... I do not not think the criterion should be whether bumping the number breaks older implementations. >From the discussion, leaving the number alone seems fine. Richard On Thu, Dec 17, 2009 at 7:20 AM, Tero Kivinen wrote: > Yaron Sheffer writes: >> Or else, we could remove the sentence "For example, it might >> indicate the ability to process a newly defined notification >> message." > > That is example what changing minor number might mean. All current > conforming implementations already know how to process our newly > defined error notifications (they assume exchange failed), thus there > is no need to update minor number, as there is no new ability needed > for implementations to process those notifications. > > There is no reason to change that text. It does not require us to do > something, it is just example. > >> I thinking bumping the minor version number would be >> extremely risky. We know that everybody can ignore unknown >> notifications. We don't know that everybody can deal correctly with >> version number, simply because this has been tested less frequently. > > Agree on that. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From danmcd@sun.com Thu Dec 17 07:28: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 2F9073A6B46 for ; Thu, 17 Dec 2009 07:28:48 -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 SATgsDxrxie5 for ; Thu, 17 Dec 2009 07:28:47 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 3D8923A69B6 for ; Thu, 17 Dec 2009 07:28:47 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBHFSU0H024914 for ; Thu, 17 Dec 2009 15:28:30 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 nBHFSUC4015710 for ; Thu, 17 Dec 2009 10:28:30 -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 nBHFSIC5024391 for ; Thu, 17 Dec 2009 10:28:18 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBHFSHdh024390 for ipsec@ietf.org; Thu, 17 Dec 2009 10:28:17 -0500 (EST) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Thu, 17 Dec 2009 10:28:17 -0500 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20091217152817.GA23861@kebe.East.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [IPsec] IKEv2bis: Variant on issue #64 (PF_KEY text), plus better SAD intro 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, 17 Dec 2009 15:28:48 -0000 While re-reading the introductory paragraph in Section 2.9: When an RFC4301-compliant IPsec subsystem receives an IP packet that matches a "protect" selector in its Security Policy Database (SPD), the subsystem protects that packet with IPsec. When no SA exists yet, it is the task of IKE to create it. Maintenance of a system's SPD is outside the scope of IKE (see [PFKEY] for an example programming interface, although it only applies to IKEv1), though some implementations might update their SPD in connection with the running of IKE (for an example scenario, see Section 1.1.3). the part about "only applies to IKEv1" struck me as just plain wrong. Also, while this paragraph re-introduces the 4301-described SPD, it doesn't mention the SAD at all, and later the SAD just appears nearly out of nowhere. For better conceptual coverage here's a proposed replacement first paragraph for section 2.9: When an RFC4301-compliant IPsec subsystem receives an outgoing IP packet that matches a "protect" selector in its Security Policy Database (SPD), the subsystem protects that packet with IPsec. When no SA exists yet, it is the task of IKE to create it. How the IPsec subsystem explicitly interacts with IKE is beyond the scope of this document (see [PFKEY] for an example programming interface). IKE obviously must manipulate the Security Association Database (SAD) as it derives child SAs, but also, some implementations might update their SPD in connection with the running of IKE as well (for an example scenario, see Section 1.1.3). Thanks, Dan From wierbows@us.ibm.com Thu Dec 17 08:13: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 D29963A67FE; Thu, 17 Dec 2009 08:13:42 -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 YuT8oVHjJvxm; Thu, 17 Dec 2009 08:13:41 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id E4CD73A63EB; Thu, 17 Dec 2009 08:13:40 -0800 (PST) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e2.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id nBHG4kgn007105; Thu, 17 Dec 2009 11:04:46 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBHGDMlC128084; Thu, 17 Dec 2009 11:13:23 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nBHGDCet007507; Thu, 17 Dec 2009 14:13:12 -0200 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nBHGD97f007238; Thu, 17 Dec 2009 14:13:09 -0200 In-Reply-To: <45c8c21a0912170441m53e72109id422607a45187763@mail.gmail.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F139@il-ex01.ad.checkpoint.com> <19242.8721.338478.28735@fireball.kivinen.iki.fi> <45c8c21a0912170441m53e72109id422607a45187763@mail.gmail.com> X-KeepSent: A89C0DF1:51679E61-8525768F:0057F92E; type=4; name=$KeepSent To: IPsecme WG , ipsec-bounces@ietf.org X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Thu, 17 Dec 2009 11:13:08 -0500 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 12/17/2009 11:13:09 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: [IPsec] Issue #130: Do we need to bump the minor version number? 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, 17 Dec 2009 16:13:42 -0000 I think it is reasonable to expect that an IKEv2 bis implementation would use an IF statement to control sending the new Notify types. If the minor number was changed an implementation could check the minor version and send the new notify types when the minor version was 1 and send the notify types recommended in RFC 4718 if the minor number was 0. That is what my implementation plans to do if the minor version number is bumped. I'm not sure I agree with Tero that an implementation getting an unknown TEMPORARY_FAILURE notify would always take the same action that it would if it received NO_PROPOSAL_CHOSEN as suggested by RFC 4718. Dave Wierbowski From: Richard Graveman To: Tero Kivinen Cc: IPsecme WG , Paul Hoffman Date: 12/17/2009 07:41 AM Subject: Re: [IPsec] Issue #130: Do we need to bump the minor version number? Sent by: ipsec-bounces@ietf.org I think the criterion should be: Would a reasonable and correct implementation need to have an IF statement, e.g., if(minor_number == 1) ... I do not not think the criterion should be whether bumping the number breaks older implementations. >From the discussion, leaving the number alone seems fine. Richard On Thu, Dec 17, 2009 at 7:20 AM, Tero Kivinen wrote: > Yaron Sheffer writes: >> Or else, we could remove the sentence "For example, it might >> indicate the ability to process a newly defined notification >> message." > > That is example what changing minor number might mean. All current > conforming implementations already know how to process our newly > defined error notifications (they assume exchange failed), thus there > is no need to update minor number, as there is no new ability needed > for implementations to process those notifications. > > There is no reason to change that text. It does not require us to do > something, it is just example. > >> I thinking bumping the minor version number would be >> extremely risky. We know that everybody can ignore unknown >> notifications. We don't know that everybody can deal correctly with >> version number, simply because this has been tested less frequently. > > Agree on that. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ken.grewal@intel.com Thu Dec 17 09:21: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 4464F3A6970; Thu, 17 Dec 2009 09:21:00 -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 lbaEe0We4TQE; Thu, 17 Dec 2009 09:20:58 -0800 (PST) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by core3.amsl.com (Postfix) with ESMTP id 0A07C3A67E6; Thu, 17 Dec 2009 09:20:58 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 17 Dec 2009 09:20:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.47,316,1257148800"; d="scan'208";a="224080095" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by azsmga001.ch.intel.com with ESMTP; 17 Dec 2009 09:20:43 -0800 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by rrsmsx602.amr.corp.intel.com (10.31.0.33) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 17 Dec 2009 10:20:34 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Thu, 17 Dec 2009 10:20:34 -0700 From: "Grewal, Ken" To: McCann Peter-A001034 , Scott C Moonen Date: Thu, 17 Dec 2009 10:19:00 -0700 Thread-Topic: WESP and combined-mode algorithms Thread-Index: Acp+fdZ2TzlKeZE5S22IQlhgTHk/dwAAQeJwAC6EAPA= Message-ID: References: <274D46DDEB9F2244B2F1EA66B3FF54BC05FCF8C9@de01exm70.ds.mot.com> <274D46DDEB9F2244B2F1EA66B3FF54BC05FCF9AC@de01exm70.ds.mot.com> In-Reply-To: <274D46DDEB9F2244B2F1EA66B3FF54BC05FCF9AC@de01exm70.ds.mot.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" , "ipsec-bounces@ietf.org" , "gen-art@ietf.org" , "draft-ietf-ipsecme-traffic-visibility.all@tools.ietf.org" Subject: Re: [IPsec] WESP and combined-mode 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, 17 Dec 2009 17:21:00 -0000 Hi Scott, Peter, This text was kept simple deliberately, so we would not need to cover every= single case of different algorithm permutations. =20 The intention was as Peter indicates below "... "augmented" meant that the = bytes would be logically prepended to the existing ESP data before the ICV = was calculated...". This is the same intention for AEAD algorithms, where the WESP header would= be prepended to the ESP header and part of the AAD.=20 If you think it adds additional clarity by explicitly specifying these 'rul= es', then we could certainly elaborate on the section as you describe below= .=20 And I agree that the '"four" should be changed' comment, which was an overs= ight due to last minute addition for IPv6 padding requirements.=20 Thanks,=20 - Ken >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >Of McCann Peter-A001034 >Sent: Wednesday, December 16, 2009 10:45 AM >To: Scott C Moonen >Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; gen-art@ietf.org; draft- >ietf-ipsecme-traffic-visibility.all@tools.ietf.org >Subject: Re: [IPsec] WESP and combined-mode algorithms > >Hi, Scott, > >Your comments make sense; I had assumed that "augmented" meant >that the bytes would be logically prepended to the existing ESP >data before the ICV was calculated, and that this notion was >well-defined wrt existing ESP ICV methods. I am not as familiar >with the combined mode AAD and how that works, so I'd defer to >your and the authors' judgement on whether additional specification >is needed. > >I do agree that the "four" should be changed. We should also keep >in mind the UDP encapsulation described in section 2.1, which adds >a header of 16 bytes, so we could say, "four, eight, or sixteen". > >-Pete > >Scott C Moonen wrote: >> Peter, your comment below made me go back and re-read the draft. >> Section 2.2 of this draft makes this statement: >> >> In the diagrams below, "WESP ICV" refers to the ICV computation as >> modified by this specification. Namely, the ESP ICV computation is >> augmented to include the four octets that constitute the WESP >> header. Otherwise, the ICV computation is as specified by ESP >> [RFC4303]. >> >> In general I wonder if this paragraph should be beefed up a bit. >> Tables 1 and 2 of RFC 4303 go into specific detail as to the order in >> which things are included in the ICV calculation, and simply saying >> "augmented" leaves some ambiguity as to where the WESP data appears. >> This paragraph should also probably say "four or eight" instead of >> "four". Finally, I wonder if the document should go into even more >> detail on how the WESP header is authenticated for combined-mode >> algorithms. Typically those algorithms have "additional >> authentication data", and I wonder if we should document specifically >> how the WESP header appears in the AAD for currently specified >> algorithms, and also document the expectation that future >> combined-mode RFCs should explicitly mention how a WESP header would >> appear in their AAD. >> >> >> Scott Moonen (smoonen@us.ibm.com) >> z/OS Communications Server TCP/IP Development >> http://www.linkedin.com/in/smoonen >> >> >> >> >> From: "McCann Peter-A001034" >> To: , >> >> Cc: ipsec@ietf.org >> Date: 12/16/2009 12:20 PM >> Subject: Re: [IPsec] Gen-ART telechat review of >> draft-ietf-ipsecme-traffic-visibility-11 >> >> ________________________________ >> >> >> >> >> I have been selected as the General Area Review Team (Gen-ART) >> reviewer for this draft (for background on Gen-ART, please see >> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html >> >> > > ). >> >> Please wait for direction from your document shepherd or AD before >> posting a new version of the draft. >> >> Document: draft-ietf-ipsecme-traffic-visibility-11 >> Reviewer: Pete McCann >> Review Date: 16 Dec 2009 >> IESG Telechat date: 17 Dec 2009 >> >> Summary: Ready >> >> Major issues: none >> Minor issues: none >> Nits/editorial comments: none >> >> This version addresses my previous comment adequately. >> >> -Pete >> >> >> >> McCann Peter-A001034 wrote: >>> I have been selected as the General Area Review Team (Gen-ART) >>> reviewer for this draft (for background on Gen-ART, please see >>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html >>> >>> >> > ). >>> >>> Please resolve these comments along with any other Last Call comments >>> you may receive. >>> >>> Document: draft-ietf-ipsecme-traffic-visibility-09 >>> Reviewer: Pete McCann >>> Review Date: 2009-10-29 >>> IETF LC End Date: 2009-10-28 >>> IESG Telechat date: unknown >>> >>> Summary: One minor issue to discuss >>> >>> Major issues: none >>> >>> Minor issues: >>> >>> Section 2: >>> As can be seen, the WESP format extends the standard ESP header >>> by the first 4 octets for IPv4 and by 8 octets for IPv6. The >>> WESP header is integrity protected, along with all the fields >>> specified for ESP in RFC 4303. >>> Normally ESP wouldn't need to process encapsulation headers that >>> appear prior to the SPI. Won't this require modification of the ESP >>> implementation, possibly breaking its modularity? Would it be >>> problematic for certain algorithms to include this data? It might be >>> good to state that. >>> >>> Nits/editorial comments: none >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From ken.grewal@intel.com Thu Dec 17 09:21: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 EEDE228C12A; Thu, 17 Dec 2009 09:21:10 -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 rzPT47anosyB; Thu, 17 Dec 2009 09:21:05 -0800 (PST) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by core3.amsl.com (Postfix) with ESMTP id 990583A67E6; Thu, 17 Dec 2009 09:21:04 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 17 Dec 2009 09:20:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.47,316,1257148800"; d="scan'208";a="224080149" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by azsmga001.ch.intel.com with ESMTP; 17 Dec 2009 09:20:50 -0800 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx603.amr.corp.intel.com ([10.31.0.57]) with mapi; Thu, 17 Dec 2009 10:20:49 -0700 From: "Grewal, Ken" To: Jack Kohn , Russ Housley Date: Thu, 17 Dec 2009 10:19:15 -0700 Thread-Topic: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Thread-Index: Acp+qCrqY8kwUrnsQ6iHegsWubg3fwAkaqlg Message-ID: References: <20091216225945.239373A6AA1@core3.amsl.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "iesg@ietf.org" Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 17 Dec 2009 17:21:11 -0000 Agreed.=20 Thanks,=20 Ken =20 >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >Of Jack Kohn >Sent: Wednesday, December 16, 2009 3:33 PM >To: Russ Housley >Cc: ipsec@ietf.org; iesg@ietf.org >Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility > >My two bits on this and I'll let the authors/chairs explain in detail .. > >On Thu, Dec 17, 2009 at 4:29 AM, Russ Housley >wrote: >> Discuss: >> =A0The primary motivation for this work is to allow a middlebox to peek >> =A0into integrity protected (but not encrypted) IPsec packets. Some >> =A0integrity-check algorithms use an IV, a middlebox cannot alway know >> =A0where the payload starts. =A0Unlike the IPsec peer that negotiated th= e >> =A0algorithm in the IKE exchange, the middlebox does not know which >> =A0integrity-check algorithm is in use, and thus doe s not know if an IV >> =A0is present or how long it might be. >> >> =A0The document allows the encapsulation of encrypted IPsec traffic. >> =A0Why? =A0I cannot see the justification for the use if WESP at all if >> =A0the IPsec traffic is encrypted. > >This was discussed and i think the idea was not to limit WESP for just >ESP-NULL. One does not lose anything by defining WESP for encrypted >packets (besides the additional bytes in the header). However, by >keeping provisions for this, we are free to define other extensions >which might later work for encrypted packets. > >I think its a good idea to keep WESP flexible and see how it evolves >in the wild. In the worst case, no one would use it for encrypted >packets .. > >Jack >> >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From ken.grewal@intel.com Thu Dec 17 09:21: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 2086228C144; Thu, 17 Dec 2009 09:21:19 -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 xDL0mIfF8VMV; Thu, 17 Dec 2009 09:21:17 -0800 (PST) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by core3.amsl.com (Postfix) with ESMTP id 82D243A69A1; Thu, 17 Dec 2009 09:21:15 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 17 Dec 2009 09:21:01 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.47,316,1257148800"; d="scan'208";a="224080245" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by azsmga001.ch.intel.com with ESMTP; 17 Dec 2009 09:21:00 -0800 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Thu, 17 Dec 2009 10:21:00 -0700 From: "Grewal, Ken" To: Tero Kivinen , Yaron Sheffer Date: Thu, 17 Dec 2009 10:19:26 -0700 Thread-Topic: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Thread-Index: Acp/EQYQTXS7FuEXSD6r3nHxmdIkQAAKXUPg Message-ID: References: <20091217023458.GA23757@mactavish> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> <19242.7719.715250.335841@fireball.kivinen.iki.fi> In-Reply-To: <19242.7719.715250.335841@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: "ipsec@ietf.org" , Russ Housley , "iesg@ietf.org" , Dan McDonald Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 17 Dec 2009 17:21:19 -0000 Some comments inline... >It does make more complexity for the middle boxes as they need to cope >with both encrypted WESP and ESP-NULL WESP, thus they still cannot use >just the WESP protocol number to indicate this packet is clear text. >Now they also need to check the bit in the header, and if we add more >extensions to WESP, they need to start doing even more processing etc, >and quite soon WESP is more complex than what AH is now. [Ken] I do not think that checking one more bit adds too much additional co= mplexity, compared with extracting the offsets and protocol Information from the header. It does provide compatibility for both encrypt= ed and unencrypted traffic.=20 If we add more extensions to WESP, then those need to be evaluated based on= the cost / complexity Vs. benefit and that will be a separate debate.=20 >ESP is extensible, but it just requires out of band communication to >negotiate those extensions. We currently already have ESP extensions >like extended sequence numbers (ESN), Explicit Congestion Notification >(ECN), Traffic Flow Confidentiality (TFC), and Combined mode >algorithms. > >Those were added after initial ESP was created, and they are >negotiated using IKEv2 (or some other method). > >ESP does not offer extensibility that can be done without out of band >communication, and as that out of band communication is normally >encrypted (inside IKEv2) that means middle boxes cannot process it. > [Ken] I think this is the whole point. All the work on ESP/IPsec this far h= as been considering a two party interaction (outside the multicast context!= ). Now there is a third party - the middle box, which would like to gain so= me additional information in order to provide valuable network services. Th= e end boxes already know what is being negotiated, so just making changes t= o IKE to add additional capability is insufficient in certain scenarios (wh= ile perfectly sufficient in others). We need to provide additional informat= ion in the data path, hence the need for WESP.=20 From smoonen@us.ibm.com Thu Dec 17 11:09: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 EFB863A6964 for ; Thu, 17 Dec 2009 11:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[AWL=-1.313, 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 oOppda16qsTJ for ; Thu, 17 Dec 2009 11:09:52 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id 5E7183A68FA for ; Thu, 17 Dec 2009 11:09:52 -0800 (PST) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e37.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nBHJ8JiM021427 for ; Thu, 17 Dec 2009 12:08:19 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBHJ9BWa065264 for ; Thu, 17 Dec 2009 12:09:14 -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 nBHJ9BxN011541 for ; Thu, 17 Dec 2009 12:09:11 -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 nBHJ990w011456; Thu, 17 Dec 2009 12:09:11 -0700 In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> 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 12/17/2009 02:04:29 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 12/17/2009 02:04:29 PM, Serialize complete at 12/17/2009 02:04:29 PM, S/MIME Sign failed at 12/17/2009 02:04:29 PM: 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 12/17/2009 02:04:45 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 12/17/2009 02:04:45 PM, Serialize complete at 12/17/2009 02:04:45 PM, S/MIME Sign failed at 12/17/2009 02:04:45 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 12/17/2009 12:09:10, Serialize complete at 12/17/2009 12:09:10 To: Paul Hoffman X-KeepSent: 542BA19B:DBBEEE82-8525768F:00684FF8; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen Message-ID: Date: Thu, 17 Dec 2009 14:09:09 -0500 Content-Type: multipart/alternative; boundary="=_alternative 0068CE158525768F_=" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Issue #129: Traffic Selector and ICMPv6/MIPv6 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, 17 Dec 2009 19:09:54 -0000 This is a multipart message in MIME format. --=_alternative 0068CE158525768F_= Content-Type: text/plain; charset="US-ASCII" I suggest replacing the "Start Port" and "End Port" bullets in section 3.13.1 with the following: o Start Port (2 octets) - Value specifying the smallest port number allowed by this Traffic Selector. For protocols for which port is undefined (including protocol 0), or if all ports are allowed, this field MUST be zero. ICMP and ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are represented in this field as specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type and Code values are treated as a single 16-bit integer port number, with Type in the most significant eight bits and Code in the least significant eight bits. MIPv6 MH Type values are treated as a single 16-bit integer port number, with Type in the most significant eight bits. o End Port (2 octets) - Value specifying the largest port number allowed by this Traffic Selector. For protocols for which port is undefined (including protocol 0), or if all ports are allowed, this field MUST be 65535. ICMP and ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are represented in this field as specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type and Code values are treated as a single 16-bit integer port number, with Type in the most significant eight bits and Code in the least significant eight bits. MIPv6 MH Type values are treated as a single 16-bit integer port number, with Type in the most significant eight bits. As an alternative, for readability we could consider splitting each of these bullets into two paragraphs, starting the second paragraph with the sentence "ICMP and ICMPv6 ..." Additionally, I suggest replacing the two later paragraphs in section 3.13.1 starting with "The traffic selector types ..." and "Traffic selectors can use ..." with the following single paragraph: The traffic selector types 7 and 8 can also refer to ICMP or ICMPv6 type and code fields, as well as MH Type fields for the IPv6 mobility header [MIPV6]. Note, however, that neither ICMP nor MIPv6 packets have separate source and destination fields. The method for specifying the traffic selectors for ICMP and MIPv6 is shown by example in Section 4.4.1.3 of [IPSECARCH]. 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: "ipsec@ietf.org" Date: 12/15/2009 04:30 PM Subject: Issue #129: Traffic Selector and ICMPv6/MIPv6 At 2:28 PM -0500 12/15/09, Scott C Moonen wrote: >But RFC 4301 already specifies this in section 4.4.1.1. Given this, I think it's incorrect to treat this as unspecified in ikev2bis: > > * If the Next Layer Protocol is a Mobility Header, . . . > For IKE, the IPv6 Mobility Header > message type (MH type) is placed in the most significant > eight bits of the 16-bit local "port" selector. > > * If the Next Layer Protocol value is ICMP, . . . > For IKE, the message type is placed in the most significant 8 > bits of the 16-bit selector and the code is placed in the > least significant 8 bits. . . . > >It's less clear that this addresses ICMPv6 than MIPv6, but but elsewhere in the document "ICMP" is explicitly used in a generic sense, and I think we're on pretty good ground for both. I'm aware of at least one implementation other than ours that uses both MH type and ICMPv6 type/code in this fashion in IKEv2. > >I'd be willing to work on alternative text for 3.13.1 if others agree, The ticket is assigned to you. :-) --Paul Hoffman, Director --VPN Consortium --=_alternative 0068CE158525768F_= Content-Type: text/html; charset="US-ASCII"
I suggest replacing the "Start Port" and "End Port" bullets in section 3.13.1 with the following:

   o  Start Port (2 octets) - Value specifying the smallest port number
      allowed by this Traffic Selector.  For protocols for which port is
      undefined (including protocol 0), or if all ports are allowed,
      this field MUST be zero.  ICMP and ICMPv6 Type and Code values, as
      well as MIPv6 MH Type values, are represented in this field as
      specified in Section 4.4.1.1 of [IPSECARCH].  ICMP Type and Code
      values are treated as a single 16-bit integer port number, with
      Type in the most significant eight bits and Code in the least
      significant eight bits.  MIPv6 MH Type values are treated as a
      single 16-bit integer port number, with Type in the most
      significant eight bits.

   o  End Port (2 octets) - Value specifying the largest port number
      allowed by this Traffic Selector.  For protocols for which port is
      undefined (including protocol 0), or if all ports are allowed,
      this field MUST be 65535.  ICMP and ICMPv6 Type and Code values, as
      well as MIPv6 MH Type values, are represented in this field as
      specified in Section 4.4.1.1 of [IPSECARCH].  ICMP Type and Code
      values are treated as a single 16-bit integer port number, with
      Type in the most significant eight bits and Code in the least
      significant eight bits.  MIPv6 MH Type values are treated as a
      single 16-bit integer port number, with Type in the most
      significant eight bits.

As an alternative, for readability we could consider splitting each of these bullets into two paragraphs, starting the second paragraph with the sentence "ICMP and ICMPv6 ..."

Additionally, I suggest replacing the two later paragraphs in section 3.13.1 starting with "The traffic selector types ..." and "Traffic selectors can use ..." with the following single paragraph:

   The traffic selector types 7 and 8 can also refer to ICMP or ICMPv6
   type and code fields, as well as MH Type fields for the IPv6 mobility
   header [MIPV6].  Note, however, that neither ICMP nor MIPv6 packets
   have separate source and destination fields.  The method for
   specifying the traffic selectors for ICMP and MIPv6 is shown by
   example in Section 4.4.1.3 of [IPSECARCH].


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: "ipsec@ietf.org" <ipsec@ietf.org>
Date: 12/15/2009 04:30 PM
Subject: Issue #129: Traffic Selector and ICMPv6/MIPv6




At 2:28 PM -0500 12/15/09, Scott C Moonen wrote:
>But RFC 4301 already specifies this in section 4.4.1.1.  Given this, I think it's incorrect to treat this as unspecified in ikev2bis:
>
>         * If the Next Layer Protocol is a Mobility Header, . . .
>           For IKE, the IPv6 Mobility Header
>           message type (MH type) is placed in the most significant
>           eight bits of the 16-bit local "port" selector.
>
>         * If the Next Layer Protocol value is ICMP, . . .
>           For IKE, the message type is placed in the most significant 8
>           bits of the 16-bit selector and the code is placed in the
>           least significant 8 bits. . . .
>
>It's less clear that this addresses ICMPv6 than MIPv6, but but elsewhere in the document "ICMP" is explicitly used in a generic sense, and I think we're on pretty good ground for both.  I'm aware of at least one implementation other than ours that uses both MH type and ICMPv6 type/code in this fashion in IKEv2.
>
>I'd be willing to work on alternative text for 3.13.1 if others agree,

The ticket is assigned to you. :-)

--Paul Hoffman, Director
--VPN Consortium

--=_alternative 0068CE158525768F_=-- From julienl@qualcomm.com Thu Dec 17 11:34: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 33ECC3A6A05 for ; Thu, 17 Dec 2009 11:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.496 X-Spam-Level: X-Spam-Status: No, score=-103.496 tagged_above=-999 required=5 tests=[AWL=-0.897, BAYES_00=-2.599, 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 V7dK2Tu5aF3b for ; Thu, 17 Dec 2009 11:34:22 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id CFC433A6A07 for ; Thu, 17 Dec 2009 11:34:21 -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=1261078447; x=1292614447; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Scott=20C=20Moonen=20,=20Paul =20Hoffman=20|CC:=20"ipsec@ietf.or g"=20|Date:=20Thu,=2017=20Dec=202009=2011 :33:53=20-0800|Subject:=20RE:=20[IPsec]=20Issue=20#129: =20Traffic=20Selector=20and=20ICMPv6/MIPv6|Thread-Topic: =20[IPsec]=20Issue=20#129:=20Traffic=20Selector=20and=20I CMPv6/MIPv6|Thread-Index:=20Acp/TIHOwGHBv1eaQFeYfthXunoFP AAAvVzQ|Message-ID:=20|References:=20<7F9A 6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.check point.com>=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=20 |In-Reply-To:=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"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=7RqRfdYp3Ams0eI+XnmoN+ksotn7U56vfiftmCdXJoc=; b=S3l1OTRDcyh4Nw8asLi0M0CBcslrj25goFKyCsI2AehweODo9MwKC2o2 fuczhr39SnebRsFYSbxocKGGrLmena4PiiUgC0E9QSQ7g4SUsZ5OVRO+y ztQlZKdGOUzKQUalcqJrvvz8M110Fd0Mr5BGTA+Mct9naW9x5eUif7+ox E=; X-IronPort-AV: E=McAfee;i="5400,1158,5835"; a="30213249" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 17 Dec 2009 11:33:55 -0800 Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nBHJXtmL032243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 17 Dec 2009 11:33:55 -0800 X-IronPort-AV: E=Sophos;i="4.47,414,1257148800"; d="scan'208";a="24541268" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 17 Dec 2009 11:33:54 -0800 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 17 Dec 2009 11:33:54 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Thu, 17 Dec 2009 11:33:54 -0800 From: "Laganier, Julien" To: Scott C Moonen , Paul Hoffman Date: Thu, 17 Dec 2009 11:33:53 -0800 Thread-Topic: [IPsec] Issue #129: Traffic Selector and ICMPv6/MIPv6 Thread-Index: Acp/TIHOwGHBv1eaQFeYfthXunoFPAAAvVzQ Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Issue #129: Traffic Selector and ICMPv6/MIPv6 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, 17 Dec 2009 19:34:23 -0000 Thanks for the text proposal, Scott. I'd like to suggest a slight variation: "MIPv6 MH Type values are treated a= s a single 16-bit integer port number, with Type in the most significant ei= ght bits and the least significant eight bits set to zero." --julien ------------------------------------------------------- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= cott C Moonen Sent: Thursday, December 17, 2009 11:09 AM To: Paul Hoffman Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #129: Traffic Selector and ICMPv6/MIPv6 I suggest replacing the "Start Port" and "End Port" bullets in section 3.13= .1 with the following:=20 =A0 =A0o =A0Start Port (2 octets) - Value specifying the smallest port numb= er=20 =A0 =A0 =A0 allowed by this Traffic Selector. =A0For protocols for which po= rt is=20 =A0 =A0 =A0 undefined (including protocol 0), or if all ports are allowed,= =20 =A0 =A0 =A0 this field MUST be zero. =A0ICMP and ICMPv6 Type and Code value= s, as=20 =A0 =A0 =A0 well as MIPv6 MH Type values, are represented in this field as= =20 =A0 =A0 =A0 specified in Section 4.4.1.1 of [IPSECARCH]. =A0ICMP Type and C= ode=20 =A0 =A0 =A0 values are treated as a single 16-bit integer port number, with= =20 =A0 =A0 =A0 Type in the most significant eight bits and Code in the least=20 =A0 =A0 =A0 significant eight bits. =A0MIPv6 MH Type values are treated as = a=20 =A0 =A0 =A0 single 16-bit integer port number, with Type in the most=20 =A0 =A0 =A0 significant eight bits.=20 =A0 =A0o =A0End Port (2 octets) - Value specifying the largest port number= =20 =A0 =A0 =A0 allowed by this Traffic Selector. =A0For protocols for which po= rt is=20 =A0 =A0 =A0 undefined (including protocol 0), or if all ports are allowed,= =20 =A0 =A0 =A0 this field MUST be 65535. =A0ICMP and ICMPv6 Type and Code valu= es, as=20 =A0 =A0 =A0 well as MIPv6 MH Type values, are represented in this field as= =20 =A0 =A0 =A0 specified in Section 4.4.1.1 of [IPSECARCH]. =A0ICMP Type and C= ode=20 =A0 =A0 =A0 values are treated as a single 16-bit integer port number, with= =20 =A0 =A0 =A0 Type in the most significant eight bits and Code in the least=20 =A0 =A0 =A0 significant eight bits. =A0MIPv6 MH Type values are treated as = a=20 =A0 =A0 =A0 single 16-bit integer port number, with Type in the most=20 =A0 =A0 =A0 significant eight bits.=20 As an alternative, for readability we could consider splitting each of thes= e bullets into two paragraphs, starting the second paragraph with the sente= nce "ICMP and ICMPv6 ..."=20 Additionally, I suggest replacing the two later paragraphs in section 3.13.= 1 starting with "The traffic selector types ..." and "Traffic selectors can= use ..." with the following single paragraph:=20 =A0 =A0The traffic selector types 7 and 8 can also refer to ICMP or ICMPv6= =20 =A0 =A0type and code fields, as well as MH Type fields for the IPv6 mobilit= y=20 =A0 =A0header [MIPV6]. =A0Note, however, that neither ICMP nor MIPv6 packet= s=20 =A0 =A0have separate source and destination fields. =A0The method for=20 =A0 =A0specifying the traffic selectors for ICMP and MIPv6 is shown by=20 =A0 =A0example in Section 4.4.1.3 of [IPSECARCH].=20 Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen=20 From:=20 Paul Hoffman =20 To:=20 Scott C Moonen/Raleigh/IBM@IBMUS=20 Cc:=20 "ipsec@ietf.org" =20 Date:=20 12/15/2009 04:30 PM=20 Subject:=20 Issue #129: Traffic Selector and ICMPv6/MIPv6 ________________________________________ At 2:28 PM -0500 12/15/09, Scott C Moonen wrote: >But RFC 4301 already specifies this in section 4.4.1.1. =A0Given this, I t= hink it's incorrect to treat this as unspecified in ikev2bis: > > =A0 =A0 =A0 =A0 * If the Next Layer Protocol is a Mobility Header, . . . > =A0 =A0 =A0 =A0 =A0 For IKE, the IPv6 Mobility Header > =A0 =A0 =A0 =A0 =A0 message type (MH type) is placed in the most signific= ant > =A0 =A0 =A0 =A0 =A0 eight bits of the 16-bit local "port" selector. > > =A0 =A0 =A0 =A0 * If the Next Layer Protocol value is ICMP, . . . > =A0 =A0 =A0 =A0 =A0 For IKE, the message type is placed in the most signi= ficant 8 > =A0 =A0 =A0 =A0 =A0 bits of the 16-bit selector and the code is placed in= the > =A0 =A0 =A0 =A0 =A0 least significant 8 bits. . . . > >It's less clear that this addresses ICMPv6 than MIPv6, but but elsewhere i= n the document "ICMP" is explicitly used in a generic sense, and I think we= 're on pretty good ground for both. =A0I'm aware of at least one implementa= tion other than ours that uses both MH type and ICMPv6 type/code in this fa= shion in IKEv2. > >I'd be willing to work on alternative text for 3.13.1 if others agree, The ticket is assigned to you. :-) --Paul Hoffman, Director --VPN Consortium From smoonen@us.ibm.com Thu Dec 17 11:47: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 8DD8828C162 for ; Thu, 17 Dec 2009 11:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.829 X-Spam-Level: X-Spam-Status: No, score=-5.829 tagged_above=-999 required=5 tests=[AWL=0.769, 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 bkh1eR5EHymo for ; Thu, 17 Dec 2009 11:47:39 -0800 (PST) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id D0CE23A67A3 for ; Thu, 17 Dec 2009 11:47:38 -0800 (PST) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e6.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id nBHJgsve018085 for ; Thu, 17 Dec 2009 14:42:54 -0500 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBHJlH6L132872 for ; Thu, 17 Dec 2009 14:47:17 -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 nBHJn93A001033 for ; Thu, 17 Dec 2009 12:49:09 -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 nBHJn9pd001030; Thu, 17 Dec 2009 12:49:09 -0700 In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893EA0C@il-ex01.ad.checkpoint.com> To: "Laganier, Julien" MIME-Version: 1.0 X-KeepSent: ABA22026:FC1BDB5A-8525768F:006BF4F5; 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 12/17/2009 02:39:49 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 12/17/2009 02:39:49 PM, Serialize complete at 12/17/2009 02:39:49 PM, S/MIME Sign failed at 12/17/2009 02:39:49 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 12/17/2009 12:47:16, Serialize complete at 12/17/2009 12:47:16 Message-ID: Date: Thu, 17 Dec 2009 14:47:15 -0500 Content-Type: multipart/alternative; boundary="=_alternative 006C04488525768F_=" Cc: "ipsec@ietf.org" , Paul Hoffman Subject: Re: [IPsec] Issue #129: Traffic Selector and ICMPv6/MIPv6 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, 17 Dec 2009 19:47:40 -0000 This is a multipart message in MIME format. --=_alternative 006C04488525768F_= Content-Type: text/plain; charset="US-ASCII" > I'd like to suggest a slight variation: "MIPv6 MH Type values are > treated as a single 16-bit integer port number, with Type in the > most significant eight bits and the least significant eight bits > set to zero." Julien, thanks. I agree with your suggestion, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: "Laganier, Julien" To: Scott C Moonen/Raleigh/IBM@IBMUS, Paul Hoffman Cc: "ipsec@ietf.org" Date: 12/17/2009 02:34 PM Subject: RE: [IPsec] Issue #129: Traffic Selector and ICMPv6/MIPv6 Thanks for the text proposal, Scott. I'd like to suggest a slight variation: "MIPv6 MH Type values are treated as a single 16-bit integer port number, with Type in the most significant eight bits and the least significant eight bits set to zero." --julien ------------------------------------------------------- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott C Moonen Sent: Thursday, December 17, 2009 11:09 AM To: Paul Hoffman Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #129: Traffic Selector and ICMPv6/MIPv6 I suggest replacing the "Start Port" and "End Port" bullets in section 3.13.1 with the following: o Start Port (2 octets) - Value specifying the smallest port number allowed by this Traffic Selector. For protocols for which port is undefined (including protocol 0), or if all ports are allowed, this field MUST be zero. ICMP and ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are represented in this field as specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type and Code values are treated as a single 16-bit integer port number, with Type in the most significant eight bits and Code in the least significant eight bits. MIPv6 MH Type values are treated as a single 16-bit integer port number, with Type in the most significant eight bits. o End Port (2 octets) - Value specifying the largest port number allowed by this Traffic Selector. For protocols for which port is undefined (including protocol 0), or if all ports are allowed, this field MUST be 65535. ICMP and ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are represented in this field as specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type and Code values are treated as a single 16-bit integer port number, with Type in the most significant eight bits and Code in the least significant eight bits. MIPv6 MH Type values are treated as a single 16-bit integer port number, with Type in the most significant eight bits. As an alternative, for readability we could consider splitting each of these bullets into two paragraphs, starting the second paragraph with the sentence "ICMP and ICMPv6 ..." Additionally, I suggest replacing the two later paragraphs in section 3.13.1 starting with "The traffic selector types ..." and "Traffic selectors can use ..." with the following single paragraph: The traffic selector types 7 and 8 can also refer to ICMP or ICMPv6 type and code fields, as well as MH Type fields for the IPv6 mobility header [MIPV6]. Note, however, that neither ICMP nor MIPv6 packets have separate source and destination fields. The method for specifying the traffic selectors for ICMP and MIPv6 is shown by example in Section 4.4.1.3 of [IPSECARCH]. 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: "ipsec@ietf.org" Date: 12/15/2009 04:30 PM Subject: Issue #129: Traffic Selector and ICMPv6/MIPv6 ________________________________________ At 2:28 PM -0500 12/15/09, Scott C Moonen wrote: >But RFC 4301 already specifies this in section 4.4.1.1. Given this, I think it's incorrect to treat this as unspecified in ikev2bis: > > * If the Next Layer Protocol is a Mobility Header, . . . > For IKE, the IPv6 Mobility Header > message type (MH type) is placed in the most significant > eight bits of the 16-bit local "port" selector. > > * If the Next Layer Protocol value is ICMP, . . . > For IKE, the message type is placed in the most significant 8 > bits of the 16-bit selector and the code is placed in the > least significant 8 bits. . . . > >It's less clear that this addresses ICMPv6 than MIPv6, but but elsewhere in the document "ICMP" is explicitly used in a generic sense, and I think we're on pretty good ground for both. I'm aware of at least one implementation other than ours that uses both MH type and ICMPv6 type/code in this fashion in IKEv2. > >I'd be willing to work on alternative text for 3.13.1 if others agree, The ticket is assigned to you. :-) --Paul Hoffman, Director --VPN Consortium --=_alternative 006C04488525768F_= Content-Type: text/html; charset="US-ASCII"
> I'd like to suggest a slight variation: "MIPv6 MH Type values are
> treated as a single 16-bit integer port number, with Type in the
> most significant eight bits and the least significant eight bits
> set to zero."

Julien, thanks.  I agree with your suggestion,


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


From: "Laganier, Julien" <julienl@qualcomm.com>
To: Scott C Moonen/Raleigh/IBM@IBMUS, Paul Hoffman <paul.hoffman@vpnc.org>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Date: 12/17/2009 02:34 PM
Subject: RE: [IPsec] Issue #129: Traffic Selector and ICMPv6/MIPv6




Thanks for the text proposal, Scott.

I'd like to suggest a slight variation: "MIPv6 MH Type values are treated as a single 16-bit integer port number, with Type in the most significant eight bits and the least significant eight bits set to zero."

--julien

-------------------------------------------------------
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott C Moonen
Sent: Thursday, December 17, 2009 11:09 AM
To: Paul Hoffman
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Issue #129: Traffic Selector and ICMPv6/MIPv6


I suggest replacing the "Start Port" and "End Port" bullets in section 3.13.1 with the following:

   o  Start Port (2 octets) - Value specifying the smallest port number
      allowed by this Traffic Selector.  For protocols for which port is
      undefined (including protocol 0), or if all ports are allowed,
      this field MUST be zero.  ICMP and ICMPv6 Type and Code values, as
      well as MIPv6 MH Type values, are represented in this field as
      specified in Section 4.4.1.1 of [IPSECARCH].  ICMP Type and Code
      values are treated as a single 16-bit integer port number, with
      Type in the most significant eight bits and Code in the least
      significant eight bits.  MIPv6 MH Type values are treated as a
      single 16-bit integer port number, with Type in the most
      significant eight bits.

   o  End Port (2 octets) - Value specifying the largest port number
      allowed by this Traffic Selector.  For protocols for which port is
      undefined (including protocol 0), or if all ports are allowed,
      this field MUST be 65535.  ICMP and ICMPv6 Type and Code values, as
      well as MIPv6 MH Type values, are represented in this field as
      specified in Section 4.4.1.1 of [IPSECARCH].  ICMP Type and Code
      values are treated as a single 16-bit integer port number, with
      Type in the most significant eight bits and Code in the least
      significant eight bits.  MIPv6 MH Type values are treated as a
      single 16-bit integer port number, with Type in the most
      significant eight bits.

As an alternative, for readability we could consider splitting each of these bullets into two paragraphs, starting the second paragraph with the sentence "ICMP and ICMPv6 ..."

Additionally, I suggest replacing the two later paragraphs in section 3.13.1 starting with "The traffic selector types ..." and "Traffic selectors can use ..." with the following single paragraph:

   The traffic selector types 7 and 8 can also refer to ICMP or ICMPv6
   type and code fields, as well as MH Type fields for the IPv6 mobility
   header [MIPV6].  Note, however, that neither ICMP nor MIPv6 packets
   have separate source and destination fields.  The method for
   specifying the traffic selectors for ICMP and MIPv6 is shown by
   example in Section 4.4.1.3 of [IPSECARCH].


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:
"ipsec@ietf.org" <ipsec@ietf.org>
Date:
12/15/2009 04:30 PM
Subject:
Issue #129: Traffic Selector and ICMPv6/MIPv6

________________________________________



At 2:28 PM -0500 12/15/09, Scott C Moonen wrote:
>But RFC 4301 already specifies this in section 4.4.1.1.  Given this, I think it's incorrect to treat this as unspecified in ikev2bis:
>
>         * If the Next Layer Protocol is a Mobility Header, . . .
>           For IKE, the IPv6 Mobility Header
>           message type (MH type) is placed in the most significant
>           eight bits of the 16-bit local "port" selector.
>
>         * If the Next Layer Protocol value is ICMP, . . .
>           For IKE, the message type is placed in the most significant 8
>           bits of the 16-bit selector and the code is placed in the
>           least significant 8 bits. . . .
>
>It's less clear that this addresses ICMPv6 than MIPv6, but but elsewhere in the document "ICMP" is explicitly used in a generic sense, and I think we're on pretty good ground for both.  I'm aware of at least one implementation other than ours that uses both MH type and ICMPv6 type/code in this fashion in IKEv2.
>
>I'd be willing to work on alternative text for 3.13.1 if others agree,

The ticket is assigned to you. :-)

--Paul Hoffman, Director
--VPN Consortium

--=_alternative 006C04488525768F_=-- From alper.yegin@yegin.org Thu Dec 17 15:50: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 00D4F3A6875 for ; Thu, 17 Dec 2009 15:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.317 X-Spam-Level: X-Spam-Status: No, score=-0.317 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, SARE_FWDLOOK=1.666] 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 3bWosByK+QSs for ; Thu, 17 Dec 2009 15:50:19 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id CAFB93A69FC for ; Thu, 17 Dec 2009 15:50:19 -0800 (PST) Received: from LENOVO ([216.123.155.200]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0M8fxz-1OG9Hi2hc3-00vqWt; Thu, 17 Dec 2009 18:49:54 -0500 From: "Alper Yegin" To: "'Nicolas Williams'" References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <1d38a3350912090742q1976ffefo85ef5e0e5627ec0b@mail.gmail.com> <023f01ca7908$480951b0$d81bf510$%yegin@yegin.org> <3824040C-7D40-4B46-B430-AE87D6729A19@checkpoint.com> <02c401ca7970$974303d0$c5c90b70$%yegin@yegin.org> <20091215183742.GV1516@Sun.COM> In-Reply-To: <20091215183742.GV1516@Sun.COM> Date: Fri, 18 Dec 2009 01:49:49 +0200 Message-ID: <00db01ca7f73$a21ce650$e656b2f0$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp9uNhPaST+NUt7QIqSAqc5X0EVcABsg34w Content-Language: en-us X-Provags-ID: V01U2FsdGVkX1823vrdBH2QqrOefHZ6UWG7hQlN0JBYdY2J/cX NV8kOfYY4Sx4kJnzhR7LFCtizc515WT+tJ7/KrimWRpazvBNOi Mjun9QbB3EboRfosFdPLw== Cc: 'Hui Deng' , ipsec@ietf.org, 'Yoav Nir' Subject: Re: [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: Thu, 17 Dec 2009 23:50:21 -0000 Hi, I'm hoping by now it is understood that "childless IKE SA" is just a technical detail of what is really on the table. The proposal on the table is "designing a network access authentication protocol based on IKEv2". That's what this WG and IETF should be discussing. Having multiple solutions for the very same problem space creates interoperability problem. If IETF has defined a protocol for a given problem, and if some other people come along and ask another solution be standardized for the very same problem, IETF needs a justification. Otherwise, we end up working "against" interoperability, not "for". The only justification I'm hearing is "we don't want to use PANA because it is not implemented in my stack." This is an extremely poor justification. One can say it for any new protocol, and choose to hack up whatever he/she has. How can growing PANA out of IKEv2 be any better than using PANA. IKEv2 is defined and used for creating IPsec SAs. Yeah, it needs to perform peer authentication, but that's for creating securing the IPsec SA creation. There are many other protocols that authenticate the peers for the sake of securely performing their own dedicated objectives. E.g., Mobile IP authenticates MN and HA for securely creating binding caches; RFC 3118 authenticates DHCP client and DHCP server for secure host configuration; etc. etc. Taking the peer authentication parts of these protocols and use it for totally different purposes is not right. > I don't see why we couldn't let IKEv2 have a go at displacing PANA in the marketplace. Few folks want to twist IKEv2 into network access authentication protocol (this proposal). Few other folks want to twist DHCP into network access authentication protocol (EAP-over-DHCP proposal). Few other folks want to twist HTTP into network access authentication protocol (EAP-over-HTTP proposal). They all have the exact same (poor) justification: We need EAP-over-Foo because we already have Foo. The above list is what is already being entertained here and there. The list is very likely to grow. How can that not be a problem if all were getting standardized (for the sake of argument, let's forget about the technical brokenness of the last two proposals). Every one of them think they were saving by implementing "one", but in fact all are getting implemented eventually. Each access authentication specific feature needs to be reproduced on each such protocol. A multi-mode terminal (host) and NAS need to implement all..... > What's really not desirable is non-interoperability, and that, I believe, we can achieve by making PANA the required to implement network access protocol. "We" (IETF) do not and cannot make PANA "required to implement" network access authentication protocol. Other SDOs/platforms make such mandates. So, I don't think saying "no" to redundant solutions is a bad thing that that way. If someone is truly hung up on using IKEv2 purely for network access authentication, why can't they already do so? So what if it creates an IPsec SA. Just don't use it. > Suppose you want a combination of "peer authentication only" for some > traffic and "peer authentication + ESP/AH" for other kinds of traffic > (think of this as differentiated services). Then to use PANA for one > and IPsec for the other seems silly. Is this a real scenario? This is not the scenario Hui brought up. He's talking about Femto AP connecting to femto access network via WAN; in one case (a) WAN is already secured (e.g., via physical security) and he does not need to use IPsec at all; in the other case (b) WAN is open Internet and ne needs to use IPsec. In both cases, he needs to authenticate the Femto AP and he wants to use IKEv2 for that. And I say use PANA instead. So, PANA-based solution becomes this: For case (a): Use PANA for Femto AP authentication. That's all you need. For case (b): Use PANA for Femto AP authentication, use IKEv2 for setting up IPsec SA. .... I'm not disputing doability of this proposal. See, an even worse example is 3GPP2 using Mobile IPv4 authentication for L3 network access authentication between the MS (MN) and PDSN (FA). I guess we are lucky that they didn't come to IETF for tweaking RFC 4004 for that (they could get good number of support, if we were going with that indication only). This can also made to work, but IMHO there is much bigger harm than benefit in this case. Alper > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Nicolas Williams > Sent: Tuesday, December 15, 2009 8:38 PM > To: Alper Yegin > Cc: 'Hui Deng'; ipsec@ietf.org; 'Yoav Nir' > Subject: Re: [IPsec] Proposed work item: Childless IKE SA > > On Thu, Dec 10, 2009 at 10:12:54AM +0200, Alper Yegin wrote: > > > The "Do phase 1 first, and phase 2 as traffic demands it" > motivation is > > > from the remote access VPN domain (though may be useful for > others). > > > > > > The "Do only phase 1, because we don't need encryption and MAC, > just > > > peer authentication" motivation is from the 3GPP (though it could > be > > > useful for others) > > > > > > The "Do only phase 1 to discover if we're in or out of the secure > > > network (then do phase 2 if we're out)" motivation is also mostly a > > > remote access VPN thing. > > > > > > The other motivations were from suggestions by others, and will be > > > hashed out (or taken out of the document) should this become a WG > > > document. > > > > I'm particularly concerned about reinventing the wheel aspect with > your > > second bullet, as I elaborated in response to Hui in my previous > email. > > > > As for the other motivations, I'm not sure the savings are worth the > effort. > > Imho.... > > Suppose you want a combination of "peer authentication only" for some > traffic and "peer authentication + ESP/AH" for other kinds of traffic > (think of this as differentiated services). Then to use PANA for one > and IPsec for the other seems silly. > > I don't see why an applicability statement should not suffice to > prevent > the scenario that you dislike (which I think is: IKEv2 displacing PANA > where IKEv2 should be considered to not be applicable). But see below. > > The issue to settle here, as I see it, is: are there any uses of > childless IKEv2 SAs that justify the work? > > Of the various use case scenarios given in the I-D the first is the > most > convincing, though the lack of childless IKEv2 SAs hardly seems > problematic there. The last use case is very interesting, but very > forward looking. The next to last use case is specific to an EAP > method, thus not very interesting to this WG (IMO) except as a way to > keep divergence between base spec and the EAP method to a minimum. The > other use case scenarios seem to encroach on the applicability of PANA. > > Just based on that my support is lukewarm. > > Quite aside from that, I question the applicability statement that you > seem to be making. PANA and IKEv2-with-childless-SAs seem roughly > equivalent, with IKEv2 being more general. Why should we forbid use of > the latter for network access control? Certainly having two such > protocols is not exactly desirable, but it's not clear to me that PANA > is the protocol that should win. What's really not desirable is non- > interoperability, and that, I believe, we can achieve by making PANA > the > required to implement network access protocol. I don't see why we > couldn't let IKEv2 have a go at displacing PANA in the marketplace. If > there is support in the WG for it, so be it. > > Nico > -- > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From wierbows@us.ibm.com Thu Dec 17 16:36: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 93E013A68C8; Thu, 17 Dec 2009 16:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 tU0Lqv7N7IAr; Thu, 17 Dec 2009 16:36:25 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id 5BAE63A6844; Thu, 17 Dec 2009 16:36:25 -0800 (PST) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e1.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id nBI0XXdn000540; Thu, 17 Dec 2009 19:33:33 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBI0a9Qc120636; Thu, 17 Dec 2009 19:36:10 -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 nBI0a9oa023299; Thu, 17 Dec 2009 19:36:09 -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 nBI0a9qA023295; Thu, 17 Dec 2009 19:36:09 -0500 In-Reply-To: <19240.48239.23842.571746@fireball.kivinen.iki.fi> References: <006FEB08D9C6444AB014105C9AEB133FB36A4EC57A@il-ex01.ad.checkpoint.com> <19240.48239.23842.571746@fireball.kivinen.iki.fi> X-KeepSent: 126BA033:CACEF956-85257690:0002D902; type=4; name=$KeepSent To: IPsecme WG , ipsec-bounces@ietf.org X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Thu, 17 Dec 2009 19:36:07 -0500 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 12/17/2009 19:36:09 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: [IPsec] Issue #128: Can implementations not reply fully to Deletes? 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, 18 Dec 2009 00:36:26 -0000 I'm not sure I'm going to buy that garage door opener if I have to wait for dead peer detection before I can open or close it again :>). Dave Wierbowski From: Tero Kivinen To: Yoav Nir Cc: IPsecme WG , Paul Hoffman Date: 12/16/2009 05:55 AM Subject: Re: [IPsec] Issue #128: Can implementations not reply fully to Deletes? Sent by: ipsec-bounces@ietf.org Yoav Nir writes: > Section 1.4.1 also says: > > "A node MAY refuse to accept incoming data on half-closed > connections but MUST NOT unilaterally close them and reuse the SPIs." > > So if your peer is only responding with empty INFORMATIONAL > responses to your deletes, you're going to accumulate more and more > stale inbound SAs. In which case you follow the text in 1.4.1 which says: If connection state becomes sufficiently messed up, a node MAY close the IKE SA; doing so will implicitly close all SAs negotiated under it. It can then rebuild the SAs it needs on a clean base under a new IKE SA. The response to a request that deletes the IKE SA is an empty Informational response. and that will fix the situation with minimal implementation. Also with minimal implementation you cannot really get more and more stale inbound SAs, as if implementation is so small it does not support Delete notifications, it most likely doesnot support more than one Child SA, i.e. it does not support CREATE_CHILD_SA (it will always reply with NO_ADDITIONAL_SAS to that), thus at most you get one extra SA. And as other end didn't understand the delete, it is not stale, as it will be working half-closed SAs, it is outbound SA for you and if you encrypt data and send it to the minimal implementation it will still decrypt, and process that packet. It will might even send reply back to your already closed inbound SA, but you will drop that as you have already deleted that half. > One of these statements has to go. Not really. Note, that I would expect all normal versions of the IPsec to support both CREATE_CHILD_SA and delete notifications, but we are talking now about the minimal requirements. I.e. if you have your battery powered garage door opener, who knows IKEv2 just enough to do IKE_SA_INIT (with exactly one set of crypto algorithms), IKE_AUTH (with preshared key and with one set of crypto algorithms and fixed traffic selectors). It only supports this exactly one Child SA, which it uses to send message saying "Open or Close the garage door" and after 30 seconds if no more buttons is pressed it will shutdown. As it does not support CREATE_CHILD_SA or INFORMATIONAL in any other way than sending NO_ADDITIONAL_SAS or empty reply back, it does not know how to process delete payloads at all. It even does not know how to delete the IKE SA, but that does not matter as it automatically goes away when it automatically turns itself off. It expects that your home area network server which acted as responder to its IPsec connection is smart enough to start DPD later and when garage door opener does not reply it will also delete the IKE SA from the server side. This kind of minimal implementations are not meant to be used in normal operations. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From rsjenwar@gmail.com Thu Dec 17 18:50: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 A556C3A690C for ; Thu, 17 Dec 2009 18:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_FWDLOOK=1.666] 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-soMrAqKt25 for ; Thu, 17 Dec 2009 18:50:23 -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 2A8A23A68B8 for ; Thu, 17 Dec 2009 18:50:23 -0800 (PST) Received: by ewy6 with SMTP id 6so33373ewy.29 for ; Thu, 17 Dec 2009 18:50: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=7Sg3kMvwazni37xomossI6Be98QFdODyvKXGf6EBaZQ=; b=xLiuOLKTBQd4DpnaZZEAZPJHycGmp7IzBDsfLfl2fqJ8OzHHvO43r3hFn/23qJKoYR pJ3jKHjsNXLdGPWKuVRNvylGtkvTQ4Wjul8zKMrzx4NtKUxDjFNKoTsiUq99EwKMwve3 HA/W9BahIEScYyh2xIZAECVVEz7Dv3kNmqg14= 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=xCyVdOaqsA9zEk955nGPlMO/T5ga5Sh+cx+GlqjraY921FrRnTYtla8BHl4r2+t5Y+ TqMNIE1PNzpddBjUHDiPgZGgIw+ttVSeZnWPW88upjsnZ35iiWkONLUQnOwI8NdSkvy6 MFn/rrzBPXJyR7h3yr5De/Q/OXAI8CM+2cGfc= MIME-Version: 1.0 Received: by 10.216.90.133 with SMTP id e5mr1182157wef.23.1261104604398; Thu, 17 Dec 2009 18:50:04 -0800 (PST) In-Reply-To: <62778081976350302@unknownmsgid> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <1d38a3350912090742q1976ffefo85ef5e0e5627ec0b@mail.gmail.com> <023f01ca7908$480951b0$d81bf510$%yegin@yegin.org> <3824040C-7D40-4B46-B430-AE87D6729A19@checkpoint.com> <02c401ca7970$974303d0$c5c90b70$%yegin@yegin.org> <20091215183742.GV1516@Sun.COM> <62778081976350302@unknownmsgid> Date: Fri, 18 Dec 2009 08:20:04 +0530 Message-ID: <7ccecf670912171850n15dd3c42t2692bb1a355f7daf@mail.gmail.com> From: Raj Singh To: Alper Yegin Content-Type: multipart/alternative; boundary=0016e6dab052f84650047af7cb88 Cc: Hui Deng , ipsec , Yoav Nir , Nicolas Williams Subject: Re: [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: Fri, 18 Dec 2009 02:50:25 -0000 --0016e6dab052f84650047af7cb88 Content-Type: text/plain; charset=UTF-8 Hi Alper, On Fri, Dec 18, 2009 at 5:19 AM, Alper Yegin wrote: > Hi, > > I'm hoping by now it is understood that "childless IKE SA" is just a > technical detail of what is really on the table. The proposal on the table > is "designing a network access authentication protocol based on IKEv2". > That's what this WG and IETF should be discussing. > > Having multiple solutions for the very same problem space creates > interoperability problem. If IETF has defined a protocol for a given > problem, and if some other people come along and ask another solution be > standardized for the very same problem, IETF needs a justification. > Otherwise, we end up working "against" interoperability, not "for". > > The only justification I'm hearing is "we don't want to use PANA because it > is not implemented in my stack." This is an extremely poor justification. > One can say it for any new protocol, and choose to hack up whatever he/she > has. How can growing PANA out of IKEv2 be any better than using PANA. > > IKEv2 is defined and used for creating IPsec SAs. IKE is Internet Key Exchange protocol NOT IPsec Key Exchange protocol. IKEv2 is not just a mean of exchanging keys but its a full package. This package provides mutual authentication, keys and readiness to secure data as needed. The main motivation for this draft is Remote Access VPN scenario. Yeah, it needs to perform > peer authentication, but that's for creating securing the IPsec SA > creation. > There are many other protocols that authenticate the peers for the sake of > securely performing their own dedicated objectives. E.g., Mobile IP > authenticates MN and HA for securely creating binding caches; RFC 3118 > authenticates DHCP client and DHCP server for secure host configuration; > etc. etc. Taking the peer authentication parts of these protocols and use > it > for totally different purposes is not right. > > > I don't see why we couldn't let IKEv2 have a go at displacing PANA in the > marketplace. > > Few folks want to twist IKEv2 into network access authentication protocol > (this proposal). > Few other folks want to twist DHCP into network access authentication > protocol (EAP-over-DHCP proposal). > Few other folks want to twist HTTP into network access authentication > protocol (EAP-over-HTTP proposal). > > They all have the exact same (poor) justification: We need EAP-over-Foo > because we already have Foo. > > The above list is what is already being entertained here and there. The > list > is very likely to grow. > > How can that not be a problem if all were getting standardized (for the > sake > of argument, let's forget about the technical brokenness of the last two > proposals). Every one of them think they were saving by implementing "one", > but in fact all are getting implemented eventually. Each access > authentication specific feature needs to be reproduced on each such > protocol. A multi-mode terminal (host) and NAS need to implement all..... > > > > What's really not desirable is non-interoperability, and that, I believe, > we can achieve by making PANA the required to implement network access > protocol. > > "We" (IETF) do not and cannot make PANA "required to implement" network > access authentication protocol. Other SDOs/platforms make such mandates. > So, > I don't think saying "no" to redundant solutions is a bad thing that that > way. > > If someone is truly hung up on using IKEv2 purely for network access > authentication, why can't they already do so? So what if it creates an > IPsec > SA. Just don't use it. > > > Suppose you want a combination of "peer authentication only" for some > > traffic and "peer authentication + ESP/AH" for other kinds of traffic > > (think of this as differentiated services). Then to use PANA for one > > and IPsec for the other seems silly. > > Is this a real scenario? This is not the scenario Hui brought up. He's > talking about Femto AP connecting to femto access network via WAN; in one > case (a) WAN is already secured (e.g., via physical security) and he does > not need to use IPsec at all; in the other case (b) WAN is open Internet > and > ne needs to use IPsec. In both cases, he needs to authenticate the Femto AP > and he wants to use IKEv2 for that. And I say use PANA instead. > > So, PANA-based solution becomes this: > For case (a): Use PANA for Femto AP authentication. That's all you need. > For case (b): Use PANA for Femto AP authentication, use IKEv2 for setting > up > IPsec SA. > > > > .... > > I'm not disputing doability of this proposal. See, an even worse example is > 3GPP2 using Mobile IPv4 authentication for L3 network access authentication > between the MS (MN) and PDSN (FA). I guess we are lucky that they didn't > come to IETF for tweaking RFC 4004 for that (they could get good number of > support, if we were going with that indication only). This can also made to > work, but IMHO there is much bigger harm than benefit in this case. > > Alper > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > > Of Nicolas Williams > > Sent: Tuesday, December 15, 2009 8:38 PM > > To: Alper Yegin > > Cc: 'Hui Deng'; ipsec@ietf.org; 'Yoav Nir' > > Subject: Re: [IPsec] Proposed work item: Childless IKE SA > > > > On Thu, Dec 10, 2009 at 10:12:54AM +0200, Alper Yegin wrote: > > > > The "Do phase 1 first, and phase 2 as traffic demands it" > > motivation is > > > > from the remote access VPN domain (though may be useful for > > others). > > > > > > > > The "Do only phase 1, because we don't need encryption and MAC, > > just > > > > peer authentication" motivation is from the 3GPP (though it could > > be > > > > useful for others) > > > > > > > > The "Do only phase 1 to discover if we're in or out of the secure > > > > network (then do phase 2 if we're out)" motivation is also mostly a > > > > remote access VPN thing. > > > > > > > > The other motivations were from suggestions by others, and will be > > > > hashed out (or taken out of the document) should this become a WG > > > > document. > > > > > > I'm particularly concerned about reinventing the wheel aspect with > > your > > > second bullet, as I elaborated in response to Hui in my previous > > email. > > > > > > As for the other motivations, I'm not sure the savings are worth the > > effort. > > > Imho.... > > > > Suppose you want a combination of "peer authentication only" for some > > traffic and "peer authentication + ESP/AH" for other kinds of traffic > > (think of this as differentiated services). Then to use PANA for one > > and IPsec for the other seems silly. > > > > I don't see why an applicability statement should not suffice to > > prevent > > the scenario that you dislike (which I think is: IKEv2 displacing PANA > > where IKEv2 should be considered to not be applicable). But see below. > > > > The issue to settle here, as I see it, is: are there any uses of > > childless IKEv2 SAs that justify the work? > > > > Of the various use case scenarios given in the I-D the first is the > > most > > convincing, though the lack of childless IKEv2 SAs hardly seems > > problematic there. The last use case is very interesting, but very > > forward looking. The next to last use case is specific to an EAP > > method, thus not very interesting to this WG (IMO) except as a way to > > keep divergence between base spec and the EAP method to a minimum. The > > other use case scenarios seem to encroach on the applicability of PANA. > > > > Just based on that my support is lukewarm. > > > > Quite aside from that, I question the applicability statement that you > > seem to be making. PANA and IKEv2-with-childless-SAs seem roughly > > equivalent, with IKEv2 being more general. Why should we forbid use of > > the latter for network access control? Certainly having two such > > protocols is not exactly desirable, but it's not clear to me that PANA > > is the protocol that should win. What's really not desirable is non- > > interoperability, and that, I believe, we can achieve by making PANA > > the > > required to implement network access protocol. I don't see why we > > couldn't let IKEv2 have a go at displacing PANA in the marketplace. If > > there is support in the WG for it, so be it. > > > > Nico > > -- > > _______________________________________________ > > 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 > Thanks, Raj --0016e6dab052f84650047af7cb88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alper,


On Fri, Dec 18, 2009 at 5:= 19 AM, Alper Yegin <alper.yegin@yegin.org> wrote:
Hi,

I'm hoping by now it is understood that "childless IKE SA" is= just a
technical detail of what is really on the table. The proposal on the table<= br> is "designing a network access authentication protocol based on IKEv2&= quot;.
That's what this WG and IETF should be discussing.

Having multiple solutions for the very same problem space creates
interoperability problem. =C2=A0If IETF has defined a protocol for a given<= br> problem, and if some other people come along and ask another solution be standardized for the very same problem, IETF needs a justification.
Otherwise, we end up working "against" interoperability, not &quo= t;for".

The only justification I'm hearing is "we don't want to use PA= NA because it
is not implemented in my stack." This is an extremely poor justificati= on.
One can say it for any new protocol, and choose to hack up whatever he/she<= br> has. How can growing PANA out of IKEv2 be any better than using PANA.

IKEv2 is defined and used for creating IPsec SAs.
=C2=A0
IKE is Internet Key Exchange protocol NOT IPsec Key Exchange proto= col.
IKEv2 is not just a mean of=C2=A0exchanging=C2=A0keys but it= s a full package.
This package provides mutual=C2=A0authentication, keys and=C2=A0readin= ess=C2=A0to secure data as needed.
The main motivation for this d= raft is Remote Access VPN scenario.

Yeah, it needs to perform
peer authentication, but that's for creating securing the IPsec SA crea= tion.
There are many other protocols that authenticate the peers for the sake of<= br> securely performing their own dedicated objectives. E.g., Mobile IP
authenticates MN and HA for securely creating binding caches; RFC 3118
authenticates DHCP client and DHCP server for secure host configuration; etc. etc. Taking the peer authentication parts of these protocols and use i= t
for totally different purposes is not right.

> I don't see why we couldn't let IKEv2 have a go at displacing = PANA in the
marketplace.

Few folks want to twist IKEv2 into network access authentication prot= ocol
(this proposal).
Few other folks want to twist DHCP into network access authentication
protocol (EAP-over-DHCP proposal).
Few other folks want to twist HTTP into network access authentication
protocol (EAP-over-HTTP proposal).

They all have the exact same (poor) justification: We need EAP-over-Foo
because we already have Foo.

The above list is what is already being entertained here and there. The lis= t
is very likely to grow.

How can that not be a problem if all were getting standardized (for the sak= e
of argument, let's forget about the technical brokenness of the last tw= o
proposals). Every one of them think they were saving by implementing "= one",
but in fact all are getting implemented eventually. Each access
authentication specific feature needs to be reproduced on each such
protocol. A multi-mode terminal (host) and NAS need to implement all.....


> What's really not desirable is non-interoperability, and that, I b= elieve,
we can achieve by making PANA the required to implement network access
protocol.

"We" (IETF) do not and cannot make PANA "required to i= mplement" network
access authentication protocol. Other SDOs/platforms make such mandates. So= ,
I don't think saying "no" to redundant solutions is a bad thi= ng that that
way.

If someone is truly hung up on using IKEv2 purely for network access
authentication, why can't they already do so? So what if it creates an = IPsec
SA. Just don't use it.

> Suppose you want a combination of "peer authentication only"= for some
> traffic and "peer authentication + ESP/AH" for other kinds o= f traffic
> (think of this as differentiated services). =C2=A0Then to use PANA for= one
> and IPsec for the other seems silly.

Is this a real scenario? This is not the scenario Hui brought up. He&= #39;s
talking about Femto AP connecting to femto access network via WAN; in one case (a) WAN is already secured (e.g., via physical security) and he does not need to use IPsec at all; in the other case (b) WAN is open Internet an= d
ne needs to use IPsec. In both cases, he needs to authenticate the Femto AP=
and he wants to use IKEv2 for that. And I say use PANA instead.

So, PANA-based solution becomes this:
For case (a): Use PANA for Femto AP authentication. That's all you need= .
For case (b): Use PANA for Femto AP authentication, use IKEv2 for setting u= p
IPsec SA.



....

I'm not disputing doability of this proposal. See, an even worse exampl= e is
3GPP2 using Mobile IPv4 authentication for L3 network access authentication=
between the MS (MN) and PDSN (FA). I guess we are lucky that they didn'= t
come to IETF for tweaking RFC 4004 for that (they could get good number of<= br> support, if we were going with that indication only). This can also made to=
work, but IMHO there is much bigger harm than benefit in this case.

Alper


















> -----Original Message-----
> From: ipsec-bounces@ietf.org= [mailto:ipsec-bounces@ietf.o= rg] On Behalf
> Of Nicolas Williams
> Sent: Tuesday, December 15, 2009 8:38 PM
> To: Alper Yegin
> Cc: 'Hui Deng'; ipsec@ietf.org; 'Yoav Nir'
> Subject: Re: [IPsec] Proposed work item: Childless IKE SA
>
> On Thu, Dec 10, 2009 at 10:12:= 54AM +0200, Alper Yegin wrote:
> > > The "Do phase 1 first, and phase 2 as traffic demands i= t"
> motivation is
> > > from the remote access VPN domain (though may be useful for<= br> > others).
> > >
> > > The "Do only phase 1, because we don't need encrypt= ion and MAC,
> just
> > > peer authentication" motivation is from the 3GPP (thoug= h it could
> be
> > > useful for others)
> > >
> > > The "Do only phase 1 to discover if we're in or out= of the secure
> > > network (then do phase 2 if we're out)" motivation = is also mostly a
> > > remote access VPN thing.
> > >
> > > The other motivations were from suggestions by others, and w= ill be
> > > hashed out (or taken out of the document) should this become= a WG
> > > document.
> >
> > I'm particularly concerned about reinventing the wheel aspect= with
> your
> > second bullet, as I elaborated in response to Hui in my previous<= br> > email.
> >
> > As for the other motivations, I'm not sure the savings are wo= rth the
> effort.
> > Imho....
>
> Suppose you want a combination of "peer authentication only"= for some
> traffic and "peer authentication + ESP/AH" for other kinds o= f traffic
> (think of this as differentiated services). =C2=A0Then to use PANA for= one
> and IPsec for the other seems silly.
>
> I don't see why an applicability statement should not suffice to > prevent
> the scenario that you dislike (which I think is: IKEv2 displacing PANA=
> where IKEv2 should be considered to not be applicable). =C2=A0But see = below.
>
> The issue to settle here, as I see it, is: are there any uses of
> childless IKEv2 SAs that justify the work?
>
> Of the various use case scenarios given in the I-D the first is the > most
> convincing, though the lack of childless IKEv2 SAs hardly seems
> problematic there. =C2=A0The last use case is very interesting, but ve= ry
> forward looking. =C2=A0The next to last use case is specific to an EAP=
> method, thus not very interesting to this WG (IMO) except as a way to<= br> > keep divergence between base spec and the EAP method to a minimum. =C2= =A0The
> other use case scenarios seem to encroach on the applicability of PANA= .
>
> Just based on that my support is lukewarm.
>
> Quite aside from that, I question the applicability statement that you=
> seem to be making. =C2=A0PANA and IKEv2-with-childless-SAs seem roughl= y
> equivalent, with IKEv2 being more general. =C2=A0Why should we forbid = use of
> the latter for network access control? =C2=A0Certainly having two such=
> protocols is not exactly desirable, but it's not clear to me that = PANA
> is the protocol that should win. =C2=A0What's really not desirable= is non-
> interoperability, and that, I believe, we can achieve by making PANA > the
> required to implement network access protocol. =C2=A0I don't see w= hy we
> couldn't let IKEv2 have a go at displacing PANA in the marketplace= . =C2=A0If
> there is support in the WG for it, so be it.
>
> Nico
> --
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

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

Thanks,
Raj
--0016e6dab052f84650047af7cb88-- From jari.arkko@piuha.net Fri Dec 18 00:19: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 C4A703A684E; Fri, 18 Dec 2009 00:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 OwFMJwjVtAzy; Fri, 18 Dec 2009 00:19:05 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E835B3A6813; Fri, 18 Dec 2009 00:19:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1C776D4929; Fri, 18 Dec 2009 10:18:50 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xapwXTTWrMsA; Fri, 18 Dec 2009 10:18:49 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9AD40D491C; Fri, 18 Dec 2009 10:18:49 +0200 (EET) Message-ID: <4B2B3AE9.1010406@piuha.net> Date: Fri, 18 Dec 2009 10:18:49 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Russ Housley References: <20091217023458.GA23757@mactavish> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> <19242.7719.715250.335841@fireball.kivinen.iki.fi> In-Reply-To: <19242.7719.715250.335841@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , "iesg@ietf.org" Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 18 Dec 2009 08:19:05 -0000 FWIW, I would personally rather see WESP do exactly what it is supposed to do, reveal the packet, and not handle other kinds of functionality (encrypted packets etc) Jari From kivinen@iki.fi Fri Dec 18 02:30: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 41A063A6862; Fri, 18 Dec 2009 02:30:27 -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 xI3zWGcU8wn0; Fri, 18 Dec 2009 02:30:26 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 078C93A69A0; Fri, 18 Dec 2009 02:30:25 -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 nBIAU52U011856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 12:30:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBIAU2kd018401; Fri, 18 Dec 2009 12:30:02 +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: <19243.22954.117354.98378@fireball.kivinen.iki.fi> Date: Fri, 18 Dec 2009 12:30:02 +0200 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F139@il-ex01.ad.checkpoint.com> <19242.8721.338478.28735@fireball.kivinen.iki.fi> <45c8c21a0912170441m53e72109id422607a45187763@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 13 min Cc: IPsecme WG , ipsec-bounces@ietf.org Subject: Re: [IPsec] Issue #130: Do we need to bump the minor version number? 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, 18 Dec 2009 10:30:27 -0000 David Wierbowski writes: > I think it is reasonable to expect that an IKEv2 bis implementation would > use an IF statement to control sending the new Notify types. No they should just use new notifies, as all old complient implementations will work with those new error messages also. There is no reason to send old error notifications. > If the minor number was changed an implementation could check the > minor version and send the new notify types when the minor version > was 1 and send the notify types recommended in RFC 4718 if the minor > number was 0. There is no point of supporting old RFC4718 error notifications after you implement IKEv2bis as new error notifications are backward compatible with old ones. Also RFC4718 used text like "thus failing the request with something non-fatal such as NO_PROPOSAL_CHOSEN seems like a reasonable approach." which clearly indicates that other error notifications are also possible, thus whether other end sends NO_PROPOSAL_CHOSEN or CHILD_SA_NOT_FOUND error notification, as recipient will process them both in a same way, and expect that exchange failed. > That is what my implementation plans to do if the minor version > number is bumped. I do not think I will ever implement RFC4718 error notifications (we have not implemented it yet, and now when we have IKEv2bis almost ready, I do not think we ever will), thus for me it does not really matter, but I think it would be much easier to just change those error notifications you already have in the code to use CHILD_SA_NOT_FOUND and TEMPORARY_FAILURE instead of NO_ADDITIONAL_SAS and NO_PROPOSAL_CHOSEN without adding any extra logic based on the minor version number. > I'm not sure I agree with Tero that an implementation getting an unknown > TEMPORARY_FAILURE notify would always take the same action that it would if > it received NO_PROPOSAL_CHOSEN as suggested by RFC 4718. Then it is not complient to RFC4306, as RFC4306 clearly says that if you get uknown error notification then you "MUST assume that the corresponding request has failed entirely". RFC4718 does not (and cannot) modify the meaning of NO_PROPOSAL_CHOSEN error notification it just gives you examples what kind error notifications could be used in which case, but I do not think it gives you instructions what to do when you receive such error notifications. This was one of the things needed to be added to the IKEv2bis, and that was the reason we needed to have separate error notifications as we wanted to be sure that it is easy to decide what to do when you get error notification back (i.e. in addition to assuming that exchange failed). -- kivinen@iki.fi From kivinen@iki.fi Fri Dec 18 02:44: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 BD0043A683D; Fri, 18 Dec 2009 02:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 RMR6UeLjSI+O; Fri, 18 Dec 2009 02:44:22 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 8DBC53A6782; Fri, 18 Dec 2009 02:44:21 -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 nBIAi2gC017235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 12:44:02 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBIAi0Fc006695; Fri, 18 Dec 2009 12:44: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: <19243.23792.890704.764300@fireball.kivinen.iki.fi> Date: Fri, 18 Dec 2009 12:44:00 +0200 From: Tero Kivinen To: "Grewal, Ken" In-Reply-To: References: <20091217023458.GA23757@mactavish> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> <19242.7719.715250.335841@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 12 min Cc: "ipsec@ietf.org" , Russ Housley , "iesg@ietf.org" , Dan McDonald Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 18 Dec 2009 10:44:22 -0000 Grewal, Ken writes: > >It does make more complexity for the middle boxes as they need to cope > >with both encrypted WESP and ESP-NULL WESP, thus they still cannot use > >just the WESP protocol number to indicate this packet is clear text. > >Now they also need to check the bit in the header, and if we add more > >extensions to WESP, they need to start doing even more processing etc, > >and quite soon WESP is more complex than what AH is now. > > [Ken] I do not think that checking one more bit adds too much > additional complexity, compared with extracting the offsets and > protocol Information from the header. It does provide compatibility > for both encrypted and unencrypted traffic. But without adding even more extensions there is no reason to ever use encrypted WESP instead of ESP. WESP just adds extra header without any benefit compared to normal encrypted ESP. > If we add more extensions to WESP, then those need to be evaluated > based on the cost / complexity Vs. benefit and that will be a > separate debate. The question is how many extensions we have which are such that they need to be understood by the middle boxes. Extensions for the end hosts can be done using standard ESP. > [Ken] I think this is the whole point. All the work on ESP/IPsec > this far has been considering a two party interaction (outside the > multicast context!). Yes, I and I think IPsec will stay that way... For example I do not think our OEM toolkit will include WESP as I do not really see any need for it. > Now there is a third party - the middle box, which would like to > gain some additional information in order to provide valuable > network services. The end boxes already know what is being > negotiated, so just making changes to IKE to add additional > capability is insufficient in certain scenarios (while perfectly > sufficient in others). We need to provide additional information in > the data path, hence the need for WESP. I am not sure WESP is right solution for that problem. It would be much better to provide authenticated protocol where the middlebox could connect to the end node and query the required parameters from the end node and the end node can give that information out without needing to waste extra bytes on each packet. Also that way end node could control who gets the information and who does not. There is no need that additional information needs to be on the data path, and in clear text, it could also be communicated using some other out of band method instead of WESP. Depending on what kind of additional information needs to be transmitted, the solutions can be quite different. -- kivinen@iki.fi From kivinen@iki.fi Fri Dec 18 03:31: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 0E8D228C0D8 for ; Fri, 18 Dec 2009 03:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 z58P1Mg7K9JX for ; Fri, 18 Dec 2009 03:31:17 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id DE23628C0D6 for ; Fri, 18 Dec 2009 03:31:16 -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 nBIBUvha013521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2009 13:30:57 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBIBUuJg012368; Fri, 18 Dec 2009 13:30:56 +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: <19243.26608.694370.818297@fireball.kivinen.iki.fi> Date: Fri, 18 Dec 2009 13:30:56 +0200 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133FB36A4EC57A@il-ex01.ad.checkpoint.com> <19240.48239.23842.571746@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: IPsecme WG Subject: Re: [IPsec] Issue #128: Can implementations not reply fully to Deletes? 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, 18 Dec 2009 11:31:18 -0000 David Wierbowski writes: > I'm not sure I'm going to buy that garage door opener if I have to wait for > dead peer detection before I can open or close it again :>). You don't, if the device is already sleeping, and you press the button again it wakes up, creates NEW IKE SA and the IPsec SA and sends the packet forward. The single Child SA is only for the opener itself, the server it is connected is assumed to be bigger device which also is able to support multiple Child SAs simultaneously and which can do complex things like DPD etc (note that the minimal implementation can already reply to DPD as that is just empty INFORMATIONAL exchange). The garage door opener can also always put up the INITIAL_CONTACT notification so if the server has not yet deleted the IKE SA by when it connectes again it will delete it based on that notification. -- kivinen@iki.fi From kivinen@iki.fi Fri Dec 18 05:08: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 17E8A3A6A25 for ; Fri, 18 Dec 2009 05:08:17 -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 x85rbGSCw9lG for ; Fri, 18 Dec 2009 05:08:16 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 80EC33A6955 for ; Fri, 18 Dec 2009 05:08:14 -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 nBID7t76020467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Dec 2009 15:07:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBID7tk9018489; Fri, 18 Dec 2009 15:07:55 +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: <19243.32427.247190.77844@fireball.kivinen.iki.fi> Date: Fri, 18 Dec 2009 15:07:55 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 26 min X-Total-Time: 66 min Subject: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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: Fri, 18 Dec 2009 13:08:17 -0000 I got just request to review modifications to IKEv2 IANA because of the draft-solinas-rfc4753bis-01.txt. We had this discussion a while back on the IPsec list where we noted that having errata which makes non-interoperable change to the RFC is not really ok, and we requested the authors to submit new document. Errata: http://www.rfc-editor.org/errata_search.php?rfc=4753&rec_status=15&presentation=records Email thread: http://www.ietf.org/mail-archive/web/ipsec/current/msg04529.html At that point Paul summarized things very nicely: My view is that the errata is technically wrong and should be withdrawn because it changes something that is disagreed to by test vectors in the document itself. If the authors of RFC 4753 want the format to be just the x coordinate, they should prepare a revision to RFC 4753 that obsoletes it and has correct text and test vectors. Now when this came to me when IANA asked me to do Expert review to the IANA allocations, I noticed that it would be very bad if we reused the old numbers 19, 20, 21 as that would mean nobody knows which version of the RFC (old RFC without errata, or RFC4753 with errata == new RFC) is really used. As the Diffie-Hellman groups are negotiated and the registry is 16 bits, we do not need to try to save the numbers, I think it would be bad idea to reuse the existing values with different meaning. Because of this I answered that the new groups with new meanings would need to get new numbers. When I started investigating problem bit more I found out that RFC5114 which defines 2 new ECP groups (in addition of repeating the 3 ECP groups from RFC4753) says: ---------------------------------------------------------------------- 3.2. IKE Use of MODP Diffie-Hellman groups with IKEv2 is defined in [RFC4306], and the use of MODP groups with IKEv1 is defined in [RFC2409]. However, in the case of ECP Diffie-Hellman groups, the format of key exchange payloads and the derivation of a shared secret has thus far been specified on a group-by-group basis. For the ECP Diffie-Hellman groups defined in this document, the key exchange payload format and shared key derivation procedure specified in [RFC4753] MUST be used (with both IKEv2 and IKEv1). ---------------------------------------------------------------------- Now if we obsolete RFC4753, does that mean that this reference will also change, so which format is used for these groups 25 and 26 define in RFC5114? Do we need a new numbers for those groups also so it will be clear which version they use. Then there is also the RFC4869 which defines UI suites. That refers Diffie-Hellman groups as "256-bit random ECP group [RFC4753]". Which format of group those uses. When we now change RFC4753 does that mean that old implementations using RFC4869 UI suites using original RFC4753 groups is not compatible with newer RFC4869 version or what? I think the best way forward is to allocate new numbers for all RFC4753 derived groups (19, 20, 21, 25, 26) and create new UI suites using those new group numbers. This will create one time update where everybody needs to change their code by changing number 19 to n and 20 to n+1 and so on, and at the same time verify that the secret they use is only the x-coordinate. This change is small and can be done very quickly, but after that we do not need to think whether we can interoperate with someone using ECP group n, as we know it must be using new secret format. If someone uses old groups 19, 20, 21, 25, or 26 then you can make your guess whether they also implemented errata or not, and act based on that. Good thing is that as Diffie-Hellman groups are negotiated in IKEv2 it is easy to offer both 19 and new group n if backward compatibility with old versions is needed (provided you also know whether the group 19 on the other end uses errata or not). -- kivinen@iki.fi From smoonen@us.ibm.com Fri Dec 18 05:38: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 AF3833A68B1; Fri, 18 Dec 2009 05:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.874 X-Spam-Level: X-Spam-Status: No, score=-3.874 tagged_above=-999 required=5 tests=[AWL=-1.276, 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 a3u5OzjSs8Gk; Fri, 18 Dec 2009 05:38:06 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id DCA293A6783; Fri, 18 Dec 2009 05:38:05 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e37.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nBIDaQgp005478; Fri, 18 Dec 2009 06:36:26 -0700 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBIDbQnA153652; Fri, 18 Dec 2009 06:37:27 -0700 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 nBIDdIg9007920; Fri, 18 Dec 2009 06:39:19 -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 nBIDdIRR007916; Fri, 18 Dec 2009 06:39:18 -0700 In-Reply-To: <19243.32427.247190.77844@fireball.kivinen.iki.fi> References: <19243.32427.247190.77844@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: 1FD3CDFB:F4E96F12-85257690:004924DB; 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 12/18/2009 08:36:52 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 12/18/2009 08:36:52 AM, Serialize complete at 12/18/2009 08:36:52 AM, S/MIME Sign failed at 12/18/2009 08:36:52 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 12/18/2009 06:37:25, Serialize complete at 12/18/2009 06:37:25 Message-ID: Date: Fri, 18 Dec 2009 08:37:25 -0500 Content-Type: multipart/alternative; boundary="=_alternative 004AC97E85257690_=" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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: Fri, 18 Dec 2009 13:38:07 -0000 This is a multipart message in MIME format. --=_alternative 004AC97E85257690_= Content-Type: text/plain; charset="US-ASCII" Tero, what you propose seems the right way to go in principle, but I suspect we are solving a problem that doesn't exist. Is there any crypto library or device that exposes the y coordinate for use in the ECDH secret? It seems pretty well established that the x coordinate serves as the ECDH secret. Moreover, since the y coordinate provides only one more bit of independent information, it's actually misleading to use it. I seriously doubt there is any implementation that does not implement the intent of the erratum, if only because there are immense practical barriers to implementing the RFC as written. Given that, I think the practical result of what you propose will actually be more confusion and a longer period of time before all implementations (as well as all standards/profiles) are able to re-stabilize to the new ECDH landscape. The practical cost of making this change is greater than the practical benefit it buys. On the other hand, if there is such an implementation, then we probably do need to do something like what you propose. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Tero Kivinen To: ipsec@ietf.org Date: 12/18/2009 08:08 AM Subject: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01) I got just request to review modifications to IKEv2 IANA because of the draft-solinas-rfc4753bis-01.txt. We had this discussion a while back on the IPsec list where we noted that having errata which makes non-interoperable change to the RFC is not really ok, and we requested the authors to submit new document. Errata: http://www.rfc-editor.org/errata_search.php?rfc=4753&rec_status=15&presentation=records Email thread: http://www.ietf.org/mail-archive/web/ipsec/current/msg04529.html At that point Paul summarized things very nicely: My view is that the errata is technically wrong and should be withdrawn because it changes something that is disagreed to by test vectors in the document itself. If the authors of RFC 4753 want the format to be just the x coordinate, they should prepare a revision to RFC 4753 that obsoletes it and has correct text and test vectors. Now when this came to me when IANA asked me to do Expert review to the IANA allocations, I noticed that it would be very bad if we reused the old numbers 19, 20, 21 as that would mean nobody knows which version of the RFC (old RFC without errata, or RFC4753 with errata == new RFC) is really used. As the Diffie-Hellman groups are negotiated and the registry is 16 bits, we do not need to try to save the numbers, I think it would be bad idea to reuse the existing values with different meaning. Because of this I answered that the new groups with new meanings would need to get new numbers. When I started investigating problem bit more I found out that RFC5114 which defines 2 new ECP groups (in addition of repeating the 3 ECP groups from RFC4753) says: ---------------------------------------------------------------------- 3.2. IKE Use of MODP Diffie-Hellman groups with IKEv2 is defined in [RFC4306], and the use of MODP groups with IKEv1 is defined in [RFC2409]. However, in the case of ECP Diffie-Hellman groups, the format of key exchange payloads and the derivation of a shared secret has thus far been specified on a group-by-group basis. For the ECP Diffie-Hellman groups defined in this document, the key exchange payload format and shared key derivation procedure specified in [RFC4753] MUST be used (with both IKEv2 and IKEv1). ---------------------------------------------------------------------- Now if we obsolete RFC4753, does that mean that this reference will also change, so which format is used for these groups 25 and 26 define in RFC5114? Do we need a new numbers for those groups also so it will be clear which version they use. Then there is also the RFC4869 which defines UI suites. That refers Diffie-Hellman groups as "256-bit random ECP group [RFC4753]". Which format of group those uses. When we now change RFC4753 does that mean that old implementations using RFC4869 UI suites using original RFC4753 groups is not compatible with newer RFC4869 version or what? I think the best way forward is to allocate new numbers for all RFC4753 derived groups (19, 20, 21, 25, 26) and create new UI suites using those new group numbers. This will create one time update where everybody needs to change their code by changing number 19 to n and 20 to n+1 and so on, and at the same time verify that the secret they use is only the x-coordinate. This change is small and can be done very quickly, but after that we do not need to think whether we can interoperate with someone using ECP group n, as we know it must be using new secret format. If someone uses old groups 19, 20, 21, 25, or 26 then you can make your guess whether they also implemented errata or not, and act based on that. Good thing is that as Diffie-Hellman groups are negotiated in IKEv2 it is easy to offer both 19 and new group n if backward compatibility with old versions is needed (provided you also know whether the group 19 on the other end uses errata or not). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 004AC97E85257690_= Content-Type: text/html; charset="US-ASCII"
Tero, what you propose seems the right way to go in principle, but I suspect we are solving a problem that doesn't exist.  Is there any crypto library or device that exposes the y coordinate for use in the ECDH secret?  It seems pretty well established that the x coordinate serves as the ECDH secret.  Moreover, since the y coordinate provides only one more bit of independent information, it's actually misleading to use it.

I seriously doubt there is any implementation that does not implement the intent of the erratum, if only because there are immense practical barriers to implementing the RFC as written.  Given that, I think the practical result of what you propose will actually be more confusion and a longer period of time before all implementations (as well as all standards/profiles) are able to re-stabilize to the new ECDH landscape.  The practical cost of making this change is greater than the practical benefit it buys.

On the other hand, if there is such an implementation, then we probably do need to do something like what you propose.


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: ipsec@ietf.org
Date: 12/18/2009 08:08 AM
Subject: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)




I got just request to review modifications to IKEv2 IANA because of
the draft-solinas-rfc4753bis-01.txt.

We had this discussion a while back on the IPsec list where we noted
that having errata which makes non-interoperable change to the RFC is
not really ok, and we requested the authors to submit new document.

Errata: http://www.rfc-editor.org/errata_search.php?rfc=4753&rec_status=15&presentation=records

Email thread: http://www.ietf.org/mail-archive/web/ipsec/current/msg04529.html

At that point Paul summarized things very nicely:

  My view is that the errata is technically wrong and should be
  withdrawn because it changes something that is disagreed to by test
  vectors in the document itself. If the authors of RFC 4753 want the
  format to be just the x coordinate, they should prepare a revision
  to RFC 4753 that obsoletes it and has correct text and test
  vectors.

Now when this came to me when IANA asked me to do Expert review to the
IANA allocations, I noticed that it would be very bad if we reused the
old numbers 19, 20, 21 as that would mean nobody knows which version
of the RFC (old RFC without errata, or RFC4753 with errata == new RFC)
is really used.

As the Diffie-Hellman groups are negotiated and the registry is 16
bits, we do not need to try to save the numbers, I think it would be
bad idea to reuse the existing values with different meaning. Because
of this I answered that the new groups with new meanings would need to
get new numbers.

When I started investigating problem bit more I found out that RFC5114
which defines 2 new ECP groups (in addition of repeating the 3 ECP
groups from RFC4753) says:
----------------------------------------------------------------------
3.2.  IKE

  Use of MODP Diffie-Hellman groups with IKEv2 is defined in [RFC4306],
  and the use of MODP groups with IKEv1 is defined in [RFC2409].
  However, in the case of ECP Diffie-Hellman groups, the format of key
  exchange payloads and the derivation of a shared secret has thus far
  been specified on a group-by-group basis.  For the ECP Diffie-Hellman
  groups defined in this document, the key exchange payload format and
  shared key derivation procedure specified in [RFC4753] MUST be used
  (with both IKEv2 and IKEv1).
----------------------------------------------------------------------

Now if we obsolete RFC4753, does that mean that this reference will
also change, so which format is used for these groups 25 and 26 define
in RFC5114?

Do we need a new numbers for those groups also so it will be clear
which version they use.

Then there is also the RFC4869 which defines UI suites. That refers
Diffie-Hellman groups as "256-bit random ECP group [RFC4753]". Which
format of group those uses. When we now change RFC4753 does that mean
that old implementations using RFC4869 UI suites using original
RFC4753 groups is not compatible with newer RFC4869 version or what?

I think the best way forward is to allocate new numbers for all
RFC4753 derived groups (19, 20, 21, 25, 26) and create new UI suites
using those new group numbers.

This will create one time update where everybody needs to change their
code by changing number 19 to n and 20 to n+1 and so on, and at the
same time verify that the secret they use is only the x-coordinate.
This change is small and can be done very quickly, but after that we
do not need to think whether we can interoperate with someone using
ECP group n, as we know it must be using new secret format.

If someone uses old groups 19, 20, 21, 25, or 26 then you can make
your guess whether they also implemented errata or not, and act based
on that. Good thing is that as Diffie-Hellman groups are negotiated in
IKEv2 it is easy to offer both 19 and new group n if backward
compatibility with old versions is needed (provided you also know
whether the group 19 on the other end uses errata or not).
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 004AC97E85257690_=-- From denghui02@gmail.com Fri Dec 18 08:12: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 41CCB28C101 for ; Fri, 18 Dec 2009 08:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_00=-2.599, SARE_FWDLOOK=1.666] 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 67pCXnTT2qct for ; Fri, 18 Dec 2009 08:12:01 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 990D628C0E4 for ; Fri, 18 Dec 2009 08:12:01 -0800 (PST) Received: by pzk6 with SMTP id 6so2300236pzk.29 for ; Fri, 18 Dec 2009 08:11:43 -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=hodNI3wpknZdwDHn2eE6MoVW/lR9Pyh0MD+pAXzeAjA=; b=WUch6V58IINNT8NtUCWsy5d9mRJDBRR4aGXMUye4dC1Sd2xODQ3W8f5W+fy6EAcG3d W5zhvyR0yd97FclcotYA3sUjQ4SqdKH86jFNnaFZgyLfthFVe4I/QHBVb3vrd5XLq8IP L0PX4MpHcKP2TgXkiG/NdrcewCf7qmKPXH0hA= 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=XfNkokduMBiWxAicaFiU46G8NPGwnZXOsnN6RHKye6u2KUZ4uN8FwR5bmuPWu3mDe6 etwbK354UKTroCPRwt8odugfR6G8mjSBrMB/sa0ue9ab0AONxx5vI1PdF2J2hn4f7wHK /+VVSzpWMxLLGfSJPFQg8HJ4Lib9gfh30tbi0= MIME-Version: 1.0 Received: by 10.141.131.2 with SMTP id i2mr2804512rvn.298.1261152703682; Fri, 18 Dec 2009 08:11:43 -0800 (PST) In-Reply-To: <62778081976350302@unknownmsgid> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <1d38a3350912090742q1976ffefo85ef5e0e5627ec0b@mail.gmail.com> <023f01ca7908$480951b0$d81bf510$%yegin@yegin.org> <3824040C-7D40-4B46-B430-AE87D6729A19@checkpoint.com> <02c401ca7970$974303d0$c5c90b70$%yegin@yegin.org> <20091215183742.GV1516@Sun.COM> <62778081976350302@unknownmsgid> Date: Sat, 19 Dec 2009 00:11:43 +0800 Message-ID: <1d38a3350912180811v36ae44edra455c607b5bda4ed@mail.gmail.com> From: Hui Deng To: Alper Yegin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, Yoav Nir , Nicolas Williams Subject: Re: [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: Fri, 18 Dec 2009 16:12:03 -0000 what if the request is during the IKE authenticaiton, network side need to signal the fermto about whether to support IPsec or no= t? if not, will fall back to usual IPsec tunnel. -Hui 2009/12/18 Alper Yegin : > Hi, > > I'm hoping by now it is understood that "childless IKE SA" is just a > technical detail of what is really on the table. The proposal on the tabl= e > is "designing a network access authentication protocol based on IKEv2". > That's what this WG and IETF should be discussing. > > Having multiple solutions for the very same problem space creates > interoperability problem. =A0If IETF has defined a protocol for a given > problem, and if some other people come along and ask another solution be > standardized for the very same problem, IETF needs a justification. > Otherwise, we end up working "against" interoperability, not "for". > > The only justification I'm hearing is "we don't want to use PANA because = it > is not implemented in my stack." This is an extremely poor justification. > One can say it for any new protocol, and choose to hack up whatever he/sh= e > has. How can growing PANA out of IKEv2 be any better than using PANA. > > IKEv2 is defined and used for creating IPsec SAs. Yeah, it needs to perfo= rm > peer authentication, but that's for creating securing the IPsec SA creati= on. > There are many other protocols that authenticate the peers for the sake o= f > securely performing their own dedicated objectives. E.g., Mobile IP > authenticates MN and HA for securely creating binding caches; RFC 3118 > authenticates DHCP client and DHCP server for secure host configuration; > etc. etc. Taking the peer authentication parts of these protocols and use= it > for totally different purposes is not right. > >> I don't see why we couldn't let IKEv2 have a go at displacing PANA in th= e > marketplace. > > Few folks want to twist IKEv2 into network access authentication protocol > (this proposal). > Few other folks want to twist DHCP into network access authentication > protocol (EAP-over-DHCP proposal). > Few other folks want to twist HTTP into network access authentication > protocol (EAP-over-HTTP proposal). > > They all have the exact same (poor) justification: We need EAP-over-Foo > because we already have Foo. > > The above list is what is already being entertained here and there. The l= ist > is very likely to grow. > > How can that not be a problem if all were getting standardized (for the s= ake > of argument, let's forget about the technical brokenness of the last two > proposals). Every one of them think they were saving by implementing "one= ", > but in fact all are getting implemented eventually. Each access > authentication specific feature needs to be reproduced on each such > protocol. A multi-mode terminal (host) and NAS need to implement all..... > > >> What's really not desirable is non-interoperability, and that, I believe= , > we can achieve by making PANA the required to implement network access > protocol. > > "We" (IETF) do not and cannot make PANA "required to implement" network > access authentication protocol. Other SDOs/platforms make such mandates. = So, > I don't think saying "no" to redundant solutions is a bad thing that that > way. > > If someone is truly hung up on using IKEv2 purely for network access > authentication, why can't they already do so? So what if it creates an IP= sec > SA. Just don't use it. > >> Suppose you want a combination of "peer authentication only" for some >> traffic and "peer authentication + ESP/AH" for other kinds of traffic >> (think of this as differentiated services). =A0Then to use PANA for one >> and IPsec for the other seems silly. > > Is this a real scenario? This is not the scenario Hui brought up. He's > talking about Femto AP connecting to femto access network via WAN; in one > case (a) WAN is already secured (e.g., via physical security) and he does > not need to use IPsec at all; in the other case (b) WAN is open Internet = and > ne needs to use IPsec. In both cases, he needs to authenticate the Femto = AP > and he wants to use IKEv2 for that. And I say use PANA instead. > > So, PANA-based solution becomes this: > For case (a): Use PANA for Femto AP authentication. That's all you need. > For case (b): Use PANA for Femto AP authentication, use IKEv2 for setting= up > IPsec SA. > > > > .... > > I'm not disputing doability of this proposal. See, an even worse example = is > 3GPP2 using Mobile IPv4 authentication for L3 network access authenticati= on > between the MS (MN) and PDSN (FA). I guess we are lucky that they didn't > come to IETF for tweaking RFC 4004 for that (they could get good number o= f > support, if we were going with that indication only). This can also made = to > work, but IMHO there is much bigger harm than benefit in this case. > > Alper > > > > > > > > > > > > > > > > > > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Nicolas Williams >> Sent: Tuesday, December 15, 2009 8:38 PM >> To: Alper Yegin >> Cc: 'Hui Deng'; ipsec@ietf.org; 'Yoav Nir' >> Subject: Re: [IPsec] Proposed work item: Childless IKE SA >> >> On Thu, Dec 10, 2009 at 10:12:54AM +0200, Alper Yegin wrote: >> > > The "Do phase 1 first, and phase 2 as traffic demands it" >> motivation is >> > > from the remote access VPN domain (though may be useful for >> others). >> > > >> > > The "Do only phase 1, because we don't need encryption and MAC, >> just >> > > peer authentication" motivation is from the 3GPP (though it could >> be >> > > useful for others) >> > > >> > > The "Do only phase 1 to discover if we're in or out of the secure >> > > network (then do phase 2 if we're out)" motivation is also mostly a >> > > remote access VPN thing. >> > > >> > > The other motivations were from suggestions by others, and will be >> > > hashed out (or taken out of the document) should this become a WG >> > > document. >> > >> > I'm particularly concerned about reinventing the wheel aspect with >> your >> > second bullet, as I elaborated in response to Hui in my previous >> email. >> > >> > As for the other motivations, I'm not sure the savings are worth the >> effort. >> > Imho.... >> >> Suppose you want a combination of "peer authentication only" for some >> traffic and "peer authentication + ESP/AH" for other kinds of traffic >> (think of this as differentiated services). =A0Then to use PANA for one >> and IPsec for the other seems silly. >> >> I don't see why an applicability statement should not suffice to >> prevent >> the scenario that you dislike (which I think is: IKEv2 displacing PANA >> where IKEv2 should be considered to not be applicable). =A0But see below= . >> >> The issue to settle here, as I see it, is: are there any uses of >> childless IKEv2 SAs that justify the work? >> >> Of the various use case scenarios given in the I-D the first is the >> most >> convincing, though the lack of childless IKEv2 SAs hardly seems >> problematic there. =A0The last use case is very interesting, but very >> forward looking. =A0The next to last use case is specific to an EAP >> method, thus not very interesting to this WG (IMO) except as a way to >> keep divergence between base spec and the EAP method to a minimum. =A0Th= e >> other use case scenarios seem to encroach on the applicability of PANA. >> >> Just based on that my support is lukewarm. >> >> Quite aside from that, I question the applicability statement that you >> seem to be making. =A0PANA and IKEv2-with-childless-SAs seem roughly >> equivalent, with IKEv2 being more general. =A0Why should we forbid use o= f >> the latter for network access control? =A0Certainly having two such >> protocols is not exactly desirable, but it's not clear to me that PANA >> is the protocol that should win. =A0What's really not desirable is non- >> interoperability, and that, I believe, we can achieve by making PANA >> the >> required to implement network access protocol. =A0I don't see why we >> couldn't let IKEv2 have a go at displacing PANA in the marketplace. =A0I= f >> there is support in the WG for it, so be it. >> >> Nico >> -- >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From dharkins@lounge.org Fri Dec 18 11:01: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 6033D3A69A1; Fri, 18 Dec 2009 11:01:26 -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 Fur1yfgmN2eJ; Fri, 18 Dec 2009 11:01:24 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 9C9763A6890; Fri, 18 Dec 2009 11:01:24 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C840D102240AE; Fri, 18 Dec 2009 11:01:09 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 18 Dec 2009 11:01:09 -0800 (PST) Message-ID: <72a888732545c5066f493228c416d286.squirrel@www.trepanning.net> In-Reply-To: References: <19243.32427.247190.77844@fireball.kivinen.iki.fi> Date: Fri, 18 Dec 2009 11:01:09 -0800 (PST) From: "Dan Harkins" To: "Scott C Moonen" 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, ipsec-bounces@ietf.org, Tero Kivinen Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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: Fri, 18 Dec 2009 19:01:26 -0000 Hi Scott, I agree. The errata is not technically wrong. That's the way ECDH is defined in ANSI X9.63, and SEC1, and FIPS 800-56A and that's the way every crypto library that I'm aware of produces the shared secret. I don't think this is problem has manifested itself in implementation non-interoperability, it's just document non-interoperability. I think it would be better to just obsolete RFC 4753 and update RFC 5114 (to not refer to RFC 4753 and have _correct_ test vectors producing Z = x_Z as the result of the ECDH), and update RFC 4869 to refer to the updated RFC 5114. Then the IANA registry should indicate that the updated RFC 5114 defines these groups. The solution of allocating new numbers still doesn't really solve the problem because if you receive an KE payload from group 19, 20, or 21 "you can make your guess whether they also implemented errata or not, and act based on that" and that sounds like a recipe for future non-interoperability. The IANA registry for these groups is used by more than just IKE(v2) and it would be nice if it was coherent and did not make assumption like that. regards, Dan. On Fri, December 18, 2009 5:37 am, Scott C Moonen wrote: > Tero, what you propose seems the right way to go in principle, but I > suspect we are solving a problem that doesn't exist. Is there any crypto > library or device that exposes the y coordinate for use in the ECDH > secret? It seems pretty well established that the x coordinate serves as > the ECDH secret. Moreover, since the y coordinate provides only one more > bit of independent information, it's actually misleading to use it. > > I seriously doubt there is any implementation that does not implement the > intent of the erratum, if only because there are immense practical > barriers to implementing the RFC as written. Given that, I think the > practical result of what you propose will actually be more confusion and a > longer period of time before all implementations (as well as all > standards/profiles) are able to re-stabilize to the new ECDH landscape. > The practical cost of making this change is greater than the practical > benefit it buys. > > On the other hand, if there is such an implementation, then we probably do > need to do something like what you propose. > > > Scott Moonen (smoonen@us.ibm.com) > z/OS Communications Server TCP/IP Development > http://www.linkedin.com/in/smoonen > > > > From: > Tero Kivinen > To: > ipsec@ietf.org > Date: > 12/18/2009 08:08 AM > Subject: > [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, > RFC4869, and draft-solinas-rfc4753bis-01) > > > > I got just request to review modifications to IKEv2 IANA because of > the draft-solinas-rfc4753bis-01.txt. > > We had this discussion a while back on the IPsec list where we noted > that having errata which makes non-interoperable change to the RFC is > not really ok, and we requested the authors to submit new document. > > Errata: > http://www.rfc-editor.org/errata_search.php?rfc=4753&rec_status=15&presentation=records > > > Email thread: > http://www.ietf.org/mail-archive/web/ipsec/current/msg04529.html > > At that point Paul summarized things very nicely: > > My view is that the errata is technically wrong and should be > withdrawn because it changes something that is disagreed to by test > vectors in the document itself. If the authors of RFC 4753 want the > format to be just the x coordinate, they should prepare a revision > to RFC 4753 that obsoletes it and has correct text and test > vectors. > > Now when this came to me when IANA asked me to do Expert review to the > IANA allocations, I noticed that it would be very bad if we reused the > old numbers 19, 20, 21 as that would mean nobody knows which version > of the RFC (old RFC without errata, or RFC4753 with errata == new RFC) > is really used. > > As the Diffie-Hellman groups are negotiated and the registry is 16 > bits, we do not need to try to save the numbers, I think it would be > bad idea to reuse the existing values with different meaning. Because > of this I answered that the new groups with new meanings would need to > get new numbers. > > When I started investigating problem bit more I found out that RFC5114 > which defines 2 new ECP groups (in addition of repeating the 3 ECP > groups from RFC4753) says: > ---------------------------------------------------------------------- > 3.2. IKE > > Use of MODP Diffie-Hellman groups with IKEv2 is defined in [RFC4306], > and the use of MODP groups with IKEv1 is defined in [RFC2409]. > However, in the case of ECP Diffie-Hellman groups, the format of key > exchange payloads and the derivation of a shared secret has thus far > been specified on a group-by-group basis. For the ECP Diffie-Hellman > groups defined in this document, the key exchange payload format and > shared key derivation procedure specified in [RFC4753] MUST be used > (with both IKEv2 and IKEv1). > ---------------------------------------------------------------------- > > Now if we obsolete RFC4753, does that mean that this reference will > also change, so which format is used for these groups 25 and 26 define > in RFC5114? > > Do we need a new numbers for those groups also so it will be clear > which version they use. > > Then there is also the RFC4869 which defines UI suites. That refers > Diffie-Hellman groups as "256-bit random ECP group [RFC4753]". Which > format of group those uses. When we now change RFC4753 does that mean > that old implementations using RFC4869 UI suites using original > RFC4753 groups is not compatible with newer RFC4869 version or what? > > I think the best way forward is to allocate new numbers for all > RFC4753 derived groups (19, 20, 21, 25, 26) and create new UI suites > using those new group numbers. > > This will create one time update where everybody needs to change their > code by changing number 19 to n and 20 to n+1 and so on, and at the > same time verify that the secret they use is only the x-coordinate. > This change is small and can be done very quickly, but after that we > do not need to think whether we can interoperate with someone using > ECP group n, as we know it must be using new secret format. > > If someone uses old groups 19, 20, 21, 25, or 26 then you can make > your guess whether they also implemented errata or not, and act based > on that. Good thing is that as Diffie-Hellman groups are negotiated in > IKEv2 it is easy to offer both 19 and new group n if backward > compatibility with old versions is needed (provided you also know > whether the group 19 on the other end uses errata or not). > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From housley@vigilsec.com Sat Dec 19 09:50: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 891A63A69DD; Sat, 19 Dec 2009 09:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.366 X-Spam-Level: X-Spam-Status: No, score=-102.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, 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 jXuXZtPTRU9m; Sat, 19 Dec 2009 09:50:28 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 62BF53A690D; Sat, 19 Dec 2009 09:50:28 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id EBDC2F24005; Sat, 19 Dec 2009 12:50:23 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 9pF3lDHJFnUo; Sat, 19 Dec 2009 12:50:12 -0500 (EST) Received: from THINKPADR52.vigilsec.com (pool-173-66-67-45.washdc.fios.verizon.net [173.66.67.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id B8BCC9A472F; Sat, 19 Dec 2009 12:50:22 -0500 (EST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 19 Dec 2009 12:49:06 -0500 To: "Grewal, Ken" From: Russ Housley In-Reply-To: References: <20091217023458.GA23757@mactavish> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> <19242.7719.715250.335841@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20091219175022.B8BCC9A472F@odin.smetech.net> Cc: ipsec@ietf.org, iesg@ietf.org Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 19 Dec 2009 17:50:29 -0000 Ken: >[Ken] I think this is the whole point. All the work on ESP/IPsec >this far has been considering a two party interaction (outside the >multicast context!). Now there is a third party - the middle box, >which would like to gain some additional information in order to >provide valuable network services. The end boxes already know what >is being negotiated, so just making changes to IKE to add additional >capability is insufficient in certain scenarios (while perfectly >sufficient in others). We need to provide additional information in >the data path, hence the need for WESP. I do not agree with your assessment of the situation. I agree with Tero's thoughts. The IPsecME charter includes this work item: A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. The starting points for this work item are draft-grewal-ipsec-traffic-visibility and draft-hoffman-esp-null-protocol. Nothing in this description prepared me for WESP processing of ESP packets with a non-NULL-cipher. It suggests making it easy for the middlebox to gain access to data that is already plaintext. It does not suggest making information available to the middlebox that was previously unavailable to it. Further, based on the discussion that has happened since I posted my DISCUSS position, other IPsecME WG participants are uncomfortable with the direction that WESP has taken. As the discussion progresses, if I can see that these people and myself are in the rough, then I will clear. So far, that does not seem to be the case. Russ From ynir@checkpoint.com Sat Dec 19 13:10: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 ED3133A6951; Sat, 19 Dec 2009 13:10:07 -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.066, 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 bUaaoEH+mAzw; Sat, 19 Dec 2009 13:10:06 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id EF5E63A6877; Sat, 19 Dec 2009 13:10:05 -0800 (PST) X-CheckPoint: {4B2D4020-10004-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2CB1829C004; Sat, 19 Dec 2009 23:09:49 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 0A47C29C002; Sat, 19 Dec 2009 23:09:49 +0200 (IST) X-CheckPoint: {4B2D401F-10000-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBJL9mT7017118; Sat, 19 Dec 2009 23:09:48 +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, 19 Dec 2009 23:09:59 +0200 From: Yoav Nir To: Scott C Moonen , Tero Kivinen Date: Sat, 19 Dec 2009 23:05:55 +0200 Thread-Topic: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01) Thread-Index: Acp/51emYkvWz3tXRjiA0olSrykVxQBB7ah4 Message-ID: <006FEB08D9C6444AB014105C9AEB133FB36A4EC5F9@il-ex01.ad.checkpoint.com> References: <19243.32427.247190.77844@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: "ipsec@ietf.org" , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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: Sat, 19 Dec 2009 21:10:08 -0000 If there is such an implementation, then it's not interoperating with all t= he other implementations and should be fixed. If someone shipped something like that, then the only reason they haven't n= oticed yet, is because they (1) didn't test it well enough, and (2) their c= ustomers are using some other option like 1024-bit MODP group (and 3DES, bu= t that's beside the point) Anyway, making everyone add a new group "28" just so nobody needs to patch = their old implementation of group "20" seems like wasted effort to me. We = can keep group 20, and fix the spec to prescribe what everybody is doing an= yway. ________________________________________ From: ipsec-bounces@ietf.org [ipsec-bounces@ietf.org] On Behalf Of Scott C = Moonen [smoonen@us.ibm.com] Sent: Friday, December 18, 2009 15:37 To: Tero Kivinen Cc: ipsec@ietf.org; ipsec-bounces@ietf.org Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC= 5114, RFC4869, and draft-solinas-rfc4753bis-01) Tero, what you propose seems the right way to go in principle, but I suspec= t we are solving a problem that doesn't exist. Is there any crypto library= or device that exposes the y coordinate for use in the ECDH secret? It se= ems pretty well established that the x coordinate serves as the ECDH secret= . Moreover, since the y coordinate provides only one more bit of independe= nt information, it's actually misleading to use it. I seriously doubt there is any implementation that does not implement the i= ntent of the erratum, if only because there are immense practical barriers = to implementing the RFC as written. Given that, I think the practical resu= lt of what you propose will actually be more confusion and a longer period = of time before all implementations (as well as all standards/profiles) are = able to re-stabilize to the new ECDH landscape. The practical cost of maki= ng this change is greater than the practical benefit it buys. On the other hand, if there is such an implementation, then we probably do = need to do something like what you propose. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Tero Kivinen To: ipsec@ietf.org Date: 12/18/2009 08:08 AM Subject: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, = RFC5114, RFC4869, and draft-solinas-rfc4753bis-01) ________________________________ I got just request to review modifications to IKEv2 IANA because of the draft-solinas-rfc4753bis-01.txt. We had this discussion a while back on the IPsec list where we noted that having errata which makes non-interoperable change to the RFC is not really ok, and we requested the authors to submit new document. Errata: http://www.rfc-editor.org/errata_search.php?rfc=3D4753&rec_status= =3D15&presentation=3Drecords Email thread: http://www.ietf.org/mail-archive/web/ipsec/current/msg04529.h= tml At that point Paul summarized things very nicely: My view is that the errata is technically wrong and should be withdrawn because it changes something that is disagreed to by test vectors in the document itself. If the authors of RFC 4753 want the format to be just the x coordinate, they should prepare a revision to RFC 4753 that obsoletes it and has correct text and test vectors. Now when this came to me when IANA asked me to do Expert review to the IANA allocations, I noticed that it would be very bad if we reused the old numbers 19, 20, 21 as that would mean nobody knows which version of the RFC (old RFC without errata, or RFC4753 with errata =3D=3D new RFC) is really used. As the Diffie-Hellman groups are negotiated and the registry is 16 bits, we do not need to try to save the numbers, I think it would be bad idea to reuse the existing values with different meaning. Because of this I answered that the new groups with new meanings would need to get new numbers. When I started investigating problem bit more I found out that RFC5114 which defines 2 new ECP groups (in addition of repeating the 3 ECP groups from RFC4753) says: ---------------------------------------------------------------------- 3.2. IKE Use of MODP Diffie-Hellman groups with IKEv2 is defined in [RFC4306], and the use of MODP groups with IKEv1 is defined in [RFC2409]. However, in the case of ECP Diffie-Hellman groups, the format of key exchange payloads and the derivation of a shared secret has thus far been specified on a group-by-group basis. For the ECP Diffie-Hellman groups defined in this document, the key exchange payload format and shared key derivation procedure specified in [RFC4753] MUST be used (with both IKEv2 and IKEv1). ---------------------------------------------------------------------- Now if we obsolete RFC4753, does that mean that this reference will also change, so which format is used for these groups 25 and 26 define in RFC5114? Do we need a new numbers for those groups also so it will be clear which version they use. Then there is also the RFC4869 which defines UI suites. That refers Diffie-Hellman groups as "256-bit random ECP group [RFC4753]". Which format of group those uses. When we now change RFC4753 does that mean that old implementations using RFC4869 UI suites using original RFC4753 groups is not compatible with newer RFC4869 version or what? I think the best way forward is to allocate new numbers for all RFC4753 derived groups (19, 20, 21, 25, 26) and create new UI suites using those new group numbers. This will create one time update where everybody needs to change their code by changing number 19 to n and 20 to n+1 and so on, and at the same time verify that the secret they use is only the x-coordinate. This change is small and can be done very quickly, but after that we do not need to think whether we can interoperate with someone using ECP group n, as we know it must be using new secret format. If someone uses old groups 19, 20, 21, 25, or 26 then you can make your guess whether they also implemented errata or not, and act based on that. Good thing is that as Diffie-Hellman groups are negotiated in IKEv2 it is easy to offer both 19 and new group n if backward compatibility with old versions is needed (provided you also know whether the group 19 on the other end uses errata or not). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From kohn.jack@gmail.com Sun Dec 20 16:36: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 631613A68FE for ; Sun, 20 Dec 2009 16:36:58 -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 VE+O8JHSA3Fw for ; Sun, 20 Dec 2009 16:36:57 -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 5AA593A68CD for ; Sun, 20 Dec 2009 16:36:57 -0800 (PST) Received: by yxe30 with SMTP id 30so5476918yxe.29 for ; Sun, 20 Dec 2009 16:36: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 :content-transfer-encoding; bh=al3Me5jW4K3g6nK2PvkL0lLqDauDlmbSdQpXlU434qE=; b=o7TOzxI+kdHbm+d/aJZe25IvipnlZ9lKwbhFLUa+PNv+Nnfz96jyHM+s5/nUEGDOnK iBxLPjLSzT6VgXNJO9lpUgyHlo+TrcJcowLpW7iULyBs7fvVUBT5wc5/p5Pdm0c2RukK cPImwWCZLIllcuoiyi4UudLA3FiHxQ6UI0vE4= 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=hoMXvQ79FAMs6pvrLdcfd/9Iv/GHvSNYuSNmGIMN/IEgVsmxGA14z5QzrzEf3SQ3ar 8M4Ucijt8ZZSeAQw32qfWVzQHSUTmH/vZkaa92xadCb+nEpGMZE/Oj4ipRwEMLLcodbL p2hQhssajN1wy2bIOam7WoXv+wNyvUZRCBHko= MIME-Version: 1.0 Received: by 10.91.63.12 with SMTP id q12mr1691900agk.23.1261355798951; Sun, 20 Dec 2009 16:36:38 -0800 (PST) In-Reply-To: <20091219175022.B8BCC9A472F@odin.smetech.net> References: <20091217023458.GA23757@mactavish> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> <19242.7719.715250.335841@fireball.kivinen.iki.fi> <20091219175022.B8BCC9A472F@odin.smetech.net> Date: Mon, 21 Dec 2009 06:06:38 +0530 Message-ID: From: Jack Kohn To: Russ Housley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 21 Dec 2009 00:36:58 -0000 Hi Russ, If we are not willing to ever extend WESP then we might as well debate the alternative scheme that i had reviewed long time back (which was shot down citing WESP being more extensible). I see that we are going through the discussions that we've already had in the WG, things that had been decided by majority consensus, approved by everyone in the WG. With this being the case we might as well debate on whether we really want a new protocol type for WESP (again discussed long time back) or if we can just hijack one of the SPI values and treat all packets with that as ESP-NULL. Alternatively, since we seem to be having unlimited bandwidth for discussions, we might as well argue whether we need heuristics also or not, as there are very few people in IPSecMe WG who feel the need for it. Strangely, its that same set of people who are against the idea of using null NULL ciphers for WESP. Is it because by supporting encryption in WESP we make it more generic, and thereby increasing the chances of its widespread implementation as against the other proposal (heuristics)? Jack On Sat, Dec 19, 2009 at 11:19 PM, Russ Housley wrote= : > Ken: > >> [Ken] I think this is the whole point. All the work on ESP/IPsec this fa= r >> has been considering a two party interaction (outside the multicast >> context!). Now there is a third party - the middle box, which would like= to >> gain some additional information in order to provide valuable network >> services. The end boxes already know what is being negotiated, so just >> making changes to IKE to add additional capability is insufficient in >> certain scenarios (while perfectly sufficient in others). We need to pro= vide >> additional information in the data path, hence the need for WESP. > > I do not agree with your assessment of the situation. =A0I agree with Ter= o's > thoughts. > > The IPsecME charter includes this work item: > > =A0A standards-track mechanism that allows an intermediary device, such > =A0as a firewall or intrusion detection system, to easily and reliably > =A0determine whether an ESP packet is encrypted with the NULL cipher; and > =A0if it is, determine the location of the actual payload data inside the > =A0packet. The starting points for this work item are > =A0draft-grewal-ipsec-traffic-visibility and draft-hoffman-esp-null-proto= col. > > Nothing in this description prepared me for WESP processing of ESP packet= s > with a non-NULL-cipher. =A0It suggests making it easy for the middlebox t= o > gain access to data that is already plaintext. =A0It does not suggest mak= ing > information available to the middlebox that was previously unavailable to > it. > > Further, based on the discussion that has happened since I posted my DISC= USS > position, other IPsecME WG participants are uncomfortable with the direct= ion > that WESP has taken. =A0As the discussion progresses, if I can see that t= hese > people and myself are in the rough, then I will clear. =A0So far, that do= es > not seem to be the case. > > Russ > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From akisada@tahi.org Sun Dec 20 22: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 710413A697E for ; Sun, 20 Dec 2009 22:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.309 X-Spam-Level: *** X-Spam-Status: No, score=3.309 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=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 8OzZYx4SSiV7 for ; Sun, 20 Dec 2009 22:42:31 -0800 (PST) Received: from ns.64translator.com (70.145.221.202.bf.2iij.net [202.221.145.70]) by core3.amsl.com (Postfix) with ESMTP id DBA4B3A677C for ; Sun, 20 Dec 2009 22:42:30 -0800 (PST) Received: from bahamas.64translator.com (bahamas.64translator.com [10.21.32.3]) by ns.64translator.com (8.14.3/8.14.3) with ESMTP id nBL68Vhx061608 for ; Mon, 21 Dec 2009 15:08:31 +0900 (JST) (envelope-from akisada@tahi.org) Received: from localhost (dhcp163.64translator.com [10.21.32.163]) by bahamas.64translator.com (8.13.6/8.13.6) with SMTP id nBL6eleF021123 for ; Mon, 21 Dec 2009 15:40:47 +0900 (JST) (envelope-from akisada@tahi.org) Date: Mon, 21 Dec 2009 15:40:39 +0900 From: Yukiyo Akisada To: ipsec@ietf.org Message-Id: <20091221154039.c3dcbc66.akisada@tahi.org> Organization: TAHI Project X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.12; i386-portbld-freebsd4.11) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [IPsec] [reminder] 10th TAHI IPv6 Interoperability test event 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, 21 Dec 2009 06:42:32 -0000 Hi, all. TAHI Project would like to announce about holding 10th TAHI IPv6 Interoperability test event again. Date: Jan. 25-29, 2010 Venue: Makuhari Messe, Makuhari, Japan Target: Conformance & Interoperability tests * IPv6 Ready Logo Program Phase-2 o IPv6 Core Protocols o IPsec o IKEv2 o MIPv6 o NEMO Basic Support o DHCPv6 o SIP o SNMP o MLDv2 (router only) o IMS (Trial) (UE only) * Others o KINK o DNS o MLDv2 (listener only) o OSPFv3 Early-Bird Registration will be closed Dec. 25, 2009. Please don't miss it, if you have an interest in this event. You can get details at . Best regards, -- Yukiyo Akisada From alper.yegin@yegin.org Mon Dec 21 01:32: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 AA5843A63EC for ; Mon, 21 Dec 2009 01:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.022 X-Spam-Level: * X-Spam-Status: No, score=1.022 tagged_above=-999 required=5 tests=[AWL=-1.909, BAYES_40=-0.185, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, SARE_FWDLOOK=1.666] 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 cN9X93mrqo77 for ; Mon, 21 Dec 2009 01:32:18 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 8C2343A672E for ; Mon, 21 Dec 2009 01:32:18 -0800 (PST) Received: from LENOVO (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MCKl7-1NDcCu2ucT-008zBn; Mon, 21 Dec 2009 04:31:54 -0500 From: "Alper Yegin" To: "'Raj Singh'" References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <1d38a3350912090742q1976ffefo85ef5e0e5627ec0b@mail.gmail.com> <023f01ca7908$480951b0$d81bf510$%yegin@yegin.org> <3824040C-7D40-4B46-B430-AE87D6729A19@checkpoint.com> <02c401ca7970$974303d0$c5c90b70$%yegin@yegin.org> <20091215183742.GV1516@Sun.COM> <62778081976350302@unknownmsgid> <7ccecf670912171850n15dd3c42t2692bb1a355f7daf@mail.gmail.com> In-Reply-To: <7ccecf670912171850n15dd3c42t2692bb1a355f7daf@mail.gmail.com> Date: Mon, 21 Dec 2009 11:31:46 +0200 Message-ID: <013f01ca8220$6f54c030$4dfe4090$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0140_01CA8231.32DD9030" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp/jNIRpOSw41X3QIyHgYqzOK21BgCksVRw Content-Language: en-us X-Provags-ID: V01U2FsdGVkX18241AJ2e8PYcxsvA0IpONWcK/85JVjDwcOAR6 RQNAsFxBjY8EPcUBJ8ZUUo52J7oGeBC+TI+G5tVwJ4b9BClOPz 2rKZ0Sgqo+bU1tQBjKD/Q== Cc: 'Hui Deng' , 'ipsec' , 'Yoav Nir' , 'Nicolas Williams' Subject: Re: [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: Mon, 21 Dec 2009 09:32:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0140_01CA8231.32DD9030 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Raj, =20 >> IKEv2 is defined and used for creating IPsec SAs. =20 > IKE is Internet Key Exchange protocol NOT IPsec Key Exchange protocol. > IKEv2 is not just a mean of exchanging keys but its a full package. > This package provides mutual authentication, keys and readiness to = secure data as needed. =20 Reading from RFC 4306: =20 IKE is a component of IPsec used for performing mutual authentication = and establishing and maintaining security associations (SAs). =20 =E2=80=A6 =20 IKE performs mutual authentication between two parties and establishes an IKE security association (SA) that includes shared secret information that can be used to efficiently establish SAs for Encapsulating Security Payload (ESP) [RFC4303] and/or Authentication Header (AH) [RFC4302] and a set of cryptographic algorithms to be used by the SAs to protect the traffic that they carry.=20 =20 Obviously IKE is designed and used for IPsec. If it weren=E2=80=99t = we=E2=80=99d not be discussing a proposal that tried to break that tie. =20 > The main motivation for this draft is Remote Access VPN scenario. =20 Alper =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Raj Singh Sent: Friday, December 18, 2009 4:50 AM To: Alper Yegin Cc: Hui Deng; ipsec; Yoav Nir; Nicolas Williams Subject: Re: [IPsec] Proposed work item: Childless IKE SA =20 Hi Alper, =20 On Fri, Dec 18, 2009 at 5:19 AM, Alper Yegin = wrote: Hi, I'm hoping by now it is understood that "childless IKE SA" is just a technical detail of what is really on the table. The proposal on the = table is "designing a network access authentication protocol based on IKEv2". That's what this WG and IETF should be discussing. Having multiple solutions for the very same problem space creates interoperability problem. If IETF has defined a protocol for a given problem, and if some other people come along and ask another solution be standardized for the very same problem, IETF needs a justification. Otherwise, we end up working "against" interoperability, not "for". The only justification I'm hearing is "we don't want to use PANA because = it is not implemented in my stack." This is an extremely poor = justification. One can say it for any new protocol, and choose to hack up whatever = he/she has. How can growing PANA out of IKEv2 be any better than using PANA. IKEv2 is defined and used for creating IPsec SAs. =20 IKE is Internet Key Exchange protocol NOT IPsec Key Exchange protocol. IKEv2 is not just a mean of exchanging keys but its a full package. This package provides mutual authentication, keys and readiness to = secure data as needed. The main motivation for this draft is Remote Access VPN scenario. =20 Yeah, it needs to perform peer authentication, but that's for creating securing the IPsec SA = creation. There are many other protocols that authenticate the peers for the sake = of securely performing their own dedicated objectives. E.g., Mobile IP authenticates MN and HA for securely creating binding caches; RFC 3118 authenticates DHCP client and DHCP server for secure host configuration; etc. etc. Taking the peer authentication parts of these protocols and = use it for totally different purposes is not right. > I don't see why we couldn't let IKEv2 have a go at displacing PANA in = the marketplace. Few folks want to twist IKEv2 into network access authentication = protocol (this proposal). Few other folks want to twist DHCP into network access authentication protocol (EAP-over-DHCP proposal). Few other folks want to twist HTTP into network access authentication protocol (EAP-over-HTTP proposal). They all have the exact same (poor) justification: We need EAP-over-Foo because we already have Foo. The above list is what is already being entertained here and there. The = list is very likely to grow. How can that not be a problem if all were getting standardized (for the = sake of argument, let's forget about the technical brokenness of the last two proposals). Every one of them think they were saving by implementing = "one", but in fact all are getting implemented eventually. Each access authentication specific feature needs to be reproduced on each such protocol. A multi-mode terminal (host) and NAS need to implement = all..... > What's really not desirable is non-interoperability, and that, I = believe, we can achieve by making PANA the required to implement network access protocol. "We" (IETF) do not and cannot make PANA "required to implement" network access authentication protocol. Other SDOs/platforms make such mandates. = So, I don't think saying "no" to redundant solutions is a bad thing that = that way. If someone is truly hung up on using IKEv2 purely for network access authentication, why can't they already do so? So what if it creates an = IPsec SA. Just don't use it. > Suppose you want a combination of "peer authentication only" for some > traffic and "peer authentication + ESP/AH" for other kinds of traffic > (think of this as differentiated services). Then to use PANA for one > and IPsec for the other seems silly. Is this a real scenario? This is not the scenario Hui brought up. He's talking about Femto AP connecting to femto access network via WAN; in = one case (a) WAN is already secured (e.g., via physical security) and he = does not need to use IPsec at all; in the other case (b) WAN is open Internet = and ne needs to use IPsec. In both cases, he needs to authenticate the Femto = AP and he wants to use IKEv2 for that. And I say use PANA instead. So, PANA-based solution becomes this: For case (a): Use PANA for Femto AP authentication. That's all you need. For case (b): Use PANA for Femto AP authentication, use IKEv2 for = setting up IPsec SA. .... I'm not disputing doability of this proposal. See, an even worse example = is 3GPP2 using Mobile IPv4 authentication for L3 network access = authentication between the MS (MN) and PDSN (FA). I guess we are lucky that they didn't come to IETF for tweaking RFC 4004 for that (they could get good number = of support, if we were going with that indication only). This can also made = to work, but IMHO there is much bigger harm than benefit in this case. Alper > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Nicolas Williams > Sent: Tuesday, December 15, 2009 8:38 PM > To: Alper Yegin > Cc: 'Hui Deng'; ipsec@ietf.org; 'Yoav Nir' > Subject: Re: [IPsec] Proposed work item: Childless IKE SA > > On Thu, Dec 10, 2009 at 10:12:54AM +0200, Alper Yegin wrote: > > > The "Do phase 1 first, and phase 2 as traffic demands it" > motivation is > > > from the remote access VPN domain (though may be useful for > others). > > > > > > The "Do only phase 1, because we don't need encryption and MAC, > just > > > peer authentication" motivation is from the 3GPP (though it could > be > > > useful for others) > > > > > > The "Do only phase 1 to discover if we're in or out of the secure > > > network (then do phase 2 if we're out)" motivation is also mostly = a > > > remote access VPN thing. > > > > > > The other motivations were from suggestions by others, and will be > > > hashed out (or taken out of the document) should this become a WG > > > document. > > > > I'm particularly concerned about reinventing the wheel aspect with > your > > second bullet, as I elaborated in response to Hui in my previous > email. > > > > As for the other motivations, I'm not sure the savings are worth the > effort. > > Imho.... > > Suppose you want a combination of "peer authentication only" for some > traffic and "peer authentication + ESP/AH" for other kinds of traffic > (think of this as differentiated services). Then to use PANA for one > and IPsec for the other seems silly. > > I don't see why an applicability statement should not suffice to > prevent > the scenario that you dislike (which I think is: IKEv2 displacing PANA > where IKEv2 should be considered to not be applicable). But see = below. > > The issue to settle here, as I see it, is: are there any uses of > childless IKEv2 SAs that justify the work? > > Of the various use case scenarios given in the I-D the first is the > most > convincing, though the lack of childless IKEv2 SAs hardly seems > problematic there. The last use case is very interesting, but very > forward looking. The next to last use case is specific to an EAP > method, thus not very interesting to this WG (IMO) except as a way to > keep divergence between base spec and the EAP method to a minimum. = The > other use case scenarios seem to encroach on the applicability of = PANA. > > Just based on that my support is lukewarm. > > Quite aside from that, I question the applicability statement that you > seem to be making. PANA and IKEv2-with-childless-SAs seem roughly > equivalent, with IKEv2 being more general. Why should we forbid use = of > the latter for network access control? Certainly having two such > protocols is not exactly desirable, but it's not clear to me that PANA > is the protocol that should win. What's really not desirable is non- > interoperability, and that, I believe, we can achieve by making PANA > the > required to implement network access protocol. I don't see why we > couldn't let IKEv2 have a go at displacing PANA in the marketplace. = If > there is support in the WG for it, so be it. > > Nico > -- > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 Thanks, Raj ------=_NextPart_000_0140_01CA8231.32DD9030 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Raj,

 

>> IKEv2 is defined and used for creating = IPsec SAs.

 

> IKE is Internet Key Exchange protocol NOT = IPsec Key Exchange protocol.

> IKEv2 is not just a mean = of exchanging keys but its a full package.

> This package provides = mutual authentication, keys and readiness to secure data as needed.

 

Reading from RFC 4306:

 

IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations = (SAs).

 

=E2=80=A6

 

=C2=A0=C2=A0 IKE performs mutual authentication between two parties =
and
=C2=A0=C2=A0 establishes an IKE security =
association (SA) that includes shared
=C2=A0=C2=A0 =
secret information that can be used to efficiently establish SAs =
for
=C2=A0=C2=A0 Encapsulating Security Payload =
(ESP) [RFC4303] and/or Authentication
=C2=A0=C2=A0 =
Header (AH) [RFC4302] and a set of cryptographic algorithms to =
be
=C2=A0=C2=A0 used by the SAs to protect the =
traffic that they carry.

 

Obviously IKE is designed and used for IPsec. If it = weren=E2=80=99t we=E2=80=99d not be discussing a proposal that tried to break that = tie.

 

> The main motivation for this draft is Remote = Access VPN scenario.

 

Alper

 

 

 

 

 

 

 

 

 

 

 

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Raj Singh
Sent: Friday, December 18, 2009 4:50 AM
To: Alper Yegin
Cc: Hui Deng; ipsec; Yoav Nir; Nicolas Williams
Subject: Re: [IPsec] Proposed work item: Childless IKE = SA

 

Hi Alper,

 

On Fri, Dec 18, 2009 at 5:19 AM, Alper Yegin <alper.yegin@yegin.org> = wrote:

Hi,

I'm hoping by now it is understood that "childless IKE SA" is = just a
technical detail of what is really on the table. The proposal on the = table
is "designing a network access authentication protocol based on IKEv2".
That's what this WG and IETF should be discussing.

Having multiple solutions for the very same problem space creates
interoperability problem.  If IETF has defined a protocol for a = given
problem, and if some other people come along and ask another solution = be
standardized for the very same problem, IETF needs a justification.
Otherwise, we end up working "against" interoperability, not "for".

The only justification I'm hearing is "we don't want to use PANA = because it
is not implemented in my stack." This is an extremely poor = justification.
One can say it for any new protocol, and choose to hack up whatever = he/she
has. How can growing PANA out of IKEv2 be any better than using = PANA.

IKEv2 is defined and used for creating IPsec SAs.

 

IKE is Internet Key Exchange protocol NOT IPsec Key = Exchange protocol.

IKEv2 is not just a mean = of exchanging keys but its a full package.

This package provides mutual authentication, = keys and readiness to secure data as needed.

The main motivation for this draft is Remote Access = VPN scenario.

 

Yeah, it needs to perform
peer authentication, but that's for creating securing the IPsec SA = creation.
There are many other protocols that authenticate the peers for the sake = of
securely performing their own dedicated objectives. E.g., Mobile IP
authenticates MN and HA for securely creating binding caches; RFC = 3118
authenticates DHCP client and DHCP server for secure host = configuration;
etc. etc. Taking the peer authentication parts of these protocols and = use it
for totally different purposes is not right.


> I don't see why we couldn't let IKEv2 have a go at displacing PANA = in the
marketplace.

Few folks want to twist IKEv2 into network access authentication protocol
(this proposal).
Few other folks want to twist DHCP into network access = authentication
protocol (EAP-over-DHCP proposal).
Few other folks want to twist HTTP into network access = authentication
protocol (EAP-over-HTTP proposal).

They all have the exact same (poor) justification: We need = EAP-over-Foo
because we already have Foo.

The above list is what is already being entertained here and there. The = list
is very likely to grow.

How can that not be a problem if all were getting standardized (for the = sake
of argument, let's forget about the technical brokenness of the last = two
proposals). Every one of them think they were saving by implementing "one",
but in fact all are getting implemented eventually. Each access
authentication specific feature needs to be reproduced on each such
protocol. A multi-mode terminal (host) and NAS need to implement = all.....



> What's really not desirable is non-interoperability, and that, I = believe,
we can achieve by making PANA the required to implement network = access
protocol.

"We" (IETF) do not and cannot make PANA "required to implement" network
access authentication protocol. Other SDOs/platforms make such mandates. = So,
I don't think saying "no" to redundant solutions is a bad = thing that that
way.

If someone is truly hung up on using IKEv2 purely for network access
authentication, why can't they already do so? So what if it creates an = IPsec
SA. Just don't use it.


> Suppose you want a combination of "peer authentication = only" for some
> traffic and "peer authentication + ESP/AH" for other = kinds of traffic
> (think of this as differentiated services).  Then to use PANA = for one
> and IPsec for the other seems silly.

Is this a real scenario? This is not the scenario = Hui brought up. He's
talking about Femto AP connecting to femto access network via WAN; in = one
case (a) WAN is already secured (e.g., via physical security) and he = does
not need to use IPsec at all; in the other case (b) WAN is open Internet = and
ne needs to use IPsec. In both cases, he needs to authenticate the Femto = AP
and he wants to use IKEv2 for that. And I say use PANA instead.

So, PANA-based solution becomes this:
For case (a): Use PANA for Femto AP authentication. That's all you = need.
For case (b): Use PANA for Femto AP authentication, use IKEv2 for = setting up
IPsec SA.



....

I'm not disputing doability of this proposal. See, an even worse example = is
3GPP2 using Mobile IPv4 authentication for L3 network access = authentication
between the MS (MN) and PDSN (FA). I guess we are lucky that they = didn't
come to IETF for tweaking RFC 4004 for that (they could get good number = of
support, if we were going with that indication only). This can also made = to
work, but IMHO there is much bigger harm than benefit in this = case.


Alper


















> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf

> Of Nicolas Williams
> Sent: Tuesday, December 15, 2009 8:38 PM
> To: Alper Yegin

> Cc: 'Hui Deng'; ipsec@ietf.org; 'Yoav Nir'
> Subject: Re: [IPsec] Proposed work item: Childless IKE SA
>

> On Thu, Dec 10, 2009 at 10:12:54AM +0200, = Alper Yegin wrote:
> > > The "Do phase 1 first, and phase 2 as traffic = demands it"
> motivation is
> > > from the remote access VPN domain (though may be useful = for
> others).
> > >
> > > The "Do only phase 1, because we don't need = encryption and MAC,
> just
> > > peer authentication" motivation is from the 3GPP = (though it could
> be
> > > useful for others)
> > >
> > > The "Do only phase 1 to discover if we're in or out = of the secure
> > > network (then do phase 2 if we're out)" motivation = is also mostly a
> > > remote access VPN thing.
> > >
> > > The other motivations were from suggestions by others, = and will be
> > > hashed out (or taken out of the document) should this = become a WG
> > > document.
> >
> > I'm particularly concerned about reinventing the wheel aspect = with
> your
> > second bullet, as I elaborated in response to Hui in my = previous
> email.
> >
> > As for the other motivations, I'm not sure the savings are = worth the
> effort.
> > Imho....
>
> Suppose you want a combination of "peer authentication = only" for some
> traffic and "peer authentication + ESP/AH" for other = kinds of traffic
> (think of this as differentiated services).  Then to use PANA = for one
> and IPsec for the other seems silly.
>
> I don't see why an applicability statement should not suffice = to
> prevent
> the scenario that you dislike (which I think is: IKEv2 displacing = PANA
> where IKEv2 should be considered to not be applicable).  But = see below.
>
> The issue to settle here, as I see it, is: are there any uses = of
> childless IKEv2 SAs that justify the work?
>
> Of the various use case scenarios given in the I-D the first is = the
> most
> convincing, though the lack of childless IKEv2 SAs hardly seems
> problematic there.  The last use case is very interesting, but = very
> forward looking.  The next to last use case is specific to an = EAP
> method, thus not very interesting to this WG (IMO) except as a way = to
> keep divergence between base spec and the EAP method to a minimum.  The
> other use case scenarios seem to encroach on the applicability of = PANA.
>
> Just based on that my support is lukewarm.
>
> Quite aside from that, I question the applicability statement that = you
> seem to be making.  PANA and IKEv2-with-childless-SAs seem = roughly
> equivalent, with IKEv2 being more general.  Why should we = forbid use of
> the latter for network access control?  Certainly having two = such
> protocols is not exactly desirable, but it's not clear to me that = PANA
> is the protocol that should win.  What's really not desirable = is non-
> interoperability, and that, I believe, we can achieve by making = PANA
> the
> required to implement network access protocol.  I don't see = why we
> couldn't let IKEv2 have a go at displacing PANA in the marketplace.  If
> there is support in the WG for it, so be it.
>
> Nico
> --
> _______________________________________________
> 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

 

Thanks,

Raj

------=_NextPart_000_0140_01CA8231.32DD9030-- From kivinen@iki.fi Mon Dec 21 03:21: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 5D5A53A680B for ; Mon, 21 Dec 2009 03:21:23 -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 pC4IuxfoZhKl for ; Mon, 21 Dec 2009 03:21:17 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id AC9A23A6848 for ; Mon, 21 Dec 2009 03:21: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 nBLBKng1029575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 13:20:49 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBLBKlbg028183; Mon, 21 Dec 2009 13:20:47 +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: <19247.23055.301223.938687@fireball.kivinen.iki.fi> Date: Mon, 21 Dec 2009 13:20:47 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EC5F9@il-ex01.ad.checkpoint.com> References: <19243.32427.247190.77844@fireball.kivinen.iki.fi> <006FEB08D9C6444AB014105C9AEB133FB36A4EC5F9@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 18 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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, 21 Dec 2009 11:21:24 -0000 Yoav Nir writes: > If there is such an implementation, then it's not interoperating > with all the other implementations and should be fixed. It is following the published RFC, so why should it be fixed. I think everybody agreed that making major non-interoperable change in the errata was not proper way of fixing the thing (there were lots of developers who had missed that). This whole discussion about the errata started because one implementor was implementing the RFC and wanted to make sure that the y is really added, and he wanted to make sure that he understood it correctly as that would eman that those groups cannot be made complient to FIPS 140-2. He had not noticed the errata. There were also other people who had not noticed the errata (including me). I am sure there is also people who do not follow the IPsec list and still do implement things (following IPsec list is not really requirement for implementing IPsec). I am only person in our office who regularly follow IPsec list and all others just take RFCs and read them and write code based on them. I am not sure if any of those people actually even know how to find errata... Made quick poll around the office, and found out that noboby here had checked any of the errata for any of the RFCs they have worked on. They said they usually do check for rfc-index to see if the RFC was updated or obsoleted, but that is it. > If someone shipped something like that, then the only reason they > haven't noticed yet, is because they (1) didn't test it well enough, Doing testing against your implementation does not detect that kind of problem as everything works fine. Also for quite a lot of IPsec vendors the main goal is to make implementation which works with their own products and the secondary goal is that it works with other vendor's product too. > and (2) their customers are using some other option like 1024-bit > MODP group (and 3DES, but that's beside the point) That is most likely true for all current IPsec implementations. Elliptic curves are not really used that much yet. That is the reason I want to fix this problem now, not move it to future. > Anyway, making everyone add a new group "28" just so nobody needs to > patch their old implementation of group "20" seems like wasted > effort to me. We can keep group 20, and fix the spec to prescribe > what everybody is doing anyway. I do not want to see the support request saying that our product does not interoperate vendor X's product when using group 19 and then later find out that is because the other vendor has implemented RFC4753 and didn't notice the errata. Also it will most likely take our customer and our support quite a long time before they even realize why recipient of IKE_AUTH will simply drop the packet because of wrong MAC. After that wasted effort I know that it will come to me, and I need to explain to our customer that our code is correct and the other implementation was also correct when they wrote the code, but they are not correct anymore... I do not think the elliptic curves are used that much in the current IPsec installations, so I think we still have time to fix this problem properly. -- kivinen@iki.fi From kivinen@iki.fi Mon Dec 21 03:36: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 57E893A69E7 for ; Mon, 21 Dec 2009 03:36:26 -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 QgEjVjJe2Ks9 for ; Mon, 21 Dec 2009 03:36:25 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 037763A69E5 for ; Mon, 21 Dec 2009 03:36: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 nBLBa52W005104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 13:36:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBLBa5SR028179; Mon, 21 Dec 2009 13:36: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: <19247.23973.271637.205639@fireball.kivinen.iki.fi> Date: Mon, 21 Dec 2009 13:36:05 +0200 From: Tero Kivinen To: Jack Kohn In-Reply-To: References: <20091217023458.GA23757@mactavish> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> <19242.7719.715250.335841@fireball.kivinen.iki.fi> <20091219175022.B8BCC9A472F@odin.smetech.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 12 min Cc: ipsec@ietf.org, Russ Housley Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 21 Dec 2009 11:36:26 -0000 Jack Kohn writes: > Alternatively, since we seem to be > having unlimited bandwidth for discussions, we might as well argue > whether we need heuristics also or not, as there are very few people > in IPSecMe WG who feel the need for it. My personal feelings is that this inspecting ESP-NULL packets is not needed at all, as everything will be encrypted ESP anyways, so there is even no point of trying to inspect any of that ESP-NULL traffic (either using WESP or heuristics). The reason I am in favor of heuristics instead of WESP, is that heuristics requires changes only on the middleboxes, we do not need to make new extension that will affect all the end nodes supporting IPsec. Also heuristics is not harmful, as it does not harm others, it is simply internal matter inside the middlebox. I do consider WESP a bit harmful, as it adds extra bytes to all packets, and does not offer that much which cannot already be done by other means, but requires all IPsec end nodes to be updated (and also every single firewall needs to be reconfigured to allow also this new protocol number through not just proto 50 and 51). But those are my personal feelings, and I agreed that as rest of the WG seemed to want to work on WESP, that is fine, but I still wanted push the heuristics forward just as middlebox only alternative to WESP. > Strangely, its that same set of people who are against the idea of > using null NULL ciphers for WESP. Is it because by supporting > encryption in WESP we make it more generic, and thereby increasing > the chances of its widespread implementation as against the other > proposal (heuristics)? Using non-NULL ciphers for WESP takes it out from its intended use, and unless there is some more extensions done for WESP (which there currently isn't), there is no point of doing that, as using WESP for encrypted ESP we are just wasting bytes for extra WESP header. Meaning that before we see any extensions that would require WESP and encrypted ESP I do not think there is any point of sending encrypted ESP traffic using WESP. And yes, making WESP more generic would mean that I would perhaps some day need to implement it (which I do not want to) if there is too much customer demand for it in the future. -- kivinen@iki.fi From kivinen@iki.fi Mon Dec 21 04:01: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 E251528C0E9 for ; Mon, 21 Dec 2009 04:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 fZjwG+bjrwkl for ; Mon, 21 Dec 2009 04:01:28 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B5F3128C0E0 for ; Mon, 21 Dec 2009 04:01: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 nBLC15Jl026894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 14:01:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBLC14Rt001355; Mon, 21 Dec 2009 14:01: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: <19247.25472.791900.940291@fireball.kivinen.iki.fi> Date: Mon, 21 Dec 2009 14:01:04 +0200 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <19243.32427.247190.77844@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 21 min Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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, 21 Dec 2009 12:01:29 -0000 Scott C Moonen writes: > Tero, what you propose seems the right way to go in principle, but I > suspect we are solving a problem that doesn't exist. Is there any crypto > library or device that exposes the y coordinate for use in the ECDH > secret? It seems pretty well established that the x coordinate serves as > the ECDH secret. Moreover, since the y coordinate provides only one more > bit of independent information, it's actually misleading to use it. At least in our crypto library it would be possible to get both of them out if we wanted. I checked our implementation and currently it seems to return only x, but that was changed July 2009 after this dicussion started on the list. Before that the code was modified in 2007 to follow RFC4753, and the original code was written in 2001. This means that all our implementations we have released between 2007-2009 are using the orignal RFC4753 version, thus nobody will be interoperable with those. > I seriously doubt there is any implementation that does not implement the > intent of the erratum, if only because there are immense practical > barriers to implementing the RFC as written. Given that, I think the > practical result of what you propose will actually be more confusion and a > longer period of time before all implementations (as well as all > standards/profiles) are able to re-stabilize to the new ECDH landscape. > The practical cost of making this change is greater than the practical > benefit it buys. There are as all our QuickSec implementations with versions 4.4 - 5.0 do include the original RFC 4753 code, and only the latest QuickSec 5.1 was modified to include errata. (I just now noticed this myself). Note, that none of our customers have complained to us that we are not compatible with other vendor's product using groups 19-21, so that either means nobody uses those groups, or some of those other vendors have also implemented RFC4753 without errata... > On the other hand, if there is such an implementation, then we probably do > need to do something like what you propose. As we need to do something on those versions anyway, I rather make patch that will fix them to follow the new RFC, and also change the group numbers to match new group numbers for those old versions, as then customers using those versions will not break their own interoperability with old versions (it is ok, if they decide to select some other Diffie-Hellman group as old versions do not support new numbers, but it is not ok for the implementations to get MAC failures when trying to use those groups). -- kivinen@iki.fi From kivinen@iki.fi Mon Dec 21 04:05: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 6DA5F3A689A for ; Mon, 21 Dec 2009 04:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 F0nC5EkRg8EC for ; Mon, 21 Dec 2009 04:05:45 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C38D63A680B for ; Mon, 21 Dec 2009 04:05:44 -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 nBLC5RF5028368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 14:05:27 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBLC5QAb002247; Mon, 21 Dec 2009 14:05: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: <19247.25734.318539.699760@fireball.kivinen.iki.fi> Date: Mon, 21 Dec 2009 14:05:26 +0200 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <72a888732545c5066f493228c416d286.squirrel@www.trepanning.net> References: <19243.32427.247190.77844@fireball.kivinen.iki.fi> <72a888732545c5066f493228c416d286.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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, 21 Dec 2009 12:05:46 -0000 Dan Harkins writes: > The solution of allocating new numbers still doesn't really solve the > problem because if you receive an KE payload from group 19, 20, or 21 > "you can make your guess whether they also implemented errata or not, > and act based on that" and that sounds like a recipe for future > non-interoperability. As I just noticed we do support RFC4753 without errata in our previous versions we need to do something on this. What my current plan would be to make patch that will change implementations to support errata, and also change the group numbers to new. This means you get no proposal support or invalid ke payload notification if you try to talk to old versions supporting groups 19-21. If the policy allows any of the modp groups then invalid ke payload error cause both ends to move to modp groups which means implementations can talk to each other, and if policy only allows those new groups then you get no proposal chosen and then you need to modify policy to support some common groups. > The IANA registry for these groups is used by more than just IKE(v2) > and it would be nice if it was coherent and did not make assumption like > that. ikev2-parameters IANA registry should not be used for anything else than IKEv2. -- kivinen@iki.fi From yaronf@checkpoint.com Mon Dec 21 05:25: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 9E30228C121 for ; Mon, 21 Dec 2009 05:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 KKQ2rlkhdncb for ; Mon, 21 Dec 2009 05:25:09 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id F24B33A6948 for ; Mon, 21 Dec 2009 05:25:08 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBLDOmT8009046; Mon, 21 Dec 2009 15:24:48 +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, 21 Dec 2009 15:24:59 +0200 From: Yaron Sheffer To: Tero Kivinen , Jack Kohn Date: Mon, 21 Dec 2009 15:24:47 +0200 Thread-Topic: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Thread-Index: AcqCMdUfIGUVExnaQvmiCztNPttotQAAqPIw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F42F@il-ex01.ad.checkpoint.com> In-Reply-To: <19247.23973.271637.205639@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: "ipsec@ietf.org" , Russ Housley Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 21 Dec 2009 13:25:12 -0000 Hi Tero, Allowing the more generic, encrypted WESP (as per the current I-D) would le= t vendors experiment with different extensions. Yes, they might play with s= ome extensions that you and I find ugly or even insecure. But crippling WES= P today would mean that any such extensions are (1) limited to IKE and (2) = invisible to the middleboxes. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of T= ero Kivinen Sent: Monday, December 21, 2009 13:36 To: Jack Kohn Cc: ipsec@ietf.org; Russ Housley Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Jack Kohn writes: > Alternatively, since we seem to be > having unlimited bandwidth for discussions, we might as well argue > whether we need heuristics also or not, as there are very few people > in IPSecMe WG who feel the need for it. My personal feelings is that this inspecting ESP-NULL packets is not needed at all, as everything will be encrypted ESP anyways, so there is even no point of trying to inspect any of that ESP-NULL traffic (either using WESP or heuristics). The reason I am in favor of heuristics instead of WESP, is that heuristics requires changes only on the middleboxes, we do not need to make new extension that will affect all the end nodes supporting IPsec. Also heuristics is not harmful, as it does not harm others, it is simply internal matter inside the middlebox. I do consider WESP a bit harmful, as it adds extra bytes to all packets, and does not offer that much which cannot already be done by other means, but requires all IPsec end nodes to be updated (and also every single firewall needs to be reconfigured to allow also this new protocol number through not just proto 50 and 51). But those are my personal feelings, and I agreed that as rest of the WG seemed to want to work on WESP, that is fine, but I still wanted push the heuristics forward just as middlebox only alternative to WESP. > Strangely, its that same set of people who are against the idea of > using null NULL ciphers for WESP. Is it because by supporting > encryption in WESP we make it more generic, and thereby increasing > the chances of its widespread implementation as against the other > proposal (heuristics)? Using non-NULL ciphers for WESP takes it out from its intended use, and unless there is some more extensions done for WESP (which there currently isn't), there is no point of doing that, as using WESP for encrypted ESP we are just wasting bytes for extra WESP header. Meaning that before we see any extensions that would require WESP and encrypted ESP I do not think there is any point of sending encrypted ESP traffic using WESP.=20 And yes, making WESP more generic would mean that I would perhaps some day need to implement it (which I do not want to) if there is too much customer demand for it in the future. --=20 kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. From paav.cisco@gmail.com Mon Dec 21 06:15: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 8163C28C0E1; Mon, 21 Dec 2009 06:15: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 zbBmuSRfUxm2; Mon, 21 Dec 2009 06:15:52 -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 AC1853A63EC; Mon, 21 Dec 2009 06:15:51 -0800 (PST) Received: by fxm7 with SMTP id 7so4898463fxm.29 for ; Mon, 21 Dec 2009 06:15:31 -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=na7ks/lzm6j2lgBsUhrbHhiVm6cngkVg0yXM3/1Mpwc=; b=JlmB/1gGcjIefbqE7zg8B0v3vw/thxce6oyxYGUWieZ5BVIbWlxWGnGYbDCTsqvfGN 7yInQLYU2ue4oxSaKC+O6zluxbTlFMZcNIs1l0VjCccEeT5zIl6a/iossQib1+H9hVqw 8b2N61MZhD7nPS0GUam4MkiV906SoOQVkUBcw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=k+BMmkP0RHPDuBPO0ONprJBMyQ7F8Db7YpPQMIbvpe1CXPAO2xo2DhQf9OalMgBqKE QWWmbjAmKBnz+PRhl35c7vFE/ccNX+n+405K1+T87pKiy+fXn4bcaBo3lD698Xnm9PQ1 EJZ0L3wvOvhb7K9h0Y9qL5UtOJv0U+CwiBjao= MIME-Version: 1.0 Received: by 10.239.170.147 with SMTP id s19mr733748hbe.177.1261404931506; Mon, 21 Dec 2009 06:15:31 -0800 (PST) Date: Mon, 21 Dec 2009 19:45:31 +0530 Message-ID: <40e68ca20912210615r78c46c26td21ae4e26426a21c@mail.gmail.com> From: Padmakumar AV To: ipsec@ietf.org, iesg@ietf.org Content-Type: multipart/alternative; boundary=001636498dd1dc40d3047b3db894 Subject: [IPsec] IKEv2 Redirect based Authentication Offload and Proxy Session Resumption (draft-padmakumar-ikev2-redirect-and-auth-offload-02) 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, 21 Dec 2009 14:15:53 -0000 --001636498dd1dc40d3047b3db894 Content-Type: text/plain; charset=ISO-8859-1 Hi, We have published a new version of 'IKEv2 Redirect based Authentication Offload and Proxy Session Resumption' (draft-padmakumar-ikev2-redirect-and-auth-offload-02). The draft may be accessed at: http://tools.ietf.org/html/draft-padmakumar-ikev2-redirect-and-auth-offload-02 Abstract: IKEv2 supports multiple authentication mechanisms like public key signatures, shared secrets and EAP. EAP based authentication requires server to maintain information about the client until EAP completes. Public key based authentication mechanisms are highly computational intensive and demands server CPU resources. Redirect Mechanism for IKEv2 proposes a mechanism for IKEv2 that enables a VPN gateway to redirect the VPN client to another VPN gateway, for example, based on the load condition. IKEv2 Session Resumption proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. Redirect mechanism can also be used to redirect a client to another router (trust anchor) to do mutual authentication and an optional proxy session negotiation on behalf of the server. This redirection happens during the IKE_SA_INIT and server does not maintain any information about the redirected client. After mutual authentication and optional proxy session negotiation trust anchor redirects the client back to the server with an Access Token which can be used as a dynamic pre-shared key between the server and client for password based IKE_AUTH exchange. Mechanism described here allows servers to compute the same pre-shared key dynamically, without contacting trust anchors, based on the information provided by the client during IKE_AUTH exchange. Access Token based authentication permits IDr of the responder to be different from that specified in Ticket and permits client to reuse the proxy session (negotiated between client and trust anchor) between client and server. Such a mechanism is useful especially for low power devices like handsets. For example, a mobile node can redirect a correspondent node to its home agent. Home agent can form a proxy session with correspondent node and then redirect it back to mobile node. We appreciate your thoughts and comments. Thanks & regards Pratima, Manik & Padmakumar --001636498dd1dc40d3047b3db894 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

We have published a new ve= rsion of 'IKEv2 Redirect based Authentication Offload and Proxy Session= Resumption' =A0(draft-padmakumar-ikev2-redirect-and-auth-offload-02).<= /div>


Abstract:

=A0=A0 IKEv2 support= s multiple authentication mechanisms like public key
=A0=A0 signa= tures, shared secrets and EAP. =A0EAP based authentication
=A0=A0= requires server to maintain information about the client until EAP
=A0=A0 completes. =A0Public key based authentication mechanisms are hi= ghly
=A0=A0 computational intensive and demands server CPU resour= ces.

=A0=A0 Redirect Mechanism for IKEv2 proposes = a mechanism for IKEv2 that
=A0=A0 enables a VPN gateway to redirect the VPN client to another VPN=
=A0=A0 gateway, for example, based on the load condition.
<= div>
=A0=A0 IKEv2 Session Resumption proposes an extension to= IKEv2 that allows a
=A0=A0 client to re-establish an IKE SA with a gateway in a highly eff= icient
=A0=A0 manner, utilizing a previously established IKE SA.<= /div>

=A0=A0 Redirect mechanism can also be used to redi= rect a client to another
=A0=A0 router (trust anchor) to do mutual authentication and an option= al
=A0=A0 proxy session negotiation on behalf of the server. =A0T= his redirection
=A0=A0 happens during the IKE_SA_INIT and server = does not maintain any
=A0=A0 information about the redirected client. =A0After mutual authen= tication
=A0=A0 and optional proxy session negotiation trust anch= or redirects the
=A0=A0 client back to the server with an Access = Token which can be used as a
=A0=A0 dynamic pre-shared key between the server and client for passwo= rd
=A0=A0 based IKE_AUTH exchange. =A0Mechanism described here al= lows servers to
=A0=A0 compute the same pre-shared key dynamicall= y, without contacting trust
=A0=A0 anchors, based on the information provided by the client during=
=A0=A0 IKE_AUTH exchange. =A0Access Token based authentication p= ermits IDr of
=A0=A0 the responder to be different from that spec= ified in Ticket and
=A0=A0 permits client to reuse the proxy session (negotiated between c= lient
=A0=A0 and trust anchor) between client and server.

=A0=A0 Such a mechanism is useful especially for low powe= r devices like
=A0=A0 handsets. =A0For example, a mobile node can redirect a correspo= ndent
=A0=A0 node to its home agent. =A0Home agent can form a pro= xy session with
=A0=A0 correspondent node and then redirect it ba= ck to mobile node.


We appreciate your thoughts and comments= .

Thanks & regards

Pr= atima, Manik & Padmakumar
--001636498dd1dc40d3047b3db894-- From yaronf@checkpoint.com Mon Dec 21 07: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 097193A67FC for ; Mon, 21 Dec 2009 07:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 4anjHVJ2ZpHv for ; Mon, 21 Dec 2009 07:48:38 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 9FC013A6A39 for ; Mon, 21 Dec 2009 07:48:37 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBLFmKT7003641; Mon, 21 Dec 2009 17:48: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; Mon, 21 Dec 2009 17:48:31 +0200 From: Yaron Sheffer To: Tero Kivinen , Yoav Nir Date: Mon, 21 Dec 2009 17:48:18 +0200 Thread-Topic: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01) Thread-Index: AcqCL70sGu4pspP1QtmDRtT4vpDEKwAI8TLA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F474@il-ex01.ad.checkpoint.com> In-Reply-To: <19247.23055.301223.938687@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: "ipsec@ietf.org" Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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, 21 Dec 2009 15:48:39 -0000 Hi Tero, I support your position (and disagree with Yoav). We had better fix this pr= oblem now by allocating a few more numbers, than live forever with an ambig= uous interpretation to the numbers that everybody's using. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of T= ero Kivinen Sent: Monday, December 21, 2009 13:21 To: Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC= 5114, RFC4869, and draft-solinas-rfc4753bis-01) Yoav Nir writes: > If there is such an implementation, then it's not interoperating > with all the other implementations and should be fixed. It is following the published RFC, so why should it be fixed. I think everybody agreed that making major non-interoperable change in the errata was not proper way of fixing the thing (there were lots of developers who had missed that). This whole discussion about the errata started because one implementor was implementing the RFC and wanted to make sure that the y is really added, and he wanted to make sure that he understood it correctly as that would eman that those groups cannot be made complient to FIPS 140-2. He had not noticed the errata. There were also other people who had not noticed the errata (including me). I am sure there is also people who do not follow the IPsec list and still do implement things (following IPsec list is not really requirement for implementing IPsec). I am only person in our office who regularly follow IPsec list and all others just take RFCs and read them and write code based on them. I am not sure if any of those people actually even know how to find errata... Made quick poll around the office, and found out that noboby here had checked any of the errata for any of the RFCs they have worked on. They said they usually do check for rfc-index to see if the RFC was updated or obsoleted, but that is it. > If someone shipped something like that, then the only reason they > haven't noticed yet, is because they (1) didn't test it well enough, Doing testing against your implementation does not detect that kind of problem as everything works fine. Also for quite a lot of IPsec vendors the main goal is to make implementation which works with their own products and the secondary goal is that it works with other vendor's product too.=20 > and (2) their customers are using some other option like 1024-bit > MODP group (and 3DES, but that's beside the point) That is most likely true for all current IPsec implementations. Elliptic curves are not really used that much yet. That is the reason I want to fix this problem now, not move it to future.=20 > Anyway, making everyone add a new group "28" just so nobody needs to > patch their old implementation of group "20" seems like wasted > effort to me. We can keep group 20, and fix the spec to prescribe > what everybody is doing anyway. I do not want to see the support request saying that our product does not interoperate vendor X's product when using group 19 and then later find out that is because the other vendor has implemented RFC4753 and didn't notice the errata. Also it will most likely take our customer and our support quite a long time before they even realize why recipient of IKE_AUTH will simply drop the packet because of wrong MAC. After that wasted effort I know that it will come to me, and I need to explain to our customer that our code is correct and the other implementation was also correct when they wrote the code, but they are not correct anymore... I do not think the elliptic curves are used that much in the current IPsec installations, so I think we still have time to fix this problem properly.=20 --=20 kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. From danmcd@sun.com Mon Dec 21 08:33: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 6C46B28C0F9 for ; Mon, 21 Dec 2009 08:33:55 -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 EjjA3-GRAfFu for ; Mon, 21 Dec 2009 08:33:54 -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 AA93528C0F8 for ; Mon, 21 Dec 2009 08:33:54 -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 nBLGXbMX018938 for ; Mon, 21 Dec 2009 16:33:37 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 nBLGXbhW025517; Mon, 21 Dec 2009 11:33:37 -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 nBLGXNGR003734; Mon, 21 Dec 2009 11:33:23 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBLGXNZZ003733; Mon, 21 Dec 2009 11:33:23 -0500 (EST) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Mon, 21 Dec 2009 11:33:23 -0500 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20091221163323.GJ26482@kebe.East.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [IPsec] ECDSA certs and 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, 21 Dec 2009 16:33:55 -0000 Section 3.8 of IKEv2bis (Authentication Payload) makes no mention of ECDSA. Now granted, there is no mention of ECDH in the Transform substructure section either, so perhaps that's why. Given the recent firestorm on ECDH (4753 and its errata), it begs the question --> does ECDSA have a similar issue with coordinate mismatches? Dan From dharkins@lounge.org Mon Dec 21 10:42: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 9DB583A6A9E for ; Mon, 21 Dec 2009 10:42:50 -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 SsR9Zbg8KwWN for ; Mon, 21 Dec 2009 10:42:49 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 30C2F3A6A8E for ; Mon, 21 Dec 2009 10:42:21 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1971D1022407E; Mon, 21 Dec 2009 10:42:05 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 21 Dec 2009 10:42:05 -0800 (PST) Message-ID: In-Reply-To: <19247.25734.318539.699760@fireball.kivinen.iki.fi> References: <19243.32427.247190.77844@fireball.kivinen.iki.fi> <72a888732545c5066f493228c416d286.squirrel@www.trepanning.net> <19247.25734.318539.699760@fireball.kivinen.iki.fi> Date: Mon, 21 Dec 2009 10:42:05 -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: ipsec@ietf.org, Dan Harkins Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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, 21 Dec 2009 18:42:50 -0000 No, you won't get "no proposal chosen" or "invalid KE" payload. What you'll get, if you "guess" wrong, is garbage IKEv2 messages because a different representation of the shared secret will be fed into the prf that generates the keying material. That will not be diagnosable. Things just won't work and the customer will get really mad. And if developers aren't reading errata (as you claim) then I seriously doubt that field engineers and support do either. So we're looking at an RMA of a perfectly good piece of equipment. Your suggested fix does not actually fix the existing problem, it just makes an unambiguous way to negotiate these groups using different numbers. The same ambiguity will still exist for 19, 20, and 21. I think it would be better to fix the problem. You mentioned to Yoav that EC groups are not used that much currently. So this is an opportune time to fix the problem! Dan. On Mon, December 21, 2009 4:05 am, Tero Kivinen wrote: > Dan Harkins writes: >> The solution of allocating new numbers still doesn't really solve the >> problem because if you receive an KE payload from group 19, 20, or 21 >> "you can make your guess whether they also implemented errata or not, >> and act based on that" and that sounds like a recipe for future >> non-interoperability. > > As I just noticed we do support RFC4753 without errata in our previous > versions we need to do something on this. What my current plan would > be to make patch that will change implementations to support errata, > and also change the group numbers to new. This means you get no > proposal support or invalid ke payload notification if you try to talk > to old versions supporting groups 19-21. If the policy allows any of > the modp groups then invalid ke payload error cause both ends to move > to modp groups which means implementations can talk to each other, and > if policy only allows those new groups then you get no proposal chosen > and then you need to modify policy to support some common groups. > >> The IANA registry for these groups is used by more than just IKE(v2) >> and it would be nice if it was coherent and did not make assumption like >> that. > > ikev2-parameters IANA registry should not be used for anything else > than IKEv2. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From dharkins@lounge.org Mon Dec 21 10:43: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 5BF0A3A68E7 for ; Mon, 21 Dec 2009 10:43:49 -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 UN-0FAYiKbU2 for ; Mon, 21 Dec 2009 10:43:48 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 492653A67EE for ; Mon, 21 Dec 2009 10:43:48 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2EC341022407E; Mon, 21 Dec 2009 10:43:32 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 21 Dec 2009 10:43:32 -0800 (PST) Message-ID: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F474@il-ex01.ad.checkpoint.co m> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F474@il-ex01.ad.checkpoint.com> Date: Mon, 21 Dec 2009 10:43:32 -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" , Yoav Nir , Tero Kivinen Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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, 21 Dec 2009 18:43:49 -0000 Yaron, If we allocate new numbers to do it right then we will, in fact, live forever with an ambiguous interpretation of groups 19, 20, and 21. I agree we should fix the problem and not live with ambiguity. The proposal to allocate new numbers doesn't seem to do that though. Dan. On Mon, December 21, 2009 7:48 am, Yaron Sheffer wrote: > Hi Tero, > > I support your position (and disagree with Yoav). We had better fix this > problem now by allocating a few more numbers, than live forever with an > ambiguous interpretation to the numbers that everybody's using. > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Tero Kivinen > Sent: Monday, December 21, 2009 13:21 > To: Yoav Nir > Cc: ipsec@ietf.org > Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, > RFC5114, RFC4869, and draft-solinas-rfc4753bis-01) > > Yoav Nir writes: >> If there is such an implementation, then it's not interoperating >> with all the other implementations and should be fixed. > > It is following the published RFC, so why should it be fixed. I think > everybody agreed that making major non-interoperable change in the > errata was not proper way of fixing the thing (there were lots of > developers who had missed that). > > This whole discussion about the errata started because one implementor > was implementing the RFC and wanted to make sure that the y is really > added, and he wanted to make sure that he understood it correctly as > that would eman that those groups cannot be made complient to FIPS > 140-2. > > He had not noticed the errata. There were also other people who had > not noticed the errata (including me). > > I am sure there is also people who do not follow the IPsec list and > still do implement things (following IPsec list is not really > requirement for implementing IPsec). > > I am only person in our office who regularly follow IPsec list and all > others just take RFCs and read them and write code based on them. I am > not sure if any of those people actually even know how to find > errata... > > Made quick poll around the office, and found out that noboby here had > checked any of the errata for any of the RFCs they have worked on. > They said they usually do check for rfc-index to see if the RFC was > updated or obsoleted, but that is it. > >> If someone shipped something like that, then the only reason they >> haven't noticed yet, is because they (1) didn't test it well enough, > > Doing testing against your implementation does not detect that kind of > problem as everything works fine. Also for quite a lot of IPsec > vendors the main goal is to make implementation which works with their > own products and the secondary goal is that it works with other > vendor's product too. > >> and (2) their customers are using some other option like 1024-bit >> MODP group (and 3DES, but that's beside the point) > > That is most likely true for all current IPsec implementations. > Elliptic curves are not really used that much yet. That is the reason > I want to fix this problem now, not move it to future. > >> Anyway, making everyone add a new group "28" just so nobody needs to >> patch their old implementation of group "20" seems like wasted >> effort to me. We can keep group 20, and fix the spec to prescribe >> what everybody is doing anyway. > > I do not want to see the support request saying that our product does > not interoperate vendor X's product when using group 19 and then later > find out that is because the other vendor has implemented RFC4753 > and didn't notice the errata. > > Also it will most likely take our customer and our support quite a > long time before they even realize why recipient of IKE_AUTH will > simply drop the packet because of wrong MAC. After that wasted effort > I know that it will come to me, and I need to explain to our customer > that our code is correct and the other implementation was also correct > when they wrote the code, but they are not correct anymore... > > I do not think the elliptic curves are used that much in the current > IPsec installations, so I think we still have time to fix this problem > properly. > -- > kivinen@iki.fi > _______________________________________________ > 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 > From Black_David@emc.com Mon Dec 21 10:54: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 1502F28C10B for ; Mon, 21 Dec 2009 10:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[AWL=0.881, 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 GYKChgSZEmSB for ; Mon, 21 Dec 2009 10:54:41 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id B5E4C28C14A for ; Mon, 21 Dec 2009 10:54:40 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id nBLIsG0K001269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 13:54:16 -0500 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Mon, 21 Dec 2009 13:54:13 -0500 Received: from corpussmtp5.corp.emc.com (corpussmtp5.corp.emc.com [128.221.166.229]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id nBLIsDoq027612; Mon, 21 Dec 2009 13:54:13 -0500 Received: from CORPUSMX80B.corp.emc.com ([10.254.89.203]) by corpussmtp5.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 13:54:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Dec 2009 13:54:12 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01) Thread-Index: AcqCbYcQcCHXEGv6Tqayf9whvhCzJAAAB4iQ References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F474@il-ex01.ad.checkpoint.com> From: To: , X-OriginalArrivalTime: 21 Dec 2009 18:54:13.0062 (UTC) FILETIME=[FCABEE60:01CA826E] X-EMM-EM: Active Cc: ipsec@ietf.org, ynir@checkpoint.com, Black_David@emc.com, kivinen@iki.fi Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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, 21 Dec 2009 18:54:42 -0000 Dan, > If we allocate new numbers to do it right then we will, in fact, = live > forever with an ambiguous interpretation of groups 19, 20, and 21. I > agree we should fix the problem and not live with ambiguity. The = proposal > to allocate new numbers doesn't seem to do that though. Fine, here's how to accomplish that goal - the RFC that allocates the new group numbers should: 1) explain why the group numbers 19, 20 and 21 are ambiguous; 2) state that group numbers 19, 20 and 21 "SHOULD NOT be used"; 3) instruct IANA to remove the group number registrations for 19, 20 and 21 in a fashion that prevents reallocation; and 4) obsolete RFC 4753. That should avoid long term problems. That said, I'd like to see more reason to believe that there is an actual "running code" problem before doing something this drastic. If most people working with elliptic curve "just know" that only one coordinate is used, we might not have a problem in practice. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) = 293-7786 black_david@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Dan Harkins > Sent: Monday, December 21, 2009 1:44 PM > To: Yaron Sheffer > Cc: ipsec@ietf.org; Yoav Nir; Tero Kivinen > Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess = (RFC4753, RFC5114, RFC4869, and draft- > solinas-rfc4753bis-01) >=20 >=20 > Yaron, >=20 > If we allocate new numbers to do it right then we will, in fact, = live > forever with an ambiguous interpretation of groups 19, 20, and 21. I > agree we should fix the problem and not live with ambiguity. The = proposal > to allocate new numbers doesn't seem to do that though. >=20 > Dan. >=20 > On Mon, December 21, 2009 7:48 am, Yaron Sheffer wrote: > > Hi Tero, > > > > I support your position (and disagree with Yoav). We had better fix = this > > problem now by allocating a few more numbers, than live forever with = an > > ambiguous interpretation to the numbers that everybody's using. > > > > Thanks, > > Yaron > > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On = Behalf Of > > Tero Kivinen > > Sent: Monday, December 21, 2009 13:21 > > To: Yoav Nir > > Cc: ipsec@ietf.org > > Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess = (RFC4753, > > RFC5114, RFC4869, and draft-solinas-rfc4753bis-01) > > > > Yoav Nir writes: > >> If there is such an implementation, then it's not interoperating > >> with all the other implementations and should be fixed. > > > > It is following the published RFC, so why should it be fixed. I = think > > everybody agreed that making major non-interoperable change in the > > errata was not proper way of fixing the thing (there were lots of > > developers who had missed that). > > > > This whole discussion about the errata started because one = implementor > > was implementing the RFC and wanted to make sure that the y is = really > > added, and he wanted to make sure that he understood it correctly as > > that would eman that those groups cannot be made complient to FIPS > > 140-2. > > > > He had not noticed the errata. There were also other people who had > > not noticed the errata (including me). > > > > I am sure there is also people who do not follow the IPsec list and > > still do implement things (following IPsec list is not really > > requirement for implementing IPsec). > > > > I am only person in our office who regularly follow IPsec list and = all > > others just take RFCs and read them and write code based on them. I = am > > not sure if any of those people actually even know how to find > > errata... > > > > Made quick poll around the office, and found out that noboby here = had > > checked any of the errata for any of the RFCs they have worked on. > > They said they usually do check for rfc-index to see if the RFC was > > updated or obsoleted, but that is it. > > > >> If someone shipped something like that, then the only reason they > >> haven't noticed yet, is because they (1) didn't test it well = enough, > > > > Doing testing against your implementation does not detect that kind = of > > problem as everything works fine. Also for quite a lot of IPsec > > vendors the main goal is to make implementation which works with = their > > own products and the secondary goal is that it works with other > > vendor's product too. > > > >> and (2) their customers are using some other option like 1024-bit > >> MODP group (and 3DES, but that's beside the point) > > > > That is most likely true for all current IPsec implementations. > > Elliptic curves are not really used that much yet. That is the = reason > > I want to fix this problem now, not move it to future. > > > >> Anyway, making everyone add a new group "28" just so nobody needs = to > >> patch their old implementation of group "20" seems like wasted > >> effort to me. We can keep group 20, and fix the spec to prescribe > >> what everybody is doing anyway. > > > > I do not want to see the support request saying that our product = does > > not interoperate vendor X's product when using group 19 and then = later > > find out that is because the other vendor has implemented RFC4753 > > and didn't notice the errata. > > > > Also it will most likely take our customer and our support quite a > > long time before they even realize why recipient of IKE_AUTH will > > simply drop the packet because of wrong MAC. After that wasted = effort > > I know that it will come to me, and I need to explain to our = customer > > that our code is correct and the other implementation was also = correct > > when they wrote the code, but they are not correct anymore... > > > > I do not think the elliptic curves are used that much in the current > > IPsec installations, so I think we still have time to fix this = problem > > properly. > > -- > > kivinen@iki.fi > > _______________________________________________ > > 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 > > >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From sommerfeld@sun.com Mon Dec 21 11:48: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 6F4C03A692A for ; Mon, 21 Dec 2009 11:48:48 -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 IANaU9WhKPUZ for ; Mon, 21 Dec 2009 11:48:47 -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 794E43A68C3 for ; Mon, 21 Dec 2009 11:48:47 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBLJmLZr018286; Mon, 21 Dec 2009 19:48:21 GMT Received: from thunk-west.local (dhcp-umpk17-109-232.SFBay.Sun.COM [129.146.109.232]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBLJmLCd019292; Mon, 21 Dec 2009 11:48:21 -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 nBLJmL7H024794; Mon, 21 Dec 2009 11:48:21 -0800 (PST) Received: (from sommerfeld@localhost) by thunk-west.local (8.14.3+Sun/8.14.3/Submit) id nBLJmJlc024793; Mon, 21 Dec 2009 11:48:19 -0800 (PST) X-Authentication-Warning: thunk-west.local: sommerfeld set sender to sommerfeld@sun.com using -f From: Bill Sommerfeld To: Black_David@emc.com In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F474@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset="ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Dec 2009 11:48:19 -0800 Message-ID: <1261424899.24623.18.camel@thunk-west> Mime-Version: 1.0 Cc: ipsec@ietf.org, ynir@checkpoint.com, dharkins@lounge.org, kivinen@iki.fi Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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, 21 Dec 2009 19:48:48 -0000 As an additional datapoint:=20 We (Dan McDonald and I) recently extended our IKEv1 implementation to include ECDH groups 19, 20, and 21 as well as the 5114 groups, over a cryptographic library which only makes the "x" coordinate available.=20 The as-specified behavior is unimplementable using the public interface to the library we have available to us. While I have not been following this list closely, I found the errata and associated discussion. This code is not yet in a publicly available build of Solaris but we've interoperated with groups 19 and 20 with a publicly available product build of one other implementation so far (worked on the first try) and wouldn't mind a little more interoperability testing before letting it escape into the wild. I believe the errata is clear and there is enough of a critical mass of implementations doing it correctly (x value only) that it's not necessary to deprecate the existing codepoints. =20 From dharkins@lounge.org Mon Dec 21 12:53: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 9442D3A67C0 for ; Mon, 21 Dec 2009 12:53:29 -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 xKh+CHyUC1at for ; Mon, 21 Dec 2009 12:53:28 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 6EC7E3A6884 for ; Mon, 21 Dec 2009 12:53:28 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 528CA1022407E; Mon, 21 Dec 2009 12:53:12 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 21 Dec 2009 12:53:12 -0800 (PST) Message-ID: <06599b9ed7e8cde198f5da423232ac09.squirrel@www.trepanning.net> In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F474@il-ex01.ad.checkpoint.com> Date: Mon, 21 Dec 2009 12:53:12 -0800 (PST) From: "Dan Harkins" To: Black_David@emc.com 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: ynir@checkpoint.com, dharkins@lounge.org, kivinen@iki.fi, ipsec@ietf.org, black_david@emc.com Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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, 21 Dec 2009 20:53:29 -0000 Hi David, I don't believe there is an actual "running code" problem. It's just a documentation problem and the errata corrects it. The thing is, _if_ a running code problem exists the proposal to add new identifiers for the exact same ECP definitions would not fix it. Dan. On Mon, December 21, 2009 10:54 am, Black_David@emc.com wrote: > Dan, > >> If we allocate new numbers to do it right then we will, in fact, live >> forever with an ambiguous interpretation of groups 19, 20, and 21. I >> agree we should fix the problem and not live with ambiguity. The >> proposal >> to allocate new numbers doesn't seem to do that though. > > Fine, here's how to accomplish that goal - the RFC that allocates > the new group numbers should: > 1) explain why the group numbers 19, 20 and 21 are ambiguous; > 2) state that group numbers 19, 20 and 21 "SHOULD NOT be used"; > 3) instruct IANA to remove the group number registrations for > 19, 20 and 21 in a fashion that prevents reallocation; and > 4) obsolete RFC 4753. > That should avoid long term problems. > > That said, I'd like to see more reason to believe that there is > an actual "running code" problem before doing something this drastic. > If most people working with elliptic curve "just know" that only > one coordinate is used, we might not have a problem in practice. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA  01748 > +1 (508) 293-7953             FAX: +1 (508) 293-7786 > black_david@emc.com        Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Dan Harkins >> Sent: Monday, December 21, 2009 1:44 PM >> To: Yaron Sheffer >> Cc: ipsec@ietf.org; Yoav Nir; Tero Kivinen >> Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, >> RFC5114, RFC4869, and draft- >> solinas-rfc4753bis-01) >> >> >> Yaron, >> >> If we allocate new numbers to do it right then we will, in fact, live >> forever with an ambiguous interpretation of groups 19, 20, and 21. I >> agree we should fix the problem and not live with ambiguity. The >> proposal >> to allocate new numbers doesn't seem to do that though. >> >> Dan. >> >> On Mon, December 21, 2009 7:48 am, Yaron Sheffer wrote: >> > Hi Tero, >> > >> > I support your position (and disagree with Yoav). We had better fix >> this >> > problem now by allocating a few more numbers, than live forever with >> an >> > ambiguous interpretation to the numbers that everybody's using. >> > >> > Thanks, >> > Yaron >> > >> > -----Original Message----- >> > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of >> > Tero Kivinen >> > Sent: Monday, December 21, 2009 13:21 >> > To: Yoav Nir >> > Cc: ipsec@ietf.org >> > Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess >> (RFC4753, >> > RFC5114, RFC4869, and draft-solinas-rfc4753bis-01) >> > >> > Yoav Nir writes: >> >> If there is such an implementation, then it's not interoperating >> >> with all the other implementations and should be fixed. >> > >> > It is following the published RFC, so why should it be fixed. I think >> > everybody agreed that making major non-interoperable change in the >> > errata was not proper way of fixing the thing (there were lots of >> > developers who had missed that). >> > >> > This whole discussion about the errata started because one implementor >> > was implementing the RFC and wanted to make sure that the y is really >> > added, and he wanted to make sure that he understood it correctly as >> > that would eman that those groups cannot be made complient to FIPS >> > 140-2. >> > >> > He had not noticed the errata. There were also other people who had >> > not noticed the errata (including me). >> > >> > I am sure there is also people who do not follow the IPsec list and >> > still do implement things (following IPsec list is not really >> > requirement for implementing IPsec). >> > >> > I am only person in our office who regularly follow IPsec list and all >> > others just take RFCs and read them and write code based on them. I am >> > not sure if any of those people actually even know how to find >> > errata... >> > >> > Made quick poll around the office, and found out that noboby here had >> > checked any of the errata for any of the RFCs they have worked on. >> > They said they usually do check for rfc-index to see if the RFC was >> > updated or obsoleted, but that is it. >> > >> >> If someone shipped something like that, then the only reason they >> >> haven't noticed yet, is because they (1) didn't test it well enough, >> > >> > Doing testing against your implementation does not detect that kind of >> > problem as everything works fine. Also for quite a lot of IPsec >> > vendors the main goal is to make implementation which works with their >> > own products and the secondary goal is that it works with other >> > vendor's product too. >> > >> >> and (2) their customers are using some other option like 1024-bit >> >> MODP group (and 3DES, but that's beside the point) >> > >> > That is most likely true for all current IPsec implementations. >> > Elliptic curves are not really used that much yet. That is the reason >> > I want to fix this problem now, not move it to future. >> > >> >> Anyway, making everyone add a new group "28" just so nobody needs to >> >> patch their old implementation of group "20" seems like wasted >> >> effort to me. We can keep group 20, and fix the spec to prescribe >> >> what everybody is doing anyway. >> > >> > I do not want to see the support request saying that our product does >> > not interoperate vendor X's product when using group 19 and then later >> > find out that is because the other vendor has implemented RFC4753 >> > and didn't notice the errata. >> > >> > Also it will most likely take our customer and our support quite a >> > long time before they even realize why recipient of IKE_AUTH will >> > simply drop the packet because of wrong MAC. After that wasted effort >> > I know that it will come to me, and I need to explain to our customer >> > that our code is correct and the other implementation was also correct >> > when they wrote the code, but they are not correct anymore... >> > >> > I do not think the elliptic curves are used that much in the current >> > IPsec installations, so I think we still have time to fix this problem >> > properly. >> > -- >> > kivinen@iki.fi >> > _______________________________________________ >> > 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 >> > >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From Black_David@emc.com Mon Dec 21 13:03: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 6C2593A6ACB for ; Mon, 21 Dec 2009 13:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.241 X-Spam-Level: X-Spam-Status: No, score=-5.241 tagged_above=-999 required=5 tests=[AWL=1.358, 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 ejZoeX-0c-Qs for ; Mon, 21 Dec 2009 13:03:49 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 1DC793A6AB1 for ; Mon, 21 Dec 2009 13:03:48 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id nBLL3OgB021820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 16:03:24 -0500 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 21 Dec 2009 16:03:20 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.169.196]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id nBLL3KY9019616; Mon, 21 Dec 2009 16:03:20 -0500 Received: from CORPUSMX80B.corp.emc.com ([10.254.89.203]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Dec 2009 16:03:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Dec 2009 16:03:19 -0500 Message-ID: In-Reply-To: <06599b9ed7e8cde198f5da423232ac09.squirrel@www.trepanning.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01) Thread-Index: AcqCf6ToIhBNH7IQQ+isacZYKEPZrgAAPZMQ References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F474@il-ex01.ad.checkpoint.com> <06599b9ed7e8cde198f5da423232ac09.squirrel@www.trepanning.net> From: To: X-OriginalArrivalTime: 21 Dec 2009 21:03:19.0705 (UTC) FILETIME=[0607D890:01CA8281] X-EMM-EM: Active Cc: ipsec@ietf.org, ynir@checkpoint.com, kivinen@iki.fi Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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, 21 Dec 2009 21:03:51 -0000 Dan, I'm inclined to concur with Bill Sommerfeld and you that we don't have a "running code" problem, but my original email suggests what could be done to retire the old identifiers _if_ we did have such a problem. Thanks, --David > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Dan Harkins > Sent: Monday, December 21, 2009 3:53 PM > To: Black, David > Cc: ynir@checkpoint.com; dharkins@lounge.org; kivinen@iki.fi; = ipsec@ietf.org; Black, David > Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess = (RFC4753, RFC5114, RFC4869, and draft- > solinas-rfc4753bis-01) >=20 >=20 > Hi David, >=20 > I don't believe there is an actual "running code" problem. It's > just a documentation problem and the errata corrects it. >=20 > The thing is, _if_ a running code problem exists the proposal to > add new identifiers for the exact same ECP definitions would not fix > it. >=20 > Dan. >=20 > On Mon, December 21, 2009 10:54 am, Black_David@emc.com wrote: > > Dan, > > > >> If we allocate new numbers to do it right then we will, in fact, = live > >> forever with an ambiguous interpretation of groups 19, 20, and 21. = I > >> agree we should fix the problem and not live with ambiguity. The > >> proposal > >> to allocate new numbers doesn't seem to do that though. > > > > Fine, here's how to accomplish that goal - the RFC that allocates > > the new group numbers should: > > 1) explain why the group numbers 19, 20 and 21 are ambiguous; > > 2) state that group numbers 19, 20 and 21 "SHOULD NOT be used"; > > 3) instruct IANA to remove the group number registrations for > > 19, 20 and 21 in a fashion that prevents reallocation; and > > 4) obsolete RFC 4753. > > That should avoid long term problems. > > > > That said, I'd like to see more reason to believe that there is > > an actual "running code" problem before doing something this = drastic. > > If most people working with elliptic curve "just know" that only > > one coordinate is used, we might not have a problem in practice. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) = 293-7786 > > black_david@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On = Behalf > >> Of Dan Harkins > >> Sent: Monday, December 21, 2009 1:44 PM > >> To: Yaron Sheffer > >> Cc: ipsec@ietf.org; Yoav Nir; Tero Kivinen > >> Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess = (RFC4753, > >> RFC5114, RFC4869, and draft- > >> solinas-rfc4753bis-01) > >> > >> > >> Yaron, > >> > >> If we allocate new numbers to do it right then we will, in fact, = live > >> forever with an ambiguous interpretation of groups 19, 20, and 21. = I > >> agree we should fix the problem and not live with ambiguity. The > >> proposal > >> to allocate new numbers doesn't seem to do that though. > >> > >> Dan. > >> > >> On Mon, December 21, 2009 7:48 am, Yaron Sheffer wrote: > >> > Hi Tero, > >> > > >> > I support your position (and disagree with Yoav). We had better = fix > >> this > >> > problem now by allocating a few more numbers, than live forever = with > >> an > >> > ambiguous interpretation to the numbers that everybody's using. > >> > > >> > Thanks, > >> > Yaron > >> > > >> > -----Original Message----- > >> > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On = Behalf > >> Of > >> > Tero Kivinen > >> > Sent: Monday, December 21, 2009 13:21 > >> > To: Yoav Nir > >> > Cc: ipsec@ietf.org > >> > Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess > >> (RFC4753, > >> > RFC5114, RFC4869, and draft-solinas-rfc4753bis-01) > >> > > >> > Yoav Nir writes: > >> >> If there is such an implementation, then it's not interoperating > >> >> with all the other implementations and should be fixed. > >> > > >> > It is following the published RFC, so why should it be fixed. I = think > >> > everybody agreed that making major non-interoperable change in = the > >> > errata was not proper way of fixing the thing (there were lots of > >> > developers who had missed that). > >> > > >> > This whole discussion about the errata started because one = implementor > >> > was implementing the RFC and wanted to make sure that the y is = really > >> > added, and he wanted to make sure that he understood it correctly = as > >> > that would eman that those groups cannot be made complient to = FIPS > >> > 140-2. > >> > > >> > He had not noticed the errata. There were also other people who = had > >> > not noticed the errata (including me). > >> > > >> > I am sure there is also people who do not follow the IPsec list = and > >> > still do implement things (following IPsec list is not really > >> > requirement for implementing IPsec). > >> > > >> > I am only person in our office who regularly follow IPsec list = and all > >> > others just take RFCs and read them and write code based on them. = I am > >> > not sure if any of those people actually even know how to find > >> > errata... > >> > > >> > Made quick poll around the office, and found out that noboby here = had > >> > checked any of the errata for any of the RFCs they have worked = on. > >> > They said they usually do check for rfc-index to see if the RFC = was > >> > updated or obsoleted, but that is it. > >> > > >> >> If someone shipped something like that, then the only reason = they > >> >> haven't noticed yet, is because they (1) didn't test it well = enough, > >> > > >> > Doing testing against your implementation does not detect that = kind of > >> > problem as everything works fine. Also for quite a lot of IPsec > >> > vendors the main goal is to make implementation which works with = their > >> > own products and the secondary goal is that it works with other > >> > vendor's product too. > >> > > >> >> and (2) their customers are using some other option like = 1024-bit > >> >> MODP group (and 3DES, but that's beside the point) > >> > > >> > That is most likely true for all current IPsec implementations. > >> > Elliptic curves are not really used that much yet. That is the = reason > >> > I want to fix this problem now, not move it to future. > >> > > >> >> Anyway, making everyone add a new group "28" just so nobody = needs to > >> >> patch their old implementation of group "20" seems like wasted > >> >> effort to me. We can keep group 20, and fix the spec to = prescribe > >> >> what everybody is doing anyway. > >> > > >> > I do not want to see the support request saying that our product = does > >> > not interoperate vendor X's product when using group 19 and then = later > >> > find out that is because the other vendor has implemented RFC4753 > >> > and didn't notice the errata. > >> > > >> > Also it will most likely take our customer and our support quite = a > >> > long time before they even realize why recipient of IKE_AUTH will > >> > simply drop the packet because of wrong MAC. After that wasted = effort > >> > I know that it will come to me, and I need to explain to our = customer > >> > that our code is correct and the other implementation was also = correct > >> > when they wrote the code, but they are not correct anymore... > >> > > >> > I do not think the elliptic curves are used that much in the = current > >> > IPsec installations, so I think we still have time to fix this = problem > >> > properly. > >> > -- > >> > kivinen@iki.fi > >> > _______________________________________________ > >> > 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 > >> > > >> > >> > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf@checkpoint.com Mon Dec 21 14:03: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 2DF613A68EA for ; Mon, 21 Dec 2009 14:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 CvZSBC1IQhRC for ; Mon, 21 Dec 2009 14:03:15 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 64B743A67D6 for ; Mon, 21 Dec 2009 14:03:15 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBLM2uT7016667; Tue, 22 Dec 2009 00:02:56 +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, 22 Dec 2009 00:03:07 +0200 From: Yaron Sheffer To: "Black_David@emc.com" , "dharkins@lounge.org" Date: Tue, 22 Dec 2009 00:03:06 +0200 Thread-Topic: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01) Thread-Index: AcqCf6ToIhBNH7IQQ+isacZYKEPZrgAAPZMQAAIGikA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F4CB@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Yoav Nir , "kivinen@iki.fi" Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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, 21 Dec 2009 22:03:17 -0000 My understanding of Tero's mail is that *he* has such running code. Definin= g the new numbers would leave these old implementations in the lurch, but w= ould ensure unconditional interoperability for new implementations. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of B= lack_David@emc.com Sent: Monday, December 21, 2009 23:03 To: dharkins@lounge.org Cc: ipsec@ietf.org; Yoav Nir; kivinen@iki.fi Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC= 5114, RFC4869, and draft-solinas-rfc4753bis-01) Dan, I'm inclined to concur with Bill Sommerfeld and you that we don't have a "running code" problem, but my original email suggests what could be done to retire the old identifiers _if_ we did have such a problem. Thanks, --David > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of= Dan Harkins > Sent: Monday, December 21, 2009 3:53 PM > To: Black, David > Cc: ynir@checkpoint.com; dharkins@lounge.org; kivinen@iki.fi; ipsec@ietf.= org; Black, David > Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, R= FC5114, RFC4869, and draft- > solinas-rfc4753bis-01) >=20 >=20 > Hi David, >=20 > I don't believe there is an actual "running code" problem. It's > just a documentation problem and the errata corrects it. >=20 > The thing is, _if_ a running code problem exists the proposal to > add new identifiers for the exact same ECP definitions would not fix > it. >=20 > Dan. >=20 > On Mon, December 21, 2009 10:54 am, Black_David@emc.com wrote: > > Dan, > > > >> If we allocate new numbers to do it right then we will, in fact, liv= e > >> forever with an ambiguous interpretation of groups 19, 20, and 21. I > >> agree we should fix the problem and not live with ambiguity. The > >> proposal > >> to allocate new numbers doesn't seem to do that though. > > > > Fine, here's how to accomplish that goal - the RFC that allocates > > the new group numbers should: > > 1) explain why the group numbers 19, 20 and 21 are ambiguous; > > 2) state that group numbers 19, 20 and 21 "SHOULD NOT be used"; > > 3) instruct IANA to remove the group number registrations for > > 19, 20 and 21 in a fashion that prevents reallocation; and > > 4) obsolete RFC 4753. > > That should avoid long term problems. > > > > That said, I'd like to see more reason to believe that there is > > an actual "running code" problem before doing something this drastic. > > If most people working with elliptic curve "just know" that only > > one coordinate is used, we might not have a problem in practice. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293= -7786 > > black_david@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > >> Of Dan Harkins > >> Sent: Monday, December 21, 2009 1:44 PM > >> To: Yaron Sheffer > >> Cc: ipsec@ietf.org; Yoav Nir; Tero Kivinen > >> Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753= , > >> RFC5114, RFC4869, and draft- > >> solinas-rfc4753bis-01) > >> > >> > >> Yaron, > >> > >> If we allocate new numbers to do it right then we will, in fact, liv= e > >> forever with an ambiguous interpretation of groups 19, 20, and 21. I > >> agree we should fix the problem and not live with ambiguity. The > >> proposal > >> to allocate new numbers doesn't seem to do that though. > >> > >> Dan. > >> > >> On Mon, December 21, 2009 7:48 am, Yaron Sheffer wrote: > >> > Hi Tero, > >> > > >> > I support your position (and disagree with Yoav). We had better fix > >> this > >> > problem now by allocating a few more numbers, than live forever with > >> an > >> > ambiguous interpretation to the numbers that everybody's using. > >> > > >> > Thanks, > >> > Yaron > >> > > >> > -----Original Message----- > >> > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Beha= lf > >> Of > >> > Tero Kivinen > >> > Sent: Monday, December 21, 2009 13:21 > >> > To: Yoav Nir > >> > Cc: ipsec@ietf.org > >> > Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess > >> (RFC4753, > >> > RFC5114, RFC4869, and draft-solinas-rfc4753bis-01) > >> > > >> > Yoav Nir writes: > >> >> If there is such an implementation, then it's not interoperating > >> >> with all the other implementations and should be fixed. > >> > > >> > It is following the published RFC, so why should it be fixed. I thin= k > >> > everybody agreed that making major non-interoperable change in the > >> > errata was not proper way of fixing the thing (there were lots of > >> > developers who had missed that). > >> > > >> > This whole discussion about the errata started because one implement= or > >> > was implementing the RFC and wanted to make sure that the y is reall= y > >> > added, and he wanted to make sure that he understood it correctly as > >> > that would eman that those groups cannot be made complient to FIPS > >> > 140-2. > >> > > >> > He had not noticed the errata. There were also other people who had > >> > not noticed the errata (including me). > >> > > >> > I am sure there is also people who do not follow the IPsec list and > >> > still do implement things (following IPsec list is not really > >> > requirement for implementing IPsec). > >> > > >> > I am only person in our office who regularly follow IPsec list and a= ll > >> > others just take RFCs and read them and write code based on them. I = am > >> > not sure if any of those people actually even know how to find > >> > errata... > >> > > >> > Made quick poll around the office, and found out that noboby here ha= d > >> > checked any of the errata for any of the RFCs they have worked on. > >> > They said they usually do check for rfc-index to see if the RFC was > >> > updated or obsoleted, but that is it. > >> > > >> >> If someone shipped something like that, then the only reason they > >> >> haven't noticed yet, is because they (1) didn't test it well enough= , > >> > > >> > Doing testing against your implementation does not detect that kind = of > >> > problem as everything works fine. Also for quite a lot of IPsec > >> > vendors the main goal is to make implementation which works with the= ir > >> > own products and the secondary goal is that it works with other > >> > vendor's product too. > >> > > >> >> and (2) their customers are using some other option like 1024-bit > >> >> MODP group (and 3DES, but that's beside the point) > >> > > >> > That is most likely true for all current IPsec implementations. > >> > Elliptic curves are not really used that much yet. That is the reaso= n > >> > I want to fix this problem now, not move it to future. > >> > > >> >> Anyway, making everyone add a new group "28" just so nobody needs t= o > >> >> patch their old implementation of group "20" seems like wasted > >> >> effort to me. We can keep group 20, and fix the spec to prescribe > >> >> what everybody is doing anyway. > >> > > >> > I do not want to see the support request saying that our product doe= s > >> > not interoperate vendor X's product when using group 19 and then lat= er > >> > find out that is because the other vendor has implemented RFC4753 > >> > and didn't notice the errata. > >> > > >> > Also it will most likely take our customer and our support quite a > >> > long time before they even realize why recipient of IKE_AUTH will > >> > simply drop the packet because of wrong MAC. After that wasted effor= t > >> > I know that it will come to me, and I need to explain to our custome= r > >> > that our code is correct and the other implementation was also corre= ct > >> > when they wrote the code, but they are not correct anymore... > >> > > >> > I do not think the elliptic curves are used that much in the current > >> > IPsec installations, so I think we still have time to fix this probl= em > >> > properly. > >> > -- > >> > kivinen@iki.fi > >> > _______________________________________________ > >> > 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 > >> > > >> > >> > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > >=20 >=20 > _______________________________________________ > 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 Scanned by Check Point Total Security Gateway. From dharkins@lounge.org Mon Dec 21 14:42: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 831F73A63EB for ; Mon, 21 Dec 2009 14:42:07 -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 C9mapBEhOfhf for ; Mon, 21 Dec 2009 14:42:06 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 1A47C3A686C for ; Mon, 21 Dec 2009 14:42:06 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D4B733FE0142; Mon, 21 Dec 2009 14:41:49 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 21 Dec 2009 14:41:50 -0800 (PST) Message-ID: <7d5c3e9fd2fc64bdc5ae9849f28e948a.squirrel@www.trepanning.net> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F4CB@il-ex01.ad.checkpoint.co m> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F4CB@il-ex01.ad.checkpoint.com> Date: Mon, 21 Dec 2009 14:41:50 -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" , Yoav Nir , "Black_David@emc.com" , "kivinen@iki.fi" , "dharkins@lounge.org" Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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, 21 Dec 2009 22:42:07 -0000 My understanding of Tero's mail is that the code was originally written in 2001. It was modified sometime in 2007 to add "y". Then in July 2009 it was changed to not add "y". So I think there is a problem for a product shipped from sometime in 2007 to July 2009 when it interoperates with product from outside that window, either before or after. And that problem will not go away by defining new numbers. We are going to have unconditional interoperability for new implementations whether we define new numbers or just clean up the existing specification. And we are going to have some potential (but probably very small) interoperability issues for product that implemented RFC 4753 without the errata whether we define new numbers or just clean up the existing specification. So defining new numbers doesn't really change anything and it leaves some weird and inexplicably unique handling of an ECDH shared secret in the specification-- groups 19 and "n" have identical parameters but with 19 you use x||y and with "n" you just use x. I think most everyone agrees that elliptic curve groups aren't really used today so the problem can be resolved by fixing the documents. Yes, the errata introduces interoperability implications, so let's be happy that those implications are likely to be minor (and possibly non-existent). Dan. On Mon, December 21, 2009 2:03 pm, Yaron Sheffer wrote: > My understanding of Tero's mail is that *he* has such running code. > Defining the new numbers would leave these old implementations in the > lurch, but would ensure unconditional interoperability for new > implementations. > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Black_David@emc.com > Sent: Monday, December 21, 2009 23:03 > To: dharkins@lounge.org > Cc: ipsec@ietf.org; Yoav Nir; kivinen@iki.fi > Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, > RFC5114, RFC4869, and draft-solinas-rfc4753bis-01) > > Dan, > > I'm inclined to concur with Bill Sommerfeld and you that we don't have > a "running code" problem, but my original email suggests what could > be done to retire the old identifiers _if_ we did have such a problem. > > Thanks, > --David > > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Dan Harkins >> Sent: Monday, December 21, 2009 3:53 PM >> To: Black, David >> Cc: ynir@checkpoint.com; dharkins@lounge.org; kivinen@iki.fi; >> ipsec@ietf.org; Black, David >> Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, >> RFC5114, RFC4869, and draft- >> solinas-rfc4753bis-01) >> >> >> Hi David, >> >> I don't believe there is an actual "running code" problem. It's >> just a documentation problem and the errata corrects it. >> >> The thing is, _if_ a running code problem exists the proposal to >> add new identifiers for the exact same ECP definitions would not fix >> it. >> >> Dan. >> >> On Mon, December 21, 2009 10:54 am, Black_David@emc.com wrote: >> > Dan, >> > >> >> If we allocate new numbers to do it right then we will, in fact, >> live >> >> forever with an ambiguous interpretation of groups 19, 20, and 21. I >> >> agree we should fix the problem and not live with ambiguity. The >> >> proposal >> >> to allocate new numbers doesn't seem to do that though. >> > >> > Fine, here's how to accomplish that goal - the RFC that allocates >> > the new group numbers should: >> > 1) explain why the group numbers 19, 20 and 21 are ambiguous; >> > 2) state that group numbers 19, 20 and 21 "SHOULD NOT be used"; >> > 3) instruct IANA to remove the group number registrations for >> > 19, 20 and 21 in a fashion that prevents reallocation; and >> > 4) obsolete RFC 4753. >> > That should avoid long term problems. >> > >> > That said, I'd like to see more reason to believe that there is >> > an actual "running code" problem before doing something this drastic. >> > If most people working with elliptic curve "just know" that only >> > one coordinate is used, we might not have a problem in practice. >> > >> > Thanks, >> > --David >> > ---------------------------------------------------- >> > David L. Black, Distinguished Engineer >> > EMC Corporation, 176 South St., Hopkinton, MA  01748 >> > +1 (508) 293-7953             FAX: +1 (508) 293-7786 >> > black_david@emc.com        Mobile: +1 (978) 394-7754 >> > ---------------------------------------------------- >> > >> >> -----Original Message----- >> >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >> Behalf >> >> Of Dan Harkins >> >> Sent: Monday, December 21, 2009 1:44 PM >> >> To: Yaron Sheffer >> >> Cc: ipsec@ietf.org; Yoav Nir; Tero Kivinen >> >> Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess >> (RFC4753, >> >> RFC5114, RFC4869, and draft- >> >> solinas-rfc4753bis-01) >> >> >> >> >> >> Yaron, >> >> >> >> If we allocate new numbers to do it right then we will, in fact, >> live >> >> forever with an ambiguous interpretation of groups 19, 20, and 21. I >> >> agree we should fix the problem and not live with ambiguity. The >> >> proposal >> >> to allocate new numbers doesn't seem to do that though. >> >> >> >> Dan. >> >> >> >> On Mon, December 21, 2009 7:48 am, Yaron Sheffer wrote: >> >> > Hi Tero, >> >> > >> >> > I support your position (and disagree with Yoav). We had better fix >> >> this >> >> > problem now by allocating a few more numbers, than live forever >> with >> >> an >> >> > ambiguous interpretation to the numbers that everybody's using. >> >> > >> >> > Thanks, >> >> > Yaron >> >> > >> >> > -----Original Message----- >> >> > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >> Behalf >> >> Of >> >> > Tero Kivinen >> >> > Sent: Monday, December 21, 2009 13:21 >> >> > To: Yoav Nir >> >> > Cc: ipsec@ietf.org >> >> > Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess >> >> (RFC4753, >> >> > RFC5114, RFC4869, and draft-solinas-rfc4753bis-01) >> >> > >> >> > Yoav Nir writes: >> >> >> If there is such an implementation, then it's not interoperating >> >> >> with all the other implementations and should be fixed. >> >> > >> >> > It is following the published RFC, so why should it be fixed. I >> think >> >> > everybody agreed that making major non-interoperable change in the >> >> > errata was not proper way of fixing the thing (there were lots of >> >> > developers who had missed that). >> >> > >> >> > This whole discussion about the errata started because one >> implementor >> >> > was implementing the RFC and wanted to make sure that the y is >> really >> >> > added, and he wanted to make sure that he understood it correctly >> as >> >> > that would eman that those groups cannot be made complient to FIPS >> >> > 140-2. >> >> > >> >> > He had not noticed the errata. There were also other people who had >> >> > not noticed the errata (including me). >> >> > >> >> > I am sure there is also people who do not follow the IPsec list and >> >> > still do implement things (following IPsec list is not really >> >> > requirement for implementing IPsec). >> >> > >> >> > I am only person in our office who regularly follow IPsec list and >> all >> >> > others just take RFCs and read them and write code based on them. I >> am >> >> > not sure if any of those people actually even know how to find >> >> > errata... >> >> > >> >> > Made quick poll around the office, and found out that noboby here >> had >> >> > checked any of the errata for any of the RFCs they have worked on. >> >> > They said they usually do check for rfc-index to see if the RFC was >> >> > updated or obsoleted, but that is it. >> >> > >> >> >> If someone shipped something like that, then the only reason they >> >> >> haven't noticed yet, is because they (1) didn't test it well >> enough, >> >> > >> >> > Doing testing against your implementation does not detect that kind >> of >> >> > problem as everything works fine. Also for quite a lot of IPsec >> >> > vendors the main goal is to make implementation which works with >> their >> >> > own products and the secondary goal is that it works with other >> >> > vendor's product too. >> >> > >> >> >> and (2) their customers are using some other option like 1024-bit >> >> >> MODP group (and 3DES, but that's beside the point) >> >> > >> >> > That is most likely true for all current IPsec implementations. >> >> > Elliptic curves are not really used that much yet. That is the >> reason >> >> > I want to fix this problem now, not move it to future. >> >> > >> >> >> Anyway, making everyone add a new group "28" just so nobody needs >> to >> >> >> patch their old implementation of group "20" seems like wasted >> >> >> effort to me. We can keep group 20, and fix the spec to prescribe >> >> >> what everybody is doing anyway. >> >> > >> >> > I do not want to see the support request saying that our product >> does >> >> > not interoperate vendor X's product when using group 19 and then >> later >> >> > find out that is because the other vendor has implemented RFC4753 >> >> > and didn't notice the errata. >> >> > >> >> > Also it will most likely take our customer and our support quite a >> >> > long time before they even realize why recipient of IKE_AUTH will >> >> > simply drop the packet because of wrong MAC. After that wasted >> effort >> >> > I know that it will come to me, and I need to explain to our >> customer >> >> > that our code is correct and the other implementation was also >> correct >> >> > when they wrote the code, but they are not correct anymore... >> >> > >> >> > I do not think the elliptic curves are used that much in the >> current >> >> > IPsec installations, so I think we still have time to fix this >> problem >> >> > properly. >> >> > -- >> >> > kivinen@iki.fi >> >> > _______________________________________________ >> >> > 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 >> >> > >> >> >> >> >> >> _______________________________________________ >> >> IPsec mailing list >> >> IPsec@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ipsec >> > >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> > >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > From briansw@microsoft.com Mon Dec 21 15:13: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 734503A684C for ; Mon, 21 Dec 2009 15:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 QPARgxujRnEY for ; Mon, 21 Dec 2009 15:13:46 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 57EB73A682C for ; Mon, 21 Dec 2009 15:13:46 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 21 Dec 2009 15:13:30 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.0.639.20; Mon, 21 Dec 2009 15:13:30 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 21 Dec 2009 15:13:30 -0800 From: Brian Swander To: Yaron Sheffer , Tero Kivinen , "Jack Kohn" Thread-Topic: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Thread-Index: AQHKgNOP0lFfuAPsgEmxYejSkS1SVZFvL8UAgAC4P4CAAB5fgIAAHJ6w Date: Mon, 21 Dec 2009 23:13:28 +0000 Message-ID: <5E38DBF64E732C4C98512C53E1B14DDC299B54C6@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <19247.23973.271637.205639@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F42F@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F42F@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Russ Housley Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 21 Dec 2009 23:13:47 -0000 I took Russ' comments about "being in the rough" to imply that we're re-ope= ning the consensus discussion. I'm not sure why we're reopening this, sinc= e we already got consensus on this when it came up the first time. Since m= any of our internal guys are already out for the holidays, I can't see mean= ingful consensus occurring until the new year. bs -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Monday, December 21, 2009 5:25 AM To: Tero Kivinen; Jack Kohn Cc: ipsec@ietf.org; Russ Housley Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Hi Tero, Allowing the more generic, encrypted WESP (as per the current I-D) would le= t vendors experiment with different extensions. Yes, they might play with s= ome extensions that you and I find ugly or even insecure. But crippling WES= P today would mean that any such extensions are (1) limited to IKE and (2) = invisible to the middleboxes. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of T= ero Kivinen Sent: Monday, December 21, 2009 13:36 To: Jack Kohn Cc: ipsec@ietf.org; Russ Housley Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Jack Kohn writes: > Alternatively, since we seem to be > having unlimited bandwidth for discussions, we might as well argue > whether we need heuristics also or not, as there are very few people > in IPSecMe WG who feel the need for it. My personal feelings is that this inspecting ESP-NULL packets is not needed at all, as everything will be encrypted ESP anyways, so there is even no point of trying to inspect any of that ESP-NULL traffic (either using WESP or heuristics). The reason I am in favor of heuristics instead of WESP, is that heuristics requires changes only on the middleboxes, we do not need to make new extension that will affect all the end nodes supporting IPsec. Also heuristics is not harmful, as it does not harm others, it is simply internal matter inside the middlebox. I do consider WESP a bit harmful, as it adds extra bytes to all packets, and does not offer that much which cannot already be done by other means, but requires all IPsec end nodes to be updated (and also every single firewall needs to be reconfigured to allow also this new protocol number through not just proto 50 and 51). But those are my personal feelings, and I agreed that as rest of the WG seemed to want to work on WESP, that is fine, but I still wanted push the heuristics forward just as middlebox only alternative to WESP. > Strangely, its that same set of people who are against the idea of > using null NULL ciphers for WESP. Is it because by supporting > encryption in WESP we make it more generic, and thereby increasing > the chances of its widespread implementation as against the other > proposal (heuristics)? Using non-NULL ciphers for WESP takes it out from its intended use, and unless there is some more extensions done for WESP (which there currently isn't), there is no point of doing that, as using WESP for encrypted ESP we are just wasting bytes for extra WESP header. Meaning that before we see any extensions that would require WESP and encrypted ESP I do not think there is any point of sending encrypted ESP traffic using WESP.=20 And yes, making WESP more generic would mean that I would perhaps some day need to implement it (which I do not want to) if there is too much customer demand for it in the future. --=20 kivinen@iki.fi _______________________________________________ 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 From manav.bhatia@alcatel-lucent.com Mon Dec 21 16:41: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 485173A688A for ; Mon, 21 Dec 2009 16:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 JVwsWM+uLBlM for ; Mon, 21 Dec 2009 16:41:38 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 234CE3A679C for ; Mon, 21 Dec 2009 16:41:37 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id nBM0fHF1022493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Dec 2009 18:41:19 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/ICT) with ESMTP id nBM0fEXh032313 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Dec 2009 06:11:15 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 22 Dec 2009 06:11:14 +0530 From: "Bhatia, Manav (Manav)" To: Tero Kivinen Date: Tue, 22 Dec 2009 06:11:13 +0530 Thread-Topic: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Thread-Index: AcqCMdYXhyU68wcETmi+Z8YtiWZTTgAavAPg Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB332CF55@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20091217023458.GA23757@mactavish> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> <19242.7719.715250.335841@fireball.kivinen.iki.fi> <20091219175022.B8BCC9A472F@odin.smetech.net> <19247.23973.271637.205639@fireball.kivinen.iki.fi> In-Reply-To: <19247.23973.271637.205639@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 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Cc: "ipsec@ietf.org" , Russ Housley Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 22 Dec 2009 00:41:39 -0000 Tero, > The reason I am in favor of heuristics instead of WESP, is that > heuristics requires changes only on the middleboxes, we do not need to > make new extension that will affect all the end nodes supporting > IPsec. >=20 > Also heuristics is not harmful, as it does not harm others, it is > simply internal matter inside the middlebox. I do consider WESP a bit > harmful, as it adds extra bytes to all packets, and does not offer I think heuristics is a good solution, but contrary to your thinking I don'= t think it's a panacea to all our problems. Heuristic solution is not an ex= clusive alternative, but a complement to the deterministic approach in prov= iding an interim solution using a subset of devices that are capable and wi= lling to consume the heuristics overheads. Few of us, long time back, had d= one some work on the issues with heuristics and I post a summary of what we= had discussed. Claiming that heuristics requires only modification of the network entities= is somewhat misleading, as the nature of the modifications is very differe= nt. Such changes would imply a radical change in architectures of devices t= hat currently do not have the capability to run complex code with the corre= sponding memory requirements. Furthermore, those changes are ongoing as heu= ristics has to continuously change to accommodate changing traffic patterns= and algorithms (e.g. leveraging new, future cryptographic algorithms for E= SP, which have different IV/ICV length requirements). From the point of vie= w of testing and compliance, such complexity is in itself an issue which co= mpounded with the potential for incorrect determination is perhaps a deploy= ment blocker. =20 Heuristics are applicable to only some (not all) stateful devices. Even wit= hin stateful devices, not all of them are expected to be able to handle heu= ristics, particularly as they grow to handle 100K-400K flows. Heuristics will NOT work for high speed, high aggregation, stateless device= s. These devices provide services such as stateless statistics, QoS marking= s or stateless firewalls (which provide basic access control functions in f= iltering unwanted network traffic). Stateless devices by definition do not = maintain dynamic, per-flow state (although they typically have fixed, stati= c rules) and hence employing any heuristics-based solution would require a = radical architecture change for these devices. This would be in the form of= incorporating state into the device or the ability to execute the heuristi= cs engine at line rate for every packet, which would require a pure hardwar= e-based solution.=20 Heuristics are not a good match for short-lived flows. Measurements of Ente= rprise traffic patterns reveal that a significant portion is represented by= UDP and short-lived flows. UDP traffic has been measured at 25% of the tot= al. The concept of "flows" which heuristics uses to amortize the initial co= st of parsing and analysis is not as applicable here. Handling such cases (= e.g., VoIP) via heuristics is very costly and may end up becoming the bottl= eneck for the services offered. The heuristics draft itself concedes that U= DP checks will be more expensive, as it does not contain immutable fields (= such as those available in TCP flows) that can be used as part of the heuri= stics algorithm to increase the probability of drawing the correct conclusi= ons.=20 Heuristics requires a proper cache flushing mechanism. Heuristics based ap= proach recommends executing the heuristics engine in software and subsequen= tly caching the results in hardware by using the packet attributes (e.g. IP= addresses, SPI). However, it does not provide a clean solution for cache m= anagement and specifically eviction of a given cache entry, if and when a g= iven flow is no longer needed. The proposed approaches for cache management= recommend simple Least Recently Used (LRU) type algorithms, which will unn= ecessarily flush legitimate cache entries for legitimate, but intermittent = traffic patterns or an approach of binding TCP flow analysis with the appro= priate cache entry, which may work for stateful protocols, but is ineffecti= ve for stateless protocols such as UDP. Additionally, the engine will have = no idea about short and long-lived security associations and may prematurel= y remove cache entries, even though the SA is still active. This will requi= re further iterations using the heuristics engine, when a subsequent packet= for that security association is seen. Furthermore, the cache will likely = be of a finite size and any of the above approaches will cause a 'cache tra= sh' resulting in performance degradation, as well as unnecessary CPU consum= ption in re-execution of the heuristics engine. This provides a new DoS att= ack vector for potential adversaries by forcing cache add/remove harmonics = by simply replaying packets at well-chosen intervals. It is hard or costly to handle quick route changes via heuristics. Heuristi= cs works best in the presence of long-lived TCP sessions. "Long-lived" must= apply both to the session at the end-nodes involved as well as to how it i= s being routed throughout the network. Even if the former is true, constant= routing changes render these sessions short-lived from the point of view o= f heuristics, as the new devices involved must re-run and relearn the flow = based on heuristics. Route changes invalidate the amortization of building = heuristic state Heuristics can lead to more latencies in error recovery and indeterminate r= esults. The heuristics draft discusses the possibility of several potential= false positives in connection with DPI engine results. Confusing failure a= nd garbage results can lead to slow error recovery. As pointed out by the h= euristics draft, lack of explicit knowledge of the Next Protocol may requir= e more passes, hence more latency and state to be built.=20 Cheers, Manav= From manav.bhatia@alcatel-lucent.com Mon Dec 21 16:46: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 C099D3A67A5 for ; Mon, 21 Dec 2009 16:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 DJyLsHG3qrTF for ; Mon, 21 Dec 2009 16:46:27 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id AE6223A6965 for ; Mon, 21 Dec 2009 16:46:27 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id nBM0k8c0011681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Dec 2009 18:46:10 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/ICT) with ESMTP id nBM0k6NL015566 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Dec 2009 06:16:07 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 22 Dec 2009 06:16:06 +0530 From: "Bhatia, Manav (Manav)" To: Brian Swander Date: Tue, 22 Dec 2009 06:16:05 +0530 Thread-Topic: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Thread-Index: AQHKgNOP0lFfuAPsgEmxYejSkS1SVZFvL8UAgAC4P4CAAB5fgIAAHJ6wgAAbLOA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB332CF57@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <19247.23973.271637.205639@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F42F@il-ex01.ad.checkpoint.com> <5E38DBF64E732C4C98512C53E1B14DDC299B54C6@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <5E38DBF64E732C4C98512C53E1B14DDC299B54C6@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.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 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 Cc: "ipsec@ietf.org" , Russ Housley Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 22 Dec 2009 00:46:28 -0000 +1=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Brian Swander > Sent: Tuesday, December 22, 2009 4.43 AM > To: Yaron Sheffer; Tero Kivinen; Jack Kohn > Cc: ipsec@ietf.org; Russ Housley > Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility >=20 > I took Russ' comments about "being in the rough" to imply=20 > that we're re-opening the consensus discussion. I'm not sure=20 > why we're reopening this, since we already got consensus on=20 > this when it came up the first time. Since many of our=20 > internal guys are already out for the holidays, I can't see=20 > meaningful consensus occurring until the new year. >=20 > bs >=20 >=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Yaron Sheffer > Sent: Monday, December 21, 2009 5:25 AM > To: Tero Kivinen; Jack Kohn > Cc: ipsec@ietf.org; Russ Housley > Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility >=20 > Hi Tero, >=20 > Allowing the more generic, encrypted WESP (as per the current=20 > I-D) would let vendors experiment with different extensions.=20 > Yes, they might play with some extensions that you and I find=20 > ugly or even insecure. But crippling WESP today would mean=20 > that any such extensions are (1) limited to IKE and (2)=20 > invisible to the middleboxes. >=20 > Thanks, > Yaron >=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Tero Kivinen > Sent: Monday, December 21, 2009 13:36 > To: Jack Kohn > Cc: ipsec@ietf.org; Russ Housley > Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility >=20 > Jack Kohn writes: > > Alternatively, since we seem to be > > having unlimited bandwidth for discussions, we might as well argue > > whether we need heuristics also or not, as there are very few people > > in IPSecMe WG who feel the need for it. >=20 > My personal feelings is that this inspecting ESP-NULL packets is not > needed at all, as everything will be encrypted ESP anyways, so there > is even no point of trying to inspect any of that ESP-NULL traffic > (either using WESP or heuristics). >=20 > The reason I am in favor of heuristics instead of WESP, is that > heuristics requires changes only on the middleboxes, we do not need to > make new extension that will affect all the end nodes supporting > IPsec. >=20 > Also heuristics is not harmful, as it does not harm others, it is > simply internal matter inside the middlebox. I do consider WESP a bit > harmful, as it adds extra bytes to all packets, and does not offer > that much which cannot already be done by other means, but requires > all IPsec end nodes to be updated (and also every single firewall > needs to be reconfigured to allow also this new protocol number > through not just proto 50 and 51). >=20 > But those are my personal feelings, and I agreed that as rest of the > WG seemed to want to work on WESP, that is fine, but I still wanted > push the heuristics forward just as middlebox only alternative to > WESP. >=20 > > Strangely, its that same set of people who are against the idea of > > using null NULL ciphers for WESP. Is it because by supporting > > encryption in WESP we make it more generic, and thereby increasing > > the chances of its widespread implementation as against the other > > proposal (heuristics)? >=20 > Using non-NULL ciphers for WESP takes it out from its intended use, > and unless there is some more extensions done for WESP (which there > currently isn't), there is no point of doing that, as using WESP for > encrypted ESP we are just wasting bytes for extra WESP header. >=20 > Meaning that before we see any extensions that would require WESP and > encrypted ESP I do not think there is any point of sending encrypted > ESP traffic using WESP.=20 >=20 > And yes, making WESP more generic would mean that I would perhaps some > day need to implement it (which I do not want to) if there is too much > customer demand for it in the future. > --=20 > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > = From kohn.jack@gmail.com Mon Dec 21 19:39: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 3F4E13A6959 for ; Mon, 21 Dec 2009 19:39:13 -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 XNQXkcQ5i8kr for ; Mon, 21 Dec 2009 19:39:12 -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 3FC203A6822 for ; Mon, 21 Dec 2009 19:39:12 -0800 (PST) Received: by ywh15 with SMTP id 15so6080270ywh.5 for ; Mon, 21 Dec 2009 19:38:53 -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=bmRmFfm+KMu/Nm7PdnuxSmn/bDS1kPD7WSDiqHZaWHk=; b=UTwVPXzXWd2Pirvzz0/Vtwn0Mp9LpzMYRQXG621u6AQGAfsQob0sLgcRxyNodKbhAL Pg2qh5ugAF5Df7opMSmOqvdbwV/kRtFTFZs2lp/tzpYYAiBOQdZ6YkNcmb5MpQpxTikK 7IMrL4QEN8ms6KMuDRdc2TBXbBkaTieg7O9Es= 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=G7Ht2Vb6CBz1pkNgDdnZT6RRjvj9iQSUrn2vmIuJl92ulRoLcvz2yMtH8KK/CvAC5a KKIwO3z1RejIlEF1PQ6SDq5p685jBwvSyhmJOQ/PHa8uHfbPLIrcMMyHrE3dFbgGWkmM SDUGbDUpqePxOPeNXSQA0p9TXCr5/ocjQ4TzA= MIME-Version: 1.0 Received: by 10.91.126.11 with SMTP id d11mr3145424agn.24.1261453131444; Mon, 21 Dec 2009 19:38:51 -0800 (PST) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F42F@il-ex01.ad.checkpoint.com> References: <19247.23973.271637.205639@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F42F@il-ex01.ad.checkpoint.com> Date: Tue, 22 Dec 2009 09:08:51 +0530 Message-ID: From: Jack Kohn To: Yaron Sheffer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" , Russ Housley , Tero Kivinen Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 22 Dec 2009 03:39:13 -0000 And in case there are no extensions for using WESP with encrypted traffic, then we will continue to use WESP for ESP-NULL only. Jack On Mon, Dec 21, 2009 at 6:54 PM, Yaron Sheffer wrot= e: > Hi Tero, > > Allowing the more generic, encrypted WESP (as per the current I-D) would = let vendors experiment with different extensions. Yes, they might play with= some extensions that you and I find ugly or even insecure. But crippling W= ESP today would mean that any such extensions are (1) limited to IKE and (2= ) invisible to the middleboxes. > > Thanks, > =A0 =A0 =A0 =A0Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of= Tero Kivinen > Sent: Monday, December 21, 2009 13:36 > To: Jack Kohn > Cc: ipsec@ietf.org; Russ Housley > Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility > > Jack Kohn writes: >> Alternatively, since we seem to be >> having unlimited bandwidth for discussions, we might as well argue >> whether we need heuristics also or not, as there are very few people >> in IPSecMe WG who feel the need for it. > > My personal feelings is that this inspecting ESP-NULL packets is not > needed at all, as everything will be encrypted ESP anyways, so there > is even no point of trying to inspect any of that ESP-NULL traffic > (either using WESP or heuristics). > > The reason I am in favor of heuristics instead of WESP, is that > heuristics requires changes only on the middleboxes, we do not need to > make new extension that will affect all the end nodes supporting > IPsec. > > Also heuristics is not harmful, as it does not harm others, it is > simply internal matter inside the middlebox. I do consider WESP a bit > harmful, as it adds extra bytes to all packets, and does not offer > that much which cannot already be done by other means, but requires > all IPsec end nodes to be updated (and also every single firewall > needs to be reconfigured to allow also this new protocol number > through not just proto 50 and 51). > > But those are my personal feelings, and I agreed that as rest of the > WG seemed to want to work on WESP, that is fine, but I still wanted > push the heuristics forward just as middlebox only alternative to > WESP. > >> Strangely, its that same set of people who are against the idea of >> using null NULL ciphers for WESP. Is it because by supporting >> encryption in WESP we make it more generic, and thereby increasing >> the chances of its widespread implementation as against the other >> proposal (heuristics)? > > Using non-NULL ciphers for WESP takes it out from its intended use, > and unless there is some more extensions done for WESP (which there > currently isn't), there is no point of doing that, as using WESP for > encrypted ESP we are just wasting bytes for extra WESP header. > > Meaning that before we see any extensions that would require WESP and > encrypted ESP I do not think there is any point of sending encrypted > ESP traffic using WESP. > > And yes, making WESP more generic would mean that I would perhaps some > day need to implement it (which I do not want to) if there is too much > customer demand for it in the future. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > From ynir@checkpoint.com Mon Dec 21 23:46: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 59D9A3A67C0 for ; Mon, 21 Dec 2009 23:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 d0w8-MirNJgq for ; Mon, 21 Dec 2009 23:46:33 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 23C923A6784 for ; Mon, 21 Dec 2009 23:46:33 -0800 (PST) X-CheckPoint: {4B30782F-10005-14201DC2-FFFF} Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 3EED729C009; Tue, 22 Dec 2009 09:46:16 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1866B29C002; Tue, 22 Dec 2009 09:46:16 +0200 (IST) X-CheckPoint: {4B30782E-10000-14201DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBM7kFT7004242; Tue, 22 Dec 2009 09:46: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; Tue, 22 Dec 2009 09:46:27 +0200 From: Yoav Nir To: "" Date: Tue, 22 Dec 2009 09:46:12 +0200 Thread-Topic: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01) Thread-Index: AcqC2t2y75n7FCKOSw6tYgu8xzkA5Q== Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F474@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" , "dharkins@lounge.org" , "kivinen@iki.fi" Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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, 22 Dec 2009 07:46:34 -0000 On Dec 21, 2009, at 8:54 PM, wrote: > Dan, >=20 >> If we allocate new numbers to do it right then we will, in fact, live >> forever with an ambiguous interpretation of groups 19, 20, and 21. I >> agree we should fix the problem and not live with ambiguity. The proposa= l >> to allocate new numbers doesn't seem to do that though. >=20 > Fine, here's how to accomplish that goal - the RFC that allocates > the new group numbers should: > 1) explain why the group numbers 19, 20 and 21 are ambiguous; > 2) state that group numbers 19, 20 and 21 "SHOULD NOT be used"; > 3) instruct IANA to remove the group number registrations for > 19, 20 and 21 in a fashion that prevents reallocation; and > 4) obsolete RFC 4753. > That should avoid long term problems. No, this will solve the problem in the long term. In the short term, there = are things like Windows 7 out there that already use group 19 and group 20 = (and they only send x). For the vendor to follow your obsolescence plan, th= ey would need to have a patch that replaces the use of 19 and 20 with, say,= groups 27 and 28. That would mean breaking interoperability with the old u= npatched Windows 7, plus all other implementations out there (there is even= less running code for groups 19 and 20). So a vendor would have to support= both group 19 (wrong or right interpretation) and group 27 (hopefully only= one right interpretation)=20 > That said, I'd like to see more reason to believe that there is > an actual "running code" problem before doing something this drastic. > If most people working with elliptic curve "just know" that only > one coordinate is used, we might not have a problem in practice. Well, both Tero's company and mine have people who follow this list, and ye= t both companies made this mistake. "People just knowing" failed". Luckily = for us, this running code was not yet released when they discovered the iss= ue, so we don't have a support/upgrade problem. The real issue is with runn= ing code that's both broken and out there. Unfortunately, we can't rely on = all developers on ECDH code being on this list. The mitigating factor is th= at those who implement by using OpenSSL code will run into the fact that Op= enSSL APIs only give you the x coordinate, unless you supplement their code= with your own function that gets the y coordinate. >=20 > Thanks, > --David From kivinen@iki.fi Tue Dec 22 02:08: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 B9E643A67A7 for ; Tue, 22 Dec 2009 02:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 IGULYC92fnyn for ; Tue, 22 Dec 2009 02:08:22 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 6C5C33A6803 for ; Tue, 22 Dec 2009 02:08: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 nBMA81Fi003877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Dec 2009 12:08:01 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBMA81vL029947; Tue, 22 Dec 2009 12:08: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: <19248.39553.319782.132148@fireball.kivinen.iki.fi> Date: Tue, 22 Dec 2009 12:08:01 +0200 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: References: <19243.32427.247190.77844@fireball.kivinen.iki.fi> <72a888732545c5066f493228c416d286.squirrel@www.trepanning.net> <19247.25734.318539.699760@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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, 22 Dec 2009 10:08:23 -0000 Dan Harkins writes: > No, you won't get "no proposal chosen" or "invalid KE" payload. > What you'll get, if you "guess" wrong, is garbage IKEv2 messages > because a different representation of the shared secret will be fed > into the prf that generates the keying material. That will not be > diagnosable. Things just won't work and the customer will get really > mad. And if developers aren't reading errata (as you claim) then I > seriously doubt that field engineers and support do either. So we're > looking at an RMA of a perfectly good piece of equipment. If we allocate new numbers and change to use them, then you DO get no proposal chosen and invalid IKE payloads. What you explaining there is what happens now when someone tries to use those ecp groups between two implementations which do not agree on errata or not. > Your suggested fix does not actually fix the existing problem, it > just makes an unambiguous way to negotiate these groups using different > numbers. The same ambiguity will still exist for 19, 20, and 21. Yes, but all of those groups are marked "OBSOLETED" or "Reserved (was xxx)" in the iana-registry, and the RFC4753 is also osboleted by the new rfc. Then I would also propose all implementations out there that when they change from numbers 19, 20, 21, 25, 26 to new numbers, they will either remove the old numbers completely (as there is no way to get interoperability with them), or at least add warnings to them saying that those groups might not be interoperable. > I think it would be better to fix the problem. You mentioned to Yoav > that EC groups are not used that much currently. So this is an opportune > time to fix the problem! EC groups are not used right now, but the implementations we have put out in the last 2 years are going to be out there for long time, and all of those will use the wrong version. I want to make sure that new versions we push out will make fail cleanly (i.e. with no proposal chosen or invalid ke payload) when talking to those old versions. This happens, because the new versions do not support groups 19, 20, 21, 25, 26 at all, but only the new ones, and with those new numbers there is no ambiguity how they are processed. -- kivinen@iki.fi From kivinen@iki.fi Tue Dec 22 02:13: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 6A5703A6B1E for ; Tue, 22 Dec 2009 02:13:27 -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 253o6rws5CrR for ; Tue, 22 Dec 2009 02:13:26 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3B33A6AB5 for ; Tue, 22 Dec 2009 02:13:25 -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 nBMAD1iR001976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Dec 2009 12:13:01 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBMAD0Z7007144; Tue, 22 Dec 2009 12:13: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: <19248.39852.369259.276885@fireball.kivinen.iki.fi> Date: Tue, 22 Dec 2009 12:13:00 +0200 From: Tero Kivinen To: In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F474@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min Cc: ipsec@ietf.org, ynir@checkpoint.com, dharkins@lounge.org Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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, 22 Dec 2009 10:13:27 -0000 Black_David@emc.com writes: > > If we allocate new numbers to do it right then we will, in fact, live > > forever with an ambiguous interpretation of groups 19, 20, and 21. I > > agree we should fix the problem and not live with ambiguity. The proposal > > to allocate new numbers doesn't seem to do that though. > > Fine, here's how to accomplish that goal - the RFC that allocates > the new group numbers should: > 1) explain why the group numbers 19, 20 and 21 are ambiguous; > 2) state that group numbers 19, 20 and 21 "SHOULD NOT be used"; > 3) instruct IANA to remove the group number registrations for > 19, 20 and 21 in a fashion that prevents reallocation; and > 4) obsolete RFC 4753. > That should avoid long term problems. Yes. Exactly that was what I was trying to say, except same thing also needs to be done for RFC5114, as it refers to RFC4753, and perhaps also RFC4869 as it also refers to RFC4753. > That said, I'd like to see more reason to believe that there is > an actual "running code" problem before doing something this drastic. As I said QuickSec versions 4.4 - 5.0 (i.e. QuickSec versions released between 2007-2009) do include original RFC4753 code, the person who fixed our code to support RFC4753 didn't notice the errata... As our OEM toolkit is used quite widely I think there are quite a lot of existing products doing things without errata. Also most of those people (our customers) are not reading this list. > If most people working with elliptic curve "just know" that only > one coordinate is used, we might not have a problem in practice. -- kivinen@iki.fi From kivinen@iki.fi Tue Dec 22 02:23: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 77E6B3A685A for ; Tue, 22 Dec 2009 02:23:08 -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 F8+-+pR-LE-K for ; Tue, 22 Dec 2009 02:23:06 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E41F23A69BD for ; Tue, 22 Dec 2009 02:23:03 -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 nBMAMexN028234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Dec 2009 12:22:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBMAMeAO001248; Tue, 22 Dec 2009 12:22: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: <19248.40432.222096.933388@fireball.kivinen.iki.fi> Date: Tue, 22 Dec 2009 12:22:40 +0200 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <7d5c3e9fd2fc64bdc5ae9849f28e948a.squirrel@www.trepanning.net> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F4CB@il-ex01.ad.checkpoint.com> <7d5c3e9fd2fc64bdc5ae9849f28e948a.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 7 min Cc: "ipsec@ietf.org" , Yoav Nir , "Black_David@emc.com" Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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, 22 Dec 2009 10:23:08 -0000 Dan Harkins writes: > My understanding of Tero's mail is that the code was originally written > in 2001. It was modified sometime in 2007 to add "y". Then in July 2009 > it was changed to not add "y". So I think there is a problem for a product > shipped from sometime in 2007 to July 2009 when it interoperates with > product from outside that window, either before or after. Yes. > And that problem will not go away by defining new numbers. It does, as if none of the new versions include support for those groups at all using those numbers (as they are obsoleted), then those old unpatched versions are getting policy mismatch instead of MAC failures, and they can fix their policy to use MODP groups. > We are going to have unconditional interoperability for new > implementations whether we define new numbers or just clean up the > existing specification. No, as every time one of those new implementations talks to old implementation following RFC4753 without errata, there will be MAC failure which is hard to diagnostic. If new version does not ever include old ECP group numbers in their SA proposals, there is no way new versions and old versions could even try to negotiate ECP groups, thus they would fall back to modp groups, or at least get people to ask correct question, i.e. why the new version removed ECP groups 19, 20, 21, 25, 26 and then vendor would answer: "because they are obsoleted and replaced with groups n .. n+m". > I think most everyone agrees that elliptic curve groups aren't really > used today so the problem can be resolved by fixing the documents. Yes, > the errata introduces interoperability implications, so let's be happy > that those implications are likely to be minor (and possibly non-existent). EC groups are not used, but the implementations are already out there, and some day someone might actually enable them in their policy, and if we do not allocate new numbers we are going to get those problems in the future. Those products using QuickSec OEM toolkit 4.4 - 5.0 are not going to disappear, and those products will nicely interoperate with each other. We can provide them fix to the old products, but that does not mean our customers will actually put that to their products, and some of those products (ADLS boxes etc), might be something they will not provide updates at all. -- kivinen@iki.fi From Faisal.Masood@caviumnetworks.com Mon Dec 21 16:11: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 353003A68B6 for ; Mon, 21 Dec 2009 16:11:21 -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 5mXKICgrWp5q for ; Mon, 21 Dec 2009 16:11:19 -0800 (PST) Received: from mail3.caviumnetworks.com (mail3.caviumnetworks.com [12.108.191.235]) by core3.amsl.com (Postfix) with ESMTP id 5F9283A63C9 for ; Mon, 21 Dec 2009 16:11:17 -0800 (PST) Received: from caexch01.caveonetworks.com (Not Verified[192.168.16.9]) by mail3.caviumnetworks.com with MailMarshal (v6, 5, 4, 7535) id ; Mon, 21 Dec 2009 16:08:25 -0800 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: Mon, 21 Dec 2009 16:08:19 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WESP encryption support Thread-Index: Acp27Zo6vitmSDQXT8udRIdz1VThagLtQZYQ From: "Masood, Faisal" To: X-Mailman-Approved-At: Tue, 22 Dec 2009 08:04:42 -0800 Subject: [IPsec] WESP encryption support 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, 22 Dec 2009 00:32:06 -0000 The support of WESP encryption, as it currently stands in the draft, is important and we would like to discuss this in detail but many of our core team members are away for the holidays. We will reply with more details after these holidays. Regards, -Faisal From paul.hoffman@vpnc.org Tue Dec 22 10:54: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 719CE3A68A5 for ; Tue, 22 Dec 2009 10:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.632 X-Spam-Level: X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 leOlBGMTWoMk for ; Tue, 22 Dec 2009 10:54:53 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 895473A6833 for ; Tue, 22 Dec 2009 10:54:53 -0800 (PST) Received: from [192.168.1.6] (pool-98-109-111-70.nwrknj.fios.verizon.net [98.109.111.70]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBMIqQbC001532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Dec 2009 11:52:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19243.32427.247190.77844@fireball.kivinen.iki.fi> References: <19243.32427.247190.77844@fireball.kivinen.iki.fi> Date: Tue, 22 Dec 2009 13:52:24 -0500 To: Tero Kivinen , ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-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, 22 Dec 2009 18:54:54 -0000 First off, thank you for bringing the topic to the WG. As the Designated Expert, you are certainly allowed to make decisions without asking, so it is extra nice that you ask on decisions that might be controversial. On this particular topic, I would note that RFC 4753 is Informational RFC, not a standards-track document. Thus, I would think that desires of the authors of the RFC should have a heavier influence than the rest of us, although our input might be important inputs to them (and maybe to the Designated Expert). Maybe we should put the issue aside until we hear from them, which could be after the holiday. --Paul Hoffman, Director --VPN Consortium From vnktshsriram@gmail.com Wed Dec 23 00:22: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 8B45F3A69A0 for ; Wed, 23 Dec 2009 00:22:15 -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 ixJTmUxfvnSP for ; Wed, 23 Dec 2009 00:22:14 -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 A8E843A6807 for ; Wed, 23 Dec 2009 00:22:14 -0800 (PST) Received: by pwi20 with SMTP id 20so4659370pwi.29 for ; Wed, 23 Dec 2009 00:21:55 -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:content-type :content-transfer-encoding; bh=j8Ui+kUIzS1fM32JwafYqGSS4Beek+G8X+Fv9yFr4rE=; b=o7T7vdd9R3D/d4lbMbsGJl9JbAkGuQhKBGbPzHzDZzUH9C1FCrx7jaLH6VW09EnODs v4FAkCEbTEKEsnVw/SOMeXTkcDTo3OT+MCKBHqtVc23+abl+UTwY3C2qFPnardJQdfcE nDlmfyuo01KKBIqpgcm9+fC2vqnNN3HKNfd7g= 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 :content-type:content-transfer-encoding; b=mKMo/VTZnnMJP0N/smRr1rkUzNHkAPDkvh9sIwzOt/nbxrtyc6DfSwm+4Y8nKIyatM jNeUQLBQp3Wm1+ZFtfP87cz75gGg44UCFtNyioQ3nYReBPzL9OUUmFdA4JwIKoC+IIOZ b9Geoq6R4QY5lz5DJ6NmeLenMOU1+wEq9zxFE= MIME-Version: 1.0 Received: by 10.115.67.8 with SMTP id u8mr6644185wak.190.1261556515317; Wed, 23 Dec 2009 00:21:55 -0800 (PST) In-Reply-To: <20091130151502.7EAAF28C122@core3.amsl.com> References: <20091130151502.7EAAF28C122@core3.amsl.com> Date: Wed, 23 Dec 2009 13:51:55 +0530 Message-ID: From: Venkatesh Sriram To: ipsec@ietf.org, Tero Kivinen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [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: Wed, 23 Dec 2009 08:22:15 -0000 Hi, I was going through the draft and i have a doubt. Section 8.1 of the draft describes the ESP-NULL packet format. While doing so, it also shows the IV as optional. Now, my question is, that isnt IV for NULL encryption (integrity only) always 0? If thats the case then why are we showing the IV in that packet? Sriram On Mon, Nov 30, 2009 at 8:45 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IP Security Maintenance and Extensions W= orking Group of the IETF. > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Heuristics for Detecting ESP-N= ULL packets > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : T. Kivinen, D. McDonald > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-ipsecme-esp-null-heur= istics-03.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 36 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 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. =A0These 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. =A0Use 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-heuristic= s-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. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > From kivinen@iki.fi Wed Dec 23 01:55: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 1E87E3A68E9 for ; Wed, 23 Dec 2009 01:55:59 -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 EZv7vIS0TKMW for ; Wed, 23 Dec 2009 01:55:58 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C4EEF3A695C for ; Wed, 23 Dec 2009 01:55: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 nBN9tY7d023061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Dec 2009 11:55:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBN9tXBv018450; Wed, 23 Dec 2009 11:55: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: <19249.59669.378950.176465@fireball.kivinen.iki.fi> Date: Wed, 23 Dec 2009 11:55:33 +0200 From: Tero Kivinen To: Venkatesh Sriram In-Reply-To: References: <20091130151502.7EAAF28C122@core3.amsl.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: ipsec@ietf.org Subject: Re: [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: Wed, 23 Dec 2009 09:55:59 -0000 Venkatesh Sriram writes: > Section 8.1 of the draft describes the ESP-NULL packet format. While > doing so, it also shows the IV as optional. Now, my question is, that > isnt IV for NULL encryption (integrity only) always 0? No. In most cases the IV length is 0, but there is AUTH_AES_*_GMAC authentication algorithms where it is 8 bytes, as explained in the draft. > If thats the case then why are we showing the IV in that packet? Because it can be there for those ESP_NULL_AUTH_AES_GMAC algorithms (RFC4543). -- kivinen@iki.fi From A.Hoenes@TR-Sys.de Wed Dec 23 01:56: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 32B363A68E9 for ; Wed, 23 Dec 2009 01:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.95 X-Spam-Level: ** X-Spam-Status: No, score=2.95 tagged_above=-999 required=5 tests=[AWL=-0.715, BAYES_40=-0.185, 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 2efe9k-UWa7N for ; Wed, 23 Dec 2009 01:56:52 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id A034F3A690C for ; Wed, 23 Dec 2009 01:56:48 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA061682189; Wed, 23 Dec 2009 10:56:29 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id KAA05565; Wed, 23 Dec 2009 10:56:27 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200912230956.KAA05565@TR-Sys.de> To: ipsec@ietf.org Date: Wed, 23 Dec 2009 10:56:27 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: [IPsec] draft-kato-ipsec-camellia-cmac96and128-05 follow-up 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, 23 Dec 2009 09:56:53 -0000 I've followed up to the revised Camellia CMAC for IPsec draft, draft-kato-ipsec-camellia-cmac96and128-05. Thanks to the authors for their efforts and cooperation. I once more read the entire document, but did not verify the test cases. All my previous textual concerns have been addressed thoroughly. In the later sections, which hadn't been so much in my focus previously, I saw a very few more nits, but these should not need a draft update at this stage. I have reported the details to the authors, but maybe that can even be left to the RFC Editor. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | 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 vnktshsriram@gmail.com Wed Dec 23 06:12:31 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 5CE253A68DA for ; Wed, 23 Dec 2009 06:12:31 -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 LbHiMX4UlY4d for ; Wed, 23 Dec 2009 06:12:28 -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 39BCD3A684E for ; Wed, 23 Dec 2009 06:12:28 -0800 (PST) Received: by pwi20 with SMTP id 20so4817625pwi.29 for ; Wed, 23 Dec 2009 06:12:08 -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=9QAXgInqCTVQs5F/VwCY8fVjuWFTx8uM/fux9GvcLHY=; b=gApA64mRoeKacbMnWRxT6t0W9ay3y9H8BPES7rImX6IN4CB3iTt3Zqr6ZuTuZpHRny 3qm0xWNY5OhyIYZKiZsv7KiDTWI67J1/C3DsaCTH4o6+m2+74uy1pZpEeJumcIecXJhk Px3gm7lzMBClIZ36iwKMe/K8tsLF/65zNeO8g= 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=nMP57/o2PxyEkj+ZB1OrFOzG7kUffP5n4kzYRCeyKC2KNsm4e/Z8hLSGmhbLCuj86l nlCji3q1L9XPDohx7oSBwvtasgiFvHcV0muhnyVlV3NyRaw2lXUl8dkPaMFiT+H4zluY MaScPuJUk8q88a7hFTTXpj6XEVU3rS+POBfMo= MIME-Version: 1.0 Received: by 10.114.249.17 with SMTP id w17mr6877737wah.148.1261577528038; Wed, 23 Dec 2009 06:12:08 -0800 (PST) In-Reply-To: <19249.59669.378950.176465@fireball.kivinen.iki.fi> References: <20091130151502.7EAAF28C122@core3.amsl.com> <19249.59669.378950.176465@fireball.kivinen.iki.fi> Date: Wed, 23 Dec 2009 19:42:07 +0530 Message-ID: From: Venkatesh Sriram To: Tero Kivinen Content-Type: text/plain; charset=ISO-8859-1 Cc: ipsec@ietf.org Subject: Re: [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: Wed, 23 Dec 2009 14:12:31 -0000 Thanks Tero. >> Section 8.1 of the draft describes the ESP-NULL packet format. While >> doing so, it also shows the IV as optional. Now, my question is, that >> isnt IV for NULL encryption (integrity only) always 0? > > No. In most cases the IV length is 0, but there is AUTH_AES_*_GMAC > authentication algorithms where it is 8 bytes, as explained in the > draft. Is this the preferred (or recommended) algorithm to be used for NULL encryption now? Are there any docs that use this? Sriram > >> If thats the case then why are we showing the IV in that packet? > > Because it can be there for those ESP_NULL_AUTH_AES_GMAC algorithms > (RFC4543). > -- > kivinen@iki.fi > From smb@cs.columbia.edu Wed Dec 23 15:06: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 E26103A693C for ; Wed, 23 Dec 2009 15:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.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 KkIF36llB4L7 for ; Wed, 23 Dec 2009 15:06:00 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id CB0A63A69B1 for ; Wed, 23 Dec 2009 15:05:59 -0800 (PST) Received: from mallet.cs.columbia.edu (mallet.cs.columbia.edu [128.59.21.121]) (user=smb2132 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nBNN5ZYa011238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Dec 2009 18:05:35 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: Date: Wed, 23 Dec 2009 18:05:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Masood, Faisal" X-Mailer: Apple Mail (2.1077) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: ipsec@ietf.org Subject: Re: [IPsec] WESP encryption support 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, 24 Dec 2009 04:50:08 -0000 On Dec 21, 2009, at 7:08 PM, Masood, Faisal wrote: > The support of WESP encryption, as it currently stands in the draft, = is > important and we would like to discuss this in detail but many of our > core team members are away for the holidays. >=20 The issue is certainly seen as important by some members of the = community. This is at least the third time it's come up -- I know; I = brought it to the IPsec working group myself the first time, many years = ago. The consensus was always not to proceed, because there were also = strong arguments against it. I'm not saying that yesterday's decision = has to be tomorrow's; I am saying that so contentious an issue should = not be decided via the back door. --Steve Bellovin, http://www.cs.columbia.edu/~smb From yaronf@checkpoint.com Wed Dec 23 23:28: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 2B1FE3A6898 for ; Wed, 23 Dec 2009 23:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 5a3TTIbEiS+m for ; Wed, 23 Dec 2009 23:28:54 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id E2BBC3A6837 for ; Wed, 23 Dec 2009 23:28:53 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBO7SKT7008743; Thu, 24 Dec 2009 09:28: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; Thu, 24 Dec 2009 09:28:31 +0200 From: Yaron Sheffer To: Steven Bellovin , "Masood, Faisal" Date: Thu, 24 Dec 2009 09:28:21 +0200 Thread-Topic: [IPsec] WESP encryption support Thread-Index: AcqEVJHY7bds4VfHQ3KUErUzWm8WygAFdTnQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C4366@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] WESP encryption support 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, 24 Dec 2009 07:28:55 -0000 Paul and I agree that a discussion is needed, and we will open this discuss= ion in a week's time, when most of the WG members are back from vacation. In the meantime, Happy Holidays! Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= teven Bellovin Sent: Thursday, December 24, 2009 1:06 To: Masood, Faisal Cc: ipsec@ietf.org Subject: Re: [IPsec] WESP encryption support On Dec 21, 2009, at 7:08 PM, Masood, Faisal wrote: > The support of WESP encryption, as it currently stands in the draft,=20 > is important and we would like to discuss this in detail but many of=20 > our core team members are away for the holidays. >=20 The issue is certainly seen as important by some members of the community. = This is at least the third time it's come up -- I know; I brought it to th= e IPsec working group myself the first time, many years ago. The consensus= was always not to proceed, because there were also strong arguments agains= t it. I'm not saying that yesterday's decision has to be tomorrow's; I am = saying that so contentious an issue should not be decided via the back door= . --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. From paul.hoffman@vpnc.org Sun Dec 27 19:06: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 094C53A677D for ; Sun, 27 Dec 2009 19:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.013 X-Spam-Level: X-Spam-Status: No, score=-5.013 tagged_above=-999 required=5 tests=[AWL=-0.826, BAYES_20=-0.74, 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 sv9H7GhDhgRV for ; Sun, 27 Dec 2009 19:06:08 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 347063A67A6 for ; Sun, 27 Dec 2009 19:06:08 -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 nBS35l7X073751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 27 Dec 2009 20:05:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sun, 27 Dec 2009 19:05:46 -0800 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Clarifying what happens with INITIAL_CONTACT 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, 28 Dec 2009 03:06:09 -0000 IKEv2bis doesn't say what actually happens when you get a INITIAL_CONTACT notification. In specific, it doesn't say what to do when you have to throw away SAs. I propose to add the following to section 2.4: If an initiator receives an INITIAL_CONTACT notification in response to its IKE_AUTH request, it MUST internally delete any IKE SAs and associated Child SAs for that responder without sending any notifications to the responder. If a responder receives an INITIAL_CONTACT notification in an IKE_AUTH request, it MUST internally delete any IKE SAs and associated Child SAs for that initiator without sending any notifications to the initiator. --Paul Hoffman, Director --VPN Consortium From syedah@huawei.com Mon Dec 28 04:22: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 D16EE3A6890 for ; Mon, 28 Dec 2009 04:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 najQGUWm56WQ for ; Mon, 28 Dec 2009 04:22:23 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 40D7E3A693E for ; Mon, 28 Dec 2009 04:22:21 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KVD009OX3OFYH@szxga04-in.huawei.com> for ipsec@ietf.org; Mon, 28 Dec 2009 20:21:51 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KVD00AY83OFYY@szxga04-in.huawei.com> for ipsec@ietf.org; Mon, 28 Dec 2009 20:21:51 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KVD00H433OCCE@szxml04-in.huawei.com> for ipsec@ietf.org; Mon, 28 Dec 2009 20:21:51 +0800 (CST) Date: Mon, 28 Dec 2009 17:51:49 +0530 From: Syed Ajim Hussain To: ipsec@ietf.org Message-id: <003501ca87b8$5630ee60$1f01120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcqDOEOoBxP2Je6eQIS1hBh27nrPMQEds8EgAAJDnSA= Subject: [IPsec] Some IPSEC/IKE NAT 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: Mon, 28 Dec 2009 12:22:24 -0000 Hi All I have some doubt about NAT With IPSEC/IKE , Example Take a Topology : IKE_PEER1 ----------- NAT1 ----------------NAT2 Server---IKE_PEER3 (1.1.1.1) | (1.1.1.10) (2.1.1.1) (2.1.1.2) (3.1.1.1) | IKE_PEER2 | (1.1.1.2) IKE_PEER1 and IKE_PEER2 , behind Same NAT Device NAT1 , Want to Establish IPSEC Tunnel with IKE_PEER3, which is Behind a NAT Server ( Service Running Behind a NAT). For IKE_PEER1, IKE_PEER2, NAT2 Server Address (2.1.1.2) is the Peer Address, Since IKE_PEE3 running behind a NAT Server. Questions1: 1. For IKE_PEER3, 2.1.1.1 is the Peer Address for both IKE_PEER1 & IKE_PEER2. If IKE ID Type is IP Address then, how IKE SA can be Established, between IKE_PEER1& IKE_PEER3 and IKE_PEER2 & IKE_PEER3, 2. If ID Type is based on Name (FQDN), Say IPSEC Tunnel is Established Between IKE_PEER1 & IKE_PEER3. If IPSEC SA Mode is Tunnel, Now Inner IP Header may have Destination IP Address as NAT2 Server's Address that is (2.1.1.2). This Original IP Packet will be a payload of IPSEC Encapsulated packet. Since NAT2 Server, will Change only Outer IP Header Destination Address, to Forward the packet to IKE_PEER3. Now in IKE_PEER3 after IPSEC Decapsulation, original Packet will Have 2.1.1.2 (NAT Server's Address) as Destination Address. Now How This packet can be processed in IKE_PEER3. Does tunnel Mode Can not be supported in such Topology?? If RFC is not clear about such Solution, then we can have one RFC To solve this scenario. With Regards Syed Ajim **************************************************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! *************************************************************************** From rsjenwar@gmail.com Mon Dec 28 04:59: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 7B5453A6884 for ; Mon, 28 Dec 2009 04:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.416, 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 Kj39QKdrJrdk for ; Mon, 28 Dec 2009 04:59:51 -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 114EA3A6878 for ; Mon, 28 Dec 2009 04:59:50 -0800 (PST) Received: by ewy6 with SMTP id 6so8538109ewy.29 for ; Mon, 28 Dec 2009 04:59:28 -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=XlgUC2ca4xplOgdmjdiDSEAalmzsqWtNFCOqTYFhf88=; b=efFZPRhBrM94sJaPMByYw+OQKfX+gUfm+G/Ur7eA60W7tkuWedxcDmuM53Vrum4qpn O4Q4P3070dIEa0GUJaDkuDY6bo6sXww6Co74k7nAix/Q1IOIWanRwyHcWTVsL9pbTyEy Owz6rNtxniDw3pezGkQkBepWL11Cmb/rcGHfc= 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=bVj25YGRKbHjThBbLpvzH9lEp3amTY9JZioM4LkNDcJf5bZI/Y7CU8uZztq7zr+vuv 7zJNGZvy4LVOk6/mi0JBNcEa8CpNql2wPN391fTj9VhcOJ0IonopvYkSqCIPOmmZ17NT Y+e1CGdTPI7SlkUIFF0eoaHEwEtfJEwiR6cZQ= MIME-Version: 1.0 Received: by 10.216.85.132 with SMTP id u4mr2088024wee.191.1262005167845; Mon, 28 Dec 2009 04:59:27 -0800 (PST) In-Reply-To: <003501ca87b8$5630ee60$1f01120a@china.huawei.com> References: <003501ca87b8$5630ee60$1f01120a@china.huawei.com> Date: Mon, 28 Dec 2009 18:29:27 +0530 Message-ID: <7ccecf670912280459y1474411dv95608863acb573a@mail.gmail.com> From: Raj Singh To: Syed Ajim Hussain Content-Type: multipart/alternative; boundary=0016e6d56698bbf1d3047bc97918 Cc: ipsec Subject: Re: [IPsec] Some IPSEC/IKE NAT 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: Mon, 28 Dec 2009 12:59:52 -0000 --0016e6d56698bbf1d3047bc97918 Content-Type: text/plain; charset=UTF-8 Hi Syed, On Mon, Dec 28, 2009 at 5:51 PM, Syed Ajim Hussain wrote: > > > Hi All > I have some doubt about NAT With IPSEC/IKE , > > Example Take a Topology : > > IKE_PEER1 ----------- NAT1 ----------------NAT2 Server---IKE_PEER3 > (1.1.1.1) | (1.1.1.10) (2.1.1.1) (2.1.1.2) (3.1.1.1) > | > IKE_PEER2 | > (1.1.1.2) > > IKE_PEER1 and IKE_PEER2 , behind Same NAT Device NAT1 , Want to > Establish IPSEC Tunnel with IKE_PEER3, which is Behind a NAT Server ( > Service Running Behind a NAT). > > For IKE_PEER1, IKE_PEER2, NAT2 Server Address (2.1.1.2) is the Peer > Address, Since IKE_PEE3 running behind a NAT Server. > > Questions1: > > 1. For IKE_PEER3, 2.1.1.1 is the Peer Address for both IKE_PEER1 & > IKE_PEER2. If IKE ID Type is IP Address then, how IKE SA can be > Established, between IKE_PEER1& IKE_PEER3 and IKE_PEER2 & IKE_PEER3, > > Even though IKE_PEER3 sees same IP address for IKE_PEER1 and IKE_PEER2, the source port will be different to distinguish the connections. 2. If ID Type is based on Name (FQDN), Say IPSEC Tunnel is > Established Between IKE_PEER1 & IKE_PEER3. If IPSEC SA Mode is > Tunnel, Now Inner IP Header may have Destination IP Address as NAT2 > Server's Address that is (2.1.1.2). This Original IP Packet will be a > payload of IPSEC Encapsulated packet. > > Since NAT2 Server, will Change only Outer IP Header Destination > Address, to Forward the packet to IKE_PEER3. > > Now in IKE_PEER3 after IPSEC Decapsulation, original Packet will > Have 2.1.1.2 (NAT Server's Address) as Destination Address. Now How > This packet can be processed in IKE_PEER3. > > The IKE_PEER3 can forward these packets to NAT device as they are not destined to it. > Does tunnel Mode Can not be supported in such Topology?? > > If RFC is not clear about such Solution, then we can have one RFC > To solve this scenario. > > > With Regards > Syed Ajim > > > > **************************************************************************** > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender > by > phone or email immediately and delete it! > > *************************************************************************** > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > Regards, Raj --0016e6d56698bbf1d3047bc97918 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Syed,


On Mon, Dec 28, 2009 at 5:5= 1 PM, Syed Ajim Hussain <syedah@huawei.com> wrote:


Hi All
=C2=A0 =C2=A0I have some doubt about NAT With IPSEC/IKE ,

=C2=A0Example Take a Topology :

=C2=A0IKE_PEER1 =C2=A0----------- NAT1 ----------------NAT2 Server---IKE_P= EER3
=C2=A0(1.1.1.1) =C2=A0 | =C2=A0(1.1.1.10) =C2=A0(2.1.1.1) =C2=A0(2.1.1.2) = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (3.1.1.1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0IKE_PEER2 =C2=A0 |
=C2=A0(1.1.1.2)

=C2=A0IKE_PEER1 and =C2=A0IKE_PEER2 , =C2=A0behind Same NAT Device NAT1 , = =C2=A0Want to
=C2=A0Establish IPSEC Tunnel with =C2=A0 IKE_PEER3, which is Behind a NAT = Server (
=C2=A0Service Running Behind a NAT).

=C2=A0For IKE_PEER1, IKE_PEER2, NAT2 Server Address (2.1.1.2) is the Peer<= br> =C2=A0Address, Since IKE_PEE3 running behind a NAT Server.

Questions1:

=C2=A01. For IKE_PEER3, 2.1.1.1 =C2=A0 is the Peer Address for both IKE_PEE= R1 &
=C2=A0 =C2=A0IKE_PEER2. If IKE ID Type is IP Address then, how IKE SA can = be
=C2=A0 =C2=A0Established, between IKE_PEER1& IKE_PEER3 and IKE_PEER2 &= amp; IKE_PEER3,

Even though IKE_PEER3 sees same IP address for IKE_PE= ER1 and IKE_PEER2, the source port will be different to distinguish the con= nections.

2. =C2=A0 If ID Type is based on Name (FQDN), Say IPSEC Tunnel is
=C2=A0 =C2=A0 Established Between IKE_PEER1 & IKE_PEER3. =C2=A0If IPSE= C SA Mode is
=C2=A0 =C2=A0 Tunnel, =C2=A0Now Inner IP Header may have Destination IP Ad= dress as NAT2
=C2=A0 =C2=A0 Server's Address that is (2.1.1.2). =C2=A0This Original = IP Packet will be a
=C2=A0 =C2=A0 payload of IPSEC Encapsulated =C2=A0packet.

=C2=A0 =C2=A0 Since NAT2 Server, will Change only Outer IP Header Destinat= ion
=C2=A0 =C2=A0 Address, to Forward the packet to IKE_PEER3.

=C2=A0 =C2=A0 Now in =C2=A0 IKE_PEER3 after IPSEC Decapsulation, original = Packet will
=C2=A0 =C2=A0 Have 2.1.1.2 (NAT Server's Address) as Destination Addre= ss. =C2=A0Now How
=C2=A0 =C2=A0 This packet can be processed in IKE_PEER3.

The IKE_PEER3 can forward these packets to NAT device= as they are not destined to it.=C2=A0
=C2=A0 =C2=A0 Does tunnel Mode Can not be supported in such Topology??

=C2=A0 =C2=A0 If RFC is not clear about such Solution, then we can have on= e RFC
=C2=A0 =C2=A0 To solve this scenario.


With Regards
Syed Ajim


***************************************************************************= *
This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender b= y
phone or email immediately and delete it!

***************************************************************************=

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

Regards,
Raj
--0016e6d56698bbf1d3047bc97918-- From yaronf@checkpoint.com Mon Dec 28 07:28: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 BCF023A6969 for ; Mon, 28 Dec 2009 07:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 HEBrWjgjjtDB for ; Mon, 28 Dec 2009 07:28:34 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 5DA953A6968 for ; Mon, 28 Dec 2009 07:28:34 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBSFSDT7012114; Mon, 28 Dec 2009 17:28:13 +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, 28 Dec 2009 17:28:26 +0200 From: Yaron Sheffer To: Paul Hoffman , IPsecme WG Date: Mon, 28 Dec 2009 17:28:11 +0200 Thread-Topic: [IPsec] Clarifying what happens with INITIAL_CONTACT Thread-Index: AcqHarTbnaH0h539TCO174CJ1LpC3QAZwR8g Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C46D7@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] Clarifying what happens with INITIAL_CONTACT 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, 28 Dec 2009 15:28:35 -0000 Hi Paul, You are adding two MUSTs, which we SHOULD NOT do unless we have very good r= easons, such as interop problems, security issues, or major functionality p= roblems (like memory leaks). I'm not sure any of these apply, so I suggest = that you change the wording to be non-normative. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of P= aul Hoffman Sent: Monday, December 28, 2009 5:06 To: IPsecme WG Subject: [IPsec] Clarifying what happens with INITIAL_CONTACT IKEv2bis doesn't say what actually happens when you get a INITIAL_CONTACT n= otification. In specific, it doesn't say what to do when you have to throw = away SAs. I propose to add the following to section 2.4: If an initiator receives an INITIAL_CONTACT notification in response to its IKE_AUTH request, it MUST internally delete any IKE SAs and associated Child SAs for that responder without sending any notifications to the responder. If a responder receives an INITIAL_CONTACT notification in an IKE_AUTH request, it MUST internally delete any IKE SAs and associated Child SAs for that initiator without sending any notifications to the initiator. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. From paul.hoffman@vpnc.org Mon Dec 28 07:36: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 62F0F3A682A for ; Mon, 28 Dec 2009 07:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.114, 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 qMkZD9pFV6Ll for ; Mon, 28 Dec 2009 07:36:37 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 99D703A68FC for ; Mon, 28 Dec 2009 07:36:37 -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 nBSFa7Kx016094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Dec 2009 08:36:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C46D7@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C46D7@il-ex01.ad.checkpoint.com> Date: Mon, 28 Dec 2009 07:36:06 -0800 To: Yaron Sheffer , IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Clarifying what happens with INITIAL_CONTACT 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, 28 Dec 2009 15:36:38 -0000 At 5:28 PM +0200 12/28/09, Yaron Sheffer wrote: >You are adding two MUSTs, which we SHOULD NOT do unless we have very good reasons, such as interop problems, security issues, or major functionality problems (like memory leaks). I'm not sure any of these apply, so I suggest that you change the wording to be non-normative. Whoops, all good points. I got carried away. How about: When an initiator receives an INITIAL_CONTACT notification in response to its IKE_AUTH request, it silently deletes any IKE SAs and associated Child SAs for that responder without sending any notifications to the responder. If a responder receives an INITIAL_CONTACT notification in an IKE_AUTH request, it silently deletes any IKE SAs and associated Child SAs for that initiator without sending any notifications to the initiator. --Paul Hoffman, Director --VPN Consortium From yaronf@checkpoint.com Mon Dec 28 08:08: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 322903A68BF for ; Mon, 28 Dec 2009 08:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 RqoR-mxVmi8c for ; Mon, 28 Dec 2009 08:08:19 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id F02793A635F for ; Mon, 28 Dec 2009 08:08:18 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.32.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id nBSG7xT7018695; Mon, 28 Dec 2009 18:07:59 +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, 28 Dec 2009 18:08:11 +0200 From: Yaron Sheffer To: Paul Hoffman , IPsecme WG Date: Mon, 28 Dec 2009 18:08:09 +0200 Thread-Topic: [IPsec] Clarifying what happens with INITIAL_CONTACT Thread-Index: AcqH04dnv4GWlv9yRqiYg7GFkcKAuwABGWRw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C46ED@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] Clarifying what happens with INITIAL_CONTACT 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, 28 Dec 2009 16:08:20 -0000 Looks good to me. Yaron -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 Sent: Monday, December 28, 2009 17:36 To: Yaron Sheffer; IPsecme WG Subject: Re: [IPsec] Clarifying what happens with INITIAL_CONTACT At 5:28 PM +0200 12/28/09, Yaron Sheffer wrote: >You are adding two MUSTs, which we SHOULD NOT do unless we have very good = reasons, such as interop problems, security issues, or major functionality = problems (like memory leaks). I'm not sure any of these apply, so I suggest= that you change the wording to be non-normative. Whoops, all good points. I got carried away. How about: When an initiator receives an INITIAL_CONTACT notification in response to its IKE_AUTH request, it silently deletes any IKE SAs and associated Child SAs for that responder without sending any notifications to the responder. If a responder receives an INITIAL_CONTACT notification in an IKE_AUTH request, it silently deletes any IKE SAs and associated Child SAs for that initiator without sending any notifications to the initiator. --Paul Hoffman, Director --VPN Consortium Scanned by Check Point Total Security Gateway. From smoonen@us.ibm.com Mon Dec 28 09:45: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 BD12A3A690E; Mon, 28 Dec 2009 09:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.804 X-Spam-Level: X-Spam-Status: No, score=-5.804 tagged_above=-999 required=5 tests=[AWL=0.794, 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 VoZY+9Sq8FSr; Mon, 28 Dec 2009 09:45:28 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 840873A68F9; Mon, 28 Dec 2009 09:45:28 -0800 (PST) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e33.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nBSHg3xf006064; Mon, 28 Dec 2009 10:42:03 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nBSHitpP106846; Mon, 28 Dec 2009 10:44:59 -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 nBSHisiM029462; Mon, 28 Dec 2009 10:44:55 -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 nBSHishn029459; Mon, 28 Dec 2009 10:44:54 -0700 In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C46ED@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C46ED@il-ex01.ad.checkpoint.com> To: Yaron Sheffer MIME-Version: 1.0 X-KeepSent: 8405AB0E:25494AC4-8525769A:00603E33; 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 12/28/2009 12:31:26 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 12/28/2009 12:31:26 PM, Serialize complete at 12/28/2009 12:31:26 PM, S/MIME Sign failed at 12/28/2009 12:31:26 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 12/28/2009 10:44:54, Serialize complete at 12/28/2009 10:44:54 Message-ID: Date: Mon, 28 Dec 2009 12:44:53 -0500 Content-Type: multipart/alternative; boundary="=_alternative 006043398525769A_=" Cc: IPsecme WG , ipsec-bounces@ietf.org, Paul Hoffman Subject: Re: [IPsec] Clarifying what happens with INITIAL_CONTACT 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, 28 Dec 2009 17:45:29 -0000 This is a multipart message in MIME format. --=_alternative 006043398525769A_= Content-Type: text/plain; charset="US-ASCII" > Looks good to me. Agreed. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Yaron Sheffer To: Paul Hoffman , IPsecme WG Date: 12/28/2009 11:08 AM Subject: Re: [IPsec] Clarifying what happens with INITIAL_CONTACT Looks good to me. Yaron -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Monday, December 28, 2009 17:36 To: Yaron Sheffer; IPsecme WG Subject: Re: [IPsec] Clarifying what happens with INITIAL_CONTACT At 5:28 PM +0200 12/28/09, Yaron Sheffer wrote: >You are adding two MUSTs, which we SHOULD NOT do unless we have very good reasons, such as interop problems, security issues, or major functionality problems (like memory leaks). I'm not sure any of these apply, so I suggest that you change the wording to be non-normative. Whoops, all good points. I got carried away. How about: When an initiator receives an INITIAL_CONTACT notification in response to its IKE_AUTH request, it silently deletes any IKE SAs and associated Child SAs for that responder without sending any notifications to the responder. If a responder receives an INITIAL_CONTACT notification in an IKE_AUTH request, it silently deletes any IKE SAs and associated Child SAs for that initiator without sending any notifications to the initiator. --Paul Hoffman, Director --VPN Consortium Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 006043398525769A_= Content-Type: text/html; charset="US-ASCII"
> Looks good to me.

Agreed.

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


From: Yaron Sheffer <yaronf@checkpoint.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>, IPsecme WG <ipsec@ietf.org>
Date: 12/28/2009 11:08 AM
Subject: Re: [IPsec] Clarifying what happens with INITIAL_CONTACT




Looks good to me.

                Yaron

-----Original Message-----
From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]
Sent: Monday, December 28, 2009 17:36
To: Yaron Sheffer; IPsecme WG
Subject: Re: [IPsec] Clarifying what happens with INITIAL_CONTACT

At 5:28 PM +0200 12/28/09, Yaron Sheffer wrote:
>You are adding two MUSTs, which we SHOULD NOT do unless we have very good reasons, such as interop problems, security issues, or major functionality problems (like memory leaks). I'm not sure any of these apply, so I suggest that you change the wording to be non-normative.

Whoops, all good points. I got carried away. How about:

When an initiator receives an INITIAL_CONTACT notification in
response to its IKE_AUTH request, it silently deletes any IKE SAs and
associated Child SAs for that responder without sending any
notifications to the responder. If a responder receives an
INITIAL_CONTACT notification in an IKE_AUTH request, it silently
deletes any IKE SAs and associated Child SAs for that initiator
without sending any notifications to the initiator.

--Paul Hoffman, Director
--VPN Consortium

Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 006043398525769A_=-- From kent@bbn.com Mon Dec 28 11:37: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 9196A3A691D for ; Mon, 28 Dec 2009 11:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 P3bs6RmrHD3W for ; Mon, 28 Dec 2009 11:37:01 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 8A3703A690A for ; Mon, 28 Dec 2009 11:37:01 -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 1NPLOS-0000C3-AB; Mon, 28 Dec 2009 14:36:40 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <7ccecf670912171850n15dd3c42t2692bb1a355f7daf@mail.gmail.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04F0@il-ex01.ad.checkpoint.com> <1d38a3350912090742q1976ffefo85ef5e0e5627ec0b@mail.gmail.com> <023f01ca7908$480951b0$d81bf510$%yegin@yegin.org> <3824040C-7D40-4B46-B430-AE87D6729A19@checkpoint.com> <02c401ca7970$974303d0$c5c90b70$%yegin@yegin.org> <20091215183742.GV1516@Sun.COM> <62778081976350302@unknownmsgid> <7ccecf670912171850n15dd3c42t2692bb1a355f7daf@mail.gmail.com> Date: Mon, 28 Dec 2009 14:26:09 -0500 To: Raj Singh From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-950093497==_ma============" Cc: Hui Deng , ipsec , Alper Yegin , Yoav Nir , Nicolas Williams Subject: Re: [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: Mon, 28 Dec 2009 19:37:02 -0000 --============_-950093497==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 8:20 AM +0530 12/18/09, Raj Singh wrote: >... > >IKE is Internet Key Exchange protocol NOT IPsec Key Exchange protocol. >IKEv2 is not just a mean of exchanging keys but its a full package. >This package provides mutual authentication, keys and readiness to >secure data as needed. >The main motivation for this draft is Remote Access VPN scenario. Depite the name, IKE really is the IPsec Key Exchange Protocol. It is true that the original vision for IKE was much broader, but over time we have tailored IKE to support IPsec. Steve --============_-950093497==_ma============ Content-Type: text/html; charset="us-ascii" Re: [IPsec] Proposed work item: Childless IKE SA
At 8:20 AM +0530 12/18/09, Raj Singh wrote:
...
 
IKE is Internet Key Exchange protocol NOT IPsec Key Exchange protocol.
IKEv2 is not just a mean of exchanging keys but its a full package.
This package provides mutual authentication, keys and readiness to secure data as needed.
The main motivation for this draft is Remote Access VPN scenario.

Depite the name, IKE really is the IPsec Key Exchange Protocol. It is true that the original vision for IKE was much broader, but over time we have tailored IKE to support IPsec.

Steve
--============_-950093497==_ma============-- From kent@bbn.com Mon Dec 28 12:47: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 A875C3A6920; Mon, 28 Dec 2009 12:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 lnWXJV57EzOd; Mon, 28 Dec 2009 12:47:58 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id D9F4F3A692A; Mon, 28 Dec 2009 12:47:58 -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 1NPMV0-0001MU-BY; Mon, 28 Dec 2009 15:47:30 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> Date: Mon, 28 Dec 2009 15:45:21 -0500 To: Yaron Sheffer From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , Russ Housley , "iesg@ietf.org" , Dan McDonald Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 28 Dec 2009 20:47:59 -0000 Yaron, I hate to admit it, but I lost track of the details of WESP as it progressed through WG discussions and briefings at IETF meetings. When I read the I-D in detail, I was very surprised to see that it was no longer a neatly-layered wrapper, as originally proposed. The fact that it now calls for the ESP ICV to be computed in a new fashion means that it really is replacing ESP, when used to mark ESP-NULL packets. From a protocol design perspective, the current version makes no sense to me. Why keep the ESP header when ESP processing is now changed in a significant way. The WESP header cannot be processed (completely) by itself, because of the dependence on the ESP ICV. So it makes little or no sense to retain the ESP header in this context. I see no strong backward compatibility motivation for this format, given that ESP processing must change to accommodate WESP (as defined). The issue of using WESP for marking encrypted traffic is a separate topic. I believe the rationale you cited was to enable WESP extensions, but I may have missed other arguments put forth for this. Since most of the WESP extension proposals discussed so far have proven to be questionable, I am not enthusiastic about that rationale. Others have noted that using WESP with encrypted traffic is not consistent with the scope of the WG charter item that authorized work on WESP. Unless Pasi approves a WESP extension WG item as part of re-chartering, I think it is inappropriate to have a flag to mark a WESP payload as encrypted. Steve From kohn.jack@gmail.com Mon Dec 28 16:47: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 DD8AB3A6889; Mon, 28 Dec 2009 16:47:43 -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 d2MxEqSOr9eQ; Mon, 28 Dec 2009 16:47:43 -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 DD6443A686B; Mon, 28 Dec 2009 16:47:42 -0800 (PST) Received: by yxe30 with SMTP id 30so12292414yxe.29 for ; Mon, 28 Dec 2009 16:47:21 -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=GINH9qpUapKb5xY/8aFJGSKPDV4MkYSzeixcfMAExKU=; b=Nw32LxTxXmDH0qwXGcDsw+ADi43TAXxypWzHc7TbTkCTBYeRreOjqG+tjon5BCppuL nK5OrLUtf7tGNajy2bD1/vmHhmb7U70BVEa7bwSl2NC/bYoYZNNqe4Ou+Om3wfcChio7 YKNeL/xkF06XvRRQ1lxkFALw+PSc2XrgiWAm0= 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=qXJkY4+JyIayY+uJavDLHJinSHfwrps5U/p681FXgtBEsjRO7HXn5Q3CRYAjFkUthN j+gwYIcCbarc7kVkwO2WIkwrVqsz5brkk9s6TWVUEgaOCbnSJ+uvg/kw5Db5I56hEJ91 NgflhAM+qghQOSixj3hRxkdNoOQI9qMDdnpSg= MIME-Version: 1.0 Received: by 10.90.8.13 with SMTP id 13mr6497087agh.89.1262047640850; Mon, 28 Dec 2009 16:47:20 -0800 (PST) In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> Date: Tue, 29 Dec 2009 06:17:20 +0530 Message-ID: From: Jack Kohn To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" , Russ Housley , "iesg@ietf.org" , Dan McDonald Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 29 Dec 2009 00:47:44 -0000 Are you suggesting that ESP ICV should not cover the WESP fields? I think, and my memory could be failing me, that this was discussed in the WG before this got added to the draft. Jack On Tue, Dec 29, 2009 at 2:15 AM, Stephen Kent wrote: > Yaron, > > I hate to admit it, but I lost track of the details of WESP as it progres= sed > through WG discussions and briefings at IETF meetings. When I read the I-= D > in detail, I was very surprised to see that it was no longer a > neatly-layered wrapper, as originally proposed. =A0The fact that it now c= alls > for the ESP ICV to be computed in a new fashion means that it really is > replacing ESP, when used to mark ESP-NULL packets. > > From a protocol design perspective, the current version makes no sense to > me. Why keep the ESP header when ESP processing is now changed in a > significant way. =A0The WESP header cannot be processed (completely) by > itself, because of the dependence on the ESP ICV. So it makes little or n= o > sense to retain the ESP header in this context. I see no strong backward > compatibility motivation for this format, given that ESP processing must > change to accommodate WESP (as defined). > > The issue of using WESP for marking encrypted traffic is a separate topic= . I > believe the rationale you cited was to enable WESP extensions, but I may > have missed other arguments put forth for this. Since most of the WESP > extension proposals discussed so far have proven to be questionable, I am > not enthusiastic about that rationale. =A0Others have noted that using WE= SP > with encrypted traffic is not consistent with the scope of the WG charter > item that authorized work on WESP. =A0Unless Pasi approves a WESP extensi= on WG > item as part of re-chartering, I think it is inappropriate to have a flag= to > mark a WESP payload as encrypted. > > Steve > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From manav.bhatia@alcatel-lucent.com Mon Dec 28 18:37: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 D36933A6813; Mon, 28 Dec 2009 18:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 pDIFrmbpMyb2; Mon, 28 Dec 2009 18:37:16 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id C5DA63A659C; Mon, 28 Dec 2009 18:37:16 -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 nBT2aqc6022776; Mon, 28 Dec 2009 20:36:52 -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 nBT2amYb008807; Mon, 28 Dec 2009 20:36: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 nBT2W3hS013579; Tue, 29 Dec 2009 10:32:03 +0800 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 29 Dec 2009 08:06:45 +0530 From: "Bhatia, Manav (Manav)" To: Jack Kohn , Stephen Kent Date: Tue, 29 Dec 2009 08:06:42 +0530 Thread-Topic: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility Thread-Index: AcqIIIJ2QL0aG3eSRHOzfAiHxjcN8wADw9/g Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB332DBC6@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@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="iso-8859-1" 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" , Russ Housley , "iesg@ietf.org" , Dan McDonald Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 29 Dec 2009 02:37:18 -0000 Yes, this was discussed in the WG (http://trac.tools.ietf.org/wg/ipsecme/tr= ac/ticket/104) and the idea was this: We could have some malicious entity that could modify the offsets to ensure= that the intermediaries don't parse a portion of the payload (which could = contain malicious content) or inspect it differently than what it would hav= e done otherwise. A way to protect against such attacks is to let the end n= ode validate the WESP header by including this as a part of the ESP ICV. If= the computed ICV does not match, the packet is dropped (usual IPSec proces= sing). This does not completely eliminate the vulnerability, but it does raise the= bar, because now the malicious routers would have to also position themsel= ves both before and after the middle boxes in order to have a chance to rev= ert the packet back to its original form before the end node verifies integ= rity over the packet.=20 We have also discussed this in the Security Considerations section of the d= raft. We did informally speak to HW guys who are interested in implementing WESP,= and they confirmed that increasing the integrity protection of ESP to now = cover the WESP header is trivial.=20 Cheers, Manav > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Jack Kohn > Sent: Tuesday, December 29, 2009 6.17 AM > To: Stephen Kent > Cc: ipsec@ietf.org; Russ Housley; iesg@ietf.org; Dan McDonald > Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility >=20 > Are you suggesting that ESP ICV should not cover the WESP fields? >=20 > I think, and my memory could be failing me, that this was discussed in > the WG before this got added to the draft. >=20 > Jack >=20 > On Tue, Dec 29, 2009 at 2:15 AM, Stephen Kent wrote: > > Yaron, > > > > I hate to admit it, but I lost track of the details of WESP=20 > as it progressed > > through WG discussions and briefings at IETF meetings. When=20 > I read the I-D > > in detail, I was very surprised to see that it was no longer a > > neatly-layered wrapper, as originally proposed. =A0The fact=20 > that it now calls > > for the ESP ICV to be computed in a new fashion means that=20 > it really is > > replacing ESP, when used to mark ESP-NULL packets. > > > > From a protocol design perspective, the current version=20 > makes no sense to > > me. Why keep the ESP header when ESP processing is now changed in a > > significant way. =A0The WESP header cannot be processed=20 > (completely) by > > itself, because of the dependence on the ESP ICV. So it=20 > makes little or no > > sense to retain the ESP header in this context. I see no=20 > strong backward > > compatibility motivation for this format, given that ESP=20 > processing must > > change to accommodate WESP (as defined). > > > > The issue of using WESP for marking encrypted traffic is a=20 > separate topic. I > > believe the rationale you cited was to enable WESP=20 > extensions, but I may > > have missed other arguments put forth for this. Since most=20 > of the WESP > > extension proposals discussed so far have proven to be=20 > questionable, I am > > not enthusiastic about that rationale. =A0Others have noted=20 > that using WESP > > with encrypted traffic is not consistent with the scope of=20 > the WG charter > > item that authorized work on WESP. =A0Unless Pasi approves a=20 > WESP extension WG > > item as part of re-chartering, I think it is inappropriate=20 > to have a flag to > > mark a WESP payload as encrypted. > > > > Steve > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > = From kivinen@iki.fi Tue Dec 29 03:08: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 B97AD3A6853 for ; Tue, 29 Dec 2009 03:08:38 -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 0y3HGp+OGU8d for ; Tue, 29 Dec 2009 03:08:38 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A5EBE3A6822 for ; Tue, 29 Dec 2009 03:08:37 -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 nBTB88Ku020646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Dec 2009 13:08:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBTB86mp024348; Tue, 29 Dec 2009 13:08:06 +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: <19257.58134.758647.17743@fireball.kivinen.iki.fi> Date: Tue, 29 Dec 2009 13:08:06 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF89C46D7@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] Clarifying what happens with INITIAL_CONTACT 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, 29 Dec 2009 11:08:38 -0000 Paul Hoffman writes: > At 5:28 PM +0200 12/28/09, Yaron Sheffer wrote: > > You are adding two MUSTs, which we SHOULD NOT do unless we have > > very good reasons, such as interop problems, security issues, or > > major functionality problems (like memory leaks). I'm not sure any > > of these apply, so I suggest that you change the wording to be > > non-normative. > > Whoops, all good points. I got carried away. How about: > > When an initiator receives an INITIAL_CONTACT notification in > response to its IKE_AUTH request, it silently deletes any IKE SAs and > associated Child SAs for that responder without sending any > notifications to the responder. If a responder receives an > INITIAL_CONTACT notification in an IKE_AUTH request, it silently > deletes any IKE SAs and associated Child SAs for that initiator > without sending any notifications to the initiator. I would actually keep the keyword we have in the RFC4306, i.e. "MAY". It says "... recipient MAY use this information to delete any other IKE_SAs ...". I am not sure what you say above and the MAY are really same. For me the text above says you need to do it, even when it does not have word "MUST" in it, as it only gives you exactly one option. As implementations are not required to understand (or send) INITIAL_CONTACT notifications writing text like you have is bit dangerous, as some people might still read that recipient of INITIAL_CONTACT needs to silently delete any IKE SAs when it receives INITIAL_CONTACT. -- kivinen@iki.fi From kivinen@iki.fi Tue Dec 29 03:27: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 B4F1B3A677C for ; Tue, 29 Dec 2009 03:27:35 -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 agguW0e-zQLW for ; Tue, 29 Dec 2009 03:27:34 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 73A553A6767 for ; Tue, 29 Dec 2009 03:27: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 nBTBQdBB016753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Dec 2009 13:26:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBTBQd94003011; Tue, 29 Dec 2009 13:26:39 +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: <19257.59246.994331.378292@fireball.kivinen.iki.fi> Date: Tue, 29 Dec 2009 13:26:38 +0200 From: Tero Kivinen To: Syed Ajim Hussain In-Reply-To: <003501ca87b8$5630ee60$1f01120a@china.huawei.com> References: <003501ca87b8$5630ee60$1f01120a@china.huawei.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 15 min Cc: ipsec@ietf.org Subject: [IPsec] Some IPSEC/IKE NAT 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, 29 Dec 2009 11:27:35 -0000 Syed Ajim Hussain writes: > > > Hi All > I have some doubt about NAT With IPSEC/IKE , > > Example Take a Topology : > > IKE_PEER1 ----------- NAT1 ----------------NAT2 Server---IKE_PEER3 > (1.1.1.1) | (1.1.1.10) (2.1.1.1) (2.1.1.2) (3.1.1.1) > | > IKE_PEER2 | > (1.1.1.2) > > IKE_PEER1 and IKE_PEER2 , behind Same NAT Device NAT1 , Want to > Establish IPSEC Tunnel with IKE_PEER3, which is Behind a NAT Server ( > Service Running Behind a NAT). > > For IKE_PEER1, IKE_PEER2, NAT2 Server Address (2.1.1.2) is the Peer > Address, Since IKE_PEE3 running behind a NAT Server. > > Questions1: > > 1. For IKE_PEER3, 2.1.1.1 is the Peer Address for both IKE_PEER1 & > IKE_PEER2. If IKE ID Type is IP Address then, how IKE SA can be > Established, between IKE_PEER1& IKE_PEER3 and IKE_PEER2 & IKE_PEER3, ID type does not matter, as it is used for authentication purposes, not for verifying that the source address of IKE packets match. If IP addresses are used in the ID payload, then the IKE_PEER1 and IKE_PEER2 will be using their own internal IP-address (1.1.1.1 and 1.1.1.2) not the IP address of the NAT box. On the other hand the IKE SPIs are used by the IKE_PEER3 to find the correct IKE SA, and when it is sending reply back it will reply to the same IP-address and port where the request came from, so that way the NAT1 can forward IKE packet back to the IKE_PEER1 or IKE_PEER2. > 2. If ID Type is based on Name (FQDN), Say IPSEC Tunnel is > Established Between IKE_PEER1 & IKE_PEER3. If IPSEC SA Mode is > Tunnel, Now Inner IP Header may have Destination IP Address as NAT2 > Server's Address that is (2.1.1.2). This Original IP Packet will be a > payload of IPSEC Encapsulated packet. > > Since NAT2 Server, will Change only Outer IP Header Destination > Address, to Forward the packet to IKE_PEER3. > > Now in IKE_PEER3 after IPSEC Decapsulation, original Packet will > Have 2.1.1.2 (NAT Server's Address) as Destination Address. Now How > This packet can be processed in IKE_PEER3. > > Does tunnel Mode Can not be supported in such Topology?? Tunel mode can be supported, but he IKE_PEER3 needs to get packets which are meaningful for it. For example normal setup would be so that IKE_PEER1 and IKE_PEER2 will request IP address from IKE_PEER3, and then they will assign that address to virtual interface and use that address to talk to the IKE_PEER3 (using real address of IKE_PEER3, not the address of NAT2), or to the hosts behind IKE_PEER3 (i.e. where IKE_PEER3 can forward packets to). The RFC3948 has some text about these issues, and even more about the problems with multiple clients behind same NAT in its section 5 and Appendix A. > If RFC is not clear about such Solution, then we can have one RFC > To solve this scenario. -- kivinen@iki.fi From kivinen@iki.fi Tue Dec 29 03:44: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 0080F3A6877 for ; Tue, 29 Dec 2009 03:44:23 -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 al0MMATPrFWz for ; Tue, 29 Dec 2009 03:44:22 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id CCB803A684A for ; Tue, 29 Dec 2009 03:44:21 -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 nBTBhuhh002459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Dec 2009 13:43:56 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBTBhq3c023137; Tue, 29 Dec 2009 13:43: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: <19257.60280.869475.44850@fireball.kivinen.iki.fi> Date: Tue, 29 Dec 2009 13:43:52 +0200 From: Tero Kivinen To: "Bhatia, Manav (Manav)" In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350AB332DBC6@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> <7C362EEF9C7896468B36C9B79200D8350AB332DBC6@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min Cc: Stephen Kent , Dan McDonald , Russ Housley , "ipsec@ietf.org" , "iesg@ietf.org" , Jack Kohn Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 29 Dec 2009 11:44:23 -0000 Bhatia, Manav (Manav) writes: > Yes, this was discussed in the WG > (http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104) and the idea > was this: > > We could have some malicious entity that could modify the offsets to > ensure that the intermediaries don't parse a portion of the payload > (which could contain malicious content) or inspect it differently > than what it would have done otherwise. A way to protect against > such attacks is to let the end node validate the WESP header by > including this as a part of the ESP ICV. If the computed ICV does > not match, the packet is dropped (usual IPSec processing). As all current fields in the WESP header for ESP-NULL traffic is already verified by the recipient to be matching their authenticated values, there is no need to extend ESP ICV to cover WESP header. Fo example the Next Header field in the WESP header is copy of the Next Header field in the ESP header, and the current draft already mandates that "The receiver MUST ensure that the Next Header field in the WESP header and the Next Header field in the ESP trailer match when using ESP in the Integrity only mode. The packet MUST be dropped if the two do not match." This same goes with HdrLen and TrailerLen etc fields. -- kivinen@iki.fi From housley@vigilsec.com Tue Dec 29 06:53: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 315F03A6898; Tue, 29 Dec 2009 06:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, 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 I8mFZEH4KdQk; Tue, 29 Dec 2009 06:53:50 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 108B23A65A6; Tue, 29 Dec 2009 06:53:50 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 506EAF2403D; Tue, 29 Dec 2009 09:53:40 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id ByJiN-+oywM2; Tue, 29 Dec 2009 09:53:29 -0500 (EST) Received: from THINKPADR52.vigilsec.com (pool-173-66-67-45.washdc.fios.verizon.net [173.66.67.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id EF067F2403E; Tue, 29 Dec 2009 09:53:38 -0500 (EST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Dec 2009 09:32:54 -0500 To: "Bhatia, Manav" From: Russ Housley In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350AB332DBC6@INBANSXCHMBSA1. in.alcatel-lucent.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> <7C362EEF9C7896468B36C9B79200D8350AB332DBC6@INBANSXCHMBSA1.in.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20091229145338.EF067F2403E@odin.smetech.net> Cc: ipsec@ietf.org, iesg@ietf.org Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 29 Dec 2009 14:53:51 -0000 Manav: I am unconvinced. If a malicious attacker is willing to alter packets to fool middleboxes, this ICV does not help the middlebox and it harms the end system. The middlebox cannot validate the ICV, and the end system does not need the WESP header information. The end system does not need the pointer data in the WESP header to process the packet correctly; it already knows the size of the IV and other values associated with the algorithms in use. Thus, the ICV protection imposes a requirement that the end system check the WESP information that it does not need, and then discard the packet if the attacker altered it to the potential detriment of the middlebox. Russ At 09:36 PM 12/28/2009, Bhatia, Manav (Manav) wrote: >Yes, this was discussed in the WG >(http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104) and the idea was this: > >We could have some malicious entity that could modify the offsets to >ensure that the intermediaries don't parse a portion of the payload >(which could contain malicious content) or inspect it differently >than what it would have done otherwise. A way to protect against >such attacks is to let the end node validate the WESP header by >including this as a part of the ESP ICV. If the computed ICV does >not match, the packet is dropped (usual IPSec processing). > >This does not completely eliminate the vulnerability, but it does >raise the bar, because now the malicious routers would have to also >position themselves both before and after the middle boxes in order >to have a chance to revert the packet back to its original form >before the end node verifies integrity over the packet. > >We have also discussed this in the Security Considerations section >of the draft. > >We did informally speak to HW guys who are interested in >implementing WESP, and they confirmed that increasing the integrity >protection of ESP to now cover the WESP header is trivial. > >Cheers, Manav > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > > On Behalf Of Jack Kohn > > Sent: Tuesday, December 29, 2009 6.17 AM > > To: Stephen Kent > > Cc: ipsec@ietf.org; Russ Housley; iesg@ietf.org; Dan McDonald > > Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility > > > > Are you suggesting that ESP ICV should not cover the WESP fields? > > > > I think, and my memory could be failing me, that this was discussed in > > the WG before this got added to the draft. > > > > Jack > > > > On Tue, Dec 29, 2009 at 2:15 AM, Stephen Kent wrote: > > > Yaron, > > > > > > I hate to admit it, but I lost track of the details of WESP > > as it progressed > > > through WG discussions and briefings at IETF meetings. When > > I read the I-D > > > in detail, I was very surprised to see that it was no longer a > > > neatly-layered wrapper, as originally proposed. The fact > > that it now calls > > > for the ESP ICV to be computed in a new fashion means that > > it really is > > > replacing ESP, when used to mark ESP-NULL packets. > > > > > > From a protocol design perspective, the current version > > makes no sense to > > > me. Why keep the ESP header when ESP processing is now changed in a > > > significant way. The WESP header cannot be processed > > (completely) by > > > itself, because of the dependence on the ESP ICV. So it > > makes little or no > > > sense to retain the ESP header in this context. I see no > > strong backward > > > compatibility motivation for this format, given that ESP > > processing must > > > change to accommodate WESP (as defined). > > > > > > The issue of using WESP for marking encrypted traffic is a > > separate topic. I > > > believe the rationale you cited was to enable WESP > > extensions, but I may > > > have missed other arguments put forth for this. Since most > > of the WESP > > > extension proposals discussed so far have proven to be > > questionable, I am > > > not enthusiastic about that rationale. Others have noted > > that using WESP > > > with encrypted traffic is not consistent with the scope of > > the WG charter > > > item that authorized work on WESP. Unless Pasi approves a > > WESP extension WG > > > item as part of re-chartering, I think it is inappropriate > > to have a flag to > > > mark a WESP payload as encrypted. > > > > > > Steve > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From kent@bbn.com Tue Dec 29 07:47: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 07E2F3A68B6; Tue, 29 Dec 2009 07:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 PHCuqSz-gNca; Tue, 29 Dec 2009 07:47:46 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 4B74A3A688A; Tue, 29 Dec 2009 07:47:46 -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 1NPeI8-0000nm-Cb; Tue, 29 Dec 2009 10:47:25 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF893F0B9@il-ex01.ad.checkpoint.com> Date: Tue, 29 Dec 2009 10:47:22 -0500 To: Jack Kohn From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , Russ Housley , "iesg@ietf.org" , Dan McDonald Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility 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, 29 Dec 2009 15:47:47 -0000 At 6:17 AM +0530 12/29/09, Jack Kohn wrote: >Are you suggesting that ESP ICV should not cover the WESP fields? > >I think, and my memory could be failing me, that this was discussed in >the WG before this got added to the draft. > >Jack I am suggesting that WESP should be cleanly layered, in one of two ways: - do not interfere with the ESP ICV computation (be unauthenticated, for the reasons already noted by Tero and Russ) - incorporate the necessary info from the ESP header and not replicate the ESP structure, i.e., become a full-fledged alternative to ESP-NULL (not for ESP when confidentiality is employed) when end systems are configured to expose encapsulated header info to middle boxes. The current design is a hybrid that imposes undue complexity on IPsec implementations. Steve