From root@core3.amsl.com Tue Jun 1 00:15:06 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 329D23A692E; Tue, 1 Jun 2010 00:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100601071504.329D23A692E@core3.amsl.com> Date: Tue, 1 Jun 2010 00:15:03 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ipsec-ha-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: Tue, 01 Jun 2010 07:15:08 -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 : IPsec High Availability and Load Sharing Problem Statement Author(s) : Y. Nir Filename : draft-ietf-ipsecme-ipsec-ha-04.txt Pages : 12 Date : 2010-06-01 This document describes a requirement from IKE and IPsec to allow for more scalable and available deployments for VPNs. It defines A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsec-ha-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-ipsec-ha-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-01001147.I-D@ietf.org> --NextPart-- From ynir@checkpoint.com Tue Jun 1 01:01:53 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEFAE3A684B for ; Tue, 1 Jun 2010 01:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 dVEKlrk6bcUI for ; Tue, 1 Jun 2010 01:01:53 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 5865D3A6939 for ; Tue, 1 Jun 2010 01:01:52 -0700 (PDT) X-CheckPoint: {4C04CA88-2-1B201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o5181dAg006573 for ; Tue, 1 Jun 2010 11:01:39 +0300 (IDT) 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 Jun 2010 11:02:06 +0300 From: Yoav Nir To: "ipsec@ietf.org" Date: Tue, 1 Jun 2010 11:02:05 +0300 Thread-Topic: I-D Action:draft-ietf-ipsecme-ipsec-ha-04.txt Thread-Index: AcsBWkgqB6w671+mT0GuNLW+/rb3OQABkhIg Message-ID: <006FEB08D9C6444AB014105C9AEB133FB49CC7596F@il-ex01.ad.checkpoint.com> References: <20100601071504.329D23A692E@core3.amsl.com> In-Reply-To: <20100601071504.329D23A692E@core3.amsl.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] I-D Action:draft-ietf-ipsecme-ipsec-ha-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: Tue, 01 Jun 2010 08:01:53 -0000 Hi. This draft revision includes comments from Jean-Michel Combes and Yaron. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, June 01, 2010 10:15 AM To: i-d-announce@ietf.org Cc: ipsec@ietf.org Subject: I-D Action:draft-ietf-ipsecme-ipsec-ha-04.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wor= king Group of the IETF. Title : IPsec High Availability and Load Sharing Problem Stateme= nt Author(s) : Y. Nir Filename : draft-ietf-ipsecme-ipsec-ha-04.txt Pages : 12 Date : 2010-06-01 This document describes a requirement from IKE and IPsec to allow for more scalable and available deployments for VPNs. It defines A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsec-ha-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. From dennis.kuegler@bsi.bund.de Tue Jun 1 06:18:19 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FDFF28C117 for ; Tue, 1 Jun 2010 06:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 Jdp7tXvR3z8F for ; Tue, 1 Jun 2010 06:18:18 -0700 (PDT) Received: from m3-bn.bund.de (m3-bn.bund.de [77.87.228.75]) by core3.amsl.com (Postfix) with ESMTP id 09D3028C11D for ; Tue, 1 Jun 2010 06:18:16 -0700 (PDT) Received: from m3.mfw.bn.ivbb.bund.de (localhost [127.0.0.1]) by m3-bn.bund.de (8.13.8/8.13.8) with ESMTP id o51DI2UF005407 for ; Tue, 1 Jun 2010 15:18:02 +0200 (CEST) Received: (from localhost) by m3.mfw.bn.ivbb.bund.de (MSCAN) id 4/m3.mfw.bn.ivbb.bund.de/smtp-gw/mscan; Tue Jun 1 15:18:02 2010 X-Virus-Scanned: by amavisd-new at bsi.bund.de From: Dennis =?iso-8859-1?q?K=FCgler?= Organization: BSI Bonn To: "Dan Harkins" Date: Tue, 1 Jun 2010 15:17:44 +0200 User-Agent: KMail/1.9.10 (enterprise35 20100401.1112527) References: <3ed604c92cb4ccc78ffaf0486db97ff7.squirrel@www.trepanning.net> <201005261418.56567.dennis.kuegler@bsi.bund.de> In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201006011517.44654.dennis.kuegler@bsi.bund.de> X-AntiVirus: checked by Avira MailGate (version: 3.1.2; AVE: 8.2.1.242; VDF: 7.10.7.208; host: sgasmtp2.bsi.de); id=32241-G3AdRA Cc: ipsec@ietf.org Subject: Re: [IPsec] PAKE selection: SPSK X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 13:18:19 -0000 Hi Dan, Let's have a closer look at the patent. > You don't mention any specific claim from the SPEKE patent so let me > address the first independent claim (there are many claims dependent on > that one). The patent I'm referring to is US 6,792,533 dated Sept 14, 2004. > The claim says: > > "A cryptographic method for providing authentication, comprising: What's claimed is a method comprising four parts. All of them are contained in SPSK. > providing a password-based value to a first party and a second party; A value derived from the password is given to (calculated by) both parties. This is clearly the case in SPSK as psk is derived from the password. > selecting a parameter based on said password-based value, said > parameter defining one of a plurality of unauthenticated key > distribution techniques; SPSK selects a parameter, SKE, from the password-based value psk. SKE is then used as the generator for a (masked) Diffie-Hellman key agreement. Due to the group generator SKE, a pluralty of key distribution techniques is defined - one for each possible (and secret) value of SKE. > generating by said first party, in cooperation with said second party, > a cryptographic key based on said one of the plurality of > unauthenticated key distribution techniques, wherein said second > party cooperates in generating said cryptographic key by using > said one of the plurality of unauthenticated key distribution > techniques defined by said first value; and The derived shared secret ss is a cryptographic key derived from a masked Diffie-Hellman key agreement based on the secret group generator SKE. > providing authentication of said first party to said second party > based on said cryptographic key." This is the calculation of the Tag using the cryptographic key ss. > > Now first of all, that is very broadly worded. Every password-based > protocol provides a password to the first party and second party. But > there's more to this claim so SPEKE doesn't cover every single protocol > that distributes and uses passwords. Actually, in contrast to other patents this one is rather clear. It describes exactly a key distribution mechanism based on a parameter derived from a password. This is what SPSK does similarly. > > The next part talks about selecting a parameter based on the password > value and dragonfly certainly does that but the important part of this > portion of the claim, and the following part of the claim, is the > "plurality of unauthenticated key distribution techniques". What is that? See above. By selecting an alternative group generator (SKE instead of g) and using an anonymous (and masked) Diffie-Hellman key exchange a plurality of unauthenticated key distribution techniques is defined. > > There are different kinds of public key distribution systems where there > is a "private key" and a "public key" which is based on the "private > key". Earlier in the descriptive portion of the patent (which is not > part of a claim but can be used to interpret a claim) it says "SPEKE can > also use other unauthenticated public-key distribution systems, such as > the Modified Diffie-Hellman" and goes on to show an example of that. I > don't believe that the Modified D-H alone comprises a "plurality of > unauthenticated key distribution techniques." I would also imagine that > a static-ephemeral D-H or a static-static D-H that used a password-derived > parameter to perform that particular type of unauthenticated key > distribution technique would probably be covered. I don't get your point. This is probably to make clear that e.g. a masked Diffie-Hellman is also covered by the patent??? > > What is common on all these unauthenticated key distribution > techniques is how a public key based on the private key is distributed > to the other party. The private key is communicated in an obfuscated > form based on the discrete logarithm problem-- e.g. pub = g^priv mod p. > That is not done in dragonfly. There are two general approaches: The first approach is to "scramble" the public key (EKE) and to keep the private key unaltered and the other approach is to send the public key in clear but to indirectly alter the private by modifying the parameters. > > In dragonfly the private key is obfuscated by adding it to a random > number modulus the order of the group. The random number is unmasked > in a fashion that gives the private key to the second party in a form > that does not let it know the private key. Such a technique is new and > novel and not part of any known "plurality of unauthenticated key > distribution techniques". The obfuscation is cryptographically not sound. As you transmit both Scalar = (private + mask) and Element = SKE^(-mask) simultaneously anyone can compute the public key SKE^private = Element*SKE^Scalar (in which case we're back to SPEKE). This construction however unnecessarily risks to leak the private key, as any bias in the random number generation will reveal information on the private key. Especially when computing random numbers modulo a prime preventing a bias is not trivial. > > So it is my contention that for this claim to apply then both a > password-based parameter must be used AND that password-based parameter > must be used with a known technique of unauthenticated key distribution. > It is not and this claim does not apply to dragonfly. I disagree. It does very well apply to SPSK/dragonfly. > > If it was not claim 1 that you were referring to above then please > say exactly what claim in the SPEKE patent you are talking about. > > > - "Dragonfly is secure and has received cryptographic review". Please > > provide > > a reference to the cryptographically reviewed document. > > Both the IEEE 802.11 TGs Draft and the EAP-pwd variant have been > reviewed. So nothing has been published and has been reviewed by the cryptographic community? > > > - The construction used for computing the group generator is susceptible > > to > > side channel (timing) attacks and may leak the shared password. I'd > > therefore > > recommend to replace the randomized search algorithm by a deterministc > > algorithm. > > I had a discussion about that. The IEEE 802.11 TGs Draft had a password > element created based on the password before the exchange started > (it was computed a configuration time when a particular group was > selected). Then, when the exchange started the identities of the two > parties were run through the random function and used in the "scalar-op" > to derive a pair-wise unique element with which to do dragonfly. This > would foil the side channel attack. But I was convinced that this was not > so important and eliminated the extra step to provide ease of analysis. > If you think this is important the SPSK draft could certainly introduce > this technique to get around a side channel attack. I think that should be addressed. > > I'm not so sure how important that is though (basically I was convinced > it's not so important). If you know I can find a solution to the curve the > first time you can eliminate some passwords from the pool of potential > passwords but you don't know which ones unless you have run them all > through the algorithm beforehand. And even if you have run all possible > password through the algorithm it certainly doesn't leak the shared > password, it just allows the attacker to eliminate some passwords from > the pool of potential passwords. And to do so this attack has to be > mounted and that is not a trivial attack. If the attacker can eleminate only a few passwords every time you execute the protocol he's done with the attack quickly. Best regards, Dennis From dennis.kuegler@bsi.bund.de Tue Jun 1 06:20:19 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8CC3A687A for ; Tue, 1 Jun 2010 06:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 MV8ihpYrf10C for ; Tue, 1 Jun 2010 06:20:18 -0700 (PDT) Received: from m3-bn.bund.de (m3-bn.bund.de [77.87.228.75]) by core3.amsl.com (Postfix) with ESMTP id D9A513A67CC for ; Tue, 1 Jun 2010 06:20:16 -0700 (PDT) Received: from m3.mfw.bn.ivbb.bund.de (localhost [127.0.0.1]) by m3-bn.bund.de (8.13.8/8.13.8) with ESMTP id o51DK3uH019990 for ; Tue, 1 Jun 2010 15:20:03 +0200 (CEST) Received: (from localhost) by m3.mfw.bn.ivbb.bund.de (MSCAN) id 4/m3.mfw.bn.ivbb.bund.de/smtp-gw/mscan; Tue Jun 1 15:20:03 2010 X-Virus-Scanned: by amavisd-new at bsi.bund.de From: Dennis =?iso-8859-1?q?K=FCgler?= Organization: BSI Bonn To: "Dan Harkins" Date: Tue, 1 Jun 2010 15:19:36 +0200 User-Agent: KMail/1.9.10 (enterprise35 20100401.1112527) References: <201005261337.14090.dennis.kuegler@bsi.bund.de> <8a7891f3e8674b766ae45a2c51ed1578.squirrel@www.trepanning.net> In-Reply-To: <8a7891f3e8674b766ae45a2c51ed1578.squirrel@www.trepanning.net> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201006011519.36069.dennis.kuegler@bsi.bund.de> X-AntiVirus: checked by Avira MailGate (version: 3.1.2; AVE: 8.2.1.242; VDF: 7.10.7.208; host: sgasmtp2.bsi.de); id=32268-nHgTnT Cc: ipsec@ietf.org Subject: Re: [IPsec] PAKE selection: PACE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 13:20:19 -0000 Hi Dan, > Hi Dennis, > > I have read the PACE submission. I believe claim 1 of the SPEKE patent, > US 6,792,533, covers this protocol. If you do think otherwise, please > explain why. This is very simple. The password is only temporarily used to protect a nonce sent to the other party. The key derivation step is completely independent of the password. > > Also, in PACE you compute CIPH=E(Pwd, s) where E() is the encryption > function of some block cipher and Pwd is the shared password. You don't > mention the block cipher but some block ciphers have weak keys and most > take a fixed-length key. Pwd is a key derived from the password, so length constrainst are no problem. The block cipher is used as a permutation mapping random input to random output. The strength of the password-derived key is not very important as the entropy of the key is at most the entropy of the password - which is rather low. > For a general specification like this I suggest > strengthening it by removing any kind of dependencies and also to bind > the parties to the exchange. I suggest using an "extraction" function with > the shared password and the identities of the two peers to distill the > entropy from the password, bind the identities, and derive a key with > which to do the encryption: > > k = Extractor(Pwd | max(ID-A, ID-B) | min(ID-A, ID-B)) > CIPH = E(k, s) > > where max(x,y) and min(x,y) output an ordering their inputs in some > deterministic fashion, ID-A and ID-B are the identities of the two parties > to the exchange, and "|" is concatenation. I don't see the point of binding the key to identities, but I might miss something here. Best regards, Dennis From dharkins@lounge.org Tue Jun 1 09:13:47 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2663228C0DE for ; Tue, 1 Jun 2010 09:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.312 X-Spam-Level: X-Spam-Status: No, score=-3.312 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, 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 qiV7LgGAWk4X for ; Tue, 1 Jun 2010 09:13:45 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id D77903A6A43 for ; Tue, 1 Jun 2010 09:13:45 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id CCAA41022404C; Tue, 1 Jun 2010 09:13:33 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 1 Jun 2010 09:13:33 -0700 (PDT) Message-ID: <868dbee876960a6ef8a3d37bded2df30.squirrel@www.trepanning.net> In-Reply-To: <201006011519.36069.dennis.kuegler@bsi.bund.de> References: <201005261337.14090.dennis.kuegler@bsi.bund.de> <8a7891f3e8674b766ae45a2c51ed1578.squirrel@www.trepanning.net> <201006011519.36069.dennis.kuegler@bsi.bund.de> Date: Tue, 1 Jun 2010 09:13:33 -0700 (PDT) From: "Dan Harkins" To: Dennis =?iso-8859-1?Q?K=FCgler?= 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] PAKE selection: PACE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 16:13:47 -0000 Hi Dennis, You made a very vague statement (SPEKE patent infringes on dragonfly). I made a very detailed response to it, using the first independent claim in a patent describing SPEKE, explaining why it did not apply. Now I make a detailed statement (SPEKE patent infringes on PACE, and specifically it's the first independent claim of US 6,792,533). You then make a vague response about how a password is used "only temporarily", which responds neither to my statement nor to the specific claim in the specific patent I mentioned, and then something that is just factually incorrect: "[t]he key derivation step is completely independent of the password." Try again, please. Make a detailed response to each part of the claim and explain what in the claim does not apply to your proposal and why. Give my statements the same level of respect that I have given yours. regards, Dan. On Tue, June 1, 2010 6:19 am, Dennis Kügler wrote: > Hi Dan, >> Hi Dennis, >> >> I have read the PACE submission. I believe claim 1 of the SPEKE >> patent, >> US 6,792,533, covers this protocol. If you do think otherwise, please >> explain why. > > This is very simple. The password is only temporarily used to protect a > nonce > sent to the other party. The key derivation step is completely independent > of > the password. From root@core3.amsl.com Tue Jun 1 11:30:14 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C86CC3A68B3; Tue, 1 Jun 2010 11:30:13 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100601183013.C86CC3A68B3@core3.amsl.com> Date: Tue, 1 Jun 2010 11:30:13 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-eap-mutual-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: Tue, 01 Jun 2010 18:30:14 -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 : An Extension for EAP-Only Authentication in IKEv2 Author(s) : P. Eronen, et al. Filename : draft-ietf-ipsecme-eap-mutual-03.txt Pages : 15 Date : 2010-06-01 IKEv2 specifies that EAP authentication must be used together with public key signature based responder authentication. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one-time passwords or token cards. This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-eap-mutual-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-eap-mutual-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-01112210.I-D@ietf.org> --NextPart-- From dharkins@lounge.org Tue Jun 1 11:55:57 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EFDC28C0E8 for ; Tue, 1 Jun 2010 11:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, 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 Xg9BqqVe5ptB for ; Tue, 1 Jun 2010 11:55:55 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 530013A6A48 for ; Tue, 1 Jun 2010 11:55:55 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id CB44B1022404C; Tue, 1 Jun 2010 11:55:42 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 1 Jun 2010 11:55:43 -0700 (PDT) Message-ID: <2354574b94c9b8805fb3f2bcc6f995b5.squirrel@www.trepanning.net> In-Reply-To: <201006011517.44654.dennis.kuegler@bsi.bund.de> References: <3ed604c92cb4ccc78ffaf0486db97ff7.squirrel@www.trepanning.net> <201005261418.56567.dennis.kuegler@bsi.bund.de> <201006011517.44654.dennis.kuegler@bsi.bund.de> Date: Tue, 1 Jun 2010 11:55:43 -0700 (PDT) From: "Dan Harkins" To: Dennis =?iso-8859-1?Q?K=FCgler?= 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] PAKE selection: SPSK X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 18:55:57 -0000 Hi Dennis, The issue here is the meaning of a "plurality of key distribution techniques." You say, "[d]ue to the group generator SKE, a pluralty of key distribution techniques is defined - one for each possible (and secret) value of SKE." That's not what the patent is talking about. The "plurality of key distribution techniques" describes different techniques of key distribution not a single technique being used with different passwords-- and therefore different SKEs. The descriptive portion of a patent (outside the claim) can be used to interpret what is said in a claim. The claim describes a "plurality of unauthenticated key distribution techniques" and looking at the patent you can see where it says, "SPEKE can also use other unauthenticated key distribution systems..." and goes on to describe one of them. What it describes is another technique at key distribution, not a repetition of a single one with different passwords (or keys). It's the other key distribution systems that comprise the plurality, not a singular system that's keyed using different passwords. The patent gives two examples, one being a straight-forward Diffie- Hellman and another being the Modified Diffie-Hellman. There are others, I would imagine, like El Gamal, that the patent holder would say falls into this claim. It's reasonable to assume that the holder of the patent doesn't want people to just use a different key distribution technique ("I'm doing Modified Diffie-Hellman not Diffie-Hellman so the patent doesn't apply"). The thing that D-H, Modified D-H, El Gamal, and static variants of D-H-- i.e other known techniques of unauthenticated key distribution-- is that the key being distributed is a secret (private key) that has been obfuscated in a form (a public key) so it cannot be recovered when distributed. All of these things have the following in common: public = g^private modulo prime (or equivalent ECC representation). That's the thing-- "public"-- that gets distributed whether you're doing plain-jane Diffie-Hellman, whether you're doing Modified Diffie-Hellman, whether you're doing El Gamal, in other words, when you're doing the "plurality of key distribution techniques". They all use the discrete logarithm problem to hide the private key and create a public key as part of their key distribution technique. Dragonfly's method of obfuscation of the private key to produce the public key is different than the others-- it uses addition modulo the ORDER of the group. public = private + mask modulo order It is different, unique, novel, new and therefore cannot be part of any claimed plurality of key distribution techniques. If you disagree, I defy you to show me mention of this technique anywhere to construct and distribute public keys out of private keys (or if you are claiming that a patent holder can patent today things that have not yet been invented then please make that claim). Down at the bottom of this email you mention that this method is "cryptographically not sound". First of all, I will note that this means you are, in fact, treating this technique differently than the others, since I don't believe you are claiming that Diffie-Hellman or El Gamal is "cryptographically not sound". That buttresses my statement above that this technique is different. Thank you for helping to prove my point. Regarding your claim, one has to know SKE to generate SKE^private and "anyone" does not know the password, so "anyone" cannot generate SKE^private. Also, you say the private key can be leaked. If you can show how a passive attacker can determine a private key in dragonfly-- even if you tell the passive attacker the password!-- I will show you how that very same attacker can solve the Computational Diffie-Hellman (CDH) problem with the same computational advantage. Since it is assumed that the CDH problem is computationally infeasible it can safely be assumed that the attack you suggest is also computationally infeasible. regards, Dan. On Tue, June 1, 2010 6:17 am, Dennis Kügler wrote: > Hi Dan, > > Let's have a closer look at the patent. > >> You don't mention any specific claim from the SPEKE patent so let me >> address the first independent claim (there are many claims dependent on >> that one). The patent I'm referring to is US 6,792,533 dated Sept 14, >> 2004. >> The claim says: >> >> "A cryptographic method for providing authentication, comprising: > > What's claimed is a method comprising four parts. All of them are > contained in > SPSK. > > >> providing a password-based value to a first party and a second >> party; > > A value derived from the password is given to (calculated by) both > parties. > This is clearly the case in SPSK as psk is derived from the password. > > >> selecting a parameter based on said password-based value, said >> parameter defining one of a plurality of unauthenticated key >> distribution techniques; > > SPSK selects a parameter, SKE, from the password-based value psk. SKE is > then > used as the generator for a (masked) Diffie-Hellman key agreement. Due to > the > group generator SKE, a pluralty of key distribution techniques is defined > - > one for each possible (and secret) value of SKE. > > >> generating by said first party, in cooperation with said second >> party, >> a cryptographic key based on said one of the plurality of >> unauthenticated key distribution techniques, wherein said second >> party cooperates in generating said cryptographic key by using >> said one of the plurality of unauthenticated key distribution >> techniques defined by said first value; and > > The derived shared secret ss is a cryptographic key derived from a masked > Diffie-Hellman key agreement based on the secret group generator SKE. > >> providing authentication of said first party to said second party >> based on said cryptographic key." > > This is the calculation of the Tag using the cryptographic key ss. > >> >> Now first of all, that is very broadly worded. Every password-based >> protocol provides a password to the first party and second party. But >> there's more to this claim so SPEKE doesn't cover every single protocol >> that distributes and uses passwords. > > Actually, in contrast to other patents this one is rather clear. It > describes > exactly a key distribution mechanism based on a parameter derived from a > password. This is what SPSK does similarly. > >> >> The next part talks about selecting a parameter based on the password >> value and dragonfly certainly does that but the important part of this >> portion of the claim, and the following part of the claim, is the >> "plurality of unauthenticated key distribution techniques". What is >> that? > > See above. By selecting an alternative group generator (SKE instead of g) > and > using an anonymous (and masked) Diffie-Hellman key exchange a plurality of > unauthenticated key distribution techniques is defined. > >> >> There are different kinds of public key distribution systems where >> there >> is a "private key" and a "public key" which is based on the "private >> key". Earlier in the descriptive portion of the patent (which is not >> part of a claim but can be used to interpret a claim) it says "SPEKE can >> also use other unauthenticated public-key distribution systems, such as >> the Modified Diffie-Hellman" and goes on to show an example of that. I >> don't believe that the Modified D-H alone comprises a "plurality of >> unauthenticated key distribution techniques." I would also imagine that >> a static-ephemeral D-H or a static-static D-H that used a >> password-derived >> parameter to perform that particular type of unauthenticated key >> distribution technique would probably be covered. > > I don't get your point. This is probably to make clear that e.g. a masked > Diffie-Hellman is also covered by the patent??? > >> >> What is common on all these unauthenticated key distribution >> techniques is how a public key based on the private key is distributed >> to the other party. The private key is communicated in an obfuscated >> form based on the discrete logarithm problem-- e.g. pub = g^priv mod p. >> That is not done in dragonfly. > > There are two general approaches: The first approach is to "scramble" the > public key (EKE) and to keep the private key unaltered and the other > approach > is to send the public key in clear but to indirectly alter the private by > modifying the parameters. > >> >> In dragonfly the private key is obfuscated by adding it to a random >> number modulus the order of the group. The random number is unmasked >> in a fashion that gives the private key to the second party in a form >> that does not let it know the private key. Such a technique is new and >> novel and not part of any known "plurality of unauthenticated key >> distribution techniques". > > The obfuscation is cryptographically not sound. As you transmit both > Scalar = > (private + mask) and Element = SKE^(-mask) simultaneously anyone can > compute > the public key SKE^private = Element*SKE^Scalar (in which case we're back > to > SPEKE). This construction however unnecessarily risks to leak the private > key, as any bias in the random number generation will reveal information > on > the private key. Especially when computing random numbers modulo a prime > preventing a bias is not trivial. > > >> >> So it is my contention that for this claim to apply then both a >> password-based parameter must be used AND that password-based parameter >> must be used with a known technique of unauthenticated key distribution. >> It is not and this claim does not apply to dragonfly. > > I disagree. It does very well apply to SPSK/dragonfly. > >> >> If it was not claim 1 that you were referring to above then please >> say exactly what claim in the SPEKE patent you are talking about. >> >> > - "Dragonfly is secure and has received cryptographic review". Please >> > provide >> > a reference to the cryptographically reviewed document. >> >> Both the IEEE 802.11 TGs Draft and the EAP-pwd variant have been >> reviewed. > > So nothing has been published and has been reviewed by the cryptographic > community? > >> >> > - The construction used for computing the group generator is >> susceptible >> > to >> > side channel (timing) attacks and may leak the shared password. I'd >> > therefore >> > recommend to replace the randomized search algorithm by a deterministc >> > algorithm. >> >> I had a discussion about that. The IEEE 802.11 TGs Draft had a >> password >> element created based on the password before the exchange started >> (it was computed a configuration time when a particular group was >> selected). Then, when the exchange started the identities of the two >> parties were run through the random function and used in the "scalar-op" >> to derive a pair-wise unique element with which to do dragonfly. This >> would foil the side channel attack. But I was convinced that this was >> not >> so important and eliminated the extra step to provide ease of analysis. >> If you think this is important the SPSK draft could certainly introduce >> this technique to get around a side channel attack. > > I think that should be addressed. > >> >> I'm not so sure how important that is though (basically I was >> convinced >> it's not so important). If you know I can find a solution to the curve >> the >> first time you can eliminate some passwords from the pool of potential >> passwords but you don't know which ones unless you have run them all >> through the algorithm beforehand. And even if you have run all possible >> password through the algorithm it certainly doesn't leak the shared >> password, it just allows the attacker to eliminate some passwords from >> the pool of potential passwords. And to do so this attack has to be >> mounted and that is not a trivial attack. > > If the attacker can eleminate only a few passwords every time you execute > the > protocol he's done with the attack quickly. > > Best regards, > > Dennis > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From dennis.kuegler@bsi.bund.de Wed Jun 2 01:46:24 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA3353A6968 for ; Wed, 2 Jun 2010 01:46:23 -0700 (PDT) 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.300, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_17=0.6, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 722zFWjH7T8E for ; Wed, 2 Jun 2010 01:46:21 -0700 (PDT) Received: from m2-bn.bund.de (m2-bn.bund.de [77.87.228.74]) by core3.amsl.com (Postfix) with ESMTP id 2EC283A684B for ; Wed, 2 Jun 2010 01:46:20 -0700 (PDT) Received: from m2.mfw.bn.ivbb.bund.de (localhost [127.0.0.1]) by m2-bn.bund.de (8.13.8/8.13.8) with ESMTP id o528k5A4028921 for ; Wed, 2 Jun 2010 10:46:05 +0200 (CEST) Received: (from localhost) by m2.mfw.bn.ivbb.bund.de (MSCAN) id 4/m2.mfw.bn.ivbb.bund.de/smtp-gw/mscan; Wed Jun 2 10:46:05 2010 X-Virus-Scanned: by amavisd-new at bsi.bund.de From: Dennis =?iso-8859-1?q?K=FCgler?= Organization: BSI Bonn To: ipsec@ietf.org Date: Wed, 2 Jun 2010 10:45:43 +0200 User-Agent: KMail/1.9.10 (enterprise35 20100401.1112527) References: <3ed604c92cb4ccc78ffaf0486db97ff7.squirrel@www.trepanning.net> <201006011517.44654.dennis.kuegler@bsi.bund.de> <2354574b94c9b8805fb3f2bcc6f995b5.squirrel@www.trepanning.net> In-Reply-To: <2354574b94c9b8805fb3f2bcc6f995b5.squirrel@www.trepanning.net> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201006021045.43514.dennis.kuegler@bsi.bund.de> X-AntiVirus: checked by Avira MailGate (version: 3.1.2; AVE: 8.2.1.242; VDF: 7.10.7.210; host: sgasmtp2.bsi.de); id=9395-Js1Ld3 Subject: Re: [IPsec] PAKE selection: SPSK X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 08:46:24 -0000 Hi Dan, > > The issue here is the meaning of a "plurality of key distribution > techniques." So let's have again a look at the claim: [...] selecting a parameter based on said password-based value, said parameter defining one of a plurality of unauthenticated key distribution techniques; [...] It explains very clearly that the key distribution mechanism to be used is defined by a parameter, which is derived from the password. I don't think that you can interpret this differently. SPEKE does this by selecting the parameter as group generator but also claims any other method. SPSK does this similarly. > > You say, "[d]ue to the group generator SKE, a pluralty of key > distribution techniques is defined - one for each possible (and secret) > value of SKE." That's not what the patent is talking about. The "plurality > of key distribution techniques" describes different techniques of key > distribution not a single technique being used with different passwords-- > and therefore different SKEs. ...based on the password??? Strange interpretation, but I don't think that we'll find consens on that and therefore I skip this discussion here. > > The thing that D-H, Modified D-H, El Gamal, and static variants of D-H-- > i.e other known techniques of unauthenticated key distribution-- is that > the key being distributed is a secret (private key) that has been > obfuscated in a form (a public key) so it cannot be recovered when > distributed. All of these things have the following in common: > > public = g^private modulo prime > > (or equivalent ECC representation). That's the thing-- "public"-- that > gets distributed whether you're doing plain-jane Diffie-Hellman, whether > you're doing Modified Diffie-Hellman, whether you're doing El Gamal, > in other words, when you're doing the "plurality of key distribution > techniques". They all use the discrete logarithm problem to hide > the private key and create a public key as part of their key distribution > technique. > > Dragonfly's method of obfuscation of the private key to produce the > public key is different than the others-- it uses addition modulo the > ORDER of the group. > > public = private + mask modulo order > > It is different, unique, novel, new and therefore cannot be part of any > claimed plurality of key distribution techniques. If you disagree, I defy > you to show me mention of this technique anywhere to construct and > distribute public keys out of private keys (or if you are claiming that > a patent holder can patent today things that have not yet been invented > then please make that claim). As I've already tried to explain in my last mail, you not only define public1 = private + mask but also public2 = g^(-mask) which finally can be combined to (by everyone) public = public2 * g^public1 = g^(-mask + private + mask)= g^private The obfuscation step isn't obfuscating the public key at all, it just introduces potential problems as the OTP on the private key very likely leaks information, if not applied correctly. The correct application of a OTP is not trivial especially if the OTP is applied modulo a prime. This is why I called it cryptographically not sound as this step is not giving you any benefit but may cause a lot of problems. > > Down at the bottom of this email you mention that this method is > "cryptographically not sound". First of all, I will note that this means > you are, in fact, treating this technique differently than the others, > since I don't believe you are claiming that Diffie-Hellman or El Gamal > is "cryptographically not sound". That buttresses my statement above > that this technique is different. Thank you for helping to prove my > point. You're welcome. Although I don't think that it'll help you to convince the patent holder. > > Regarding your claim, one has to know SKE to generate SKE^private > and "anyone" does not know the password, so "anyone" cannot generate > SKE^private. > > Also, you say the private key can be leaked. If you can show how a > passive attacker can determine a private key in dragonfly-- even if > you tell the passive attacker the password!-- I will show you how that > very same attacker can solve the Computational Diffie-Hellman (CDH) > problem with the same computational advantage. Since it is assumed that > the CDH problem is computationally infeasible it can safely be assumed > that the attack you suggest is also computationally infeasible. I'm looking forward to that. When can we expect a full paper? Best regards, Dennis From dharkins@lounge.org Wed Jun 2 09:24:58 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6253A6828 for ; Wed, 2 Jun 2010 09:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, 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 UQXa-ctyPLfD for ; Wed, 2 Jun 2010 09:24:57 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 4E7613A63C9 for ; Wed, 2 Jun 2010 09:24:57 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C4C581022404C; Wed, 2 Jun 2010 09:24:44 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 2 Jun 2010 09:24:44 -0700 (PDT) Message-ID: In-Reply-To: <201006021045.43514.dennis.kuegler@bsi.bund.de> References: <3ed604c92cb4ccc78ffaf0486db97ff7.squirrel@www.trepanning.net> <201006011517.44654.dennis.kuegler@bsi.bund.de> <2354574b94c9b8805fb3f2bcc6f995b5.squirrel@www.trepanning.net> <201006021045.43514.dennis.kuegler@bsi.bund.de> Date: Wed, 2 Jun 2010 09:24:44 -0700 (PDT) From: "Dan Harkins" To: Dennis =?iso-8859-1?Q?K=FCgler?= 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] PAKE selection: SPSK X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 16:24:58 -0000 Hi Dennis, >> You say, "[d]ue to the group generator SKE, a pluralty of key >> distribution techniques is defined - one for each possible (and secret) >> value of SKE." That's not what the patent is talking about. The >> "plurality >> of key distribution techniques" describes different techniques of key >> distribution not a single technique being used with different >> passwords-- >> and therefore different SKEs. > > ...based on the password??? Strange interpretation, but I don't think that > we'll find consens on that and therefore I skip this discussion here. The strange interpretation is all yours. You said "one for each possible (and secret) value of SKE." Different values of SKE occur through different passwords. I agree there is no consensus on your view of this matter because it is not supported by descriptive text in the rest of the patent. >> Down at the bottom of this email you mention that this method is >> "cryptographically not sound". First of all, I will note that this means >> you are, in fact, treating this technique differently than the others, >> since I don't believe you are claiming that Diffie-Hellman or El Gamal >> is "cryptographically not sound". That buttresses my statement above >> that this technique is different. Thank you for helping to prove my >> point. > > You're welcome. Although I don't think that it'll help you to convince the > patent holder. Thank you for offering your personal opinion. Let me return the favor: I think it's more convincing that making irrelevant remarks ("the password is only temporarily used") followed by incorrect statements ("the key derivation is completely independent of the password"). >> Regarding your claim, one has to know SKE to generate SKE^private >> and "anyone" does not know the password, so "anyone" cannot generate >> SKE^private. >> >> Also, you say the private key can be leaked. If you can show how a >> passive attacker can determine a private key in dragonfly-- even if >> you tell the passive attacker the password!-- I will show you how that >> very same attacker can solve the Computational Diffie-Hellman (CDH) >> problem with the same computational advantage. Since it is assumed that >> the CDH problem is computationally infeasible it can safely be assumed >> that the attack you suggest is also computationally infeasible. > > I'm looking forward to that. And I'm looking forward to giving it to you :-) But I said "if you can show me how a passive attacker can determine a private key...." so the proverbial ball is in your court. Show me how a passive attack can successfully obtain either private key in dragonfly (not something that begins "well, if he uses a bad random number generator..." which is not an attack against the protocol) and I'll show you how you can solve the CDH. > When can we expect a full paper? Real Soon Now (tm). I know you are aware that it is time consuming and not a trivial task. But something that is much easier is for you to do a full and adequate response to my previous statement on PACE-- it infringes on claims 1 and 10 of US 6,792,533. When can we expect that? It is quite telling that you apparently do not wish to engage in the same sort of detailed analysis of PACE that you do with dragonfly. regards, Dan. From paul.hoffman@vpnc.org Fri Jun 4 14:10:15 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B443A6A46 for ; Fri, 4 Jun 2010 14:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.177 X-Spam-Level: * X-Spam-Status: No, score=1.177 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_60=1, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSjez4Lu+xG3 for ; Fri, 4 Jun 2010 14:10:13 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id BA97F3A6A14 for ; Fri, 4 Jun 2010 14:10:11 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o54L9ujn019559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 Jun 2010 14:09:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 4 Jun 2010 14:09:55 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Beginning the PAKE selection process X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 21:10:15 -0000 Two and a half weeks later, we only have contributions on these threads from people who have proposed algorithms, plus one other WG member. Wearing my WG co-chair hat, I would like to find out why. Please respond on the list or, only if you feel it is necessary, off-list. --Paul Hoffman, Director --VPN Consortium From dharkins@lounge.org Fri Jun 4 16:09:16 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA9428B23E for ; Fri, 4 Jun 2010 16:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_60=1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 4tbPaNzpXvJ0 for ; Fri, 4 Jun 2010 16:09:14 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id C35593A6989 for ; Fri, 4 Jun 2010 16:09:10 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id A95AD1022404C; Fri, 4 Jun 2010 16:08:56 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 4 Jun 2010 16:08:56 -0700 (PDT) Message-ID: <18f85715daf1245213a6d392f84dcd39.squirrel@www.trepanning.net> In-Reply-To: <201006011519.36069.dennis.kuegler@bsi.bund.de> References: <201005261337.14090.dennis.kuegler@bsi.bund.de> <8a7891f3e8674b766ae45a2c51ed1578.squirrel@www.trepanning.net> <201006011519.36069.dennis.kuegler@bsi.bund.de> Date: Fri, 4 Jun 2010 16:08:56 -0700 (PDT) From: "Dan Harkins" To: Dennis =?iso-8859-1?Q?K=FCgler?= 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] PAKE selection: PACE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 23:09:16 -0000 Hi Dennis, On Tue, June 1, 2010 6:19 am, Dennis Kügler wrote: > Hi Dan, >> Hi Dennis, >> >> I have read the PACE submission. I believe claim 1 of the SPEKE >> patent, >> US 6,792,533, covers this protocol. If you do think otherwise, please >> explain why. > > This is very simple. The password is only temporarily used to protect a > nonce > sent to the other party. The key derivation step is completely independent > of > the password. The "temporary" use of a password has nothing to do with anything in claim 1 of US 6,792,533. And the key derivation does rely on the password. Without knowledge of the password it is not possible to derive the key. That is the whole point of running your protocol. Let me provide a more detailed look into PACE's infringement on the SPEKE patent using a paper entitled "Security Analysis of the PACE Key Agreement Protocol" by J. Bender, M. Fischlin, and you, Dennis Kugler. I'll refer to this as "the PACE paper". The SPEKE patent says that "a function of the password determines parameters of a public-key distribution system, such as a Diffie-Hellman ('DH') key exchange." In particular, it chooses a generator, g, based on a function of the password, f(S) g = f(S) which is then used in the public-key distribution system, such as a Diffie-Hellman. The patent says, "We will show at least two public-key distributions systems that work with SPEKE", and it does. It shows SPEKE with the plain-jane Diffie-Hellman and the Modified Diffie-Hellman. So if you create a password-based parameter, like a generator, to the Diffie-Hellman or the Modified Diffie-Hellman key exchange, and then use that password-based parameter in the Diffie-Hellman (or Modified Diffie-Hellman) then you're basically doing SPEKE. Does PACE create a generator based on the password? Yes. The generator in a Diffie-Hellman key exchange is an element in the group. And the PACE paper defines a problem in its number theoretic assumptions section called the PACE-DH problem: the "PAssword-based Chosen-Element (PACE) DH problem". The security of PACE is based on using a password ("password-based") to choose a generator ("element") in which to do a Diffie-Hellman. According to the PACE paper it's doing g = f(S) and f(S) is based on the PACE-DH assumption. Does PACE use that chosen element, that generator, based on the password in a Diffie-Hellman exchange? Yes, it does. The paper says, "This generator is subsequently used to run a Diffie-Hellman key agreement to derive a common key K." It looks like PACE is SPEKE. The PACE paper describes the exchange in phases. It says, "In the first phase the chip sends a random nonce s encyrpted with the password to the terminal. In the second phase both parties execute an interactive protocol Map2Point, mapping the nonce to a random generateor G of a group, e.g. an elliptic curve (the group parameters are provided by the chip and authenticated by a governmental authority). In the third phase the two parties run a Diffie-Hellman (DH) key agreement on the agreed-upon generator G and use the DH key to derive the actual keys for subsequent use." It goes on to mention a "final authentication step" to "derive an ephemeral MAC key K'mac as K'mac = H(K || 3) and use this key for authentication." (Note: K is the result of the Diffie-Hellman and H is a hash function). Let's map that into the first independent claim from the SPEKE patent, the one that claims "A cryptographic method for providing authentication, comprising:" SPEKE patent: "providing a password-based value to a first party and a second party" PACE paper: "In the first phase the chip sends a random nonce s encrypted with the password to the terminal." Discussion: an encrypted nonce is a value and it is based on the password since the password was used to encrypt it. It's a password-based value and it's being provided. SPEKE patent: "selecting a parameter based on said password-based value, said parameter defining one of a plurality of unauthenticated key distribution techniques" PACE paper: "In the second phase both parties execute an interactive protocol Map2Point, mapping the nonce to a random generator G of a group, e.g. an elliptic curve" Discussion: the parameter defining one of a plurality of unauthenticated key distribution techniques is a generator for a Diffie-Hellman protocol. PACE computes a generator based on the nonce which was encrypted with the password. In other words, it selects a generator, a parameter, based on the aforementioned password-based value, the nonce. To use the terminology from the PACE paper, it does PAssword-based Chosen Element Diffie-Hellman (PACE-DH). SPEKE patent: "generating by said first party, in cooperation with said second party, a cryptographic key based on said one of the plurality of unauthenticated key distribution techniques, wherein said second party cooperates in generating said cryptographic key by using said one of the plurality of unauthenticated key distribution techniques defined by said first value" PACE paper: "In the third phase the two parties run a Diffie-Hellman (DH) key agreement on the agreed-upon generator G and use the DH key to derive the actual keys for subsequent use." Discussion: the two parties, in cooperation with each other, do one of the plurality of unauthenticated key distribution techniques that the aformentioned parameter is for. In other words, they do a Diffie-Hellman with the agreed-upon generator. And they generate "a cryptographic key", aka "the DH key." SPEKE patent: "providing authentication of said first party to said second party based on said cryptographic key" PACE paper: "derive an ephemeral MAC key K'mac as K'mac = H(K || 3) and use this key for authentication." Discussion: the key K is "said cryptographic key", it's the result of the Diffie-Hellman. And K'mac is definitely "based on" K since it's the output of a hash function to which K has is an input. And K'mac is used for authentication. So it provides authentication based on (a derivative of) the K, "said cryptographic key". There is a step-by-step match between the description of the PACE protocol from a paper describing it and the SPEKE patent. Quite obviously, PACE is SPEKE. Any "temporary" use of the password is really irrelevant, and, as your paper notes, the PAssword-based Chosen Element is used in a Diffie-Hellman to create a key, K. So the key can only be derived by knowing the password. regards, Dan. From turners@ieca.com Tue Jun 8 04:23:42 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8C728C164 for ; Tue, 8 Jun 2010 04:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001, 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 2UGJys3+057u for ; Tue, 8 Jun 2010 04:23:40 -0700 (PDT) Received: from smtp114.biz.mail.mud.yahoo.com (smtp114.biz.mail.mud.yahoo.com [209.191.68.79]) by core3.amsl.com (Postfix) with SMTP id 9756728C139 for ; Tue, 8 Jun 2010 04:23:40 -0700 (PDT) Received: (qmail 80061 invoked from network); 8 Jun 2010 11:23:31 -0000 Received: from thunderfish.local (turners@96.231.124.63 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 08 Jun 2010 04:23:30 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: Yb8zzagVM1kw_xfSLWUKjikC2uegTfMIK7sLY6LyXU1.a5GYLjAb9mPcahQLEPDSvjJjHZoxLXe9nhca8.IHE8nFKIV.P1NkJZGTmGMJcVl_Fq3U32qRjIEYq4ezYNHgCVeeXW49_TWEdbqA5.CvI3NkS3RuIGrl1w8X8gk4Au2w5POqmhsnhIc6ipa5JsKRLzuBEONiM0tm9aHU3uvRuc4FgSUGJmGNRW__DWxWc_yVH7vrmNvpI.GP0gmbEkUUTquTLw4zp5duRw.JVJoXInONLAVTeqnu8eWsSejTlFFsfg0EwUHqX.B4KUojWmj2E1M- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C0E2832.8050205@ieca.com> Date: Tue, 08 Jun 2010 07:23:30 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] AD review: draft-ietf-ipsecme-ipsec-ha X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 11:23:42 -0000 Yaron asked me to review draft-ietf-ipsecme-ipsec-ha on 2010-06-01. Here are my comments most of which are about clarifying text (so that readers who didn't participate in the WG discussions can understand this unambiguously), plus a couple of nits. Yoav, could you post a new version that addresses my comments before we start IETF Last Call? #1) Should this I-D have been called "IPsec Cluter Problem Statement" to more closely align with the charter? The header also? #2) The abstract needs to be clearer and more closely follow what's in the charter (I think the document does, but the abstract doesn't state it clearly). It states: This document describes a requirement from IKE and IPsec to allow for more scalable and available deployments for VPNs. It defines terminology for high availability and load sharing clusters implementing IKE and IPsec, and describes gaps in the existing standards. Is this a requirement "from" or "for" IKE/IPsec? I think it's supposed to be for. It's missing the "problem statement" text from the charter. How about the following suggested text: This document defines a set of terminology, a problem statement, and set of requirements for clusters implementing IKE and IPsec. It also describes gaps in the existing standards that need to be filled in order to allow peers to interoperate with clusters from different vendors. An agreed terminology, problem statement, and requirements will allow the IPSECME WG to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations. #3) I'd like to see "cluster" introduced in the 2nd paragraph of Section 1. It kind of jumps out in the 3rd para. by using more than one physical gateway to either share the load or back each other up (i.e., using a cluster). ^^^^^^^^^^^^^^^^^^^^^^^ #4) Section 1: r/organizations's/organization's #5) Section 2: In section 1, it specifically mentions that the gateways are physically separate. Should this also be worked in to the definition of cluster in section 2: "Cluster" is a set of two or more physically separated gateways, ^^^^^^^^^^^^^^^^^^^^ implementing the same security policy, and protecting the same domain. Clusters exist to provide both high availability through redundancy, and scalability through load sharing. #6) Section 2: Should this I-D explain or point (informatively) to how Availability is computed? #7) Section 2: HS Cluster (there might only be one other): r/whereas the others are/whereas the other(s) are #8) Section 2: LS Cluster: Can we replace: "and we don't want to even imply that this is a requirement" with "and this is not a requirement"? #9) Section 2: Failover (add ,): r/In a load sharing cluster/In a load sharing cluster, #10) Section 2: Loose Cluster: Is it that one address gets allocated to more than one member at failover, just one other, or can both happen? r/In some cases, members IP addresses may be allocated to other members at failover./In some cases, member's IP address(es) may be allocated to another member or members at failover. #11) Section 3.2: Spell out first instance of SAD (it's not in the RFC editor's expansion list:http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt). #12) Section 3.2 (last paragraph): The definition of High Availability states that it's not a configuration type, but in the following it sure does sound like it: "A naive implementation of a high availability cluster would have no synchronized state, and a failover would produce an effect similar to that of a rebooted gateway". Because all of the clusters in this document offer high availability can you just strike "high availability" from the sentence? #13) Section 3.3: This section needs to be rephrased as a problem statement not a solution. If the solution presented is a MUST requirement, then I'd like to see that stated clearly with a "MUST". #14) Assuming the sections 3.4 and 3.5 are about IPsec SA: r/SA/IPsec SA #15) Section 3.4-9: I'd like to see clear requirements language about what the mechanism(s) MUST/SHOULD/MAY support. #16) Section 3.4: Shouldn't the 'must not' be "MUST NOT"? #17) Section 3.5 (knowing people will want to verify this statement): Please provide a pointer to where this is: This is allowed by the standards, because replay counter verification is an optional feature. i.e., see section x of [RFCXYZ]. #18) Section 3.6: All the clusters are highly available: r/a high availability cluster/a cluster #19) Section 3.7, spell out first instance of HA and add it to the definition in Section 2. #20) Section 3.7: what's a "commodity load balancer"? #21) Section 3.7 to make the two category sentence work, r/The other way, is to duplicate the child SAs, and have a pair of IPsec SAs for each active member./The second is the "duplicate" category, where the child SA is duplicated for each pair of IPsec SAs for each active member. #22) Shouldn't the 'must never' be 'MUST NOT'? spt From turners@ieca.com Tue Jun 8 10:47:07 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F33263A69F3 for ; Tue, 8 Jun 2010 10:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 itDxbioXN7IU for ; Tue, 8 Jun 2010 10:47:05 -0700 (PDT) Received: from smtp111.biz.mail.re2.yahoo.com (smtp111.biz.mail.re2.yahoo.com [66.196.116.96]) by core3.amsl.com (Postfix) with SMTP id 9FBEE3A6953 for ; Tue, 8 Jun 2010 10:47:05 -0700 (PDT) Received: (qmail 17101 invoked from network); 8 Jun 2010 17:47:04 -0000 Received: from thunderfish.local (turners@96.231.124.63 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 08 Jun 2010 10:47:03 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: N_q4cv4VM1mK_VUKN2GbNvFUAKndayzCb5Lipq0J4MrV9waBPzGx1XX5ysC80pcDEpMNdB4Xw1PIbjtIvx3uQnTOQFL5D_ief3JouVDjRQuBK_z65wcmmiEQSkag56qkQ_oqLS0eFk5Rt.lEhHS6P7dCn_k6pODI2X06_myXIbfkpvnumb_gtbPJFbtecV9rMVTMLSeyWSgo9Jn_LqdNy0yBUzikuEhZSguPKXErXpqguQi6V3fVD57YForwGNJELoNwdbEPzzWsmLxvgnotbzsrGOiCZVLODoJIQmv3lBmXmqqORfOv8S2WmNvSV_5VPiXM.DbcGelUsQJrdakzXrl5xrRbK.Rs3OZCEA7ir3rWENTvsRq00VVhynY35YfYhR_Ia1WuEd7rWniVXH_NELZ9NrAiDUSlVPTEC_88HjAfrKWJaA5XoZNj7xGqUa3uUZLw5Jo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C0E8217.6020706@ieca.com> Date: Tue, 08 Jun 2010 13:47:03 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] AD review of: draft-ietf-ipsecme-roadmap X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 17:47:07 -0000 I've now done my AD review for draft-ietf-ipsecme-roadmap-06, and have some comments. Some of them are making sure what was going to get done got done. The ones after "NEW" are the new comments. Here are the comments: #1) Remove sections 6.5-10 and 6.12-16. Pasi & Paul agreed; I didn't see anybody object. #2) Section 5.x: Pasi & Paul agreed; I didn't see anybody object to the following: OLD: ESP-v2 - undefined (no IANA #) NEW: ESP-v2 - optional (but no IANA #, so cannot be negotiated by IKEv1) #3) Pasi and Paul had a back and forth about Sections 8.6 and 8.4.1. I thought it was agreed to move these two to a new section because they don't have anything to do with IPsec/IKE, except for borrowing some design from RFC 4306? #4) Repeating Pasi's comment: Section 6.1: RFC 3740 barely mentions IPsec, so the description should probably point out that 3740 isn't really about IPsec. #5) I don't think this move was completed: Repeating Pasi's comment and Sheila's response: > - IMHO MOBIKE would belong together with other IKEv2 remote > > access extensions in Section 4.2.4? > > OK - MOBIKE will be moved to 4.2.4 (Remote Access) under the Section "IKE Additions and Extensions" #6) I think this comment was addressed in 5.4.1. and 5.4.2 but not in 5.4.3 and 5.6.2: > - Section 5.4: "Since combined mode algorithms are not a feature >of IPsec-v2, these IKEv1 implementations are used in conjunction with >IPsec-v3." I'm not sure if this is really a good way to describe >the situation; after all, GCM-for-ESP (RFC 4106) predates IPsec-v3... > >I'd suggest something like "Although IPsec-v2 ESP [RFC2406] did not >originally include combined mode algorithms, 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." > >Analogous changes are needed in 5.4.1, 5.4.2, 5.4.3, and 5.6.2. NEW #8) Sec 5.4.1 and 5.5.1: To avoid the discussion about whether this document updates 4307 or 4109. Please add some text to the NOTEs that says and errata has been submitted that addresses this (don't add a pointer to it somebody will complain later that it's not stable). There has been one submitted on 4307 but not on 4109. If 4109 is wrong submit an errata. #9) I think section 3.1.1 should be IPsec-v2 (or "Old" IPsec (IPsec-v2) and 3.1.2 should be IPsec-v3 (or "New" IPsec (IPsec-v3). Section 2.2 says that's how they're going to be referred to. #10) Sec 3.2.8 should be discussing RFC 5879 not 5840 ;) #11) Sections 3.3.4, 4.1.2.3, 4.2.1.4, 5.7.3, 8.9.1 and 8.9.2: For the work-in-progress can we add "work-in-progress" to the heading? #12) Sec 4.1.1.4: remove "using": [RFC2412] describes a key establishment protocol using which two authenticated parties can #13) Sections 4.2.2.1: Last sentence says: This optional extension applies to both IKEv1 and IKEv2. These don't really define extensions to IKE or IPsec; it's just a requirements document. Please reword. #14) Sections 5 and and 1: Should "Optional" be replaced with "'optional'"? I want to avoid confusion with the keyword OPTIONAL so even though "Optional" is correct to use at the beginning of the sentence when you're talking about this word maybe putting it in quotes and making it all lower case will further drive the point home. #15) Sections 5.2.2, 5.2.3, 5.3.2, 5.5.1, 5.7, 5.7.1, and Appendix B make use of the + and - after the requirements language. Do you think that this is covered by the penultimate paragraph in Section 1 or should something be said about them in 5.1? I'd like to err on the side of caution and at least mention that these are used and their definitions are taken from the document reference that follows (or something like that). #16) Sec 5.2.3: I'm getting hung up on getting the text to align with the words. The text says 128-bit keys is MUST but bullets show it as SHOULD/SHOULD+. #17) Sec 5.2.5: Need a new line: 5.2.5. draft-ietf-ipsecme-aes-ctr-ikev2, Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 (S) <<< new line here [ipsecme-2] extends [RFC3686] to enable the use of AES-CTR to provide encryption and integrity-protection for IKEv2 messages. #18) Sec 6.4: r/purposel/purpose. #19) Sec 7.3: r/LZJH algorithm/LZJH algorithm. #20) Sec 7.6: Is this only applicable to IKEv1? If so, I'd make an explicit statement that it's N/A for IKEv2. Please address these in a new version and make sure an errata is filed for RFC 4109. After both are published, I will request IETF LC. Cheers, spt From seonghan.shin@aist.go.jp Tue Jun 8 19:00:55 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A590F3A6891 for ; Tue, 8 Jun 2010 19:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.96 X-Spam-Level: *** X-Spam-Status: No, score=3.96 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, 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 8VQuQJDEvVZf for ; Tue, 8 Jun 2010 19:00:49 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by core3.amsl.com (Postfix) with ESMTP id 5116A3A67B2 for ; Tue, 8 Jun 2010 19:00:49 -0700 (PDT) Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id o5920kWP019247; Wed, 9 Jun 2010 11:00:47 +0900 (JST) env-from (seonghan.shin@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1276048847; bh=TTcfwjHPn5Od0mfb2/1e9C7XIstJT3VUFq6KIg6O+So=; h=From:Date:Message-ID; b=bRRsCTdDpljBMP7byQ+0bB8a+EIp1ZH7Ryyy8DE4eJDtFQ2d2tT8BES/uZHe9BJDx 4xWDPeaPIMi1+y8LLvSojiJe4xv1KdEHKD3G4mes1/PDdboWNwB4vnOA0NySL7ma+G wiZgnhELkobKrRDnUKQybh+akderARfNuCj7Rv1M= Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id o5920kcS010286; Wed, 9 Jun 2010 11:00:46 +0900 (JST) env-from (seonghan.shin@aist.go.jp) Received: by smtp2.aist.go.jp with ESMTP id o5920hMh006615; Wed, 9 Jun 2010 11:00:46 +0900 (JST) env-from (seonghan.shin@aist.go.jp) From: "SeongHan Shin" To: "'IPsecme WG'" Date: Wed, 9 Jun 2010 11:00:40 +0900 Message-ID: <002d01cb0777$8fbbbfe0$af333fa0$@shin@aist.go.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01CB07C2.FFA367E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsHd48XHxhr+VnPQ3GxLq5dApPzYg== Content-Language: ja Cc: 'Kaz Kobara' , 'SeongHan Shin' Subject: [IPsec] PAKE Selection: AugPAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 02:00:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002E_01CB07C2.FFA367E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, I posted a new I-D version (draft-shin-augmented-pake ) which also includes how to integrate AugPAKE into IKEv2. The AugPAKE protocol has the following advantages: 1. Simple structure (it is constructed from Diffie-Hellman type key exchange plus "usual" hash function) 2. Most efficient (it is almost same computation/communication costs as the plain DH key exchange) 3. Provable security (see SEC5) 4. Royal -free license (see IPR2/3) 5. No special function (neither hash-to-group mapping technique nor ideal cipher is needed) 6. Additional security (PAKE security (against passive/active/off-line dictionary attacks) plus resistance to server-compromise impersonation attacks) Below are self evaluation of the AugPAKE protocol by following selection criteria http://www.ietf.org/id/draft-harkins-ipsecme-pake-criteria-00.txt. SEC1: AugPAKE is zero knowledge (password) proof. It is secure against passive/active/off-line dictionary attacks. It is also resistant to server-compromise impersonation attacks. SEC2: AugPAKE provides PFS and secure against Denning-Sacco attack. SEC3: IKEv2 identity protection is preserved. SEC4: Any cryptographically secure Diffie-Hellman groups can be used. SEC5: The formal security proof of AugPAKE can be found at Cryptology ePrint Archive: Report 2010/334. http://eprint.iacr.org/2010/334 SEC6: AugPAKE can be easily used with strong credential. SEC7: In the case of server compromise, an attacker has to perform off-line dictionary attacks while computing mod. exp. with a password candidate. IPR1: AugPAKE was publicly disclosed on Oct. 2008. IPR2: AIST applied for patent in Japan on July 10, 2008. AIST would provide royal-free license of AugPAKE. IPR3: IPR disclosure (see https://datatracker.ietf.org/ipr/1284/) MISC1: AugPAKE adds one round trip to IKEv2 MISC2: Initiator needs to compute only 2 mod. exp. computations while responder needs to compute 2.17 mod. exp. computations. AugPAKE needs to exchange 2 group elements and 2 hash values. This is almost same computation/communication costs as the plain DH key exchange. If we use a large (e.g., 2048/3072-bits) parent group, hash size would be relatively small. MISC3: AugPAKE has the same performance for any type of secrets. MISC4: Internationalization of character-based passwords can be supported. MISC5: AugPAKE can be implemented over any ECP, EC2N and MODP groups. MISC6: AugPAKE has request/response nature of IKEv2. MISC7: No additional negotiation is needed. MISC8: No TTP and clock synchronization MISC9: No additional primitive is needed. MISC10: As above, AugPAKE can be implemented over any ECP/EC2N groups. MISC11: Easy implementation. We already implemented AugPAKE and have been testing in AIST. Any comments are welcome! Best regards, Shin ------=_NextPart_000_002E_01CB07C2.FFA367E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I posted a new I-D version (draft-shin-augmented-pake) which also includes how to integrate AugPAKE into = IKEv2.

 

 

The AugPAKE protocol has the following = advantages:

1. Simple structure (it is constructed from Diffie-Hellman type key exchange plus “usual” hash function) =

2. Most efficient (it is almost same computation/communication costs as the plain DH key = exchange)

3. Provable security (see = SEC5)

4. Royal –free license (see = IPR2/3)

5. No special function (neither hash-to-group mapping technique nor ideal cipher is needed)

6. Additional security (PAKE security = (against passive/active/off-line dictionary attacks) plus resistance to server-compromise impersonation attacks)

 

Below are self evaluation of the AugPAKE = protocol by following selection criteria http://www.ietf.org/id/draft-harkins-ipsecme-pake-criteria-00.txt.

 

SEC1: AugPAKE is zero knowledge (password) = proof. It is secure against passive/active/off-line dictionary attacks. It is also resistant to server-compromise impersonation = attacks.

SEC2: AugPAKE provides PFS and secure against Denning-Sacco attack.

SEC3: IKEv2 identity protection is = preserved.

SEC4: Any cryptographically secure = Diffie-Hellman groups can be used.

SEC5: The formal security proof of AugPAKE = can be found at Cryptology ePrint Archive: Report 2010/334. = http://eprint.iacr.org/2010/334

SEC6: AugPAKE can be easily used with strong credential.

SEC7: In the case of server compromise, an = attacker has to perform off-line dictionary attacks while computing mod. exp. = with a password candidate.

 

IPR1: AugPAKE was publicly disclosed on Oct. = 2008.

IPR2: AIST applied for patent in Japan on = July 10, 2008. AIST would provide royal-free license of = AugPAKE.

IPR3: IPR disclosure (see https://datatracker.ietf.org/ipr/1284/)

 

MISC1: AugPAKE adds one round trip to = IKEv2

MISC2: Initiator needs to compute only 2 mod. = exp. computations while responder needs to compute 2.17 mod. exp. = computations. AugPAKE needs to exchange 2 group elements and 2 hash values. This is = almost same computation/communication costs as the plain DH key exchange. If we = use a large (e.g., 2048/3072-bits) parent group, hash size would be relatively = small.

MISC3: AugPAKE has the same performance for = any type of secrets.

MISC4: Internationalization of = character-based passwords can be supported.

MISC5: AugPAKE can be implemented over any = ECP, EC2N and MODP groups.

MISC6: AugPAKE has request/response nature of = IKEv2.

MISC7: No additional negotiation is = needed.

MISC8: No TTP and clock = synchronization

MISC9: No additional primitive is = needed.

MISC10: As above, AugPAKE can be implemented = over any ECP/EC2N groups.

MISC11: Easy implementation. We already = implemented AugPAKE and have been testing in AIST.

 

Any comments are = welcome!

 

Best regards,

Shin

------=_NextPart_000_002E_01CB07C2.FFA367E0-- From yaronf.ietf@gmail.com Wed Jun 9 20:42:34 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B44603A68A7 for ; Wed, 9 Jun 2010 20:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EG84kGNyHTH for ; Wed, 9 Jun 2010 20:42:33 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 705B83A689D for ; Wed, 9 Jun 2010 20:42:33 -0700 (PDT) Received: by wya21 with SMTP id 21so348618wya.31 for ; Wed, 09 Jun 2010 20:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:x-priority:content-type :content-transfer-encoding; bh=Sh6jDQsUPEdk80y6Fan+Zq9bN+w1SF6rWn1unwcDBUM=; b=puboxa28/rFsU0ayTm8QF7oHvSedPaY+jVA1JbrOFA4DzK2xYDPARLX3/gHUnJDb8R NFxaS1R6DZnNfBLoE2y1v7gTrlxf0MeyKD6i4sOX4RhuPmprytUVUt7JSE1CtCbK8bJ7 uy3q+MAP/z82EkxJNcKM+6Rvyg3abfW/oLxqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:x-priority :content-type:content-transfer-encoding; b=QC6TiqgpWfcg7PgvpIBRghoD/HmefQmyWpxZHOS3FKm5HVX0XbfVnxKrCwuAOOpXIw diBhr+BRrMk86qVHKHMpy8n3ms5NBLqlp+EABG3zmTbXzWvATyCZKfW9xs1X/WZdX2O+ e5qDVc8Ub6hTLfxeAzME7Fo+pDKxdwZxsVHrc= Received: by 10.227.157.134 with SMTP id b6mr4033272wbx.12.1276141350748; Wed, 09 Jun 2010 20:42:30 -0700 (PDT) Received: from [10.0.0.2] ([109.65.15.116]) by mx.google.com with ESMTPS id n31sm61333484wba.3.2010.06.09.20.42.29 (version=SSLv3 cipher=RC4-MD5); Wed, 09 Jun 2010 20:42:30 -0700 (PDT) Message-ID: <4C105F24.1010904@gmail.com> Date: Thu, 10 Jun 2010 06:42:28 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: IPsecme WG X-Priority: 1 (Highest) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] HA solution document - moving forward *before* Maastricht X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 03:42:34 -0000 Hi, We have gotten the HA problem statement (http://tools.ietf.org/html/draft-ietf-ipsecme-ipsec-ha) back from Sean Turner, our AD, and we expect it to move to IETF last call soon after Yoav issues the next revision. We certainly expect useful input from the IETF LC and IESG review, but believe that we are ready to move to the next step: an in-depth discussion of possible HA solutions at the Maastricht face-to-face meeting next month. As we said in the past, our preferred process for dealing with this issue is through a design team, which will be tasked with publishing a strawman proposal before the July 5 initial I-D cutoff. Please let us know by tomorrow, June 11 if you'd like to take part in this design team. Alternatively, we are also open to discuss individually submitted solution documents. If you plan to submit such a draft, we would appreciate a heads-up by private mail to Paul and myself. Thanks, Yaron From root@core3.amsl.com Thu Jun 10 05:30:05 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8E2563A6980; Thu, 10 Jun 2010 05:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100610123004.8E2563A6980@core3.amsl.com> Date: Thu, 10 Jun 2010 05:30:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ipsec-ha-05.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: Thu, 10 Jun 2010 12:30:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IPsec Cluster Problem Statement Author(s) : Y. Nir Filename : draft-ietf-ipsecme-ipsec-ha-05.txt Pages : 12 Date : 2010-06-10 This document defines terminology, problem statement and requirements for implementing IKE and IPsec on clusters. It also describes gaps in existing standards and their implementation that need to be filled, in order to allow peers to interoperate with clusters from different vendors. An agreed terminology, problem statement and requirements will allow the IPSECME WG to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsec-ha-05.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-ipsec-ha-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-10052152.I-D@ietf.org> --NextPart-- From ynir@checkpoint.com Thu Jun 10 05:35:28 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB02A3A68F2 for ; Thu, 10 Jun 2010 05:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBGZHbbS3fpN for ; Thu, 10 Jun 2010 05:35:27 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 866AC3A6836 for ; Thu, 10 Jun 2010 05:35:25 -0700 (PDT) X-CheckPoint: {4C10E9DD-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o5ACZKDq005353; Thu, 10 Jun 2010 15:35:20 +0300 (IDT) 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 Jun 2010 15:35:49 +0300 From: Yoav Nir To: Sean Turner Date: Thu, 10 Jun 2010 15:35:38 +0300 Thread-Topic: [IPsec] AD review: draft-ietf-ipsecme-ipsec-ha Thread-Index: AcsImXS0kBlcZGOeTnCIwctOT5XQTQ== Message-ID: References: <4C0E2832.8050205@ieca.com> In-Reply-To: <4C0E2832.8050205@ieca.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] AD review: draft-ietf-ipsecme-ipsec-ha X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 12:35:28 -0000 Hi Sean. I have just submitted version -05 which addresses most (but not all) of you= r comments. Here's a list of the exceptions (hope I didn't miss any) #2. I've worded the abstract a little differently. Main difference is addin= g to "gaps in existing standards" the words "and their implementation". Som= e things (like tolerating skips in replay counters and multiple parallel SA= s) are allowed by the RFC even now, but some vendors may perceive them as "= weird" and drop the tunnels. Yes, we've had this happen with real vendors. This document defines terminology, problem statement and requirements for implementing IKE and IPsec on clusters. It also describes gaps in existing standards and their implementation that need to be filled, in order to allow peers to interoperate with clusters from different vendors. An agreed terminology, problem statement and requirements will allow the IPSECME WG to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations. #13, #15, a few more (no MUST/SHOULD/MAY language). I have two issues with = this. The first, is that this document is a problem statement, and intended= to be INFORMATIONAL. No gateway is ever going to be said to "implement" th= is document. As such, I don't think it should mandate any behaviors. Some b= ehaviors are suggested as solutions, for example "replay counter must not r= epeat" =3D=3D> "gateway can synchronize occasionally, and skip 10,000 numbe= rs at failover". The charter does not allow us at this point to mandate tha= t newly-active gateways skip 10,000 numbers. We only say this, because it i= s one way to solve the problem, which some vendors have already done, and o= ther gateways should be ready for this to happen. When it comes to creating= a standards-track document, we might suggest this to cluster implementers,= and more important, we may mandate that all conforming IPsec implementers = (whether their gateways cluster or not) MUST accept such replay counter jum= ps. So I left most of sections 3.4-9 without RFC 2119 language. As an exception= to this rule, where the behavior is already mandated by older RFCs (4301 a= nd/or 4306), I did capitalize the requirement language (so "replay counter = must never repeat" --> "replay counter MUST NOT repeat") Yoav On Jun 8, 2010, at 2:23 PM, Sean Turner wrote: > Yaron asked me to review draft-ietf-ipsecme-ipsec-ha on 2010-06-01.=20 > Here are my comments most of which are about clarifying text (so that=20 > readers who didn't participate in the WG discussions can understand=20 > this unambiguously), plus a couple of nits. >=20 > Yoav, could you post a new version that addresses my comments before=20 > we start IETF Last Call? >=20 > #1) Should this I-D have been called "IPsec Cluter Problem Statement"=20 > to more closely align with the charter? The header also? >=20 > #2) The abstract needs to be clearer and more closely follow what's in=20 > the charter (I think the document does, but the abstract doesn't state=20 > it clearly). It states: >=20 > This document describes a requirement from IKE and IPsec to allow for > more scalable and available deployments for VPNs. It defines > terminology for high availability and load sharing clusters > implementing IKE and IPsec, and describes gaps in the existing > standards. >=20 > Is this a requirement "from" or "for" IKE/IPsec? I think it's=20 > supposed to be for. >=20 > It's missing the "problem statement" text from the charter. How about=20 > the following suggested text: >=20 > This document defines a set of terminology, a problem statement, and=20 > set of requirements for clusters implementing IKE and IPsec. It also=20 > describes gaps in the existing standards that need to be filled in=20 > order to allow peers to interoperate with clusters from different=20 > vendors. An agreed terminology, problem statement, and requirements=20 > will allow the IPSECME WG to consider development of IPsec/IKEv2=20 > mechanisms to simplify cluster implementations. >=20 > #3) I'd like to see "cluster" introduced in the 2nd paragraph of=20 > Section 1. It kind of jumps out in the 3rd para. >=20 > by using more than one physical gateway to either share the load > or back each other up (i.e., using a cluster). > ^^^^^^^^^^^^^^^^^^^^^^^ >=20 > #4) Section 1: r/organizations's/organization's >=20 > #5) Section 2: In section 1, it specifically mentions that the=20 > gateways are physically separate. Should this also be worked in to=20 > the definition of cluster in section 2: >=20 > "Cluster" is a set of two or more physically separated gateways, > ^^^^^^^^^^^^^^^^^^^^ > implementing the same > security policy, and protecting the same domain. Clusters exist to > provide both high availability through redundancy, and scalability > through load sharing. >=20 > #6) Section 2: Should this I-D explain or point (informatively) to how=20 > Availability is computed? >=20 > #7) Section 2: HS Cluster (there might only be one other): r/whereas=20 > the others are/whereas the other(s) are >=20 > #8) Section 2: LS Cluster: Can we replace: "and we don't want to even=20 > imply that this is a requirement" with "and this is not a requirement"? >=20 > #9) Section 2: Failover (add ,): r/In a load sharing cluster/In a load=20 > sharing cluster, >=20 > #10) Section 2: Loose Cluster: Is it that one address gets allocated=20 > to more than one member at failover, just one other, or can both=20 > happen? r/In some cases, members IP addresses may be allocated to=20 > other members at failover./In some cases, member's IP address(es) may=20 > be allocated to another member or members at failover. >=20 > #11) Section 3.2: Spell out first instance of SAD (it's not in the RFC=20 > editor's expansion > list:http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt). >=20 > #12) Section 3.2 (last paragraph): The definition of High Availability=20 > states that it's not a configuration type, but in the following it=20 > sure does sound like it: "A naive implementation of a high=20 > availability cluster would have no synchronized state, and a failover=20 > would produce an effect similar to that of a rebooted gateway".=20 > Because all of the clusters in this document offer high availability=20 > can you just strike "high availability" from the sentence? >=20 > #13) Section 3.3: This section needs to be rephrased as a problem=20 > statement not a solution. If the solution presented is a MUST=20 > requirement, then I'd like to see that stated clearly with a "MUST". >=20 > #14) Assuming the sections 3.4 and 3.5 are about IPsec SA: r/SA/IPsec SA >=20 > #15) Section 3.4-9: I'd like to see clear requirements language about=20 > what the mechanism(s) MUST/SHOULD/MAY support. >=20 > #16) Section 3.4: Shouldn't the 'must not' be "MUST NOT"? >=20 > #17) Section 3.5 (knowing people will want to verify this statement):=20 > Please provide a pointer to where this is: This is allowed by the=20 > standards, because replay counter verification is an optional feature.=20 > i.e., see section x of [RFCXYZ]. >=20 > #18) Section 3.6: All the clusters are highly available: r/a high=20 > availability cluster/a cluster >=20 > #19) Section 3.7, spell out first instance of HA and add it to the=20 > definition in Section 2. >=20 > #20) Section 3.7: what's a "commodity load balancer"? >=20 > #21) Section 3.7 to make the two category sentence work, r/The other=20 > way, is to duplicate the child SAs, and have a pair of IPsec SAs for=20 > each active member./The second is the "duplicate" category, where the=20 > child SA is duplicated for each pair of IPsec SAs for each active member. >=20 > #22) Shouldn't the 'must never' be 'MUST NOT'? >=20 > spt >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From turners@ieca.com Thu Jun 10 08:39:55 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1093028C12F for ; Thu, 10 Jun 2010 08:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_40=-0.185, 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 r2s9aIPZ18in for ; Thu, 10 Jun 2010 08:39:53 -0700 (PDT) Received: from smtp115.biz.mail.mud.yahoo.com (smtp115.biz.mail.mud.yahoo.com [209.191.68.75]) by core3.amsl.com (Postfix) with SMTP id A84DB28C114 for ; Thu, 10 Jun 2010 08:39:53 -0700 (PDT) Received: (qmail 49817 invoked from network); 10 Jun 2010 15:39:45 -0000 Received: from thunderfish.local (turners@96.231.125.208 with plain) by smtp115.biz.mail.mud.yahoo.com with SMTP; 10 Jun 2010 08:39:44 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: WsidhecVM1kYelBaxWxTERb7GUKPwr_2cTyJZeKOs68hMnqGEXZp.zkvK54gye0hiGD_.UvvvP27hPr6EBki509ICAALVyftI7_BZ2cxQlKIHBvB6zupCNNDkvueUeIozBNGID.40Zf_3Oguinj4ZIi3zUs3ReCm8ma0lqm2U6e3g5qs9jFAhVnGm4lGIAdurxJHwqIKIvRCItF.ffLY4UAb3ks7ST7dr63stYKYnlQXj6u0p3qkxZtfhBw4Gfkmez52w7o.TsVVlAxl9hCRtvAGM93lt_ADiIPWjjFTQiwAsBx_4i43C5iC9yD8ao7oXxUFq6Pq58uWBKN4EPyJpw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C11073F.2010608@ieca.com> Date: Thu, 10 Jun 2010 11:39:43 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Yoav Nir References: <4C0E2832.8050205@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] AD review: draft-ietf-ipsecme-ipsec-ha X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 15:39:55 -0000 Yoav Nir wrote: > Hi Sean. > > I have just submitted version -05 which addresses most (but not all) of your comments. Here's a list of the exceptions (hope I didn't miss any) > > #2. I've worded the abstract a little differently. Main difference is adding to "gaps in existing standards" the words "and their implementation". Some things (like tolerating skips in replay counters and multiple parallel SAs) are allowed by the RFC even now, but some vendors may perceive them as "weird" and drop the tunnels. Yes, we've had this happen with real vendors. > > This document defines terminology, problem statement and requirements > for implementing IKE and IPsec on clusters. It also describes gaps > in existing standards and their implementation that need to be > filled, in order to allow peers to interoperate with clusters from > different vendors. An agreed terminology, problem statement and > requirements will allow the IPSECME WG to consider development of > IPsec/IKEv2 mechanisms to simplify cluster implementations. This is fine. > #13, #15, a few more (no MUST/SHOULD/MAY language). I have two issues with this. The first, is that this document is a problem statement, and intended to be INFORMATIONAL. No gateway is ever going to be said to "implement" this document. As such, I don't think it should mandate any behaviors. Some behaviors are suggested as solutions, for example "replay counter must not repeat" ==> "gateway can synchronize occasionally, and skip 10,000 numbers at failover". The charter does not allow us at this point to mandate that newly-active gateways skip 10,000 numbers. We only say this, because it is one way to solve the problem, which some vendors have already done, and other gateways should be ready for this to happen. When it comes to creating a standards-track document, we might suggest this to cluster implementers, and more important, we may mandate that all conforming IPsec implementers (whether their gateways cluster or not) MUST accept such replay counter jumps. > So I left most of sections 3.4-9 without RFC 2119 language. As an exception to this rule, where the behavior is already mandated by older RFCs (4301 and/or 4306), I did capitalize the requirement language (so "replay counter must never repeat" --> "replay counter MUST NOT repeat") On #15, I can see that the text is proposing possible solutions. For #13, it reads like counters are the only solution. Can you tweak the text in such a way that it says "one possible solution, is ..." and that way it doesn't sound like counters is the only mechanism (even if it is)? > Yoav > > On Jun 8, 2010, at 2:23 PM, Sean Turner wrote: > >> Yaron asked me to review draft-ietf-ipsecme-ipsec-ha on 2010-06-01. >> Here are my comments most of which are about clarifying text (so that >> readers who didn't participate in the WG discussions can understand >> this unambiguously), plus a couple of nits. >> >> Yoav, could you post a new version that addresses my comments before >> we start IETF Last Call? >> >> #1) Should this I-D have been called "IPsec Cluter Problem Statement" >> to more closely align with the charter? The header also? >> >> #2) The abstract needs to be clearer and more closely follow what's in >> the charter (I think the document does, but the abstract doesn't state >> it clearly). It states: >> >> This document describes a requirement from IKE and IPsec to allow for >> more scalable and available deployments for VPNs. It defines >> terminology for high availability and load sharing clusters >> implementing IKE and IPsec, and describes gaps in the existing >> standards. >> >> Is this a requirement "from" or "for" IKE/IPsec? I think it's >> supposed to be for. >> >> It's missing the "problem statement" text from the charter. How about >> the following suggested text: >> >> This document defines a set of terminology, a problem statement, and >> set of requirements for clusters implementing IKE and IPsec. It also >> describes gaps in the existing standards that need to be filled in >> order to allow peers to interoperate with clusters from different >> vendors. An agreed terminology, problem statement, and requirements >> will allow the IPSECME WG to consider development of IPsec/IKEv2 >> mechanisms to simplify cluster implementations. >> >> #3) I'd like to see "cluster" introduced in the 2nd paragraph of >> Section 1. It kind of jumps out in the 3rd para. >> >> by using more than one physical gateway to either share the load >> or back each other up (i.e., using a cluster). >> ^^^^^^^^^^^^^^^^^^^^^^^ >> >> #4) Section 1: r/organizations's/organization's >> >> #5) Section 2: In section 1, it specifically mentions that the >> gateways are physically separate. Should this also be worked in to >> the definition of cluster in section 2: >> >> "Cluster" is a set of two or more physically separated gateways, >> ^^^^^^^^^^^^^^^^^^^^ >> implementing the same >> security policy, and protecting the same domain. Clusters exist to >> provide both high availability through redundancy, and scalability >> through load sharing. >> >> #6) Section 2: Should this I-D explain or point (informatively) to how >> Availability is computed? >> >> #7) Section 2: HS Cluster (there might only be one other): r/whereas >> the others are/whereas the other(s) are >> >> #8) Section 2: LS Cluster: Can we replace: "and we don't want to even >> imply that this is a requirement" with "and this is not a requirement"? >> >> #9) Section 2: Failover (add ,): r/In a load sharing cluster/In a load >> sharing cluster, >> >> #10) Section 2: Loose Cluster: Is it that one address gets allocated >> to more than one member at failover, just one other, or can both >> happen? r/In some cases, members IP addresses may be allocated to >> other members at failover./In some cases, member's IP address(es) may >> be allocated to another member or members at failover. >> >> #11) Section 3.2: Spell out first instance of SAD (it's not in the RFC >> editor's expansion >> list:http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt). >> >> #12) Section 3.2 (last paragraph): The definition of High Availability >> states that it's not a configuration type, but in the following it >> sure does sound like it: "A naive implementation of a high >> availability cluster would have no synchronized state, and a failover >> would produce an effect similar to that of a rebooted gateway". >> Because all of the clusters in this document offer high availability >> can you just strike "high availability" from the sentence? >> >> #13) Section 3.3: This section needs to be rephrased as a problem >> statement not a solution. If the solution presented is a MUST >> requirement, then I'd like to see that stated clearly with a "MUST". >> >> #14) Assuming the sections 3.4 and 3.5 are about IPsec SA: r/SA/IPsec SA >> >> #15) Section 3.4-9: I'd like to see clear requirements language about >> what the mechanism(s) MUST/SHOULD/MAY support. >> >> #16) Section 3.4: Shouldn't the 'must not' be "MUST NOT"? >> >> #17) Section 3.5 (knowing people will want to verify this statement): >> Please provide a pointer to where this is: This is allowed by the >> standards, because replay counter verification is an optional feature. >> i.e., see section x of [RFCXYZ]. >> >> #18) Section 3.6: All the clusters are highly available: r/a high >> availability cluster/a cluster >> >> #19) Section 3.7, spell out first instance of HA and add it to the >> definition in Section 2. >> >> #20) Section 3.7: what's a "commodity load balancer"? >> >> #21) Section 3.7 to make the two category sentence work, r/The other >> way, is to duplicate the child SAs, and have a pair of IPsec SAs for >> each active member./The second is the "duplicate" category, where the >> child SA is duplicated for each pair of IPsec SAs for each active member. >> >> #22) Shouldn't the 'must never' be 'MUST NOT'? >> >> spt >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. > > From ynir@checkpoint.com Thu Jun 10 09:11:54 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4238F3A6A3B for ; Thu, 10 Jun 2010 09:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unAYD0m-XNPh for ; Thu, 10 Jun 2010 09:11:43 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 17C753A6983 for ; Thu, 10 Jun 2010 09:11:27 -0700 (PDT) X-CheckPoint: {4C111C7E-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o5AGBNDq008849; Thu, 10 Jun 2010 19:11:23 +0300 (IDT) 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 Jun 2010 19:11:51 +0300 From: Yoav Nir To: Sean Turner Date: Thu, 10 Jun 2010 19:11:40 +0300 Thread-Topic: [IPsec] AD review: draft-ietf-ipsecme-ipsec-ha Thread-Index: AcsIt6MArOWCkU17QL6YFVBippUmHw== Message-ID: <6A42450B-ECBC-4D54-8429-F54D3FEAB4DA@checkpoint.com> References: <4C0E2832.8050205@ieca.com> <4C11073F.2010608@ieca.com> In-Reply-To: <4C11073F.2010608@ieca.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] AD review: draft-ietf-ipsecme-ipsec-ha X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 16:11:54 -0000 On Jun 10, 2010, at 6:39 PM, Sean Turner wrote: > Yoav Nir wrote: >=20 >> #13, #15, a few more (no MUST/SHOULD/MAY language). I have two issues wi= th this. The first, is that this document is a problem statement, and inten= ded to be INFORMATIONAL. No gateway is ever going to be said to "implement"= this document. As such, I don't think it should mandate any behaviors. Som= e behaviors are suggested as solutions, for example "replay counter must no= t repeat" =3D=3D> "gateway can synchronize occasionally, and skip 10,000 nu= mbers at failover". The charter does not allow us at this point to mandate = that newly-active gateways skip 10,000 numbers. We only say this, because i= t is one way to solve the problem, which some vendors have already done, an= d other gateways should be ready for this to happen. When it comes to creat= ing a standards-track document, we might suggest this to cluster implemente= rs, and more important, we may mandate that all conforming IPsec implemente= rs (whether their gateways cluster or not) MUST accept such replay counter = jumps. >> So I left most of sections 3.4-9 without RFC 2119 language. As an except= ion to this rule, where the behavior is already mandated by older RFCs (430= 1 and/or 4306), I did capitalize the requirement language (so "replay count= er must never repeat" --> "replay counter MUST NOT repeat") >=20 > On #15, I can see that the text is proposing possible solutions. For=20 > #13, it reads like counters are the only solution. Can you tweak the=20 > text in such a way that it says "one possible solution, is ..." and=20 > that way it doesn't sound like counters is the only mechanism (even if=20 > it is)? How about this: One possible solution, is to synchronize information about the IKE message counters after every IKE exchange. This way, the newly active member knows what messages it is allowed to process, and what message IDs to use on IKE requests, so that peers process them. This solution may be appropriate in some cases, but may be too onerous in systems with lots of SAs. It also has the drawback, that it never recovers from the missing synch message problem, which is described in Section 3.6. From turners@ieca.com Thu Jun 10 09:18:01 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0301C3A6A1D for ; Thu, 10 Jun 2010 09:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.752 X-Spam-Level: X-Spam-Status: No, score=-0.752 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_40=-0.185, 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 l-7sa6ZqPjbf for ; Thu, 10 Jun 2010 09:18:00 -0700 (PDT) Received: from smtp111.biz.mail.mud.yahoo.com (smtp111.biz.mail.mud.yahoo.com [209.191.68.76]) by core3.amsl.com (Postfix) with SMTP id 684FC3A6983 for ; Thu, 10 Jun 2010 09:17:53 -0700 (PDT) Received: (qmail 5241 invoked from network); 10 Jun 2010 16:17:50 -0000 Received: from thunderfish.local (turners@96.231.125.208 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 10 Jun 2010 09:17:49 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: juEBUXgVM1na6.XXiHH_axbUlOS2YB9Npbeog9b76YMKH0yAyjimE0yj0YHswfGPk3EEjovuTXhJW1bRx75fq.DrpDglHzfezAg2jEmLbzvd2kolCEx1uHGgS2Ap__.xsb6GCQ49M2SE3OVlNZLuJlIESpnz4pAWrD23cUqUDoGArKXsh5QRhhdopMKg3NAaRdsQ1vk7R0IxYuOUns97RAShicQqbN7kDAZfxuyIe9PxT0YWsmRv0h.CuaVmyYM7jsp7GFwx46DHj8rCjZZlABVEZYxMLsV83wBIbItU_AJseuRjBX9lhUo- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C11102D.4050508@ieca.com> Date: Thu, 10 Jun 2010 12:17:49 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Yoav Nir References: <4C0E2832.8050205@ieca.com> <4C11073F.2010608@ieca.com> <6A42450B-ECBC-4D54-8429-F54D3FEAB4DA@checkpoint.com> In-Reply-To: <6A42450B-ECBC-4D54-8429-F54D3FEAB4DA@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] AD review: draft-ietf-ipsecme-ipsec-ha X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 16:18:01 -0000 Yoav Nir wrote: > On Jun 10, 2010, at 6:39 PM, Sean Turner wrote: > >> Yoav Nir wrote: >> >>> #13, #15, a few more (no MUST/SHOULD/MAY language). I have two issues with this. The first, is that this document is a problem statement, and intended to be INFORMATIONAL. No gateway is ever going to be said to "implement" this document. As such, I don't think it should mandate any behaviors. Some behaviors are suggested as solutions, for example "replay counter must not repeat" ==> "gateway can synchronize occasionally, and skip 10,000 numbers at failover". The charter does not allow us at this point to mandate that newly-active gateways skip 10,000 numbers. We only say this, because it is one way to solve the problem, which some vendors have already done, and other gateways should be ready for this to happen. When it comes to creating a standards-track document, we might suggest this to cluster implementers, and more important, we may mandate that all conforming IPsec implementers (whether their gateways cluster or not) MUST accept such replay counter jumps. >>> So I left most of sections 3.4-9 without RFC 2119 language. As an exception to this rule, where the behavior is already mandated by older RFCs (4301 and/or 4306), I did capitalize the requirement language (so "replay counter must never repeat" --> "replay counter MUST NOT repeat") >> On #15, I can see that the text is proposing possible solutions. For >> #13, it reads like counters are the only solution. Can you tweak the >> text in such a way that it says "one possible solution, is ..." and >> that way it doesn't sound like counters is the only mechanism (even if >> it is)? > > > How about this: > One possible solution, is to synchronize information about the IKE > message counters after every IKE exchange. This way, the newly > active member knows what messages it is allowed to process, and what > message IDs to use on IKE requests, so that peers process them. This > solution may be appropriate in some cases, but may be too onerous in > systems with lots of SAs. It also has the drawback, that it never > recovers from the missing synch message problem, which is described > in Section 3.6. That works for me. spt From ynir@checkpoint.com Thu Jun 10 09:28:09 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35B03A699D for ; Thu, 10 Jun 2010 09:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUGhaE-7aKHQ for ; Thu, 10 Jun 2010 09:28:08 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 51CDC3A6983 for ; Thu, 10 Jun 2010 09:28:07 -0700 (PDT) X-CheckPoint: {4C112065-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o5AGS6Dq010935; Thu, 10 Jun 2010 19:28:06 +0300 (IDT) 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 Jun 2010 19:28:35 +0300 From: Yoav Nir To: Sean Turner Date: Thu, 10 Jun 2010 19:28:23 +0300 Thread-Topic: [IPsec] AD review: draft-ietf-ipsecme-ipsec-ha Thread-Index: AcsIufkbRv6BoR2sSHa8ts3QnNyQNg== Message-ID: <21A937C6-D771-4A64-B1F4-5CBE4E903BD6@checkpoint.com> References: <4C0E2832.8050205@ieca.com> <4C11073F.2010608@ieca.com> <6A42450B-ECBC-4D54-8429-F54D3FEAB4DA@checkpoint.com> <4C11102D.4050508@ieca.com> In-Reply-To: <4C11102D.4050508@ieca.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] AD review: draft-ietf-ipsecme-ipsec-ha X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 16:28:09 -0000 Done in -06 On Jun 10, 2010, at 7:17 PM, Sean Turner wrote: > Yoav Nir wrote: >> On Jun 10, 2010, at 6:39 PM, Sean Turner wrote: >>=20 >>> Yoav Nir wrote: >>>=20 >>>> #13, #15, a few more (no MUST/SHOULD/MAY language). I have two issues = with this. The first, is that this document is a problem statement, and int= ended to be INFORMATIONAL. No gateway is ever going to be said to "implemen= t" this document. As such, I don't think it should mandate any behaviors. S= ome behaviors are suggested as solutions, for example "replay counter must = not repeat" =3D=3D> "gateway can synchronize occasionally, and skip 10,000 = numbers at failover". The charter does not allow us at this point to mandat= e that newly-active gateways skip 10,000 numbers. We only say this, because= it is one way to solve the problem, which some vendors have already done, = and other gateways should be ready for this to happen. When it comes to cre= ating a standards-track document, we might suggest this to cluster implemen= ters, and more important, we may mandate that all conforming IPsec implemen= ters (whether their gateways cluster or not) MUST accept such replay counte= r jumps. >>>> So I left most of sections 3.4-9 without RFC 2119 language. As an exce= ption to this rule, where the behavior is already mandated by older RFCs (4= 301 and/or 4306), I did capitalize the requirement language (so "replay cou= nter must never repeat" --> "replay counter MUST NOT repeat") >>> On #15, I can see that the text is proposing possible solutions. For=20 >>> #13, it reads like counters are the only solution. Can you tweak the=20 >>> text in such a way that it says "one possible solution, is ..." and=20 >>> that way it doesn't sound like counters is the only mechanism (even if= =20 >>> it is)? >>=20 >>=20 >> How about this: >> One possible solution, is to synchronize information about the IKE >> message counters after every IKE exchange. This way, the newly >> active member knows what messages it is allowed to process, and what >> message IDs to use on IKE requests, so that peers process them. This >> solution may be appropriate in some cases, but may be too onerous in >> systems with lots of SAs. It also has the drawback, that it never >> recovers from the missing synch message problem, which is described >> in Section 3.6. >=20 > That works for me. >=20 > spt >=20 > Scanned by Check Point Total Security Gateway. From root@core3.amsl.com Thu Jun 10 09:30:24 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5F93F3A69A0; Thu, 10 Jun 2010 09:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100610163017.5F93F3A69A0@core3.amsl.com> Date: Thu, 10 Jun 2010 09:30:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ipsec-ha-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: Thu, 10 Jun 2010 16:30:26 -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 : IPsec Cluster Problem Statement Author(s) : Y. Nir Filename : draft-ietf-ipsecme-ipsec-ha-06.txt Pages : 12 Date : 2010-06-10 This document defines terminology, problem statement and requirements for implementing IKE and IPsec on clusters. It also describes gaps in existing standards and their implementation that need to be filled, in order to allow peers to interoperate with clusters from different vendors. An agreed terminology, problem statement and requirements will allow the IPSECME WG to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsec-ha-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-ipsec-ha-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-10092817.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Thu Jun 10 09:47:44 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id DAC0328C10E; Thu, 10 Jun 2010 09:47:44 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100610164744.DAC0328C10E@core3.amsl.com> Date: Thu, 10 Jun 2010 09:47:44 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] Last Call: draft-ietf-ipsecme-ipsec-ha (IPsec Cluster Problem Statement) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 16:47:45 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'IPsec Cluster Problem Statement ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-06-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsec-ha-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19677&rfc_flag=0 From rahul.bharadhwaj@gmail.com Thu Jun 10 23:40:21 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5ECD3A69C7 for ; Thu, 10 Jun 2010 23:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JDSeazA-fCM for ; Thu, 10 Jun 2010 23:40:21 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id F393F3A6940 for ; Thu, 10 Jun 2010 23:40:20 -0700 (PDT) Received: by pwi8 with SMTP id 8so380291pwi.31 for ; Thu, 10 Jun 2010 23:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=sAtCTkWS0E4NlJJBM3MamamF1y0QZE30i0zYJQtRaCY=; b=jd2+3EWi6wfPCH8r9h1ux4O3iKrOeExh6zCxEcqlGvp7p87r1dmsX5RWJ35exDjYB9 T24+M/CGCBHM5B78bWgV1L0T+fl8g6RqNcyCv+GCNpRExSV7th2z4YpsZpunfZRsGL8l WX23VeShjxIS0Fu6CPpXadTh2SkOb8tEg3G6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=oGDF/BhoENbKA45ns4NypB95dsPHA9d/YPtOWAyhKZAVFzqS3Dn2iLf12RPfKVCnFK 0WoBBehDYSAUmMhrJBJLQWYEw3gtR1L/J9Ll1J2u7sTsJZh6uWu5SMuNDsZYgTItN1jf TTp2lXXtn0UKJyrJ1/rkFNcuewYYImdi+6Mmw= MIME-Version: 1.0 Received: by 10.115.38.23 with SMTP id q23mr1063844waj.212.1276238419942; Thu, 10 Jun 2010 23:40:19 -0700 (PDT) Received: by 10.114.92.15 with HTTP; Thu, 10 Jun 2010 23:40:19 -0700 (PDT) Date: Fri, 11 Jun 2010 12:10:19 +0530 Message-ID: From: rahul bharadhwaj To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=0016e64c2468ab5f340488bb69a9 Subject: [IPsec] which is better SSL/TLS or IPsec for embedded networking products X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 06:40:22 -0000 --0016e64c2468ab5f340488bb69a9 Content-Type: text/plain; charset=ISO-8859-1 Hi For networking embedded products like scanner , printer or Multi Function devices, which is better to have SSL/TLS or IPSec ? I came to know that SSL is also capable to provide security for scanning and printing apart from HTTPS for web pages. So, please let me have inputs on this comparision. -rb --0016e64c2468ab5f340488bb69a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi

For networking embedded products like =A0scanner , pr= inter or Multi Function devices, which is better to have SSL/TLS or IPSec ?=

I came to know that SSL is also capable to provid= e security for scanning and printing apart from HTTPS for web pages.=A0

So, please let me have inputs on this comparision.

-rb
--0016e64c2468ab5f340488bb69a9-- From paul.hoffman@vpnc.org Fri Jun 11 17:27:52 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3193A67A1 for ; Fri, 11 Jun 2010 17:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.628 X-Spam-Level: X-Spam-Status: No, score=0.628 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLNYMLxI-shH for ; Fri, 11 Jun 2010 17:27:50 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6049E3A679C for ; Fri, 11 Jun 2010 17:27:50 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5C0RptX086242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 11 Jun 2010 17:27:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 11 Jun 2010 17:27:49 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Fwd: RFC 5903 on Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE 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: Sat, 12 Jun 2010 00:27:52 -0000 >A new Request for Comments is now available in online RFC libraries. > > > RFC 5903 > > Title: Elliptic Curve Groups modulo a > Prime (ECP Groups) for IKE and > IKEv2 > Author: D. Fu, J. Solinas > Status: Informational > Stream: IETF > Date: June 2010 > Mailbox: defu@orion.ncsc.mil, > jasolin@orion.ncsc.mil > Pages: 16 > Characters: 29175 > Obsoletes: RFC4753 > > I-D Tag: draft-solinas-rfc4753bis-01.txt > > URL: http://www.rfc-editor.org/rfc/rfc5903.txt > >This document describes three Elliptic Curve Cryptography (ECC) groups >for use in the Internet Key Exchange (IKE) and Internet Key Exchange >version 2 (IKEv2) protocols in addition to previously defined groups. >These groups are based on modular arithmetic rather than binary >arithmetic. These groups are defined to align IKE and IKEv2 with >other ECC implementations and standards, particularly NIST standards. >In addition, the curves defined here can provide more efficient >implementation than previously defined ECC groups. This document >obsoletes RFC 4753. This document is not an Internet Standards Track >specification; it is published for informational purposes. > > >INFORMATIONAL: This memo provides information for the Internet community. >It does not specify an Internet standard of any kind. Distribution of >this memo is unlimited. From kagarigi@cisco.com Mon Jun 14 09:03:08 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 010E53A69EB for ; Mon, 14 Jun 2010 09:03:08 -0700 (PDT) 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 By4fg0nIBozL for ; Mon, 14 Jun 2010 09:03:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 3A1653A690A for ; Mon, 14 Jun 2010 09:03:07 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngFAJTvFUxAaHte/2dsb2JhbACBQ5EkjBpxplyZdYUaBINL X-IronPort-AV: E=Sophos;i="4.53,415,1272844800"; d="scan'208,217";a="261495383" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-2.cisco.com with ESMTP; 14 Jun 2010 16:03:08 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5EG3687018271 for ; Mon, 14 Jun 2010 16:03:06 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 21:33:06 +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_01CB0BDB.136E7D9E" Date: Mon, 14 Jun 2010 21:33:05 +0530 Message-ID: <04BD913C7AD1B84297D26D5614FBE133820DF9@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New draft posted Thread-Index: AcsL2xLtRuWjBTVoQX2vdcKK3JYgNg== From: "Kalyani Garigipati (kagarigi)" To: X-OriginalArrivalTime: 14 Jun 2010 16:03:06.0171 (UTC) FILETIME=[136AF0B0:01CB0BDB] Subject: [IPsec] New draft posted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 16:03:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0BDB.136E7D9E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 A new version of I-D, http://www.ietf.org/id/draft-ikev2-windowssync-00.txt has been posted to the IETF repository. =20 Filename: http://www.ietf.org/id/draft-ikev2-windowssync-00.txt Revision: 00 Title: IKEv2 window synchronization among peers =20 Please give your comments. =20 Regards, Kalyani =20 ------_=_NextPart_001_01CB0BDB.136E7D9E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,

 

A new version of = I-D, http://www= .ietf.org/id/draft-ikev2-windowssync-00.txt has been posted to the IETF repository.

 

Filename:   http://www= .ietf.org/id/draft-ikev2-windowssync-00.txt<= /p>

Revision:   00

Title:          &= nbsp;=20 IKEv2 window synchronization among peers

  =

Please give your = comments.

 

Regards,

Kalyani

 

------_=_NextPart_001_01CB0BDB.136E7D9E-- From root@core3.amsl.com Mon Jun 14 12:15:04 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C33133A6936; Mon, 14 Jun 2010 12:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100614191503.C33133A6936@core3.amsl.com> Date: Mon, 14 Jun 2010 12:15:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-eap-mutual-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: Mon, 14 Jun 2010 19:15:04 -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 : An Extension for EAP-Only Authentication in IKEv2 Author(s) : P. Eronen, et al. Filename : draft-ietf-ipsecme-eap-mutual-04.txt Pages : 15 Date : 2010-06-14 IKEv2 specifies that EAP authentication must be used together with public key signature based responder authentication. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one-time passwords or token cards. This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-eap-mutual-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-eap-mutual-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-14120522.I-D@ietf.org> --NextPart-- From B22245@freescale.com Mon Jun 14 20:45:09 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AD283A67E9 for ; Mon, 14 Jun 2010 20:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl0m7C-+B26V for ; Mon, 14 Jun 2010 20:44:55 -0700 (PDT) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id B3B083A67B7 for ; Mon, 14 Jun 2010 20:44:54 -0700 (PDT) Received: from de01smr02.am.mot.com (de01smr02.freescale.net [10.208.0.151]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id o5F3iwnv021622 for ; Mon, 14 Jun 2010 20:44:58 -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 o5F3ulBt010362 for ; Mon, 14 Jun 2010 22:56:48 -0500 (CDT) 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, 15 Jun 2010 09:14:39 +0530 Message-ID: <402621A7D69DDA458D0E12F070D1E55F84BC65@zin33exm29.fsl.freescale.net> In-Reply-To: <20100614191503.C33133A6936@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] I-D Action:draft-ietf-ipsecme-eap-mutual-04.txt Thread-Index: AcsL9fLw2ZbRY0jrSMG6ygTgNkbi5wARjzCg References: <20100614191503.C33133A6936@core3.amsl.com> From: "V Jyothi-B22245" To: Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-eap-mutual-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: Tue, 15 Jun 2010 03:45:09 -0000 Hi, To my knowledge, each EAP method has client and server implementation. Suppose if there are two gateways: gw1 and gw2, gw1 has EAP client implementation and gw2 has EAP server implementation. Irrespective of IKEv2 acting as initiator or responder, can gw1 act as only EAP client and gw2 act as only EAP server. With this posted draft, is it possible to achieve this functionality. Thanks Jyothi -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, June 15, 2010 12:45 AM To: i-d-announce@ietf.org Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-eap-mutual-04.txt 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 : An Extension for EAP-Only Authentication in IKEv2 Author(s) : P. Eronen, et al. Filename : draft-ietf-ipsecme-eap-mutual-04.txt Pages : 15 Date : 2010-06-14 IKEv2 specifies that EAP authentication must be used together with public key signature based responder authentication. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one-time passwords or token cards. This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-eap-mutual-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. From yaronf.ietf@gmail.com Mon Jun 14 22:02:19 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 146833A6A2D for ; Mon, 14 Jun 2010 22:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VsWRjrYzfeP for ; Mon, 14 Jun 2010 22:02:17 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 511163A6802 for ; Mon, 14 Jun 2010 22:02:17 -0700 (PDT) Received: by wya21 with SMTP id 21so775830wya.31 for ; Mon, 14 Jun 2010 22:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=70V4yq4IX2DG1Qg1Iqm0k3e5Fyeoq4n9fgNFTmFHdP0=; b=TDi6PmJxp0tECWchSJScz0fH7f8om5F5B8ER8Zr51dx8l9ESDx+4AHhFSz4DXCtluA t1CT4oy2lusZoSBLWlmZSCgcdXzQ2PggLpe0sqhYN3T0gqlnxGvBcvOqHY8NpXTf5Q30 r5/1zHWT1iezyc6gOXdR9f4Uz7u9glKi4vww0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=lC6dP77LzqUFiEEnDhZhauVmg8o9TIqJ9KAUbvlxplPhi9c5YuiTxRgdxMQMwBF9Gf y/lmzyLINpurH5fmYrgJTUrO34lbCdCIZYfhxlkgvqkIPEtFB48a276mMy5FmH4woY42 J+0ZwHVpaIEeOcJGIeuc+FbJ6PiojU57PUoBE= Received: by 10.227.135.195 with SMTP id o3mr6512153wbt.120.1276578138086; Mon, 14 Jun 2010 22:02:18 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-178-30-177.red.bezeqint.net [79.178.30.177]) by mx.google.com with ESMTPS id y31sm42827912wby.22.2010.06.14.22.02.15 (version=SSLv3 cipher=RC4-MD5); Mon, 14 Jun 2010 22:02:16 -0700 (PDT) Message-ID: <4C170954.709@gmail.com> Date: Tue, 15 Jun 2010 08:02:12 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: V Jyothi-B22245 References: <20100614191503.C33133A6936@core3.amsl.com> <402621A7D69DDA458D0E12F070D1E55F84BC65@zin33exm29.fsl.freescale.net> In-Reply-To: <402621A7D69DDA458D0E12F070D1E55F84BC65@zin33exm29.fsl.freescale.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-eap-mutual-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: Tue, 15 Jun 2010 05:02:19 -0000 Hi Jyothi, the proposed protocol is asymmetric. So you will need to make sure somehow that gw1 is always the initiator. Thanks, Yaron On 06/15/2010 06:44 AM, V Jyothi-B22245 wrote: > Hi, > > To my knowledge, each EAP method has client and server implementation. > > Suppose if there are two gateways: gw1 and gw2, gw1 has EAP client > implementation and gw2 has EAP server implementation. > Irrespective of IKEv2 acting as initiator or responder, can gw1 act as > only EAP client and gw2 act as only EAP server. > With this posted draft, is it possible to achieve this functionality. > > Thanks > Jyothi > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Tuesday, June 15, 2010 12:45 AM > To: i-d-announce@ietf.org > Cc: ipsec@ietf.org > Subject: [IPsec] I-D Action:draft-ietf-ipsecme-eap-mutual-04.txt > > 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 : An Extension for EAP-Only Authentication in > IKEv2 > Author(s) : P. Eronen, et al. > Filename : draft-ietf-ipsecme-eap-mutual-04.txt > Pages : 15 > Date : 2010-06-14 > > IKEv2 specifies that EAP authentication must be used together with > public key signature based responder authentication. This is necessary > with old EAP methods that provide only unilateral authentication using, > e.g., one-time passwords or token cards. > > This document specifies how EAP methods that provide mutual > authentication and key agreement can be used to provide extensible > responder authentication for IKEv2 based on methods other than public > key signatures. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-eap-mutual-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. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kagarigi@cisco.com Tue Jun 15 04:39:04 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8B43A6827 for ; Tue, 15 Jun 2010 04:39:03 -0700 (PDT) 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 DW5xQ0cM0fKy for ; Tue, 15 Jun 2010 04:39:01 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7BA043A689C for ; Tue, 15 Jun 2010 04:39:01 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAPcCF0xAaHte/2dsb2JhbACBQ50wcaRMmkaFGgSDTQ X-IronPort-AV: E=Sophos;i="4.53,420,1272844800"; d="scan'208,217";a="261686045" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-2.cisco.com with ESMTP; 15 Jun 2010 11:39:05 +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 o5FBcmQu000991 for ; Tue, 15 Jun 2010 11:39:04 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jun 2010 17:09:02 +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_01CB0C7F.5A79D379" Date: Tue, 15 Jun 2010 17:09:04 +0530 Message-ID: <04BD913C7AD1B84297D26D5614FBE133821051@XMB-BGL-417.cisco.com> In-Reply-To: <04BD913C7AD1B84297D26D5614FBE133820DF9@XMB-BGL-417.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] New draft posted Thread-Index: AcsL2xLtRuWjBTVoQX2vdcKK3JYgNgApBrdw References: <04BD913C7AD1B84297D26D5614FBE133820DF9@XMB-BGL-417.cisco.com> From: "Kalyani Garigipati (kagarigi)" To: "Kalyani Garigipati (kagarigi)" , X-OriginalArrivalTime: 15 Jun 2010 11:39:02.0954 (UTC) FILETIME=[5A89A0A0:01CB0C7F] Subject: Re: [IPsec] New draft posted X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 11:39:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0C7F.5A79D379 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi , =20 I have changed the name of the document as per the naming convention. =20 Please find the draft in the below link and give your comments. =20 http://www.ietf.org/id/draft-kagarigi-ipsecme-ikev2-windowsync-00.txt =20 regards, Kalyani =20 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Kalyani Garigipati (kagarigi) Sent: Monday, June 14, 2010 9:33 PM To: ipsec@ietf.org Subject: [IPsec] New draft posted =20 Hi All, =20 A new version of I-D, http://www.ietf.org/id/draft-ikev2-windowssync-00.txt has been posted to the IETF repository. =20 Filename: http://www.ietf.org/id/draft-ikev2-windowssync-00.txt Revision: 00 Title: IKEv2 window synchronization among peers =20 Please give your comments. =20 Regards, Kalyani =20 ------_=_NextPart_001_01CB0C7F.5A79D379 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi ,

 

I have changed the name of the = document as per the naming convention.

 

Please find the draft in the below = link and give your comments.

 

http://www.ietf.org/id/draft-kagarigi-ipsecme-ikev2-windowsync-00.t= xt

 

regards,

Kalyani

=

 

From: = ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On = Behalf Of Kalyani Garigipati (kagarigi)
Sent: Monday, June 14, = 2010 9:33 PM
To: ipsec@ietf.org
Subject: [IPsec] New = draft posted

 

Hi = All,

 

A new version of = I-D, http://www= .ietf.org/id/draft-ikev2-windowssync-00.txt has been posted to the IETF repository.

 

Filename:   http://www= .ietf.org/id/draft-ikev2-windowssync-00.txt<= /p>

Revision:   00

Title:          &= nbsp; IKEv2 window synchronization among peers

  =

Please give your = comments.

 

Regards,

Kalyani

 

------_=_NextPart_001_01CB0C7F.5A79D379-- From yaronf.ietf@gmail.com Thu Jun 17 23:26:15 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42DB43A698E for ; Thu, 17 Jun 2010 23:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jKiVFEoJObt for ; Thu, 17 Jun 2010 23:26:14 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 0C6723A69C5 for ; Thu, 17 Jun 2010 23:26:13 -0700 (PDT) Received: by wya21 with SMTP id 21so540263wya.31 for ; Thu, 17 Jun 2010 23:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=e5+X7QO/4A8XqlCk1rPbvuTyg/CCiGYsNITcn1BPNdc=; b=B85VjRFNXYun8etV66ekpzYdCLtfLrmVt7cfxH2HgEMfiBH5IzzwYNNmv2JsCHE6KW hjo0BRxbD3fZKvyMq4rQ4M3QiISkeDpAGepBFwcXJN5UmWlkDcHyN5moWKRVQQ/jM0gR b7GwnKs5HFuThIyVRG2yRW4iZdTG2UIIxv/mE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=wdIYEz5504+fPy5ATd5kByd8kqpRG/ZtuUjAFxWeI3VpR2h6DQVguKtlpcxq9SS4C9 pQ1deRpfV66TXQ67vZmQpMtEduCxLKL8jV4noCm1KMThKbUEAmSyx5lZ9nGgmRvp+8AM JLiSh+hcbhCTTZlOogQSIEZtiXWnOZRu8mThw= Received: by 10.227.142.21 with SMTP id o21mr524567wbu.187.1276842375538; Thu, 17 Jun 2010 23:26:15 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-178-30-177.red.bezeqint.net [79.178.30.177]) by mx.google.com with ESMTPS id n31sm42053211wba.9.2010.06.17.23.26.14 (version=SSLv3 cipher=RC4-MD5); Thu, 17 Jun 2010 23:26:15 -0700 (PDT) Message-ID: <4C1B1185.9090800@gmail.com> Date: Fri, 18 Jun 2010 09:26:13 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] HA design team started X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 06:26:15 -0000 Hi, As promised, we have started a design team on IPsec HA. Paul and I have asked Raj Singh to lead the team. His job is to make sure that the team meets regularly in the next few weeks, and produces a good output document before the Maastricht face-to-face meeting. The initial membership of the team is: - Raj Singh (rsjenwar@gmail.com, lead) - Jitender Arora (JArora@acmepacket.com) - Min Huang (huangmin@huaweisymantec.com) - Dacheng Zhang (zhangdacheng@huawei.com) - Yoav Nir (ynir@checkpoint.com) - Yaron Sheffer (yaronf.ietf@gmail.com, observer) According to IETF rules (see http://www.ietf.org/iesg/statement/design-team.htm), every design team needs to have a mission statement. So here it is: Produce a high-level solution document that covers most or all of the issues raised by the HA problem statement (draft-ietf-ipsecme-ipsec-ha). Any solution should be applicable to different deployments, in order to accommodate the variety of existing and future IPsec products. Solutions should have a similar level of security as the IKE/IPsec suite. Another process reminder: the design team's output serves as input to the full WG, essentially like an individual draft. So all protocol decisions will eventually be made by the working group. Thanks, Yaron From jmpark81@gmail.com Fri Jun 18 07:51:05 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B39683A690E for ; Fri, 18 Jun 2010 07:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 Ds582+1mLqr8 for ; Fri, 18 Jun 2010 07:51:04 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 85E3F3A6A9E for ; Fri, 18 Jun 2010 07:51:00 -0700 (PDT) Received: by gwj16 with SMTP id 16so740928gwj.31 for ; Fri, 18 Jun 2010 07:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=8SJjTMYBI/rk2EF7N3NmmsLObUpwf3mIOdBsYg6SWZU=; b=eg/M7bcfDq3GPKdDYVRpDwTP0mcSlaM5Amymc3/FW6H9Bh+SRHi/PflXoqHc+Lipqf 5Tt9BOwC+u5ZhsSW9qEMThDjMSnYksjV0t5UIHo1GcXCA2iVk1TTAf+0A2mngLAd7VD7 01DOF59OBqAfRT9w3XgDIT9pvxgMUOHsBo2Yk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=x1c+pcPdvG2kP7HEMgbLMCpqyMgcYZnm9/Inf78BaaQ39GitBw+6q8ahtqSKdp3CSL PECFXZqDsg42/KGkwXhZFBX5bK5gZi/WHsZ13MFuTX/GtM/qSfCYP7bUp2HwSNziGFHn 3WjBBe0BYy6RKyFteKGE/doJETT3DsIh4UydE= MIME-Version: 1.0 Received: by 10.224.97.221 with SMTP id m29mr740393qan.61.1276872661716; Fri, 18 Jun 2010 07:51:01 -0700 (PDT) Received: by 10.229.185.17 with HTTP; Fri, 18 Jun 2010 07:51:01 -0700 (PDT) Date: Fri, 18 Jun 2010 23:51:01 +0900 Message-ID: From: Jaemin Park To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=00c09f8e5c276ccf9a04894f15a6 Subject: [IPsec] Complexing of Traffic Selector (TSi & TSr) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 14:51:06 -0000 --00c09f8e5c276ccf9a04894f15a6 Content-Type: text/plain; charset=ISO-8859-1 Dear All, I'm in charge of developing VPN Clients based on IKEv2 and IPSec. We referred to the implementation of strongswan and RFC documents such as 4306 and 4718. While developing, we faced one question about complexing of Traffic Selectors. According to the RFC 4718, complexing of TSi and TSr which have same protocol IDs are defined and clarified. However, in the case when TSi is (17 (udp) any any) and TSr is (ip any any) where protocol IDs are different, should VPN complex TSi and TSr? According to the implementation of strongswan, we could find the fact that the strongswan is checking when complexing the TSi and TSr as follows : 1) remove the policy which has different protocol IDs for TSi and TSr as long as both of them are not "ANY" 2) follow the protocol which is not "ANY" if one of TSi and TSr is "ANY" According to my analysis, following examples can be possible : - ANY & ANY yields ANY - ANY & UDP yields UDP - UDP & UDP yields UDP - TCP & UDP <-- remove this case Does above implementation of strongswan follow the standards? If so, we're planning to implement the way the strongswan supports. I'm looking forward to all of the experts' responses. My Best Regards, Jaemin Park -- Park, Jae Min Assistant Manager Device R&D Center , Convergence WIBRO BU, KT M : +82-10-3010-2658 T : +82-2-2010-9255 jmpark@kt.com, jmpark81@gmail.com --00c09f8e5c276ccf9a04894f15a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear All,
=A0
I'm in charge of developing VPN Clients based on IKEv2 and IPSec.<= /div>
=A0
We referred to the implementation of strongswan and RFC documents such= as 4306 and 4718.
=A0
While developing, we faced one question about complexing of Traffic Se= lectors.
According to the RFC 4718, complexing of TSi and TSr which have same p= rotocol IDs are defined and clarified.
However, in the case when TSi is (17 (udp) any any) and TSr is (ip any= any) where protocol IDs are different, should VPN complex TSi and TSr?
According to the implementation of strongswan, we could find the fact = that the strongswan is checking when complexing the TSi and TSr as follows = :
1) remove the policy which has different protocol IDs for TSi and TSr = as long as both of them are not "ANY"
2) follow the protocol which is not "ANY" if one of TSi and = TSr is "ANY"
According to my analysis, following examples can be possible :
- ANY & ANY yields ANY
- ANY & UDP yields UDP
- UDP & UDP yields UDP
- TCP & UDP <-- remove this case
=A0
Does above implementation of strongswan follow the standards?
If so, we're planning to implement the way the strongswan supports= .
=A0
I'm looking forward to all of the experts' responses.
=A0
My Best Regards,
Jaemin Park

--
Park, Jae Min
Assistant Man= ager
Device R&D Center , Convergence WIBRO BU, KT
M : +82-10-3010= -2658
T =A0: +82-2-2010-9255 =A0
jmp= ark@kt.com, jmpark81@gmail.com
--00c09f8e5c276ccf9a04894f15a6-- From smoonen@us.ibm.com Fri Jun 18 08:07:56 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 385443A699A; Fri, 18 Jun 2010 08:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzc012bKpPi1; Fri, 18 Jun 2010 08:07:55 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id B559B3A6A81; Fri, 18 Jun 2010 08:07:54 -0700 (PDT) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e1.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o5IF1jOr015593; Fri, 18 Jun 2010 11:01:45 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o5IF7pIg121374; Fri, 18 Jun 2010 11:07:52 -0400 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o5IF7cSJ007425; Fri, 18 Jun 2010 09:07:38 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o5IF7ccK007421; Fri, 18 Jun 2010 09:07:38 -0600 In-Reply-To: References: X-KeepSent: CD5B1407:71CD92EA-85257746:0051C364; type=4; name=$KeepSent To: Jaemin Park X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: Scott C Moonen Date: Fri, 18 Jun 2010 11:07:37 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 06/18/2010 09:07:38 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBFDD5DFC245F48f9e8a93df938690918c0ABBFDD5DFC245F4" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] Complexing of Traffic Selector (TSi & TSr) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 15:07:56 -0000 --0__=0ABBFDD5DFC245F48f9e8a93df938690918c0ABBFDD5DFC245F4 Content-type: multipart/alternative; Boundary="1__=0ABBFDD5DFC245F48f9e8a93df938690918c0ABBFDD5DFC245F4" --1__=0ABBFDD5DFC245F48f9e8a93df938690918c0ABBFDD5DFC245F4 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Hi Jaemin, The RFC allows you to narrow the proposed traffic selectors to somethin= g smaller than what the peer proposes. From your description, it sounds = like StrongSwan has made a pragmatic choice to narrow the proposed selectors= to something symmetrical. This is allowed by the RFC. The TCP&UDP case i= s a strange one, and in particular it doesn't accomplish much for TCP, but = it is allowed by the RFC. If your SPD and/or SAD pragmatically do not all= ow you to express this sort of asymmetry for IPsec-protected traffic, then= it is proper for you to respond with TS_UNACCEPTABLE to such a proposal. = You will of course be unable to interoperate with a peer making such a proposal, but in this case I'm not sure that is a great hardship. Also don't forget to take into account complex proposals containing mor= e than one traffic selector for TSi and/or TSr. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen |------------> | From: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |Jaemin Park = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |------------> | To: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |ipsec@ietf.org = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |------------> | Date: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |06/18/2010 10:51 AM = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |------------> | Subject: | |------------> >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| |[IPsec] Complexing of Traffic Selector (TSi & TSr) = = | >--------------------------------------------------------------------= -----------------------------------------------------------------------= -------| Dear All, I'm in charge of developing VPN Clients based on IKEv2 and IPSec. We referred to the implementation of strongswan and RFC documents such = as 4306 and 4718. While developing, we faced one question about complexing of Traffic Selectors. According to the RFC 4718, complexing of TSi and TSr which have same protocol IDs are defined and clarified. However, in the case when TSi is (17 (udp) any any) and TSr is (ip any = any) where protocol IDs are different, should VPN complex TSi and TSr? According to the implementation of strongswan, we could find the fact t= hat the strongswan is checking when complexing the TSi and TSr as follows := 1) remove the policy which has different protocol IDs for TSi and TSr a= s long as both of them are not "ANY" 2) follow the protocol which is not "ANY" if one of TSi and TSr is "ANY= " According to my analysis, following examples can be possible : - ANY & ANY yields ANY - ANY & UDP yields UDP - UDP & UDP yields UDP - TCP & UDP <-- remove this case Does above implementation of strongswan follow the standards? If so, we're planning to implement the way the strongswan supports. I'm looking forward to all of the experts' responses. My Best Regards, Jaemin Park -- Park, Jae Min Assistant Manager Device R&D Center , Convergence WIBRO BU, KT M : +82-10-3010-2658 T =A0: +82-2-2010-9255 jmpark@kt.com, jmpark81@gmail.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBFDD5DFC245F48f9e8a93df938690918c0ABBFDD5DFC245F4 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable

Hi Jaemin,

The RFC allows you to narrow the proposed traffic selectors to somethin= g smaller than what the peer proposes. From your description, it sound= s like StrongSwan has made a pragmatic choice to narrow the proposed se= lectors to something symmetrical. This is allowed by the RFC. The TCP= &UDP case is a strange one, and in particular it doesn't accomplish= much for TCP, but it is allowed by the RFC. If your SPD and/or SAD pr= agmatically do not allow you to express this sort of asymmetry for IPse= c-protected traffic, then it is proper for you to respond with TS_UNACC= EPTABLE to such a proposal. You will of course be unable to interopera= te with a peer making such a proposal, but in this case I'm not sure th= at is a great hardship.

Also don't forget to take into account complex proposals containing mor= e than one traffic selector for TSi and/or TSr.


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

3D"InactiveJ= aemin Park ---06/18/2010 10:51:53 AM---Dear All,

=
3D=
From:		= 3D""
Jaemin Park <jmpark81@gmail.com>
3D=
To:
ipsec@ietf.org
3D=
Date:		= 3D""
06/18/2010 10:51 AM
3D=
Subject:		3D""
[IPsec] Complexing of Traffic Selector (TSi & TSr)=




Dear All,
=A0
I'm in charge of developing VPN Clients based on IKEv2= and IPSec.
=A0
We referred to the implementation of strongswan and RF= C documents such as 4306 and 4718.
=A0
While developing, we faced one question about complexi= ng of Traffic Selectors.
According to the RFC 4718, complexing of TSi and TSr w= hich have same protocol IDs are defined and clarified.
However, in the case when TSi is (17 (udp) any any) an= d TSr is (ip any any) where protocol IDs are different, should VPN comp= lex TSi and TSr?
According to the implementation of strongswan, we coul= d find the fact that the strongswan is checking when complexing the TSi= and TSr as follows :
1) remove the policy which has different protocol IDs = for TSi and TSr as long as both of them are not "ANY"<= br> 2) follow the protocol which is not "ANY" if= one of TSi and TSr is "ANY"
According to my analysis, following examples can be po= ssible :
- ANY & ANY yields ANY
- ANY & UDP yields UDP
- UDP & UDP yields UDP
- TCP & UDP <-- remove this case
=A0
Does above implementation of strongswan follow the sta= ndards?
If so, we're planning to implement the way the strongs= wan supports.
=A0
I'm looking forward to all of the experts' responses.<= /font>
=A0
My Best Regards,
Jaemin Park

--
Park, Jae Min
Assistant Manager
Device R&D Center , Convergence WIBRO BU, KT
M : +82-10-3010-2658
T =A0: +82-2-2010-9255 =A0=
jmpark@kt.com, jm= park81@gmail.com____________________________________= ___________
IPsec mailing list
IPsec@ietf.org
https:= //www.ietf.org/mailman/listinfo/ipsec


= --1__=0ABBFDD5DFC245F48f9e8a93df938690918c0ABBFDD5DFC245F4-- --0__=0ABBFDD5DFC245F48f9e8a93df938690918c0ABBFDD5DFC245F4 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFDD5DFC245F48f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFDD5DFC245F48f9e8a93df938690918c0ABBFDD5DFC245F4 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=0ABBFDD5DFC245F48f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBFDD5DFC245F48f9e8a93df938690918c0ABBFDD5DFC245F4-- From latten@austin.ibm.com Fri Jun 18 14:38:52 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1F083A68D1 for ; Fri, 18 Jun 2010 14:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=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 lg6sz6GBzoGT for ; Fri, 18 Jun 2010 14:38:52 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id DCC463A68A3 for ; Fri, 18 Jun 2010 14:38:51 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o5ILVcLj023626 for ; Fri, 18 Jun 2010 15:31:38 -0600 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 o5ILco6o113928 for ; Fri, 18 Jun 2010 15:38:50 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o5ILcoiE020068 for ; Fri, 18 Jun 2010 15:38:50 -0600 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o5ILcnFc020062 for ; Fri, 18 Jun 2010 15:38:49 -0600 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 o5ILcn4A047970; Fri, 18 Jun 2010 16:38:49 -0500 From: Joy Latten To: IPsecme WG Content-Type: text/plain Date: Fri, 18 Jun 2010 16:14:00 -0500 Message-Id: <1276895640.5121.197.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: rashmin@us.ibm.com Subject: [IPsec] Clarification about an implementation's response to out of order payloads 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, 18 Jun 2010 21:38:52 -0000 The last paragraph of section 2.5 in RFC 4306 states: Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations MUST send the payloads defined in this specification in the order shown in the figures in section 2 and implementations SHOULD reject as invalid a message with those payloads in any other order. So, for clarification, if an initiator sends an IKE_SA_INIT message whose KEi and Ni payloads are not in order, for example, Ni comes before KEi, then it is up to the responder's implementation whether or nor he will accept or reject the message? I guess I am fixated on the "SHOULD" in the above paragraph. It is acceptable for responder to accept the message and send second message, his IKE_SA_INIT response? Thanks for any clarification. regards, Joy From paul.hoffman@vpnc.org Fri Jun 18 17:13:46 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06BA23A6A94 for ; Fri, 18 Jun 2010 17:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.662 X-Spam-Level: X-Spam-Status: No, score=0.662 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNyNxrHlYIFS for ; Fri, 18 Jun 2010 17:13:45 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 447AD3A69DF for ; Fri, 18 Jun 2010 17:13:45 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5J0CWLx030249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jun 2010 17:12:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1276895640.5121.197.camel@faith.austin.ibm.com> References: <1276895640.5121.197.camel@faith.austin.ibm.com> Date: Fri, 18 Jun 2010 17:12:30 -0700 To: latten@austin.ibm.com, IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: rashmin@us.ibm.com Subject: Re: [IPsec] Clarification about an implementation's response to out of order payloads X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 00:13:46 -0000 At 4:14 PM -0500 6/18/10, Joy Latten wrote: >The last paragraph of section 2.5 in RFC 4306 states: > > Although new payload types may be added in the future and may appear > interleaved with the fields defined in this specification, > implementations MUST send the payloads defined in this specification > in the order shown in the figures in section 2 and implementations > SHOULD reject as invalid a message with those payloads in any other > order. > >So, for clarification, if an initiator sends an IKE_SA_INIT message whose KEi and Ni >payloads are not in order, for example, Ni comes before KEi, then it is up to the >responder's implementation whether or nor he will accept or reject the message? >I guess I am fixated on the "SHOULD" in the above paragraph. It is acceptable for >responder to accept the message and send second message, his IKE_SA_INIT response? IKEv2bis, which is now in the RFC Editor's queue, says: 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 Sections 1 and 2; implementations MUST NOT reject as invalid a message with those payloads in any other order. --Paul Hoffman, Director --VPN Consortium From jmpark81@gmail.com Sat Jun 19 10:45:40 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C16B13A6A3F; Sat, 19 Jun 2010 10:45:40 -0700 (PDT) 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=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH28TcenRIFf; Sat, 19 Jun 2010 10:45:39 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 375DC3A690D; Sat, 19 Jun 2010 10:45:38 -0700 (PDT) Received: by qyk32 with SMTP id 32so535747qyk.31 for ; Sat, 19 Jun 2010 10:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=HTqozmYUROYD+7VD5q3s/5xlHFDokaA/0b8d6wyYfPg=; b=CZHxJvlMqNFm06Ns+ITD/uOgBwhNnEHRutxpCxlce9GAT0QmQVCqQZubxtl/kBvF9R h5Ge4+UtEFu5gNcR7759DdmUff9Gh6fZse7Vk2EC/jxRzc/WSknZacNT10tcNN+uqiVq 2XXpe5dYdNR6p+KFeM8igJ/DKDvP4HUZXqiy0= 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=JQ7bkj6W8UeXT72ehaF1WzMHlVzljMYcG1ZBdQVUEh2l6wViYOWLa1ODr05ndu+xc3 5avRGV6HceKEYTbYKiu3AjR7UC572O/sSvVY9xzvwYT/7+JW28Rm9NAhi6swkLiUT7Ex QwMfJOQmeOySz59n/hsA0igY1JLwq/xpMp98M= MIME-Version: 1.0 Received: by 10.224.78.157 with SMTP id l29mr1814870qak.214.1276969540480; Sat, 19 Jun 2010 10:45:40 -0700 (PDT) Received: by 10.229.185.17 with HTTP; Sat, 19 Jun 2010 10:45:40 -0700 (PDT) In-Reply-To: References: Date: Sun, 20 Jun 2010 02:45:40 +0900 Message-ID: From: Jaemin Park To: Scott C Moonen Content-Type: multipart/related; boundary=00c09f9c9762d97548048965a391 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] Complexing of Traffic Selector (TSi & TSr) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 17:45:40 -0000 --00c09f9c9762d97548048965a391 Content-Type: multipart/alternative; boundary=00c09f9c9762d9753e048965a390 --00c09f9c9762d9753e048965a390 Content-Type: text/plain; charset=ISO-8859-1 Hi, Scott, I want to ask one more thing about Traffic Selector. In my case, host A and host B are working as follows about Traffic Selector : 1) host A (initiator) sends TS to host B (responder) 2) host B narrows the TS sent by host A and responses the narrowed TS to host A At this point, the narrowed TS includes the TSs that violates the policy of initiator such as different protocol IDs of TSi and TSr, etc. Then, can host A (initiator) also narrow the narrowed TSs, that is to remove the case of which the protocol IDs are different? I'm looking forward to responses. Thanks in advance. My Best Regards, Jaemin Park On Sat, Jun 19, 2010 at 12:07 AM, Scott C Moonen wrote: > Hi Jaemin, > > The RFC allows you to narrow the proposed traffic selectors to something > smaller than what the peer proposes. From your description, it sounds like > StrongSwan has made a pragmatic choice to narrow the proposed selectors to > something symmetrical. This is allowed by the RFC. The TCP&UDP case is a > strange one, and in particular it doesn't accomplish much for TCP, but it is > allowed by the RFC. If your SPD and/or SAD pragmatically do not allow you to > express this sort of asymmetry for IPsec-protected traffic, then it is > proper for you to respond with TS_UNACCEPTABLE to such a proposal. You will > of course be unable to interoperate with a peer making such a proposal, but > in this case I'm not sure that is a great hardship. > > Also don't forget to take into account complex proposals containing more > than one traffic selector for TSi and/or TSr. > > > Scott Moonen (smoonen@us.ibm.com) > z/OS Communications Server TCP/IP Development > http://www.linkedin.com/in/smoonen > > [image: Inactive hide details for Jaemin Park ---06/18/2010 10:51:53 > AM---Dear All,]Jaemin Park ---06/18/2010 10:51:53 AM---Dear All, > > > From: > Jaemin Park > To: > ipsec@ietf.org > Date: > 06/18/2010 10:51 AM > Subject: > [IPsec] Complexing of Traffic Selector (TSi & TSr) > ------------------------------ > > > > Dear All, > > I'm in charge of developing VPN Clients based on IKEv2 and IPSec. > > We referred to the implementation of strongswan and RFC documents such as > 4306 and 4718. > > While developing, we faced one question about complexing of Traffic > Selectors. > According to the RFC 4718, complexing of TSi and TSr which have same > protocol IDs are defined and clarified. > However, in the case when TSi is (17 (udp) any any) and TSr is (ip any any) > where protocol IDs are different, should VPN complex TSi and TSr? > According to the implementation of strongswan, we could find the fact that > the strongswan is checking when complexing the TSi and TSr as follows : > 1) remove the policy which has different protocol IDs for TSi and TSr as > long as both of them are not "ANY" > 2) follow the protocol which is not "ANY" if one of TSi and TSr is "ANY" > According to my analysis, following examples can be possible : > - ANY & ANY yields ANY > - ANY & UDP yields UDP > - UDP & UDP yields UDP > - TCP & UDP <-- remove this case > > Does above implementation of strongswan follow the standards? > If so, we're planning to implement the way the strongswan supports. > > I'm looking forward to all of the experts' responses. > > My Best Regards, > Jaemin Park > > -- > Park, Jae Min > Assistant Manager > Device R&D Center , Convergence WIBRO BU, KT > M : +82-10-3010-2658 > T : +82-2-2010-9255 * > * > *jmpark@kt.com* , *jmpark81@gmail.com* > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > -- Park, Jae Min Assistant Manager Device R&D Center , Convergence WIBRO BU, KT M : +82-10-3010-2658 T : +82-2-2010-9255 jmpark@kt.com, jmpark81@gmail.com --00c09f9c9762d9753e048965a390 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Scott,
=A0
I want to ask one more thing about Traffic Selector.
=A0
In my case, host A and host B are working as follows about Traffic Sel= ector :
=A0
1) host A (initiator)=A0sends TS=A0to host B (responder)
2) host B narrows the TS sent by host A and responses the narrowed TS = to host A
=A0
At this point, the narrowed TS includes the TSs that violates the poli= cy of initiator such as different protocol IDs of TSi and TSr, etc.
Then,=A0can host A (initiator)=A0also narrow the narrowed TSs, that is= to remove the case of which the protocol IDs are different?
=A0
I'm looking forward to responses.
=A0
Thanks in advance.
=A0
My Best Regards,
Jaemin Park

On Sat, Jun 19, 2010 at 12:07 AM, Scott C Moonen= <smoonen@us.ibm= .com> wrote:

Hi Jaemin,

The RFC allows you to narrow the proposed traffic sele= ctors to something smaller than what the peer proposes. From your descripti= on, it sounds like StrongSwan has made a pragmatic choice to narrow the pro= posed selectors to something symmetrical. This is allowed by the RFC. The T= CP&UDP case is a strange one, and in particular it doesn't accompli= sh much for TCP, but it is allowed by the RFC. If your SPD and/or SAD pragm= atically do not allow you to express this sort of asymmetry for IPsec-prote= cted traffic, then it is proper for you to respond with TS_UNACCEPTABLE to = such a proposal. You will of course be unable to interoperate with a peer m= aking such a proposal, but in this case I'm not sure that is a great ha= rdship.

Also don't forget to take into account complex proposals containing= more than one traffic selector for TSi and/or TSr.


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

3D"InactiveJae= min Park ---06/18/2010 10:51:53 AM---Dear All,

3D""
From:		 3D""
Jaemin Park <jm= park81@gmail.com>
3D""
To:		 3D""
ipsec@ietf.org
3D""
Date:		 3D""
06/18/2010 10:51 AM
3D""
Subject:		 3D""
[IPsec] Complexing of Traffic Selector (TSi & TSr)




Dear All,
=A0
I'm in charge of developing VPN= Clients based on IKEv2 and IPSec.
=A0We referred to the implementation of strongswan and RFC d= ocuments such as 4306 and 4718.
=A0
While developing, we faced = one question about complexing of Traffic Selectors.
According to the RFC 4718, complexing of TSi and TSr which have same pr= otocol IDs are defined and clarified.
However, in the case when TSi is (17 (udp) any any) and TS= r is (ip any any) where protocol IDs are different, should VPN complex TSi = and TSr?
According to the implementation of stro= ngswan, we could find the fact that the strongswan is checking when complex= ing the TSi and TSr as follows :
1) remove the policy which has different protocol IDs for = TSi and TSr as long as both of them are not "ANY"
2) follow the protocol which is not "ANY" if one of T= Si and TSr is "ANY"
According to my analysis, following examples can be possib= le :
- ANY & ANY yields ANY
- ANY & UDP yields UDP
- UDP &= ; UDP yields UDP
- TCP & UDP <-- remove this case
=A0
Does above implementation of strong= swan follow the standards?
If so, we're plan= ning to implement the way the strongswan supports.
=A0
I'm looking forward to = all of the experts' responses.
=A0My Best Regards,
Jaemin Park
--
Park, Jae Min
Assistant Manager
Device R&D Center , Convergence W= IBRO BU, KT
M : +82-10-3010-2658
T =A0: +82-2-2010-9255 =A0=
jmpark@kt.com, j= mpark81@gmail.com_______________________________________= ________
IPsec mailing list
I= Psec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec





--
Park, = Jae Min
Assistant Manager
Device R&D Center , Convergence WIBRO B= U, KT
M : +82-10-3010-2658
T =A0: +82-2-2010-9255 =A0
jmpark@kt.com, jmpark81@gmail.com
--00c09f9c9762d9753e048965a390-- --00c09f9c9762d97548048965a391 Content-Type: image/gif; name="ecblank.gif" Content-Transfer-Encoding: base64 Content-ID: <2__=0ABBFDD5DFC245F48f9e8a93df938@us.ibm.com> X-Attachment-Id: 6538da9caa981b1c_0.2 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --00c09f9c9762d97548048965a391 Content-Type: image/gif; name="graycol.gif" Content-Transfer-Encoding: base64 Content-ID: <1__=0ABBFDD5DFC245F48f9e8a93df938@us.ibm.com> X-Attachment-Id: 6538da9caa981b1c_0.1 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --00c09f9c9762d97548048965a391-- From rsjenwar@gmail.com Sat Jun 19 22:36:15 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C9B3A679C; Sat, 19 Jun 2010 22:36:15 -0700 (PDT) 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=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVAypyhOeptw; Sat, 19 Jun 2010 22:36:13 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 2C7C73A65A6; Sat, 19 Jun 2010 22:36:13 -0700 (PDT) Received: by vws15 with SMTP id 15so193228vws.31 for ; Sat, 19 Jun 2010 22:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=DB9UG0wDxso8PDretGIFpHUXg4EzMJWB0tBUSyth72U=; b=A5CfSZoyMfT6lpzz1TQoptIGkRVZiYueyBPOsSqdtttm86wDUX2SXDh9dyatvUb9PK AcPGtQYWHKy0F+Pxn+kQ2FwT+PoDzAx907L2tA0VNT/mHW8X63iAkem5Cb5EN/c0BZj5 FaRMr6TwtH61tObVH6huBxOtv9JrB3ZDeHT6o= 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=L16NaGex83n7S5fRcJLTbsQ3sAE3s2mK0w122kO16CzP+CafxzrWeMN/M/GKk0p3Bd irlDKjBvMVIbt9TSZz10ngieLLiApYGQHIneb9eXoQhYtmy0QXdYbtu8pxabadLCnll6 ROpdJJJ4cLX9iMpq0BIPsUdW5XMFnxqaW7Tl4= MIME-Version: 1.0 Received: by 10.229.182.3 with SMTP id ca3mr1760443qcb.11.1277012175821; Sat, 19 Jun 2010 22:36:15 -0700 (PDT) Received: by 10.229.221.132 with HTTP; Sat, 19 Jun 2010 22:36:15 -0700 (PDT) In-Reply-To: References: Date: Sun, 20 Jun 2010 11:06:15 +0530 Message-ID: From: Raj Singh To: Jaemin Park Content-Type: multipart/related; boundary=0016364175ad1d1bc604896f9107 Cc: ipsec , ipsec-bounces Subject: Re: [IPsec] Complexing of Traffic Selector (TSi & TSr) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 05:36:15 -0000 --0016364175ad1d1bc604896f9107 Content-Type: multipart/alternative; boundary=0016364175ad1d1bbf04896f9106 --0016364175ad1d1bbf04896f9106 Content-Type: text/plain; charset=UTF-8 Hi Jaemin, If initiator narrows down the TSr, then 1. the responder is not aware of initiator has narrowed down TSr and if it initiates a traffic which is from a broader section of range which Initiator has not accepted, there will data black-hole. 2. I think, better solution will be, If initiator has to narrow down the TSr, it can delete old Child SA and negotiate a new Child SA based on knowledge of TSr that are acceptable to initiator as well as responder. Regards, Raj On Sat, Jun 19, 2010 at 11:15 PM, Jaemin Park wrote: > Hi, Scott, > > I want to ask one more thing about Traffic Selector. > > In my case, host A and host B are working as follows about Traffic Selector > : > > 1) host A (initiator) sends TS to host B (responder) > 2) host B narrows the TS sent by host A and responses the narrowed TS to > host A > > At this point, the narrowed TS includes the TSs that violates the policy of > initiator such as different protocol IDs of TSi and TSr, etc. > Then, can host A (initiator) also narrow the narrowed TSs, that is to > remove the case of which the protocol IDs are different? > > I'm looking forward to responses. > > Thanks in advance. > > My Best Regards, > Jaemin Park > > On Sat, Jun 19, 2010 at 12:07 AM, Scott C Moonen wrote: > >> Hi Jaemin, >> >> The RFC allows you to narrow the proposed traffic selectors to something >> smaller than what the peer proposes. From your description, it sounds like >> StrongSwan has made a pragmatic choice to narrow the proposed selectors to >> something symmetrical. This is allowed by the RFC. The TCP&UDP case is a >> strange one, and in particular it doesn't accomplish much for TCP, but it is >> allowed by the RFC. If your SPD and/or SAD pragmatically do not allow you to >> express this sort of asymmetry for IPsec-protected traffic, then it is >> proper for you to respond with TS_UNACCEPTABLE to such a proposal. You will >> of course be unable to interoperate with a peer making such a proposal, but >> in this case I'm not sure that is a great hardship. >> >> Also don't forget to take into account complex proposals containing more >> than one traffic selector for TSi and/or TSr. >> >> >> Scott Moonen (smoonen@us.ibm.com) >> z/OS Communications Server TCP/IP Development >> http://www.linkedin.com/in/smoonen >> >> [image: Inactive hide details for Jaemin Park ---06/18/2010 10:51:53 >> AM---Dear All,]Jaemin Park ---06/18/2010 10:51:53 AM---Dear All, >> >> >> From: >> Jaemin Park >> To: >> ipsec@ietf.org >> Date: >> 06/18/2010 10:51 AM >> Subject: >> [IPsec] Complexing of Traffic Selector (TSi & TSr) >> ------------------------------ >> >> >> >> Dear All, >> >> I'm in charge of developing VPN Clients based on IKEv2 and IPSec. >> >> We referred to the implementation of strongswan and RFC documents such as >> 4306 and 4718. >> >> While developing, we faced one question about complexing of Traffic >> Selectors. >> According to the RFC 4718, complexing of TSi and TSr which have same >> protocol IDs are defined and clarified. >> However, in the case when TSi is (17 (udp) any any) and TSr is (ip any >> any) where protocol IDs are different, should VPN complex TSi and TSr? >> According to the implementation of strongswan, we could find the fact that >> the strongswan is checking when complexing the TSi and TSr as follows : >> 1) remove the policy which has different protocol IDs for TSi and TSr as >> long as both of them are not "ANY" >> 2) follow the protocol which is not "ANY" if one of TSi and TSr is "ANY" >> According to my analysis, following examples can be possible : >> - ANY & ANY yields ANY >> - ANY & UDP yields UDP >> - UDP & UDP yields UDP >> - TCP & UDP <-- remove this case >> >> Does above implementation of strongswan follow the standards? >> If so, we're planning to implement the way the strongswan supports. >> >> I'm looking forward to all of the experts' responses. >> >> My Best Regards, >> Jaemin Park >> >> -- >> Park, Jae Min >> Assistant Manager >> Device R&D Center , Convergence WIBRO BU, KT >> M : +82-10-3010-2658 >> T : +82-2-2010-9255 * >> * >> *jmpark@kt.com* , *jmpark81@gmail.com* >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> > > > -- > Park, Jae Min > Assistant Manager > Device R&D Center , Convergence WIBRO BU, KT > M : +82-10-3010-2658 > T : +82-2-2010-9255 > jmpark@kt.com, jmpark81@gmail.com > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --0016364175ad1d1bbf04896f9106 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jaemin,

If initiator narrows down the TSr, then=C2=A0=
1. the responder is not aware of initiator has narrowed down TSr= and if it initiates a traffic which is from a broader section of range whi= ch Initiator has not accepted, there will data black-hole.
2. I think, better solution will be, If initiator has to narrow down t= he TSr, it can delete old Child SA and negotiate a new Child SA based on kn= owledge of TSr that are acceptable to initiator as well as responder.

Regards,
Raj


On Sat, Jun 19, 2010 at 11:15 PM, Jaemin Park <jmpark81@gmail.com> wrote:
Hi, Scott,
=C2=A0
I want to ask one more thing about Traffic Selector.
=C2=A0
In my case, host A and host B are working as follows about Traffic Sel= ector :
=C2=A0
1) host A (initiator)=C2=A0sends TS=C2=A0to host B (responder)
2) host B narrows the TS sent by host A and responses the narrowed TS = to host A
=C2=A0
At this point, the narrowed TS includes the TSs that violates the poli= cy of initiator such as different protocol IDs of TSi and TSr, etc.
Then,=C2=A0can host A (initiator)=C2=A0also narrow the narrowed TSs, t= hat is to remove the case of which the protocol IDs are different?
=C2=A0
I'm looking forward to responses.
=C2=A0
Thanks in advance.
=C2=A0
My Best Regards,
Jaemin Park

On Sat, = Jun 19, 2010 at 12:07 AM, Scott C Moonen <smoonen@us.ibm.com> wrote:

Hi Jaemin,

The RFC allows you to narrow the proposed traffic sele= ctors to something smaller than what the peer proposes. From your descripti= on, it sounds like StrongSwan has made a pragmatic choice to narrow the pro= posed selectors to something symmetrical. This is allowed by the RFC. The T= CP&UDP case is a strange one, and in particular it doesn't accompli= sh much for TCP, but it is allowed by the RFC. If your SPD and/or SAD pragm= atically do not allow you to express this sort of asymmetry for IPsec-prote= cted traffic, then it is proper for you to respond with TS_UNACCEPTABLE to = such a proposal. You will of course be unable to interoperate with a peer m= aking such a proposal, but in this case I'm not sure that is a great ha= rdship.

Also don't forget to take into account complex proposals containing= more than one traffic selector for TSi and/or TSr.


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

3D"InactiveJae= min Park ---06/18/2010 10:51:53 AM---Dear All,

3D""
From:		 3D""
Jaemin Park <jm= park81@gmail.com>
3D""
To:		 3D""
ipsec@ietf.org
3D""
Date:		 3D""
06/18/2010 10:51 AM
3D""
Subject:		 3D""
[IPsec] Complexing of Traffic Selector (TSi & TSr)



Dear All,
=C2= =A0
I'm in charge of developing VPN Clients = based on IKEv2 and IPSec.
=C2=A0
We referred to the implementation of strongswan and RFC documen= ts such as 4306 and 4718.
=C2=A0
While developing, we fac= ed one question about complexing of Traffic Selectors.
According to the RFC 4718, complexing of TSi and TSr which have same= protocol IDs are defined and clarified.
However, in the case when TSi is (17 (udp) any any) and TS= r is (ip any any) where protocol IDs are different, should VPN complex TSi = and TSr?
According to the implementation of stro= ngswan, we could find the fact that the strongswan is checking when complex= ing the TSi and TSr as follows :
1) remove the policy which has different protocol IDs for = TSi and TSr as long as both of them are not "ANY"
2) follow the protocol which is not "ANY" if one of T= Si and TSr is "ANY"
According to my analysis, following examples can be possib= le :
- ANY & ANY yields ANY
- ANY & UDP yields UDP
- UDP &= ; UDP yields UDP
- TCP & UDP <-- remove this case
=C2=A0
Does above implementation of str= ongswan follow the standards?
If so, we're p= lanning to implement the way the strongswan supports.
=C2=A0
I'm looking forward = to all of the experts' responses.
=C2=A0
My Best Regards,
Jaemin = Park

--
Park, Jae Min
Assistant Manager
Device R&D Center , Convergence W= IBRO BU, KT
M : +82-10-3010-2658
T =C2=A0: +82-2-2010-9255 =C2=A0
jmpark@kt.com, jmpark81@gmail.com_______________________________= ________________
IPsec mailing list
I= Psec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec





--
Par= k, Jae Min
Assistant Manager
Device R&D Center , Convergence WIBR= O BU, KT
M : +82-10-3010-2658
T =C2=A0: +82-2-2010-9255 =C2=A0
jmpark@kt.com, jmpark81@gmail.com

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


--0016364175ad1d1bbf04896f9106-- --0016364175ad1d1bc604896f9107 Content-Type: image/gif; name="ecblank.gif" Content-Transfer-Encoding: base64 Content-ID: <2__=0ABBFDD5DFC245F48f9e8a93df938@us.ibm.com> X-Attachment-Id: 6538da9caa981b1c_0.2 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0016364175ad1d1bc604896f9107 Content-Type: image/gif; name="graycol.gif" Content-Transfer-Encoding: base64 Content-ID: <1__=0ABBFDD5DFC245F48f9e8a93df938@us.ibm.com> X-Attachment-Id: 6538da9caa981b1c_0.1 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0016364175ad1d1bc604896f9107-- From jmpark81@gmail.com Sun Jun 20 00:36:29 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B5F3A6823; Sun, 20 Jun 2010 00:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.866 X-Spam-Level: ** X-Spam-Status: No, score=2.866 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuTCWhBoIEli; Sun, 20 Jun 2010 00:36:27 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id AB4E33A6783; Sun, 20 Jun 2010 00:36:27 -0700 (PDT) Received: by pvc21 with SMTP id 21so463624pvc.31 for ; Sun, 20 Jun 2010 00:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=zd4XqZ/JgSbZVinIWfgNmCM/JlfAqe29KcBxVmS0Q+c=; b=cHlgUvfjX8wKl/yB6PNsR3sXIAM7AxrF9t/nUzuhjXItVQ7iDFraeJSUdtNOvO33ah WyeMgHjpEKXzhuf7GCvbQAeGIg7wnnHP1sozUrIhTuSscZSFG3Yxj+W5pALCWwBa/FxK 16qDwu5pR8VrWfwZAXzz17Ralfy7cUgLnhKik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=SUjf13cLqliuB/SsesipDvwFHqKgn8xTV330SKWtS9v23bg7d2Xw34KcUo2dVu2+Et eEOUyn2mv+w66aZqsacsU+HnEJK7Uliv4sDmpzROqpT3ZHKJUnTxrp+LmSGQ0uAgY62j nD1LfKXURoglXP/tAkgIwaKzbzUb9VgExeyqk= Received: by 10.142.247.28 with SMTP id u28mr2271313wfh.69.1277019391540; Sun, 20 Jun 2010 00:36:31 -0700 (PDT) Received: from [110.68.84.35] ([110.68.84.35]) by mx.google.com with ESMTPS id r20sm56297895wam.17.2010.06.20.00.36.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 20 Jun 2010 00:36:30 -0700 (PDT) References: Message-Id: From: Jaemin Park To: Raj Singh In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-5-211955918 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7E18) Mime-Version: 1.0 (iPhone Mail 7E18) Date: Sun, 20 Jun 2010 16:36:22 +0900 Cc: ipsec , ipsec-bounces Subject: Re: [IPsec] Complexing of Traffic Selector (TSi & TSr) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 07:36:29 -0000 --Apple-Mail-5-211955918 Content-Type: text/plain; charset=euc-kr; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Dear All, I need to clarify my question. My question is about the way for initiator to complex the TS narrowed =20= by responder. Suppose that following TSs are returned by the responder. 1) TSi =3D (TS1, TS2) 2) TSr =3D (TS3, TS4, TS5) While complexing, the case TS1 and TS5 need to be removed by initiator =20= due to the difference of protocol ID and violation of the intended =20= policy. Can initiator remove the above case and follow the RFC? I'm looking forward to the experts' responses. Thanks in advance. =46rom My iPhone 2010. 6. 20. =BF=C0=C8=C4 2:36 Raj Singh =C0=DB=BC=BA= : > Hi Jaemin, > > If initiator narrows down the TSr, then > 1. the responder is not aware of initiator has narrowed down TSr and =20= > if it initiates a traffic which is from a broader section of range =20 > which Initiator has not accepted, there will data black-hole. > 2. I think, better solution will be, If initiator has to narrow down =20= > the TSr, it can delete old Child SA and negotiate a new Child SA =20 > based on knowledge of TSr that are acceptable to initiator as well =20 > as responder. > > Regards, > Raj > > > On Sat, Jun 19, 2010 at 11:15 PM, Jaemin Park =20 > wrote: > Hi, Scott, > > I want to ask one more thing about Traffic Selector. > > In my case, host A and host B are working as follows about Traffic =20 > Selector : > > 1) host A (initiator) sends TS to host B (responder) > 2) host B narrows the TS sent by host A and responses the narrowed =20 > TS to host A > > At this point, the narrowed TS includes the TSs that violates the =20 > policy of initiator such as different protocol IDs of TSi and TSr, =20 > etc. > Then, can host A (initiator) also narrow the narrowed TSs, that is =20 > to remove the case of which the protocol IDs are different? > > I'm looking forward to responses. > > Thanks in advance. > > My Best Regards, > Jaemin Park > > On Sat, Jun 19, 2010 at 12:07 AM, Scott C Moonen =20 > wrote: > Hi Jaemin, > > The RFC allows you to narrow the proposed traffic selectors to =20 > something smaller than what the peer proposes. =46rom your =20 > description, it sounds like StrongSwan has made a pragmatic choice =20 > to narrow the proposed selectors to something symmetrical. This is =20 > allowed by the RFC. The TCP&UDP case is a strange one, and in =20 > particular it doesn't accomplish much for TCP, but it is allowed by =20= > the RFC. If your SPD and/or SAD pragmatically do not allow you to =20 > express this sort of asymmetry for IPsec-protected traffic, then it =20= > is proper for you to respond with TS_UNACCEPTABLE to such a =20 > proposal. You will of course be unable to interoperate with a peer =20 > making such a proposal, but in this case I'm not sure that is a =20 > great hardship. > > Also don't forget to take into account complex proposals containing =20= > more than one traffic selector for TSi and/or TSr. > > > Scott Moonen (smoonen@us.ibm.com) > z/OS Communications Server TCP/IP Development > http://www.linkedin.com/in/smoonen > > Jaemin Park ---06/18/2010 10:51:53 AM---Dear All, > > > From: > Jaemin Park > > To: > ipsec@ietf.org > > Date: > 06/18/2010 10:51 AM > > Subject: > [IPsec] Complexing of Traffic Selector (TSi & TSr) > > > > Dear All, > > I'm in charge of developing VPN Clients based on IKEv2 and IPSec. > > We referred to the implementation of strongswan and RFC documents =20 > such as 4306 and 4718. > > While developing, we faced one question about complexing of Traffic =20= > Selectors. > According to the RFC 4718, complexing of TSi and TSr which have same =20= > protocol IDs are defined and clarified. > However, in the case when TSi is (17 (udp) any any) and TSr is (ip =20 > any any) where protocol IDs are different, should VPN complex TSi =20 > and TSr? > According to the implementation of strongswan, we could find the =20 > fact that the strongswan is checking when complexing the TSi and TSr =20= > as follows : > 1) remove the policy which has different protocol IDs for TSi and =20 > TSr as long as both of them are not "ANY" > 2) follow the protocol which is not "ANY" if one of TSi and TSr is =20 > "ANY" > According to my analysis, following examples can be possible : > - ANY & ANY yields ANY > - ANY & UDP yields UDP > - UDP & UDP yields UDP > - TCP & UDP <-- remove this case > > Does above implementation of strongswan follow the standards? > If so, we're planning to implement the way the strongswan supports. > > I'm looking forward to all of the experts' responses. > > My Best Regards, > Jaemin Park > > --=20 > Park, Jae Min > Assistant Manager > Device R&D Center , Convergence WIBRO BU, KT > M : +82-10-3010-2658 > T : +82-2-2010-9255 > jmpark@kt.com, =20 > jmpark81@gmail.com_______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > --=20 > Park, Jae Min > Assistant Manager > Device R&D Center , Convergence WIBRO BU, KT > M : +82-10-3010-2658 > T : +82-2-2010-9255 > jmpark@kt.com, jmpark81@gmail.com > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --Apple-Mail-5-211955918 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear = All,

I need to clarify my = question.
My question is about the way for initiator to = complex the TS narrowed by responder.

Suppose = that following TSs are returned by the = responder.

1) TSi =3D (TS1, TS2)
2) = TSr =3D (TS3, TS4, TS5)

While complexing, the = case TS1 and TS5 need to be removed by initiator due to the difference = of protocol ID and     violation of the intended = policy.

Can initiator remove the above case and = follow the RFC?

I'm looking forward to the = experts' responses.

Thanks in = advance.

=46rom My iPhone

2010. 6. 20. = =EC=98=A4=ED=9B=84 2:36 Raj Singh <rsjenwar@gmail.com> = =EC=9E=91=EC=84=B1:

Hi Jaemin,

If initiator narrows = down the TSr, then 
1. the responder is not aware of = initiator has narrowed down TSr and if it initiates a traffic which is = from a broader section of range which Initiator has not accepted, there = will data black-hole.
2. I think, better solution will be, If initiator has to narrow = down the TSr, it can delete old Child SA and negotiate a new Child SA = based on knowledge of TSr that are acceptable to initiator as well as = responder.

Regards,
Raj


On Sat, Jun 19, 2010 at 11:15 PM, Jaemin Park = <jmpark81@gmail.com> = wrote:
Hi, Scott,
 
I want to ask one more thing about Traffic Selector.
 
In my case, host A and host B are working as follows about Traffic = Selector :
 
1) host A (initiator) sends TS to host B = (responder)
2) host B narrows the TS sent by host A and responses the narrowed = TS to host A
 
At this point, the narrowed TS includes the TSs that violates the = policy of initiator such as different protocol IDs of TSi and TSr, = etc.
Then, can host A (initiator) also narrow the narrowed = TSs, that is to remove the case of which the protocol IDs are = different?
 
I'm looking forward to responses.
 
Thanks in advance.
 
My Best Regards,
Jaemin Park

On = Sat, Jun 19, 2010 at 12:07 AM, Scott C Moonen <smoonen@us.ibm.com> = wrote:

Hi Jaemin,

The RFC allows you to narrow the proposed traffic = selectors to something smaller than what the peer proposes. =46rom your = description, it sounds like StrongSwan has made a pragmatic choice to = narrow the proposed selectors to something symmetrical. This is allowed = by the RFC. The TCP&UDP case is a strange one, and in particular it = doesn't accomplish much for TCP, but it is allowed by the RFC. If your = SPD and/or SAD pragmatically do not allow you to express this sort of = asymmetry for IPsec-protected traffic, then it is proper for you to = respond with TS_UNACCEPTABLE to such a proposal. You will of course be = unable to interoperate with a peer making such a proposal, but in this = case I'm not sure that is a great hardship.

Also don't forget to take into account complex proposals containing = more than one traffic selector for TSi and/or TSr.


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

<graycol.gif>Jaemin = Park ---06/18/2010 10:51:53 AM---Dear All,

<ecblank.gif>
From:		 <ecblank.gif>
Jaemin Park = <jmpark81@gmail.com>
<ecblank.gif>
To:		 <ecblank.gif>
ipsec@ietf.org
<ecblank.gif>
Date:		 <ecblank.gif>
06/18/2010 = 10:51 AM
<ecblank.gif>
Subject:		 <ecblank.gif>
[IPsec] = Complexing of Traffic Selector (TSi & = TSr)



Dear All,
 
I'm in charge of developing = VPN Clients based on IKEv2 and IPSec.
 
We referred to the = implementation of strongswan and RFC documents such as 4306 and = 4718.
 
While developing, we = faced one question about complexing of Traffic = Selectors.
According to the RFC 4718, = complexing of TSi and TSr which have same protocol IDs are defined and = clarified.
However, in the case when TSi is (17 (udp) any any) and = TSr is (ip any any) where protocol IDs are different, should VPN complex = TSi and TSr?
According to the implementation = of strongswan, we could find the fact that the strongswan is checking = when complexing the TSi and TSr as follows :
1) remove the policy which has different protocol IDs = for TSi and TSr as long as both of them are not "ANY"
2) follow the protocol which is not "ANY" if one of TSi and = TSr is "ANY"
According to my analysis, following examples can be = possible :
- ANY & ANY yields = ANY
- ANY & UDP yields = UDP
- UDP & UDP yields UDP
- TCP & UDP <-- remove this case
 
Does above implementation = of strongswan follow the standards?
If so, = we're planning to implement the way the strongswan supports.
 
I'm looking forward = to all of the experts' responses.
 
My Best = Regards,
Jaemin Park

--
Park, Jae Min
Assistant Manager
Device R&D Center , = Convergence WIBRO BU, KT
M : +82-10-3010-2658
T  : = +82-2-2010-9255  
jmpark@kt.com, jmpark81@gmail.com__________________________= _____________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/= mailman/listinfo/ipsec





-- =
Park, Jae Min
Assistant Manager
Device R&D Center , = Convergence WIBRO BU, KT
M : +82-10-3010-2658
T  : = +82-2-2010-9255  
jmpark@kt.com, = jmpark81@gmail.com

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


= --Apple-Mail-5-211955918-- From rsjenwar@gmail.com Mon Jun 21 06:48:03 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1276128C0E2; Mon, 21 Jun 2010 06:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=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 v+dEhXAPvvel; Mon, 21 Jun 2010 06:47:58 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 0265E3A6A86; Mon, 21 Jun 2010 06:47:57 -0700 (PDT) Received: by wya21 with SMTP id 21so2632283wya.31 for ; Mon, 21 Jun 2010 06:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=s1V/rznQGsBy5rqkzJyUfSGxFepbcNw0UJQRMkxZ5IQ=; b=MfTRDLP40kKzOuQKXTHo6TlSkHlntgTX0voalgwuQ9nyVXNHAU9jkhBD98WMg5QEOg fn0idmJ1CAM0ksvxvXCW+kums2NsmTs7X4adbgoUg/jDdhNNanmgtmL04+C8vd5pcFUs lbPAf6MUPAYQhhJv3yZlCplt0npRRkSHgckq8= 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=ilfJHUNnfkIS68IlSjuiPHGkF2DDLvp2kTrW6SdxG3Y8z1loMeZXH1wgcivIEURTg/ k16y9v+jYpFXK9yLQufWE2s86Fn2/iIACQ726oRktl67P0iiRSN1zF/hJiNLIBhJeEIM 23b9j7/Rdz2YJuRoK97xa3elbhSj8tC/w0BTM= MIME-Version: 1.0 Received: by 10.216.86.140 with SMTP id w12mr3480889wee.95.1277127684722; Mon, 21 Jun 2010 06:41:24 -0700 (PDT) Received: by 10.216.172.138 with HTTP; Mon, 21 Jun 2010 06:41:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Jun 2010 19:11:24 +0530 Message-ID: From: Raj Singh To: Jaemin Park Content-Type: multipart/alternative; boundary=0016e6d9a116fb0fbe04898a7596 Cc: ipsec , ipsec-bounces Subject: Re: [IPsec] Complexing of Traffic Selector (TSi & TSr) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 13:48:03 -0000 --0016e6d9a116fb0fbe04898a7596 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jaemin, The problem is at initiator side, when its sending its TSi/TSr, it sending some range which is violating its own policies. This is not allowed by RFC as per section 2.9.1. Regards, Raj 2010/6/20 Jaemin Park > Dear All, > > I need to clarify my question. > My question is about the way for initiator to complex the TS narrowed by > responder. > > Suppose that following TSs are returned by the responder. > > 1) TSi =3D (TS1, TS2) > 2) TSr =3D (TS3, TS4, TS5) > > While complexing, the case TS1 and TS5 need to be removed by initiator du= e > to the difference of protocol ID and violation of the intended policy= . > > Can initiator remove the above case and follow the RFC? > > I'm looking forward to the experts' responses. > > Thanks in advance. > > From My iPhone > > 2010. 6. 20. =EC=98=A4=ED=9B=84 2:36 Raj Singh =EC= =9E=91=EC=84=B1: > > Hi Jaemin, > > If initiator narrows down the TSr, then > 1. the responder is not aware of initiator has narrowed down TSr and if i= t > initiates a traffic which is from a broader section of range which Initia= tor > has not accepted, there will data black-hole. > 2. I think, better solution will be, If initiator has to narrow down the > TSr, it can delete old Child SA and negotiate a new Child SA based on > knowledge of TSr that are acceptable to initiator as well as responder. > > Regards, > Raj > > > On Sat, Jun 19, 2010 at 11:15 PM, Jaemin Park < > jmpark81@gmail.com> wrote: > >> Hi, Scott, >> >> I want to ask one more thing about Traffic Selector. >> >> In my case, host A and host B are working as follows about Traffic >> Selector : >> >> 1) host A (initiator) sends TS to host B (responder) >> 2) host B narrows the TS sent by host A and responses the narrowed TS to >> host A >> >> At this point, the narrowed TS includes the TSs that violates the policy >> of initiator such as different protocol IDs of TSi and TSr, etc. >> Then, can host A (initiator) also narrow the narrowed TSs, that is to >> remove the case of which the protocol IDs are different? >> >> I'm looking forward to responses. >> >> Thanks in advance. >> >> My Best Regards, >> Jaemin Park >> >> On Sat, Jun 19, 2010 at 12:07 AM, Scott C Moonen < >> smoonen@us.ibm.com> wrote: >> >>> Hi Jaemin, >>> >>> The RFC allows you to narrow the proposed traffic selectors to somethin= g >>> smaller than what the peer proposes. From your description, it sounds l= ike >>> StrongSwan has made a pragmatic choice to narrow the proposed selectors= to >>> something symmetrical. This is allowed by the RFC. The TCP&UDP case is = a >>> strange one, and in particular it doesn't accomplish much for TCP, but = it is >>> allowed by the RFC. If your SPD and/or SAD pragmatically do not allow y= ou to >>> express this sort of asymmetry for IPsec-protected traffic, then it is >>> proper for you to respond with TS_UNACCEPTABLE to such a proposal. You = will >>> of course be unable to interoperate with a peer making such a proposal,= but >>> in this case I'm not sure that is a great hardship. >>> >>> Also don't forget to take into account complex proposals containing mor= e >>> than one traffic selector for TSi and/or TSr. >>> >>> >>> Scott Moonen ( smoonen@us.ibm.com) >>> z/OS Communications Server TCP/IP Development >>> http://www.linkedin.com/in/smoonen >>> >>> Jaemin Park ---06/18/2010 10:51:53 AM---Dear All, >>> >>> >>> From: >>> >>> Jaemin Park < jmpark81@gmail.com> >>> >>> To: >>> ipsec@ietf.org >>> Date: >>> >>> 06/18/2010 10:51 AM >>> >>> Subject: >>> >>> [IPsec] Complexing of Traffic Selector (TSi & TSr) >>> ------------------------------ >>> >>> >>> >>> Dear All, >>> >>> I'm in charge of developing VPN Clients based on IKEv2 and IPSec. >>> >>> We referred to the implementation of strongswan and RFC documents such = as >>> 4306 and 4718. >>> >>> While developing, we faced one question about complexing of Traffic >>> Selectors. >>> According to the RFC 4718, complexing of TSi and TSr which have same >>> protocol IDs are defined and clarified. >>> However, in the case when TSi is (17 (udp) any any) and TSr is (ip any >>> any) where protocol IDs are different, should VPN complex TSi and TSr? >>> According to the implementation of strongswan, we could find the fact >>> that the strongswan is checking when complexing the TSi and TSr as foll= ows : >>> 1) remove the policy which has different protocol IDs for TSi and TSr a= s >>> long as both of them are not "ANY" >>> 2) follow the protocol which is not "ANY" if one of TSi and TSr is "ANY= " >>> According to my analysis, following examples can be possible : >>> - ANY & ANY yields ANY >>> - ANY & UDP yields UDP >>> - UDP & UDP yields UDP >>> - TCP & UDP <-- remove this case >>> >>> Does above implementation of strongswan follow the standards? >>> If so, we're planning to implement the way the strongswan supports. >>> >>> I'm looking forward to all of the experts' responses. >>> >>> My Best Regards, >>> Jaemin Park >>> >>> -- >>> Park, Jae Min >>> Assistant Manager >>> Device R&D Center , Convergence WIBRO BU, KT >>> M : +82-10-3010-2658 >>> T : +82-2-2010-9255 * >>> * >>> *jmpark@kt.com* , *jmpark81@gmail.com* >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> >>> >> >> >> -- >> Park, Jae Min >> Assistant Manager >> Device R&D Center , Convergence WIBRO BU, KT >> M : +82-10-3010-2658 >> T : +82-2-2010-9255 >> jmpark@kt.com, jmpark81@gmail.com >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > --0016e6d9a116fb0fbe04898a7596 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jaemin,

The problem is at initiator side, when its se= nding its TSi/TSr, it sending some range which is violating its own policie= s. This is not allowed by RFC as per section 2.9.1.

Regards,
Raj


20= 10/6/20 Jaemin Park <jmpark81@gmail.com>
Dear All,

I need to = clarify my question.
My question is about the way for initiator t= o complex the TS narrowed by responder.

Suppose th= at following TSs are returned by the responder.

1) TSi =3D (TS1, TS2)
2) TSr =3D (TS3, TS4, T= S5)

While complexing, the case TS1 and TS5 need to= be removed by initiator due to the difference of protocol ID and =C2=A0 = =C2=A0 violation of the intended policy.

Can initiator remove the above case and follow the RFC?=

I'm looking forward to the experts' respo= nses.

Thanks in advance.

From My iPh= one

2010. 6. 20. =EC=98=A4=ED=9B=84 2:36 Raj Singh <rsjenwar@gmail.com> =EC=9E= =91=EC=84=B1:

<= div>
Hi Jaemin,

If initiator narrows down the TSr, then=C2=A0
1. t= he responder is not aware of initiator has narrowed down TSr and if it init= iates a traffic which is from a broader section of range which Initiator ha= s not accepted, there will data black-hole.
2. I think, better solution will be, If initiator has to narrow down t= he TSr, it can delete old Child SA and negotiate a new Child SA based on kn= owledge of TSr that are acceptable to initiator as well as responder.

Regards,
Raj


On Sat, Jun 19, = 2010 at 11:15 PM, Jaemin Park <jmpark81@gmail.com> wrote:
Hi, Scott,
=C2=A0
I want to ask one more thing about Traffic Selector.
=C2=A0
In my case, host A and host B are working as follows about Traffic Sel= ector :
=C2=A0
1) host A (initiator)=C2=A0sends TS=C2=A0to host B (responder)
2) host B narrows the TS sent by host A and responses the narrowed TS = to host A
=C2=A0
At this point, the narrowed TS includes the TSs that violates the poli= cy of initiator such as different protocol IDs of TSi and TSr, etc.
Then,=C2=A0can host A (initiator)=C2=A0also narrow the narrowed TSs, t= hat is to remove the case of which the protocol IDs are different?
=C2=A0
I'm looking forward to responses.
=C2=A0
Thanks in advance.
=C2=A0
My Best Regards,
Jaemin Park

On Sat, Jun 19, 2010 at 12:07 AM, Scott C Moonen <= span dir=3D"ltr"><smoonen@us.ib= m.com> wrote:

Hi Jaemin,

The RFC allows y= ou to narrow the proposed traffic selectors to something smaller than what = the peer proposes. From your description, it sounds like StrongSwan has mad= e a pragmatic choice to narrow the proposed selectors to something symmetri= cal. This is allowed by the RFC. The TCP&UDP case is a strange one, and= in particular it doesn't accomplish much for TCP, but it is allowed by= the RFC. If your SPD and/or SAD pragmatically do not allow you to express = this sort of asymmetry for IPsec-protected traffic, then it is proper for y= ou to respond with TS_UNACCEPTABLE to such a proposal. You will of course b= e unable to interoperate with a peer making such a proposal, but in this ca= se I'm not sure that is a great hardship.

Also don't forget to take into account complex proposals containing= more than one traffic selector for TSi and/or TSr.


Scott Moonen= (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
=
<graycol.gif>Jaemin Park ---06/18= /2010 10:51:53 AM---Dear All,

<ecblank.gif>
= From:		 <ecblank.gif>

Jaemin Park <<= /a>jmpark81@gmail.c= om>
<ecblank.gif>
= To:		 <ecblank.gif>
ipsec@ietf.org
<ecblank.gif>
= Date:		 <ecblank.gif>

06/18/2010 10:51 AM
<ecblank.gif>
= Subject:		 <ecblank.gif>
[IPsec] Complexing of Traffic Selector (TSi & TSr)



Dear All,
=C2= =A0
I'm in charge of developing VPN Clients = based on IKEv2 and IPSec.
=C2=A0
We referred to the implementation of strongswan and RFC documen= ts such as 4306 and 4718.
=C2=A0
While developing, we fac= ed one question about complexing of Traffic Selectors.
According to the RFC 4718, complexing of TSi and TSr which have same= protocol IDs are defined and clarified.
However, in the case when TSi is (17 (udp) any any) and TS= r is (ip any any) where protocol IDs are different, should VPN complex TSi = and TSr?
According to the implementation of stro= ngswan, we could find the fact that the strongswan is checking when complex= ing the TSi and TSr as follows :
1) remove the policy which has different protocol IDs for = TSi and TSr as long as both of them are not "ANY"
2) follow the protocol which is not "ANY" if one of T= Si and TSr is "ANY"
According to my analysis, following examples can be possib= le :
- ANY & ANY yields ANY
- ANY & UDP yields UDP
- UDP &= ; UDP yields UDP
- TCP & UDP <-- remove this case
=C2=A0
Does above implementation of str= ongswan follow the standards?
If so, we're p= lanning to implement the way the strongswan supports.
=C2=A0
I'm looking forward = to all of the experts' responses.
=C2=A0
My Best Regards,
Jaemin = Park

--
Park, Jae Min
Assistant Manager
Device R&D Center , Convergence W= IBRO BU, KT
M : +82-10-3010-2658
T =C2=A0: +82-2-2010-9255 =C2=A0
jmpark@kt.com, jmpark81@gmail.com_______________________________= ________________
IPsec mailing list
<= /a>IPsec@ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec





--
Park, Jae Min
Assistant Manag= er
Device R&D Center , Convergence WIBRO BU, KT
M : +82-10-3010-2= 658
T =C2=A0: +82-2-2010-9255 =C2=A0
jmpark@k= t.com, jmpark81@gmail.com<= br>

_____________= __________________________________
IPsec mailing list
IPsec@ietf.org
<= /a>https://www.ietf.org/mailman/listinfo/ipsec



--0016e6d9a116fb0fbe04898a7596-- From yaronf.ietf@gmail.com Mon Jun 21 09:31:37 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1CBD3A69EF for ; Mon, 21 Jun 2010 09:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=1.133, 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 VuIyPSf-VeO2 for ; Mon, 21 Jun 2010 09:31:37 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 240633A6A67 for ; Mon, 21 Jun 2010 09:31:25 -0700 (PDT) Received: by wya21 with SMTP id 21so2791529wya.31 for ; Mon, 21 Jun 2010 09:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=pG3tKnaVKhY1JBjmjsjDMkFahjPD7UwDd0AtyRuu1DQ=; b=nn7Sbusb8s1uWkiYZm5SxD2d9qtRWQ9L3Efyvcp0uY7tXhsEEXOdQQikqmX6L8TYPC u+pqLfJvDY2f4Mv+tVcvcGdAurkhcPulvCKEPUaTHc6hCJ/IihM1e2WPqwMIXw9AgJ+y GYe6V3JPvXnne3eaGb/q5CgIrTSdNSTQ3EglI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=FbXlV62OkjXx1ZJGV86f/IwBvkS3Kr7Y2UgDBmRoTV8/FK5T2Yw5WwkiKgENhJlul3 7aicazrIKEEZx3VgGCkeQDszrrROHAdnYwzUpGzOfCFACJJnyLRKOSznhJfMJgmTl11V Yfb0mld4gWGWaWKIblXarj+1BAxNMi2zJi/Ik= Received: by 10.227.135.2 with SMTP id l2mr4885168wbt.216.1277137888896; Mon, 21 Jun 2010 09:31:28 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-178-30-177.red.bezeqint.net [79.178.30.177]) by mx.google.com with ESMTPS id y31sm26218368wby.16.2010.06.21.09.31.26 (version=SSLv3 cipher=RC4-MD5); Mon, 21 Jun 2010 09:31:27 -0700 (PDT) Message-ID: <4C1F93DA.4070200@gmail.com> Date: Mon, 21 Jun 2010 19:31:22 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] EAP Mutual Auth and IKE session resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 16:31:38 -0000 Hi, EAP-Mutual has just gone through IESG review, but I'd like to make one more addition and would appreciate the group's feedback. The interaction between this draft (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eap-mutual/) and session resumption (RFC 5723 ) is simple, but I think should still be pointed out. So I was thinking of adding this text at the end of Sec. 3: An IKE SA that was set up with this extension can be resumed using the mechanism described in . However session resumption does not change the authentication method. Therefore during the IKE_AUTH exchange of the resumed session, this extension MUST NOT be sent by the initiator. All comments welcome. Thanks, Yaron From paul.hoffman@vpnc.org Mon Jun 21 10:49:12 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4ABC3A6AB3 for ; Mon, 21 Jun 2010 10:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.67 X-Spam-Level: X-Spam-Status: No, score=0.67 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqhxmpZsWf51 for ; Mon, 21 Jun 2010 10:49:11 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 11D0B3A6AA6 for ; Mon, 21 Jun 2010 10:49:11 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5LHnEvD023341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Jun 2010 10:49:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C1F93DA.4070200@gmail.com> References: <4C1F93DA.4070200@gmail.com> Date: Mon, 21 Jun 2010 10:49:13 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] EAP Mutual Auth and IKE session resumption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 17:49:12 -0000 At 7:31 PM +0300 6/21/10, Yaron Sheffer wrote: >Hi, > > >EAP-Mutual has just gone through IESG review, but I'd like to make one more addition and would appreciate the group's feedback. > > >The interaction between this draft (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eap-mutual/) and session resumption (RFC 5723 ) is simple, but I think should still be pointed out. So I was thinking of adding this text at the end of Sec. 3: > > > An IKE SA that was set up with this extension can be resumed using the mechanism described > in . However session resumption does not change the authentication > method. Therefore during the IKE_AUTH exchange of the resumed > session, this extension MUST NOT be sent by the initiator. > >All comments welcome. Please respond before Friday so that we move this document forwards. Yaron's other proposed changes to the draft are simple clarifications to clear IESG concerns. --Paul Hoffman, Director --VPN Consortium From root@core3.amsl.com Thu Jun 24 08:00:02 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 187A53A69B3; Thu, 24 Jun 2010 08:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100624150002.187A53A69B3@core3.amsl.com> Date: Thu, 24 Jun 2010 08:00:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ipsec-ha-07.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: Thu, 24 Jun 2010 15: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 : IPsec Cluster Problem Statement Author(s) : Y. Nir Filename : draft-ietf-ipsecme-ipsec-ha-07.txt Pages : 12 Date : 2010-06-24 This document defines terminology, problem statement and requirements for implementing IKE and IPsec on clusters. It also describes gaps in existing standards and their implementation that need to be filled, in order to allow peers to interoperate with clusters from different vendors. An agreed terminology, problem statement and requirements will allow the IPSECME WG to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsec-ha-07.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-ipsec-ha-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-24074933.I-D@ietf.org> --NextPart-- From ynir@checkpoint.com Thu Jun 24 08:01:24 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53A6C3A69F2 for ; Thu, 24 Jun 2010 08:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[AWL=0.838, 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 zrsgQ8n9O3f0 for ; Thu, 24 Jun 2010 08:01:23 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id E87B13A69EB for ; Thu, 24 Jun 2010 08:01:22 -0700 (PDT) X-CheckPoint: {4C23807B-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o5OF1UDq012433 for ; Thu, 24 Jun 2010 18:01:30 +0300 (IDT) 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 Jun 2010 18:02:00 +0300 From: Yoav Nir To: "ipsec@ietf.org WG" Date: Thu, 24 Jun 2010 18:01:30 +0300 Thread-Topic: I-D Action:draft-ietf-ipsecme-ipsec-ha-07.txt Thread-Index: AcsTrjKbzjBMvoe0QmC7ST0wZmc9rw== Message-ID: References: <20100624150002.187A53A69B3@core3.amsl.com> In-Reply-To: <20100624150002.187A53A69B3@core3.amsl.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] I-D Action:draft-ietf-ipsecme-ipsec-ha-07.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: Thu, 24 Jun 2010 15:01:24 -0000 Hi all No big changes here. Just some nits from the secdir review. Yoav On Jun 24, 2010, at 6:00 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. >=20 >=20 > Title : IPsec Cluster Problem Statement > Author(s) : Y. Nir > Filename : draft-ietf-ipsecme-ipsec-ha-07.txt > Pages : 12 > Date : 2010-06-24 >=20 > This document defines terminology, problem statement and requirements > for implementing IKE and IPsec on clusters. It also describes gaps > in existing standards and their implementation that need to be > filled, in order to allow peers to interoperate with clusters from > different vendors. An agreed terminology, problem statement and > requirements will allow the IPSECME WG to consider development of > IPsec/IKEv2 mechanisms to simplify cluster implementations. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsec-ha-07.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From root@core3.amsl.com Fri Jun 25 09:30:04 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8C0553A6849; Fri, 25 Jun 2010 09:30:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100625163003.8C0553A6849@core3.amsl.com> Date: Fri, 25 Jun 2010 09:30:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-eap-mutual-05.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, 25 Jun 2010 16:30:04 -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 : An Extension for EAP-Only Authentication in IKEv2 Author(s) : P. Eronen, et al. Filename : draft-ietf-ipsecme-eap-mutual-05.txt Pages : 16 Date : 2010-06-25 IKEv2 specifies that EAP authentication must be used together with public key signature based responder authentication. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one-time passwords or token cards. This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. Note to RFC Editor: this document updates draft-ietf-ipsecme-ikev2bis, and therefore depends on that document. Please add "Updates: RFCxxxx" to the title page, where "xxxx" is the RFC number assigned to IKEv2-bis. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-eap-mutual-05.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-eap-mutual-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-25092323.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sat Jun 26 22:30:15 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 882C13A68DE; Sat, 26 Jun 2010 22:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100627053014.882C13A68DE@core3.amsl.com> Date: Sat, 26 Jun 2010 22:30:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-roadmap-07.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: Sun, 27 Jun 2010 05:30:15 -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 : IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap Author(s) : S. Frankel, S. Krishnan Filename : draft-ietf-ipsecme-roadmap-07.txt Pages : 64 Date : 2010-06-26 Over the past few years, the number of RFCs that define and use IPsec and IKE has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes the previous IPsec Document Roadmap [RFC2411]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-roadmap-07.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-roadmap-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-26222710.I-D@ietf.org> --NextPart-- From yaronf.ietf@gmail.com Sat Jun 26 23:38:49 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C05B43A684A for ; Sat, 26 Jun 2010 23:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 o4FeUCWrnvJO for ; Sat, 26 Jun 2010 23:38:48 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 8B02A3A6804 for ; Sat, 26 Jun 2010 23:38:48 -0700 (PDT) Received: by wye20 with SMTP id 20so3265247wye.31 for ; Sat, 26 Jun 2010 23:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=zLraX7L5Sddeiq5le6dGanXUtdtYh8HjmhJP/1jPYS8=; b=aapvBBwf/yhR/lGgolGlyCnjrXGovOQStbAJD82slwEY3hyQFpYMV/vcM9ntc22A6g JOWo7XN2IHjkWlYcZIDLMMyuxMZgfXCYUNnilM5u9aBIxzVY99O9Kl9LpKKqs4tq9VCB k9OS9UHPtKLME6yJPZSjEINaydGqqszyoh0Ro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=PzUtOu6+6C8A9f0iS6JgAKe5aOGaZVVkWeXIKUNxRrO4oPo5eJwsXnsbxDHYGrXst6 a0jCo1bgiDV517L3pQthnW/kYkA30kEYg1iTXGWDSBYuyKcupSqje09TbgOaGkg4UiCq Q3hV0CHtV+Zsu7alFwybe1KPi+sklRCQgq7kQ= Received: by 10.227.133.65 with SMTP id e1mr2391889wbt.76.1277620734030; Sat, 26 Jun 2010 23:38:54 -0700 (PDT) Received: from [10.0.0.1] (bzq-109-67-47-233.red.bezeqint.net [109.67.47.233]) by mx.google.com with ESMTPS id n31sm57376534wba.21.2010.06.26.23.38.49 (version=SSLv3 cipher=RC4-MD5); Sat, 26 Jun 2010 23:38:53 -0700 (PDT) Message-ID: <4C26F1F1.1080402@gmail.com> Date: Sun, 27 Jun 2010 09:38:41 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Roadmap -07: two minor and one major comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 06:38:49 -0000 5.2.4: [draft-ietf-ipsecme-aes-ctr-ikev2] is used as a reference, instead of [ipsecme-2]. 6.5 (rfc 4359 on using RSA with ESP/AH): if all of msec goes away, I don't see a reason to leave this one in. There's absolutely no reason to implement it other than multicast. Also, per my comment to -06, I still think that Appendix A (req levels for RFCs that are *not* algorithms) needs to go: - It mostly consists of empty space, "optional" and "N/A". - It adds normative weight to an informative document. - It is of little use to implementers. People will be reading the roadmap doc itself to decide what RFCs they need in their product, based on market needs. Thanks, Yaron From paul.hoffman@vpnc.org Sun Jun 27 09:26:30 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5794C3A6843 for ; Sun, 27 Jun 2010 09:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7BK27zpFepO for ; Sun, 27 Jun 2010 09:26:29 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id A34A13A6784 for ; Sun, 27 Jun 2010 09:26:29 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5RGQcNO014716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 27 Jun 2010 09:26:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sun, 27 Jun 2010 09:25:52 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Closing IPsecME work on PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 16:26:30 -0000 Greetings again. It does not seem like there are many people in the WG who want to work on the password-authenticated key exchange (PAKE) item in our charter. During the past few threads on PAKE, the only people who spoke out were authors of proposed PAKE protocols. Even after some prodding on my part, only one other WG participant spoke up, and that person even proposed another alternative. This work would take a fair amount of design work and review, yet few people are willing to do that particular work, and thus it seems unlikely that we could produce a high-quality PAKE extension. I have proposed to Sean Turner, our Area Director, that we instead simply drop the work from our charter, and he agreed. Of course, the authors of the various proposals that have been discussed are probably still interested in moving their proposals forwards. Sean has agreed to consider each of them as proposals to become Experimental RFCs. If some implementers adopt one or more of the proposals that become Experimental RFCs, the IETF might later move one or more to standards track. My personal hope is that one, and only one, PAKE for IKEv2 eventually makes it to standards track, but that is a consideration for the IETF in the future, not now. Yaron and I will follow up with Sean about updating our charter accordingly. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Sun Jun 27 17:38:45 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2133A6831 for ; Sun, 27 Jun 2010 17:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.681 X-Spam-Level: X-Spam-Status: No, score=0.681 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l44TwD7EauVF for ; Sun, 27 Jun 2010 17:38:44 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 0DBFA3A67D3 for ; Sun, 27 Jun 2010 17:38:43 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5S0cqtm037695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 27 Jun 2010 17:38:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C26F1F1.1080402@gmail.com> References: <4C26F1F1.1080402@gmail.com> Date: Sun, 27 Jun 2010 17:38:51 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Roadmap -07: two minor and one major comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 00:38:46 -0000 At 9:38 AM +0300 6/27/10, Yaron Sheffer wrote: >Also, per my comment to -06, I still think that Appendix A (req levels for RFCs that are *not* algorithms) needs to go: > >- It mostly consists of empty space, "optional" and "N/A". >- It adds normative weight to an informative document. >- It is of little use to implementers. People will be reading the roadmap doc itself to decide what RFCs they need in their product, based on market needs. Not wearing a hat, I also agree with Yaron about Appendix A. I don't see what an implementer is going to get from reading it. --Paul Hoffman, Director --VPN Consortium From root@core3.amsl.com Mon Jun 28 00:45:07 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 75F6C3A67D9; Mon, 28 Jun 2010 00:45:06 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100628074507.75F6C3A67D9@core3.amsl.com> Date: Mon, 28 Jun 2010 00:45:07 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ipsec-ha-08.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 07:45:07 -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 : IPsec Cluster Problem Statement Author(s) : Y. Nir Filename : draft-ietf-ipsecme-ipsec-ha-08.txt Pages : 12 Date : 2010-06-28 This document defines terminology, problem statement and requirements for implementing IKE and IPsec on clusters. It also describes gaps in existing standards and their implementation that need to be filled, in order to allow peers to interoperate with clusters from different vendors. An agreed terminology, problem statement and requirements will allow the IPSECME WG to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsec-ha-08.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-ipsec-ha-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-28003052.I-D@ietf.org> --NextPart-- From paul.hoffman@vpnc.org Mon Jun 28 06:57:35 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B613A6A5A for ; Mon, 28 Jun 2010 06:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.678 X-Spam-Level: X-Spam-Status: No, score=0.678 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1Z9gzAwzwqA for ; Mon, 28 Jun 2010 06:57:34 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1AA333A6A55 for ; Mon, 28 Jun 2010 06:57:34 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5SDvghb085382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Jun 2010 06:57:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 28 Jun 2010 06:57:39 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Starting discussion of failure detection proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 13:57:35 -0000 Greetings again. The WG has one item on our charter that we have barely discussed, namely failure detection. The charter item says that the work item is: >- A standards-track IKEv2 extension that allows an IKE peer to quickly and securely detect that its opposite peer, while currently reachable, has lost its IKEv2/IPsec state. Changes to how the peers recover from this situation are beyond the scope of this work item, as is improving the detection of an unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and draft-detienne-ikev2-recovery-03 can be used as starting points. I gave a brief presentation on failure detection at the last IETF meeting in Anaheim. The slides are at , and the following is directly derived from them. The basic problem being covered by the new extension is: - Alice and Bob have SAs up and ESP traffic is flowing, but then Bob crashes - Alice keeps sending ESP to Bob - When Bob finally comes back up, he replies to Alice's ESP with INVALID_SPI notifications - Alice starts sending IKE liveness checks until she is "sure" that the INVALID_SPI responses are not a DoS attack; this could be "several minutes" - Then Alice rekeys Some other problem cases include: - Bob has two gateways in some failover architecture. One gateway goes down, the other gateway detects this and wants to tell Alice to rekey - Bob has a bunch of gateways in some load-balancing or cluster architecture. One gateway is taken down on purpose, and the system wants to tell Alice to rekey - Protocol robustness: Bob's gateway loses the SA without going down Our primary goal is that, as soon as Bob starts sending INVALID_SPI responses to Alice's ESP traffic, Bob and Alice should be able to quickly determine that this is not an attack and therefore they probably want to rekey right away. Note that if Bob and Alice are also using session resumption, they can use that instead of rekeying; however, in the discussion here, we always use "rekey" to mean "rekey or, if appropriate, resume". The proposed extension does not include the actual rekeying, just the context for them to do it now. The WG has seen two proposed solutions, QCD and SIR. The following are brief summaries of the two proposals. In QCD (), Bob gives Alice a secret token in the AUTH exchange, and then puts the token in his INVALID_SPI response as a way to say "this SPI is gone". Bob must remember his tokens across reboots, or derive tokens from a master token that he memorizes across reboots, and Alice must remember the token (or a hash of it) for each SA. In SIR (), Alice sends a new Check_SPI query with a stateless cookie, essentially asking "do you really not know about this SPI?"; Bob responds by saying "I'm sure I don't know that SPI". Nothing is stored on either side, so a man-in-the-middle can attack this to cause an unnecessary rekey just as they can normal IKE. The first task for the WG is to decide which of these two quite different approaches to take. After we have done that, we can then hone the chosen proposal. During earlier discussion of the proposals, the following criteria were mentioned as ones that the WG should consider when thinking about the approaches: - Support for different scenarios (load balancers, active clusters, failover) - Security from man-in-the-middle DoS attacks - Resources used - Intellectual property rights So: please start discussing the two proposals with respect to these criteria or other criteria that are important to you. In a few weeks (hopefully well before the Maastricht meeting), I make a call for consensus and see where it leads us. --Paul Hoffman, Director --VPN Consortium From wwwrun@core3.amsl.com Mon Jun 28 08:00:01 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8C7723A68BA; Mon, 28 Jun 2010 08:00:01 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100628150001.8C7723A68BA@core3.amsl.com> Date: Mon, 28 Jun 2010 08:00:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] Last Call: draft-ietf-ipsecme-roadmap (IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 15:00:01 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-07-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-roadmap-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18086&rfc_flag=0 From wwwrun@core3.amsl.com Mon Jun 28 09:43:54 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 2E9F93A6A81; Mon, 28 Jun 2010 09:43:53 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100628164354.2E9F93A6A81@core3.amsl.com> Date: Mon, 28 Jun 2010 09:43:54 -0700 (PDT) Cc: ipsecme mailing list , ipsecme chair , Internet Architecture Board , RFC Editor Subject: [IPsec] Protocol Action: 'An Extension for EAP-Only Authentication in IKEv2' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 16:43:54 -0000 The IESG has approved the following document: - 'An Extension for EAP-Only Authentication in IKEv2 ' as a Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Sean Turner and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-eap-mutual-05.txt Technical Summary This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. Working Group Summary Nothing particular to note about WG discussions. It did receive an adequate amount of review. Document Quality One developer said they had implemented this experimentally and hand no problem. There are other developers who have expressed interest in implementing it in the future. Personnel Paul Hoffman (paul.hoffman@vpnc.org) is the Document Shepherd. Sean Turner (turners@ieca.com) is the Responsible Area Director. The IANA Expert for the registries in this document is Tero Kivinen (kivinen@iki.fi). From paul.hoffman@vpnc.org Mon Jun 28 11:34:01 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCCE53A693A for ; Mon, 28 Jun 2010 11:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.676 X-Spam-Level: X-Spam-Status: No, score=0.676 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfpgIoXMT3ZQ for ; Mon, 28 Jun 2010 11:33:59 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 91D2E3A6935 for ; Mon, 28 Jun 2010 11:33:58 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5SIY7dx005160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Jun 2010 11:34:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 28 Jun 2010 11:33:50 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Scheduling for Maastricht meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 18:34:01 -0000 Greetings again. For those of you planning your time at the upcoming IETF meeting in Masstricht, be aware that the IPsecME WG time slot was just moved from Tuesday morning to Monday morning. This IETF had many more meeting requests than normal, and the agenda can still change, so you should not make sub-week travel plans based on the agenda until probably July 15 (if even then). --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Mon Jun 28 13:31:45 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED273A697A for ; Mon, 28 Jun 2010 13:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.673 X-Spam-Level: X-Spam-Status: No, score=0.673 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxUMsly6ZFye for ; Mon, 28 Jun 2010 13:31:43 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id B5B1E3A69D5 for ; Mon, 28 Jun 2010 13:31:14 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5SKOJFq011481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Jun 2010 13:24:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 28 Jun 2010 13:24:18 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Proposed agenda for Maastricht X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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 Jun 2010 20:31:45 -0000 Greetings again. We currently have a 2.5 hour time slot for the IPsecME meeting, although that could change. Although the WG has not heard yet from the HA protocol design team, they should have first products well before the IETF meeting. Given that, I propose the following for an agenda. Bashing and blue - 5 min HA problem statement recap - 15 min HA protocol first round presentation - 30 min HA protocol discussion - 1 hr Rapid crash discovery selection - 30 min The time slots might shrink if we get moved again to a shorter time slot, or if there is not enough interest to discuss the topics. We can also add non-charter topics to the very end in case time permits; feel free to suggest such items here on the list. Please respond on the list if you want changes to the above. --Paul Hoffman, Director --VPN Consortium