From kivinen@iki.fi Fri Oct 1 02:17:22 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 D20AC3A6C3B for ; Fri, 1 Oct 2010 02:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MraCgXpmznhE for ; Fri, 1 Oct 2010 02:17:19 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 92CFC3A6C25 for ; Fri, 1 Oct 2010 02:17:18 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o919HvHa007004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Oct 2010 12:17:57 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o919HvE1029196; Fri, 1 Oct 2010 12:17:57 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19621.42821.206492.897684@fireball.kivinen.iki.fi> Date: Fri, 1 Oct 2010 12:17:57 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: IPsecme WG Subject: [IPsec] Issue #191 - The danger of predictable SPIs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 01 Oct 2010 09:17:22 -0000 Yoav Nir writes: > Alternatively it would simplify things immensely if we mandate that > SPIs be random for implementations that support QCD (possibly only > on the gateway side). Can we do it without having to "update RFC > 4306"? Yes I think we can do that, as this is requirement for only those hosts who support QCD. I.e. we can add text which says, that if you support QCD and enable it, then you MUST use random SPI for your IKE SA. There is no requirement for us to require random SPI for other hosts, so this do not break interoperability. > At least one IKEv2 implementation chooses IKE SPIs in a very > predictable manner. It starts with 0x0000000000001000 and increments > by one for each successive IKE SA. Assuming not too many SAs, and > QCD secrets not being replaced very often, it should be possible to > create a dictionary of SPI pairs to QCD tokens by simply sending the > likely pairs to the implementation, and getting the INVALID IKE SPI > notification along with the QCD token. Throttling and rate limiting > helps a little, but not if the pool of possible SPI pairs is small. I would expect such implementation will change their SPI generation code when they implement QCD. > Fortunately, to thwart this enumeration attack, it's enough for > either the token taker or token maker to do the right thing and use > random IKE SPIs. I suggest addressing the issue by requiring good > random IKE SPIs for token makers. Please send comments to the list. That makes sense, as the token maker is the one who wants protection against attackers guessing the tokens, so he wants to use random SPI. -- kivinen@iki.fi From yaronf.ietf@gmail.com Sat Oct 2 04:46: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 8C6DC3A6DDA for ; Sat, 2 Oct 2010 04:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgXuGIkAU0Su for ; Sat, 2 Oct 2010 04:46:33 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 693D53A6D66 for ; Sat, 2 Oct 2010 04:46:33 -0700 (PDT) Received: by fxm6 with SMTP id 6so3008709fxm.31 for ; Sat, 02 Oct 2010 04:47:23 -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=V/mQC6jo0/zNWSxElLqBZng0CyLWw6K02g+1xphe4sM=; b=CBDjwejlLO1j6hFUWTPPHlrYHcTD7L3dZDT99UDFCJlgeuvjSaNux/VAuDcNM3Q4I7 20m5Nn62UxjA2oSaZp94of8A+mLgC01U22IRXdAzKUd40L5qbbYfS14HRiQ8De8NJgwD xaLox0aiI1PD5J49aBQ0fMUs9ne2HNrFsBlBw= 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=PratK2WuM/4vzSRiWQCrVVOUW/gvdQmcl55YHPmq9qiwwZJB3a/mIxSmVHOSJGDRpE L1x6mv4zON7oZgpl9jN8EqUeiLWf5tgfEQok4d5QipDUGiopm7Brwpppsl5VKvCtpkC8 W/0hlDozvkXumWxCPmd89HQuRhDAU8vQvhgJM= Received: by 10.223.111.79 with SMTP id r15mr3789429fap.14.1286020042959; Sat, 02 Oct 2010 04:47:22 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-183-43-64.red.bezeqint.net [79.183.43.64]) by mx.google.com with ESMTPS id s20sm1157872faa.4.2010.10.02.04.47.20 (version=SSLv3 cipher=RC4-MD5); Sat, 02 Oct 2010 04:47:21 -0700 (PDT) Message-ID: <4CA71BC6.8090903@gmail.com> Date: Sat, 02 Oct 2010 13:47:18 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] IPsecME agenda for IETF-79 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 02 Oct 2010 11:46:34 -0000 Hi, below is the draft agenda. Most of the meeting will focus on technical discussion of the failure detection and the high availability work items. If you have anything else that you'd like to discuss at the meeting, please get in touch with Paul and myself. Thanks, Yaron --- Wed., 10 Nov. 2010, 13:00-15:00 at Garden Ballroom 1 13:00-13:10 Agenda bashing, administration, document status - Paul 13:10-13:40 Failure detection (presentation and discussion of open issues) - Yoav 13:40-14:30 High availability (presentation and discussion of open issues) - Raj 14:30-14:50 Reauthentication - Keith 14:50-15:00 IPsec-related work in other WGs and BOFs From martin@strongswan.org Tue Oct 5 05:41: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 D38E43A6E09 for ; Tue, 5 Oct 2010 05:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gf5GWAFfp9sH for ; Tue, 5 Oct 2010 05:41:30 -0700 (PDT) Received: from strongswan.org (sitav-80024.hsr.ch [152.96.80.24]) by core3.amsl.com (Postfix) with ESMTP id 736843A6C24 for ; Tue, 5 Oct 2010 05:41:29 -0700 (PDT) Received: from 224-92.105-92.cust.bluewin.ch ([92.105.92.224] helo=[192.168.1.36]) by strongswan.org with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1P36qa-0001hQ-W9; Tue, 05 Oct 2010 14:42:21 +0200 From: Martin Willi To: Keith Welter In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 05 Oct 2010 14:42:20 +0200 Message-ID: <1286282540.1778.133.camel@martin> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: IPsec@ietf.org Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 12:41:31 -0000 Hi Keith, > subject "[IPsec] Reauthentication extension for IKEv2" > certainly rough consensus was not reached. There was not much demand for such as an extension at this time. To sum it up, the two main arguments against such an extension were: 1. The current procedure is good enough / it's not worth the effort to define and implement an extension. 2. There is not really much demand for reauthentication at all > I would appreciate comments from the subscribers of this list as to > whether or not a reauthentication extension for IKEv2 is worth doing I still think the current reauthentication procedure is problematic, mainly because of the mentioned INTERNAL_ADDRESS and housekeeping issues. It is really hard to implement it properly in my opinion. I also see demand for reauthentication, for example with: - reauthenticating users periodically with a password based EAP methods - certificate based smartcard reauthentication, by reentering PIN - reauthenticating with renewed client certificates - periodic certificate revocation checking with inline OCSP, RFC4806 > of course I would also appreciate comments on the draft itself. I like the approach in your draft. It is relatively lightweight, but should give enough flexibility in conjunction with repeated authentication (RFC4478). I would at least mention RFC4478 to show how each party can trigger the reauthentication procedure. One problem that is currently not addressed is the handling of INTERNAL_ADDRESS or other configuration attributes. This is rather important, as the CHILD_SAs to inherit usually have traffic selectors derived from the INTERNAL_ADDRESS. We could either: - silently inherit these attributes along with the CHILD_SAs, as it is done during IKE_SA rekeying, or - re-enroll the attributes in the given reauthentication context I'd tend to the second option, as the first gets a little complicated if the responder does not support REAUTH_SA. Best regards Martin From ynir@checkpoint.com Tue Oct 5 07:32:41 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 2E2CC3A6F75 for ; Tue, 5 Oct 2010 07:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pTl0PZdmB+4 for ; Tue, 5 Oct 2010 07:32:39 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 191E23A6F7B for ; Tue, 5 Oct 2010 07:32:38 -0700 (PDT) X-CheckPoint: {4CAB3631-10002-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o95EXZTZ007610; Tue, 5 Oct 2010 16:33:35 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 5 Oct 2010 16:33:35 +0200 From: Yoav Nir To: Keith Welter Date: Tue, 5 Oct 2010 16:33:33 +0200 Thread-Topic: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 Thread-Index: Actkmkpt3qMBkXdxRrGnVWm8Bm2dcQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 14:32:41 -0000 Hi Keith. After reading your draft, I wish I had done this in RFC 4478. Still, I have= some comments. What are the considerations for the responder accepting a re-authentication= ? Suppose we have an active IKE SA between Alice and Bob. Now Bob gets a new= IKE_SA_INIT request with an N(REAUTH_SA) and the IKE SPIs for the old IKE = SA. When should Bob accept? When should Bob decline? What if later (in the= IKE_AUTH exchange) the authenticated identity turns out to be Mallory? The way the draft is now, anyone can probe for the existence of IKE SPIs by= sending IKE_SA_INIT requests with arbitrary IKE SPIs in the REAUTH_SA noti= fication. This is not a particularly useful attack, but no need to expose o= urselves to it. I think it would be better to move the notifications to the= IKE_AUTH exchange. Once there, the intuitive logic would be: - If the peer authenticates as other than Alice, deny REAUTH (fail the exc= hange?) - If authentication fails, ignore it. The old IKE SA remains alive. - If the peer authenticates as Alice, allow the reauth. This leads me to another issue. If the peer authenticates as Alice, we can = treat it as an "Alice". Is it OK for "an Alice" to inherit the child SAs of= any other "Alice"? Ideally, there is only one "Alice" and if the peer aut= henticates as "Alice" it may inherit any child SAs belonging to any IKE SA = belonging to "Alice", but I think it would be better to somehow tie the old= SA to the new SA with non-public information. Perhaps something derived fr= om the SKEYSEED along with SK_d and the rest. One final issue. The IKE_AUTH exchange in your draft does not include what'= s needed for creating new Child SAs. This is not allowed by RFC 5996. There= is, however, a soon-to-be-published RFC for this (draft-nir-ipsecme-childl= ess) Yoav On Sep 28, 2010, at 10:03 PM, Keith Welter wrote: >=20 > A new version of I-D, draft-welter-ipsecme-ikev2-reauth-00.txt has been s= uccessfully submitted by Keith Welter and posted to the IETF repository. >=20 > Filename: draft-welter-ipsecme-ikev2-reauth > Revision: 00 > Title: Reauthentication Extension for I= KEv2 > Creation_date: 2010-09-28 > WG ID: Independent Submission > Number_of_pages: 10 >=20 > Abstract: > This document extends the Internet Key Exchange (IKEv2) Protocol > document [IKEv2]. IKEv2 reauthentication does not scale well when an > IKE SA has multiple Child SAs because each Child SA of the IKE SA to > be reauthenticated must be renegotiated. In addition, > reauthentication is susceptible to the same kinds of exchange > collisions as those that may occur during rekeying. This document > describes a mechanism to detect reauthentication and avoid > renegotiating the Child SAs. In addition, this document describes > proper handling of exchange collisions that may occur during > reauthentication. > = =20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 > From yaronf.ietf@gmail.com Tue Oct 5 10:47:27 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 9C5FF3A6FD0 for ; Tue, 5 Oct 2010 10:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYNvvt7fH6eF for ; Tue, 5 Oct 2010 10:47:26 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id EF4613A6FF5 for ; Tue, 5 Oct 2010 10:47:25 -0700 (PDT) Received: by bwz9 with SMTP id 9so6115951bwz.31 for ; Tue, 05 Oct 2010 10:48:23 -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=byNQVRvhuWekbj4wqNlDDOCksWBCNal1TTeZr1roOGc=; b=pvraIwWxJGIBUj1Y+k79LpLUFIrky5v46u8uDScXYJrPQE43gpRNrOkRvxm97KV9X7 hSyivmpYGIuvHwOQpL7qbRn271RQZAOtYXwsQy2u46Ijh+UfjUNHi7s/2sze9XXPWQWM gekt6xX4tJ/AjZMLOFrn0dKs9VYnLCfS8PNks= 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=xz6GeVgZhoEWeBHsg1J/I+xHKQPpThWEsx66dI9nB7dBwJ+7kZ/ExJo7MQyP5Vd2rs +WlKuZ/LrgfMmER1yXzlxG447y8DH79OtWI33ApgCXlby+wcHy66tWlRbwhdlavqAGkd wtFt3oaK2DCMQrzuFNVGuiTCuhMxQdA36WHr0= Received: by 10.204.54.68 with SMTP id p4mr8636947bkg.184.1286300903422; Tue, 05 Oct 2010 10:48:23 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-181-39-14.red.bezeqint.net [79.181.39.14]) by mx.google.com with ESMTPS id y2sm5137934bkx.8.2010.10.05.10.48.17 (version=SSLv3 cipher=RC4-MD5); Tue, 05 Oct 2010 10:48:21 -0700 (PDT) Message-ID: <4CAB64DD.5050803@gmail.com> Date: Tue, 05 Oct 2010 19:48:13 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: Yoav Nir References: In-Reply-To: Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:47:27 -0000 Hi Yoav, you are discussing two separate issues related to identity: the "alleged identity" (the name presented as IDi and/or authenticated by the IKE_AUTH exchange) and the ability to correlate the two SAs using some secret information. I think we should be flexible about the alleged identity. If Alice has had a medical operation and is now Alistair, your policy might still allow him to reuse the old SA. Some EAP methods support anonymity and pseudonymity, and I don't think we want to force them to employ stable identities. But this implies that we need something else to ensure continuity of the identity, and mixing the old SK_d into the new authentication certainly makes sense. Thanks, Yaron On 10/05/2010 04:33 PM, Yoav Nir wrote: > Hi Keith. > > After reading your draft, I wish I had done this in RFC 4478. Still, I have some comments. > > What are the considerations for the responder accepting a re-authentication? > > Suppose we have an active IKE SA between Alice and Bob. Now Bob gets a new IKE_SA_INIT request with an N(REAUTH_SA) and the IKE SPIs for the old IKE SA. When should Bob accept? When should Bob decline? What if later (in the IKE_AUTH exchange) the authenticated identity turns out to be Mallory? > > The way the draft is now, anyone can probe for the existence of IKE SPIs by sending IKE_SA_INIT requests with arbitrary IKE SPIs in the REAUTH_SA notification. This is not a particularly useful attack, but no need to expose ourselves to it. I think it would be better to move the notifications to the IKE_AUTH exchange. Once there, the intuitive logic would be: > - If the peer authenticates as other than Alice, deny REAUTH (fail the exchange?) > - If authentication fails, ignore it. The old IKE SA remains alive. > - If the peer authenticates as Alice, allow the reauth. > > This leads me to another issue. If the peer authenticates as Alice, we can treat it as an "Alice". Is it OK for "an Alice" to inherit the child SAs of any other "Alice"? Ideally, there is only one "Alice" and if the peer authenticates as "Alice" it may inherit any child SAs belonging to any IKE SA belonging to "Alice", but I think it would be better to somehow tie the old SA to the new SA with non-public information. Perhaps something derived from the SKEYSEED along with SK_d and the rest. > > One final issue. The IKE_AUTH exchange in your draft does not include what's needed for creating new Child SAs. This is not allowed by RFC 5996. There is, however, a soon-to-be-published RFC for this (draft-nir-ipsecme-childless) > > Yoav > > On Sep 28, 2010, at 10:03 PM, Keith Welter wrote: > >> >> A new version of I-D, draft-welter-ipsecme-ikev2-reauth-00.txt has been successfully submitted by Keith Welter and posted to the IETF repository. >> >> Filename: draft-welter-ipsecme-ikev2-reauth >> Revision: 00 >> Title: Reauthentication Extension for IKEv2 >> Creation_date: 2010-09-28 >> WG ID: Independent Submission >> Number_of_pages: 10 >> >> Abstract: >> This document extends the Internet Key Exchange (IKEv2) Protocol >> document [IKEv2]. IKEv2 reauthentication does not scale well when an >> IKE SA has multiple Child SAs because each Child SA of the IKE SA to >> be reauthenticated must be renegotiated. In addition, >> reauthentication is susceptible to the same kinds of exchange >> collisions as those that may occur during rekeying. This document >> describes a mechanism to detect reauthentication and avoid >> renegotiating the Child SAs. In addition, this document describes >> proper handling of exchange collisions that may occur during >> reauthentication. >> >> >> >> The IETF Secretariat. >> >> >> >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Tue Oct 5 11:46: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 5E1233A70BA for ; Tue, 5 Oct 2010 11:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 YSjPhNotsIos for ; Tue, 5 Oct 2010 11:46:56 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id BB5C63A6FDC for ; Tue, 5 Oct 2010 11:46:55 -0700 (PDT) X-CheckPoint: {4CAB71C9-10000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o95Ilpso017642; Tue, 5 Oct 2010 20:47:51 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 5 Oct 2010 20:47:51 +0200 From: Yoav Nir To: Yaron Sheffer Date: Tue, 5 Oct 2010 20:47:50 +0200 Thread-Topic: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 Thread-Index: ActkvdAE0RyXTKLbQRePGrZPGGKhKA== Message-ID: References: <4CAB64DD.5050803@gmail.com> In-Reply-To: <4CAB64DD.5050803@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 18:46:57 -0000 On Oct 5, 2010, at 7:48 PM, Yaron Sheffer wrote: > Hi Yoav, >=20 > you are discussing two separate issues related to identity: the "alleged= =20 > identity" (the name presented as IDi and/or authenticated by the=20 > IKE_AUTH exchange) and the ability to correlate the two SAs using some=20 > secret information. >=20 > I think we should be flexible about the alleged identity. If Alice has=20 > had a medical operation and is now Alistair, your policy might still=20 > allow him to reuse the old SA. Some EAP methods support anonymity and=20 > pseudonymity, and I don't think we want to force them to employ stable=20 > identities. All the more reason to have set rules on when a new IKE SA can inherit. >=20 > But this implies that we need something else to ensure continuity of the= =20 > identity, and mixing the old SK_d into the new authentication certainly=20 > makes sense. >=20 > Thanks, > Yaron >=20 > On 10/05/2010 04:33 PM, Yoav Nir wrote: >> Hi Keith. >>=20 >> After reading your draft, I wish I had done this in RFC 4478. Still, I h= ave some comments. >>=20 >> What are the considerations for the responder accepting a re-authenticat= ion? >>=20 >> Suppose we have an active IKE SA between Alice and Bob. Now Bob gets a = new IKE_SA_INIT request with an N(REAUTH_SA) and the IKE SPIs for the old I= KE SA. When should Bob accept? When should Bob decline? What if later (in = the IKE_AUTH exchange) the authenticated identity turns out to be Mallory? >>=20 >> The way the draft is now, anyone can probe for the existence of IKE SPIs= by sending IKE_SA_INIT requests with arbitrary IKE SPIs in the REAUTH_SA n= otification. This is not a particularly useful attack, but no need to expos= e ourselves to it. I think it would be better to move the notifications to = the IKE_AUTH exchange. Once there, the intuitive logic would be: >> - If the peer authenticates as other than Alice, deny REAUTH (fail the = exchange?) >> - If authentication fails, ignore it. The old IKE SA remains alive. >> - If the peer authenticates as Alice, allow the reauth. >>=20 >> This leads me to another issue. If the peer authenticates as Alice, we c= an treat it as an "Alice". Is it OK for "an Alice" to inherit the child SAs= of any other "Alice"? Ideally, there is only one "Alice" and if the peer = authenticates as "Alice" it may inherit any child SAs belonging to any IKE = SA belonging to "Alice", but I think it would be better to somehow tie the = old SA to the new SA with non-public information. Perhaps something derived= from the SKEYSEED along with SK_d and the rest. >>=20 >> One final issue. The IKE_AUTH exchange in your draft does not include wh= at's needed for creating new Child SAs. This is not allowed by RFC 5996. Th= ere is, however, a soon-to-be-published RFC for this (draft-nir-ipsecme-chi= ldless) >>=20 >> Yoav >>=20 >> On Sep 28, 2010, at 10:03 PM, Keith Welter wrote: >>=20 >>>=20 >>> A new version of I-D, draft-welter-ipsecme-ikev2-reauth-00.txt has been= successfully submitted by Keith Welter and posted to the IETF repository. >>>=20 >>> Filename: draft-welter-ipsecme-ikev2-reauth >>> Revision: 00 >>> Title: Reauthentication Extension for= IKEv2 >>> Creation_date: 2010-09-28 >>> WG ID: Independent Submission >>> Number_of_pages: 10 >>>=20 >>> Abstract: >>> This document extends the Internet Key Exchange (IKEv2) Protocol >>> document [IKEv2]. IKEv2 reauthentication does not scale well when an >>> IKE SA has multiple Child SAs because each Child SA of the IKE SA to >>> be reauthenticated must be renegotiated. In addition, >>> reauthentication is susceptible to the same kinds of exchange >>> collisions as those that may occur during rekeying. This document >>> describes a mechanism to detect reauthentication and avoid >>> renegotiating the Child SAs. In addition, this document describes >>> proper handling of exchange collisions that may occur during >>> reauthentication. >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat. >>>=20 >>>=20 >>>=20 >>> >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From kivinen@iki.fi Wed Oct 6 06:39:38 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 105E83A6E6D for ; Wed, 6 Oct 2010 06:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.577 X-Spam-Level: X-Spam-Status: No, score=-101.577 tagged_above=-999 required=5 tests=[AWL=-0.837, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq4lWIBV3p6h for ; Wed, 6 Oct 2010 06:39:36 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 376723A6F5B for ; Wed, 6 Oct 2010 06:39:35 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o96DeWd0029328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Oct 2010 16:40:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o96DeVsk004552; Wed, 6 Oct 2010 16:40:31 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19628.31823.7854.335670@fireball.kivinen.iki.fi> Date: Wed, 6 Oct 2010 16:40:31 +0300 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <19591.24647.497524.822377@fireball.kivinen.iki.fi> <19591.32575.931479.621032@fireball.kivinen.iki.fi> <19592.37973.545808.950166@fireball.kivinen.iki.fi> <19594.16591.378433.920474@fireball.kivinen.iki.fi> <4C8C95E9.5080801@gmail.com> <19600.33044.946153.563329@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 26 min X-Total-Time: 52 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Comments to draft-ietf-ipsecme-failure-detection-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 13:39:38 -0000 David Wierbowski writes: > Tero writes: > >David Wierbowski writes: > >> Tero writes: > >> >I do not consider very open protocols which allow all kind of things > >> >"just for fun" and "in case we someday get scenario which can use it" > >> >as good thing. > >> > >> I do not think we are allowing the initiator and responder to > >> be both a taker and a maker just for fun. There are cases where > >> either side can initiate and it makes sense in those cases. > > > >Can you give example of such setup, preferrable something that I have > >not already covered in my previous emails and explained why QCD is not > >needed there. > > Consider a business partner relationship where data exchanged between > the partners are protected by IPsec. In these environments it is often > common for either end to initiate a negotiation and for either end to > initiate sending data. For example perhaps they share a process > management system or order fulfillment system. One end might initiate > a connection to submit an request/order. Days later the other end might > initiate a connection to indicate the fulfillment of the request/order. > There truly envirnoments that do and can initiate from either end. Yes, and as both ends might initiate connection there is no need for QCD, as if one end wants to submit request/order and sends packet to the other end it notices there is no IKE SA and creates one. If connection breaks down in the middle of the exchange then the end which did not crash will notice that traffic is unidirectional and take corrective actions (i.e. start DPD, and then tear down IKE SA and start to try to create new IKE SA even before the other end has recovered from the crash). > > The ability to initiate an IKE_SA is not the only case where allowing > both endpoint be takers and makers is applicable. Consider the > following: > > Host (responder) <======> GW (initiator) <-------> Client > > The Client is connecting to the Host. The GW chooses to initiate a > single SA per client behind the GW. The Client's connection has data > streaming in from the host -- perhaps the Client is downloading a > significant database replication update. The GW oes down. The Client > connection is still viable. If the GW goes down and I am the host I do > not want to depend on the GW being smart enough to receive my ESP packet > and negotiate a new tunnel, especially when QCD might let me (the host) > initiate a new tunnel. It really does not matter if the Host could have > done this initial negotiation. It just to be able to reconstitute the SA. As the host is sending traffic it will immediately notice when it is not getting ACKs back from the GW, i.e. when the traffic gets unidirectional, and again it can start fixing situation at that point. Note, also that in most cases the Client will also send something when it does not get any more traffic, and when it sends a single packet the GW will immediately recreate the IKE SA and Child SAs. > It seems unlikely to me that every GW behaves as Tero suggests here. > In case that do not behave as Tero suggest QCD will allow me to > drive a faster recovery. That behavior is described in the RFC4306 and now in RFC5996: If there has only been outgoing traffic on all of the SAs associated with an IKE SA, it is essential to confirm liveness of the other endpoint to avoid black holes. Also as I said if the client sends any packets (TCP acks or similar) then GW will immediately recreate the IKE SA with Host again. > I think allowing both the initiator and responder to be token makers > actually keeps the protocol simpler. Clearly we are in disagreement about that. I think it makes protocol more complex, and adds lots of test cases that needs to be separately tested. > From an implementation perspective I'd prefer to take advantage of > QCD as a rather than rely on the fact that every gateway behaves as > Tero suggests. You do not need to rely it. If the GW or Host implementations are bad (or broken), then there might be longer delays in recovering. Everything still works. If you are making implementation then it is better to make good implementation that follows the RFC 5996 and which can start liveness checks when necessarely (and not do stupid things like doing them every 30 seconds), and use the hints from the network to shorten those timers. That good implementation will work well also with implementations which do not support QCD at all (i.e. all existing implementations). > >Yes it is not authenticated, but you do have limited number of > >configured IP-addresses in your configuration file, which means that > >attacker can only set up IKE SA for exactly those hosts, not any > >other, and as you only create the IKE SA if you do not have any, then > >only thing attacker can cause is you to create the IKE SA even when > >you do not yet have traffic to go that way. > > I'm not so sure that having a limited number of configured IP addresses in > the configuration file equates to having a small number of address. It is > also likely that one could easily determine the range of valid addresses. Matching against range or mathing against single IP-address is trivial. On the other hand usually you need per IP-address shared key, or other policy information anyways, thus your VPN style point-to-point configuration usually has fixed entries for each GW. Note, that VPN GW configuration for VPN client (road warriors) is different (it usually uses wildcards), but this question is not about those configurations, as in those setups the VPN GW cannot create connection to the VPN client, as it does not know in which IP-address the VPN client is at given time. We were talking here about the situation where both ends can initiate connections any time. > >As I said, in our case we do check our configuration and if the > >invalid ESP packet has IP-address which matches a known peer in the > >configuration file, our implementation do set up the IKE SA for the > >peer and do send Child SA delete for the ESP SPI to clean up the > >state. > > But how do you authenticate that address? Are you saying that if I > find an addresses in your config file that I can sit there all day > sending you bogus ESP packets and watch you initiate IKE_SAs? I must > be missing something here. Yes. You can send our GW bogus ESP packet (or you actually might need few depending on other things), which will couse us to initiate IKE_SA to the configured host in our configuration. Then the IKE SA is up and running, and we do not recreate it even if you send more ESP packets. Usually site to site vpn sessions are set up to be autostarted anyways, so those IKE SAs are created on the boot time, thus sending bogus ESP packets do not do anything (or more accurately they can generate delete message to be send using existing IKE SA to the other end, which the other end will audit when it gets delete message for unknown ESP, but those messages are rate limited). -- kivinen@iki.fi From smoonen@us.ibm.com Wed Oct 6 06:53: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 399B93A6EBC; Wed, 6 Oct 2010 06:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.489 X-Spam-Level: X-Spam-Status: No, score=-4.489 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 1q9UOhY7BjtV; Wed, 6 Oct 2010 06:53:04 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id 611493A6E6D; Wed, 6 Oct 2010 06:53:04 -0700 (PDT) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e31.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o96DfVHW009908; Wed, 6 Oct 2010 07:41:31 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o96Ds3XG139612; Wed, 6 Oct 2010 07:54:03 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o96Ds2hZ023023; Wed, 6 Oct 2010 07:54:02 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o96Ds2l3022890; Wed, 6 Oct 2010 07:54:02 -0600 In-Reply-To: <19628.31823.7854.335670@fireball.kivinen.iki.fi> References: <19591.24647.497524.822377@fireball.kivinen.iki.fi> <19591.32575.931479.621032@fireball.kivinen.iki.fi> <19592.37973.545808.950166@fireball.kivinen.iki.fi> <19594.16591.378433.920474@fireball.kivinen.iki.fi> <4C8C95E9.5080801@gmail.com> <19600.33044.946153.563329@fireball.kivinen.iki.fi> <19628.31823.7854.335670@fireball.kivinen.iki.fi> X-KeepSent: 5E9983E8:4D23E20D-852577B4:004BA26D; type=4; name=$KeepSent To: Tero Kivinen X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: Scott C Moonen Date: Wed, 6 Oct 2010 09:53:51 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 10/06/2010 07:54:02 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBFD27DFD824FD8f9e8a93df938690918c0ABBFD27DFD824FD" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, David Wierbowski Subject: Re: [IPsec] Comments to draft-ietf-ipsecme-failure-detection-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 13:53:07 -0000 --0__=0ABBFD27DFD824FD8f9e8a93df938690918c0ABBFD27DFD824FD Content-type: multipart/alternative; Boundary="1__=0ABBFD27DFD824FD8f9e8a93df938690918c0ABBFD27DFD824FD" --1__=0ABBFD27DFD824FD8f9e8a93df938690918c0ABBFD27DFD824FD Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable > > The ability to initiate an IKE_SA is not the only case where allowi= ng > > both endpoint be takers and makers is applicable. Consider the > > following: > > > > Host (responder) <=3D=3D=3D=3D=3D=3D> GW (initiator) <-------> Clie= nt > > > > The Client is connecting to the Host. The GW chooses to initiate a= > > single SA per client behind the GW. The Client's connection has da= ta > > streaming in from the host -- perhaps the Client is downloading a > > significant database replication update. The GW oes down. The Cli= ent > > connection is still viable. If the GW goes down and I am the host = I do > > not want to depend on the GW being smart enough to receive my ESP packet > > and negotiate a new tunnel, especially when QCD might let me (the h= ost) > > initiate a new tunnel. It really does not matter if the Host could= have > > done this initial negotiation. It just to be able to reconstitute = the SA. > > As the host is sending traffic it will immediately notice when it is > not getting ACKs back from the GW, i.e. when the traffic gets > unidirectional, and again it can start fixing situation at that > point. But Tero, that process can take several minutes. First the host initia= tes a liveness exchange, then after a minute or two of retransmissions it t= imes out, then starts to negotiate a new IKE SA. By that time the TCP connection has timed out. This is *exactly* the problem that QCD is designed to fix, and if I am the host here I definitely want to take advantage of QCD in this situation rather than lose my TCP connection. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Tero Kivinen To: David Wierbowski/Endicott/IBM@IBMUS Cc: ipsec@ietf.org Date: 10/06/2010 09:40 AM Subject: Re: [IPsec] Comments to draft-ietf-ipsecme-failure-detection-0= 0 Sent by: ipsec-bounces@ietf.org David Wierbowski writes: > Tero writes: > >David Wierbowski writes: > >> Tero writes: > >> >I do not consider very open protocols which allow all kind of thi= ngs > >> >"just for fun" and "in case we someday get scenario which can use= it" > >> >as good thing. > >> > >> I do not think we are allowing the initiator and responder to > >> be both a taker and a maker just for fun. There are cases where > >> either side can initiate and it makes sense in those cases. > > > >Can you give example of such setup, preferrable something that I hav= e > >not already covered in my previous emails and explained why QCD is n= ot > >needed there. > > Consider a business partner relationship where data exchanged between= > the partners are protected by IPsec. In these environments it is oft= en > common for either end to initiate a negotiation and for either end to= > initiate sending data. For example perhaps they share a process > management system or order fulfillment system. One end might initiat= e > a connection to submit an request/order. Days later the other end mi= ght > initiate a connection to indicate the fulfillment of the request/orde= r. > There truly envirnoments that do and can initiate from either end. Yes, and as both ends might initiate connection there is no need for QCD, as if one end wants to submit request/order and sends packet to the other end it notices there is no IKE SA and creates one. If connection breaks down in the middle of the exchange then the end which did not crash will notice that traffic is unidirectional and take corrective actions (i.e. start DPD, and then tear down IKE SA and start to try to create new IKE SA even before the other end has recovered from the crash). > > The ability to initiate an IKE_SA is not the only case where allowing= > both endpoint be takers and makers is applicable. Consider the > following: > > Host (responder) <=3D=3D=3D=3D=3D=3D> GW (initiator) <-------> Client= > > The Client is connecting to the Host. The GW chooses to initiate a > single SA per client behind the GW. The Client's connection has data= > streaming in from the host -- perhaps the Client is downloading a > significant database replication update. The GW oes down. The Clien= t > connection is still viable. If the GW goes down and I am the host I = do > not want to depend on the GW being smart enough to receive my ESP pac= ket > and negotiate a new tunnel, especially when QCD might let me (the hos= t) > initiate a new tunnel. It really does not matter if the Host could h= ave > done this initial negotiation. It just to be able to reconstitute th= e SA. As the host is sending traffic it will immediately notice when it is not getting ACKs back from the GW, i.e. when the traffic gets unidirectional, and again it can start fixing situation at that point. Note, also that in most cases the Client will also send something when it does not get any more traffic, and when it sends a single packet the GW will immediately recreate the IKE SA and Child SAs. > It seems unlikely to me that every GW behaves as Tero suggests here. > In case that do not behave as Tero suggest QCD will allow me to > drive a faster recovery. That behavior is described in the RFC4306 and now in RFC5996: If there has only been outgoing traffic on all of the SAs associated with an IKE SA, it is essential to confirm liveness of the other endpoint to avoid black holes. Also as I said if the client sends any packets (TCP acks or similar) then GW will immediately recreate the IKE SA with Host again. > I think allowing both the initiator and responder to be token makers > actually keeps the protocol simpler. Clearly we are in disagreement about that. I think it makes protocol more complex, and adds lots of test cases that needs to be separately tested. > From an implementation perspective I'd prefer to take advantage of > QCD as a rather than rely on the fact that every gateway behaves as > Tero suggests. You do not need to rely it. If the GW or Host implementations are bad (or broken), then there might be longer delays in recovering. Everything still works. If you are making implementation then it is better to make good implementation that follows the RFC 5996 and which can start liveness checks when necessarely (and not do stupid things like doing them every 30 seconds), and use the hints from the network to shorten those timers. That good implementation will work well also with implementations which do not support QCD at all (i.e. all existing implementations). > >Yes it is not authenticated, but you do have limited number of > >configured IP-addresses in your configuration file, which means that= > >attacker can only set up IKE SA for exactly those hosts, not any > >other, and as you only create the IKE SA if you do not have any, the= n > >only thing attacker can cause is you to create the IKE SA even when > >you do not yet have traffic to go that way. > > I'm not so sure that having a limited number of configured IP address= es in > the configuration file equates to having a small number of address. = It is > also likely that one could easily determine the range of valid addres= ses. Matching against range or mathing against single IP-address is trivial. On the other hand usually you need per IP-address shared key, or other policy information anyways, thus your VPN style point-to-point configuration usually has fixed entries for each GW. Note, that VPN GW configuration for VPN client (road warriors) is different (it usually uses wildcards), but this question is not about those configurations, as in those setups the VPN GW cannot create connection to the VPN client, as it does not know in which IP-address the VPN client is at given time. We were talking here about the situation where both ends can initiate connections any time. > >As I said, in our case we do check our configuration and if the > >invalid ESP packet has IP-address which matches a known peer in the > >configuration file, our implementation do set up the IKE SA for the > >peer and do send Child SA delete for the ESP SPI to clean up the > >state. > > But how do you authenticate that address? Are you saying that if I > find an addresses in your config file that I can sit there all day > sending you bogus ESP packets and watch you initiate IKE_SAs? I must= > be missing something here. Yes. You can send our GW bogus ESP packet (or you actually might need few depending on other things), which will couse us to initiate IKE_SA to the configured host in our configuration. Then the IKE SA is up and running, and we do not recreate it even if you send more ESP packets. Usually site to site vpn sessions are set up to be autostarted anyways, so those IKE SAs are created on the boot time, thus sending bogus ESP packets do not do anything (or more accurately they can generate delete message to be send using existing IKE SA to the other end, which the other end will audit when it gets delete message for unknown ESP, but those messages are rate limited). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBFD27DFD824FD8f9e8a93df938690918c0ABBFD27DFD824FD Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

> > The ability to initiate an IKE_SA is not the only case= where allowing
> > both endpoint be takers and makers is applicable.  Consi= der the
> > following:
> >
> > Host (responder) <=3D=3D=3D=3D=3D=3D> GW (initiator) &l= t;-------> Client
> >
> > The Client is connecting to the Host.  The GW chooses to= initiate a
> > single SA per client behind the GW.  The Client's connec= tion has data
> > streaming in from the host -- perhaps the Client is downloadi= ng a
> > significant database replication update.  The GW oes dow= n.  The Client
> > connection is still viable.  If the GW goes down and I a= m the host I do
> > not want to depend on the GW being smart enough to receive my= ESP packet
> > and negotiate a new tunnel, especially when QCD might let me = (the host)
> > initiate a new tunnel.  It really does not matter if the= Host could have
> > done this initial negotiation.  It just to be able to re= constitute the SA.
>
> As the host is sending traffic it will immediately notice when it = is
> not getting ACKs back from the GW, i.e. when the traffic gets
> unidirectional, and again it can start fixing situation at that > point.

But Tero, that process can take several minutes. First the host initia= tes a liveness exchange, then after a minute or two of retransmissions = it times out, then starts to negotiate a new IKE SA. By that time the = TCP connection has timed out. This is *exactly* the problem that QCD i= s designed to fix, and if I am the host here I definitely want to take = advantage of QCD in this situation rather than lose my TCP connection.<= br>

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

3D"InactiveTero Kivinen ---10/06/2010 09:40:52 AM= ---David Wierbowski writes: > Tero writes:

From: Tero K= ivinen <kivinen@iki.fi>
To: David Wi= erbowski/Endicott/IBM@IBMUS
Cc: ipsec@ie= tf.org
Date: 10/06/= 2010 09:40 AM
Subject: Re:= [IPsec] Comments to draft-ietf-ipsecme-failure-detection-00
= Sent by: ips= ec-bounces@ietf.org




David Wierbowski writes:
> Tero writes:
> >David Wierbowski writes:
> >> Tero writes:
> >> >I do not consider very open protocols which allow all= kind of things
> >> >"just for fun" and "in case we someday= get scenario which can use it"
> >> >as good thing.
> >>
> >> I do not think we are allowing the initiator and responde= r to
> >> be both a taker and a maker just for fun.  There are= cases where
> >> either side can initiate and it makes sense in those case= s.
> >
> >Can you give example of such setup, preferrable something that= I have
> >not already covered in my previous emails and explained why QC= D is not
> >needed there.
>
> Consider a business partner relationship where data exchanged betw= een
> the partners are protected by IPsec.  In these environments i= t is often
> common for either end to initiate a negotiation and for either end= to
> initiate sending data.  For example perhaps they share a proc= ess
> management system or order fulfillment system.  One end might= initiate
> a connection to submit an request/order.  Days later the othe= r end might
> initiate a connection to indicate the fulfillment of the request/o= rder.
> There truly envirnoments that do and can initiate from either end.=

Yes, and as both ends might initiate connection there is no need for QCD, as if one end wants to submit request/order and sends packet to the other end it notices there is no IKE SA and creates one. If
connection breaks down in the middle of the exchange then the end
which did not crash will notice that traffic is unidirectional and
take corrective actions (i.e. start DPD, and then tear down IKE SA and<= br> start to try to create new IKE SA even before the other end has
recovered from the crash).

>
> The ability to initiate an IKE_SA is not the only case where allow= ing
> both endpoint be takers and makers is applicable.  Consider t= he
> following:
>
> Host (responder) <=3D=3D=3D=3D=3D=3D> GW (initiator) <---= ----> Client
>
> The Client is connecting to the Host.  The GW chooses to init= iate a
> single SA per client behind the GW.  The Client's connection = has data
> streaming in from the host -- perhaps the Client is downloading a<= br> > significant database replication update.  The GW oes down. &n= bsp;The Client
> connection is still viable.  If the GW goes down and I am the= host I do
> not want to depend on the GW being smart enough to receive my ESP = packet
> and negotiate a new tunnel, especially when QCD might let me (the = host)
> initiate a new tunnel.  It really does not matter if the Host= could have
> done this initial negotiation.  It just to be able to reconst= itute the SA.

As the host is sending traffic it will immediately notice when it is not getting ACKs back from the GW, i.e. when the traffic gets
unidirectional, and again it can start fixing situation at that
point.

Note, also that in most cases the Client will also send something when<= br> it does not get any more traffic, and when it sends a single packet
= the GW will immediately recreate the IKE SA and Child SAs.

> It seems unlikely to me that every GW behaves as Tero suggests her= e.
> In case that do not behave as Tero suggest QCD will allow me to > drive a faster recovery.

That behavior is described in the RFC4306 and now in RFC5996:


      If there has only been outgoing traffic on all = of
  the SAs associated with an IKE SA, it is essential to confirm   liveness of the other endpoint to avoid black holes.  
=
Also as I said if the client sends any packets (TCP acks or similar) then GW will immediately recreate the IKE SA with Host again.

> I think allowing both the initiator and responder to be token make= rs
> actually keeps the protocol simpler.

Clearly we are in disagreement about that. I think it makes protocol more complex, and adds lots of test cases that needs to be separately tested.

> From an implementation perspective I'd prefer to take advantage of=
> QCD as a rather than rely on the fact that every gateway behaves a= s
> Tero suggests.

You do not need to rely it. If the GW or Host implementations are bad (or broken), then there might be longer delays in recovering.
Everything still works.

If you are making implementation then it is better to make good
implementation that follows the RFC 5996 and which can start liveness checks when necessarely (and not do stupid things like doing them
every 30 seconds), and use the hints from the network to shorten those<= br> timers.

That good implementation will work well also with implementations
which do not support QCD at all (i.e. all existing implementations).
> >Yes it is not authenticated, but you do have limited number of=
> >configured IP-addresses in your configuration file, which mean= s that
> >attacker can only set up IKE SA for exactly those hosts, not a= ny
> >other, and as you only create the IKE SA if you do not have an= y, then
> >only thing attacker can cause is you to create the IKE SA even= when
> >you do not yet have traffic to go that way.
>
> I'm not so sure that having a limited number of configured IP addr= esses in
> the configuration file equates to having a small number of address= .  It is
> also likely that one could easily determine the range of valid add= resses.

Matching against range or mathing against single IP-address is
trivial. On the other hand usually you need per IP-address shared key,<= br> or other policy information anyways, thus your VPN style
point-to-point configuration usually has fixed entries for each GW.
=
Note, that VPN GW configuration for VPN client (road warriors) is
different (it usually uses wildcards), but this question is not about those configurations, as in those setups the VPN GW cannot create
connection to the VPN client, as it does not know in which IP-address the VPN client is at given time. We were talking here about the
situation where both ends can initiate connections any time.

> >As I said, in our case we do check our configuration and if th= e
> >invalid ESP packet has IP-address which matches a known peer i= n the
> >configuration file, our implementation do set up the IKE SA fo= r the
> >peer and do send Child SA delete for the ESP SPI to clean up t= he
> >state.
>
> But how do you authenticate that address?  Are you saying tha= t if I
> find an addresses in your config file that I can sit there all day=
> sending you bogus ESP packets and watch you initiate IKE_SAs? &nbs= p;I must
> be missing something here.

Yes. You can send our GW bogus ESP packet (or you actually might need few depending on other things), which will couse us to initiate IKE_SA<= br> to the configured host in our configuration. Then the IKE SA is up and<= br> running, and we do not recreate it even if you send more ESP packets.
Usually site to site vpn sessions are set up to be autostarted
anyways, so those IKE SAs are created on the boot time, thus sending bogus ESP packets do not do anything (or more accurately they can
generate delete message to be send using existing IKE SA to the other end, which the other end will audit when it gets delete message for
= unknown ESP, but those messages are rate limited).
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https:= //www.ietf.org/mailman/listinfo/ipsec

= --1__=0ABBFD27DFD824FD8f9e8a93df938690918c0ABBFD27DFD824FD-- --0__=0ABBFD27DFD824FD8f9e8a93df938690918c0ABBFD27DFD824FD Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFD27DFD824FD8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFD27DFD824FD8f9e8a93df938690918c0ABBFD27DFD824FD-- From welterk@us.ibm.com Wed Oct 6 14:17:02 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 3FE4F3A722B for ; Wed, 6 Oct 2010 14:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.811 X-Spam-Level: X-Spam-Status: No, score=-5.811 tagged_above=-999 required=5 tests=[AWL=0.788, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyvBe+IjBDKf for ; Wed, 6 Oct 2010 14:17:00 -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 417D83A7147 for ; Wed, 6 Oct 2010 14:16:59 -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 o96L7PlY016562 for ; Wed, 6 Oct 2010 15:07:25 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o96LHrwP183230 for ; Wed, 6 Oct 2010 15:17:53 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o96LLfde011072 for ; Wed, 6 Oct 2010 15:21:41 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o96LLfGK011068; Wed, 6 Oct 2010 15:21:41 -0600 In-Reply-To: References: To: "ipsec@ietf.org" MIME-Version: 1.0 X-KeepSent: BBB4E91B:B3ABD016-882577B4:0067AC58; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Wed, 6 Oct 2010 14:17:51 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 10/06/2010 15:17:51, Serialize complete at 10/06/2010 15:17:51 Content-Type: multipart/alternative; boundary="=_alternative 0074FD45882577B4_=" Cc: Yoav Nir Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 21:17:02 -0000 This is a multipart message in MIME format. --=_alternative 0074FD45882577B4_= Content-Type: text/plain; charset="US-ASCII" Yoav Nir wrote on 10/05/2010 07:33:33 AM: > Hi Keith. > > After reading your draft, I wish I had done this in RFC 4478. That's encouraging. Thanks. > Still, I have some comments. > > What are the considerations for the responder accepting a re-authentication? > > Suppose we have an active IKE SA between Alice and Bob. Now Bob > gets a new IKE_SA_INIT request with an N(REAUTH_SA) and the IKE SPIs > for the old IKE SA. When should Bob accept? When should Bob > decline? What if later (in the IKE_AUTH exchange) the authenticated > identity turns out to be Mallory? Interesting question. Would you say that the same problem exists for re-authentication as defined in RFC 5996? It seems to me that in general there is nothing but local policy to stop a different IKE peer from establishing a child SA with the same traffic selectors as an existing child SA. So I wonder what makes that different from moving an existing child SA to a new IKE SA with a different peer. Can you describe a problem that would occur with moving a child SA that would not occur with RFC 5996-style reauthentication? > > The way the draft is now, anyone can probe for the existence of IKE > SPIs by sending IKE_SA_INIT requests with arbitrary IKE SPIs in the > REAUTH_SA notification. This is not a particularly useful attack, > but no need to expose ourselves to it. I think it would be better to > move the notifications to the IKE_AUTH exchange. Good point about the potential for SPI probing. My first version (unpublished) of the draft actually had the REAUTH_SA notification in the IKE_AUTH exchange. There were three advantages I saw for including the REAUTH_SA notification in the IKE_SA_INIT exchange instead. The main advantage was that I could use the presence of the REAUTH_SA notification in the IKE_SA_INIT request to signal usage of the IKE_AUTH exchange described in the draft that adds no additional children. Even though the child SA piggy-backed on the IKE_AUTH exchange doesn't cost any additional round-trips it does cost additional CPU that is unnecessary. And, to be tidy, one would also need to delete the old child SA that was re-negotiated before moving all the remaining children to the new IKE SA. So, eliminating the piggy-backed child SA this way seemed like a very attractive enhancement. The second advantage I saw to including the notification in the IKE_SA_INIT exchange was that it eliminated an obscure collision case. The collision case was awkward to describe but I still have the text for it. To be clear, this was written for the version in which the IKE_AUTH exchange carried the REAUTH_SA notification: If a peer receives a request to reauthenticate an IKE SA for which it has not yet sent a request to reauthenticate, but has sent the IKE_SA_INIT request with intent to reauthenticate, it SHOULD reply as usual but SHOULD NOT include the REAUTH_SA notification in the IKE_AUTH request that it will send and SHOULD close the new IKE SA it creates after it receives the IKE_AUTH response. That text hints at the third and final reason. With the REAUTH_SA notification in the IKE_AUTH exchange, one doesn't know that a new IKE SA is reauthenticating an old IKE SA until the IKE_AUTH exchange begins. Alternatively, with the REAUTH_SA in the IKE_SA_INIT exchange, one knows immediately, from the very first IKE message, whether or not a given IKE SA is intended to reauthenticate another IKE SA or not. Whether or not removing this ambiguity is really an advantage or a disadvantage is debatable I suppose. I'm not sure those three reasons outweigh your SPI probing concern. I'm assuming there is not already a way to probe for SPIs without the REAUTH_SA (I did a quick review of RFC 5996 from that angle and couldn't see another way to accomplish such a probe). If I could still omit the piggy-backed child SA from the IKE_AUTH exchange for a reauthentication I would be happy to move the notification back to the IKE_AUTH exchange where I originally had it. > Once there, the intuitive logic would be: > - If the peer authenticates as other than Alice, deny REAUTH (fail > the exchange?) > - If authentication fails, ignore it. The old IKE SA remains alive. > - If the peer authenticates as Alice, allow the reauth. > > This leads me to another issue. If the peer authenticates as Alice, > we can treat it as an "Alice". Is it OK for "an Alice" to inherit > the child SAs of any other "Alice"? Ideally, there is only one > "Alice" and if the peer authenticates as "Alice" it may inherit any > child SAs belonging to any IKE SA belonging to "Alice", but I think > it would be better to somehow tie the old SA to the new SA with non- > public information. Perhaps something derived from the SKEYSEED > along with SK_d and the rest. I'll defer to Yaron's response here though I'd still like to understand if this issue is really isolated to the proposed movement of child SAs for reauthentication as I asked above. > > One final issue. The IKE_AUTH exchange in your draft does not > include what's needed for creating new Child SAs. This is not > allowed by RFC 5996. There is, however, a soon-to-be-published RFC > for this (draft-nir-ipsecme-childless) I was aware of this draft. Assuming we conclude that it would be best to move the REAUTH_SA notification to the IKE_AUTH exchange then I would want to refer to that document and specify that it's mechanisms be used to avoid creating an additional child SA when reauthenticating an IKE SA. However, I'm not clear why the approach described in the current version of my draft is a not an acceptable way to specify a childless IKE_AUTH exchange. > > Yoav > > On Sep 28, 2010, at 10:03 PM, Keith Welter wrote: > > > > > A new version of I-D, draft-welter-ipsecme-ikev2-reauth-00.txt has > been successfully submitted by Keith Welter and posted to the IETF repository. > > > > Filename: draft-welter-ipsecme-ikev2-reauth > > Revision: 00 > > Title: Reauthentication > Extension for IKEv2 > > Creation_date: 2010-09-28 > > WG ID: Independent Submission > > Number_of_pages: 10 > > > > Abstract: > > This document extends the Internet Key Exchange (IKEv2) Protocol > > document [IKEv2]. IKEv2 reauthentication does not scale well when an > > IKE SA has multiple Child SAs because each Child SA of the IKE SA to > > be reauthenticated must be renegotiated. In addition, > > reauthentication is susceptible to the same kinds of exchange > > collisions as those that may occur during rekeying. This document > > describes a mechanism to detect reauthentication and avoid > > renegotiating the Child SAs. In addition, this document describes > > proper handling of exchange collisions that may occur during > > reauthentication. > > > > > > > > The IETF Secretariat. > > > > > > > > > --=_alternative 0074FD45882577B4_= Content-Type: text/html; charset="US-ASCII"
Yoav Nir <ynir@checkpoint.com> wrote on 10/05/2010 07:33:33 AM:

> Hi Keith.
>
> After reading your draft, I wish I had done this in RFC 4478.
That's encouraging.  Thanks.

> Still, I have some comments.
>
> What are the considerations for the responder accepting a re-authentication?
>
> Suppose we have an active IKE SA between Alice and Bob.  Now Bob
> gets a new IKE_SA_INIT request with an N(REAUTH_SA) and the IKE SPIs
> for the old IKE SA. When should Bob accept?  When should Bob
> decline? What if later (in the IKE_AUTH exchange) the authenticated
> identity turns out to be Mallory?
Interesting question.  Would you say that the same problem exists for re-authentication as defined in RFC 5996?  It seems to me that in general there is nothing but local policy to stop a different IKE peer from establishing a child SA with the same traffic selectors as an existing child SA.  So I wonder what makes that different from moving an existing child SA to a new IKE SA with a different peer.  Can you describe a problem that would occur with moving a child SA that would not occur with RFC 5996-style reauthentication?

>
> The way the draft is now, anyone can probe for the existence of IKE
> SPIs by sending IKE_SA_INIT requests with arbitrary IKE SPIs in the
> REAUTH_SA notification. This is not a particularly useful attack,
> but no need to expose ourselves to it. I think it would be better to
> move the notifications to the IKE_AUTH exchange.
Good point about the potential for SPI probing.  

My first version (unpublished) of the draft actually had the REAUTH_SA notification in the IKE_AUTH exchange.  There were three advantages I saw for including the REAUTH_SA notification in the IKE_SA_INIT exchange instead.  The main advantage was that I could use the presence of the REAUTH_SA notification in the IKE_SA_INIT request to signal usage of the IKE_AUTH exchange described in the draft that adds no additional children.  Even though the child SA piggy-backed on the IKE_AUTH exchange doesn't cost any additional round-trips it does cost additional CPU that is unnecessary.  And, to be tidy, one would also need to delete the old child SA that was re-negotiated before moving all the remaining children to the new IKE SA.  So, eliminating the piggy-backed child SA this way seemed like a very attractive enhancement.

The second advantage I saw to including the notification in the IKE_SA_INIT exchange was that it eliminated an obscure collision case.  The collision case was awkward to describe but I still have the text for it.  To be clear, this was written for the version in which the IKE_AUTH exchange carried the REAUTH_SA notification:
   If a peer receives a request to reauthenticate an IKE SA for which it
   has not yet sent a request to reauthenticate, but has sent the
   IKE_SA_INIT request with intent to reauthenticate, it SHOULD reply as
   usual but SHOULD NOT include the REAUTH_SA notification in the
   IKE_AUTH request that it will send and SHOULD close the new IKE SA it
   creates after it receives the IKE_AUTH response.

That text hints at the third and final reason.  With the REAUTH_SA notification in the IKE_AUTH exchange, one doesn't know that a new IKE SA is reauthenticating an old IKE SA until the IKE_AUTH exchange begins.  Alternatively, with the REAUTH_SA in the IKE_SA_INIT exchange, one knows immediately, from the very first IKE message, whether or not a given IKE SA is intended to reauthenticate another IKE SA or not.  Whether or not removing this ambiguity is really an advantage or a disadvantage is debatable I suppose.

I'm not sure those three reasons outweigh your SPI probing concern.  I'm assuming there is not already a way to probe for SPIs without the REAUTH_SA (I did a quick review of RFC 5996 from that angle and couldn't see another way to accomplish such a probe).  If I could still omit the piggy-backed child SA from the IKE_AUTH exchange for a reauthentication I would be happy to move the notification back to the IKE_AUTH exchange where I originally had it.

> Once there, the intuitive logic would be:
>  - If the peer authenticates as other than Alice, deny REAUTH (fail
> the exchange?)
>  - If authentication fails, ignore it. The old IKE SA remains alive.
>  - If the peer authenticates as Alice, allow the reauth.
>
> This leads me to another issue. If the peer authenticates as Alice,
> we can treat it as an "Alice". Is it OK for "an Alice" to inherit
> the child SAs of any other "Alice"?  Ideally, there is only one
> "Alice" and if the peer authenticates as "Alice" it may inherit any
> child SAs belonging to any IKE SA belonging to "Alice", but I think
> it would be better to somehow tie the old SA to the new SA with non-
> public information. Perhaps something derived from the SKEYSEED
> along with SK_d and the rest.
I'll defer to Yaron's response here though I'd still like to understand if this issue is really isolated to the proposed movement of child SAs for reauthentication as I asked above.

>
> One final issue. The IKE_AUTH exchange in your draft does not
> include what's needed for creating new Child SAs. This is not
> allowed by RFC 5996. There is, however, a soon-to-be-published RFC
> for this (draft-nir-ipsecme-childless)
I was aware of this draft.  Assuming we conclude that it would be best to move the REAUTH_SA notification to the IKE_AUTH exchange then I would want to refer to that document and specify that it's mechanisms be used to avoid creating an additional child SA when reauthenticating an IKE SA.  However, I'm not clear why the approach described in the current version of my draft is a not an acceptable way to specify a childless IKE_AUTH exchange.

>
> Yoav
>
> On Sep 28, 2010, at 10:03 PM, Keith Welter wrote:
>
> >
> > A new version of I-D, draft-welter-ipsecme-ikev2-reauth-00.txt has
> been successfully submitted by Keith Welter and posted to the IETF repository.
> >
> > Filename:                  draft-welter-ipsecme-ikev2-reauth
> > Revision:                  00
> > Title:                                   Reauthentication
> Extension for IKEv2
> > Creation_date:                  2010-09-28
> > WG ID:                                   Independent Submission
> > Number_of_pages: 10
> >
> > Abstract:
> > This document extends the Internet Key Exchange (IKEv2) Protocol
> > document [IKEv2].  IKEv2 reauthentication does not scale well when an
> > IKE SA has multiple Child SAs because each Child SA of the IKE SA to
> > be reauthenticated must be renegotiated.  In addition,
> > reauthentication is susceptible to the same kinds of exchange
> > collisions as those that may occur during rekeying.  This document
> > describes a mechanism to detect reauthentication and avoid
> > renegotiating the Child SAs.  In addition, this document describes
> > proper handling of exchange collisions that may occur during
> > reauthentication.
> >                                                                            
> >
> >
> > The IETF Secretariat.
> >
> >
> >
> > <ATT00001..txt>
>
--=_alternative 0074FD45882577B4_=-- From yaronf.ietf@gmail.com Wed Oct 6 14:32: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 A8C6B3A6F95 for ; Wed, 6 Oct 2010 14:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjMkseXr0rKW for ; Wed, 6 Oct 2010 14:32:39 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 760A93A6FF2 for ; Wed, 6 Oct 2010 14:32:35 -0700 (PDT) Received: by bwz9 with SMTP id 9so38728bwz.31 for ; Wed, 06 Oct 2010 14:33:35 -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=2Y47GctfWZC62kcuW/0Uv3UsKoH8H7fqIzo6z615cfQ=; b=BXgh3xST4JYzbiSDy910z+8/2nkRm30Pp6vxejc1X5MmNIVLbUp00FayGBG1tMDHRA y2UliT/kbFyPl3FIKTXKLgo6BMg7b/oJc0x4IfkYGcrdgPaGJ96Adw2Kuq5JSBLW3BLg xUj4BeyewIIQFsDicNMp5n0ylttD1+9kN/l5I= 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=qE9ZaQ/G3OWBygBP2evr3Vog7D61T4iubw6SDIQyjxOVpDBqrHFJjDsP3j6HcTTgNG ebRDtHXu8GT1uHIBSBBo4LSKMnj1F9rd54QGGYfciXgcWLoKug6KO8xzuzRBCzK8CNVC 0QE2mWnT3eTJbNUHSwuyh5Ru/AnxINrqYolAE= Received: by 10.204.148.67 with SMTP id o3mr10129041bkv.208.1286400815757; Wed, 06 Oct 2010 14:33:35 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-181-39-14.red.bezeqint.net [79.181.39.14]) by mx.google.com with ESMTPS id 11sm1028511bkj.23.2010.10.06.14.33.31 (version=SSLv3 cipher=RC4-MD5); Wed, 06 Oct 2010 14:33:34 -0700 (PDT) Message-ID: <4CACEB28.2040301@gmail.com> Date: Wed, 06 Oct 2010 23:33:28 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: Keith Welter References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 21:32:41 -0000 Hi Keith, I think you can exchange the REAUTH notification in the *original* IKE_AUTH exchange (when you authenticate for the first time), probably with an empty notification data. This would let both peers know that they both support the protocol. And then during reauth, you can still have the notification in IKE_AUTH. Am I missing anything? Thanks, Yaron On 10/06/2010 11:17 PM, Keith Welter wrote: > [...] > > I'm not sure those three reasons outweigh your SPI probing concern. I'm > assuming there is not already a way to probe for SPIs without the > REAUTH_SA (I did a quick review of RFC 5996 from that angle and couldn't > see another way to accomplish such a probe). If I could still omit the > piggy-backed child SA from the IKE_AUTH exchange for a reauthentication > I would be happy to move the notification back to the IKE_AUTH exchange > where I originally had it. > From welterk@us.ibm.com Wed Oct 6 15:49:20 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 DE0E13A715B for ; Wed, 6 Oct 2010 15:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4dH6yaQ8p9i for ; Wed, 6 Oct 2010 15:49:19 -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 B0D4B3A6F50 for ; Wed, 6 Oct 2010 15:49:19 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o96Mdq75012767 for ; Wed, 6 Oct 2010 16:39:52 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o96MoKTp042342 for ; Wed, 6 Oct 2010 16:50:20 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o96MoJMD003396 for ; Wed, 6 Oct 2010 16:50:19 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o96MoILG003391; Wed, 6 Oct 2010 16:50:18 -0600 In-Reply-To: <4CACEB28.2040301@gmail.com> References: <4CACEB28.2040301@gmail.com> To: Yaron Sheffer MIME-Version: 1.0 X-KeepSent: 956967E0:684A9E77-882577B4:00794A87; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Wed, 6 Oct 2010 15:50:17 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 10/06/2010 16:50:18, Serialize complete at 10/06/2010 16:50:18 Content-Type: multipart/alternative; boundary="=_alternative 007D73DF882577B4_=" Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 22:49:21 -0000 This is a multipart message in MIME format. --=_alternative 007D73DF882577B4_= Content-Type: text/plain; charset="US-ASCII" Hi Yaron, Adding an empty REAUTH_SA notification in the original IKE_AUTH exchange is a nice way to determine in advance of a reauth if both peers support the protocol. It might be sufficient to only include it in the response as is done with the CHILDLESS_IKE_SUPPORTED notification in draft-nir-ipsecme-childless. For the sake of argument though, I could put an empty REAUTH_SA notification in the original IKE_SA_INIT exchange and accomplish the same thing. The essential change to avoid the SPI probe that Yoav pointed out is that the REAUTH_SA notification be in the IKE_AUTH exchange regardless of whether the initiator knows in advance that the responder supports the protocol. At this point, including the REAUTH_SA notification in the IKE_AUTH exchange seems like the right thing to do and I like your suggestion too. I can use the peer protocol support knowledge to disambiguate the following case: If the response does not include the REAUTH_SA notification it indicates that either the responder does not recognize the IKE SA to be reauthenticated or the responder does not support the REAUTH_SA notification. I also think that the right thing to do is to make draft-nir-ipsecme-childless a normative reference in my draft and incorporate it's methods for making the IKE_AUTH exchange childless. Thanks, Keith Yaron Sheffer wrote on 10/06/2010 02:33:28 PM: > [...] > Hi Keith, > > I think you can exchange the REAUTH notification in the *original* > IKE_AUTH exchange (when you authenticate for the first time), probably > with an empty notification data. This would let both peers know that > they both support the protocol. And then during reauth, you can still > have the notification in IKE_AUTH. Am I missing anything? > > Thanks, > Yaron > > On 10/06/2010 11:17 PM, Keith Welter wrote: > > > [...] > > > > > I'm not sure those three reasons outweigh your SPI probing concern. I'm > > assuming there is not already a way to probe for SPIs without the > > REAUTH_SA (I did a quick review of RFC 5996 from that angle and couldn't > > see another way to accomplish such a probe). If I could still omit the > > piggy-backed child SA from the IKE_AUTH exchange for a reauthentication > > I would be happy to move the notification back to the IKE_AUTH exchange > > where I originally had it. > > --=_alternative 007D73DF882577B4_= Content-Type: text/html; charset="US-ASCII"
Hi Yaron,

Adding an empty REAUTH_SA notification in the original IKE_AUTH exchange is a nice way to determine in advance of a reauth if both peers support the protocol.  It might be sufficient to only include it in the response as is done with the CHILDLESS_IKE_SUPPORTED notification in draft-nir-ipsecme-childless.  For the sake of argument though, I could put an empty REAUTH_SA notification in the original IKE_SA_INIT exchange and accomplish the same thing.  The essential change to avoid the SPI probe that Yoav pointed out is that the REAUTH_SA notification be in the IKE_AUTH exchange regardless of whether the initiator knows in advance that the responder supports the protocol.  At this point, including the REAUTH_SA notification in the IKE_AUTH exchange seems like the right thing to do and I like your suggestion too.  I can use the peer protocol support knowledge to disambiguate the following case:
   If the response
  does not include the REAUTH_SA notification it indicates that either
  the responder does not recognize the IKE SA to be reauthenticated or
  the responder does not support the REAUTH_SA notification.

I also think that the right thing to do is to make draft-nir-ipsecme-childless a normative reference in my draft and incorporate it's methods for making the IKE_AUTH exchange childless.  

Thanks,
Keith

Yaron Sheffer <yaronf.ietf@gmail.com> wrote on 10/06/2010 02:33:28 PM:

>
[...]
> Hi Keith,
>
> I think you can exchange the REAUTH notification in the *original*
> IKE_AUTH exchange (when you authenticate for the first time), probably
> with an empty notification data. This would let both peers know that
> they both support the protocol. And then during reauth, you can still
> have the notification in IKE_AUTH. Am I missing anything?
>
> Thanks,
>    Yaron
>
> On 10/06/2010 11:17 PM, Keith Welter wrote:
> >
> [...]
>
> >
> > I'm not sure those three reasons outweigh your SPI probing concern. I'm
> > assuming there is not already a way to probe for SPIs without the
> > REAUTH_SA (I did a quick review of RFC 5996 from that angle and couldn't
> > see another way to accomplish such a probe). If I could still omit the
> > piggy-backed child SA from the IKE_AUTH exchange for a reauthentication
> > I would be happy to move the notification back to the IKE_AUTH exchange
> > where I originally had it.
> >
 --=_alternative 007D73DF882577B4_=-- From ynir@checkpoint.com Thu Oct 7 00:47:20 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 99A443A6EA5 for ; Thu, 7 Oct 2010 00:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 JhGRsu7F2-1b for ; Thu, 7 Oct 2010 00:47:19 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 3F63E3A6D14 for ; Thu, 7 Oct 2010 00:47:17 -0700 (PDT) X-CheckPoint: {4CAD7A20-10000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o977mInv025845; Thu, 7 Oct 2010 09:48:18 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 7 Oct 2010 09:48:18 +0200 From: Yoav Nir To: Keith Welter Date: Thu, 7 Oct 2010 09:48:17 +0200 Thread-Topic: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 Thread-Index: Actl9AFKbGPb0s0kTTS2tJ2zdXvTdg== Message-ID: <3C3AC0EB-BBBB-4857-A595-A958E175CD4A@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 07:47:20 -0000 Hi Keith. My responses are below, but first I would like to know if you have consider= ed a different solution - having an IKE_AUTH exchange in the middle of the = IKE SA lifetime. Suppose the IKE SA has been around for a couple of hours, = and has been used for creating some child SAs, why not keep it and just pas= s one or more IKE_AUTH exchanges? I had considered this when making 4478, and the only thing that "blocked" m= e was that I couldn't figure out what to sign in the AUTH payloads. In regu= lar IKE, they sign the IKE_SA_INIT messages, and I didn't like the idea of = storing those for the lifetime of the IKE SA. Perhaps we could store the co= ntents of the previous AUTH payload (or a hash thereof) and sign that. On Oct 6, 2010, at 11:17 PM, Keith Welter wrote: >=20 > Yoav Nir wrote on 10/05/2010 07:33:33 AM: >=20 > > Hi Keith. > >=20 > > After reading your draft, I wish I had done this in RFC 4478.=20 > That's encouraging. Thanks.=20 >=20 > > Still, I have some comments. > >=20 > > What are the considerations for the responder accepting a re-authentica= tion? > >=20 > > Suppose we have an active IKE SA between Alice and Bob. Now Bob=20 > > gets a new IKE_SA_INIT request with an N(REAUTH_SA) and the IKE SPIs > > for the old IKE SA. When should Bob accept? When should Bob=20 > > decline? What if later (in the IKE_AUTH exchange) the authenticated=20 > > identity turns out to be Mallory?=20 > Interesting question. Would you say that the same problem exists for re-= authentication as defined in RFC 5996? In RFC 5996, the new IKE SA does not inherit the old child SAs. New child S= As will be created according to the policy relevant to Mallory. > It seems to me that in general there is nothing but local policy to stop= a different IKE peer from establishing a child SA with the same traffic se= lectors as an existing child SA. So I wonder what makes that different fro= m moving an existing child SA to a new IKE SA with a different peer. Can y= ou describe a problem that would occur with moving a child SA that would no= t occur with RFC 5996-style reauthentication?=20 The problem is having a child SA that belongs to Mallory, that is not allow= ed by policy (for Mallory). Another problem is one user getting another us= er's IP address, because the servers behind the gateway often rely on IP ad= dress for continuation of a session. One way is that when inheriting the ch= ild SAs, the IKE implementation goes over them, and only transfers those th= at agree with policy. That might work for inter-domain, but with remote acc= ess, there's usually no pre-defined policy as to what selectors are allowed= for the user.=20 As Tero pointed out, re-authenticating implies also inheriting the assigned= IP address, so I really think you need to set rules (or at least guidance)= about the relationship between the old and new authenticated identity (is = "Alice" with a password the same as the user who presents a certificate wit= h "CN=3DAlice,OU=3DUsers"? What about same DN but a different certificate?= ) >=20 > >=20 > > The way the draft is now, anyone can probe for the existence of IKE=20 > > SPIs by sending IKE_SA_INIT requests with arbitrary IKE SPIs in the=20 > > REAUTH_SA notification. This is not a particularly useful attack,=20 > > but no need to expose ourselves to it. I think it would be better to > > move the notifications to the IKE_AUTH exchange.=20 > Good point about the potential for SPI probing. =20 >=20 > My first version (unpublished) of the draft actually had the REAUTH_SA no= tification in the IKE_AUTH exchange. There were three advantages I saw for= including the REAUTH_SA notification in the IKE_SA_INIT exchange instead. = The main advantage was that I could use the presence of the REAUTH_SA noti= fication in the IKE_SA_INIT request to signal usage of the IKE_AUTH exchang= e described in the draft that adds no additional children. Even though the= child SA piggy-backed on the IKE_AUTH exchange doesn't cost any additional= round-trips it does cost additional CPU that is unnecessary. And, to be t= idy, one would also need to delete the old child SA that was re-negotiated = before moving all the remaining children to the new IKE SA. So, eliminatin= g the piggy-backed child SA this way seemed like a very attractive enhancem= ent.=20 The childless notification can be used for signaling, and I agree with Yaro= n, that support for REAUTH_SA can be signaled in the original IKE_AUTH. >=20 > The second advantage I saw to including the notification in the IKE_SA_IN= IT exchange was that it eliminated an obscure collision case. The collisio= n case was awkward to describe but I still have the text for it. To be cle= ar, this was written for the version in which the IKE_AUTH exchange carried= the REAUTH_SA notification:=20 > If a peer receives a request to reauthenticate an IKE SA for which it= =20 > has not yet sent a request to reauthenticate, but has sent the=20 > IKE_SA_INIT request with intent to reauthenticate, it SHOULD reply as= =20 > usual but SHOULD NOT include the REAUTH_SA notification in the=20 > IKE_AUTH request that it will send and SHOULD close the new IKE SA it= =20 > creates after it receives the IKE_AUTH response.=20 I think you can require never to send a REAUTH_SA if you have already recei= ved one from the peer. If that means leaving a half-open SA, so be it. RFC = 5996 already requires implementations to handle these cases, and you can re= duce them with guidance for original initiators to re-authenticate earlier = than original responders. This leaves just the case of both sides having performed the IKE_SA_INIT, a= nd sending the IKE_AUTH request before either receives the other IKE_AUTH r= equest. This can be handled by having the one with lower Initiator SPI win,= while the other exchange gets some error message (no proposal chosen? or = a new one?) >=20 > That text hints at the third and final reason. With the REAUTH_SA notifi= cation in the IKE_AUTH exchange, one doesn't know that a new IKE SA is reau= thenticating an old IKE SA until the IKE_AUTH exchange begins. Alternative= ly, with the REAUTH_SA in the IKE_SA_INIT exchange, one knows immediately, = from the very first IKE message, whether or not a given IKE SA is intended = to reauthenticate another IKE SA or not. Whether or not removing this ambi= guity is really an advantage or a disadvantage is debatable I suppose.=20 OK. I'll debate for the other side. There's no reason to expose to eavesdro= ppers that we're doing a re-authentication. IKE_AUTH is encrypted, while IK= E_SA_INIT is not.=20 >=20 > I'm not sure those three reasons outweigh your SPI probing concern. I'm = assuming there is not already a way to probe for SPIs without the REAUTH_SA= (I did a quick review of RFC 5996 from that angle and couldn't see another= way to accomplish such a probe). If I could still omit the piggy-backed c= hild SA from the IKE_AUTH exchange for a reauthentication I would be happy = to move the notification back to the IKE_AUTH exchange where I originally h= ad it.=20 >=20 > > Once there, the intuitive logic would be: > > - If the peer authenticates as other than Alice, deny REAUTH (fail=20 > > the exchange?) > > - If authentication fails, ignore it. The old IKE SA remains alive. > > - If the peer authenticates as Alice, allow the reauth.=20 > >=20 > > This leads me to another issue. If the peer authenticates as Alice,=20 > > we can treat it as an "Alice". Is it OK for "an Alice" to inherit=20 > > the child SAs of any other "Alice"? Ideally, there is only one=20 > > "Alice" and if the peer authenticates as "Alice" it may inherit any=20 > > child SAs belonging to any IKE SA belonging to "Alice", but I think=20 > > it would be better to somehow tie the old SA to the new SA with non- > > public information. Perhaps something derived from the SKEYSEED=20 > > along with SK_d and the rest. > I'll defer to Yaron's response here though I'd still like to understand i= f this issue is really isolated to the proposed movement of child SAs for r= eauthentication as I asked above.=20 If I connect to work from both computer and my phone, should the phone be a= ble to "steal" the computer's SAs? If IKE is ever integrated with NEA work,= it might imply moving SAs that were created with one posture to a host wit= h another posture. Without NEA, it's not so much a security issue, as it is= a networking issue. >=20 > >=20 > > One final issue. The IKE_AUTH exchange in your draft does not=20 > > include what's needed for creating new Child SAs. This is not=20 > > allowed by RFC 5996. There is, however, a soon-to-be-published RFC=20 > > for this (draft-nir-ipsecme-childless)=20 > I was aware of this draft. Assuming we conclude that it would be best to= move the REAUTH_SA notification to the IKE_AUTH exchange then I would want= to refer to that document and specify that it's mechanisms be used to avoi= d creating an additional child SA when reauthenticating an IKE SA. However= , I'm not clear why the approach described in the current version of my dra= ft is a not an acceptable way to specify a childless IKE_AUTH exchange.=20 >=20 > >=20 > > Yoav > >=20 > > On Sep 28, 2010, at 10:03 PM, Keith Welter wrote: > >=20 > > >=20 > > > A new version of I-D, draft-welter-ipsecme-ikev2-reauth-00.txt has > > been successfully submitted by Keith Welter and posted to the IETF repo= sitory. > > >=20 > > > Filename: draft-welter-ipsecme-ikev2-reauth > > > Revision: 00 > > > Title: Reauthentication=20 > > Extension for IKEv2 > > > Creation_date: 2010-09-28 > > > WG ID: Independent Submission > > > Number_of_pages: 10 > > >=20 > > > Abstract: > > > This document extends the Internet Key Exchange (IKEv2) Protocol > > > document [IKEv2]. IKEv2 reauthentication does not scale well when an > > > IKE SA has multiple Child SAs because each Child SA of the IKE SA to > > > be reauthenticated must be renegotiated. In addition, > > > reauthentication is susceptible to the same kinds of exchange > > > collisions as those that may occur during rekeying. This document > > > describes a mechanism to detect reauthentication and avoid > > > renegotiating the Child SAs. In addition, this document describes > > > proper handling of exchange collisions that may occur during > > > reauthentication. > > > = =20 > > >=20 > > >=20 > > > The IETF Secretariat. > > >=20 > > >=20 > > >=20 > > > > >=20 >=20 >=20 > Scanned by Check Point Total Security Gateway.=20 >=20 From kivinen@iki.fi Thu Oct 7 03:29:25 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 683E63A6E2C for ; Thu, 7 Oct 2010 03:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04PxlmVWOB92 for ; Thu, 7 Oct 2010 03:29:24 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E882F3A6FC0 for ; Thu, 7 Oct 2010 03:29:23 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o97AUMmJ016168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Oct 2010 13:30:22 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o97AULoU018068; Thu, 7 Oct 2010 13:30:21 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19629.41277.63968.179061@fireball.kivinen.iki.fi> Date: Thu, 7 Oct 2010 13:30:21 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <19591.24647.497524.822377@fireball.kivinen.iki.fi> <19591.32575.931479.621032@fireball.kivinen.iki.fi> <19592.37973.545808.950166@fireball.kivinen.iki.fi> <19594.16591.378433.920474@fireball.kivinen.iki.fi> <4C8C95E9.5080801@gmail.com> <19600.33044.946153.563329@fireball.kivinen.iki.fi> <19628.31823.7854.335670@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 78 min Cc: ipsec@ietf.org, David Wierbowski Subject: Re: [IPsec] Comments to draft-ietf-ipsecme-failure-detection-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 10:29:25 -0000 Scott C Moonen writes: > > As the host is sending traffic it will immediately notice when it is > > not getting ACKs back from the GW, i.e. when the traffic gets > > unidirectional, and again it can start fixing situation at that > > point. > > But Tero, that process can take several minutes. First the host initiates > a liveness exchange, then after a minute or two of retransmissions it times > out, then starts to negotiate a new IKE SA. On bad implementation it can even take forever, if they do not implement any kind of crash recovery code. On good implementation it will recover in few seconds after the GW is up again (i.e when GW receives first unknown ESP packet and finds Host from its configuration and recreates IKE SA and sends delete for ESP, or when client sends next IP packet which will cause GW to recreate IKE SA and Child SA as they do not exists). > By that time the TCP connection has timed out. TCP Timeouts are several minutes too, so TCP connections should not time out that soon. > This is *exactly* the problem that QCD is > designed to fix, and if I am the host here I definitely want to take > advantage of QCD in this situation rather than lose my TCP connection. Host will notice that traffic changed unidirectional and should start liveness check way before the GW has even recovered, and especially if it receives hints from the other end that GW has crashed (ICMP host unreachables, protocol unreachables, IKE invalid SPI notifications etc), then it can shorten timeouts needed to really delete IKE SA and start over. Bad implementation can take that much time that TCP connections times out, but not all implementations needs to be bad, you can also make good implementations and if you are writing that host implementation better make that implementation good so it will work regardless whether QCD is there or not. It seems that in most discussions about QCD people assume that the IPsec implementations are the very bad and the QCD is magic wand that will make those implementations good. I do not expect that to happen. If the vendors have not bothered to care about crash recover before QCD, I do not expect them to be bothering about it later either, meaning they most likely will not implement QCD. -- kivinen@iki.fi From welterk@us.ibm.com Thu Oct 7 09:43:22 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 02D153A6FF5 for ; Thu, 7 Oct 2010 09:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.968 X-Spam-Level: X-Spam-Status: No, score=-5.968 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5G8HGpYqQlsN for ; Thu, 7 Oct 2010 09:43:20 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 124D33A6F96 for ; Thu, 7 Oct 2010 09:43:19 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o97GiYgl021480 for ; Thu, 7 Oct 2010 12:44:34 -0400 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o97GiCDg135584 for ; Thu, 7 Oct 2010 12:44:13 -0400 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o97GiCuM009447 for ; Thu, 7 Oct 2010 10:44:12 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o97GiC03009444; Thu, 7 Oct 2010 10:44:12 -0600 In-Reply-To: References: To: "ipsec@ietf.org" MIME-Version: 1.0 X-KeepSent: E0EA640A:BB1BC41B-882577B5:005B0F86; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Thu, 7 Oct 2010 09:44:11 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 10/07/2010 10:44:12, Serialize complete at 10/07/2010 10:44:12 Content-Type: multipart/alternative; boundary="=_alternative 005BEF11882577B5_=" Cc: Yoav Nir Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:43:22 -0000 This is a multipart message in MIME format. --=_alternative 005BEF11882577B5_= Content-Type: text/plain; charset="US-ASCII" Answering my own question... > > What are the considerations for the responder accepting a re-authentication? > > > > Suppose we have an active IKE SA between Alice and Bob. Now Bob > > gets a new IKE_SA_INIT request with an N(REAUTH_SA) and the IKE SPIs > > for the old IKE SA. When should Bob accept? When should Bob > > decline? What if later (in the IKE_AUTH exchange) the authenticated > > identity turns out to be Mallory? > Interesting question. Would you say that the same problem exists > for re-authentication as defined in RFC 5996? It seems to me that > in general there is nothing but local policy to stop a different IKE > peer from establishing a child SA with the same traffic selectors as > an existing child SA. So I wonder what makes that different from > moving an existing child SA to a new IKE SA with a different peer. > Can you describe a problem that would occur with moving a child SA > that would not occur with RFC 5996-style reauthentication? RFC 4301 section 4.4.3.4 "How the PAD is Used" says: Child SAs are created based on the exchange of traffic selector payloads, either at the end of the initial IKE exchange or in subsequent CREATE_CHILD_SA exchanges. The PAD entry for the (now authenticated) IKE peer is used to constrain creation of child SAs; specifically, the PAD entry specifies how the SPD is searched using a traffic selector proposal from a peer. There are two choices: either the IKE ID asserted by the peer is used to find an SPD entry via its symbolic name, or peer IP addresses asserted in traffic selector payloads are used for SPD lookups based on the remote IP address field portion of an SPD entry. It is necessary to impose these constraints on creation of child SAs to prevent an authenticated peer from spoofing IDs associated with other, legitimate peers. Moving the child SAs for a reauthenticated IKE SA could circumvent the checking that allows the PAD to constrain the creation of a child SA to a particular IKE peer. So, I agree that the initiator of a reauth must prove that he is the same entity with which the original IKE SA was established. Having the reauth initiator supply the old SK_d as Yoav suggested would accomplish that. The old SK_d can be appended to the SPIs in the REAUTH_SA notification. --=_alternative 005BEF11882577B5_= Content-Type: text/html; charset="US-ASCII"
Answering my own question...

> > What are the considerations for the responder accepting a re-authentication?
> >
> > Suppose we have an active IKE SA between Alice and Bob.  Now Bob
> > gets a new IKE_SA_INIT request with an N(REAUTH_SA) and the IKE SPIs
> > for the old IKE SA. When should Bob accept?  When should Bob
> > decline? What if later (in the IKE_AUTH exchange) the authenticated
> > identity turns out to be Mallory?
> Interesting question.  Would you say that the same problem exists
> for re-authentication as defined in RFC 5996?  It seems to me that
> in general there is nothing but local policy to stop a different IKE
> peer from establishing a child SA with the same traffic selectors as
> an existing child SA.  So I wonder what makes that different from
> moving an existing child SA to a new IKE SA with a different peer.  
> Can you describe a problem that would occur with moving a child SA
> that would not occur with RFC 5996-style reauthentication?

RFC 4301 section 4.4.3.4 "How the PAD is Used" says:
   Child SAs are created based on the exchange of traffic selector
  payloads, either at the end of the initial IKE exchange or in
  subsequent CREATE_CHILD_SA exchanges.  The PAD entry for the (now
  authenticated) IKE peer is used to constrain creation of child SAs;
  specifically, the PAD entry specifies how the SPD is searched using a
  traffic selector proposal from a peer.  There are two choices: either
  the IKE ID asserted by the peer is used to find an SPD entry via its
  symbolic name, or peer IP addresses asserted in traffic selector
  payloads are used for SPD lookups based on the remote IP address
  field portion of an SPD entry.  It is necessary to impose these
  constraints on creation of child SAs to prevent an authenticated peer
  from spoofing IDs associated with other, legitimate peers.
Moving the child SAs for a reauthenticated IKE SA could circumvent the checking that allows the PAD to constrain the creation of a child SA to a particular IKE peer.  So, I agree that the initiator of a reauth must prove that he is the same entity with which the original IKE SA was established.  Having the reauth initiator supply the old SK_d as Yoav suggested would accomplish that.  The old SK_d can be appended to the SPIs in the REAUTH_SA notification. --=_alternative 005BEF11882577B5_=-- From welterk@us.ibm.com Thu Oct 7 09:59: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 4D76A3A706B for ; Thu, 7 Oct 2010 09:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.025 X-Spam-Level: X-Spam-Status: No, score=-6.025 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtCXBFp58a+J for ; Thu, 7 Oct 2010 09:59:46 -0700 (PDT) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id 567673A6F90 for ; Thu, 7 Oct 2010 09:59:46 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o97GufDS019439 for ; Thu, 7 Oct 2010 10:56:41 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id o97H0a3Z155558 for ; Thu, 7 Oct 2010 11:00:39 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o97H4P7c003232 for ; Thu, 7 Oct 2010 11:04:25 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o97H4P3w003229 for ; Thu, 7 Oct 2010 11:04:25 -0600 In-Reply-To: References: To: "ipsec@ietf.org" MIME-Version: 1.0 X-KeepSent: 4C003D9A:88D71070-882577B5:005D2DAA; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Thu, 7 Oct 2010 10:00:36 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 10/07/2010 11:00:35, Serialize complete at 10/07/2010 11:00:35 Content-Type: multipart/alternative; boundary="=_alternative 005D6FAB882577B5_=" Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 16:59:47 -0000 This is a multipart message in MIME format. --=_alternative 005D6FAB882577B5_= Content-Type: text/plain; charset="US-ASCII" A colleague pointed-out that including the old SK_d itself in the REAUTH_SA notification is a bad idea. A better approach would be to incorporate it into the new AUTH payload. > RFC 4301 section 4.4.3.4 "How the PAD is Used" says: > Child SAs are created based on the exchange of traffic selector > payloads, either at the end of the initial IKE exchange or in > subsequent CREATE_CHILD_SA exchanges. The PAD entry for the (now > authenticated) IKE peer is used to constrain creation of child SAs; > specifically, the PAD entry specifies how the SPD is searched using a > traffic selector proposal from a peer. There are two choices: either > the IKE ID asserted by the peer is used to find an SPD entry via its > symbolic name, or peer IP addresses asserted in traffic selector > payloads are used for SPD lookups based on the remote IP address > field portion of an SPD entry. It is necessary to impose these > constraints on creation of child SAs to prevent an authenticated peer > from spoofing IDs associated with other, legitimate peers. > > Moving the child SAs for a reauthenticated IKE SA could circumvent > the checking that allows the PAD to constrain the creation of a > child SA to a particular IKE peer. So, I agree that the initiator > of a reauth must prove that he is the same entity with which the > original IKE SA was established. Having the reauth initiator supply > the old SK_d as Yoav suggested would accomplish that. The old SK_d > can be appended to the SPIs in the REAUTH_SA > notification. --=_alternative 005D6FAB882577B5_= Content-Type: text/html; charset="US-ASCII"
A colleague pointed-out that including the old SK_d itself in the REAUTH_SA notification is a bad idea.  A better approach would be to incorporate it into the new AUTH payload.

> RFC 4301 section 4.4.3.4 "How the PAD is Used" says:
>    Child SAs are created based on the exchange of traffic selector
>   payloads, either at the end of the initial IKE exchange or in
>   subsequent CREATE_CHILD_SA exchanges.  The PAD entry for the (now
>   authenticated) IKE peer is used to constrain creation of child SAs;
>   specifically, the PAD entry specifies how the SPD is searched using a
>   traffic selector proposal from a peer.  There are two choices: either
>   the IKE ID asserted by the peer is used to find an SPD entry via its
>   symbolic name, or peer IP addresses asserted in traffic selector
>   payloads are used for SPD lookups based on the remote IP address
>   field portion of an SPD entry.  It is necessary to impose these
>   constraints on creation of child SAs to prevent an authenticated peer
>   from spoofing IDs associated with other, legitimate peers.
>
> Moving the child SAs for a reauthenticated IKE SA could circumvent
> the checking that allows the PAD to constrain the creation of a
> child SA to a particular IKE peer.  So, I agree that the initiator
> of a reauth must prove that he is the same entity with which the
> original IKE SA was established.  Having the reauth initiator supply
> the old SK_d as Yoav suggested would accomplish that.  The old SK_d
> can be appended to the SPIs in the REAUTH_SA
> notification.
 --=_alternative 005D6FAB882577B5_=-- From welterk@us.ibm.com Thu Oct 7 10:26: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 9739F3A6FA0 for ; Thu, 7 Oct 2010 10:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.073 X-Spam-Level: X-Spam-Status: No, score=-6.073 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZ6azg5zJk1Q for ; Thu, 7 Oct 2010 10:26:05 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 2237E3A6F81 for ; Thu, 7 Oct 2010 10:26:05 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o97HHQC4019434 for ; Thu, 7 Oct 2010 11:17:26 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o97HQxbJ220746 for ; Thu, 7 Oct 2010 11:26:59 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o97HQvAu008992 for ; Thu, 7 Oct 2010 11:26:58 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o97HQvqP008969; Thu, 7 Oct 2010 11:26:57 -0600 In-Reply-To: <3C3AC0EB-BBBB-4857-A595-A958E175CD4A@checkpoint.com> References: <3C3AC0EB-BBBB-4857-A595-A958E175CD4A@checkpoint.com> To: Yoav Nir MIME-Version: 1.0 X-KeepSent: CE4B4071:F23CF424-882577B5:005E1700; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Thu, 7 Oct 2010 10:26:56 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 10/07/2010 11:26:57, Serialize complete at 10/07/2010 11:26:57 Content-Type: multipart/alternative; boundary="=_alternative 005FD90F882577B5_=" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 17:26:07 -0000 This is a multipart message in MIME format. --=_alternative 005FD90F882577B5_= Content-Type: text/plain; charset="US-ASCII" Hi Yoav, I made a couple posts before reading this. Sorry about that. Yoav Nir wrote on 10/07/2010 12:48:17 AM: [...] > Hi Keith. > > My responses are below, but first I would like to know if you have > considered a different solution - having an IKE_AUTH exchange in the > middle of the IKE SA lifetime. Suppose the IKE SA has been around > for a couple of hours, and has been used for creating some child > SAs, why not keep it and just pass one or more IKE_AUTH exchanges? Interesting. If support for the new reauth protocol is signaled in the original IKE_AUTH exchange then I think you could do a modified IKE_AUTH exchange in the old IKE SA to accomplish reauthentication. That would eliminate moving the children and having to prove that the reauth initiator is the same entity as he was before. It also would reduce the variety of collision cases substantially. That sounds very attractive. Offhand, I can't think of any reason not to do it. > > I had considered this when making 4478, and the only thing that > "blocked" me was that I couldn't figure out what to sign in the AUTH > payloads. In regular IKE, they sign the IKE_SA_INIT messages, and I > didn't like the idea of storing those for the lifetime of the IKE > SA. Perhaps we could store the contents of the previous AUTH payload > (or a hash thereof) and sign that. Choosing suitable material to sign for a modified IKE_AUTH is not really my strong point. Scott Moonen and Dave Wierbowski are colleagues of mine and I suspect they would have good input here. I'll ask them. > > On Oct 6, 2010, at 11:17 PM, Keith Welter wrote: > > > > > Yoav Nir wrote on 10/05/2010 07:33:33 AM: > > > > > Hi Keith. > > > > > > After reading your draft, I wish I had done this in RFC 4478. > > That's encouraging. Thanks. > > > > > Still, I have some comments. > > > > > > What are the considerations for the responder accepting a re- > authentication? > > > > > > Suppose we have an active IKE SA between Alice and Bob. Now Bob > > > gets a new IKE_SA_INIT request with an N(REAUTH_SA) and the IKE SPIs > > > for the old IKE SA. When should Bob accept? When should Bob > > > decline? What if later (in the IKE_AUTH exchange) the authenticated > > > identity turns out to be Mallory? > > Interesting question. Would you say that the same problem exists > for re-authentication as defined in RFC 5996? > > In RFC 5996, the new IKE SA does not inherit the old child SAs. New > child SAs will be created according to the policy relevant to Mallory. > > > It seems to me that in general there is nothing but local policy > to stop a different IKE peer from establishing a child SA with the > same traffic selectors as an existing child SA. So I wonder what > makes that different from moving an existing child SA to a new IKE > SA with a different peer. Can you describe a problem that would > occur with moving a child SA that would not occur with RFC 5996- > style reauthentication? > > The problem is having a child SA that belongs to Mallory, that is > not allowed by policy (for Mallory). Another problem is one user > getting another user's IP address, because the servers behind the > gateway often rely on IP address for continuation of a session. One > way is that when inheriting the child SAs, the IKE implementation > goes over them, and only transfers those that agree with policy. > That might work for inter-domain, but with remote access, there's > usually no pre-defined policy as to what selectors are allowed for the user. > > As Tero pointed out, re-authenticating implies also inheriting the > assigned IP address, so I really think you need to set rules (or at > least guidance) about the relationship between the old and new > authenticated identity (is "Alice" with a password the same as the > user who presents a certificate with "CN=Alice,OU=Users"? What > about same DN but a different certificate?) > > > > > > > > > The way the draft is now, anyone can probe for the existence of IKE > > > SPIs by sending IKE_SA_INIT requests with arbitrary IKE SPIs in the > > > REAUTH_SA notification. This is not a particularly useful attack, > > > but no need to expose ourselves to it. I think it would be better to > > > move the notifications to the IKE_AUTH exchange. > > Good point about the potential for SPI probing. > > > > My first version (unpublished) of the draft actually had the > REAUTH_SA notification in the IKE_AUTH exchange. There were three > advantages I saw for including the REAUTH_SA notification in the > IKE_SA_INIT exchange instead. The main advantage was that I could > use the presence of the REAUTH_SA notification in the IKE_SA_INIT > request to signal usage of the IKE_AUTH exchange described in the > draft that adds no additional children. Even though the child SA > piggy-backed on the IKE_AUTH exchange doesn't cost any additional > round-trips it does cost additional CPU that is unnecessary. And, > to be tidy, one would also need to delete the old child SA that was > re-negotiated before moving all the remaining children to the new > IKE SA. So, eliminating the piggy-backed child SA this way seemed > like a very attractive enhancement. > > The childless notification can be used for signaling, and I agree > with Yaron, that support for REAUTH_SA can be signaled in the > original IKE_AUTH. > > > > > The second advantage I saw to including the notification in the > IKE_SA_INIT exchange was that it eliminated an obscure collision > case. The collision case was awkward to describe but I still have > the text for it. To be clear, this was written for the version in > which the IKE_AUTH exchange carried the REAUTH_SA notification: > > If a peer receives a request to reauthenticate an IKE SA for which it > > has not yet sent a request to reauthenticate, but has sent the > > IKE_SA_INIT request with intent to reauthenticate, it SHOULD reply as > > usual but SHOULD NOT include the REAUTH_SA notification in the > > IKE_AUTH request that it will send and SHOULD close the new IKE SA it > > creates after it receives the IKE_AUTH response. > > I think you can require never to send a REAUTH_SA if you have > already received one from the peer. If that means leaving a half- > open SA, so be it. RFC 5996 already requires implementations to > handle these cases, and you can reduce them with guidance for > original initiators to re-authenticate earlier than original responders. > > This leaves just the case of both sides having performed the > IKE_SA_INIT, and sending the IKE_AUTH request before either receives > the other IKE_AUTH request. This can be handled by having the one > with lower Initiator SPI win, while the other exchange gets some > error message (no proposal chosen? or a new one?) > > > > > That text hints at the third and final reason. With the REAUTH_SA > notification in the IKE_AUTH exchange, one doesn't know that a new > IKE SA is reauthenticating an old IKE SA until the IKE_AUTH exchange > begins. Alternatively, with the REAUTH_SA in the IKE_SA_INIT > exchange, one knows immediately, from the very first IKE message, > whether or not a given IKE SA is intended to reauthenticate another > IKE SA or not. Whether or not removing this ambiguity is really an > advantage or a disadvantage is debatable I suppose. > > OK. I'll debate for the other side. There's no reason to expose to > eavesdroppers that we're doing a re-authentication. IKE_AUTH is > encrypted, while IKE_SA_INIT is not. > > > > > I'm not sure those three reasons outweigh your SPI probing > concern. I'm assuming there is not already a way to probe for SPIs > without the REAUTH_SA (I did a quick review of RFC 5996 from that > angle and couldn't see another way to accomplish such a probe). If > I could still omit the piggy-backed child SA from the IKE_AUTH > exchange for a reauthentication I would be happy to move the > notification back to the IKE_AUTH exchange where I originally had it. > > > > > Once there, the intuitive logic would be: > > > - If the peer authenticates as other than Alice, deny REAUTH (fail > > > the exchange?) > > > - If authentication fails, ignore it. The old IKE SA remains alive. > > > - If the peer authenticates as Alice, allow the reauth. > > > > > > This leads me to another issue. If the peer authenticates as Alice, > > > we can treat it as an "Alice". Is it OK for "an Alice" to inherit > > > the child SAs of any other "Alice"? Ideally, there is only one > > > "Alice" and if the peer authenticates as "Alice" it may inherit any > > > child SAs belonging to any IKE SA belonging to "Alice", but I think > > > it would be better to somehow tie the old SA to the new SA with non- > > > public information. Perhaps something derived from the SKEYSEED > > > along with SK_d and the rest. > > I'll defer to Yaron's response here though I'd still like to > understand if this issue is really isolated to the proposed movement > of child SAs for reauthentication as I asked above. > > If I connect to work from both computer and my phone, should the > phone be able to "steal" the computer's SAs? If IKE is ever > integrated with NEA work, it might imply moving SAs that were > created with one posture to a host with another posture. Without > NEA, it's not so much a security issue, as it is a networking issue. > > > > > > > > > One final issue. The IKE_AUTH exchange in your draft does not > > > include what's needed for creating new Child SAs. This is not > > > allowed by RFC 5996. There is, however, a soon-to-be-published RFC > > > for this (draft-nir-ipsecme-childless) > > I was aware of this draft. Assuming we conclude that it would be > best to move the REAUTH_SA notification to the IKE_AUTH exchange > then I would want to refer to that document and specify that it's > mechanisms be used to avoid creating an additional child SA when > reauthenticating an IKE SA. However, I'm not clear why the approach > described in the current version of my draft is a not an acceptable > way to specify a childless IKE_AUTH exchange. > > > > > > > > Yoav > > > > > > On Sep 28, 2010, at 10:03 PM, Keith Welter wrote: > > > > > > > > > > > A new version of I-D, draft-welter-ipsecme-ikev2-reauth-00.txt has > > > been successfully submitted by Keith Welter and posted to the > IETF repository. > > > > > > > > Filename: draft-welter-ipsecme-ikev2-reauth > > > > Revision: 00 > > > > Title: Reauthentication > > > Extension for IKEv2 > > > > Creation_date: 2010-09-28 > > > > WG ID: Independent Submission > > > > Number_of_pages: 10 > > > > > > > > Abstract: > > > > This document extends the Internet Key Exchange (IKEv2) Protocol > > > > document [IKEv2]. IKEv2 reauthentication does not scale well when an > > > > IKE SA has multiple Child SAs because each Child SA of the IKE SA to > > > > be reauthenticated must be renegotiated. In addition, > > > > reauthentication is susceptible to the same kinds of exchange > > > > collisions as those that may occur during rekeying. This document > > > > describes a mechanism to detect reauthentication and avoid > > > > renegotiating the Child SAs. In addition, this document describes > > > > proper handling of exchange collisions that may occur during > > > > reauthentication. > > > > > > > > > > > > > > > > The IETF Secretariat. > > > > > > > > > > > > > > > > > > > > > > > > > Scanned by Check Point Total Security Gateway. > > > --=_alternative 005FD90F882577B5_= Content-Type: text/html; charset="US-ASCII"
Hi Yoav,
I made a couple posts before reading this.  Sorry about that.

Yoav Nir <ynir@checkpoint.com> wrote on 10/07/2010 12:48:17 AM:
[...]
> Hi Keith.
>
> My responses are below, but first I would like to know if you have
> considered a different solution - having an IKE_AUTH exchange in the
> middle of the IKE SA lifetime. Suppose the IKE SA has been around
> for a couple of hours, and has been used for creating some child
> SAs, why not keep it and just pass one or more IKE_AUTH exchanges?
Interesting.  If support for the new reauth protocol is signaled in the original IKE_AUTH exchange then I think you could do a modified IKE_AUTH exchange in the old IKE SA to accomplish reauthentication.  That would eliminate moving the children and having to prove that the reauth initiator is the same entity as he was before.  It also would reduce the variety of collision cases substantially.  That sounds very attractive.  Offhand, I can't think of any reason not to do it.

>
> I had considered this when making 4478, and the only thing that
> "blocked" me was that I couldn't figure out what to sign in the AUTH
> payloads. In regular IKE, they sign the IKE_SA_INIT messages, and I
> didn't like the idea of storing those for the lifetime of the IKE
> SA. Perhaps we could store the contents of the previous AUTH payload
> (or a hash thereof) and sign that.
Choosing suitable material to sign for a modified IKE_AUTH is not really my strong point.  Scott Moonen and Dave Wierbowski are colleagues of mine and I suspect they would have good input here.  I'll ask them.

>
> On Oct 6, 2010, at 11:17 PM, Keith Welter wrote:
>
> >
> > Yoav Nir <ynir@checkpoint.com> wrote on 10/05/2010 07:33:33 AM:
> >
> > > Hi Keith.
> > >
> > > After reading your draft, I wish I had done this in RFC 4478.
> > That's encouraging.  Thanks.
> >
> > > Still, I have some comments.
> > >
> > > What are the considerations for the responder accepting a re-
> authentication?
> > >
> > > Suppose we have an active IKE SA between Alice and Bob.  Now Bob
> > > gets a new IKE_SA_INIT request with an N(REAUTH_SA) and the IKE SPIs
> > > for the old IKE SA. When should Bob accept?  When should Bob
> > > decline? What if later (in the IKE_AUTH exchange) the authenticated
> > > identity turns out to be Mallory?
> > Interesting question.  Would you say that the same problem exists
> for re-authentication as defined in RFC 5996?
>
> In RFC 5996, the new IKE SA does not inherit the old child SAs. New
> child SAs will be created according to the policy relevant to Mallory.
>
> >  It seems to me that in general there is nothing but local policy
> to stop a different IKE peer from establishing a child SA with the
> same traffic selectors as an existing child SA.  So I wonder what
> makes that different from moving an existing child SA to a new IKE
> SA with a different peer.  Can you describe a problem that would
> occur with moving a child SA that would not occur with RFC 5996-
> style reauthentication?
>
> The problem is having a child SA that belongs to Mallory, that is
> not allowed by policy (for Mallory).  Another problem is one user
> getting another user's IP address, because the servers behind the
> gateway often rely on IP address for continuation of a session. One
> way is that when inheriting the child SAs, the IKE implementation
> goes over them, and only transfers those that agree with policy.
> That might work for inter-domain, but with remote access, there's
> usually no pre-defined policy as to what selectors are allowed for the user.
>
> As Tero pointed out, re-authenticating implies also inheriting the
> assigned IP address, so I really think you need to set rules (or at
> least guidance) about the relationship between the old and new
> authenticated identity (is "Alice" with a password the same as the
> user who presents a certificate with "CN=Alice,OU=Users"?  What
> about same DN but a different certificate?)
>
> >
> > >
> > > The way the draft is now, anyone can probe for the existence of IKE
> > > SPIs by sending IKE_SA_INIT requests with arbitrary IKE SPIs in the
> > > REAUTH_SA notification. This is not a particularly useful attack,
> > > but no need to expose ourselves to it. I think it would be better to
> > > move the notifications to the IKE_AUTH exchange.
> > Good point about the potential for SPI probing.  
> >
> > My first version (unpublished) of the draft actually had the
> REAUTH_SA notification in the IKE_AUTH exchange.  There were three
> advantages I saw for including the REAUTH_SA notification in the
> IKE_SA_INIT exchange instead.  The main advantage was that I could
> use the presence of the REAUTH_SA notification in the IKE_SA_INIT
> request to signal usage of the IKE_AUTH exchange described in the
> draft that adds no additional children.  Even though the child SA
> piggy-backed on the IKE_AUTH exchange doesn't cost any additional
> round-trips it does cost additional CPU that is unnecessary.  And,
> to be tidy, one would also need to delete the old child SA that was
> re-negotiated before moving all the remaining children to the new
> IKE SA.  So, eliminating the piggy-backed child SA this way seemed
> like a very attractive enhancement.
>
> The childless notification can be used for signaling, and I agree
> with Yaron, that support for REAUTH_SA can be signaled in the
> original IKE_AUTH.
>
> >
> > The second advantage I saw to including the notification in the
> IKE_SA_INIT exchange was that it eliminated an obscure collision
> case.  The collision case was awkward to describe but I still have
> the text for it.  To be clear, this was written for the version in
> which the IKE_AUTH exchange carried the REAUTH_SA notification:
> >    If a peer receives a request to reauthenticate an IKE SA for which it
> >    has not yet sent a request to reauthenticate, but has sent the
> >    IKE_SA_INIT request with intent to reauthenticate, it SHOULD reply as
> >    usual but SHOULD NOT include the REAUTH_SA notification in the
> >    IKE_AUTH request that it will send and SHOULD close the new IKE SA it
> >    creates after it receives the IKE_AUTH response.
>
> I think you can require never to send a REAUTH_SA if you have
> already received one from the peer. If that means leaving a half-
> open SA, so be it. RFC 5996 already requires implementations to
> handle these cases, and you can reduce them with guidance for
> original initiators to re-authenticate earlier than original responders.
>
> This leaves just the case of both sides having performed the
> IKE_SA_INIT, and sending the IKE_AUTH request before either receives
> the other IKE_AUTH request. This can be handled by having the one
> with lower Initiator SPI win, while the other exchange gets some
> error message (no proposal chosen?  or a new one?)
>
> >
> > That text hints at the third and final reason.  With the REAUTH_SA
> notification in the IKE_AUTH exchange, one doesn't know that a new
> IKE SA is reauthenticating an old IKE SA until the IKE_AUTH exchange
> begins.  Alternatively, with the REAUTH_SA in the IKE_SA_INIT
> exchange, one knows immediately, from the very first IKE message,
> whether or not a given IKE SA is intended to reauthenticate another
> IKE SA or not.  Whether or not removing this ambiguity is really an
> advantage or a disadvantage is debatable I suppose.
>
> OK. I'll debate for the other side. There's no reason to expose to
> eavesdroppers that we're doing a re-authentication. IKE_AUTH is
> encrypted, while IKE_SA_INIT is not.
>
> >
> > I'm not sure those three reasons outweigh your SPI probing
> concern.  I'm assuming there is not already a way to probe for SPIs
> without the REAUTH_SA (I did a quick review of RFC 5996 from that
> angle and couldn't see another way to accomplish such a probe).  If
> I could still omit the piggy-backed child SA from the IKE_AUTH
> exchange for a reauthentication I would be happy to move the
> notification back to the IKE_AUTH exchange where I originally had it.
> >
> > > Once there, the intuitive logic would be:
> > >  - If the peer authenticates as other than Alice, deny REAUTH (fail
> > > the exchange?)
> > >  - If authentication fails, ignore it. The old IKE SA remains alive.
> > >  - If the peer authenticates as Alice, allow the reauth.
> > >
> > > This leads me to another issue. If the peer authenticates as Alice,
> > > we can treat it as an "Alice". Is it OK for "an Alice" to inherit
> > > the child SAs of any other "Alice"?  Ideally, there is only one
> > > "Alice" and if the peer authenticates as "Alice" it may inherit any
> > > child SAs belonging to any IKE SA belonging to "Alice", but I think
> > > it would be better to somehow tie the old SA to the new SA with non-
> > > public information. Perhaps something derived from the SKEYSEED
> > > along with SK_d and the rest.
> > I'll defer to Yaron's response here though I'd still like to
> understand if this issue is really isolated to the proposed movement
> of child SAs for reauthentication as I asked above.
>
> If I connect to work from both computer and my phone, should the
> phone be able to "steal" the computer's SAs? If IKE is ever
> integrated with NEA work, it might imply moving SAs that were
> created with one posture to a host with another posture. Without
> NEA, it's not so much a security issue, as it is a networking issue.
>
> >
> > >
> > > One final issue. The IKE_AUTH exchange in your draft does not
> > > include what's needed for creating new Child SAs. This is not
> > > allowed by RFC 5996. There is, however, a soon-to-be-published RFC
> > > for this (draft-nir-ipsecme-childless)
> > I was aware of this draft.  Assuming we conclude that it would be
> best to move the REAUTH_SA notification to the IKE_AUTH exchange
> then I would want to refer to that document and specify that it's
> mechanisms be used to avoid creating an additional child SA when
> reauthenticating an IKE SA.  However, I'm not clear why the approach
> described in the current version of my draft is a not an acceptable
> way to specify a childless IKE_AUTH exchange.
> >
> > >
> > > Yoav
> > >
> > > On Sep 28, 2010, at 10:03 PM, Keith Welter wrote:
> > >
> > > >
> > > > A new version of I-D, draft-welter-ipsecme-ikev2-reauth-00.txt has
> > > been successfully submitted by Keith Welter and posted to the
> IETF repository.
> > > >
> > > > Filename:                  draft-welter-ipsecme-ikev2-reauth
> > > > Revision:                  00
> > > > Title:                                   Reauthentication
> > > Extension for IKEv2
> > > > Creation_date:                  2010-09-28
> > > > WG ID:                                   Independent Submission
> > > > Number_of_pages: 10
> > > >
> > > > Abstract:
> > > > This document extends the Internet Key Exchange (IKEv2) Protocol
> > > > document [IKEv2].  IKEv2 reauthentication does not scale well when an
> > > > IKE SA has multiple Child SAs because each Child SA of the IKE SA to
> > > > be reauthenticated must be renegotiated.  In addition,
> > > > reauthentication is susceptible to the same kinds of exchange
> > > > collisions as those that may occur during rekeying.  This document
> > > > describes a mechanism to detect reauthentication and avoid
> > > > renegotiating the Child SAs.  In addition, this document describes
> > > > proper handling of exchange collisions that may occur during
> > > > reauthentication.
> > > >                                                                        
> > > >
> > > >
> > > > The IETF Secretariat.
> > > >
> > > >
> > > >
> > > > <ATT00001..txt>
> > >
> >
> >
> > Scanned by Check Point Total Security Gateway.
> >
>
--=_alternative 005FD90F882577B5_=-- From ynir@checkpoint.com Thu Oct 7 12:25: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 F37783A702E for ; Thu, 7 Oct 2010 12:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 iwCiSYYoMkrS for ; Thu, 7 Oct 2010 12:25:36 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 90B563A701E for ; Thu, 7 Oct 2010 12:25:35 -0700 (PDT) X-CheckPoint: {4CAE1DC5-10000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o97JQbJm021884; Thu, 7 Oct 2010 21:26:37 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 7 Oct 2010 21:26:37 +0200 From: Yoav Nir To: Keith Welter Date: Thu, 7 Oct 2010 21:26:36 +0200 Thread-Topic: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 Thread-Index: ActmVY8htLb1szvERxmxQ+X65/reBg== Message-ID: <3B06F293-55D4-414C-8A49-6CC69C0DBFEF@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 19:25:37 -0000 I was not suggesting to use SK_d itself.=20 RFC 5996 says this: {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } =3D prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) I suggest replaceing/augmenting it with this: {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr | SK_ri | SK_rr} =3D prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) Where SK_ri and SK_rr are x number of bits each (128? 256? same as the SK_d= ?) and these can be used for re-authentication later. On Oct 7, 2010, at 7:00 PM, Keith Welter wrote: >=20 > A colleague pointed-out that including the old SK_d itself in the REAUTH_= SA notification is a bad idea. A better approach would be to incorporate i= t into the new AUTH payload.=20 >=20 > > RFC 4301 section 4.4.3.4 "How the PAD is Used" says:=20 > > Child SAs are created based on the exchange of traffic selector > > payloads, either at the end of the initial IKE exchange or in > > subsequent CREATE_CHILD_SA exchanges. The PAD entry for the (now > > authenticated) IKE peer is used to constrain creation of child SAs; > > specifically, the PAD entry specifies how the SPD is searched using a > > traffic selector proposal from a peer. There are two choices: either > > the IKE ID asserted by the peer is used to find an SPD entry via its > > symbolic name, or peer IP addresses asserted in traffic selector > > payloads are used for SPD lookups based on the remote IP address > > field portion of an SPD entry. It is necessary to impose these > > constraints on creation of child SAs to prevent an authenticated peer > > from spoofing IDs associated with other, legitimate peers. > >=20 > > Moving the child SAs for a reauthenticated IKE SA could circumvent=20 > > the checking that allows the PAD to constrain the creation of a=20 > > child SA to a particular IKE peer. So, I agree that the initiator=20 > > of a reauth must prove that he is the same entity with which the=20 > > original IKE SA was established. Having the reauth initiator supply > > the old SK_d as Yoav suggested would accomplish that. The old SK_d=20 > > can be appended to the SPIs in the REAUTH_SA=20 > > notification. > From welterk@us.ibm.com Thu Oct 7 13:49:27 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 4B64C3A7020 for ; Thu, 7 Oct 2010 13:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.113 X-Spam-Level: X-Spam-Status: No, score=-4.113 tagged_above=-999 required=5 tests=[AWL=-1.515, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ard+O39Bc2SZ for ; Thu, 7 Oct 2010 13:49:24 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id E33643A700E for ; Thu, 7 Oct 2010 13:49:23 -0700 (PDT) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o97KmBwM005062 for ; Thu, 7 Oct 2010 14:48:11 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o97KoILo124836 for ; Thu, 7 Oct 2010 14:50:18 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o97Ks7QO022007 for ; Thu, 7 Oct 2010 14:54:07 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o97Ks7bD022001; Thu, 7 Oct 2010 14:54:07 -0600 In-Reply-To: <3B06F293-55D4-414C-8A49-6CC69C0DBFEF@checkpoint.com> References: <3B06F293-55D4-414C-8A49-6CC69C0DBFEF@checkpoint.com> To: Yoav Nir MIME-Version: 1.0 X-KeepSent: BC129828:367A788D-882577B5:006F9F5C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Thu, 7 Oct 2010 13:50:17 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 10/07/2010 14:50:17, Serialize complete at 10/07/2010 14:50:17 Content-Type: multipart/alternative; boundary="=_alternative 007276D4882577B5_=" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 20:49:27 -0000 This is a multipart message in MIME format. --=_alternative 007276D4882577B5_= Content-Type: text/plain; charset="US-ASCII" Yoav Nir wrote on 10/07/2010 12:26:36 PM: > I was not suggesting to use SK_d itself. Sorry, I misread your note. You clearly did not suggest using SK_d itself. > > RFC 5996 says this: > > {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } > = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) > > > I suggest replaceing/augmenting it with this: > > {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr | SK_ri | SK_rr} > = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) > > Where SK_ri and SK_rr are x number of bits each (128? 256? same as > the SK_d?) and these can be used for re-authentication later. First, to level-set, I assume that we are talking about key generation during an IKE_AUTH that occurs on a new IKE SA rather than the alternative approach you described of doing a subsequent IKE_AUTH exchange on the original IKE SA. I'm confused by what you suggest here though. Wouldn't the augmentation go in the data to which prf+ is applied, rather than the output? For example: {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } << new keys >> = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr | SK_ri | SK_rr ) << augmented data from which to derive keys >> Is that what you meant? It seems to me that any piece of keying material from the old IKE SA that both sides incorporate into the key generation for the new IKE SA ought to be sufficient. So here is another option to consider: {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } << new keys >> = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr | prior SK_d ) << augmented data from which to derive keys >> > > > On Oct 7, 2010, at 7:00 PM, Keith Welter wrote: > > > > > A colleague pointed-out that including the old SK_d itself in the > REAUTH_SA notification is a bad idea. A better approach would be to > incorporate it into the new AUTH payload. > > > > > RFC 4301 section 4.4.3.4 "How the PAD is Used" says: > > > Child SAs are created based on the exchange of traffic selector > > > payloads, either at the end of the initial IKE exchange or in > > > subsequent CREATE_CHILD_SA exchanges. The PAD entry for the (now > > > authenticated) IKE peer is used to constrain creation of child SAs; > > > specifically, the PAD entry specifies how the SPD is searched using a > > > traffic selector proposal from a peer. There are two choices: either > > > the IKE ID asserted by the peer is used to find an SPD entry via its > > > symbolic name, or peer IP addresses asserted in traffic selector > > > payloads are used for SPD lookups based on the remote IP address > > > field portion of an SPD entry. It is necessary to impose these > > > constraints on creation of child SAs to prevent an authenticated peer > > > from spoofing IDs associated with other, legitimate peers. > > > > > > Moving the child SAs for a reauthenticated IKE SA could circumvent > > > the checking that allows the PAD to constrain the creation of a > > > child SA to a particular IKE peer. So, I agree that the initiator > > > of a reauth must prove that he is the same entity with which the > > > original IKE SA was established. Having the reauth initiator supply > > > the old SK_d as Yoav suggested would accomplish that. The old SK_d > > > can be appended to the SPIs in the REAUTH_SA > > > notification. > > > --=_alternative 007276D4882577B5_= Content-Type: text/html; charset="US-ASCII"
Yoav Nir <ynir@checkpoint.com> wrote on 10/07/2010 12:26:36 PM:
> I was not suggesting to use  SK_d itself.
Sorry, I misread your note.  You clearly did not suggest using SK_d itself.

>
> RFC 5996 says this:
>
>    {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
>                    = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
>
>
> I suggest replaceing/augmenting it with this:
>
>    {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr | SK_ri | SK_rr}
>                    = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
>
> Where SK_ri and SK_rr are x number of bits each (128? 256? same as
> the SK_d?) and these can be used for re-authentication later.
First, to level-set, I assume that we are talking about key generation during an IKE_AUTH that occurs on a new IKE SA rather than the alternative approach you described of doing a subsequent IKE_AUTH exchange on the original IKE SA.  I'm confused by what you suggest here though.  Wouldn't the augmentation go in the data to which prf+ is applied, rather than the output?  For example:
    {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } << new keys >>
   = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr | SK_ri | SK_rr ) << augmented data from which to derive keys >>
Is that what you meant?  It seems to me that any piece of keying material from the old IKE SA that both sides incorporate into the key generation for the new IKE SA ought to be sufficient.  So here is another option to consider:
    {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } << new keys >>
   = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr | prior SK_d ) << augmented data from which to derive keys >>

>
>
> On Oct 7, 2010, at 7:00 PM, Keith Welter wrote:
>
> >
> > A colleague pointed-out that including the old SK_d itself in the
> REAUTH_SA notification is a bad idea.  A better approach would be to
> incorporate it into the new AUTH payload.
> >
> > > RFC 4301 section 4.4.3.4 "How the PAD is Used" says:
> > >    Child SAs are created based on the exchange of traffic selector
> > >   payloads, either at the end of the initial IKE exchange or in
> > >   subsequent CREATE_CHILD_SA exchanges.  The PAD entry for the (now
> > >   authenticated) IKE peer is used to constrain creation of child SAs;
> > >   specifically, the PAD entry specifies how the SPD is searched using a
> > >   traffic selector proposal from a peer.  There are two choices: either
> > >   the IKE ID asserted by the peer is used to find an SPD entry via its
> > >   symbolic name, or peer IP addresses asserted in traffic selector
> > >   payloads are used for SPD lookups based on the remote IP address
> > >   field portion of an SPD entry.  It is necessary to impose these
> > >   constraints on creation of child SAs to prevent an authenticated peer
> > >   from spoofing IDs associated with other, legitimate peers.
> > >
> > > Moving the child SAs for a reauthenticated IKE SA could circumvent
> > > the checking that allows the PAD to constrain the creation of a
> > > child SA to a particular IKE peer.  So, I agree that the initiator
> > > of a reauth must prove that he is the same entity with which the
> > > original IKE SA was established.  Having the reauth initiator supply
> > > the old SK_d as Yoav suggested would accomplish that.  The old SK_d
> > > can be appended to the SPIs in the REAUTH_SA
> > > notification.
> > <ATT00001..txt>
>
--=_alternative 007276D4882577B5_=-- From welterk@us.ibm.com Thu Oct 7 14:14:31 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 0F53C3A7134 for ; Thu, 7 Oct 2010 14:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.005 X-Spam-Level: X-Spam-Status: No, score=-6.005 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4z-IPgCHXddV for ; Thu, 7 Oct 2010 14:14:27 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id B70A23A6FA9 for ; Thu, 7 Oct 2010 14:14:26 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o97L5uta001004 for ; Thu, 7 Oct 2010 15:05:56 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id o97LFTGL228442 for ; Thu, 7 Oct 2010 15:15:29 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o97LFSSx004975 for ; Thu, 7 Oct 2010 15:15:29 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o97LFSKQ004954; Thu, 7 Oct 2010 15:15:28 -0600 In-Reply-To: References: <3C3AC0EB-BBBB-4857-A595-A958E175CD4A@checkpoint.com> To: "ipsec@ietf.org" MIME-Version: 1.0 X-KeepSent: B0865423:D32F4537-882577B5:0073F719; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Thu, 7 Oct 2010 14:15:27 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 10/07/2010 15:15:28, Serialize complete at 10/07/2010 15:15:28 Content-Type: multipart/alternative; boundary="=_alternative 0074C4EC882577B5_=" Cc: Yoav Nir Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 21:14:31 -0000 This is a multipart message in MIME format. --=_alternative 0074C4EC882577B5_= Content-Type: text/plain; charset="US-ASCII" Keith Welter wrote on 10/07/2010 10:26:56 AM: [...] > Yoav Nir wrote on 10/07/2010 12:48:17 AM: > [...] > > Hi Keith. > > > > My responses are below, but first I would like to know if you have > > considered a different solution - having an IKE_AUTH exchange in the > > middle of the IKE SA lifetime. Suppose the IKE SA has been around > > for a couple of hours, and has been used for creating some child > > SAs, why not keep it and just pass one or more IKE_AUTH exchanges? > Interesting. If support for the new reauth protocol is signaled in > the original IKE_AUTH exchange then I think you could do a modified > IKE_AUTH exchange in the old IKE SA to accomplish reauthentication. > That would eliminate moving the children and having to prove that > the reauth initiator is the same entity as he was before. It also > would reduce the variety of collision cases substantially. That > sounds very attractive. Offhand, I can't think of any reason not to do it. Actually, one down-side does come to mind. RFC5996-style reauthentication and the kind described in my draft both allow the IKE SA attributes such as the encryption algorithm to be changed by virtue of the new IKE_SA_INIT exchange. That capability would be lost with IKE_AUTH on the old IKE SA. I wouldn't want to take that capability away. To affect an IKE SA policy change you'd have to deactivate/reactivate. > > > > > I had considered this when making 4478, and the only thing that > > "blocked" me was that I couldn't figure out what to sign in the AUTH > > payloads. In regular IKE, they sign the IKE_SA_INIT messages, and I > > didn't like the idea of storing those for the lifetime of the IKE > > SA. Perhaps we could store the contents of the previous AUTH payload > > (or a hash thereof) and sign that. > Choosing suitable material to sign for a modified IKE_AUTH is not > really my strong point. Scott Moonen and Dave Wierbowski are > colleagues of mine and I suspect they would have good input here. > I'll ask them. Scott responded and said, "I can't think of a problem with Yoav's idea of signing the previous Auth payload." > > > > > On Oct 6, 2010, at 11:17 PM, Keith Welter wrote: > > > > > > > > Yoav Nir wrote on 10/05/2010 07:33:33 AM: > > > > > > > Hi Keith. > > > > > > > > After reading your draft, I wish I had done this in RFC 4478. > > > That's encouraging. Thanks. > > > > > > > Still, I have some comments. > > > > > > > > What are the considerations for the responder accepting a re- > > authentication? > > > > > > > > Suppose we have an active IKE SA between Alice and Bob. Now Bob > > > > gets a new IKE_SA_INIT request with an N(REAUTH_SA) and the IKE SPIs > > > > for the old IKE SA. When should Bob accept? When should Bob > > > > decline? What if later (in the IKE_AUTH exchange) the authenticated > > > > identity turns out to be Mallory? > > > Interesting question. Would you say that the same problem exists > > for re-authentication as defined in RFC 5996? > > > > In RFC 5996, the new IKE SA does not inherit the old child SAs. New > > child SAs will be created according to the policy relevant to Mallory. > > > > > It seems to me that in general there is nothing but local policy > > to stop a different IKE peer from establishing a child SA with the > > same traffic selectors as an existing child SA. So I wonder what > > makes that different from moving an existing child SA to a new IKE > > SA with a different peer. Can you describe a problem that would > > occur with moving a child SA that would not occur with RFC 5996- > > style reauthentication? > > > > The problem is having a child SA that belongs to Mallory, that is > > not allowed by policy (for Mallory). Another problem is one user > > getting another user's IP address, because the servers behind the > > gateway often rely on IP address for continuation of a session. One > > way is that when inheriting the child SAs, the IKE implementation > > goes over them, and only transfers those that agree with policy. > > That might work for inter-domain, but with remote access, there's > > usually no pre-defined policy as to what selectors are allowed forthe user. > > > > As Tero pointed out, re-authenticating implies also inheriting the > > assigned IP address, so I really think you need to set rules (or at > > least guidance) about the relationship between the old and new > > authenticated identity (is "Alice" with a password the same as the > > user who presents a certificate with "CN=Alice,OU=Users"? What > > about same DN but a different certificate?) > > > > > > > > > > > > > The way the draft is now, anyone can probe for the existence of IKE > > > > SPIs by sending IKE_SA_INIT requests with arbitrary IKE SPIs in the > > > > REAUTH_SA notification. This is not a particularly useful attack, > > > > but no need to expose ourselves to it. I think it would be better to > > > > move the notifications to the IKE_AUTH exchange. > > > Good point about the potential for SPI probing. > > > > > > My first version (unpublished) of the draft actually had the > > REAUTH_SA notification in the IKE_AUTH exchange. There were three > > advantages I saw for including the REAUTH_SA notification in the > > IKE_SA_INIT exchange instead. The main advantage was that I could > > use the presence of the REAUTH_SA notification in the IKE_SA_INIT > > request to signal usage of the IKE_AUTH exchange described in the > > draft that adds no additional children. Even though the child SA > > piggy-backed on the IKE_AUTH exchange doesn't cost any additional > > round-trips it does cost additional CPU that is unnecessary. And, > > to be tidy, one would also need to delete the old child SA that was > > re-negotiated before moving all the remaining children to the new > > IKE SA. So, eliminating the piggy-backed child SA this way seemed > > like a very attractive enhancement. > > > > The childless notification can be used for signaling, and I agree > > with Yaron, that support for REAUTH_SA can be signaled in the > > original IKE_AUTH. > > > > > > > > The second advantage I saw to including the notification in the > > IKE_SA_INIT exchange was that it eliminated an obscure collision > > case. The collision case was awkward to describe but I still have > > the text for it. To be clear, this was written for the version in > > which the IKE_AUTH exchange carried the REAUTH_SA notification: > > > If a peer receives a request to reauthenticate an IKE SA for which it > > > has not yet sent a request to reauthenticate, but has sent the > > > IKE_SA_INIT request with intent to reauthenticate, it SHOULD reply as > > > usual but SHOULD NOT include the REAUTH_SA notification in the > > > IKE_AUTH request that it will send and SHOULD close the new IKE SA it > > > creates after it receives the IKE_AUTH response. > > > > I think you can require never to send a REAUTH_SA if you have > > already received one from the peer. If that means leaving a half- > > open SA, so be it. RFC 5996 already requires implementations to > > handle these cases, and you can reduce them with guidance for > > original initiators to re-authenticate earlier than original responders. > > > > This leaves just the case of both sides having performed the > > IKE_SA_INIT, and sending the IKE_AUTH request before either receives > > the other IKE_AUTH request. This can be handled by having the one > > with lower Initiator SPI win, while the other exchange gets some > > error message (no proposal chosen? or a new one?) > > > > > > > > That text hints at the third and final reason. With the REAUTH_SA > > notification in the IKE_AUTH exchange, one doesn't know that a new > > IKE SA is reauthenticating an old IKE SA until the IKE_AUTH exchange > > begins. Alternatively, with the REAUTH_SA in the IKE_SA_INIT > > exchange, one knows immediately, from the very first IKE message, > > whether or not a given IKE SA is intended to reauthenticate another > > IKE SA or not. Whether or not removing this ambiguity is really an > > advantage or a disadvantage is debatable I suppose. > > > > OK. I'll debate for the other side. There's no reason to expose to > > eavesdroppers that we're doing a re-authentication. IKE_AUTH is > > encrypted, while IKE_SA_INIT is not. > > > > > > > > I'm not sure those three reasons outweigh your SPI probing > > concern. I'm assuming there is not already a way to probe for SPIs > > without the REAUTH_SA (I did a quick review of RFC 5996 from that > > angle and couldn't see another way to accomplish such a probe). If > > I could still omit the piggy-backed child SA from the IKE_AUTH > > exchange for a reauthentication I would be happy to move the > > notification back to the IKE_AUTH exchange where I originally had it. > > > > > > > Once there, the intuitive logic would be: > > > > - If the peer authenticates as other than Alice, deny REAUTH (fail > > > > the exchange?) > > > > - If authentication fails, ignore it. The old IKE SA remains alive. > > > > - If the peer authenticates as Alice, allow the reauth. > > > > > > > > This leads me to another issue. If the peer authenticates as Alice, > > > > we can treat it as an "Alice". Is it OK for "an Alice" to inherit > > > > the child SAs of any other "Alice"? Ideally, there is only one > > > > "Alice" and if the peer authenticates as "Alice" it may inherit any > > > > child SAs belonging to any IKE SA belonging to "Alice", but I think > > > > it would be better to somehow tie the old SA to the new SA with non- > > > > public information. Perhaps something derived from the SKEYSEED > > > > along with SK_d and the rest. > > > I'll defer to Yaron's response here though I'd still like to > > understand if this issue is really isolated to the proposed movement > > of child SAs for reauthentication as I asked above. > > > > If I connect to work from both computer and my phone, should the > > phone be able to "steal" the computer's SAs? If IKE is ever > > integrated with NEA work, it might imply moving SAs that were > > created with one posture to a host with another posture. Without > > NEA, it's not so much a security issue, as it is a networking issue. > > > > > > > > > > > > > One final issue. The IKE_AUTH exchange in your draft does not > > > > include what's needed for creating new Child SAs. This is not > > > > allowed by RFC 5996. There is, however, a soon-to-be-published RFC > > > > for this (draft-nir-ipsecme-childless) > > > I was aware of this draft. Assuming we conclude that it would be > > best to move the REAUTH_SA notification to the IKE_AUTH exchange > > then I would want to refer to that document and specify that it's > > mechanisms be used to avoid creating an additional child SA when > > reauthenticating an IKE SA. However, I'm not clear why the approach > > described in the current version of my draft is a not an acceptable > > way to specify a childless IKE_AUTH exchange. > > > > > > > > > > > Yoav > > > > > > > > On Sep 28, 2010, at 10:03 PM, Keith Welter wrote: > > > > > > > > > > > > > > A new version of I-D, draft-welter-ipsecme-ikev2-reauth-00.txt has > > > > been successfully submitted by Keith Welter and posted to the > > IETF repository. > > > > > > > > > > Filename: draft-welter-ipsecme-ikev2-reauth > > > > > Revision: 00 > > > > > Title: Reauthentication > > > > Extension for IKEv2 > > > > > Creation_date: 2010-09-28 > > > > > WG ID: Independent Submission > > > > > Number_of_pages: 10 > > > > > > > > > > Abstract: > > > > > This document extends the Internet Key Exchange (IKEv2) Protocol > > > > > document [IKEv2]. IKEv2 reauthentication does not scale well when an > > > > > IKE SA has multiple Child SAs because each Child SA of the IKE SA to > > > > > be reauthenticated must be renegotiated. In addition, > > > > > reauthentication is susceptible to the same kinds of exchange > > > > > collisions as those that may occur during rekeying. This document > > > > > describes a mechanism to detect reauthentication and avoid > > > > > renegotiating the Child SAs. In addition, this document describes > > > > > proper handling of exchange collisions that may occur during > > > > > reauthentication. > > > > > > > > > > > > > > > > > > > > The IETF Secretariat. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Scanned by Check Point Total Security Gateway. > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 0074C4EC882577B5_= Content-Type: text/html; charset="US-ASCII"
Keith Welter <welterk@us.ibm.com> wrote on 10/07/2010 10:26:56 AM:
[...]
> Yoav Nir <ynir@checkpoint.com> wrote on 10/07/2010 12:48:17 AM:
> [...]
> > Hi Keith.
> >
> > My responses are below, but first I would like to know if you have
> > considered a different solution - having an IKE_AUTH exchange in the
> > middle of the IKE SA lifetime. Suppose the IKE SA has been around
> > for a couple of hours, and has been used for creating some child
> > SAs, why not keep it and just pass one or more IKE_AUTH exchanges?
> Interesting.  If support for the new reauth protocol is signaled in
> the original IKE_AUTH exchange then I think you could do a modified
> IKE_AUTH exchange in the old IKE SA to accomplish reauthentication.
> That would eliminate moving the children and having to prove that
> the reauth initiator is the same entity as he was before.  It also
> would reduce the variety of collision cases substantially.  That
> sounds very attractive.  Offhand, I can't think of any reason not to do it.
Actually, one down-side does come to mind.  RFC5996-style reauthentication and the kind described in my draft both allow the IKE SA attributes such as the encryption algorithm to be changed by virtue of the new IKE_SA_INIT exchange.  That capability would be lost with IKE_AUTH on the old IKE SA.  I wouldn't want to take that capability away.  To affect an IKE SA policy change you'd have to deactivate/reactivate.  

>
> >
> > I had considered this when making 4478, and the only thing that
> > "blocked" me was that I couldn't figure out what to sign in the AUTH
> > payloads. In regular IKE, they sign the IKE_SA_INIT messages, and I
> > didn't like the idea of storing those for the lifetime of the IKE
> > SA. Perhaps we could store the contents of the previous AUTH payload
> > (or a hash thereof) and sign that.
> Choosing suitable material to sign for a modified IKE_AUTH is not
> really my strong point.  Scott Moonen and Dave Wierbowski are
> colleagues of mine and I suspect they would have good input here.  
> I'll ask them.
Scott responded and said, "I can't think of a problem with Yoav's idea of signing the previous Auth payload."

>
> >
> > On Oct 6, 2010, at 11:17 PM, Keith Welter wrote:
> >
> > >
> > > Yoav Nir <ynir@checkpoint.com> wrote on 10/05/2010 07:33:33 AM:
> > >
> > > > Hi Keith.
> > > >
> > > > After reading your draft, I wish I had done this in RFC 4478.
> > > That's encouraging.  Thanks.
> > >
> > > > Still, I have some comments.
> > > >
> > > > What are the considerations for the responder accepting a re-
> > authentication?
> > > >
> > > > Suppose we have an active IKE SA between Alice and Bob.  Now Bob
> > > > gets a new IKE_SA_INIT request with an N(REAUTH_SA) and the IKE SPIs
> > > > for the old IKE SA. When should Bob accept?  When should Bob
> > > > decline? What if later (in the IKE_AUTH exchange) the authenticated
> > > > identity turns out to be Mallory?
> > > Interesting question.  Would you say that the same problem exists
> > for re-authentication as defined in RFC 5996?
> >
> > In RFC 5996, the new IKE SA does not inherit the old child SAs. New
> > child SAs will be created according to the policy relevant to Mallory.
> >
> > >  It seems to me that in general there is nothing but local policy
> > to stop a different IKE peer from establishing a child SA with the
> > same traffic selectors as an existing child SA.  So I wonder what
> > makes that different from moving an existing child SA to a new IKE
> > SA with a different peer.  Can you describe a problem that would
> > occur with moving a child SA that would not occur with RFC 5996-
> > style reauthentication?
> >
> > The problem is having a child SA that belongs to Mallory, that is
> > not allowed by policy (for Mallory).  Another problem is one user
> > getting another user's IP address, because the servers behind the
> > gateway often rely on IP address for continuation of a session. One
> > way is that when inheriting the child SAs, the IKE implementation
> > goes over them, and only transfers those that agree with policy.
> > That might work for inter-domain, but with remote access, there's
> > usually no pre-defined policy as to what selectors are allowed forthe user.
> >
> > As Tero pointed out, re-authenticating implies also inheriting the
> > assigned IP address, so I really think you need to set rules (or at
> > least guidance) about the relationship between the old and new
> > authenticated identity (is "Alice" with a password the same as the
> > user who presents a certificate with "CN=Alice,OU=Users"?  What
> > about same DN but a different certificate?)
> >
> > >
> > > >
> > > > The way the draft is now, anyone can probe for the existence of IKE
> > > > SPIs by sending IKE_SA_INIT requests with arbitrary IKE SPIs in the
> > > > REAUTH_SA notification. This is not a particularly useful attack,
> > > > but no need to expose ourselves to it. I think it would be better to
> > > > move the notifications to the IKE_AUTH exchange.
> > > Good point about the potential for SPI probing.  
> > >
> > > My first version (unpublished) of the draft actually had the
> > REAUTH_SA notification in the IKE_AUTH exchange.  There were three
> > advantages I saw for including the REAUTH_SA notification in the
> > IKE_SA_INIT exchange instead.  The main advantage was that I could
> > use the presence of the REAUTH_SA notification in the IKE_SA_INIT
> > request to signal usage of the IKE_AUTH exchange described in the
> > draft that adds no additional children.  Even though the child SA
> > piggy-backed on the IKE_AUTH exchange doesn't cost any additional
> > round-trips it does cost additional CPU that is unnecessary.  And,
> > to be tidy, one would also need to delete the old child SA that was
> > re-negotiated before moving all the remaining children to the new
> > IKE SA.  So, eliminating the piggy-backed child SA this way seemed
> > like a very attractive enhancement.
> >
> > The childless notification can be used for signaling, and I agree
> > with Yaron, that support for REAUTH_SA can be signaled in the
> > original IKE_AUTH.
> >
> > >
> > > The second advantage I saw to including the notification in the
> > IKE_SA_INIT exchange was that it eliminated an obscure collision
> > case.  The collision case was awkward to describe but I still have
> > the text for it.  To be clear, this was written for the version in
> > which the IKE_AUTH exchange carried the REAUTH_SA notification:
> > >    If a peer receives a request to reauthenticate an IKE SA for which it
> > >    has not yet sent a request to reauthenticate, but has sent the
> > >    IKE_SA_INIT request with intent to reauthenticate, it SHOULD reply as
> > >    usual but SHOULD NOT include the REAUTH_SA notification in the
> > >    IKE_AUTH request that it will send and SHOULD close the new IKE SA it
> > >    creates after it receives the IKE_AUTH response.
> >
> > I think you can require never to send a REAUTH_SA if you have
> > already received one from the peer. If that means leaving a half-
> > open SA, so be it. RFC 5996 already requires implementations to
> > handle these cases, and you can reduce them with guidance for
> > original initiators to re-authenticate earlier than original responders.
> >
> > This leaves just the case of both sides having performed the
> > IKE_SA_INIT, and sending the IKE_AUTH request before either receives
> > the other IKE_AUTH request. This can be handled by having the one
> > with lower Initiator SPI win, while the other exchange gets some
> > error message (no proposal chosen?  or a new one?)
> >
> > >
> > > That text hints at the third and final reason.  With the REAUTH_SA
> > notification in the IKE_AUTH exchange, one doesn't know that a new
> > IKE SA is reauthenticating an old IKE SA until the IKE_AUTH exchange
> > begins.  Alternatively, with the REAUTH_SA in the IKE_SA_INIT
> > exchange, one knows immediately, from the very first IKE message,
> > whether or not a given IKE SA is intended to reauthenticate another
> > IKE SA or not.  Whether or not removing this ambiguity is really an
> > advantage or a disadvantage is debatable I suppose.
> >
> > OK. I'll debate for the other side. There's no reason to expose to
> > eavesdroppers that we're doing a re-authentication. IKE_AUTH is
> > encrypted, while IKE_SA_INIT is not.
> >
> > >
> > > I'm not sure those three reasons outweigh your SPI probing
> > concern.  I'm assuming there is not already a way to probe for SPIs
> > without the REAUTH_SA (I did a quick review of RFC 5996 from that
> > angle and couldn't see another way to accomplish such a probe).  If
> > I could still omit the piggy-backed child SA from the IKE_AUTH
> > exchange for a reauthentication I would be happy to move the
> > notification back to the IKE_AUTH exchange where I originally had it.
> > >
> > > > Once there, the intuitive logic would be:
> > > >  - If the peer authenticates as other than Alice, deny REAUTH (fail
> > > > the exchange?)
> > > >  - If authentication fails, ignore it. The old IKE SA remains alive.
> > > >  - If the peer authenticates as Alice, allow the reauth.
> > > >
> > > > This leads me to another issue. If the peer authenticates as Alice,
> > > > we can treat it as an "Alice". Is it OK for "an Alice" to inherit
> > > > the child SAs of any other "Alice"?  Ideally, there is only one
> > > > "Alice" and if the peer authenticates as "Alice" it may inherit any
> > > > child SAs belonging to any IKE SA belonging to "Alice", but I think
> > > > it would be better to somehow tie the old SA to the new SA with non-
> > > > public information. Perhaps something derived from the SKEYSEED
> > > > along with SK_d and the rest.
> > > I'll defer to Yaron's response here though I'd still like to
> > understand if this issue is really isolated to the proposed movement
> > of child SAs for reauthentication as I asked above.
> >
> > If I connect to work from both computer and my phone, should the
> > phone be able to "steal" the computer's SAs? If IKE is ever
> > integrated with NEA work, it might imply moving SAs that were
> > created with one posture to a host with another posture. Without
> > NEA, it's not so much a security issue, as it is a networking issue.
> >
> > >
> > > >
> > > > One final issue. The IKE_AUTH exchange in your draft does not
> > > > include what's needed for creating new Child SAs. This is not
> > > > allowed by RFC 5996. There is, however, a soon-to-be-published RFC
> > > > for this (draft-nir-ipsecme-childless)
> > > I was aware of this draft.  Assuming we conclude that it would be
> > best to move the REAUTH_SA notification to the IKE_AUTH exchange
> > then I would want to refer to that document and specify that it's
> > mechanisms be used to avoid creating an additional child SA when
> > reauthenticating an IKE SA.  However, I'm not clear why the approach
> > described in the current version of my draft is a not an acceptable
> > way to specify a childless IKE_AUTH exchange.
> > >
> > > >
> > > > Yoav
> > > >
> > > > On Sep 28, 2010, at 10:03 PM, Keith Welter wrote:
> > > >
> > > > >
> > > > > A new version of I-D, draft-welter-ipsecme-ikev2-reauth-00.txt has
> > > > been successfully submitted by Keith Welter and posted to the
> > IETF repository.
> > > > >
> > > > > Filename:                  draft-welter-ipsecme-ikev2-reauth
> > > > > Revision:                  00
> > > > > Title:                                   Reauthentication
> > > > Extension for IKEv2
> > > > > Creation_date:                  2010-09-28
> > > > > WG ID:                                   Independent Submission
> > > > > Number_of_pages: 10
> > > > >
> > > > > Abstract:
> > > > > This document extends the Internet Key Exchange (IKEv2) Protocol
> > > > > document [IKEv2].  IKEv2 reauthentication does not scale well when an
> > > > > IKE SA has multiple Child SAs because each Child SA of the IKE SA to
> > > > > be reauthenticated must be renegotiated.  In addition,
> > > > > reauthentication is susceptible to the same kinds of exchange
> > > > > collisions as those that may occur during rekeying.  This document
> > > > > describes a mechanism to detect reauthentication and avoid
> > > > > renegotiating the Child SAs.  In addition, this document describes
> > > > > proper handling of exchange collisions that may occur during
> > > > > reauthentication.
> > > > >                                                                      
> > > > >
> > > > >
> > > > > The IETF Secretariat.
> > > > >
> > > > >
> > > > >
> > > > > <ATT00001..txt>
> > > >
> > >
> > >
> > > Scanned by Check Point Total Security Gateway.
> > >
> > _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
 --=_alternative 0074C4EC882577B5_=-- From ynir@checkpoint.com Thu Oct 7 15:27:36 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 1DE293A6DD4 for ; Thu, 7 Oct 2010 15:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMoJO2I70ghO for ; Thu, 7 Oct 2010 15:27:35 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 640073A6F90 for ; Thu, 7 Oct 2010 15:27:34 -0700 (PDT) X-CheckPoint: {4CAE486B-10000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o97MSaXa014013; Fri, 8 Oct 2010 00:28:36 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 8 Oct 2010 00:28:36 +0200 From: Yoav Nir To: Keith Welter Date: Fri, 8 Oct 2010 00:28:34 +0200 Thread-Topic: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 Thread-Index: ActmbvthLRS/YHxtQu6g2ZPo/Mgf6A== Message-ID: <9F9F0232-5453-457A-8BE6-BDA620283652@checkpoint.com> References: <3B06F293-55D4-414C-8A49-6CC69C0DBFEF@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9F9F02325453457A8BE6BDA620283652checkpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 22:27:36 -0000 --_000_9F9F02325453457A8BE6BDA620283652checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 7, 2010, at 10:50 PM, Keith Welter wrote: Yoav Nir > wrote on 10/07/2= 010 12:26:36 PM: > I was not suggesting to use SK_d itself. Sorry, I misread your note. You clearly did not suggest using SK_d itself. > > RFC 5996 says this: > > {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } > =3D prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) > > > I suggest replaceing/augmenting it with this: > > {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr | SK_ri | SK_rr} > =3D prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) > > Where SK_ri and SK_rr are x number of bits each (128? 256? same as > the SK_d?) and these can be used for re-authentication later. First, to level-set, I assume that we are talking about key generation duri= ng an IKE_AUTH that occurs on a new IKE SA rather than the alternative appr= oach you described of doing a subsequent IKE_AUTH exchange on the original = IKE SA. I'm confused by what you suggest here though. Wouldn't the augmen= tation go in the data to which prf+ is applied, rather than the output? Fo= r example: {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } << new keys >> =3D prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr | SK_ri | SK_rr ) << augmented= data from which to derive keys >> Is that what you meant? It seems to me that any piece of keying material f= rom the old IKE SA that both sides incorporate into the key generation for = the new IKE SA ought to be sufficient. So here is another option to consid= er: {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } << new keys >> =3D prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr | prior SK_d ) << augmented da= ta from which to derive keys >> Nope. I just meant that in the original IKE SA creation, you generate some = more values and keep them (in both sides). Later, when we do a re-auth, the= peers prove linkage to the old SA by including these SK_ri and SK_rr in th= e REAUTH_SA notification. I didn't mean to change the calculation of the keys in the new SA, just pro= duce some more material. --_000_9F9F02325453457A8BE6BDA620283652checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Oct 7, 20= 10, at 10:50 PM, Keith Welter wrote:


Yoav Nir <ynir@checkpoint.com> wrote on 10/07/2010 12:26:36 PM:
> I was not suggesting to use  SK_d itself.
Sorry, I misread your note.  You clearly did not suggest using SK_d itself.

>
> RFC 5996 says this:
>
>    {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
>                    = =3D prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
>
>
> I suggest replaceing/augmenting it with this:
>
>    {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr | SK_ri | SK_rr}
>                    = =3D prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
>
> Where SK_ri and SK_rr are x number of bits each (128? 256? same as
> the SK_d?) and these can be used for re-authentication later.
First, to level-set, I assume that we are talking about key generation during an IKE_AUTH that occurs on a new IKE SA rather than the alternative approach you described of doing a subsequent IKE_AUTH exchange on the original IKE SA.  I'm confused by what you suggest here though.  Wouldn't the augmentation go in the data to which prf+ is applied, rather than the output?  For example:
    {SK_d | SK_ai | SK_ar | SK_ei | SK_e= r | SK_pi | SK_pr } << new keys >>
   =3D prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr | SK_ri | SK_rr ) << augmented data from which to derive keys >>
Is that what you meant?  It seems to me that any piece of keying material from the old IKE SA that both sides incorporat= e into the key generation for the new IKE SA ought to be sufficient.  So here is another option to consider:
    {SK_d | SK_ai | SK_ar | SK_ei | SK_e= r | SK_pi | SK_pr } << new keys >>
   =3D prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr | prior SK_d ) <= < augmented data from which to derive keys >>

Nope. I just meant that in the original IKE SA creation, = you generate some more values and keep them (in both sides). Later, when we= do a re-auth, the peers prove linkage to the old SA by including these SK_= ri and SK_rr in the REAUTH_SA notification.

I didn= 't mean to change the calculation of the keys in the new SA, just produce s= ome more material.
= --_000_9F9F02325453457A8BE6BDA620283652checkpointcom_-- From ynir@checkpoint.com Thu Oct 7 15:29: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 98A813A7032 for ; Thu, 7 Oct 2010 15:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFNAcHnZ9yIt for ; Thu, 7 Oct 2010 15:29:23 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id D466E3A6FAE for ; Thu, 7 Oct 2010 15:29:21 -0700 (PDT) X-CheckPoint: {4CAE48D6-10000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o97MUOZ2014183; Fri, 8 Oct 2010 00:30:24 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 8 Oct 2010 00:30:24 +0200 From: Yoav Nir To: Keith Welter Date: Fri, 8 Oct 2010 00:30:22 +0200 Thread-Topic: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 Thread-Index: Actmbzto6tFj75MoQ2izVuX6ghRQuQ== Message-ID: <4EA7CC61-FEBC-465C-A388-841E45398D5F@checkpoint.com> References: <3C3AC0EB-BBBB-4857-A595-A958E175CD4A@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4EA7CC61FEBC465CA388841E45398D5Fcheckpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-welter-ipsecme-ikev2-reauth-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 22:29:35 -0000 --_000_4EA7CC61FEBC465CA388841E45398D5Fcheckpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Oct 7, 2010, at 11:15 PM, Keith Welter wrote: Keith Welter > wrote on 10/07= /2010 10:26:56 AM: [...] > Yoav Nir > wrote on 10/07= /2010 12:48:17 AM: > [...] > > Hi Keith. > > > > My responses are below, but first I would like to know if you have > > considered a different solution - having an IKE_AUTH exchange in the > > middle of the IKE SA lifetime. Suppose the IKE SA has been around > > for a couple of hours, and has been used for creating some child > > SAs, why not keep it and just pass one or more IKE_AUTH exchanges? > Interesting. If support for the new reauth protocol is signaled in > the original IKE_AUTH exchange then I think you could do a modified > IKE_AUTH exchange in the old IKE SA to accomplish reauthentication. > That would eliminate moving the children and having to prove that > the reauth initiator is the same entity as he was before. It also > would reduce the variety of collision cases substantially. That > sounds very attractive. Offhand, I can't think of any reason not to do i= t. Actually, one down-side does come to mind. RFC5996-style reauthentication = and the kind described in my draft both allow the IKE SA attributes such as= the encryption algorithm to be changed by virtue of the new IKE_SA_INIT ex= change. That capability would be lost with IKE_AUTH on the old IKE SA. I = wouldn't want to take that capability away. To affect an IKE SA policy cha= nge you'd have to deactivate/reactivate. We're not taking away the ability to rekey IKE SAs. In rekey, you get to ch= oose new algorithms. --_000_4EA7CC61FEBC465CA388841E45398D5Fcheckpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Oct 7, 20= 10, at 11:15 PM, Keith Welter wrote:


Keith Welter <welterk@us.ibm.com> wrote on 10/07/2010 10:26:56 AM:
[...]
> Yoav Nir <ynir@checkpoint.co= m> wrote on 10/07/2010 12:48:17 AM:
> [...]
> > Hi Keith.
> >
> > My responses are below, but first I would like to know if you have
> > considered a different solution - having an IKE_AUTH exchange in the
> > middle of the IKE SA lifetime. Suppose the IKE SA has been around
> > for a couple of hours, and has been used for creating some child
> > SAs, why not keep it and just pass one or more IKE_AUTH exchanges= ?
> Interesting.  If support for the new reauth protocol is signaled in
> the original IKE_AUTH exchange then I think you could do a modified
> IKE_AUTH exchange in the old IKE SA to accomplish reauthentication.
> That would eliminate moving the children and having to prove that
> the reauth initiator is the same entity as he was before.  It also
> would reduce the variety of collision cases substantially.  That
> sounds very attractive.  Offhand, I can't think of any reason not to do it.
Actually, one down-side does come to mind.  R= FC5996-style reauthentication and the kind described in my draft both allow the IKE SA attributes such as the encryption algorithm to be changed by virtue of the new IKE_SA_INIT exchange.  That capability would be lost with IKE_AUTH on the old IKE SA.  I wouldn't want to take that capability away.  To affect an IKE SA policy change you'd have to deactivate/reac= tivate.  

We're not taking away= the ability to rekey IKE SAs. In rekey, you get to choose new algorithms.<= /div>
= --_000_4EA7CC61FEBC465CA388841E45398D5Fcheckpointcom_-- From ietf-ipsec@m.gmane.org Fri Oct 8 12:42: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 E213B3A694E for ; Fri, 8 Oct 2010 12:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHRI0Ti2YeFM for ; Fri, 8 Oct 2010 12:41:42 -0700 (PDT) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by core3.amsl.com (Postfix) with ESMTP id 073123A693E for ; Fri, 8 Oct 2010 12:41:40 -0700 (PDT) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P4InU-0006pC-AM for ipsec@ietf.org; Fri, 08 Oct 2010 21:40:04 +0200 Received: from 64.145.66.146 ([64.145.66.146]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Oct 2010 21:40:04 +0200 Received: from micah by 64.145.66.146 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Oct 2010 21:40:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ipsec@ietf.org From: Micah Anderson Date: Fri, 08 Oct 2010 12:47:57 -0400 Lines: 61 Message-ID: <87pqvk3a2q.fsf@algae.riseup.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 64.145.66.146 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:nG43tFlNGJnjjAhyxqQNa5cckVE= Cc: mjs@tycho.ncsc.mil Subject: [IPsec] IANA port number assignment name for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 19:42:37 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, The IANA port number assignment for UDP/TCP port 500[0] reads as follows: isakmp 500/tcp isakmp isakmp 500/udp isakmp # Mark Schertler isakmp was originally designated in RFC2408[1] =C2=A7 2.5.1 "Transport Protocol" to be port 500 UDP. It was assigned to be named isakmp by the Internet Assigned Numbers Authority (IANA). It has come to my attention that RFC5996[2] has been designated as obsoleting RFC2408 (via RFC 4306) and describes IKEv2 as the non-backwards compatible protocol that is used for this purpose, and is transported over port 500 UDP, and port 4500 when NAT traversal is enabled (cf. RFC5996 =C2=A7 2[3]) However, the IANA port assignment list still shows isakmp as being the port name for 500. Should this port assignment name be changed? I have CC'd the original IANA assignment requestor on this email. Thanks, Micah 0. http://www.iana.org/assignments/port-numbers 1. http://tools.ietf.org/html/rfc2408 2. http://tools.ietf.org/html/rfc5996 3. http://tools.ietf.org/html/rfc5996#section-2 =2D-=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCgAGBQJMr0s+AAoJEIy/mjIoYaeQc4EP/0P/YvOtp7iH2VvZfo8mkknO y4yM66JxoqYox7SSXvBMr6wXqtbV0JxSyt3dJlMUfW6N9HDzoN9YiKiF+IN+xGJT EJWURc1I+mhIKZIYvp9ngQrth3GIH/dMIJmaI83MgKFlZBtft4MlcW1TEQo2UcfL 1Ipf3C6e5li7j9gyik2g8iOaB368n1caVBRPifYvTafLP/PIPc+RkYy76pq3Uiqu d68pzM1xuNbut+R0nPIMYnc8aWiRZ89+FV437Mnlw/MXMnrne+AcGvWadIqdGHz7 krZldM3eH96JV1h4v19dosm5WaMUBhW0M51GtD9tAZ4cihBoY/hGI/YZ0teSNBuC wD/U4ih9y83L2kwfMyhglHLtRV1+jp9s9UHQwiBOXDhRQPlPkm22+qXwwOSz8AQ4 0RekTiuWFPb6mr/Ch5UalYguwouXhJLJHINKGb4Dn9ZDQUvx5wfKDZhAmniQkiHc zGr+xoZ97nylbHPOpOlhuJAQLe7whCKb6R+2PzxU2zSAkVYpGv3SEQRfAySpEtcN EqWrLzwdSOrNOqV+tgOLOaLSGafDxHbOdkT02FBAHJ6621oxFBSzeRtp6SbnQiSM Caf+3cZgaFLVqQSiXiobJjcoegh5mXcwENXUfG2T/V5W9OP1EkeMmdZIcxqahvsz vp9Uzl50bbYjNktQrH1/ =OR4i -----END PGP SIGNATURE----- --=-=-=-- From dharkins@lounge.org Fri Oct 8 16:18:18 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 1C1BB3A6981 for ; Fri, 8 Oct 2010 16:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.803 X-Spam-Level: X-Spam-Status: No, score=-5.803 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqIWN3b-y3oM for ; Fri, 8 Oct 2010 16:18:15 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id C34813A696D for ; Fri, 8 Oct 2010 16:18:15 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 543E6FE0030; Fri, 8 Oct 2010 16:19:21 -0700 (PDT) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 8 Oct 2010 16:19:21 -0700 (PDT) Message-ID: In-Reply-To: <87pqvk3a2q.fsf@algae.riseup.net> References: <87pqvk3a2q.fsf@algae.riseup.net> Date: Fri, 8 Oct 2010 16:19:21 -0700 (PDT) From: "Dan Harkins" To: "Micah Anderson" 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] IANA port number assignment name for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 23:18:18 -0000 Hi, I'm not sure what non-backwards compatibility issue there is because the IKEv2 header is, intentionally, the same as the ISAKMP header. The former has MajVer as 2 and the latter has MajVer as 1. It's possible to demultiplex a packet unambiguously. I don't know what problem would be solved by having IANA go through the motions. For what it's worth, I am unaware of any plain-jane ISAKMP versions out in the world. There's RFC 2409 that uses port 500 and there's RFC 4306/5996 that uses port. It hasn't been a problem for the past 12 years and it doesn't look like a problem now. regards, Dan. On Fri, October 8, 2010 9:47 am, Micah Anderson wrote: > > Hello, > > The IANA port number assignment for UDP/TCP port 500[0] reads as follows: > > isakmp 500/tcp isakmp > isakmp 500/udp isakmp > # Mark Schertler > > isakmp was originally designated in RFC2408[1] § 2.5.1 "Transport > Protocol" to be port 500 UDP. It was assigned to be named isakmp by the > Internet Assigned Numbers Authority (IANA). > > It has come to my attention that RFC5996[2] has been designated as > obsoleting RFC2408 (via RFC 4306) and describes IKEv2 as the > non-backwards compatible protocol that is used for this purpose, and is > transported over port 500 UDP, and port 4500 when NAT traversal is > enabled (cf. RFC5996 § 2[3]) > > However, the IANA port assignment list still shows isakmp as being the > port name for 500. Should this port assignment name be changed? > > I have CC'd the original IANA assignment requestor on this email. > > Thanks, > Micah > > 0. http://www.iana.org/assignments/port-numbers > 1. http://tools.ietf.org/html/rfc2408 > 2. http://tools.ietf.org/html/rfc5996 > 3. http://tools.ietf.org/html/rfc5996#section-2 > > > -- > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From micah@riseup.net Sat Oct 9 09:55: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 B05D13A6892 for ; Sat, 9 Oct 2010 09:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 JdYblYItXoPx for ; Sat, 9 Oct 2010 09:55:07 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [204.13.164.18]) by core3.amsl.com (Postfix) with ESMTP id 2AC3A3A6874 for ; Sat, 9 Oct 2010 09:55:07 -0700 (PDT) Received: from tern.riseup.net (tern-pn.riseup.net [10.0.1.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 037C125F02E; Sat, 9 Oct 2010 09:56:13 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: micah@tern.riseup.net) with ESMTPSA id 36BF014C12F Received: by algae (Postfix, from userid 1000) id 02E6641B3D; Sat, 9 Oct 2010 12:56:10 -0400 (EDT) From: micah anderson To: Dan Harkins In-Reply-To: References: <87pqvk3a2q.fsf@algae.riseup.net> User-Agent: Notmuch/0.3.1-93-g3ec9d24 (http://notmuchmail.org) Emacs/23.2.1 (i486-pc-linux-gnu) Date: Sat, 09 Oct 2010 12:56:04 -0400 Message-ID: <87lj67nw4b.fsf@algae.riseup.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.96.3 at mx1 X-Virus-Status: Clean Cc: ipsec@ietf.org, monkeysphere@lists.riseup.net Subject: Re: [IPsec] IANA port number assignment name for 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, 09 Oct 2010 16:55:08 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Hello, On Fri, 8 Oct 2010 16:19:21 -0700 (PDT), "Dan Harkins" wrote: > I'm not sure what non-backwards compatibility issue there is because > the IKEv2 header is, intentionally, the same as the ISAKMP header. The > former has MajVer as 2 and the latter has MajVer as 1. It's possible to > demultiplex a packet unambiguously. My understanding of reading RFC5996 page 71[0] is that they are only backwards compatible in the sense that you can at least talk to an older version. However that conversation is limited to establishing that you will not shake hands. They share a lineage and basic structure but they diverge with some specific version number fields and are incompatible From=20there onwards: The Internet Security Association and Key Management Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight-octet fields called "cookies", and that syntax is used by both IKEv1 and IKEv2, although in IKEv2 they are referred to as the "IKE SPI" and there is a new separate field in a Notify payload holding the cookie. The syntax of Security Associations, Proposals, Transforms, and Attributes is based on ISAKMP; however, the semantics are somewhat different. IKEv2 is not backwards compatible with IKEv1, as the Introduction to RFC5996[1] says: This document describes such a protocol -- the Internet Key Exchange (IKE). . . IKEv2 was a change to the IKE protocol that was not backward compatible. > I don't know what problem would be solved by having IANA go through > the motions.=20 Having a properly named port that matches its intended protocol name is much more useful than having a port named after an obsolete protocol that has been supersceded.=20 > For what it's worth, I am unaware of any plain-jane ISAKMP versions > out in the world. There's RFC 2409 that uses port 500 and there's RFC > 4306/5996 that uses port.=20 RFC2409 has been obsoleted by 4306 which was then obsoleted by 5996. My understanding of obsoleted rfcs means that what they contain is no longer valid. RFC 2409 used port 500 for ISAKMP, but RFC 5996 has overtaken that port by the IKEv2 protocol. If we move forwards with port 500 named after the obsolete RFC 2409 ISAKMP, but use it for IKEv2, then we are doing a disservice to people trying to understand what is going on. IKEv1 was ISAKMP+oakley+skeme, and IKEv2 is none of that. From what I can tell, IKEv2 has nothing to do with ISAKMP, except for the lineage as described above. > It hasn't been a problem for the past 12 years and it doesn't look > like a problem now. It was only last month that RFC5996 was released, and 5 years ago that the RFC that it now obsoletes was released (RFC 4306).=20 micah 0. http://tools.ietf.org/html/rfc5996#page-71 1. http://tools.ietf.org/html/rfc5996#page-5 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCgAGBQJMsJ6kAAoJEIy/mjIoYaeQWWUP/1Y6qEu5jFTWibv4Zx/L1IQf ZEsty9eovv27FA8Ny0fYdywe2issRKiH3vOPgaCi+7Os3QhIfSjnWJB7m1ZPeA1u uFnJle6QLcZem+yCUIUz08RO2OnZp1AOcFoM3efnSiFgj9/LFj/Ppa5gotkgHj5o wDD/AdPiUVgOJbrbIYdybAXemgAhn+mKGJMFuQKPXg88PP7nxvXfurfwV7ZJuDox yBf09hc7uxHxhEj2c063uXt9jfebWIR/NmwNZcoVZ9+m1rAlkMifmcdPdCqP0lK9 YW4NP+8Qko0zEW1tEpdNlADd4Sv1Ta2q4/nZa9UyRVCEAngwQf1YTzc4Q/5lk5Qb U/j/OvnoeiKXF6JeXx6Ssf5UQ0QgeDKwdSD9Nvc6SnPFJIQMcUexS8mH40S5Mzxc jdR67txeFjfv7/XecuT2Tb0oo7krxKACFs3+sP2i2ydG2IEyG4n5WHgDXwMKoQ4q qzdX7DUI3tpEaNot/YI0/x2rDu544o0IR8286VX+zNwVjnLVN1iS6Adw+Y5rmiAk +f5wghyWka2/1XY9o464Fzv3+bpaKLaKPsPkF0skTDuRrpA6SuyVS2OyI3ILiR04 0w1Huj2YzLdR2oYEStKDaHF+aBUxC4sSlljJwrpI/hwUeZQ0QXxT1eB+coFqX4rb 9nmRgRQDyR0u/Id8xdGT =u7Uu -----END PGP SIGNATURE----- --=-=-=-- From dan.mcdonald@oracle.com Sat Oct 9 12:00: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 75C653A69E8 for ; Sat, 9 Oct 2010 12:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 aY5x2Lx3uoa4 for ; Sat, 9 Oct 2010 12:00:08 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 0498B3A68FD for ; Sat, 9 Oct 2010 12:00:07 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o99J1Eo7014204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Oct 2010 19:01:15 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o99AMjxB022114; Sat, 9 Oct 2010 19:01:13 GMT Received: from abhmt015.oracle.com by acsmt354.oracle.com with ESMTP id 677198691286650857; Sat, 09 Oct 2010 12:00:57 -0700 Received: from @ (/71.174.113.16) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 09 Oct 2010 12:00:56 -0700 Date: Sat, 9 Oct 2010 15:00:49 -0400 From: Dan McDonald To: micah anderson Message-ID: <20101009190049.GA724@mactavish> References: <87pqvk3a2q.fsf@algae.riseup.net> <87lj67nw4b.fsf@algae.riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87lj67nw4b.fsf@algae.riseup.net> Organization: Oracle - Solaris Security (hon. Networking) User-Agent: Mutt/1.5.17 (2007-11-01) Cc: ipsec@ietf.org, Dan Harkins , monkeysphere@lists.riseup.net Subject: Re: [IPsec] IANA port number assignment name for 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, 09 Oct 2010 19:00:09 -0000 On Sat, Oct 09, 2010 at 12:56:04PM -0400, micah anderson wrote: > RFC2409 has been obsoleted by 4306 which was then obsoleted by 5996. My > understanding of obsoleted rfcs means that what they contain is no > longer valid. RFC 2409 used port 500 for ISAKMP, but RFC 5996 has > overtaken that port by the IKEv2 protocol. If we move forwards with port > 500 named after the obsolete RFC 2409 ISAKMP, but use it for IKEv2, then > we are doing a disservice to people trying to understand what is going > on. > > IKEv1 was ISAKMP+oakley+skeme, and IKEv2 is none of that. From what I > can tell, IKEv2 has nothing to do with ISAKMP, except for the lineage as > described above. So if you want to be a pedant, let's call 500 (and 4500) what they really are: 500/udp Internet Key Exchange (IKE), versions 1 and 2 4500/udp NAT-Traversal for IPsec and IKE Here are the entries in Solaris's /etc/services, e.g.: ike 500/udp ike # Internet Key Exchange ipsec-nat-t 4500/udp # IPsec NAT-Traversal Why is this a big deal? Are you just wanting to make sure IANA reflects reality? Dan From root@core3.amsl.com Sun Oct 10 01:30:26 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 1DB763A659C; Sun, 10 Oct 2010 01:30:25 -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: <20101010083026.1DB763A659C@core3.amsl.com> Date: Sun, 10 Oct 2010 01:30:25 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-01.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, 10 Oct 2010 08: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 : A Quick Crash Detection Method for IKE Author(s) : Y. Nir, et al. Filename : draft-ietf-ipsecme-failure-detection-01.txt Pages : 22 Date : 2010-10-10 This document describes an extension to the IKEv2 protocol that allows for faster detection of SA desynchronization using a saved token. When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text we propose an extension to the protocol, that allows for recovery immediately following the restart. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-failure-detection-01.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-failure-detection-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-10012531.I-D@ietf.org> --NextPart-- From ynir@checkpoint.com Sun Oct 10 01:54:02 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 A7DFF3A659A for ; Sun, 10 Oct 2010 01:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 a-K3oZ1GpT07 for ; Sun, 10 Oct 2010 01:54:01 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 4AD143A6452 for ; Sun, 10 Oct 2010 01:54:00 -0700 (PDT) X-CheckPoint: {4CB17E26-10000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o9A8t9I4025627 for ; Sun, 10 Oct 2010 10:55:09 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 10 Oct 2010 10:55:09 +0200 From: Yoav Nir To: "ipsec@ietf.org WG" Date: Sun, 10 Oct 2010 10:55:10 +0200 Thread-Topic: I-D Action:draft-ietf-ipsecme-failure-detection-01.txt Thread-Index: ActoWNdqpDPRvcvLSg+D0HmOL9kmXg== Message-ID: References: <20101010083026.1DB763A659C@core3.amsl.com> In-Reply-To: <20101010083026.1DB763A659C@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-failure-detection-01.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, 10 Oct 2010 08:54:02 -0000 Hi all This version resolves issues #189, #190, #191, and #192.=20 Also the content of section 9.3 has been moved to section 10.4 because, as = Frederic pointed out, it's more a security considerations than operational. Yoav On Oct 10, 2010, at 10:30 AM, 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 : A Quick Crash Detection Method for IKE > Author(s) : Y. Nir, et al. > Filename : draft-ietf-ipsecme-failure-detection-01.txt > Pages : 22 > Date : 2010-10-10 >=20 > This document describes an extension to the IKEv2 protocol that > allows for faster detection of SA desynchronization using a saved > token. >=20 > When an IPsec tunnel between two IKEv2 peers is disconnected due to a > restart of one peer, it can take as much as several minutes for the > other peer to discover that the reboot has occurred, thus delaying > recovery. In this text we propose an extension to the protocol, that > allows for recovery immediately following the restart. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-failure-detection-= 01.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 yaronf.ietf@gmail.com Sun Oct 10 05:59: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 103EA3A67F4 for ; Sun, 10 Oct 2010 05:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dB0-UH3Qhr6O for ; Sun, 10 Oct 2010 05:59:27 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B75E93A67EB for ; Sun, 10 Oct 2010 05:59:26 -0700 (PDT) Received: by fxm17 with SMTP id 17so51513fxm.31 for ; Sun, 10 Oct 2010 06:00:35 -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=8HyK5l9V2Bny/3EsvBHiX12hF03GSfL2fTkZWzSDsGU=; b=diAWuFX8WrBiZ8abtlzefkYRwNBwpXTqSyMyYedaWIBLrqNep7yMLiTHpaRiHAGwH0 BoXNObpFuTBF6kqD2nAvlZLtZ0h7OoF0NaNwSuhgxjXkELT7zEajmOcM6SIkFS1wVpqh 83EoqkkY3Rs05gtMaG8t6G5yEhq9St6P5Thh8= 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=m5zA6GqCGSxL+ezl5TTbfKaYFkc0IItQsGp2z5zJeSBZ3HepfXhKC1ig92VBbgfx1K hy4m2XK5SO6I+dftwFjSg+v92hUtkIcDQwQjOf8Q+0xciVksqZlwWEuOzTVsFba1aYYM fZefhO6Xudhp4w5aGrWWNaSpoK1R8J8Ddq4Rw= Received: by 10.223.74.193 with SMTP id v1mr455339faj.19.1286715633531; Sun, 10 Oct 2010 06:00:33 -0700 (PDT) Received: from [194.194.194.43] (80.179.5.52.static.012.net.il [80.179.5.52]) by mx.google.com with ESMTPS id f28sm2645441faa.0.2010.10.10.06.00.30 (version=SSLv3 cipher=RC4-MD5); Sun, 10 Oct 2010 06:00:32 -0700 (PDT) Message-ID: <4CB1B8EA.1070703@gmail.com> Date: Sun, 10 Oct 2010 15:00:26 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8 MIME-Version: 1.0 To: Yoav Nir References: <20101010083026.1DB763A659C@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-01.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, 10 Oct 2010 12:59:28 -0000 There's a typo in Sec. 3, "These are the final IKE_AUTH request..." should be "the first". More importantly, I think this new text is a bit wimpy... "To ensure this, token makers MUST use a good pseudo-random number generator to generate the IKE SPIs." I would have preferred "To ensure this, token makers MUST generate unpredictable IKE SPIs by using a cryptographically strong pseudo-random number generator." Thanks, Yaron On 10/10/2010 10:55 AM, Yoav Nir wrote: > Hi all > > This version resolves issues #189, #190, #191, and #192. > > Also the content of section 9.3 has been moved to section 10.4 because, as Frederic pointed out, it's more a security considerations than operational. > > Yoav > > On Oct 10, 2010, at 10:30 AM, wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. >> >> >> Title : A Quick Crash Detection Method for IKE >> Author(s) : Y. Nir, et al. >> Filename : draft-ietf-ipsecme-failure-detection-01.txt >> Pages : 22 >> Date : 2010-10-10 >> >> This document describes an extension to the IKEv2 protocol that >> allows for faster detection of SA desynchronization using a saved >> token. >> >> When an IPsec tunnel between two IKEv2 peers is disconnected due to a >> restart of one peer, it can take as much as several minutes for the >> other peer to discover that the reboot has occurred, thus delaying >> recovery. In this text we propose an extension to the protocol, that >> allows for recovery immediately following the restart. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-failure-detection-01.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 micah@riseup.net Sun Oct 10 14:14:33 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 D4C093A6864 for ; Sun, 10 Oct 2010 14:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 b6ll9palNOv2 for ; Sun, 10 Oct 2010 14:14:21 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [204.13.164.18]) by core3.amsl.com (Postfix) with ESMTP id 543113A684F for ; Sun, 10 Oct 2010 14:14:18 -0700 (PDT) Received: from tern.riseup.net (tern-pn.riseup.net [10.0.1.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 203E925E5D2; Sun, 10 Oct 2010 14:15:28 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: micah@tern.riseup.net) with ESMTPSA id EDF6E14C12F Received: by algae (Postfix, from userid 1000) id C57A341A01; Sun, 10 Oct 2010 17:15:22 -0400 (EDT) From: micah anderson To: Dan McDonald In-Reply-To: <20101009190049.GA724@mactavish> References: <87pqvk3a2q.fsf@algae.riseup.net> <87lj67nw4b.fsf@algae.riseup.net> <20101009190049.GA724@mactavish> User-Agent: Notmuch/0.3.1-93-g3ec9d24 (http://notmuchmail.org) Emacs/23.2.1 (i486-pc-linux-gnu) Date: Sun, 10 Oct 2010 17:15:22 -0400 Message-ID: <874octzr4l.fsf@algae.riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.3 at mx1 X-Virus-Status: Clean Cc: ipsec@ietf.org, Dan Harkins , monkeysphere@lists.riseup.net Subject: Re: [IPsec] IANA port number assignment name for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 21:14:33 -0000 On Sat, 9 Oct 2010 15:00:49 -0400, Dan McDonald wrote: > On Sat, Oct 09, 2010 at 12:56:04PM -0400, micah anderson wrote: > > > > > RFC2409 has been obsoleted by 4306 which was then obsoleted by 5996. My > > understanding of obsoleted rfcs means that what they contain is no > > longer valid. RFC 2409 used port 500 for ISAKMP, but RFC 5996 has > > overtaken that port by the IKEv2 protocol. If we move forwards with port > > 500 named after the obsolete RFC 2409 ISAKMP, but use it for IKEv2, then > > we are doing a disservice to people trying to understand what is going > > on. > > > > IKEv1 was ISAKMP+oakley+skeme, and IKEv2 is none of that. From what I > > can tell, IKEv2 has nothing to do with ISAKMP, except for the lineage as > > described above. > > So if you want to be a pedant, let's call 500 (and 4500) what they really > are: > > 500/udp Internet Key Exchange (IKE), versions 1 and 2 > > 4500/udp NAT-Traversal for IPsec and IKE Precisely. > Here are the entries in Solaris's /etc/services, e.g.: > > ike 500/udp ike # Internet Key Exchange > ipsec-nat-t 4500/udp # IPsec NAT-Traversal Great, Solaris has updated them, but its not updated in IANA's port assignment database. > Why is this a big deal? Are you just wanting to make sure IANA reflects > reality? Yes, I think having IANA reflect reality is a good idea. micah From root@core3.amsl.com Sun Oct 10 20:15: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 5D45B3A68A4; Sun, 10 Oct 2010 20:15:04 -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: <20101011031505.5D45B3A68A4@core3.amsl.com> Date: Sun, 10 Oct 2010 20:15:05 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-01.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, 11 Oct 2010 03:15:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Protocol Support for High Availability IKEv2/IPsec Author(s) : R. Jenwar, et al. Filename : draft-ietf-ipsecme-ipsecha-protocol-01.txt Pages : 19 Date : 2010-10-10 IKEv2 and IPsec protocols are widely used for deploying VPN. In order to make such VPN highly available, more scalable and failure- prone, these VPNs are implemented as IKEv2/IPsec Highly Available (HA) cluster. But there are many issues in IKEv2/IPsec HA cluster. The draft "IPsec Cluster Problem Statement" enumerates all the issues encountered in IKEv2/IPsec HA cluster environment. This document proposes an extension to IKEv2 protocol to solve main issues of "IPsec Cluster Problem Statement" in Hot Standby cluster and gives implementation advice for other issues. The main issues to be solved are: o IKEv2 Message Id synchronization : This is done by syncing up expected send and receive message Id values with the peer and updating the values at the newly active cluster member after the failover. o IPsec Replay Counter synchronization : This is done by syncing up bumped up outgoing SA replay counters values with peer and updating the values at the newly active cluster member after the failover. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsecha-protocol-01.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-ipsecha-protocol-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-10200815.I-D@ietf.org> --NextPart-- From yaronf.ietf@gmail.com Sun Oct 10 21:46:10 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 AD7E53A68E1 for ; Sun, 10 Oct 2010 21:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSdHFsSh7vtr for ; Sun, 10 Oct 2010 21:46:08 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id BD4C03A68E0 for ; Sun, 10 Oct 2010 21:46:07 -0700 (PDT) Received: by bwz14 with SMTP id 14so1042901bwz.31 for ; Sun, 10 Oct 2010 21:47: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:subject:content-type :content-transfer-encoding; bh=GQ5aizP1co3BNHUCWVf8rMy8akDhijOWrboHLpPA1JY=; b=pvRbnnJ+fzIv4oDrBwFRurE+h0Es7YrAMrT78GO59Gbx+fYXjphWZnuGr5hFVSt9/l Hu2TOK1IBllq2du2HLK6VDR5h/FnTJ4t6S3uE/pp6RmVfp8ljl0UNT+uh3dZ//kcKs/E 7hRWwrvsYVCglcZhUQH7w11w1S/7AVja/N368= 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=s+zZeLHJCKeUjLagQbzRXRFO92qGO0jwMkumMhq9qRegqNCK/GrQestsykJ8OTqjDm SRbsQDzpLGrU5S4KpOmoMmD9eLeiHjraXLf7VJZ81+rPZJq6gFWHPeyG+ATF94lmnX1F y0YcGyq47aex3IJfWgPXqtLC7MJPLktpDKwh8= Received: by 10.204.63.9 with SMTP id z9mr4567100bkh.66.1286772436968; Sun, 10 Oct 2010 21:47:16 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-181-39-14.red.bezeqint.net [79.181.39.14]) by mx.google.com with ESMTPS id o12sm3994684bkb.21.2010.10.10.21.47.14 (version=SSLv3 cipher=RC4-MD5); Sun, 10 Oct 2010 21:47:16 -0700 (PDT) Message-ID: <4CB296D1.7040500@gmail.com> Date: Mon, 11 Oct 2010 06:47:13 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100922 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Fwd: RFC 6023 on A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 04:46:11 -0000 This RFC was published outside the working group, as an independent submission. FYI. -------- Original Message -------- Subject: RFC 6023 on A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA) Date: Sun, 10 Oct 2010 17:11:30 -0700 (PDT) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 6023 Title: A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA) Author: Y. Nir, H. Tschofenig, H. Deng, R. Singh Status: Experimental Stream: Independent Date: October 2010 Mailbox: ynir@checkpoint.com, Hannes.Tschofenig@gmx.net, denghui02@gmail.com, rsj@cisco.com Pages: 7 Characters: 12560 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-nir-ipsecme-childless-06.txt URL: http://www.rfc-editor.org/rfc/rfc6023.txt This document describes an extension to the Internet Key Exchange version 2 (IKEv2) protocol that allows an IKEv2 Security Association (SA) to be created and authenticated without generating a Child SA. This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From ynir@checkpoint.com Sun Oct 10 23:21:32 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 189643A67B7 for ; Sun, 10 Oct 2010 23:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 KH-Fg2PffWrh for ; Sun, 10 Oct 2010 23:21:31 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id C0AE03A6767 for ; Sun, 10 Oct 2010 23:21:30 -0700 (PDT) X-CheckPoint: {4CB2ABDF-10002-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o9B6MeKN007332 for ; Mon, 11 Oct 2010 08:22:40 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 11 Oct 2010 08:22:40 +0200 From: Yoav Nir To: "'ipsec@ietf.org'" Date: Mon, 11 Oct 2010 08:22:39 +0200 Thread-Topic: Issue #193 - Is section 10.4 needed Thread-Index: ActpDLSPDLVO+gxxRUyW+X1emwlUqg== Message-ID: <006FEB08D9C6444AB014105C9AEB133F012E6FCD43B6@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Issue #193 - Is section 10.4 needed X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 11 Oct 2010 06:21:32 -0000 Hi. In -00 this section was labeled 9.3. This issue is very much about subs= tance, so we would very much like to see discussion of it. Ultimately it go= es to the question of whether and when the methods in 5.1 and 5.2 should be= recommended. Yaron: 10.4: this entire discussion is probably redundant, because when a n= ode fails in the LS cluster, you switch to another node. Implementing QCD o= n top of this is probably an overkill. If we remove this section, we can ge= t rid of sec. 5.2 as well, and we can focus on a single recommended way to = generate the token, which would make analysis that much easier.=20 Yoav: I disagree. Section 10.4 is about an active-standby configuration wit= hout synchronization. A failover is the same as a reboot, only faster. Please send comments to the list Yoav From ynir@checkpoint.com Sun Oct 10 23:21:39 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 832CA3A68F6 for ; Sun, 10 Oct 2010 23:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 0BUpKDAV-xxB for ; Sun, 10 Oct 2010 23:21:38 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 5F0D83A68F5 for ; Sun, 10 Oct 2010 23:21:38 -0700 (PDT) X-CheckPoint: {4CB2ABE7-10000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o9B6MmGk007345 for ; Mon, 11 Oct 2010 08:22:48 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 11 Oct 2010 08:22:48 +0200 From: Yoav Nir To: "'ipsec@ietf.org'" Date: Mon, 11 Oct 2010 08:22:47 +0200 Thread-Topic: Issue #194 - Security Considerations should discuss the threat Thread-Index: ActpDLlNWAk9C9neRy+IPEAY+p3a7Q== Message-ID: <006FEB08D9C6444AB014105C9AEB133F012E6FCD43B7@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Issue #194 - Security Considerations should discuss the threat X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 11 Oct 2010 06:21:39 -0000 Yaron: The security considerations are focused on details of the QCD soluti= on, rather then on the threats we are dealing with. These threats are non-t= rivial to describe, since an active MITM attacker can easily cause an IKE S= A to be reset. OTOH, we don't want an active non-MITM attacker to be able t= o do so. We need to analyze the threats in order to select a secure, but no= t overly complex solution. Suggested text would be most welcome. Yoav From A.Hoenes@TR-Sys.de Wed Oct 13 16:53:39 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 45B273A69EF for ; Wed, 13 Oct 2010 16:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.132 X-Spam-Level: X-Spam-Status: No, score=-98.132 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1eI74YG-ojq for ; Wed, 13 Oct 2010 16:53:38 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 775E83A6A13 for ; Wed, 13 Oct 2010 16:53:36 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA031674087; Thu, 14 Oct 2010 01:54:47 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA12355; Thu, 14 Oct 2010 01:54:46 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201010132354.BAA12355@TR-Sys.de> To: ipsec@ietf.org Date: Thu, 14 Oct 2010 01:54:46 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: Re: [IPsec] IANA port number assignment name for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 23:53:39 -0000 On Sun, 10 Oct 2010 17:15:22 -0400, Micah Anderson wrote: > On Sat, 9 Oct 2010 15:00:49 -0400, Dan McDonald wrote: > > ... > >> Here are the entries in Solaris's /etc/services, e.g.: >> >> ike 500/udp ike # Internet Key Exchange >> ipsec-nat-t 4500/udp # IPsec NAT-Traversal > > Great, Solaris has updated them, but its not updated in IANA's port > assignment database. > >> Why is this a big deal? Are you just wanting to make sure IANA >> reflects reality? > > Yes, I think having IANA reflect reality is a good idea. +1 The above entries look reasonable, and preferable to me as well. Procedural background: There's an effort ongoing at IANA and directed by TSVWG for a major revision of the Port Numbers registry to become the "Service Name and Transport Protocol Port Numbers" registry -- see http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports/ . The precise term for the subject we are talking about here is (registered) "service name" (for ports 500 and 4500, respectively). The revised policy for that registry reinforces to strongly discourages the handing out the assignment of different port numbers for different versions of an application/service in favor of recommending that application designers use wire formats that allow to demultiplex and/or negotiated different versions of the service. That's what we have. So sticking with the previously assigned port numbers conforms to the present and the upcoming registry policy as well. Further, the registry allows -- for scenarios essentially limited to very few important legacy cases -- the assignment of multiple service names for the same service, by introducing 'alias' service names. One of these names SHOULD be designated as the primary one. This will be implemented for the known legacy cases during the conversion of the registry, i.e. the implementation of draft-ietf-tsvwg-iana-ports. That I-D is approaching WGLC in TSVWG, and Magnus Westerlund has asked for more cases where alias service names are needed and for the designated primary service name in these cases. It looks like we have one such case here. Is it o.k. for the WG to include the above new service names in the registry and turning the presently registered service names into secondary names (aliases) ? I'm in the process of supplying another round of comments, and if the WG concurs, I could include that request in comments to the draft, pointing to this thread for reference, and supplying the necessary registration templates according to the above draft. Alternatively, I suggest that the authors of RFC 5996 or the chairs supply these templates to the aformentioned I-D's authors for documentation in the draft and inclusion in the registry conversion process. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From yaronf.ietf@gmail.com Thu Oct 14 01:56:02 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 4A0083A68A8 for ; Thu, 14 Oct 2010 01:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVuuCftenG4F for ; Thu, 14 Oct 2010 01:56:01 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 250FC3A6805 for ; Thu, 14 Oct 2010 01:56:00 -0700 (PDT) Received: by wwj40 with SMTP id 40so5068458wwj.13 for ; Thu, 14 Oct 2010 01:57:19 -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=VFDCko5QCOgxvSXCm/TiV8EpMWTM+BnA0NqI0BDBo5M=; b=BUBeO+hkVMF9vJjIDTKkfbnFEmIGJzGmSpQm1orR3X6uXvugLLDltZcDofqAl8C/e1 zVVBgqZo/5SqTCZ6gkwRmKOlNCnAcrJqFtlACNo89nk9au9UPpJG+XK8wAOWkWyj/MhM XQTFFyeFxRe1NxlPNvbLCmIRt/MvtRv1zzkac= 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=GZON+aVkOVNcZPoYEam/2QlRlvw31R/Mqcf92jyjnIlaa5S/6WhvnWR6UbYb5Zg374 BtW/rufSjLDiLgCp33aQyOYfrCkRrRr2dovrwEPCtz3u7hKlH/n03jmC4xiglvV/8lFp cB1BPuXz5YyxDeDSB/ODaOra/m5og8VgdfyZw= Received: by 10.227.145.20 with SMTP id b20mr9985701wbv.28.1287046638776; Thu, 14 Oct 2010 01:57:18 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-181-39-14.red.bezeqint.net [79.181.39.14]) by mx.google.com with ESMTPS id f14sm7680552wbe.20.2010.10.14.01.57.15 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Oct 2010 01:57:16 -0700 (PDT) Message-ID: <4CB6C5EA.3060500@gmail.com> Date: Thu, 14 Oct 2010 10:57:14 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100922 Lightning/1.0b2 Thunderbird/3.1.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 protocol -01 - 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: Thu, 14 Oct 2010 08:56:02 -0000 Hi, the new draft is a good realization of our discussions since the previous version. Please see a few comments below. My main point is that if you choose to implement *only* replay counter sync, you should not pay the price of all the other stuff that we added because of the problems with Message ID zero. I suggest that the protocol support the following three cases: - Both Msg ID and Replay Counter sync, where both must be sent in the same IKE message (and so can have one protection mechanism). - Only Msg ID sync. - Only Replay Counter sync, where we use a regular Informational message. Detailed comments: 1. Abstract: failure prone -> failure-resistant (same in intro) 2. "Standby member would initiate the SYNC Request with an INFORMATIONAL exchange with message Id zero ." It's very important to note that the zero message ID only applies to IKE counter sync (or when doing both), not to implementations that only sync IPsec counters. 3. There's no need for a nonce in the IPsec Replay Counter notification. Either it is sent within a regular IKE message, which is already replay-protected, or (when the message ID is 0) it is sent along with the other notification, whose nonce is sufficient for this purpose. Similarly for the failover count. 4. 6.4: the diagram should be reformatted so that it is clear which bit ESN is (i.e. use the letter 'E' for ESN). 5. 7: "IKEV2_MESSAGE_ID_SYNC exchange" - no, it's an Informational exchange that contains this notification. 6. Where is the failover count first initialized, and to what value? 7. Are there special processing rules for simultaneous failover? Where are they described? Thanks, Yaron From rsjenwar@gmail.com Thu Oct 14 03:14: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 9DA843A6B3D for ; Thu, 14 Oct 2010 03:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 bpUViK6Ptw+3 for ; Thu, 14 Oct 2010 03:14:32 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 382C53A6B35 for ; Thu, 14 Oct 2010 03:14:23 -0700 (PDT) Received: by iwn10 with SMTP id 10so9328344iwn.31 for ; Thu, 14 Oct 2010 03:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=pMGOsqVfayNAMqFU47bit8eBhoVLBcdSIoFTx52ss9E=; b=XfEw/KOHcs/Tbhu738g7T4LMUDh9HIZy+RD8qnNoUnduvC/hbDP6gkeFEmZ9ZyMov1 V7MNd/lnACxDwjUuuPozqeXyhRVPlrq/ouR6Giau+GH6k5gfsm07IsqjfqmJ+BCBT2TA Ts/IIyBu/LgXkbLy27de8jmEpJvLW0FNNljtY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=wJXvq/ZkvlS/jR2V0dFdzhdrJgvTa11L4CAeP9q2BLFFb3QIzDwhf75u/VVDfkweBt osRNWz1pweUGaijp43BIiJfzWC/njgIXa6QFgcrE4NzKv0ipL0nsvwq/gRABXmT93NwL uGlqfS02RVTvg778kggDe6d8pg2MGrcfbDHdY= MIME-Version: 1.0 Received: by 10.42.216.201 with SMTP id hj9mr4328011icb.390.1287051341199; Thu, 14 Oct 2010 03:15:41 -0700 (PDT) Received: by 10.42.2.138 with HTTP; Thu, 14 Oct 2010 03:15:41 -0700 (PDT) In-Reply-To: <4CB6C5EA.3060500@gmail.com> References: <4CB6C5EA.3060500@gmail.com> Date: Thu, 14 Oct 2010 15:45:41 +0530 Message-ID: From: Raj Singh To: Yaron Sheffer Content-Type: multipart/alternative; boundary=20cf301d431cfffac8049290fd11 Cc: IPsecme WG Subject: Re: [IPsec] HA protocol -01 - comments X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: RSJenwar@gmail.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 10:14:40 -0000 --20cf301d431cfffac8049290fd11 Content-Type: text/plain; charset=UTF-8 Hi Yaron, Thanks for comments. We will address them in next version. On Thu, Oct 14, 2010 at 2:27 PM, Yaron Sheffer wrote: > Hi, > > the new draft is a good realization of our discussions since the previous > version. Please see a few comments below. My main point is that if you > choose to implement *only* replay counter sync, you should not pay the price > of all the other stuff that we added because of the problems with Message ID > zero. I suggest that the protocol support the following three cases: > > - Both Msg ID and Replay Counter sync, where both must be sent in the same > IKE message (and so can have one protection mechanism). > - Only Msg ID sync. > - Only Replay Counter sync, where we use a regular Informational message. > > Detailed comments: > > 1. Abstract: failure prone -> failure-resistant (same in intro) > 2. "Standby member would initiate the SYNC Request with an > INFORMATIONAL exchange with message Id zero ." It's very important > to note that the zero message ID only applies to IKE counter sync > (or when doing both), not to implementations that only sync IPsec > counters. > 3. There's no need for a nonce in the IPsec Replay Counter > notification. Either it is sent within a regular IKE message, > which is already replay-protected, or (when the message ID is 0) > it is sent along with the other notification, whose nonce is > sufficient for this purpose. Similarly for the failover count. > 4. 6.4: the diagram should be reformatted so that it is clear which > bit ESN is (i.e. use the letter 'E' for ESN). > 5. 7: "IKEV2_MESSAGE_ID_SYNC exchange" - no, it's an Informational > exchange that contains this notification. > 6. Where is the failover count first initialized, and to what value? > The failover count is global parameter of HA and is generic across the cluster. I will add some text for it. > 7. Are there special processing rules for simultaneous failover? > Where are they described? > The current protocol which shift the to higher side on each end will take care of simultaneous failover too. We will add one example scenario for it in next version. > > Thanks, > Yaron > Best Regards, Raj > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --20cf301d431cfffac8049290fd11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yaron,

Thanks for comments. We will address them in next version.=

On Thu, Oct 14, 2010 at 2:27 PM, Yaron S= heffer <yaron= f.ietf@gmail.com> wrote:
Hi,

the new draft is a good realization of our discussions since the previous v= ersion. Please see a few comments below. My main point is that if you choos= e to implement *only* replay counter sync, you should not pay the price of = all the other stuff that we added because of the problems with Message ID z= ero. I suggest that the protocol support the following three cases:

- Both Msg ID and Replay Counter sync, where both must be sent in the same = IKE message (and so can have one protection mechanism).
- Only Msg ID sync.
- Only Replay Counter sync, where we use a regular Informational message.
Detailed comments:

=C2=A01. Abstract: =C2=A0failure prone -> failure-resistant (same in in= tro)
=C2=A02. "Standby member would initiate the SYNC Request with an
=C2=A0 =C2=A0 INFORMATIONAL exchange with message Id zero ." It's= very important
=C2=A0 =C2=A0 to note that the zero message ID only applies to IKE counter= sync
=C2=A0 =C2=A0 (or when doing both), not to implementations that only sync = IPsec
=C2=A0 =C2=A0 counters.
=C2=A03. There's no need for a nonce in the IPsec Replay Counter
=C2=A0 =C2=A0 notification. Either it is sent within a regular IKE message= ,
=C2=A0 =C2=A0 which is already replay-protected, or (when the message ID i= s 0)
=C2=A0 =C2=A0 it is sent along with the other notification, whose nonce is=
=C2=A0 =C2=A0 sufficient for this purpose. Similarly for the failover coun= t.
=C2=A04. 6.4: the diagram should be reformatted so that it is clear which<= br> =C2=A0 =C2=A0 bit ESN is (i.e. use the letter 'E' for ESN).
=C2=A05. 7: "IKEV2_MESSAGE_ID_SYNC exchange" - no, it's an I= nformational
=C2=A0 =C2=A0 exchange that contains this notification.
=C2=A06. Where is the failover count first initialized, and to what value?=
The failover count is global parameter of HA and is g= eneric across the cluster. I will add some text for it.
=C2=A07. Are there special processing rules for simultaneous failover?
=C2=A0 =C2=A0 Where are they described?
The current p= rotocol which shift the to higher side on each end will take care of simult= aneous failover too.
We will add one example scenario for it in next ver= sion.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0Yaron
Best Regards,
Raj=
_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--20cf301d431cfffac8049290fd11-- From wwwrun@rfc-editor.org Thu Oct 14 10: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 1C7E43A6B77; Thu, 14 Oct 2010 10:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.343 X-Spam-Level: X-Spam-Status: No, score=-102.343 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9JlnizOEnkY; Thu, 14 Oct 2010 10:13:23 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 41CCD3A6B27; Thu, 14 Oct 2010 10:13:07 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 12266E0704; Thu, 14 Oct 2010 10:14:04 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20101014171404.12266E0704@rfc-editor.org> Date: Thu, 14 Oct 2010 10:14:04 -0700 (PDT) Cc: ipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [IPsec] RFC 6027 on IPsec Cluster Problem Statement X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 14 Oct 2010 17:13:48 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6027 Title: IPsec Cluster Problem Statement Author: Y. Nir Status: Informational Stream: IETF Date: October 2010 Mailbox: ynir@checkpoint.com Pages: 12 Characters: 27497 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsecme-ipsec-ha-09.txt URL: http://www.rfc-editor.org/rfc/rfc6027.txt This document defines the terminology, problem statement, and requirements for implementing Internet Key Exchange (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. Agreed upon terminology, problem statement, and requirements will allow IETF working groups to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. 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. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From fd@cisco.com Fri Oct 15 03:28: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 1A6F33A689A for ; Fri, 15 Oct 2010 03:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 6PBubOxzLSCI for ; Fri, 15 Oct 2010 03:28:55 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id EA97E3A68D1 for ; Fri, 15 Oct 2010 03:28:54 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9F9rbJx022836; Fri, 15 Oct 2010 11:53:37 +0200 (CEST) Received: from ams-fdetienn-87110.cisco.com (ams-fdetienn-87110.cisco.com [10.55.136.235]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9F9raRs012350; Fri, 15 Oct 2010 11:53:37 +0200 (CEST) From: Frederic Detienne Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Oct 2010 11:53:39 +0200 Message-Id: To: Yoav Nir Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: IPsecme WG Subject: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue 193 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 15 Oct 2010 10:28:56 -0000 Hi Yaron, In response to issue 193. For reference: --8<-- Section 9.3: this entire discussion is probably redundant, because when = a node fails in the LS cluster, you switch to another node. Implementing = QCD on top of this is probably an overkill. If we remove this section, = we can get rid of sec. 5.2 as well, and we can focus on a single = recommended way to generate the token, which would make analysis that = much easier. --8<-- 9.3 has been moved to 10.4 under security consideration. I will refer to = 10.4 instead of 9.3 from now on. The token generation method highlighted in 5.1 presents a security risk = highlighted in section 10.4. We can not get rid of 5.2 nor 10.4, however we could make it clearer = that 5.2 is the recommended token generation method when the risk = highlighted in10.4 is present. Regards, fred From yaronf.ietf@gmail.com Sun Oct 17 05:55:43 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 9A8323A6ACF for ; Sun, 17 Oct 2010 05:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgE1UEaom5We for ; Sun, 17 Oct 2010 05:55:42 -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 797D03A6A09 for ; Sun, 17 Oct 2010 05:55:42 -0700 (PDT) Received: by wyb29 with SMTP id 29so2410699wyb.31 for ; Sun, 17 Oct 2010 05:57:07 -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=NkZXGyfUTPW9mY4KEGTYi5qF9cVxPzuP4oo7G/f4dEo=; b=OqCIITV2RTlcjPznyEIEzFLy2uGHlaahD/nDI0GNk/1IaV7vR1/t8OCgpSZvW4RU4W /SEeBF/codi1SgUGlPglW+WJzzsbc3fUu3cF2pjfdCl4wr9mnsJu3xbAGIRAmKzQ3HTx IX0EPTwGt+CdRbLksmOiPVOhzy4Rijpr1czwM= 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=Bzxqvqch/xy8vdb4R+P6qljpiiTbKgAwweA8AH5vsMzw1Uyty/Z9lMORGgBNgivPV0 XZHyL9b5vTVm6Y/5QUlBl2P8KSEtogePFBibuZtzI7ofvujLAaibsixXexonzzE+14QJ 0z5YsgAyRjmXrbozW74Kp9F3ar8UjMMrAgwDg= Received: by 10.227.145.20 with SMTP id b20mr3425763wbv.28.1287320225437; Sun, 17 Oct 2010 05:57:05 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-181-39-14.red.bezeqint.net [79.181.39.14]) by mx.google.com with ESMTPS id f14sm11201104wbe.2.2010.10.17.05.57.01 (version=SSLv3 cipher=RC4-MD5); Sun, 17 Oct 2010 05:57:02 -0700 (PDT) Message-ID: <4CBAF29C.7000805@gmail.com> Date: Sun, 17 Oct 2010 14:57:00 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100922 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Frederic Detienne References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Yoav Nir Subject: Re: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue 193 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 17 Oct 2010 12:55:43 -0000 Hi Frederic, I understand the scenario now and I agree that a solution is needed. But I have two issues, one general and one specific: - Even though there are no interoperability implications, I think we should specify the token format. This will prevent people from making some security-critical design mistakes. In other words, we should have *one* token generation method. - The proposed method uses the taker's IP address, making some assumptions on the load balancer's behavior. But what if the load balancer behaves a bit differently, e.g. by including the source port in the decision function? Such a system will still have the vulnerability. What if we choose instead to include the *maker* identity (a sequential member number, or a private IP, or even a MAC address)? This would prevent another member from re-generating the same token for an attacker, and as a side benefit, will not require token changes when the client is roaming. Thanks, Yaron On 15/10/10 11:53, Frederic Detienne wrote: > Hi Yaron, > > In response to issue 193. For reference: > > --8<-- > Section 9.3: this entire discussion is probably redundant, because when a node fails in the LS cluster, you switch to another node. Implementing QCD on top of this is probably an overkill. If we remove this section, we can get rid of sec. 5.2 as well, and we can focus on a single recommended way to generate the token, which would make analysis that much easier. > --8<-- > > 9.3 has been moved to 10.4 under security consideration. I will refer to 10.4 instead of 9.3 from now on. > > The token generation method highlighted in 5.1 presents a security risk highlighted in section 10.4. > > We can not get rid of 5.2 nor 10.4, however we could make it clearer that 5.2 is the recommended token generation method when the risk highlighted in10.4 is present. > > Regards, > > fred > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Sun Oct 17 06:41: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 EBEB13A6B8B for ; Sun, 17 Oct 2010 06:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3XDnuC4g+eP for ; Sun, 17 Oct 2010 06:40:30 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 09B3B3A6B6A for ; Sun, 17 Oct 2010 06:40:20 -0700 (PDT) X-CheckPoint: {4CBAFB79-10004-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o9HDfXWj021853; Sun, 17 Oct 2010 15:41:33 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 17 Oct 2010 15:41:33 +0200 From: Yoav Nir To: Yaron Sheffer Date: Sun, 17 Oct 2010 15:41:31 +0200 Thread-Topic: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue 193 Thread-Index: ActuAQK5xcO/0PiHRoiDUeA14yZ+bw== Message-ID: References: <4CBAF29C.7000805@gmail.com> In-Reply-To: <4CBAF29C.7000805@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Frederic Detienne Subject: Re: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue 193 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 17 Oct 2010 13:41:19 -0000 On Oct 17, 2010, at 2:57 PM, Yaron Sheffer wrote: > Hi Frederic, >=20 > I understand the scenario now and I agree that a solution is needed. But= =20 > I have two issues, one general and one specific: >=20 > - Even though there are no interoperability implications, I think we=20 > should specify the token format. This will prevent people from making=20 > some security-critical design mistakes. In other words, we should have=20 > *one* token generation method. Since there are no interoperability implications, I thing we should not spe= cify the format, merely suggest it. Same as we suggest a Cookie format in R= FC 5996: The exact algorithms and syntax used to generate cookies do not affect interoperability and hence are not specified here. The following is an example of how an endpoint could use cookies to implement limited DoS protection. Also, if different methods match different scenarios, I don't think we shou= ld have any problem with specifying^H^H^H^H^H^H^H^H^H^H suggesting *two* me= thods. I would not want to implement the method in section 5.2 just because= somebody has some issues with a load balancer. >=20 > - The proposed method uses the taker's IP address, making some=20 > assumptions on the load balancer's behavior. But what if the load=20 > balancer behaves a bit differently, e.g. by including the source port in= =20 > the decision function? Such a system will still have the vulnerability.=20 > What if we choose instead to include the *maker* identity (a sequential=20 > member number, or a private IP, or even a MAC address)? This would=20 > prevent another member from re-generating the same token for an=20 > attacker, and as a side benefit, will not require token changes when the= =20 > client is roaming. Yes, but this will interact badly with clusters. We actually do want two cl= uster members to return the same tokens for the same IKE SPIs. If they have= their states synched often, then it's no problem, because they both know w= hich IKE SAs exist, and which do not. If they don't have their states synch= ed and they are hot-standby, we also don't have a problem, because a fail-o= ver is like a reboot (but much faster), and you can't get a response from t= he non-active member. The only problem scenario is when you have load shari= ng and no synchronized state, and no control over the load balancer (otherw= ise, I would tell it to balance by the initiator's IKE SPI). So if one mem= ber fails, you can't get the others to offer valid QCD tokens, and the IKE = SAs have to take the long route to recovery. With the method in 5.2, the ot= her members (which don't have state) can still create valid QCD tokens, to = get all those clients that connected to the down gateway to begin IKE again= .=20 >=20 > Thanks, > Yaron >=20 > On 15/10/10 11:53, Frederic Detienne wrote: >> Hi Yaron, >>=20 >> In response to issue 193. For reference: >>=20 >> --8<-- >> Section 9.3: this entire discussion is probably redundant, because when = a node fails in the LS cluster, you switch to another node. Implementing QC= D on top of this is probably an overkill. If we remove this section, we can= get rid of sec. 5.2 as well, and we can focus on a single recommended way = to generate the token, which would make analysis that much easier. >> --8<-- >>=20 >> 9.3 has been moved to 10.4 under security consideration. I will refer to= 10.4 instead of 9.3 from now on. >>=20 >> The token generation method highlighted in 5.1 presents a security risk = highlighted in section 10.4. >>=20 >> We can not get rid of 5.2 nor 10.4, however we could make it clearer tha= t 5.2 is the recommended token generation method when the risk highlighted = in10.4 is present. >>=20 >> Regards, >>=20 >> fred >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From fd@cisco.com Sun Oct 17 12:57: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 C82AE3A6AA7 for ; Sun, 17 Oct 2010 12:57:53 -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 XdwXBwI2ytiP for ; Sun, 17 Oct 2010 12:57:52 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 287963A6961 for ; Sun, 17 Oct 2010 12:57:52 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9HJTGib005299; Sun, 17 Oct 2010 21:29:16 +0200 (CEST) Received: from ams-fdetienn-87110.cisco.com (ams-fdetienn-87110.cisco.com [10.55.136.235]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9HJTFdE003731; Sun, 17 Oct 2010 21:29:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Frederic Detienne In-Reply-To: Date: Sun, 17 Oct 2010 21:29:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <415E5B43-C885-4C26-85F4-966432B2D744@cisco.com> References: <4CBAF29C.7000805@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.1081) Cc: IPsecme WG Subject: Re: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue 193 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 17 Oct 2010 19:57:53 -0000 This type of debate happened before and once again, it is critical to = design a secure protocol rather than a protocol that can/may be = implemented securely. The rejoinder is to - offer recommended cookie computation methods - highlight the risks of each method and the risks of doing something = else This way, those who follow the spec can ascertain their computation = method is secure and has a well defined domain of applicability. I feel the draft is headed in the right direction. If we take out computation methods, we probably ought to restrict the = domain of applicability of the specification and/or spend more time = highlighting the risk of do-it-yourself cookie methods. Neither option = looks attractive. Notice the problem of address-less cookie is not limited to load = balanced clusters. If the attacker can somehow target a device owning = the QCD cookie-generating-key but not owning the SA, this attacker may = gain access to the QCD token for a given SPI. This applies _for = instance_ to HSRP pairs if the real addresses of the devices are = accessible by the attacker and if the standby device accepts = connections. This is just an example but it is likely to affect many = implementations in practice. The address-less method will likely require more severe warnings in = order to restrict or constraint its domain of applicability. regards, fred On 17 Oct 2010, at 15:41, Yoav Nir wrote: >=20 > On Oct 17, 2010, at 2:57 PM, Yaron Sheffer wrote: >=20 >> Hi Frederic, >>=20 >> I understand the scenario now and I agree that a solution is needed. = But=20 >> I have two issues, one general and one specific: >>=20 >> - Even though there are no interoperability implications, I think we=20= >> should specify the token format. This will prevent people from making=20= >> some security-critical design mistakes. In other words, we should = have=20 >> *one* token generation method. >=20 > Since there are no interoperability implications, I thing we should = not specify the format, merely suggest it. Same as we suggest a Cookie = format in RFC 5996: > The exact > algorithms and syntax used to generate cookies do not affect > interoperability and hence are not specified here. The following is > an example of how an endpoint could use cookies to implement limited > DoS protection. >=20 > Also, if different methods match different scenarios, I don't think we = should have any problem with specifying^H^H^H^H^H^H^H^H^H^H suggesting = *two* methods. I would not want to implement the method in section 5.2 = just because somebody has some issues with a load balancer. >=20 >>=20 >> - The proposed method uses the taker's IP address, making some=20 >> assumptions on the load balancer's behavior. But what if the load=20 >> balancer behaves a bit differently, e.g. by including the source port = in=20 >> the decision function? Such a system will still have the = vulnerability.=20 >> What if we choose instead to include the *maker* identity (a = sequential=20 >> member number, or a private IP, or even a MAC address)? This would=20 >> prevent another member from re-generating the same token for an=20 >> attacker, and as a side benefit, will not require token changes when = the=20 >> client is roaming. >=20 > Yes, but this will interact badly with clusters. We actually do want = two cluster members to return the same tokens for the same IKE SPIs. If = they have their states synched often, then it's no problem, because they = both know which IKE SAs exist, and which do not. If they don't have = their states synched and they are hot-standby, we also don't have a = problem, because a fail-over is like a reboot (but much faster), and you = can't get a response from the non-active member. The only problem = scenario is when you have load sharing and no synchronized state, and no = control over the load balancer (otherwise, I would tell it to balance by = the initiator's IKE SPI). So if one member fails, you can't get the = others to offer valid QCD tokens, and the IKE SAs have to take the long = route to recovery. With the method in 5.2, the other members (which = don't have state) can still create valid QCD tokens, to get all those = clients that connected to the down gateway to begin IKE again.=20 >=20 >>=20 >> Thanks, >> Yaron >>=20 >> On 15/10/10 11:53, Frederic Detienne wrote: >>> Hi Yaron, >>>=20 >>> In response to issue 193. For reference: >>>=20 >>> --8<-- >>> Section 9.3: this entire discussion is probably redundant, because = when a node fails in the LS cluster, you switch to another node. = Implementing QCD on top of this is probably an overkill. If we remove = this section, we can get rid of sec. 5.2 as well, and we can focus on a = single recommended way to generate the token, which would make analysis = that much easier. >>> --8<-- >>>=20 >>> 9.3 has been moved to 10.4 under security consideration. I will = refer to 10.4 instead of 9.3 from now on. >>>=20 >>> The token generation method highlighted in 5.1 presents a security = risk highlighted in section 10.4. >>>=20 >>> We can not get rid of 5.2 nor 10.4, however we could make it clearer = that 5.2 is the recommended token generation method when the risk = highlighted in10.4 is present. >>>=20 >>> Regards, >>>=20 >>> fred >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >> Scanned by Check Point Total Security Gateway. >=20 From ynir@checkpoint.com Wed Oct 20 01:08: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 9BEDC3A69D0 for ; Wed, 20 Oct 2010 01:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 5gNXCkN43jpN for ; Wed, 20 Oct 2010 01:08:22 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 16F7D3A686A for ; Wed, 20 Oct 2010 01:08:18 -0700 (PDT) X-CheckPoint: {4CBEA20D-10000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o9K89lZW003576 for ; Wed, 20 Oct 2010 10:09:47 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 20 Oct 2010 10:09:47 +0200 From: Yoav Nir To: IPsecme WG Date: Wed, 20 Oct 2010 10:09:45 +0200 Thread-Topic: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue 193 Thread-Index: ActwLijBnQQSmOPWRrW3wux1YgGpDw== Message-ID: <081AA6D0-20F1-48CA-83E9-A868BAFE54D3@checkpoint.com> References: <4CBAF29C.7000805@gmail.com> <415E5B43-C885-4C26-85F4-966432B2D744@cisco.com> In-Reply-To: <415E5B43-C885-4C26-85F4-966432B2D744@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue 193 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 20 Oct 2010 08:08:24 -0000 Hi all I have started this thread about this issue a week ago, and so far the only= responses we have had are from Yaron and Frederic. I would like to hear so= me more, because this issue is very central. Here's a summary of my take on this issue. The draft does not mandate any particular method of token generation (in th= is, we follow the example of the stateless cookie in RFC 5996). It does, ho= wever, suggest two such methods, both of which are somewhat similar to the = cookie generation method suggested in RFC 5996: 1. The method in section 5.1 involves hashing a secret with the IKE SPIs 2. The method in section 5.2 involves hashing a secret with the IKE SPIs an= d the token taker's IP address. The big disadvantage of the method in 5.2 is that whenever the token taker'= s IP address changes (as is common for roaming clients) the Token has to be= replaced. The advantage is that in a certain configuration (details below)= it prevents a token discovery attack. This attack involves tricking one ga= teway to send a clear QCD token for an IKE SA owned by another gateway. If = a cluster is located behind a load balancer, at attacker can attempt to sen= d fake IKE messages from various IP addresses, until those requests reach t= he "wrong" gateway, which will generate a QCD token that can be used to cau= se the original token taker to disconnect. Details of this scenario: For this attack to take place, we need all of the= following: - A group of gateways, all sharing the same QCD token secret. - A disjoint IKE SA database, meaning that IKE SAs are not synchronized. O= ne member in this cluster cannot know if a particular IKE SA exists on anot= her member. - The ability of an attacker to direct requests to different members (eith= er by varying its IP address or by directly addressing the member), and a w= illingness of all members to reply with a QCD token. We are not saying that having such no-sync clusters is a good idea. In fact= , it may be a good idea to recommend against them in the ipsecha document. = But they do exist. I have no problem recommending that implementations that= don't have such concerns just go ahead and implement the method in 5.1, bu= t since these things do exist, I think it's OK to recommend the method in 5= .2 for these configurations. Frederic is apparently with me on this, which= is good. Yaron has some doubts, though, and we'd really like to hear what = other people think. Yoav On Oct 17, 2010, at 9:29 PM, Frederic Detienne wrote: >=20 > This type of debate happened before and once again, it is critical to des= ign a secure protocol rather than a protocol that can/may be implemented se= curely. >=20 > The rejoinder is to > - offer recommended cookie computation methods > - highlight the risks of each method and the risks of doing something els= e >=20 > This way, those who follow the spec can ascertain their computation metho= d is secure and has a well defined domain of applicability. >=20 > I feel the draft is headed in the right direction. >=20 > If we take out computation methods, we probably ought to restrict the dom= ain of applicability of the specification and/or spend more time highlighti= ng the risk of do-it-yourself cookie methods. Neither option looks attracti= ve. >=20 > Notice the problem of address-less cookie is not limited to load balanced= clusters. If the attacker can somehow target a device owning the QCD cooki= e-generating-key but not owning the SA, this attacker may gain access to th= e QCD token for a given SPI. This applies _for instance_ to HSRP pairs if t= he real addresses of the devices are accessible by the attacker and if the = standby device accepts connections. This is just an example but it is likel= y to affect many implementations in practice. >=20 > The address-less method will likely require more severe warnings in order= to restrict or constraint its domain of applicability. >=20 > regards, >=20 > fred >=20 > On 17 Oct 2010, at 15:41, Yoav Nir wrote: >=20 >>=20 >> On Oct 17, 2010, at 2:57 PM, Yaron Sheffer wrote: >>=20 >>> Hi Frederic, >>>=20 >>> I understand the scenario now and I agree that a solution is needed. Bu= t=20 >>> I have two issues, one general and one specific: >>>=20 >>> - Even though there are no interoperability implications, I think we=20 >>> should specify the token format. This will prevent people from making=20 >>> some security-critical design mistakes. In other words, we should have= =20 >>> *one* token generation method. >>=20 >> Since there are no interoperability implications, I thing we should not = specify the format, merely suggest it. Same as we suggest a Cookie format i= n RFC 5996: >> The exact >> algorithms and syntax used to generate cookies do not affect >> interoperability and hence are not specified here. The following is >> an example of how an endpoint could use cookies to implement limited >> DoS protection. >>=20 >> Also, if different methods match different scenarios, I don't think we s= hould have any problem with specifying^H^H^H^H^H^H^H^H^H^H suggesting *two*= methods. I would not want to implement the method in section 5.2 just beca= use somebody has some issues with a load balancer. >>=20 >>>=20 >>> - The proposed method uses the taker's IP address, making some=20 >>> assumptions on the load balancer's behavior. But what if the load=20 >>> balancer behaves a bit differently, e.g. by including the source port i= n=20 >>> the decision function? Such a system will still have the vulnerability.= =20 >>> What if we choose instead to include the *maker* identity (a sequential= =20 >>> member number, or a private IP, or even a MAC address)? This would=20 >>> prevent another member from re-generating the same token for an=20 >>> attacker, and as a side benefit, will not require token changes when th= e=20 >>> client is roaming. >>=20 >> Yes, but this will interact badly with clusters. We actually do want two= cluster members to return the same tokens for the same IKE SPIs. If they h= ave their states synched often, then it's no problem, because they both kno= w which IKE SAs exist, and which do not. If they don't have their states sy= nched and they are hot-standby, we also don't have a problem, because a fai= l-over is like a reboot (but much faster), and you can't get a response fro= m the non-active member. The only problem scenario is when you have load sh= aring and no synchronized state, and no control over the load balancer (oth= erwise, I would tell it to balance by the initiator's IKE SPI). So if one = member fails, you can't get the others to offer valid QCD tokens, and the I= KE SAs have to take the long route to recovery. With the method in 5.2, the= other members (which don't have state) can still create valid QCD tokens, = to get all those clients that connected to the down gateway to begin IKE ag= ain.=20 >>=20 >>>=20 >>> Thanks, >>> Yaron >>>=20 >>> On 15/10/10 11:53, Frederic Detienne wrote: >>>> Hi Yaron, >>>>=20 >>>> In response to issue 193. For reference: >>>>=20 >>>> --8<-- >>>> Section 9.3: this entire discussion is probably redundant, because whe= n a node fails in the LS cluster, you switch to another node. Implementing = QCD on top of this is probably an overkill. If we remove this section, we c= an get rid of sec. 5.2 as well, and we can focus on a single recommended wa= y to generate the token, which would make analysis that much easier. >>>> --8<-- >>>>=20 >>>> 9.3 has been moved to 10.4 under security consideration. I will refer = to 10.4 instead of 9.3 from now on. >>>>=20 >>>> The token generation method highlighted in 5.1 presents a security ris= k highlighted in section 10.4. >>>>=20 >>>> We can not get rid of 5.2 nor 10.4, however we could make it clearer t= hat 5.2 is the recommended token generation method when the risk highlighte= d in10.4 is present. >>>>=20 >>>> Regards, >>>>=20 >>>> fred >>>>=20 >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>=20 >>> Scanned by Check Point Total Security Gateway. >>=20 >=20 >=20 > Scanned by Check Point Total Security Gateway. From ynir@checkpoint.com Wed Oct 20 01:08:25 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 1AA9A3A686A for ; Wed, 20 Oct 2010 01:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 mNtrqcqaltRQ for ; Wed, 20 Oct 2010 01:08:24 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 3A5CB3A69B9 for ; Wed, 20 Oct 2010 01:08:23 -0700 (PDT) X-CheckPoint: {4CBEA215-10001-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o9K89ttu003657 for ; Wed, 20 Oct 2010 10:09:55 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 20 Oct 2010 10:09:55 +0200 From: Yoav Nir To: IPsecme WG Date: Wed, 20 Oct 2010 10:09:53 +0200 Thread-Topic: [IPsec] Issue #194 - Security Considerations should discuss the threat Thread-Index: ActwLi1304KWIkerQFy6gpy+YTG0uw== Message-ID: <57568731-A4E2-4876-8B54-876AD95D1A40@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD43B7@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F012E6FCD43B7@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss the threat X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 20 Oct 2010 08:08:25 -0000 One week, and no replies... I will leave this issue open unless I get some suggested security considera= tions text. The first paragraph in section 10.1 says the following. What else is missin= g? Tokens MUST be hard to guess. This is critical, because if an attacker can guess the token associated with an IKE SA, she can tear down the IKE SA and associated tunnels at will. When the token is delivered in the IKE_AUTH exchange, it is encrypted. When it is sent again in an unprotected notification, it is not, but that is the last time this token is ever used. Yoav On Oct 11, 2010, at 8:22 AM, Yoav Nir wrote: > Yaron: The security considerations are focused on details of the QCD solu= tion, rather then on the threats we are dealing with. These threats are non= -trivial to describe, since an active MITM attacker can easily cause an IKE= SA to be reset. OTOH, we don't want an active non-MITM attacker to be able= to do so. We need to analyze the threats in order to select a secure, but = not overly complex solution. >=20 >=20 >=20 > Suggested text would be most welcome. >=20 > Yoav > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From wierbows@us.ibm.com Wed Oct 20 05:56:23 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 A2A6C3A67FC; Wed, 20 Oct 2010 05:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.263 X-Spam-Level: X-Spam-Status: No, score=-6.263 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vq0fv+Cvjpx6; Wed, 20 Oct 2010 05:56:22 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 649423A67EE; Wed, 20 Oct 2010 05:56:22 -0700 (PDT) Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o9KCwTQD020884; Wed, 20 Oct 2010 08:58:29 -0400 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o9KCvtic364026; Wed, 20 Oct 2010 08:57:55 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o9KBvsaE014566; Wed, 20 Oct 2010 07:57:54 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o9KBvs03014563; Wed, 20 Oct 2010 07:57:54 -0400 In-Reply-To: <57568731-A4E2-4876-8B54-876AD95D1A40@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD43B7@il-ex01.ad.checkpoint.com> <57568731-A4E2-4876-8B54-876AD95D1A40@checkpoint.com> X-KeepSent: A6C03F3C:8ED5B9A7-852577C2:0046D1E7; type=4; name=$KeepSent To: IPsecme WG , ipsec-bounces@ietf.org X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: David Wierbowski Date: Wed, 20 Oct 2010 08:57:52 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 10/20/2010 08:57:54 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss the threat X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 20 Oct 2010 12:56:23 -0000 I'm not sure I understand Yaron's concern. Yaron, can you elaborate how a MITM attacker can easily cause an IKE SA to be reset? I would think he could only do so if he hi-jacked the original IKE_SA negotiation and is now impersonating the remote security endpoint. In that case you have bigger issues. Dave Wierbowski From: Yoav Nir To: IPsecme WG Date: 10/20/2010 04:10 AM Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss the threat Sent by: ipsec-bounces@ietf.org One week, and no replies... I will leave this issue open unless I get some suggested security considerations text. The first paragraph in section 10.1 says the following. What else is missing? Tokens MUST be hard to guess. This is critical, because if an attacker can guess the token associated with an IKE SA, she can tear down the IKE SA and associated tunnels at will. When the token is delivered in the IKE_AUTH exchange, it is encrypted. When it is sent again in an unprotected notification, it is not, but that is the last time this token is ever used. Yoav On Oct 11, 2010, at 8:22 AM, Yoav Nir wrote: > Yaron: The security considerations are focused on details of the QCD solution, rather then on the threats we are dealing with. These threats are non-trivial to describe, since an active MITM attacker can easily cause an IKE SA to be reset. OTOH, we don't want an active non-MITM attacker to be able to do so. We need to analyze the threats in order to select a secure, but not overly complex solution. > > > > Suggested text would be most welcome. > > Yoav > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From wierbows@us.ibm.com Wed Oct 20 06:04:18 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 6C86D3A67FE; Wed, 20 Oct 2010 06:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.305 X-Spam-Level: X-Spam-Status: No, score=-6.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vb6eSEsNXfWU; Wed, 20 Oct 2010 06:04:16 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 752C83A6768; Wed, 20 Oct 2010 06:04:16 -0700 (PDT) Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e2.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o9KCnvav026699; Wed, 20 Oct 2010 08:49:57 -0400 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o9KD5TlR372306; Wed, 20 Oct 2010 09:05:29 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o9KC5TeZ020934; Wed, 20 Oct 2010 08:05:29 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o9KC5TLg020931; Wed, 20 Oct 2010 08:05:29 -0400 In-Reply-To: <081AA6D0-20F1-48CA-83E9-A868BAFE54D3@checkpoint.com> References: <4CBAF29C.7000805@gmail.com> <415E5B43-C885-4C26-85F4-966432B2D744@cisco.com> <081AA6D0-20F1-48CA-83E9-A868BAFE54D3@checkpoint.com> X-KeepSent: 5DAFC225:0DF1AA08-852577C2:0047582C; type=4; name=$KeepSent To: IPsecme WG , ipsec-bounces@ietf.org X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: David Wierbowski Date: Wed, 20 Oct 2010 09:05:27 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 10/20/2010 09:05:29 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue 193 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 20 Oct 2010 13:04:18 -0000 I think it is fine to not mandate a particular method of token generation. I think it is sufficient to provide two recommendations with an applicable explanation of pros and cons. I do not think this will lead implementers to make security-critical design mistakes. Most implementers can read an RFC and understand the issues. When in doubt they post a question here. Dave Wierbowski From: Yoav Nir To: IPsecme WG Date: 10/20/2010 04:10 AM Subject: Re: [IPsec] draft-ietf-ipsecme-failure-detection-01 -- issue 193 Sent by: ipsec-bounces@ietf.org Hi all I have started this thread about this issue a week ago, and so far the only responses we have had are from Yaron and Frederic. I would like to hear some more, because this issue is very central. Here's a summary of my take on this issue. The draft does not mandate any particular method of token generation (in this, we follow the example of the stateless cookie in RFC 5996). It does, however, suggest two such methods, both of which are somewhat similar to the cookie generation method suggested in RFC 5996: 1. The method in section 5.1 involves hashing a secret with the IKE SPIs 2. The method in section 5.2 involves hashing a secret with the IKE SPIs and the token taker's IP address. The big disadvantage of the method in 5.2 is that whenever the token taker's IP address changes (as is common for roaming clients) the Token has to be replaced. The advantage is that in a certain configuration (details below) it prevents a token discovery attack. This attack involves tricking one gateway to send a clear QCD token for an IKE SA owned by another gateway. If a cluster is located behind a load balancer, at attacker can attempt to send fake IKE messages from various IP addresses, until those requests reach the "wrong" gateway, which will generate a QCD token that can be used to cause the original token taker to disconnect. Details of this scenario: For this attack to take place, we need all of the following: - A group of gateways, all sharing the same QCD token secret. - A disjoint IKE SA database, meaning that IKE SAs are not synchronized. One member in this cluster cannot know if a particular IKE SA exists on another member. - The ability of an attacker to direct requests to different members (either by varying its IP address or by directly addressing the member), and a willingness of all members to reply with a QCD token. We are not saying that having such no-sync clusters is a good idea. In fact, it may be a good idea to recommend against them in the ipsecha document. But they do exist. I have no problem recommending that implementations that don't have such concerns just go ahead and implement the method in 5.1, but since these things do exist, I think it's OK to recommend the method in 5.2 for these configurations. Frederic is apparently with me on this, which is good. Yaron has some doubts, though, and we'd really like to hear what other people think. Yoav On Oct 17, 2010, at 9:29 PM, Frederic Detienne wrote: > > This type of debate happened before and once again, it is critical to design a secure protocol rather than a protocol that can/may be implemented securely. > > The rejoinder is to > - offer recommended cookie computation methods > - highlight the risks of each method and the risks of doing something else > > This way, those who follow the spec can ascertain their computation method is secure and has a well defined domain of applicability. > > I feel the draft is headed in the right direction. > > If we take out computation methods, we probably ought to restrict the domain of applicability of the specification and/or spend more time highlighting the risk of do-it-yourself cookie methods. Neither option looks attractive. > > Notice the problem of address-less cookie is not limited to load balanced clusters. If the attacker can somehow target a device owning the QCD cookie-generating-key but not owning the SA, this attacker may gain access to the QCD token for a given SPI. This applies _for instance_ to HSRP pairs if the real addresses of the devices are accessible by the attacker and if the standby device accepts connections. This is just an example but it is likely to affect many implementations in practice. > > The address-less method will likely require more severe warnings in order to restrict or constraint its domain of applicability. > > regards, > > fred > > On 17 Oct 2010, at 15:41, Yoav Nir wrote: > >> >> On Oct 17, 2010, at 2:57 PM, Yaron Sheffer wrote: >> >>> Hi Frederic, >>> >>> I understand the scenario now and I agree that a solution is needed. But >>> I have two issues, one general and one specific: >>> >>> - Even though there are no interoperability implications, I think we >>> should specify the token format. This will prevent people from making >>> some security-critical design mistakes. In other words, we should have >>> *one* token generation method. >> >> Since there are no interoperability implications, I thing we should not specify the format, merely suggest it. Same as we suggest a Cookie format in RFC 5996: >> The exact >> algorithms and syntax used to generate cookies do not affect >> interoperability and hence are not specified here. The following is >> an example of how an endpoint could use cookies to implement limited >> DoS protection. >> >> Also, if different methods match different scenarios, I don't think we should have any problem with specifying^H^H^H^H^H^H^H^H^H^H suggesting *two* methods. I would not want to implement the method in section 5.2 just because somebody has some issues with a load balancer. >> >>> >>> - The proposed method uses the taker's IP address, making some >>> assumptions on the load balancer's behavior. But what if the load >>> balancer behaves a bit differently, e.g. by including the source port in >>> the decision function? Such a system will still have the vulnerability. >>> What if we choose instead to include the *maker* identity (a sequential >>> member number, or a private IP, or even a MAC address)? This would >>> prevent another member from re-generating the same token for an >>> attacker, and as a side benefit, will not require token changes when the >>> client is roaming. >> >> Yes, but this will interact badly with clusters. We actually do want two cluster members to return the same tokens for the same IKE SPIs. If they have their states synched often, then it's no problem, because they both know which IKE SAs exist, and which do not. If they don't have their states synched and they are hot-standby, we also don't have a problem, because a fail-over is like a reboot (but much faster), and you can't get a response from the non-active member. The only problem scenario is when you have load sharing and no synchronized state, and no control over the load balancer (otherwise, I would tell it to balance by the initiator's IKE SPI). So if one member fails, you can't get the others to offer valid QCD tokens, and the IKE SAs have to take the long route to recovery. With the method in 5.2, the other members (which don't have state) can still create valid QCD tokens, to get all those clients that connected to the down gateway to begin IKE again. >> >>> >>> Thanks, >>> Yaron >>> >>> On 15/10/10 11:53, Frederic Detienne wrote: >>>> Hi Yaron, >>>> >>>> In response to issue 193. For reference: >>>> >>>> --8<-- >>>> Section 9.3: this entire discussion is probably redundant, because when a node fails in the LS cluster, you switch to another node. Implementing QCD on top of this is probably an overkill. If we remove this section, we can get rid of sec. 5.2 as well, and we can focus on a single recommended way to generate the token, which would make analysis that much easier. >>>> --8<-- >>>> >>>> 9.3 has been moved to 10.4 under security consideration. I will refer to 10.4 instead of 9.3 from now on. >>>> >>>> The token generation method highlighted in 5.1 presents a security risk highlighted in section 10.4. >>>> >>>> We can not get rid of 5.2 nor 10.4, however we could make it clearer that 5.2 is the recommended token generation method when the risk highlighted in10.4 is present. >>>> >>>> Regards, >>>> >>>> fred >>>> >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> Scanned by Check Point Total Security Gateway. >> > > > Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Wed Oct 20 06:45:38 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 7A1043A693C for ; Wed, 20 Oct 2010 06:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jywWX33ts1p9 for ; Wed, 20 Oct 2010 06:45:37 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 31EA83A684D for ; Wed, 20 Oct 2010 06:45:37 -0700 (PDT) Received: by fxm17 with SMTP id 17so2893811fxm.31 for ; Wed, 20 Oct 2010 06:47:10 -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=GARowPc1EcXzWLKW+Q8Gamst4Yf/z94iRS/gwFPRFn0=; b=GythcoHk1idf4NefoyOPMjf0yrAXBGPRl7/JJeKjyBpWAhs/Dw7ltNd1moU7pbECER PKp6/S6PxIFTMBmL5hYCd1d9ZtIb4+jZfBxVlJL+6lu6z8++Rp2Vcsk8klBIi6bj8c2a N4AdYezyN7oyO2vKIu7WAzDf2poyHArxdwWxs= 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=Nuj2e/nxSOeTW8cklVOXJYr7BasYD+rYPzrgUC04bBOS9Wl5v+CWbt6r+fn2d7C4ke B5yoFlY0lBxD10LLrxXKwUAehrDOR1fAy3zZKfjI1AMz/9p3a2GYqnXNueILjhopbTtn fFC7eO2zdlTrTSNTVu0uzPhHOsvg2/YHGzirY= Received: by 10.102.244.18 with SMTP id r18mr3693815muh.62.1287582429477; Wed, 20 Oct 2010 06:47:09 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-179-22-84.red.bezeqint.net [79.179.22.84]) by mx.google.com with ESMTPS id a10sm106957fak.27.2010.10.20.06.47.04 (version=SSLv3 cipher=RC4-MD5); Wed, 20 Oct 2010 06:47:05 -0700 (PDT) Message-ID: <4CBEF2D5.8080903@gmail.com> Date: Wed, 20 Oct 2010 15:47:01 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100922 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: David Wierbowski References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD43B7@il-ex01.ad.checkpoint.com> <57568731-A4E2-4876-8B54-876AD95D1A40@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss the threat X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 20 Oct 2010 13:45:38 -0000 Hi Dave, an active MITM, i.e. the sys admin at your local Starbucks, needs to only drop a few packets of an open IKE SA (a few retransmissions) for the peers to decide that they have a problem and attempt to renegotiate the SA. This attack is trivial to mount if you're at the right spot. On the other hand, Sec. 5.2 of the document is designed to prevent another kind of DoS attack that eventually does the same thing: resets the SA. So we need to explain why we add a mechanism to prevent one kind of DoS attacks even though we have other potential DoS issues. I'm not saying this is wrong, I'm saying it needs to be rationalized. Thanks, Yaron On 10/20/2010 02:57 PM, David Wierbowski wrote: > I'm not sure I understand Yaron's concern. Yaron, can you elaborate how a > MITM attacker can easily cause an IKE SA to be reset? I would think he > could only do so if he hi-jacked the original IKE_SA negotiation and is > now impersonating the remote security endpoint. In that case you have > bigger issues. > > Dave Wierbowski > > > > > From: Yoav Nir > To: IPsecme WG > Date: 10/20/2010 04:10 AM > Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss > the threat > Sent by: ipsec-bounces@ietf.org > > > > One week, and no replies... > > I will leave this issue open unless I get some suggested security > considerations text. > > The first paragraph in section 10.1 says the following. What else is > missing? > > Tokens MUST be hard to guess. This is critical, because if an > attacker can guess the token associated with an IKE SA, she can tear > down the IKE SA and associated tunnels at will. When the token is > delivered in the IKE_AUTH exchange, it is encrypted. When it is sent > again in an unprotected notification, it is not, but that is the last > time this token is ever used. > > Yoav > > On Oct 11, 2010, at 8:22 AM, Yoav Nir wrote: > >> Yaron: The security considerations are focused on details of the QCD > solution, rather then on the threats we are dealing with. These threats are > non-trivial to describe, since an active MITM attacker can easily cause an > IKE SA to be reset. OTOH, we don't want an active non-MITM attacker to be > able to do so. We need to analyze the threats in order to select a secure, > but not overly complex solution. >> >> >> >> Suggested text would be most welcome. >> >> Yoav >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Wed Oct 20 06:56: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 646B83A67CF for ; Wed, 20 Oct 2010 06:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 XonVZiX42cIe for ; Wed, 20 Oct 2010 06:56:43 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 7650D3A6824 for ; Wed, 20 Oct 2010 06:56:42 -0700 (PDT) X-CheckPoint: {4CBEF3B6-10001-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o9KDwB35008395; Wed, 20 Oct 2010 15:58:11 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 20 Oct 2010 15:58:11 +0200 From: Yoav Nir To: Yaron Sheffer Date: Wed, 20 Oct 2010 15:58:09 +0200 Thread-Topic: [IPsec] Issue #194 - Security Considerations should discuss the threat Thread-Index: ActwXtT5TOqLvmEqQk2+dtF836eAew== Message-ID: References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD43B7@il-ex01.ad.checkpoint.com> <57568731-A4E2-4876-8B54-876AD95D1A40@checkpoint.com> <4CBEF2D5.8080903@gmail.com> In-Reply-To: <4CBEF2D5.8080903@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , David Wierbowski Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss the threat X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 20 Oct 2010 13:56:46 -0000 OK. I did not understand that this was about 5.2 rather than the whole exte= nsion. In that case, does section 10.4 address this? If not, can you suggest some= text? Yoav On Oct 20, 2010, at 3:47 PM, Yaron Sheffer wrote: > Hi Dave, >=20 > an active MITM, i.e. the sys admin at your local Starbucks, needs to=20 > only drop a few packets of an open IKE SA (a few retransmissions) for=20 > the peers to decide that they have a problem and attempt to renegotiate=20 > the SA. This attack is trivial to mount if you're at the right spot. >=20 > On the other hand, Sec. 5.2 of the document is designed to prevent=20 > another kind of DoS attack that eventually does the same thing: resets=20 > the SA. >=20 > So we need to explain why we add a mechanism to prevent one kind of DoS=20 > attacks even though we have other potential DoS issues. I'm not saying=20 > this is wrong, I'm saying it needs to be rationalized. >=20 > Thanks, > Yaron >=20 > On 10/20/2010 02:57 PM, David Wierbowski wrote: >> I'm not sure I understand Yaron's concern. Yaron, can you elaborate how= a >> MITM attacker can easily cause an IKE SA to be reset? I would think he >> could only do so if he hi-jacked the original IKE_SA negotiation and is >> now impersonating the remote security endpoint. In that case you have >> bigger issues. >>=20 >> Dave Wierbowski >>=20 >>=20 >>=20 >>=20 >> From: Yoav Nir >> To: IPsecme WG >> Date: 10/20/2010 04:10 AM >> Subject: Re: [IPsec] Issue #194 - Security Considerations should disc= uss >> the threat >> Sent by: ipsec-bounces@ietf.org >>=20 >>=20 >>=20 >> One week, and no replies... >>=20 >> I will leave this issue open unless I get some suggested security >> considerations text. >>=20 >> The first paragraph in section 10.1 says the following. What else is >> missing? >>=20 >> Tokens MUST be hard to guess. This is critical, because if an >> attacker can guess the token associated with an IKE SA, she can tear >> down the IKE SA and associated tunnels at will. When the token is >> delivered in the IKE_AUTH exchange, it is encrypted. When it is sent >> again in an unprotected notification, it is not, but that is the last >> time this token is ever used. >>=20 >> Yoav >>=20 >> On Oct 11, 2010, at 8:22 AM, Yoav Nir wrote: >>=20 >>> Yaron: The security considerations are focused on details of the QCD >> solution, rather then on the threats we are dealing with. These threats = are >> non-trivial to describe, since an active MITM attacker can easily cause = an >> IKE SA to be reset. OTOH, we don't want an active non-MITM attacker to b= e >> able to do so. We need to analyze the threats in order to select a secur= e, >> but not overly complex solution. >>>=20 >>>=20 >>>=20 >>> Suggested text would be most welcome. >>>=20 >>> Yoav >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>>=20 >>> Scanned by Check Point Total Security Gateway. >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From yaronf.ietf@gmail.com Wed Oct 20 07:19: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 B85CB3A6848 for ; Wed, 20 Oct 2010 07:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH7mqCti13+z for ; Wed, 20 Oct 2010 07:19:41 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 319E43A67D9 for ; Wed, 20 Oct 2010 07:19:41 -0700 (PDT) Received: by bwz14 with SMTP id 14so2891050bwz.31 for ; Wed, 20 Oct 2010 07:21:14 -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=xgJE5AyfE5HciCFnYzAwIeAzXVelKKk8KY9BLbhHqKk=; b=wZOLP+iScnpsPNYnNaKqOgUFGtji3W9/WEi9+w2nR9I+SIom1N/hKXZI5AvJCXhmav d2rSdL01TuRd5vLIK1sfeGE/w9lereaf0m0fdLNMHmQWF/sa/I9ia/JcrQV4q37Zb6ys s424O0HhWE/sgUNksyKX65iLUH2eaE+4qSHZo= 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=PaHOTNBIY3apya3+MXk8ufY+nfmrJm3tjGs7HvvQW86Ovb8BLqiWjAUx4hITh6kA4Y gE/aSd/ghIQeRMJJzB8Pxs18yMRDEzi8JOQikwTNnqmEL3LnDUFdgdwf1QLb+WhI9nKj qk+3ru0ULcIuObKzWNDx4MrN0m2QzUiiEMK00= Received: by 10.204.54.68 with SMTP id p4mr6819348bkg.184.1287584473605; Wed, 20 Oct 2010 07:21:13 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-179-22-84.red.bezeqint.net [79.179.22.84]) by mx.google.com with ESMTPS id p34sm213276bkf.3.2010.10.20.07.21.08 (version=SSLv3 cipher=RC4-MD5); Wed, 20 Oct 2010 07:21:10 -0700 (PDT) Message-ID: <4CBEFAD2.1050303@gmail.com> Date: Wed, 20 Oct 2010 16:21:06 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100922 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Yoav Nir References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD43B7@il-ex01.ad.checkpoint.com> <57568731-A4E2-4876-8B54-876AD95D1A40@checkpoint.com> <4CBEF2D5.8080903@gmail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , David Wierbowski Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss the threat X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 20 Oct 2010 14:19:42 -0000 In fact I was referring to the whole extension. OK, since you're forcing my hand... General The mechanism must not reduce the security of IKEv2 or IPsec. Specifically, an eavesdropper must not learn any non-public information about the peers. DoS Resistance The proposed mechanism should be secure against attacks by a passive MITM (eavesdropper). Such an attacker must not be able to disrupt an existing IKE session, either by resetting the session or by introducing significant delays. The mechanism need not be similarly secure against an active MITM, since this type of attacker is already able to disrupt IKE sessions. Thanks, Yaron On 10/20/2010 03:58 PM, Yoav Nir wrote: > OK. I did not understand that this was about 5.2 rather than the whole extension. > > In that case, does section 10.4 address this? If not, can you suggest some text? > > Yoav > > On Oct 20, 2010, at 3:47 PM, Yaron Sheffer wrote: > >> Hi Dave, >> >> an active MITM, i.e. the sys admin at your local Starbucks, needs to >> only drop a few packets of an open IKE SA (a few retransmissions) for >> the peers to decide that they have a problem and attempt to renegotiate >> the SA. This attack is trivial to mount if you're at the right spot. >> >> On the other hand, Sec. 5.2 of the document is designed to prevent >> another kind of DoS attack that eventually does the same thing: resets >> the SA. >> >> So we need to explain why we add a mechanism to prevent one kind of DoS >> attacks even though we have other potential DoS issues. I'm not saying >> this is wrong, I'm saying it needs to be rationalized. >> >> Thanks, >> Yaron >> >> On 10/20/2010 02:57 PM, David Wierbowski wrote: >>> I'm not sure I understand Yaron's concern. Yaron, can you elaborate how a >>> MITM attacker can easily cause an IKE SA to be reset? I would think he >>> could only do so if he hi-jacked the original IKE_SA negotiation and is >>> now impersonating the remote security endpoint. In that case you have >>> bigger issues. >>> >>> Dave Wierbowski >>> >>> >>> >>> >>> From: Yoav Nir >>> To: IPsecme WG >>> Date: 10/20/2010 04:10 AM >>> Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss >>> the threat >>> Sent by: ipsec-bounces@ietf.org >>> >>> >>> >>> One week, and no replies... >>> >>> I will leave this issue open unless I get some suggested security >>> considerations text. >>> >>> The first paragraph in section 10.1 says the following. What else is >>> missing? >>> >>> Tokens MUST be hard to guess. This is critical, because if an >>> attacker can guess the token associated with an IKE SA, she can tear >>> down the IKE SA and associated tunnels at will. When the token is >>> delivered in the IKE_AUTH exchange, it is encrypted. When it is sent >>> again in an unprotected notification, it is not, but that is the last >>> time this token is ever used. >>> >>> Yoav >>> >>> On Oct 11, 2010, at 8:22 AM, Yoav Nir wrote: >>> >>>> Yaron: The security considerations are focused on details of the QCD >>> solution, rather then on the threats we are dealing with. These threats are >>> non-trivial to describe, since an active MITM attacker can easily cause an >>> IKE SA to be reset. OTOH, we don't want an active non-MITM attacker to be >>> able to do so. We need to analyze the threats in order to select a secure, >>> but not overly complex solution. >>>> >>>> >>>> >>>> Suggested text would be most welcome. >>>> >>>> Yoav >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>> >>>> Scanned by Check Point Total Security Gateway. >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. > From ynir@checkpoint.com Wed Oct 20 07:48: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 22D063A67D3 for ; Wed, 20 Oct 2010 07:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIRT7ukOP2pP for ; Wed, 20 Oct 2010 07:48:45 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id CEDA23A69D0 for ; Wed, 20 Oct 2010 07:37:02 -0700 (PDT) X-CheckPoint: {4CBEFCF8-10000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o9KEbiIk016902 for ; Wed, 20 Oct 2010 16:37:44 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 20 Oct 2010 16:37:44 +0200 From: Yoav Nir To: IPsecme WG Date: Wed, 20 Oct 2010 16:37:42 +0200 Thread-Topic: Ticket #195 - Protection against SPI enumeration Thread-Index: ActwZFswLg2vhx2ESBmfRmn0NyQFRg== Message-ID: <2DB4C303-E240-45A0-8964-3A38C56BD18C@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Ticket #195 - Protection against SPI enumeration X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 20 Oct 2010 14:48:45 -0000 Yaron: 10.3: of course, it is possible that *both* implementations generate= predictable/short SPI values Hi all.=20 I think this one was solved together with ticket #191 ("The danger of predi= ctable SPIs"), but requiring that the token maker randomize IKE SPIs. Unless somebody (like Yaron) objects within the next few days, I will close= this issue as well. And yes, Yaron, I have made the language about the PRNG less "wimpy". Yoav= From wierbows@us.ibm.com Wed Oct 20 08:16:13 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 2801C3A681E for ; Wed, 20 Oct 2010 08:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lt8z5dPy71HD for ; Wed, 20 Oct 2010 08:16:09 -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 C7D643A67D3 for ; Wed, 20 Oct 2010 08:16:08 -0700 (PDT) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e1.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o9KFAQ8w010322 for ; Wed, 20 Oct 2010 11:10:26 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o9KFHcCI2068614 for ; Wed, 20 Oct 2010 11:17:38 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o9KFHcqk025725 for ; Wed, 20 Oct 2010 11:17:38 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o9KFHcpU025722; Wed, 20 Oct 2010 11:17:38 -0400 In-Reply-To: <4CBEFAD2.1050303@gmail.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD43B7@il-ex01.ad.checkpoint.com> <57568731-A4E2-4876-8B54-876AD95D1A40@checkpoint.com> <4CBEF2D5.8080903@gmail.com> <4CBEFAD2.1050303@gmail.com> X-KeepSent: 9311D01B:52405777-852577C2:0050F845; type=4; name=$KeepSent To: Yaron Sheffer X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: David Wierbowski Date: Wed, 20 Oct 2010 11:17:37 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 10/20/2010 11:17:38 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: IPsecme WG , Yoav Nir Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss the threat X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 20 Oct 2010 15:16:13 -0000 Yaron/Yoav, Thanks for your answers, but I should have been more specific in my question. I was not asking how a MITM could break IKE. I was asking for an example of how draft-ietf-ipsecme-failure-detection-01 increases the risk over what we have today in IKE. That's what I'm not seeing. An eavesdropper could see an IKE request (e.g. CREATE_CHILD_SA request) and forge an informational message back to the requester containing N (INVALID_IKE_SPI) and N(QCD_TOKEN). If he guesses QCD_TOKEN correctly he can disrupt the IKE_SA and force a negotiation. So in theory this makes IKE more prone to a passive MITM, but that's theory. Given significant randomness in the token the attack is not feasible. If there's a flaw in the RFC that makes tokens easy to guess this would be a valid attack. True, if we do not mandate the algorithm somebody can implement a token generation scheme that is easy to guess. Yaron are you saying that we need to explain the possible attack so one does not implement a trivial token generation algorithm? I tend to agree with Yoav, that we do that in the first paragraph of 10.1. Even with your forced hand I'm not sure what you are looking for :>), Do you know of a way that the draft allows an attacker to disrupt an existing IKE session or learn of non-public information about the peers? Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 From: Yaron Sheffer To: Yoav Nir Cc: David Wierbowski/Endicott/IBM@IBMUS, IPsecme WG Date: 10/20/2010 10:21 AM Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss the threat In fact I was referring to the whole extension. OK, since you're forcing my hand... General The mechanism must not reduce the security of IKEv2 or IPsec. Specifically, an eavesdropper must not learn any non-public information about the peers. DoS Resistance The proposed mechanism should be secure against attacks by a passive MITM (eavesdropper). Such an attacker must not be able to disrupt an existing IKE session, either by resetting the session or by introducing significant delays. The mechanism need not be similarly secure against an active MITM, since this type of attacker is already able to disrupt IKE sessions. Thanks, Yaron On 10/20/2010 03:58 PM, Yoav Nir wrote: > OK. I did not understand that this was about 5.2 rather than the whole extension. > > In that case, does section 10.4 address this? If not, can you suggest some text? > > Yoav > > On Oct 20, 2010, at 3:47 PM, Yaron Sheffer wrote: > >> Hi Dave, >> >> an active MITM, i.e. the sys admin at your local Starbucks, needs to >> only drop a few packets of an open IKE SA (a few retransmissions) for >> the peers to decide that they have a problem and attempt to renegotiate >> the SA. This attack is trivial to mount if you're at the right spot. >> >> On the other hand, Sec. 5.2 of the document is designed to prevent >> another kind of DoS attack that eventually does the same thing: resets >> the SA. >> >> So we need to explain why we add a mechanism to prevent one kind of DoS >> attacks even though we have other potential DoS issues. I'm not saying >> this is wrong, I'm saying it needs to be rationalized. >> >> Thanks, >> Yaron >> >> On 10/20/2010 02:57 PM, David Wierbowski wrote: >>> I'm not sure I understand Yaron's concern. Yaron, can you elaborate how a >>> MITM attacker can easily cause an IKE SA to be reset? I would think he >>> could only do so if he hi-jacked the original IKE_SA negotiation and is >>> now impersonating the remote security endpoint. In that case you have >>> bigger issues. >>> >>> Dave Wierbowski >>> >>> >>> >>> >>> From: Yoav Nir >>> To: IPsecme WG >>> Date: 10/20/2010 04:10 AM >>> Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss >>> the threat >>> Sent by: ipsec-bounces@ietf.org >>> >>> >>> >>> One week, and no replies... >>> >>> I will leave this issue open unless I get some suggested security >>> considerations text. >>> >>> The first paragraph in section 10.1 says the following. What else is >>> missing? >>> >>> Tokens MUST be hard to guess. This is critical, because if an >>> attacker can guess the token associated with an IKE SA, she can tear >>> down the IKE SA and associated tunnels at will. When the token is >>> delivered in the IKE_AUTH exchange, it is encrypted. When it is sent >>> again in an unprotected notification, it is not, but that is the last >>> time this token is ever used. >>> >>> Yoav >>> >>> On Oct 11, 2010, at 8:22 AM, Yoav Nir wrote: >>> >>>> Yaron: The security considerations are focused on details of the QCD >>> solution, rather then on the threats we are dealing with. These threats are >>> non-trivial to describe, since an active MITM attacker can easily cause an >>> IKE SA to be reset. OTOH, we don't want an active non-MITM attacker to be >>> able to do so. We need to analyze the threats in order to select a secure, >>> but not overly complex solution. >>>> >>>> >>>> >>>> Suggested text would be most welcome. >>>> >>>> Yoav >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>> >>>> Scanned by Check Point Total Security Gateway. >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. > From kent@bbn.com Wed Oct 20 08:23: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 53EE13A6841 for ; Wed, 20 Oct 2010 08:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.411 X-Spam-Level: X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eA39htd-J-S3 for ; Wed, 20 Oct 2010 08:23:53 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 59C623A683F for ; Wed, 20 Oct 2010 08:23:53 -0700 (PDT) Received: from dhcp89-089-159.bbn.com ([128.89.89.159]:49196) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1P8aXe-0004A7-9z; Wed, 20 Oct 2010 11:25:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <2DB4C303-E240-45A0-8964-3A38C56BD18C@checkpoint.com> References: <2DB4C303-E240-45A0-8964-3A38C56BD18C@checkpoint.com> Date: Wed, 20 Oct 2010 11:01:28 -0400 To: Yoav Nir From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: IPsecme WG Subject: Re: [IPsec] Ticket #195 - Protection against SPI enumeration X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 20 Oct 2010 15:23:54 -0000 At 4:37 PM +0200 10/20/10, Yoav Nir wrote: >Yaron: 10.3: of course, it is possible that *both* implementations >generate predictable/short SPI values > > >Hi all. > >I think this one was solved together with ticket #191 ("The danger >of predictable SPIs"), but requiring that the token maker randomize >IKE SPIs. > >Unless somebody (like Yaron) objects within the next few days, I >will close this issue as well. > >And yes, Yaron, I have made the language about the PRNG less "wimpy". > >Yoav Why not allow either peer (or both) to add a sizeable nonce as a separate source of unpredictable data? Steve From julienl@qualcomm.com Wed Oct 20 09:42:48 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 8F5FF3A69F5 for ; Wed, 20 Oct 2010 09:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.515 X-Spam-Level: X-Spam-Status: No, score=-106.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgODdlKrw8sm for ; Wed, 20 Oct 2010 09:42:47 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 0BE313A69FD for ; Wed, 20 Oct 2010 09:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1287592847; x=1319128847; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"ipsec@ietf.org"=20|CC:=20"draft-e balard-mext-pfkey-enhanced-migrate@tools.ietf.org"=0D=0A =09,=20Jari=20Arkko=0D=0A=09|Date: =20Wed,=2020=20Oct=202010=2009:40:45=20-0700|Subject:=20R eview=20of=20PF_KEY=20extension|Thread-Topic:=20Review=20 of=20PF_KEY=20extension|Thread-Index:=20ActwdYsqdR6mVCN4R gi+JMstBkMMGg=3D=3D|Message-ID:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=l6HsdxzNAU5L6eA07V9TrkA9a/ZKjT7+QTd6xd0vUS4=; b=P6lt9Vti+ur/NYvtwlvucnJ5eKMF7Wab/QlmtDX/ovHyL8/GNRjmvVGt N4OTBJ4a+J5sdHWQ2+1B66+2pJoSD1UrbsqATvLafT7ys3Egm9b8fAkXm yWOGmk0R6oOYWv4Z5jTAVvNUOMXKbaw1g1kr+i5Tc3wM58YvZ87VEtQ0f M=; X-IronPort-AV: E=McAfee;i="5400,1158,6142"; a="58569642" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 20 Oct 2010 09:40:47 -0700 X-IronPort-AV: E=Sophos;i="4.57,354,1283756400"; d="scan'208";a="21530787" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 20 Oct 2010 09:40:47 -0700 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 20 Oct 2010 09:40:39 -0700 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 20 Oct 2010 09:40:54 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Wed, 20 Oct 2010 09:40:53 -0700 From: "Laganier, Julien" To: "ipsec@ietf.org" Date: Wed, 20 Oct 2010 09:40:45 -0700 Thread-Topic: Review of PF_KEY extension Thread-Index: ActwdYsqdR6mVCN4Rgi+JMstBkMMGg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ebalard-mext-pfkey-enhanced-migrate@tools.ietf.org" , Jari Arkko Subject: [IPsec] Review of PF_KEY extension X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 20 Oct 2010 16:42:48 -0000 Folks, We are trying to get this PF_KEY extension document published as an Informa= tional RFC and it would be beneficial if some IPsec experts on this list co= uld help us by reviewing the document. Please let me know if you are willing to review the document.=20 Thanks. --julien PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE draft-ebalard-mext-pfkey-enhanced-migrate-01 Abstract This document describes the need for an interface between Mobile IPv6 and IPsec/IKE and shows how the two protocols can interwork. An extension of the PF_KEY framework is proposed which allows smooth and solid operation of IPsec/IKE in a Mobile IPv6 environment. PF_KEY MIGRATE message serves as a carrier for updated information for both the in-kernel IPsec structures (Security Policy Database / Security Association Database) and those maintained by the key managers. This includes in-kernel Security Policy / Security Association endpoints, key manager maintained equivalents, and addresses used by IKE_SA (current and to be negotiated). The extension is helpful for assuring smooth interworking between Mobile IPv6 and IPsec/IKE for the bootstrapping of mobile nodes and their movements. From jari.arkko@piuha.net Wed Oct 20 10:00: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 DA8323A6984 for ; Wed, 20 Oct 2010 10:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdY8bEnu1ua1 for ; Wed, 20 Oct 2010 10:00:04 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E18C53A69D2 for ; Wed, 20 Oct 2010 10:00:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8EACC2CC32; Wed, 20 Oct 2010 20:01:36 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1KJ1ZgX2qxg; Wed, 20 Oct 2010 20:01:35 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 95EFA2CC2F; Wed, 20 Oct 2010 20:01:35 +0300 (EEST) Message-ID: <4CBF206F.7020802@piuha.net> Date: Wed, 20 Oct 2010 20:01:35 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: "Laganier, Julien" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , "draft-ebalard-mext-pfkey-enhanced-migrate@tools.ietf.org" Subject: Re: [IPsec] Review of PF_KEY extension X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 20 Oct 2010 17:00:04 -0000 A review from an IPsec implementation perspective would indeed be much appreciated. For background, my AD review is here http://www.ietf.org/mail-archive/web/mext/current/msg04450.html Jari From ietf-ipsec@m.gmane.org Wed Oct 20 13:03:33 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 A66823A68BE for ; Wed, 20 Oct 2010 13:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 A+mvGwqCAOq0 for ; Wed, 20 Oct 2010 13:03:32 -0700 (PDT) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by core3.amsl.com (Postfix) with ESMTP id 6B44E3A67AB for ; Wed, 20 Oct 2010 13:03:32 -0700 (PDT) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P8euG-0001Ly-N8 for ipsec@ietf.org; Wed, 20 Oct 2010 22:05:04 +0200 Received: from copper.chdir.org ([88.191.97.87]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Oct 2010 22:05:04 +0200 Received: from arno by copper.chdir.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Oct 2010 22:05:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ipsec@ietf.org From: arno@natisbad.org (Arnaud Ebalard) Date: Wed, 20 Oct 2010 21:59:15 +0200 Lines: 26 Message-ID: <87wrpcocto.fsf@small.ssi.corp> References: <4CBF206F.7020802@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: copper.chdir.org X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: D3A5 B68A 839B 38A5 815A 781B B77C 0748 A7AE 341B User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:B2FZmpWRqanFmwaKvkfkoi4PKXM= Subject: Re: [IPsec] Review of PF_KEY extension X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 20 Oct 2010 20:03:33 -0000 Hi, Jari Arkko writes: > A review from an IPsec implementation perspective would indeed be much > appreciated. Yes. > For background, my AD review is here > http://www.ietf.org/mail-archive/web/mext/current/msg04450.html My reply to those comments is in the thread pointed by Jari: http://www.ietf.org/mail-archive/web/mext/current/msg04453.html The latest of version of the draft (including corrections associated with Jari's comments) is here (in txt or xml): http://hg.natisbad.org/migrate2_draft/file/ I will wait for additional comments before making it a v2. Cheers, a+ From yaronf.ietf@gmail.com Wed Oct 20 13:31:17 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 6A8CA3A6911 for ; Wed, 20 Oct 2010 13:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9lWmpFsDHZB for ; Wed, 20 Oct 2010 13:31:14 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 209183A6936 for ; Wed, 20 Oct 2010 13:31:09 -0700 (PDT) Received: by bwz14 with SMTP id 14so3249492bwz.31 for ; Wed, 20 Oct 2010 13:32:43 -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=8efHlqPkYwVlnzQ44dUnDvKs5um4I4vonkrqTK6q1JQ=; b=FCudHtP/rYCI/LzGi4lGlrRYJobqtnZJxbxR5802N6nDllmtc26Qnl7EzXdHaeweNF 4SgQCIuf88r/lHh7LKkbI8pPDJ3Hml4nFzIzNSaCb3Fzj6e3C7stMAF8IB4f/iWO4r6L 9wO8xlH9o46s86x2LQZUFT1QYlLmwAz79UK1c= 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=QxigJMkWyB7wgz7dJY3wzU/i4emUHBf/QQ0bHx2qGdRRUv9h7gbNNjqnS8+TBFOfgP XdUr69V9ThmwNUddqhTHs3pRqTM9h76laatKs848AMYvB3Tap+k8y5/wEM6AEbqLPnAj qH7aLuE+0Njve5J5vfnUz7O2aHWQBu2f5+EJg= Received: by 10.204.101.84 with SMTP id b20mr2549630bko.53.1287606761248; Wed, 20 Oct 2010 13:32:41 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-179-22-84.red.bezeqint.net [79.179.22.84]) by mx.google.com with ESMTPS id d12sm534462bkw.7.2010.10.20.13.32.38 (version=SSLv3 cipher=RC4-MD5); Wed, 20 Oct 2010 13:32:39 -0700 (PDT) Message-ID: <4CBF51E4.6070403@gmail.com> Date: Wed, 20 Oct 2010 22:32:36 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100922 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: David Wierbowski References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD43B7@il-ex01.ad.checkpoint.com> <57568731-A4E2-4876-8B54-876AD95D1A40@checkpoint.com> <4CBEF2D5.8080903@gmail.com> <4CBEFAD2.1050303@gmail.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Yoav Nir Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss the threat X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 20 Oct 2010 20:31:17 -0000 Hi Dave, if I had known of such an attack, you'd be the first to know :-) Seriously, I didn't like the approach in Sec. 10, where you start from the solution and "nitpick" some of its aspects. I would have preferred a top-down approach, where you start with a set of security goals and demonstrate (to the best of our collective abilities) that they are achieved. Your approach is certainly legitimate - these are "security considerations", not a security analysis. But I think the alternative might result in a better analysis and a more secure solution. Let me just remind you that the "significant randomness" has only been added in the latest version of this draft. Thanks, Yaron On 10/20/2010 05:17 PM, David Wierbowski wrote: > Yaron/Yoav, > > Thanks for your answers, but I should have been more specific in my > question. I was not asking how a MITM could break IKE. I was asking for > an example of how draft-ietf-ipsecme-failure-detection-01 increases the > risk over what we have today in IKE. That's what I'm not seeing. > > An eavesdropper could see an IKE request (e.g. CREATE_CHILD_SA request) > and forge an informational message back to the requester containing N > (INVALID_IKE_SPI) and N(QCD_TOKEN). If he guesses QCD_TOKEN correctly he > can disrupt the IKE_SA and force a negotiation. So in theory this makes > IKE more prone to a passive MITM, but that's theory. Given significant > randomness in the token the attack is not feasible. If there's a flaw in > the RFC that makes tokens easy to guess this would be a valid attack. > True, if we do not mandate the algorithm somebody can implement a token > generation scheme that is easy to guess. > > Yaron are you saying that we need to explain the possible attack so one > does not implement a trivial token generation algorithm? I tend to agree > with Yoav, that we do that in the first paragraph of 10.1. Even with your > forced hand I'm not sure what you are looking for :>), > > Do you know of a way that the draft allows an attacker to disrupt an > existing IKE session or learn of non-public information about the peers? > > Dave Wierbowski > > > z/OS Comm Server Developer > > Phone: > Tie line: 620-4055 > External: 607-429-4055 > > > > > > > From: Yaron Sheffer > To: Yoav Nir > Cc: David Wierbowski/Endicott/IBM@IBMUS, IPsecme WG > > Date: 10/20/2010 10:21 AM > Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss > the threat > > > > In fact I was referring to the whole extension. OK, since you're forcing > my hand... > > General > > The mechanism must not reduce the security of IKEv2 or IPsec. > Specifically, an eavesdropper must not learn any non-public information > about the peers. > > DoS Resistance > > The proposed mechanism should be secure against attacks by a passive > MITM (eavesdropper). Such an attacker must not be able to disrupt an > existing IKE session, either by resetting the session or by introducing > significant delays. > > The mechanism need not be similarly secure against an active MITM, since > this type of attacker is already able to disrupt IKE sessions. > > Thanks, > Yaron > > On 10/20/2010 03:58 PM, Yoav Nir wrote: >> OK. I did not understand that this was about 5.2 rather than the whole > extension. >> >> In that case, does section 10.4 address this? If not, can you suggest > some text? >> >> Yoav >> >> On Oct 20, 2010, at 3:47 PM, Yaron Sheffer wrote: >> >>> Hi Dave, >>> >>> an active MITM, i.e. the sys admin at your local Starbucks, needs to >>> only drop a few packets of an open IKE SA (a few retransmissions) for >>> the peers to decide that they have a problem and attempt to renegotiate >>> the SA. This attack is trivial to mount if you're at the right spot. >>> >>> On the other hand, Sec. 5.2 of the document is designed to prevent >>> another kind of DoS attack that eventually does the same thing: resets >>> the SA. >>> >>> So we need to explain why we add a mechanism to prevent one kind of DoS >>> attacks even though we have other potential DoS issues. I'm not saying >>> this is wrong, I'm saying it needs to be rationalized. >>> >>> Thanks, >>> Yaron >>> >>> On 10/20/2010 02:57 PM, David Wierbowski wrote: >>>> I'm not sure I understand Yaron's concern. Yaron, can you elaborate > how a >>>> MITM attacker can easily cause an IKE SA to be reset? I would think he >>>> could only do so if he hi-jacked the original IKE_SA negotiation and > is >>>> now impersonating the remote security endpoint. In that case you have >>>> bigger issues. >>>> >>>> Dave Wierbowski >>>> >>>> >>>> >>>> >>>> From: Yoav Nir >>>> To: IPsecme WG >>>> Date: 10/20/2010 04:10 AM >>>> Subject: Re: [IPsec] Issue #194 - Security Considerations should > discuss >>>> the threat >>>> Sent by: ipsec-bounces@ietf.org >>>> >>>> >>>> >>>> One week, and no replies... >>>> >>>> I will leave this issue open unless I get some suggested security >>>> considerations text. >>>> >>>> The first paragraph in section 10.1 says the following. What else is >>>> missing? >>>> >>>> Tokens MUST be hard to guess. This is critical, because if an >>>> attacker can guess the token associated with an IKE SA, she can > tear >>>> down the IKE SA and associated tunnels at will. When the token is >>>> delivered in the IKE_AUTH exchange, it is encrypted. When it is > sent >>>> again in an unprotected notification, it is not, but that is the > last >>>> time this token is ever used. >>>> >>>> Yoav >>>> >>>> On Oct 11, 2010, at 8:22 AM, Yoav Nir wrote: >>>> >>>>> Yaron: The security considerations are focused on details of the QCD >>>> solution, rather then on the threats we are dealing with. These threats > are >>>> non-trivial to describe, since an active MITM attacker can easily cause > an >>>> IKE SA to be reset. OTOH, we don't want an active non-MITM attacker to > be >>>> able to do so. We need to analyze the threats in order to select a > secure, >>>> but not overly complex solution. >>>>> >>>>> >>>>> >>>>> Suggested text would be most welcome. >>>>> >>>>> Yoav >>>>> _______________________________________________ >>>>> IPsec mailing list >>>>> IPsec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>> >>>>> Scanned by Check Point Total Security Gateway. >>>> >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>> >>>> >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> Scanned by Check Point Total Security Gateway. >> > > From ynir@checkpoint.com Wed Oct 20 14:04:00 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 DCA9C3A6905 for ; Wed, 20 Oct 2010 14:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JoHCPi2qKGN for ; Wed, 20 Oct 2010 14:03:59 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 0E8FF3A6911 for ; Wed, 20 Oct 2010 14:03:58 -0700 (PDT) X-CheckPoint: {4CBF57D8-10000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o9KL5QhR022618; Wed, 20 Oct 2010 23:05:27 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 20 Oct 2010 23:05:26 +0200 From: Yoav Nir To: Stephen Kent Date: Wed, 20 Oct 2010 23:05:25 +0200 Thread-Topic: [IPsec] Ticket #195 - Protection against SPI enumeration Thread-Index: ActwmoSPY48KKfLzQouAWYh9Zvjmhg== Message-ID: <411FBDBD-82B0-4B21-8D99-A9892D02E0DD@checkpoint.com> References: <2DB4C303-E240-45A0-8964-3A38C56BD18C@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Ticket #195 - Protection against SPI enumeration X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 20 Oct 2010 21:04:01 -0000 On Oct 20, 2010, at 5:01 PM, Stephen Kent wrote: > At 4:37 PM +0200 10/20/10, Yoav Nir wrote: >> Yaron: 10.3: of course, it is possible that *both* implementations=20 >> generate predictable/short SPI values >>=20 >>=20 >> Hi all. >>=20 >> I think this one was solved together with ticket #191 ("The danger=20 >> of predictable SPIs"), but requiring that the token maker randomize=20 >> IKE SPIs. >>=20 >> Unless somebody (like Yaron) objects within the next few days, I=20 >> will close this issue as well. >>=20 >> And yes, Yaron, I have made the language about the PRNG less "wimpy". >>=20 >> Yoav >=20 > Why not allow either peer (or both) to add a sizeable nonce as a separate > source of unpredictable data? >=20 Where would that nonce be used? The QCD token is first sent from the token maker to the token taker in the = IKE_AUTH exchange. Certainly we could add a nonce there, but what happens t= o the nonce then? The other time a QCD token is sent, is after the token maker has lost state= . It receives an IKE request, and in reply, it sends back an identical QCD = token. With this scheme, it has to be able to generate the token based on t= he IKE request alone. The only data that doesn't change for all requests fr= om a particular IKE SA are the IKE SPIs (and with no mobility, the IP addre= sses). So the QCD token can only depend on the IKE SPIs (and maybe the IP a= ddresses). Still, I can think of two ways to incorporate a nonce: The first is to have the token maker keep a persistent database of all the = IKE SAs and their associated nonces (although in that case, we'd probably c= all it a "salt"). Then when the request arrives, it retrieves the nonce for= this IKE SA and calculates the token. With an unknown IKE SPI, it generate= s random garbage so as not to let on that this is not a real IKE SA. But th= at would require a lot of persistent storage, and we might as well store th= e real IKE SA if we have access to that. The other way is to modify the protocol to something like this: - the (rebooted) token maker receives an unknown request - It sends just a N(UNKNOWN_IKE_SPI) - The token taker sends an unprotected QCD_TOKEN_REQUEST with the nonce an= d the SPIs - The token maker sends back the real QCD token, only if the IKE SPI is re= ally unknown. This could work, but it adds a round trip, and requires that the nonce be s= ent in the clear. I don't think it's worth it. Yoav From zhangdong_rh@huaweisymantec.com Thu Oct 21 00:33: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 C1A743A69F8 for ; Thu, 21 Oct 2010 00:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.542 X-Spam-Level: *** X-Spam-Status: No, score=3.542 tagged_above=-999 required=5 tests=[AWL=-2.766, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA3oXgzSyy9m for ; Thu, 21 Oct 2010 00:33:41 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id AE9833A69F4 for ; Thu, 21 Oct 2010 00:33:40 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LAM00LXCQEUUI90@hstga01-in.huaweisymantec.com> for ipsec@ietf.org; Thu, 21 Oct 2010 15:35:18 +0800 (CST) Received: from z90001956 ([10.27.154.169]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LAM004ZUQEG2Y10@hstml02-in.huaweisymantec.com> for ipsec@ietf.org; Thu, 21 Oct 2010 15:35:05 +0800 (CST) Date: Thu, 21 Oct 2010 15:35:03 +0800 From: Dong Zhang To: ipsec References: <20101018075543.AB6573A6934@core3.amsl.com> Message-id: <201010211535035909598@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Content-transfer-encoding: base64 Cc: zhangdacheng Subject: [IPsec] Fw: New Version Notification fordraft-zhang-ipsecme-distributed-redundancy-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 07:33:43 -0000 SGkgZm9sa3MsDQoNCldlIGhhdmUgcHVibGlzaGVkIGEgbmV3IGRyYWZ0Lg0KVGhlIG9iamVjdGl2 ZSBvZiB0aGUgZG9jdW1lbnQgaXMgdG8gcHJvdmlkZSBzb21lIHVzZWZ1bCBpbmZvcm1hdGlvbiBm b3IgZnV0dXJlIHdvcmsuIA0KSXQgaXMgdHJ5aW5nIHRvIGFuYWx5emUgdGhlIGhpZ2ggYXZhaWxh YmlsaXR5IGlzc3VlcyBvZiBsb29zZSBjbHVzdGVyIG9mIElQc2VjIGdhdGV3YXkuIFRoZSBkcmFm dCB0YWtlcyB0aGUgbG9vc2UgY2x1c3RlciBhcyBhIGRpc3RyaWJ1dGVkIGRlcGxveW1lbnQgc2Nl bmFyaW8uIFNldmVyYWwgdXNlIGNhc2VzIGFyZSBwb2ludGVkIG91dC4gQW5kIGFuIGFuYWx5c2lz IG9mIHRoZSBoaWdoIGF2YWlsYWJpbGl0eSBpc3N1ZXMgdW5kZXIgdGhpcyBzaXR1YXRpb24gYXJl IGRlc2NyaWJlZC4NCg0KV2VsY29tZSBjb21tZW50IQ0KDQpUaGFua3MNCi0tLS0tLS0tLS0tLS0t LS0tLQkJCQkgDQpEb25nIFpoYW5nDQoyMDEwLTEwLTIxDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCreivP7Iy6O6SUVURiBJ LUQgU3VibWlzc2lvbiBUb29sDQq3osvNyNXG2qO6MjAxMC0xMC0xOCAxNTo1NzoyMA0KytW8/sjL o7p6aGFuZ2RvbmdfcmhAaHVhd2Vpc3ltYW50ZWMuY29tDQqzrcvNo7p6aGFuZ2RhY2hlbmdAaHVh d2VpLmNvbQ0K1vfM4qO6TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcmRyYWZ0LXpoYW5nLWlw c2VjbWUtZGlzdHJpYnV0ZWQtcmVkdW5kYW5jeS0wMA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC16aGFuZy1pcHNlY21lLWRpc3RyaWJ1dGVkLXJlZHVuZGFuY3ktMDAudHh0IGhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRG9uZyBaaGFuZyBhbmQgcG9zdGVkIHRvIHRo ZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtemhhbmctaXBzZWNtZS1kaXN0 cmlidXRlZC1yZWR1bmRhbmN5DQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBSZWR1bmRhbmN5IENv bnNpZGVyYXRpb25zIGZvciBJUHNlYyBEaXN0cmlidXRlZCBkZXBsb3ltZW50DQpDcmVhdGlvbl9k YXRlOgkgMjAxMC0xMC0xOA0KV0cgSUQ6CQkgSW5kZXBlbmRlbnQgU3VibWlzc2lvbg0KTnVtYmVy X29mX3BhZ2VzOiAxMA0KDQpBYnN0cmFjdDoNClRoaXMgaW5mb3JtYXRpb25hbCBkb2N1bWVudCBh dHRlbXB0cyB0byBhbmFseXplIHNldmVyYWwgY3JpdGljYWwNCmlzc3VlcyB3aXRoIGZhaWxvdmVy IG9mIElQU2VjIEdhdGV3YXlzIChJRykgZGlzdHJpYnV0ZWQgYWNyb3NzDQpkaWZmZXJlbnQgbmV0 d29ya3MuICBBZGRpdGlvbmFsbHksIHNldmVyYWwgY2FuZGlkYXRlIGFwcHJvYWNoZXMgdG8NCnN1 Y2ggaXNzdWVzIGFyZSBsaXN0ZWQgYW5kIGNvbXBhcmVkLiAgVGhlIG9iamVjdGl2ZSBvZiB0aGlz IHdvcmsgaXMNCnRvIHByb3ZpZGUgdXNlZnVsIGluZm9ybWF0aW9uIGZvciB0aGUgZnV0dXJlIHJl c2VhcmNoIGluIHRoZSBmYWlsb3Zlcg0Kb2YgbXVsdGlwbGUgZ2VvZ3JhcGhpY2FsbHkgZGlzdHJp YnV0ZWQgSUdzLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0Lg0KDQoNCg== From kivinen@iki.fi Thu Oct 21 02:58:25 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 CDF2D3A6857 for ; Thu, 21 Oct 2010 02:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhkWlDA2D3Ru for ; Thu, 21 Oct 2010 02:58:23 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id AF5623A694A for ; Thu, 21 Oct 2010 02:58:22 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o9L9xmsC010730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2010 12:59:48 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o9L9xkLr012935; Thu, 21 Oct 2010 12:59:46 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19648.3858.260532.88878@fireball.kivinen.iki.fi> Date: Thu, 21 Oct 2010 12:59:46 +0300 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD43B7@il-ex01.ad.checkpoint.com> <57568731-A4E2-4876-8B54-876AD95D1A40@checkpoint.com> <4CBEF2D5.8080903@gmail.com> <4CBEFAD2.1050303@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 42 min Cc: IPsecme WG , Yoav Nir Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss the threat X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 21 Oct 2010 09:58:26 -0000 David Wierbowski writes: > Thanks for your answers, but I should have been more specific in my > question. I was not asking how a MITM could break IKE. I was asking for > an example of how draft-ietf-ipsecme-failure-detection-01 increases the > risk over what we have today in IKE. That's what I'm not seeing. If the QCD token generation secret is shared with multiple hosts which do NOT share the same IKE SA state then there are attacks which are not possible without QCD. > An eavesdropper could see an IKE request (e.g. CREATE_CHILD_SA request) > and forge an informational message back to the requester containing N > (INVALID_IKE_SPI) and N(QCD_TOKEN). If he guesses QCD_TOKEN correctly he > can disrupt the IKE_SA and force a negotiation. So in theory this makes > IKE more prone to a passive MITM, but that's theory. Given significant > randomness in the token the attack is not feasible. If there's a flaw in > the RFC that makes tokens easy to guess this would be a valid attack. > True, if we do not mandate the algorithm somebody can implement a token > generation scheme that is easy to guess. There has been talks here in the list about cases where we have loose cluster which do not share same IKE SA state, but which do share QCD token generation secrets. Such clusters would be vulnerable to this kind of attacks regardless whether the token generation contains token takers IP number or not. The attack simply needs to fake one IKE SA message so that its source IP is the real source ip of the host attacker wants to attack, send it to the cluster member which do not have the IKE SA state for that IKE SA, and then see the QCD reply sent by the cluster member. This reply now contains the QCD token which can then be used to attack the host. Actually normally when that packet reaches its final destination the host will tear down its IKE SA anyways. So attacker just need to know the IKE SA SPI pair and the IP addresses of the valid IKE SA on one cluster member and then send any faked IKE message to another cluster member sharing same QCD token generation secret, but separate IKE SA database. The section 10.4 seems to assume that attacker cannot force the load balancer to send the faked packet to any other cluster member than the one mapped by the source IP-address of the packet. As the algorithm how the load balancer really selects the peer where it sends the packet is not necessarely known by the IPsec implementations, I do not think we can trust we can include all same information to the token generation. For example it could use source port numbers, or destination IP-address, etc so I think it is quite unsafe to assume anything what the load balancer might do. I think it would be safer to forbid situations where the cluster members share the same QCD token unless they also share the IKE SA state. -- kivinen@iki.fi From ynir@checkpoint.com Thu Oct 21 03:32:02 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 125223A694F for ; Thu, 21 Oct 2010 03:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8H92aUQxAaB6 for ; Thu, 21 Oct 2010 03:31:57 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 6CB883A68D0 for ; Thu, 21 Oct 2010 03:31:54 -0700 (PDT) X-CheckPoint: {4CC0152B-10000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o9LAXOgl001271; Thu, 21 Oct 2010 12:33:24 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 21 Oct 2010 12:33:24 +0200 From: Yoav Nir To: Tero Kivinen Date: Thu, 21 Oct 2010 12:33:22 +0200 Thread-Topic: [IPsec] Issue #194 - Security Considerations should discuss the threat Thread-Index: ActxC2NKNPJGzc16QKS6/R81/obefQ== Message-ID: <97606E95-19E2-472E-BAA6-DAA5F3DECD84@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD43B7@il-ex01.ad.checkpoint.com> <57568731-A4E2-4876-8B54-876AD95D1A40@checkpoint.com> <4CBEF2D5.8080903@gmail.com> <4CBEFAD2.1050303@gmail.com> <19648.3858.260532.88878@fireball.kivinen.iki.fi> In-Reply-To: <19648.3858.260532.88878@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , David Wierbowski Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss the threat X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 21 Oct 2010 10:32:02 -0000 On Oct 21, 2010, at 11:59 AM, Tero Kivinen wrote: > The section 10.4 seems to assume that attacker cannot force the load > balancer to send the faked packet to any other cluster member than the > one mapped by the source IP-address of the packet. As the algorithm > how the load balancer really selects the peer where it sends the > packet is not necessarely known by the IPsec implementations, I do not > think we can trust we can include all same information to the token > generation. I agree, although I suspect some of my co-authors might not. > For example it could use source port numbers, or destination > IP-address, etc so I think it is quite unsafe to assume anything what > the load balancer might do. >=20 > I think it would be safer to forbid situations where the cluster > members share the same QCD token unless they also share the IKE SA > state. I agree that there is a problem that needs solving here, but I also see som= e great utility in allowing QCD on such configurations. In a hot-standby cluster, you can have QCD instead of synchronizing state. = When one gateway fails, the other takes over immediately (or in less than o= ne second). This is like a reboot, but instantaneous, and it's easier and c= heaper to implement than a real cluster with state synchronization - you on= ly need to make sure that the QCD token secret is the same. In this configu= ration you don't have a problem, unless there's a way to get responses out = of the standby member before it becomes active.=20 If you also want to achieve scalability with your cluster, you implement lo= ad sharing. There is no state synch, but in case one of the gateways fails,= we want the other to be able to use QCD to quickly destroy the existing IK= E SAs. Again, if I can get one member to generate a token for an IKE SA own= ed by another gateway, the attacker wins. I'd say that this requires some v= ery big assumptions for the load balancer anyway (for example, that without= a failure, all IKE traffic for a particular SA goes to the same gateway, a= nd even after a failure, old IKE SAs owned by other gateways remain with th= eir respective gateways). We might need some interesting text to describe t= he requirements there. I think I will close #194, and open a new one that makes the contentious po= int clearer. From ynir@checkpoint.com Thu Oct 21 04:17: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 B530F3A6874 for ; Thu, 21 Oct 2010 04:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 ayFysYTIax6w for ; Thu, 21 Oct 2010 04:17:52 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id BE3863A689F for ; Thu, 21 Oct 2010 04:17:49 -0700 (PDT) X-CheckPoint: {4CC01FF1-10000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o9LBJNMR009853 for ; Thu, 21 Oct 2010 13:19:23 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 21 Oct 2010 13:19:23 +0200 From: Yoav Nir To: IPsecme WG Date: Thu, 21 Oct 2010 13:19:22 +0200 Thread-Topic: Issue #197 - More text needed to describe RFC4306^H^H^H^H5996 recovery Thread-Index: ActxEc/dXFkaAakrRzObLofZY6kZsQ== Message-ID: <55E5000D-A2ED-4402-A73A-AB3CAE086C1C@checkpoint.com> References: <19591.24647.497524.822377@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Issue #197 - More text needed to describe RFC4306^H^H^H^H5996 recovery X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 21 Oct 2010 11:17:54 -0000 Hi all. Tero Kivinen sent the message included below to the mailing list on= September 8th. I am fine with this text. Please read it thoroughly, and if there are no objections, I will incorpora= te it into the next version of the draft (which I intend to publish at the = last possible moment on Monday) Yoav Begin forwarded message: > From: Tero Kivinen > Date: September 8, 2010 1:07:03 PM GMT+03:00 > To: "ipsec@ietf.org" > Subject: [IPsec] Comments to draft-ietf-ipsecme-failure-detection-00 >=20 > The section 2 describing RFC4306 crash recovery is not complete. It > does not include the normal processing happining on the peer that is > not rebooting. >=20 > I suggest adding following text: > ---------------------------------------------------------------------- > When the one peer loses state or reboots it might not be able to > recover immediately (especially in case of reboot). This means that at > first the peer just goes silent, i.e. does not send or respond to any > messages. Conforming IKEv2 implementation will detect this situation > and follow the rules given in the section 2.4: >=20 > "If there has only been outgoing traffic on all of > the SAs associated with an IKE SA, it is essential to confirm > liveness of the other endpoint to avoid black holes. If no > cryptographically protected messages have been received on an IKE SA > or any of its Child SAs recently, the system needs to perform a > liveness check in order to prevent sending messages to a dead peer." >=20 > I.e. the peer usually will start liveness checks even before the other > end is sending INVALID_SPI notification, as it detected that the other > end is not sending any packets anymore while it is still rebooting or > recovering from the situation. >=20 > This means that the several minutes recovery period is overlaping the > actual recover time of the other peer, i.e. if the security gateway > requires several minutes to boot up from the crash then the other > peers have already finished their liveness checks before the crashing > peer even has change to send INVALID_SPI notifications. >=20 > There are cases where the peer looses state and is able to recover > immediately, in those cases it might take several minutes to recover. >=20 > Note, that IKEv2 specification specifically leaves number of > retries and lengths of timeouts out from the specification, as they do > not affect interoperability. This means that implementations are > allowed to use the hints provided by the INVALID_SPI messages as hints > that will shorten those timeouts (i.e. different environment and > situation requiring different rules). >=20 > Good existing IKEv2 implementations already do that (i.e. both shorten > timeouts or limit number of retries) based on that kind of hints and > also start liveness checks quickly after the other end goes silent. > ---------------------------------------------------------------------- >=20 > The final paragraph saying: >=20 > Those "at least several minutes" are a time during which both peers > are active, but IPsec cannot be used. >=20 > is incorrect, as it is only true when the crashed peer recoverd > instantenously. In normal case most of that time is actually > overlaping the recovery time of the peer. >=20 > -- >=20 > The protocol currently says that: >=20 > Supporting implementations will send a notification, called a "QCD > token", as described in Section 4.1 in the last IKE_AUTH exchange > messages. These are the final IKE_AUTH request and final IKE_AUTH > response that contain the AUTH payloads. >=20 > This is very differnet compared to all other processing, usually this > kind of payloads are put to the same packet that contains traffic > selectors etc. Is there some reason why this is done this way? >=20 > -- >=20 > Also do we really need the QCD token for the initiator too? The > initiator has already proven to be able to create the IKE SA on its > own, and it will have enough information to recreate the IKE SA after > the boot. Responder usually does not have enough information to be > able to recrete the IKE SA on its own after reboot, as it might not > for example know anymore what was the peer address where the IKE SA > was connected to when it just has IP packet it needs to forward to > that peer. The initiator must already have that information as he was > able to trigger IPsec SA creation in the first place based on the ip > packet. >=20 > I think it would simplify the implementations and the protocol by just > limiting that only responders can be token makers without loosing any > of the functionality.=20 >=20 > -- >=20 > Section 7.4 is mostly wrong. >=20 > The default retransmission policy needed for mobike cases is much, > much longer than what is needed in normal case. When mobike switches > from one interface to the another there might be very long delays > because of this (for example the device first needs to notice that > old interface does not work anymore, and then perhaps it needs to run > dhcp and other link related protocols on the new interface before it > can even try it and all those take a long time). >=20 > For example in our implementation the mobike uses MUCH longer timeouts > just to make sure we do not time out the IKE exchanges while we are > trying to go through all possible interfaces etc. Because of those > even longer timeouts there is very good reason to shorten those > timeouts in case we get any feedback back from the other end (i.e. > INVALID_SPI notifications). >=20 > The timeouts used in different situations even in the same > implementation needs to be different. In our case when you enable > mobike the number of retries used is more than 2 times what it is if > you do not turn mobike on. >=20 > Also the last paragraph again assumes that the peer staying up didn't > start liveness check almost immediately when the crashing peer > crashed. This is something that is already part of the standard IKEv2 > specification, so implementions need to do that. This means the > timeout starts from the time of the crash, not from the time when the > gateway is up again. >=20 > Anyways as all this is standard IKEv2 already it does not belong here > in the alternative solutions section, but belongs as part of the > section 2. >=20 > -- >=20 > Section 8 again ignores the IKEv2 text saying: >=20 > "If there has only been outgoing traffic on all of > the SAs associated with an IKE SA, it is essential to confirm > liveness of the other endpoint to avoid black holes. If no > cryptographically protected messages have been received on an IKE SA > or any of its Child SAs recently, the system needs to perform a > liveness check in order to prevent sending messages to a dead peer." >=20 > Especially the text: >=20 > A failed gateway may go undetected > for as long as the lifetime of a child SA, because IPsec does not > have packet acknowledgement, and applications cannot signal the IPsec > layer that the tunnel "does not work". =20 >=20 > If the gateway has failed then if there is ANY traffic on any of the > IPsec SAs then that means that from the other peers point of view > there is only outgoing traffic, thus it needs to do liveness check to > verify that the other end is alive. Thus the failed gateway cannot > really go undetected for as long as the lifetime of child SA, unless > the lifetimes is in order of few minutes :-) >=20 > I know there are implementations who do not implement that part of the > IKEv2 specification, but that does not mean that the part is not > there. We should not write or specifications to cover broken > implementations, but try to assume that implementations are following > the IKEv2 specification. >=20 > Note that the IKEv2 text does not have any conditionals there, it says > that "...the system needs to perform a liveness check...". It does not > say it may, or even should do it, it says it needs to be done. >=20 > Also I think the picture itself is bit incorrect, the exchange after > the reboot should probably be: >=20 > ---- Reboot ----- >=20 > HDR, SK {} --> >=20 > <-- HDR, N(INVALID_IKE_SPI), N(QCD_TOKEN) >=20 >=20 > I.e I assume the first packet is normal liveness check, and the reply > that is normal INVALID_IKE_SPI with QCD_TOKEN.=20 >=20 > -- >=20 > In section 9.1. it says that inter-domain VPN gateways should do both, > but I think that inter-domain VPN gateways does not really need this > specification as all, as they by configuration do know the other ends > IP-addresses etc, thus when the inter-domain VPN gateway gets up, it > can immediately create the IKE SAs needed based on the configuration. > This is in the case where either end of the inter-domain VPN gateway > can act as a initiator, i.e. no EAP is used, and neither is behind the > NAT. >=20 > If one of the inter-domain VPN gateway is behind restricted NAT, then > it is more or less similar to the remote-access client case (i.e. only > that end can initiate connections), and as the other peer cannot > initiate connections to the gw behind NAT, there is no point of > supporting token taker on that end. > --=20 > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From yaronf.ietf@gmail.com Thu Oct 21 05:49:44 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 8CEB93A67AE for ; Thu, 21 Oct 2010 05:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoKuBdkGGfin for ; Thu, 21 Oct 2010 05:49:40 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 49C113A6934 for ; Thu, 21 Oct 2010 05:49:40 -0700 (PDT) Received: by fxm17 with SMTP id 17so3957335fxm.31 for ; Thu, 21 Oct 2010 05:51: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:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=KkN9VgYpLOAE3Tz3OK9pdKWYDZcBsrdPE/utuJz69bM=; b=iyqJAYl/7sIT5aAqr/ar7YzbLuAcu/GCVhkHIxWmigD6llaA5c/Kb2PoE9khJTP4xm 3n+WXdRgS4Brv9ZtRqpK88MJWYjDRuDqZyAObel9IGWpRuXhuAX1PKvCVLN9kLtGw9Z2 0l+FXEN2zihYVNX6dq8AUc2T0ZFmpzDXA6wtw= 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=E2MkcFQ8FCVE6FUbhK5U1n3NaTWsfg5BYUa0tZVkP+vE99Qi7dc61fQPYC+0sLVbHp b3tEtNDkPBMzST3XuYwT3fR56MZesWTVH1c8j7uBvdjtG1KCDiCryktrfz3U29I87HgC 4YkM8Ell/PspYDRyrRe7YEAIhgr70eXbEvtSM= Received: by 10.103.251.4 with SMTP id d4mr1055701mus.131.1287665468171; Thu, 21 Oct 2010 05:51:08 -0700 (PDT) Received: from [10.0.0.6] (85-250-177-253.bb.netvision.net.il [85.250.177.253]) by mx.google.com with ESMTPS id 14sm742537fas.20.2010.10.21.05.51.02 (version=SSLv3 cipher=RC4-MD5); Thu, 21 Oct 2010 05:51:03 -0700 (PDT) Message-ID: <4CC03733.7050701@gmail.com> Date: Thu, 21 Oct 2010 14:50:59 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Yoav Nir References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD43B7@il-ex01.ad.checkpoint.com> <57568731-A4E2-4876-8B54-876AD95D1A40@checkpoint.com> <4CBEF2D5.8080903@gmail.com> <4CBEFAD2.1050303@gmail.com> <19648.3858.260532.88878@fireball.kivinen.iki.fi> <97606E95-19E2-472E-BAA6-DAA5F3DECD84@checkpoint.com> In-Reply-To: <97606E95-19E2-472E-BAA6-DAA5F3DECD84@checkpoint.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , David Wierbowski , Tero Kivinen Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss the threat X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 21 Oct 2010 12:49:44 -0000 Hi Yoav, as I mentioned in my mail yesterday, #194 is not just about this particular issue. Thanks, Yaron On 10/21/2010 12:33 PM, Yoav Nir wrote: > > On Oct 21, 2010, at 11:59 AM, Tero Kivinen wrote: > > > >> The section 10.4 seems to assume that attacker cannot force the load >> balancer to send the faked packet to any other cluster member than the >> one mapped by the source IP-address of the packet. As the algorithm >> how the load balancer really selects the peer where it sends the >> packet is not necessarely known by the IPsec implementations, I do not >> think we can trust we can include all same information to the token >> generation. > > I agree, although I suspect some of my co-authors might not. > >> For example it could use source port numbers, or destination >> IP-address, etc so I think it is quite unsafe to assume anything what >> the load balancer might do. >> >> I think it would be safer to forbid situations where the cluster >> members share the same QCD token unless they also share the IKE SA >> state. > > I agree that there is a problem that needs solving here, but I also see some great utility in allowing QCD on such configurations. > > In a hot-standby cluster, you can have QCD instead of synchronizing state. When one gateway fails, the other takes over immediately (or in less than one second). This is like a reboot, but instantaneous, and it's easier and cheaper to implement than a real cluster with state synchronization - you only need to make sure that the QCD token secret is the same. In this configuration you don't have a problem, unless there's a way to get responses out of the standby member before it becomes active. > > If you also want to achieve scalability with your cluster, you implement load sharing. There is no state synch, but in case one of the gateways fails, we want the other to be able to use QCD to quickly destroy the existing IKE SAs. Again, if I can get one member to generate a token for an IKE SA owned by another gateway, the attacker wins. I'd say that this requires some very big assumptions for the load balancer anyway (for example, that without a failure, all IKE traffic for a particular SA goes to the same gateway, and even after a failure, old IKE SAs owned by other gateways remain with their respective gateways). We might need some interesting text to describe the requirements there. > > I think I will close #194, and open a new one that makes the contentious point clearer. > > > From paul.hoffman@vpnc.org Thu Oct 21 16:58: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 B52F73A67F3 for ; Thu, 21 Oct 2010 16:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.106 X-Spam-Level: X-Spam-Status: No, score=-100.106 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QZ75PJlUsXO for ; Thu, 21 Oct 2010 16:58:12 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id EFC4D3A67F0 for ; Thu, 21 Oct 2010 16:58:11 -0700 (PDT) Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9LNxjMw066964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Oct 2010 16:59:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 21 Oct 2010 16:59:44 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Agenda items for face-to-face meeting Beijing? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 21 Oct 2010 23:58:12 -0000 Greetings again. We have a two-hour slot at the upcoming IETF meeting. We will, of course, be dealing with the open issues on our two main documents, and trying to get as much information out as possible so we can get closure on all of them. We have some time for short presentations on other IPsec-related topics that have not been presented previously. If you have such a topic, please let me know ASAP so we can get a reasonably-correct agenda in. --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Sun Oct 24 01:54: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 BBBD33A679F for ; Sun, 24 Oct 2010 01:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[AWL=-0.856, 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 AOXvs7iN6Bo3 for ; Sun, 24 Oct 2010 01:54:02 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id BEF413A6407 for ; Sun, 24 Oct 2010 01:54:01 -0700 (PDT) X-CheckPoint: {4CC3F2A1-10000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o9O8tgLk027940 for ; Sun, 24 Oct 2010 10:55:42 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 24 Oct 2010 10:55:42 +0200 From: Yoav Nir To: IPsecme WG Date: Sun, 24 Oct 2010 10:55:41 +0200 Thread-Topic: Failure Detection - status of some issues Thread-Index: ActzWTxraj0X9+QrQvKSI16VT4tJ8Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Failure Detection - status of some issues X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 08:54:04 -0000 #195 was closed as a duplicate of (the already closed) #191. #193, #194, and #197 will be closed with the publishing of draft -02. #202 (below) is newly submitted, and I expect a lively discussion of it in = Beijing. It's fine to discuss it between now and then, as well as #198-#201= , but if you have comments about #193, #194 and #197, please say them now, = before we publish -02. Token makers generating the same tokens without synchronized DB =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Section 10.4 of the draft has a use-case where a cluster of gateways share = the same QCD token secret, because they back each other up.=20 The twist in this case, is that they don't have synchronized databases, so = a fail-over is very much like a reboot - the IKE SA is gone, and QCD is eff= ective in getting the other side to restart IKE quickly. The problem is, that without a failover, it may be possible to get a member= that does not own the IKE SA to send the QCD token to an attacker. The att= acker can then use this QCD token to tear down the IKE SA. The method in section 5.2 tries to address this, by considering the IP addr= ess of the token taker in the calculation.=20 Tero claims that this is a scenario that we should not address, and that pr= edicting or prescribing load balancer behavior in inherently dangerous. From yaronf.ietf@gmail.com Sun Oct 24 02:34: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 2CC443A6820 for ; Sun, 24 Oct 2010 02:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cg37yaaeZa33 for ; Sun, 24 Oct 2010 02:34:54 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id AFB133A6827 for ; Sun, 24 Oct 2010 02:34:48 -0700 (PDT) Received: by bwz12 with SMTP id 12so2677149bwz.31 for ; Sun, 24 Oct 2010 02:36: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:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=UljowOeWFOvd1rToZ5DGYUt1IsLLg5LIpGqUkK9TSwA=; b=D+k3XrYK/gy9NY/sGy99NXiNf8Hxhr19BQJT2gzJo6OUWVBuGKx/OxQL0IFDmmQybE N0Mll7ppQH4/bwYMg7g/DXe1nkke79Xy2aoiHQoS5RsYf/FzEo5hv4gS5/B7vrFHqxsw f7bKRH6OFAdOMh6zxsK/oF5qTl5iH2TAfWm/g= 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=LwPQ996zoa62XXYpTgegBJIoYvzBMSkdT+5m15qPlzC2m3TLLN2V6ez5lO/u6Np7RT cCDziPew0C+7OHy2UQW2uN0O63U3ZJYKZNYZg51fC2MjDYQvdc+kGOOrmo6e1R5eClAi uNTOFRmHNRYkmkvL6BEDTkFyO75ae1KigsRcQ= Received: by 10.204.118.209 with SMTP id w17mr3435885bkq.107.1287912987166; Sun, 24 Oct 2010 02:36:27 -0700 (PDT) Received: from [194.194.194.30] (80.179.5.52.static.012.net.il [80.179.5.52]) by mx.google.com with ESMTPS id d27sm3738756bkw.2.2010.10.24.02.36.22 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Oct 2010 02:36:24 -0700 (PDT) Message-ID: <4CC3FE0F.2050403@gmail.com> Date: Sun, 24 Oct 2010 11:36:15 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Yoav Nir References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Failure Detection - status of some issues X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 09:34:59 -0000 Two further problems with this solution are: - We must have two different ways of producing the token, making security analysis more complex. - The token taker does not know which method the maker is using, so it doesn't know whether it should request a new token each time it changes address (by piggybacking on the MOBIKE messaging). This is solved by allowing the maker to push the token, but at the cost of bandwidth and complexity. Thanks, Yaron On 10/24/2010 10:55 AM, Yoav Nir wrote: > #195 was closed as a duplicate of (the already closed) #191. > #193, #194, and #197 will be closed with the publishing of draft -02. > > #202 (below) is newly submitted, and I expect a lively discussion of it in Beijing. It's fine to discuss it between now and then, as well as #198-#201, but if you have comments about #193, #194 and #197, please say them now, before we publish -02. > > > > Token makers generating the same tokens without synchronized DB > ===================================================== > > Section 10.4 of the draft has a use-case where a cluster of gateways share the same QCD token secret, because they back each other up. > > The twist in this case, is that they don't have synchronized databases, so a fail-over is very much like a reboot - the IKE SA is gone, and QCD is effective in getting the other side to restart IKE quickly. > > The problem is, that without a failover, it may be possible to get a member that does not own the IKE SA to send the QCD token to an attacker. The attacker can then use this QCD token to tear down the IKE SA. > > The method in section 5.2 tries to address this, by considering the IP address of the token taker in the calculation. > > Tero claims that this is a scenario that we should not address, and that predicting or prescribing load balancer behavior in inherently dangerous. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Sun Oct 24 02:47:36 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 D8FB33A679F for ; Sun, 24 Oct 2010 02:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXKppN7Omz6E for ; Sun, 24 Oct 2010 02:47:36 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 743E13A6820 for ; Sun, 24 Oct 2010 02:47:35 -0700 (PDT) X-CheckPoint: {4CC3FF2F-10000-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o9O9nFXI004814; Sun, 24 Oct 2010 11:49:15 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 24 Oct 2010 11:49:15 +0200 From: Yoav Nir To: Yaron Sheffer Date: Sun, 24 Oct 2010 11:49:13 +0200 Thread-Topic: [IPsec] Failure Detection - status of some issues Thread-Index: ActzYLcUAJ41TnXuTf6fU3yjwL4OhA== Message-ID: References: <4CC3FE0F.2050403@gmail.com> In-Reply-To: <4CC3FE0F.2050403@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Failure Detection - status of some issues X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 09:47:37 -0000 There is no "request". The maker can piggy-back on the MOBIKE response, and= the taker has no way to request a token. It gets more difficult when the taker changes address, and expects the make= r to silently notice this and updates its SAs. I remember a discussion of t= his "cheap mobility" idea, but I don't remember if it was ever specified. I= n that case, the token maker will have to take the initiative. On Oct 24, 2010, at 11:36 AM, Yaron Sheffer wrote: > Two further problems with this solution are: >=20 > - We must have two different ways of producing the token, making=20 > security analysis more complex. >=20 > - The token taker does not know which method the maker is using, so it=20 > doesn't know whether it should request a new token each time it changes=20 > address (by piggybacking on the MOBIKE messaging). This is solved by=20 > allowing the maker to push the token, but at the cost of bandwidth and=20 > complexity. >=20 > Thanks, > Yaron >=20 > On 10/24/2010 10:55 AM, Yoav Nir wrote: >> #195 was closed as a duplicate of (the already closed) #191. >> #193, #194, and #197 will be closed with the publishing of draft -02. >>=20 >> #202 (below) is newly submitted, and I expect a lively discussion of it = in Beijing. It's fine to discuss it between now and then, as well as #198-#= 201, but if you have comments about #193, #194 and #197, please say them no= w, before we publish -02. >>=20 >>=20 >>=20 >> Token makers generating the same tokens without synchronized DB >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>=20 >> Section 10.4 of the draft has a use-case where a cluster of gateways sha= re the same QCD token secret, because they back each other up. >>=20 >> The twist in this case, is that they don't have synchronized databases, = so a fail-over is very much like a reboot - the IKE SA is gone, and QCD is = effective in getting the other side to restart IKE quickly. >>=20 >> The problem is, that without a failover, it may be possible to get a mem= ber that does not own the IKE SA to send the QCD token to an attacker. The = attacker can then use this QCD token to tear down the IKE SA. >>=20 >> The method in section 5.2 tries to address this, by considering the IP a= ddress of the token taker in the calculation. >>=20 >> Tero claims that this is a scenario that we should not address, and that= predicting or prescribing load balancer behavior in inherently dangerous. >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From root@core3.amsl.com Mon Oct 25 05:45: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 326A43A685E; Mon, 25 Oct 2010 05:45: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: <20101025124502.326A43A685E@core3.amsl.com> Date: Mon, 25 Oct 2010 05:45:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 12:45: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 : Protocol Support for High Availability of IKEv2/IPsec Author(s) : R. Jenwar, et al. Filename : draft-ietf-ipsecme-ipsecha-protocol-02.txt Pages : 19 Date : 2010-10-25 The IPsec protocol suite is widely used for the deployment of virtual private networks (VPNs). In order to make such VPNs highly available, more scalable and failure-resistant, these VPNs are implemented as IPsec High Availability (HA) clusters. However there are many issues in IPsec HA clustering, and in particular in IKEv2 clustering. An earlier document, "IPsec Cluster Problem Statement", enumerates the issues encountered in the IKEv2/IPsec HA cluster environment. This document attempts to resolve these issues with the least possible change to the protocol. This document proposes an extension to the IKEv2 protocol to solve the main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot-standby cluster, and provides implementation advice for other issues. The main issues to be solved are the synchronization of IKEv2 Message ID counters, and of IPsec Replay Counters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsecha-protocol-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ipsecha-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25053327.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 25 09:00: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 22CCF3A68B8; Mon, 25 Oct 2010 09:00: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: <20101025160005.22CCF3A68B8@core3.amsl.com> Date: Mon, 25 Oct 2010 09:00:03 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 16:00: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 : A Quick Crash Detection Method for IKE Author(s) : Y. Nir, et al. Filename : draft-ietf-ipsecme-failure-detection-02.txt Pages : 23 Date : 2010-10-25 This document describes an extension to the IKEv2 protocol that allows for faster detection of SA desynchronization using a saved token. When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text we propose an extension to the protocol, that allows for recovery immediately following the restart. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-failure-detection-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-failure-detection-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25084743.I-D@ietf.org> --NextPart-- From fd@cisco.com Mon Oct 25 12:07: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 9B3513A67B3 for ; Mon, 25 Oct 2010 12:07:07 -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 ugTYZGYiuw4A for ; Mon, 25 Oct 2010 12:07:06 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id DDD673A682F for ; Mon, 25 Oct 2010 12:07:05 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9PJ1EIP004700; Mon, 25 Oct 2010 21:01:14 +0200 (CEST) Received: from ams-fdetienn-87110.cisco.com (ams-fdetienn-87110.cisco.com [10.55.136.235]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9PJ1C2u023258; Mon, 25 Oct 2010 21:01:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Frederic Detienne In-Reply-To: <19648.3858.260532.88878@fireball.kivinen.iki.fi> Date: Mon, 25 Oct 2010 21:01:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <046AB661-C3AC-42DD-B405-36F23C8DB1AB@cisco.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD43B7@il-ex01.ad.checkpoint.com> <57568731-A4E2-4876-8B54-876AD95D1A40@checkpoint.com> <4CBEF2D5.8080903@gmail.com> <4CBEFAD2.1050303@gmail.com> <19648.3858.260532.88878@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1081) Cc: IPsecme WG , Yoav Nir , David Wierbowski Subject: [IPsec] Issue 202 [was Issue #194] - Security Considerations should discuss the threat X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 25 Oct 2010 19:07:07 -0000 Hi Tero, Like I explained earlier, sharing the address-less QCD token is = problematic in multiple practical network designs: - Stateless failover pairs (e.g. VRRP, HSRP, ..) - Load Balanced clusters - Anycast server clusters In general, QCD address-less token generation is dangerous in all the = scenarios where the server owning the state can be bypassed by the = attacker and any other server in the cluster, not owning state, can be = targeted to receive the "invalid" IKE or ESP packet. In the current proposal, I agree that the issues raised by address-less = token should be more explicit and general. This token method should be = explicitly forbidden when either - the accessibility to other servers of the clusters can not be = restricted - or insufficient state is shared across the cluster to avoid sending = unwanted INVALID_SPI This statement is more accurate and less restrictive than having to = share the IKE SA DB. regards, fred On 21 Oct 2010, at 11:59, Tero Kivinen wrote: [...] >=20 >> An eavesdropper could see an IKE request (e.g. CREATE_CHILD_SA = request) >> and forge an informational message back to the requester containing = N >> (INVALID_IKE_SPI) and N(QCD_TOKEN). If he guesses QCD_TOKEN = correctly he >> can disrupt the IKE_SA and force a negotiation. So in theory this = makes >> IKE more prone to a passive MITM, but that's theory. Given = significant >> randomness in the token the attack is not feasible. If there's a = flaw in >> the RFC that makes tokens easy to guess this would be a valid attack. >> True, if we do not mandate the algorithm somebody can implement a = token >> generation scheme that is easy to guess. >=20 > There has been talks here in the list about cases where we have loose > cluster which do not share same IKE SA state, but which do share QCD > token generation secrets. Such clusters would be vulnerable to this > kind of attacks regardless whether the token generation contains token > takers IP number or not. >=20 > The attack simply needs to fake one IKE SA message so that its source > IP is the real source ip of the host attacker wants to attack, send it > to the cluster member which do not have the IKE SA state for that IKE > SA, and then see the QCD reply sent by the cluster member. This reply > now contains the QCD token which can then be used to attack the host. >=20 > Actually normally when that packet reaches its final destination the > host will tear down its IKE SA anyways. >=20 > So attacker just need to know the IKE SA SPI pair and the IP addresses > of the valid IKE SA on one cluster member and then send any faked IKE > message to another cluster member sharing same QCD token generation > secret, but separate IKE SA database. >=20 > The section 10.4 seems to assume that attacker cannot force the load > balancer to send the faked packet to any other cluster member than the > one mapped by the source IP-address of the packet. As the algorithm > how the load balancer really selects the peer where it sends the > packet is not necessarely known by the IPsec implementations, I do not > think we can trust we can include all same information to the token > generation. >=20 > For example it could use source port numbers, or destination > IP-address, etc so I think it is quite unsafe to assume anything what > the load balancer might do. >=20 > I think it would be safer to forbid situations where the cluster > members share the same QCD token unless they also share the IKE SA > state. > --=20 > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From fd@cisco.com Tue Oct 26 03:11: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 7661F3A67CF for ; Tue, 26 Oct 2010 03:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cg05Wu+cu+uE for ; Tue, 26 Oct 2010 03:11:44 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 63E273A6931 for ; Tue, 26 Oct 2010 03:11:43 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9QA258I006306; Tue, 26 Oct 2010 12:02:05 +0200 (CEST) Received: from ams-fdetienn-87110.cisco.com (ams-fdetienn-87110.cisco.com [10.55.136.235]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o9QA23NE018794; Tue, 26 Oct 2010 12:02:04 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Frederic Detienne In-Reply-To: <97606E95-19E2-472E-BAA6-DAA5F3DECD84@checkpoint.com> Date: Tue, 26 Oct 2010 12:02:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <554A8B95-CD8E-43E3-AFC5-81AE158BA341@cisco.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD43B7@il-ex01.ad.checkpoint.com> <57568731-A4E2-4876-8B54-876AD95D1A40@checkpoint.com> <4CBEF2D5.8080903@gmail.com> <4CBEFAD2.1050303@gmail.com> <19648.3858.260532.88878@fireball.kivinen.iki.fi> <97606E95-19E2-472E-BAA6-DAA5F3DECD84@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1081) Cc: IPsecme WG , David Wierbowski , Tero Kivinen Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss the threat X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 26 Oct 2010 10:11:46 -0000 On 21 Oct 2010, at 12:33, Yoav Nir wrote: >=20 > On Oct 21, 2010, at 11:59 AM, Tero Kivinen wrote: >=20 > >=20 >> The section 10.4 seems to assume that attacker cannot force the load >> balancer to send the faked packet to any other cluster member than = the >> one mapped by the source IP-address of the packet. As the algorithm >> how the load balancer really selects the peer where it sends the >> packet is not necessarely known by the IPsec implementations, I do = not >> think we can trust we can include all same information to the token >> generation. >=20 > I agree, although I suspect some of my co-authors might not. I suppose your statement was for me... Not only I agree with Tero this can happen but I personally mentioned it = a few times already. :-) I am also claiming that it happens not just with SLB -- it can happen = with HSRP and various other network designs. In order to secure QCD, the token has to include all the fields that can = be used for routing a packet to any given server: - source/destinatition IP - protocol (UDP / ESP) - source/destination ports if applicable This is of course on top of the SPI and the QCD Secret. In doing so, we impose additional constraints on QCD's security and = scope but this is necessary to ensure QCD is a secure protocol. So we are now facing three main options 1- keep using 5.1 token generation and mention that it is dangerous in = specific situations 2- restrict the token generation method to 5.2 and expand 5.2 to using = port and protocol as well (all routable fields) which actually restricts = QCD out of Mobike. Warnings still apply for specific cases. 3- expand QCD to send a liveness check with a short answer delay. In = this scenario, if the server still has the IKE SA, it will respond to = the liveness check -- which will prove that the clear-text INV_SPI = should not have been sent in the first place. This must hint the client = to NOT tear down or rekey the SA's, which protects against the attack. With point 3, the protocol does not need the token and the persistent = key anymore and the proposal effectively becomes SIR which itself is = immune to the attacks and works with Mobike. regards, fred= From kivinen@iki.fi Thu Oct 28 04:11:36 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 7AD443A67EF for ; Thu, 28 Oct 2010 04:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dc2cQcPz+DkT for ; Thu, 28 Oct 2010 04:11:22 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2EBFA3A68A7 for ; Thu, 28 Oct 2010 04:11:19 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o9SBCdpb009364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2010 14:12:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o9SBCbjR012068; Thu, 28 Oct 2010 14:12:37 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19657.23205.1832.908334@fireball.kivinen.iki.fi> Date: Thu, 28 Oct 2010 14:12:37 +0300 From: Tero Kivinen To: Frederic Detienne In-Reply-To: <046AB661-C3AC-42DD-B405-36F23C8DB1AB@cisco.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD43B7@il-ex01.ad.checkpoint.com> <57568731-A4E2-4876-8B54-876AD95D1A40@checkpoint.com> <4CBEF2D5.8080903@gmail.com> <4CBEFAD2.1050303@gmail.com> <19648.3858.260532.88878@fireball.kivinen.iki.fi> <046AB661-C3AC-42DD-B405-36F23C8DB1AB@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 9 min Cc: IPsecme WG , David Wierbowski , Yoav Nir Subject: [IPsec] Issue 202 [was Issue #194] - Security Considerations should discuss the threat X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 28 Oct 2010 11:11:36 -0000 Frederic Detienne writes: > Like I explained earlier, sharing the address-less QCD token is > problematic in multiple practical network designs: > - Stateless failover pairs (e.g. VRRP, HSRP, ..) > - Load Balanced clusters > - Anycast server clusters I do not think having address inside the QCD calculations help at all, as the attacker can easily fake that address (it is source address of the IKE SA packet triggering QCD). Adding source address to the QCD token hash only helps if you can guarantee that the load balancer forwarding packets to multiple cluster members does it based on the source address and there is no way to get packet past the load balancer without this demuxing. > In general, QCD address-less token generation is dangerous in all > the scenarios where the server owning the state can be bypassed by > the attacker and any other server in the cluster, not owning state, > can be targeted to receive the "invalid" IKE or ESP packet. I would remove the "address-less" there. QCD is dangerous in those situations regardless whether address is there or not. > In the current proposal, I agree that the issues raised by > address-less token should be more explicit and general. This token > method should be explicitly forbidden when either You misunderstood me. I am not proposing forbidding or adding text for the address-less token. It is secure and works fine on those environments where QCD can be used, i.e. where the QCD token generation secret is not shared with other members. I am opposed of including cookies with IP addresses, as I do not think that solves any problem, as it puts way too much implicit assumptions how the load balancer work. I think that section 5.2 is dangeours and should be removed, and we should forbid sharing QCD token generation secret in all cases where the IKE SA databases are not shared too. -- kivinen@iki.fi From kivinen@iki.fi Thu Oct 28 04:15: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 B4A2B3A67E1 for ; Thu, 28 Oct 2010 04:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kYZQ7pC1xfZ for ; Thu, 28 Oct 2010 04:15:56 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2C92F3A6875 for ; Thu, 28 Oct 2010 04:15:55 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o9SBHfHE015323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Oct 2010 14:17:41 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o9SBHfcu008578; Thu, 28 Oct 2010 14:17:41 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19657.23509.448261.967876@fireball.kivinen.iki.fi> Date: Thu, 28 Oct 2010 14:17:41 +0300 From: Tero Kivinen To: Frederic Detienne In-Reply-To: <554A8B95-CD8E-43E3-AFC5-81AE158BA341@cisco.com> References: <006FEB08D9C6444AB014105C9AEB133F012E6FCD43B7@il-ex01.ad.checkpoint.com> <57568731-A4E2-4876-8B54-876AD95D1A40@checkpoint.com> <4CBEF2D5.8080903@gmail.com> <4CBEFAD2.1050303@gmail.com> <19648.3858.260532.88878@fireball.kivinen.iki.fi> <97606E95-19E2-472E-BAA6-DAA5F3DECD84@checkpoint.com> <554A8B95-CD8E-43E3-AFC5-81AE158BA341@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: IPsecme WG , David Wierbowski , Yoav Nir Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss the threat X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.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, 28 Oct 2010 11:15:57 -0000 Frederic Detienne writes: > In order to secure QCD, the token has to include all the fields that > can be used for routing a packet to any given server: > > - source/destinatition IP > - protocol (UDP / ESP) > - source/destination ports if applicable But the problem is that the IPsec implementation does not have way to know what fields is used. Some future load balancer might use something else in addition to those you listed there and if that happens we immediately open the QCD protocol for attacks. > > This is of course on top of the SPI and the QCD Secret. > > In doing so, we impose additional constraints on QCD's security and > scope but this is necessary to ensure QCD is a secure protocol. > > So we are now facing three main options > 1- keep using 5.1 token generation and mention that it is dangerous > in specific situations 5.1 token generation is not dangerous, unless you share QCD token generation secrets. Both 5.1 and 5.2 token generations are dangerous if you share QCD token generation secrets unless you know exactly how your load balancer demuxes the IKE packets, and include all information used for this demuxing to your QCD token and make sure load balancer cannot pass packets to any members directly (i.e. bypassing the demuxing). -- kivinen@iki.fi