From ipsec-bounces@ietf.org Sat Oct 01 08:23:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELgOu-0006Nn-9f; Sat, 01 Oct 2005 08:23:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELgOr-0006Mr-LF for ipsec@megatron.ietf.org; Sat, 01 Oct 2005 08:23:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29248 for ; Sat, 1 Oct 2005 08:23:29 -0400 (EDT) Received: from xproxy.gmail.com ([66.249.82.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELgWs-0004fo-Uh for ipsec@ietf.org; Sat, 01 Oct 2005 08:31:54 -0400 Received: by xproxy.gmail.com with SMTP id t13so35996wxc for ; Sat, 01 Oct 2005 05:23:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=tSYS8O4Ds1vwlQxwKwO1x+jUk6a6cgaKP+G8r9ffGm/4qMJ1RCK6iJzJLPmU6x9Brsqc2K9xp0VfC5oeiflg2Ef7DtrqFBQBIxtZJwg78UalhKEPerONpz4SQhhlSzM2vZtPMKvQ3OQlTCE7mwfSzNwndOkUTg3C+xAFJ/zOHZc= Received: by 10.70.91.12 with SMTP id o12mr1173978wxb; Sat, 01 Oct 2005 05:23:21 -0700 (PDT) Received: from ?192.168.2.190? ( [84.121.24.204]) by mx.gmail.com with ESMTP id i37sm2981420wxd.2005.10.01.05.23.20; Sat, 01 Oct 2005 05:23:21 -0700 (PDT) From: Alejandro Perez Mendez To: ipsec@ietf.org Content-Type: text/plain Date: Sat, 01 Oct 2005 14:23:19 +0200 Message-Id: <1128169399.2349.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Subject: [Ipsec] Rekeying SA bundles X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi! I need some clarifications. The IKEV2 clarifications document, in the section 5.1, says: << When rekeying an existing CHILD_SA, the leading N payload of type REKEY_SA MUST be included and MUST give the SPI (as they would be expected in the headers of inbound packets) of the SAs being rekeyed. >> What about SA bundles? REKEY_SA notification payload can identify only one inbound SA. I think there are at least three ways to do this: a) Two(or more) notification payload must be included indicating the SPI of all the inbound SAs of the SA bundle. b) Two(or more) CREATE_CHILD_SA exchanges must be started to rekey all SAs in the SA bundle. c) The REKEY_SA identifies only one of the SAs in the bundle, but this is enough to identify the entire SA bundle. The responder knows all the SPI values. d).... Thanks for your help. Regards! _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 04 14:09:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMrE3-0000bm-JT; Tue, 04 Oct 2005 14:09:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMrE0-0000bb-0l for ipsec@megatron.ietf.org; Tue, 04 Oct 2005 14:09:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14470 for ; Tue, 4 Oct 2005 14:09:10 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=barracuda.intoto.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMrMh-0003QL-SV for ipsec@ietf.org; Tue, 04 Oct 2005 14:18:13 -0400 Received: from angel.intoto.com (angel.intoto.com [10.1.5.29]) by barracuda.intoto.com (Spam Firewall) with ESMTP id 403C710E4D for ; Tue, 4 Oct 2005 11:09:08 -0700 (PDT) Received: from knight.intoto.com (dhcp-73.intoto.com [10.1.5.73]) (authenticated bits=0) by angel.intoto.com (8.13.1/8.13.1) with ESMTP id j94INM8b008063 for ; Tue, 4 Oct 2005 11:23:23 -0700 Message-Id: <6.2.3.4.0.20051004110537.0381b208@mail.intoto.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 04 Oct 2005 11:07:05 -0700 To: ipsec@ietf.org From: vamsi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by Barracuda Spam Firewall at intoto.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Ipsec] 64 bit/8 byte Life Time Duration attribute for Kilo bytes Query X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, Rfc 2407 (IP Security Domain of Interpretation) states that Life time attribute is a variable length SA attribute and that particular text is as shown below 4.5 IPSEC Security Association Attributes The following SA attribute definitions are used in Phase II of an IKE negotiation. Attribute types can be either Basic (B) or Variable- Length (V). Encoding of these attributes is defined in the base ISAKMP specification. Attributes described as basic MUST NOT be encoded as variable. Variable length attributes MAY be encoded as basic attributes if their value can fit into two octets. See [IKE] for further information on attribute encoding in the IPSEC DOI. All restrictions listed in [IKE] also apply to the IPSEC DOI. Attribute Types class value type ------------------------------------------------- SA Life Type 1 B SA Life Duration 2 V How does a receiver should behave if it receives a Life time duration attribute of length 64bit/8 byte for Kilobytes? If it doesn't support more than 4 bytes, does it has to Reject the Negotiation? Most of the implementations entertain 4 byte length attribute . Please give your comments on this Life time duration attribute of length more than 4 bytes. Thanks! regards vamsi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 05 06:06:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN6AT-0003do-Qb; Wed, 05 Oct 2005 06:06:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN6AR-0003bl-FB for ipsec@megatron.ietf.org; Wed, 05 Oct 2005 06:06:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11010 for ; Wed, 5 Oct 2005 06:06:28 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN6JH-00068B-Qw for ipsec@ietf.org; Wed, 05 Oct 2005 06:15:41 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j95A6F95002497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Oct 2005 13:06:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j95A6ELm010911; Wed, 5 Oct 2005 13:06:14 +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: <17219.42390.247899.807864@fireball.kivinen.iki.fi> Date: Wed, 5 Oct 2005 13:06:14 +0300 From: Tero Kivinen To: Alejandro Perez Mendez Subject: [Ipsec] Rekeying SA bundles In-Reply-To: <1128169399.2349.15.camel@localhost.localdomain> References: <1128169399.2349.15.camel@localhost.localdomain> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 20 min X-Total-Time: 21 min X-Spam-Score: 0.0 (/) X-Scan-Signature: ba9cd4f9acda58dbe142afff7265daff Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Alejandro Perez Mendez writes: > Hi! I need some clarifications. > > The IKEV2 clarifications document, in the section 5.1, says: > << When rekeying an existing > CHILD_SA, the leading N payload of type REKEY_SA MUST be > included and MUST give the SPI (as they would be expected in > the headers of inbound packets) of the SAs being rekeyed. >> > > What about SA bundles? There is no bundles in the IKEv2 + RFC 2401bis. You can create AH+ESP "bundle" with IKEv2 and RFC2401bis, but it happens so that you first create ESP SA with the traffic selectors matching the actual traffic, and then you create AH SA with traffic selectors matching the ESP SA traffic (i.e. protocol ESP, IP addresses of the gateways etc). > REKEY_SA notification payload can identify only one inbound SA. Yes, and as there is no bundles, that is enough. If you rekey AH+ESP "bundle" described above, then you simply rekey both SAs (AH and ESP) separately). > b) Two(or more) CREATE_CHILD_SA exchanges must be started to rekey all > SAs in the SA bundle. As there is no other relation than traffic selectors betwen the AH and ESP, this is the correct way to do the thing. Note also, that as there is no bunndles in IKEv2 + RFC2401bis you do not need to provide support for the SA payloads having multiple protocols. That will simplify the parsing and generation of SA payloads. Also as there is no real reason for use multiple proposals in the IKEv2 either (we can encode everything we really want inside one proposal having multiple transforms), you can also leave that feature out (i.e. in normal case you have exactly one proposal having exactly one protocol, and inside those there is multiple transforms). Encoding the SA payload like we did in the IKEv1 i.e having separate proposal for each transform set (i.e. only single transforms inside proposal) should not be used as it simply makes the packets bigger and may cause fragmentation. So use this: SA payload Proposal substructure Proposal # = 1 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 9 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 256 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 192 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 128 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 3 (3DES) Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 1 (HMAC_MD5_96) Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 2 (HMAC_SHA1_96) Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 5 (AES_XCBC_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 1 (Extended Sequence numbers) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 0 (No Extended Sequence numbers) And not this (which is identical in the policy point of view): SA payload Proposal substructure Proposal # = 1 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 256 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 1 (HMAC_MD5_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 1 (Extended Sequence numbers) Proposal substructure Proposal # = 2 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 256 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 1 (HMAC_MD5_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 0 (No Extended Sequence numbers) Proposal substructure Proposal # = 3 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 256 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 2 (HMAC_SHA1_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 1 (Extended Sequence numbers) Proposal substructure Proposal # = 4 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 256 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 2 (HMAC_SHA1_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 0 (No Extended Sequence numbers) Proposal substructure Proposal # = 5 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 256 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 5 (AES_XCBC_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 1 (Extended Sequence numbers) Proposal substructure Proposal # = 6 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 256 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 5 (AES_XCBC_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 0 (No Extended Sequence numbers) Proposal substructure Proposal # = 7 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 192 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 1 (HMAC_MD5_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 1 (Extended Sequence numbers) Proposal substructure Proposal # = 8 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 192 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 1 (HMAC_MD5_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 0 (No Extended Sequence numbers) Proposal substructure Proposal # = 9 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 192 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 2 (HMAC_SHA1_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 1 (Extended Sequence numbers) Proposal substructure Proposal # = 10 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 192 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 2 (HMAC_SHA1_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 0 (No Extended Sequence numbers) Proposal substructure Proposal # = 11 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 192 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 5 (AES_XCBC_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 1 (Extended Sequence numbers) Proposal substructure Proposal # = 12 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 192 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 5 (AES_XCBC_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 0 (No Extended Sequence numbers) Proposal substructure Proposal # = 13 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 128 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 1 (HMAC_MD5_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 1 (Extended Sequence numbers) Proposal substructure Proposal # = 14 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 128 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 1 (HMAC_MD5_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 0 (No Extended Sequence numbers) Proposal substructure Proposal # = 15 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 128 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 2 (HMAC_SHA1_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 1 (Extended Sequence numbers) Proposal substructure Proposal # = 16 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 128 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 2 (HMAC_SHA1_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 0 (No Extended Sequence numbers) Proposal substructure Proposal # = 17 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 128 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 5 (AES_XCBC_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 1 (Extended Sequence numbers) Proposal substructure Proposal # = 18 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 12 (AES-CBC) Attribute 14 (Key-length) = 128 Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 5 (AES_XCBC_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 0 (No Extended Sequence numbers) Proposal substructure Proposal # = 19 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 3 (3DES) Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 1 (HMAC_MD5_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 1 (Extended Sequence numbers) Proposal substructure Proposal # = 20 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 3 (3DES) Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 1 (HMAC_MD5_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 0 (No Extended Sequence numbers) Proposal substructure Proposal # = 21 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 3 (3DES) Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 2 (HMAC_SHA1_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 1 (Extended Sequence numbers) Proposal substructure Proposal # = 22 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 3 (3DES) Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 2 (HMAC_SHA1_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 0 (No Extended Sequence numbers) Proposal substructure Proposal # = 23 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 3 (3DES) Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 5 (AES_XCBC_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 1 (Extended Sequence numbers) Proposal substructure Proposal # = 24 Protocol ID = ESP SPI size = 4 SPI = 0x12345678 (inbound SPI for the peer generating this) # transforms = 3 Transform substructure Transform type = 1 (encryption algorithm) Transform ID = 3 (3DES) Transform substructure Transform type = 3 (integrity algorithm) Transform ID = 5 (AES_XCBC_96) Transform substructure Transform type = 5 (integrity algorithm) Transform ID = 0 (No Extended Sequence numbers) -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 05 06:19:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN6Mz-0008Tv-J6; Wed, 05 Oct 2005 06:19:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN6Mx-0008Tq-IP for ipsec@megatron.ietf.org; Wed, 05 Oct 2005 06:19:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12378 for ; Wed, 5 Oct 2005 06:19:24 -0400 (EDT) Received: from xproxy.gmail.com ([66.249.82.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN6Vo-0006iZ-7y for ipsec@ietf.org; Wed, 05 Oct 2005 06:28:37 -0400 Received: by xproxy.gmail.com with SMTP id t6so76670wxc for ; Wed, 05 Oct 2005 03:19:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=cURjff5SvGmf464JMTPg4KzKtXdV0192qg/jzWknS6nvHRtrTl+PWdXELNdbrXlz6YmeYt5odSwOOgXSfcRw8dn+4h32KPotN9ZRvlbbm2HpR/j2KKzm7Psl4bhCQk48RflR+gNT6DO2ucBGqv5bCvd5Mwz30AELT86YdfYxxO0= Received: by 10.70.12.19 with SMTP id 19mr368689wxl; Wed, 05 Oct 2005 03:19:13 -0700 (PDT) Received: from ?192.168.2.190? ( [84.121.24.204]) by mx.gmail.com with ESMTP id i11sm358996wxd.2005.10.05.03.19.12; Wed, 05 Oct 2005 03:19:13 -0700 (PDT) Subject: Re: [Ipsec] Rekeying SA bundles From: Alejandro Perez Mendez To: Tero Kivinen In-Reply-To: <17219.42390.247899.807864@fireball.kivinen.iki.fi> References: <1128169399.2349.15.camel@localhost.localdomain> <17219.42390.247899.807864@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=UTF-8 Date: Wed, 05 Oct 2005 12:19:10 +0200 Message-Id: <1128507550.9671.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA12378 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org El mi=C3=A9, 05-10-2005 a las 13:06 +0300, Tero Kivinen escribi=C3=B3: > Alejandro Perez Mendez writes: > > Hi! I need some clarifications. > >=20 > > The IKEV2 clarifications document, in the section 5.1, says: > > << When rekeying an existing > > CHILD_SA, the leading N payload of type REKEY_SA MUST be > > included and MUST give the SPI (as they would be expected in > > the headers of inbound packets) of the SAs being rekeyed. >> > >=20 > > What about SA bundles? >=20 > There is no bundles in the IKEv2 + RFC 2401bis. But I what to use IKEv2 + RFC 2401. In this combination, there are bundles possibility. What is the desired behaviour in this case? Note that if IKEv2 allows multiple protocol proposals, it allows, IMHO, old style AH+ESP bundles. Thanks for your response. Alejandro _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 05 06:20:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN6NW-00008l-Ac; Wed, 05 Oct 2005 06:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN6NV-00008b-6t for ipsec@megatron.ietf.org; Wed, 05 Oct 2005 06:20:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12461 for ; Wed, 5 Oct 2005 06:19:58 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN6WM-0006kg-P9 for ipsec@ietf.org; Wed, 05 Oct 2005 06:29:11 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j95AJxNu006127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Oct 2005 13:19:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j95AJwU7010445; Wed, 5 Oct 2005 13:19:58 +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: <17219.43214.809413.149382@fireball.kivinen.iki.fi> Date: Wed, 5 Oct 2005 13:19:58 +0300 From: Tero Kivinen To: vamsi Subject: [Ipsec] 64 bit/8 byte Life Time Duration attribute for Kilo bytes Query In-Reply-To: <6.2.3.4.0.20051004110537.0381b208@mail.intoto.com> References: <6.2.3.4.0.20051004110537.0381b208@mail.intoto.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 7 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org vamsi writes: > How does a receiver should behave if it receives a Life time > duration attribute of length 64bit/8 byte for Kilobytes? > If it doesn't support more than 4 bytes, does it has to Reject the > Negotiation? I do not think it should be rejecting the negotiation because of that. If the lifetime is just encoded as 8 bytes but higher 4 bytes are zero, then it should simply use it as 32 bit value. If the value is actually more than 32-bit, then it should work just like it works when it has smaller lifetime for kilobytes configured, i.e. send RESPONDER-LIFETIME with its own lifetime. > Most of the implementations entertain 4 byte length attribute . > > Please give your comments on this Life time duration attribute of > length more than 4 bytes. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 05 07:48:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN7lF-000736-W3; Wed, 05 Oct 2005 07:48:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN7lF-000731-0o for ipsec@megatron.ietf.org; Wed, 05 Oct 2005 07:48:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17432 for ; Wed, 5 Oct 2005 07:48:35 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EN7u5-0000sN-HO for ipsec@ietf.org; Wed, 05 Oct 2005 07:57:47 -0400 Received: from [10.84.130.96] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j95BmLDf027525; Wed, 5 Oct 2005 07:48:22 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <1128507550.9671.5.camel@localhost.localdomain> References: <1128169399.2349.15.camel@localhost.localdomain> <17219.42390.247899.807864@fireball.kivinen.iki.fi> <1128507550.9671.5.camel@localhost.localdomain> Date: Wed, 5 Oct 2005 07:45:21 -0400 To: Alejandro Perez Mendez From: Stephen Kent Subject: Re: [Ipsec] Rekeying SA bundles Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 12:19 PM +0200 10/5/05, Alejandro Perez Mendez wrote: >El mi=E9, 05-10-2005 a las 13:06 +0300, Tero Kivinen escribi=F3: >> Alejandro Perez Mendez writes: >> > Hi! I need some clarifications. >> > >> > The IKEV2 clarifications document, in the section 5.1, says: >> > << When rekeying an existing >> > CHILD_SA, the leading N payload of type REKEY_SA MUST be >> > included and MUST give the SPI (as they would be expected in >> > the headers of inbound packets) of the SAs being rekeyed. >> >> > >> > What about SA bundles? >> >> There is no bundles in the IKEv2 + RFC 2401bis. > >But I what to use IKEv2 + RFC 2401. In this combination, there are >bundles possibility. >What is the desired behaviour in this case? Note that if IKEv2 allows >multiple protocol proposals, it allows, IMHO, old style AH+ESP bundles. > >Thanks for your response. > >Alejandro While it may be technically possible top use=20 IKEv2 with 2401 vs. 2401bis, there are a lot of=20 mismatches between the functionality offered by=20 this pairing, so we don't recommend it. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 05 16:12:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFcu-0001Ij-K8; Wed, 05 Oct 2005 16:12:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENEsA-0000P6-4W for ipsec@megatron.ietf.org; Wed, 05 Oct 2005 15:24:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12664 for ; Wed, 5 Oct 2005 15:24:11 -0400 (EDT) Received: from mx2.trusecure.com ([208.251.192.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENF15-0005QG-3Q for ipsec@ietf.org; Wed, 05 Oct 2005 15:33:28 -0400 Received: from VAMAIL01.corp.trusecure.net (vamail01.corp.cybertrust.net [172.19.1.52]) by mx2.trusecure.com (Postfix) with ESMTP id D4776C9297 for ; Wed, 5 Oct 2005 15:23:48 -0400 (EDT) Received: from HRN-MSC-EXCH-01.mscore.trusecure.net (hrn-msc-exch-01.corp.cybertrust.net [172.19.1.49]) by VAMAIL01.corp.trusecure.net (8.12.10/maybe_its_not_even_really_Sendmail....) with ESMTP id j95JNmkt022138 for ; Wed, 5 Oct 2005 15:23:48 -0400 (EDT) Received: from usvastrcybexch1.ms.cybertrust.net ([172.18.1.10]) by HRN-MSC-EXCH-01.mscore.trusecure.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 15:23:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Oct 2005 15:23:48 -0400 Message-ID: Thread-Topic: Toronto IKEv2 Interop Results thread-index: AcXJ4k+hIUhko7ITRfubbSo/kGqqJg== From: "Zimmerman, Mark" To: X-OriginalArrivalTime: 05 Oct 2005 19:23:47.0277 (UTC) FILETIME=[4EDC27D0:01C5C9E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] Toronto IKEv2 Interop Results X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The Toronto IKEv2 aggregate interop testing results have been posted at: http://www.icsalabs.com/ipsec Included in the doc is a percentage improvement column between the February and September events. 15 vendors participated with 13 Products. There was a marked decrease in draft interpretation issues at this event as opposed to the first due mostly to the clarifications document. The overwhelming majority insist upon a third event sometime in the spring of 2006. We would like to partner with anyone interested who might be able to provide an appropriate venue for this proposed next event in an effort to keep the costs and=20 registration enrollment fees to an absolute minimum. Some of the "old-timers" tell me this was the method used in the v1 days and which was very successful. Please contact me if interested, Regards, Mark Zimmerman, CISSP IPsec/Cryptography Technology Program Manager ICSA Labs 1000 Bent Creek Blvd Mechanicsburg, PA 17050 mzimmerman@icsalabs 717-790-8144 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 06 06:32:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENT35-0002oG-5v; Thu, 06 Oct 2005 06:32:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENT33-0002oB-0E for ipsec@megatron.ietf.org; Thu, 06 Oct 2005 06:32:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23080 for ; Thu, 6 Oct 2005 06:32:21 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENTC6-0000Jj-31 for ipsec@ietf.org; Thu, 06 Oct 2005 06:41:47 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j96AWHPL001079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Oct 2005 13:32:17 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j96AWEh6005835; Thu, 6 Oct 2005 13:32:14 +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: <17220.64814.649458.245220@fireball.kivinen.iki.fi> Date: Thu, 6 Oct 2005 13:32:14 +0300 From: Tero Kivinen To: Alejandro Perez Mendez Subject: Re: [Ipsec] Rekeying SA bundles In-Reply-To: <1128507550.9671.5.camel@localhost.localdomain> References: <1128169399.2349.15.camel@localhost.localdomain> <17219.42390.247899.807864@fireball.kivinen.iki.fi> <1128507550.9671.5.camel@localhost.localdomain> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Alejandro Perez Mendez writes: > > There is no bundles in the IKEv2 + RFC 2401bis. > > But I what to use IKEv2 + RFC 2401. In this combination, there are > bundles possibility. It is also possible to use IKEv2 and some other RFCs too, but IKEv2 do require RFC2401bis not RFC2401. You can extend the IKEv2 to support other RFCs (including RFC2401), but then you are creating extensions, not using the base IKEv2 + RFC2401bis combination. > What is the desired behaviour in this case? Note that if IKEv2 allows > multiple protocol proposals, it allows, IMHO, old style AH+ESP bundles. The reason IKEv2 allows multiple protocol proposal is partly because of the copied structure of the ISAKMP and partly because it do allow us to extend the protocol in the future. IKEv2 could be used also for old style AH+ESP bundles, but when used with RFC2401bis there is no requirement for that kind of support. Thus if you implement IKEv2 and RFC2401bis there is no need to support those. The desired behavior is not specified, as it is outside the scope of these documents. If you want to define what is the desired behavior then you need to write a document describing how to use IKEv2 with RFC2401. I do not think we should be wasting our time to even consider such document. The RFC2401bis describes how the same effect (AH+ESP) can be done using different method, and the IKEv2 rekeying text is completely in sync in that. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 06 17:12:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENd2C-00051J-W1; Thu, 06 Oct 2005 17:12:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENd2B-000517-Rf for ipsec@megatron.ietf.org; Thu, 06 Oct 2005 17:12:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16592 for ; Thu, 6 Oct 2005 17:12:08 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENdBJ-0000PS-9o for ipsec@ietf.org; Thu, 06 Oct 2005 17:21:39 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j96LC0KW024941 for ; Thu, 6 Oct 2005 14:12:01 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 6 Oct 2005 14:11:52 -0700 To: IPsec WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Ipsec] Important changes in draft-hoffman-rfc3664bis; please review X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Greetings again. At the IKEv2 bakeoff, a significant problem was found with draft-hoffman-rfc3664bis, which has already been put in the RFC Editor's queue. It would have been nice if this had been noticed before we all agreed that the document was sound, but there is still time to make a technical change to fix this. A summary of the problem is: In IKEv2 section 2.14 on generating keying material, it says: If the negotiated prf takes a fixed length key and the lengths of Ni and Nr do not add up to that length, half the bits must come from Ni and half from Nr, taking the first bits of each. In section 2.15 on authentication, it says: If the negotiated prf takes a fixed size key, the shared secret MUST be of that fixed size. rfc3664bis section 1.1 says: This document specifies the same algorithm as RFC 3664 except that the restriction on keys having to be exactly 128 bits from [AES-XCBC- MAC] is removed. Implementations of RFC 3664 will have the same bits-on-the-wire results as this algorithm; the only difference is that keys that were not equal in length to 128 bits will no longer be rejected, but instead will be made 128 bits. The problem is that changing from fixed-key-size to variable-key-size changes the bits output from generating keying material. Because the nonces must each be at least 128 bits (from IKEv2 section 2.10), the lengths will never add up to the key length unless the key is 256 or longer. Because of this, I have issued a new version of draft-hoffman-rfc3664bis (-05, to be specific), that attempts to solve the problem by adding the following two paragraphs to section 1.1: ----- IKEv2 [IKEv2] uses PRFs for multiple purposes, most notably for generating keying material and authentication of the IKE_SA. The IKEv2 specification differentiates between PRFs with fixed key sizes and those with variable key sizes. When using the PRF described in this document with IKEv2, the PRF is considered to be fixed-length for generating keying material but variable-length for authentication. That is, when generating keying material, "half the bits must come from Ni and half from Nr, taking the first bits of each" as described in IKEv2 section 2.14, but when authenticating with shared secrets (IKEv2 section 2.16), the shared secret does not have to be 128 bits long. This somewhat tortured logic allows IKEv2 implementations that use the fixed-length-key semantics from RFC 3664 to interoperate with implementations that use the variable-length-key semantics of this document. ----- I have also asked Russ Housley to take the previous draft off the RFC Editor's queue and, if there is general agreement on this change, put the revised draft back into the queue. All IKEv2 implementers: please read the whole document carefully (again, I hope), particularly looking at these two paragraphs, and comment on whether this fixes the problems stated. Thanks! --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 06 17:12:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENd2D-00051k-O3; Thu, 06 Oct 2005 17:12:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENd2C-00051C-Hl for ipsec@megatron.ietf.org; Thu, 06 Oct 2005 17:12:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16595 for ; Thu, 6 Oct 2005 17:12:09 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENdBJ-0000PO-9j for ipsec@ietf.org; Thu, 06 Oct 2005 17:21:40 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j96LC0KU024941 for ; Thu, 6 Oct 2005 14:12:01 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 6 Oct 2005 14:05:22 -0700 To: IPsec WG From: Internet-Drafts@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.3 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Ipsec] I-D ACTION:draft-hoffman-rfc3664bis-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) Author(s) : P. Hoffman Filename : draft-hoffman-rfc3664bis-05.txt Pages : 5 Date : 2005-10-6 Some implementations of IP Security (IPsec) may want to use a pseudo- random function derived from the Advanced Encryption Standard (AES). This document describes such an algorithm, called AES-XCBC-PRF-128. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoffman-rfc3664bis-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hoffman-rfc3664bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hoffman-rfc3664bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 07 05:49:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENoqd-0004o7-2H; Fri, 07 Oct 2005 05:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENoqa-0004nj-U7 for ipsec@megatron.ietf.org; Fri, 07 Oct 2005 05:49:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07207 for ; Fri, 7 Oct 2005 05:48:58 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENozq-0005hw-O1 for ipsec@ietf.org; Fri, 07 Oct 2005 05:58:35 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j979mtaw022519; Fri, 7 Oct 2005 12:48:56 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Oct 2005 12:48:55 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Oct 2005 12:48:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] INVALID_KE_PAYLOAD and clarifications document Date: Fri, 7 Oct 2005 12:49:04 +0300 Message-ID: Thread-Topic: [Ipsec] INVALID_KE_PAYLOAD and clarifications document Thread-Index: AcXAQX750ojar02VRp2emlPl1m27kAK25S0g To: X-OriginalArrivalTime: 07 Oct 2005 09:48:55.0038 (UTC) FILETIME=[54B5A9E0:01C5CB24] X-Spam-Score: 0.4 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > Unfortunately the spec can be interpreted two ways there. >=20 > The text in 3.1 says: >=20 > o Responder's SPI (8 octets) - A value chosen by the > responder to identify a unique IKE security association. This > value MUST be zero in the first message of an IKE Initial > Exchange (including repeats of that message including a > cookie) and MUST NOT be zero in any other message. >=20 > which says that it MUST be zero for the cookie request. It does not > clearly say what should be used for the invalid ke payload. >=20 > In the COOKIE notifies there is similar text in 3.10.1: >=20 > COOKIE 16390 >=20 > This notification MAY be included in an IKE_SA_INIT > response. It indicates that the request should be retried > with a copy of this notification as the first payload. > This notification MUST be included in an IKE_SA_INIT > request retry if a COOKIE notification was included in the > initial response. The data associated with this > notification MUST >=20 > If I have understood correctly, you interpret the text in 3.1 include > all IKE_SA_INIT packets (not just cookie retry), but you interpreted > the 3.10.1 you interpreted it to include only the first retry (only > the cookie retry). >=20 > I think we should interpret both of those texts to include all > IKE_SA_INIT retries, i.e both COOKIE and INVALID_KE_PAYLOAD retries. > I.e. SPIr MUST be zero for all of IKE_SA_INIT replies, and COOKIE must > be included by the initiator to the all the retries of the IKE_SA_INIT > after it was first returned by the responder to the initiator. I fully agree with you about the 3.1 part: I think it was intended to=20 cover all IKE_SA_INIT retries. I'm a bit ambiguous about the cookie part, but well, I guess it can be reasonably interpreted that way as well. > There might be reason for the responder to allocate state in the > invalid ke payload, thus he might want to allocate SPIr for that. >=20 > The general text there in 2.6 says: >=20 > initial two eight octet fields in the header are used as a > connection identifier at the beginning of IKE packets. Each > endpoint chooses one of the two SPIs and SHOULD choose them so as > to be unique identifiers of an IKE_SA. An SPI value of zero is > special and indicates that the remote SPI value is not yet known by > the sender. >=20 > which would indicate that if the initiator do know the remote SPI > (SPIr), he should use it. I.e. if the responder have returned SPIr to > initiator, then initiator cannot claim he do not know it and he wants > to use zero because of that. That text would indicate that if the > responder do return SPIr in the COOKIE/INVALID_KE_PAYLOAD (against the > MUST in the document), then initiator should then use that same value > when sending next packet. >=20 > But if consider the text in 3.1 to cover all IKE_SA_INIT messages, > then this MUST NOT happen in any valid implementation of the draft, it > will not really matter what initiator does in that case :-) Yes, I think the text in 3.1 is correct here (and 2.6 was intended more as an overview that didn't yet all include all the special cases). How about adding this to section 2.1 of the clarifications text: If the responder sends a non-zero responder SPI, the initiator should not reject the response just for that reason. However, when retrying the IKE_SA_INIT request, the initiator will use a zero responder SPI, as described in Section 3.1: "Responder's SPI [...] This value MUST be zero in the first message of an IKE Initial Exchange (including repeats of that message including a cookie) [...]". We believe the intent was to cover repeats of that message due to other reasons, such as INVALID_KE_PAYLOAD, as well. And re-writing section 2.4 as follows: There are two common reasons why the initiator may have to retry the IKE_SA_INIT exchange: the responder requests a cookie or wants a different Diffie-Hellman group than was included in the KEi payload. Both of these cases are quite simple alone, but it is not totally obvious what happens when they occur at the same time; i.e., IKE_SA_INIT exchange is retried several times. The main question seems to be the following: if the initiator receives a cookie from the responder, should it include the cookie in only the next retry of the IKE_SA_INIT request, or in all subsequent retries as well? Section 3.10.1 says that: "This notification MUST be included in an IKE_SA_INIT request retry if a COOKIE notification was included in the initial response." This could be interpreted as saying that when a cookie is received in the initial response, it is included in all retries. On the other hand, Section 2.6 says that: =20 "Initiators who receive such responses MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE containing the responder supplied cookie data as the first payload and all other payloads unchanged." Including the same cookie in later retries makes sense only if the "all other payloads unchanged" restriction applies only to the first retry, but not to subsequent retries. It seems that both interpretations can peacefully co-exist. If the initiator includes the cookie only in the next retry, one additional roundtrip may be needed in some cases: Initiator Responder ----------- ----------- HDR(A,0), SAi1, KEi, Ni --> <-- HDR(A,0), N(COOKIE) HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> <-- HDR(A,0), N(INVALID_KE_PAYLOAD) HDR(A,0), SAi1, KEi', Ni --> <-- HDR(A,0), N(COOKIE') HDR(A,0), N(COOKIE'), SAi1, KEi',Ni --> <-- HDR(A,B), SAr1, KEr, Nr An additional roundtrip is needed also if the initiator includes the cookie in all retries, but the responder does not support this. For instance, if the responder includes the SAi1 and KEi payloads in cookie calculation, it will reject the request by sending a new cookie (see also Section 2.5 of this document for more text about invalid cookies): Initiator Responder ----------- ----------- HDR(A,0), SAi1, KEi, Ni --> <-- HDR(A,0), N(COOKIE) HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> <-- HDR(A,0), N(INVALID_KE_PAYLOAD) HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> <-- HDR(A,0), N(COOKIE') HDR(A,0), N(COOKIE'), SAi1, KEi',Ni --> <-- HDR(A,B), SAr1, KEr, Nr If both peers support including the cookie in all retries, a slightly shorter exchange can happen: Initiator Responder ----------- ----------- HDR(A,0), SAi1, KEi, Ni --> <-- HDR(A,0), N(COOKIE) HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> <-- HDR(A,0), N(INVALID_KE_PAYLOAD) HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> <-- HDR(A,B), SAr1, KEr, Nr =20 This document recommends that implementations should support this shorter exchange, but it must not be assumed the other peer also supports this. In theory, even this exchange has one unnecessary roundtrip, as both the cookie and Diffie-Hellman group could be checked at the same time: Initiator Responder ----------- ----------- HDR(A,0), SAi1, KEi, Ni --> <-- HDR(A,0), N(COOKIE), N(INVALID_KE_PAYLOAD) HDR(A,0), N(COOKIE), SAi1, KEi',Ni --> <-- HDR(A,B), SAr1, KEr, Nr However, it is clear that this case is not allowed by the text in Section 2.6, since "all other payloads" clearly includes the KEi payload as well. Does this look right to you? Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 10 04:18:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOsrS-0002Uc-SP; Mon, 10 Oct 2005 04:18:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOsrQ-0002UV-F7 for ipsec@megatron.ietf.org; Mon, 10 Oct 2005 04:18:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24103 for ; Mon, 10 Oct 2005 04:18:14 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOt1I-0005OH-25 for ipsec@ietf.org; Mon, 10 Oct 2005 04:28:28 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j9A8I4Gd012390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Oct 2005 11:18:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9A8I3Mw011461; Mon, 10 Oct 2005 11:18:03 +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: <17226.9147.670065.689231@fireball.kivinen.iki.fi> Date: Mon, 10 Oct 2005 11:18:03 +0300 From: Tero Kivinen To: Subject: RE: [Ipsec] INVALID_KE_PAYLOAD and clarifications document In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 8 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > How about adding this to section 2.1 of the clarifications text: > > If the responder sends a non-zero responder SPI, the initiator > should not reject the response just for that reason. However, when > retrying the IKE_SA_INIT request, the initiator will use a zero > responder SPI, as described in Section 3.1: "Responder's SPI [...] > This value MUST be zero in the first message of an IKE Initial > Exchange (including repeats of that message including a cookie) > [...]". We believe the intent was to cover repeats of that message > due to other reasons, such as INVALID_KE_PAYLOAD, as well. I think that version is also good, as it gives only one option. Another option would be to say "value MUST be copied to later retries". That version could allow later some optional statefull error processing to be done in case if IKE_SA_INIT requests too, but I do not think we need that. > And re-writing section 2.4 as follows: ... > Does this look right to you? Yes. Do we already have section saying what to do if N(COOKIE) returned by the initiator is incorrect? If not we need to add that, saying that if N(COOKIE) returned is invalid, then N(COOKIE) is simply ignored and processing continues just like it never was there, meaning that if cookie is required new cookie is requested, and if no cookie is required then processing goes forward. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 10 10:25:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOyas-0002LE-QM; Mon, 10 Oct 2005 10:25:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOyar-0002L9-QZ for ipsec@megatron.ietf.org; Mon, 10 Oct 2005 10:25:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12701 for ; Mon, 10 Oct 2005 10:25:31 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOykl-0006Sb-NS for ipsec@ietf.org; Mon, 10 Oct 2005 10:35:49 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9AEPQgP027386; Mon, 10 Oct 2005 17:25:28 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Oct 2005 17:25:28 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Oct 2005 17:25:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] INVALID_KE_PAYLOAD and clarifications document Date: Mon, 10 Oct 2005 17:25:26 +0300 Message-ID: Thread-Topic: [Ipsec] INVALID_KE_PAYLOAD and clarifications document Thread-Index: AcXNczOBtdTYx7hUQQehh6WdCLN5jwAMpCtQ To: X-OriginalArrivalTime: 10 Oct 2005 14:25:28.0259 (UTC) FILETIME=[76478130:01C5CDA6] X-Spam-Score: 0.4 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > I think that version is also good, as it gives only one option. > Another option would be to say "value MUST be copied to later > retries". That version could allow later some optional statefull=20 > error processing to be done in case if IKE_SA_INIT requests too,=20 > but I do not think we need that. I agree, we don't need that (and even if we did need that, it would IMHO be a non-trivial technical change to the IKEv2 spec, not a clarification). > > Does this look right to you? >=20 > Yes. >=20 > Do we already have section saying what to do if N(COOKIE) returned by > the initiator is incorrect? If not we need to add that, saying that if > N(COOKIE) returned is invalid, then N(COOKIE) is simply ignored and > processing continues just like it never was there, meaning that if > cookie is required new cookie is requested, and if no cookie is > required then processing goes forward.=20 We're planning to add a section about that in -06 (as was hinted by the text "see also Section 2.5 of this document for more text=20 about invalid cookies" -- but the current draft doesn't have=20 Section 2.5 yet :-) Cheers, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 12 08:48:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPg1e-0008Df-VC; Wed, 12 Oct 2005 08:48:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPg1d-0008DX-5S for ipsec@megatron.ietf.org; Wed, 12 Oct 2005 08:48:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18846 for ; Wed, 12 Oct 2005 08:48:02 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPgBt-00013q-GV for ipsec@ietf.org; Wed, 12 Oct 2005 08:58:42 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9CClsjr007631; Wed, 12 Oct 2005 15:47:57 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Oct 2005 15:47:55 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Oct 2005 15:47:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Important changes in draft-hoffman-rfc3664bis; please review Date: Wed, 12 Oct 2005 15:47:54 +0300 Message-ID: Thread-Topic: [Ipsec] Important changes in draft-hoffman-rfc3664bis; please review Thread-Index: AcXKuxDUKb5AwC8aSZmqcGdsE48+UQEbqylw To: , X-OriginalArrivalTime: 12 Oct 2005 12:47:55.0911 (UTC) FILETIME=[2AD59170:01C5CF2B] X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The text should also say that for the purpose of algorithm negotiation, this PRF has a fixed key length. In other words, the "key length" attribute is not included in the SA payloads. BTW, there's text in IKEv2 -17 that has this wrong. Section 3.3.5 says that "The only algorithms defined in this document that accept attributes are the AES based encryption, integrity, and pseudo-random functions, which require a single attribute specifying key width." Only ENCR_AES_CBC and ENCR_AES_CTR accept different key lengths;=20 and since there's no specified default key length, the key length attribute MUST be included. But AUTH_AES_XCBC_96 [RFC3566] always uses 128-bit keys, and PRF_AES128_CBC always uses 128-bit AES internally (even with 3664bis). Best regards, Pasi > -----Original Message----- > From: Paul Hoffman > Sent: 07 October, 2005 00:12 > To: IPsec WG > Subject: [Ipsec] Important changes in draft-hoffman-rfc3664bis; please review >=20 > Greetings again. At the IKEv2 bakeoff, a significant problem was=20 > found with draft-hoffman-rfc3664bis, which has already been put in=20 > the RFC Editor's queue. It would have been nice if this had been=20 > noticed before we all agreed that the document was sound, but there=20 > is still time to make a technical change to fix this. >=20 > A summary of the problem is: >=20 > In IKEv2 section 2.14 on generating keying material, it says: > If the negotiated prf takes a fixed length key and the lengths > of Ni and Nr do not add up to that length, half the bits must > come from Ni and half from Nr, taking the first bits of each. > In section 2.15 on authentication, it says: > If the negotiated prf takes a fixed size key, the shared secret > MUST be of that fixed size. > rfc3664bis section 1.1 says: > This document specifies the same algorithm as RFC 3664 except > that the restriction on keys having to be exactly 128 bits from > [AES-XCBC- MAC] is removed. Implementations of RFC 3664 will > have the same bits-on-the-wire results as this algorithm; the > only difference is that keys that were not equal in length to > 128 bits will no longer be rejected, but instead will be made > 128 bits. > The problem is that changing from fixed-key-size to variable-key-size=20 > changes the bits output from generating keying material. Because the=20 > nonces must each be at least 128 bits (from IKEv2 section 2.10), the=20 > lengths will never add up to the key length unless the key is 256 or=20 > longer. >=20 > Because of this, I have issued a new version of=20 > draft-hoffman-rfc3664bis (-05, to be specific), that attempts to=20 > solve the problem by adding the following two paragraphs to section=20 > 1.1: >=20 > ----- > IKEv2 [IKEv2] uses PRFs for multiple purposes, most notably for > generating keying material and authentication of the IKE_SA. The > IKEv2 specification differentiates between PRFs with=20 > fixed key sizes and those with variable key sizes. >=20 > When using the PRF described in this document with IKEv2, the > PRF is considered to be fixed-length for generating keying > material but variable-length for authentication. That is, when > generating keying material, "half the bits must come from Ni and > half from Nr, taking the first bits of each" as described in > IKEv2 section 2.14, but when authenticating with shared secrets > (IKEv2 section 2.16), the shared secret does not have to be 128 > bits long. This somewhat tortured logic allows IKEv2 > implementations that use the fixed-length-key semantics from RFC > 3664 to interoperate with implementations that use the > variable-length-key semantics of this document. > ----- >=20 > I have also asked Russ Housley to take the previous draft off the RFC=20 > Editor's queue and, if there is general agreement on this change, put=20 > the revised draft back into the queue. >=20 > All IKEv2 implementers: please read the whole document carefully=20 > (again, I hope), particularly looking at these two paragraphs, and=20 > comment on whether this fixes the problems stated. Thanks! >=20 > --Paul Hoffman, Director > --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 12 09:08:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPgLL-0006Jj-OA; Wed, 12 Oct 2005 09:08:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPgLJ-0006DP-R5 for ipsec@megatron.ietf.org; Wed, 12 Oct 2005 09:08:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20062 for ; Wed, 12 Oct 2005 09:08:23 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPgVc-0001gT-78 for ipsec@ietf.org; Wed, 12 Oct 2005 09:19:05 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9CD5KHa025779 for ; Wed, 12 Oct 2005 16:05:21 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Oct 2005 16:08:20 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Oct 2005 16:07:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Important changes in draft-hoffman-rfc3664bis; please review Date: Wed, 12 Oct 2005 16:07:28 +0300 Message-ID: Thread-Topic: [Ipsec] Important changes in draft-hoffman-rfc3664bis; please review Thread-Index: AcXKuxDUKb5AwC8aSZmqcGdsE48+UQEbqylwAADdguA= To: X-OriginalArrivalTime: 12 Oct 2005 13:07:29.0086 (UTC) FILETIME=[E619DDE0:01C5CF2D] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Earlier today I wrote: > "The only algorithms defined in this document that accept > attributes are the AES based encryption, integrity, and > pseudo-random functions, which require a single attribute > specifying key width." > > Only ENCR_AES_CBC and ENCR_AES_CTR accept different key lengths;=20 > and since there's no specified default key length, the key length > attribute MUST be included. ...except that RFC3602 actually does include a sentence saying=20 "The default key size is 128 bits". However, it later talks about negotiating this in IKEv1: Since the AES allows variable key lengths, the Key Length attribute MUST be specified in both a Phase 1 exchange [IKE] and a Phase 2 exchange [DOI]. And since the IKEv2 draft also uses the word "require", I think the=20 default value mentioned in RFC3602 was intended as a configuration hint, and does not imply that sending the Key Length attribute would be optional.=20 (More stuff for the IKEv2 clarifications draft, it seems :-) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 12 09:48:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPgxr-0001Ur-1g; Wed, 12 Oct 2005 09:48:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPgxp-0001Ud-BX for ipsec@megatron.ietf.org; Wed, 12 Oct 2005 09:48:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21922 for ; Wed, 12 Oct 2005 09:48:10 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPh89-0002f4-35 for ipsec@ietf.org; Wed, 12 Oct 2005 09:58:53 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j9CDluqd011081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Oct 2005 16:47:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9CDlufC003212; Wed, 12 Oct 2005 16:47:56 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17229.5132.144599.952212@fireball.kivinen.iki.fi> Date: Wed, 12 Oct 2005 16:47:56 +0300 From: Tero Kivinen To: Pasi.Eronen@nokia.com Subject: RE: [Ipsec] Important changes in draft-hoffman-rfc3664bis; please review In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 7 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, paul.hoffman@vpnc.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > The text should also say that for the purpose of algorithm > negotiation, this PRF has a fixed key length. In other words, > the "key length" attribute is not included in the SA payloads. I was about the send the same comment earlier, but noticed that the Key Lenght attribute is defined to be used with Encryption algorithm, not with PRFs, so there is not really specified way to tell what is the PRF key lenght (i.e. the key length is taken from the actual keying material fed to the PRF). > BTW, there's text in IKEv2 -17 that has this wrong. Section 3.3.5 > says that > > "The only algorithms defined in this document that accept > attributes are the AES based encryption, integrity, and > pseudo-random functions, which require a single attribute > specifying key width." > > Only ENCR_AES_CBC and ENCR_AES_CTR accept different key lengths; > and since there's no specified default key length, the key length > attribute MUST be included. > > But AUTH_AES_XCBC_96 [RFC3566] always uses 128-bit keys, and > PRF_AES128_CBC always uses 128-bit AES internally (even with 3664bis). That text in the IKEv2 has always confused me, is it so that for example ENCR_CAST or ENCR_BLOWFISH cannot be used with any other key length than the default, or is it so that key length is not needed if it is default, but it can be given? The text says that only algorithms defined that accept attributes are AES, so that would indicate BLOWFISH or CAST cannot use Key length attribute. I think the original text should have said that only algorithms that REQUIRE key lengths attributes are the AES based, others can use it but it is not required. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 13 09:53:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ3WS-00057A-J2; Thu, 13 Oct 2005 09:53:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ3WR-00056u-FO for ipsec@megatron.ietf.org; Thu, 13 Oct 2005 09:53:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18949 for ; Thu, 13 Oct 2005 09:53:24 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ3gw-0004Cv-Uf for ipsec@ietf.org; Thu, 13 Oct 2005 10:04:20 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9DDpS2C032285; Thu, 13 Oct 2005 16:51:30 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Oct 2005 16:53:20 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Oct 2005 16:52:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Oct 2005 16:52:29 +0300 Message-ID: Thread-Topic: Key length attribute (was: Important changes in draft-hoffman-rfc3664bis; please review) Thread-Index: AcXPM6AhCPvjH+BeRsa2kcOHaWXDUwAySiCw To: X-OriginalArrivalTime: 13 Oct 2005 13:52:33.0273 (UTC) FILETIME=[5C55CE90:01C5CFFD] X-Spam-Score: 0.3 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org Subject: [Ipsec] Key length attribute (was: Important changes in draft-hoffman-rfc3664bis; please review) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > Pasi.Eronen@nokia.com writes: > > The text should also say that for the purpose of algorithm > > negotiation, this PRF has a fixed key length. In other words, > > the "key length" attribute is not included in the SA payloads. >=20 > I was about the send the same comment earlier, but noticed that the > Key Lenght attribute is defined to be used with Encryption algorithm, > not with PRFs, so there is not really specified way to tell what is > the PRF key lenght (i.e. the key length is taken from the actual > keying material fed to the PRF).=20 Hmm... that's true. =20 > > BTW, there's text in IKEv2 -17 that has this wrong. Section 3.3.5 > > says that > >=20 > > "The only algorithms defined in this document that accept > > attributes are the AES based encryption, integrity, and > > pseudo-random functions, which require a single attribute > > specifying key width." > >=20 > > Only ENCR_AES_CBC and ENCR_AES_CTR accept different key lengths;=20 > > and since there's no specified default key length, the key length > > attribute MUST be included. > >=20 > > But AUTH_AES_XCBC_96 [RFC3566] always uses 128-bit keys, and > > PRF_AES128_CBC always uses 128-bit AES internally (even=20 > with 3664bis). >=20 > That text in the IKEv2 has always confused me, is it so that for > example ENCR_CAST or ENCR_BLOWFISH cannot be used with any other key > length than the default, or is it so that key length is not needed if > it is default, but it can be given? >=20 > The text says that only algorithms defined that accept attributes are > AES, so that would indicate BLOWFISH or CAST cannot use Key length > attribute. I think the original text should have said that only > algorithms that REQUIRE key lengths attributes are the AES based, > others can use it but it is not required. Yes, I think the intention was not to prohibit variable-length keys with e.g. Blowfish. Here's proposed text for the clarifications document: Section 3.3.5 says that "The only algorithms defined in this document that accept attributes are the AES based encryption, integrity, and pseudo-random functions, which require a single attribute specifying key width." This is incorrect. The AES-based integrity and pseudo-random functions defined in this document always use a 128-bit key. In fact, there are currently no integrity or PRF algorithms that use the key length attribute (and we recommend that they should not be defined in the future either). For encryption algorithms, the situation is slightly more complex since there are three different types of algorithms: o The key length attribute is never used with algorithms that=20 use a fixed length key, such as DES, 3DES and IDEA. =20 o The key length attribute is always included for the currently defined AES-based algorithms (CBC, CTR, CCM and GCM). Omitting the key length attribute is not allowed; if the proposal does not contain it, it has to be rejected. o For other algorithms, the key length attribute can be included but is not mandatory. These algorithms include, e.g., RC5, CAST and BLOWFISH. If the key length attribute is not included, the=20 default value specified in [RFC2451] is used. Does this look right to you? Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 13 10:00:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ3cp-0006yW-Gc; Thu, 13 Oct 2005 10:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ3cn-0006xU-1m for ipsec@megatron.ietf.org; Thu, 13 Oct 2005 10:00:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19472 for ; Thu, 13 Oct 2005 09:59:55 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ3nG-0004Rv-Da for ipsec@ietf.org; Thu, 13 Oct 2005 10:10:52 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9DDxtvD009093 for ; Thu, 13 Oct 2005 07:59:55 -0600 (MDT) Received: from punchin-danmcd.east.sun.com (punchin-danmcd.East.Sun.COM [129.148.19.2]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j9DDxssn014322 for ; Thu, 13 Oct 2005 09:59:55 -0400 (EDT) Received: from punchin-danmcd.east.sun.com (localhost [127.0.0.1]) by punchin-danmcd.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j9DDxHDL003287; Thu, 13 Oct 2005 09:59:17 -0400 (EDT) Received: (from danmcd@localhost) by punchin-danmcd.east.sun.com (8.13.4+Sun/8.13.4/Submit) id j9DDxHsO003286; Thu, 13 Oct 2005 09:59:17 -0400 (EDT) Date: Thu, 13 Oct 2005 09:59:17 -0400 From: Dan McDonald To: Pasi.Eronen@nokia.com Subject: Re: [Ipsec] Key length attribute (was: Important changes in draft-hoffman-rfc3664bis; please review) Message-ID: <20051013135917.GG3069@everywhere.east.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Organization: Sun Microsystems, Inc. - Solaris Networking & Security X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ipsec@ietf.org, kivinen@iki.fi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org So glad this thread came up! On Thu, Oct 13, 2005 at 04:52:29PM +0300, Pasi.Eronen@nokia.com wrote: > > Yes, I think the intention was not to prohibit variable-length > keys with e.g. Blowfish. Here's proposed text for the clarifications > document: > > Section 3.3.5 says that "The only algorithms defined in this > document that accept attributes are the AES based encryption, > integrity, and pseudo-random functions, which require a single > attribute specifying key width." > > This is incorrect. The AES-based integrity and pseudo-random > functions defined in this document always use a 128-bit key. In > fact, there are currently no integrity or PRF algorithms that use > the key length attribute (and we recommend that they should not > be defined in the future either). > > For encryption algorithms, the situation is slightly more complex > since there are three different types of algorithms: > > o The key length attribute is never used with algorithms that > use a fixed length key, such as DES, 3DES and IDEA. > > o The key length attribute is always included for the currently > defined AES-based algorithms (CBC, CTR, CCM and GCM). Omitting > the key length attribute is not allowed; if the proposal does > not contain it, it has to be rejected. > > o For other algorithms, the key length attribute can be included > but is not mandatory. These algorithms include, e.g., RC5, CAST > and BLOWFISH. If the key length attribute is not included, the > default value specified in [RFC2451] is used. > > Does this look right to you? Except for one thing, yes it does. That one thing: - IKE is supposed to be algorithm-agile. Let's say some grinning weirdo comes up with a better-than-AES algorithm, or worse, some other grinning weirdo breaks AES and we NEED a new cipher. How will we handle ciphers in the future? There are two ways to solve this: 1.) All algorithms must have a default key length that is used when no key-length attribute is present. This means picking a default size for AES. 2.) All new algorithms with variable-sized keys are treated like AES, and MUST include a key-length attribute. I don't care which one of those two is picked, but one of them must be used to maintain algorithm-agility. Dan _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 13 16:25:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9eG-0003JU-L0; Thu, 13 Oct 2005 16:25:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ9eF-0003JP-1g for ipsec@megatron.ietf.org; Thu, 13 Oct 2005 16:25:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15378 for ; Thu, 13 Oct 2005 16:25:51 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ9oo-0008Rr-2d for ipsec@ietf.org; Thu, 13 Oct 2005 16:36:51 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9DKPkVE023779; Thu, 13 Oct 2005 13:25:46 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20051013135917.GG3069@everywhere.east.sun.com> References: <20051013135917.GG3069@everywhere.east.sun.com> Date: Thu, 13 Oct 2005 13:25:44 -0700 To: Dan McDonald , Pasi.Eronen@nokia.com From: Paul Hoffman Subject: Re: [Ipsec] Key length attribute (was: Important changes in draft-hoffman-rfc3664bis; please review) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipsec@ietf.org, kivinen@iki.fi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 9:59 AM -0400 10/13/05, Dan McDonald wrote: > > Does this look right to you? > >Except for one thing, yes it does. > >That one thing: > > - IKE is supposed to be algorithm-agile. Let's say some grinning > weirdo comes up with a better-than-AES algorithm, or worse, some > other grinning weirdo breaks AES and we NEED a new cipher. > > How will we handle ciphers in the future? > >There are two ways to solve this: > > 1.) All algorithms must have a default key length that is used when > no key-length attribute is present. This means picking a default > size for AES. > > 2.) All new algorithms with variable-sized keys are treated like AES, > and MUST include a key-length attribute. > >I don't care which one of those two is picked, but one of them must be used >to maintain algorithm-agility. I strongly support the second one. Default key lengths are of no use to the user, and are easy to mis-implement, particularly many years from now when the vogue may change. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 13 20:47:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQDj7-0004jg-S1; Thu, 13 Oct 2005 20:47:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQDj5-0004jb-Sn for ipsec@megatron.ietf.org; Thu, 13 Oct 2005 20:47:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07035 for ; Thu, 13 Oct 2005 20:47:06 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQDth-0001DD-B2 for ipsec@ietf.org; Thu, 13 Oct 2005 20:58:10 -0400 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j9E0kxwn005726; Thu, 13 Oct 2005 20:47:00 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Oct 2005 20:46:59 -0400 Message-ID: To: Pasi.Eronen@nokia.com Date: Thu, 13 Oct 2005 20:46:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.10.13.34 X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipsec@ietf.org Subject: [Ipsec] Integrity and key length X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi, > This is incorrect. The AES-based integrity and pseudo-random > functions defined in this document always use a 128-bit key. In > fact, there are currently no integrity or PRF algorithms that use > the key length attribute (and we recommend that they should not > be defined in the future either). Hmm ... draft-mcgrew-aes-gmac-esp-00.txt is using AES with a variable key length in a MAC and is using the key length attribute. This didn't come up with the AES XCBC MAC (RFC 3566) because its AES key length is fixed at 128 bits. If the key length attribute is really a bad idea for integrity algorithms, this draft will need to be certain to allocate 3 transform identifiers for the possible 128 bit, 192 bit and 256 bit key lengths. I thought I'd check here before sending the authors a strong suggestion to allocate 3 transform identifiers (although they seem to be already halfway there, if one compares Sections 9.3 and 13 of the draft). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 14 03:55:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQKPu-0006LV-SB; Fri, 14 Oct 2005 03:55:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQKPt-0006LQ-1G for ipsec@megatron.ietf.org; Fri, 14 Oct 2005 03:55:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24213 for ; Fri, 14 Oct 2005 03:55:43 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQKaX-0003IP-QG for ipsec@ietf.org; Fri, 14 Oct 2005 04:06:51 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j9E7tiBZ018906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Oct 2005 10:55:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9E7tisI012172; Fri, 14 Oct 2005 10:55:44 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17231.25728.73236.324773@fireball.kivinen.iki.fi> Date: Fri, 14 Oct 2005 10:55:44 +0300 From: Tero Kivinen To: Pasi.Eronen@nokia.com Subject: [Ipsec] Key length attribute (was: Important changes in draft-hoffman-rfc3664bis; please review) In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > Yes, I think the intention was not to prohibit variable-length > keys with e.g. Blowfish. Here's proposed text for the clarifications > document: > > Section 3.3.5 says that "The only algorithms defined in this > document that accept attributes are the AES based encryption, > integrity, and pseudo-random functions, which require a single > attribute specifying key width." > > This is incorrect. The AES-based integrity and pseudo-random > functions defined in this document always use a 128-bit key. In > fact, there are currently no integrity or PRF algorithms that use > the key length attribute (and we recommend that they should not > be defined in the future either). > > For encryption algorithms, the situation is slightly more complex > since there are three different types of algorithms: > > o The key length attribute is never used with algorithms that > use a fixed length key, such as DES, 3DES and IDEA. > > o The key length attribute is always included for the currently > defined AES-based algorithms (CBC, CTR, CCM and GCM). Omitting > the key length attribute is not allowed; if the proposal does > not contain it, it has to be rejected. > > o For other algorithms, the key length attribute can be included > but is not mandatory. These algorithms include, e.g., RC5, CAST > and BLOWFISH. If the key length attribute is not included, the > default value specified in [RFC2451] is used. > > Does this look right to you? Looks perfect for me. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 14 05:41:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQM4N-0004Wo-3J; Fri, 14 Oct 2005 05:41:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQM4L-0004Wj-9t for ipsec@megatron.ietf.org; Fri, 14 Oct 2005 05:41:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28467 for ; Fri, 14 Oct 2005 05:41:37 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQMEz-0005uf-86 for ipsec@ietf.org; Fri, 14 Oct 2005 05:52:44 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9E9fZ9s007159; Fri, 14 Oct 2005 12:41:36 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 12:41:32 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 12:41:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Key length attribute (was: Important changes in draft-hoffman-rfc3664bis; please review) Date: Fri, 14 Oct 2005 12:41:26 +0300 Message-ID: Thread-Topic: [Ipsec] Key length attribute (was: Important changes in draft-hoffman-rfc3664bis; please review) Thread-Index: AcXP/qEu7KmqByByTUiXiToUjVOAzgAodx/w To: X-OriginalArrivalTime: 14 Oct 2005 09:41:32.0569 (UTC) FILETIME=[75DE8090:01C5D0A3] X-Spam-Score: 0.4 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dan McDonald wrote: > Except for one thing, yes it does. >=20 > That one thing: >=20 > - IKE is supposed to be algorithm-agile. Let's say=20 > some grinning weirdo comes up with a better-than-AES=20 > algorithm, or worse, some other grinning weirdo breaks=20 > AES and we NEED a new cipher. >=20 > How will we handle ciphers in the future? >=20 > There are two ways to solve this: >=20 > 1.) All algorithms must have a default key length that=20 > is used when no key-length attribute is present. =20 > This means picking a default size for AES. >=20 > 2.) All new algorithms with variable-sized keys are=20 > treated like AES, and MUST include a key-length=20 > attribute. >=20 > I don't care which one of those two is picked, but one of=20 > them must be used to maintain algorithm-agility. Option 1 would be an incompatible technical change to the=20 current specification, so I'm not in favour of that one. Option 2 sounds reasonable to me, but actually there are a=20 couple of other options that would work as well: =20 3.) All new algorithms must allocate different transform numbers for different key lengths. E.g., when someone defines a new Really Great Encryption Algorithm (RGEA), we would allocate =20 two numbers for ENCR_RGEA128_CBC and ENCR_RGEA256_CBC. =20 4.) When a new algorithm with a variable-sized key is defined, the specification can choose which way to go: either it=20 defines a default key length (like Blowfish and RC5), or=20 it says that including the key length transform attribute is mandatory. These are not totally exclusive; one algorithm could follow 2 and another algorithm 3 without problems... There was actually some discussion about this issue before; see the "AES Algorithm Negotiation in IKE" thread in Oct-Nov 2004. The end result of that discussion was that CTR/CCM/GCM use the key length attribute just like CBC, but they define different transform IDs for different ICV lengths (instead of defining a separate "ICV length" transform attribute). Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 14 05:54:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQMH2-0000HO-VJ; Fri, 14 Oct 2005 05:54:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQMGz-0000HG-LC for ipsec@megatron.ietf.org; Fri, 14 Oct 2005 05:54:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29161 for ; Fri, 14 Oct 2005 05:54:41 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQMRc-0006JP-Qh for ipsec@ietf.org; Fri, 14 Oct 2005 06:05:46 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9E9pUZJ028847; Fri, 14 Oct 2005 12:51:32 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 12:54:37 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 12:54:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Oct 2005 12:54:35 +0300 Message-ID: Thread-Topic: Integrity and key length Thread-Index: AcXQWNoU3YggPJATSPi7QVwbFqZtygASyY4Q To: X-OriginalArrivalTime: 14 Oct 2005 09:54:37.0117 (UTC) FILETIME=[497F06D0:01C5D0A5] X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org Subject: [Ipsec] RE: Integrity and key length X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, Thanks, I did forget GMAC when writing that.. Allocating three different transform identifiers sounds simpler=20 to me, especially since there are no other integrity algorithms=20 that use the key length attribute. But on the other hand, all=20 the AES-based encryption algorithms do use the attribute, so=20 I wouldn't call that a horribly bad choice either... Best regards, Pasi > -----Original Message----- > From: ext Black_David@emc.com [mailto:Black_David@emc.com]=20 > Sent: 14 October, 2005 03:47 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: ipsec@ietf.org > Subject: Integrity and key length >=20 > Pasi, >=20 > > This is incorrect. The AES-based integrity and pseudo-random > > functions defined in this document always use a 128-bit key. In > > fact, there are currently no integrity or PRF algorithms that use > > the key length attribute (and we recommend that they should not > > be defined in the future either). >=20 > Hmm ... draft-mcgrew-aes-gmac-esp-00.txt is using AES with a > variable key length in a MAC and is using the key length attribute. > This didn't come up with the AES XCBC MAC (RFC 3566) because its > AES key length is fixed at 128 bits. If the key length attribute > is really a bad idea for integrity algorithms, this draft will need > to be certain to allocate 3 transform identifiers for the possible > 128 bit, 192 bit and 256 bit key lengths. >=20 > I thought I'd check here before sending the authors a strong > suggestion to allocate 3 transform identifiers (although they seem > to be already halfway there, if one compares Sections 9.3 and 13 of > the draft). >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 14 06:19:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQMfD-0007o7-7G; Fri, 14 Oct 2005 06:19:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQMfA-0007o2-PI for ipsec@megatron.ietf.org; Fri, 14 Oct 2005 06:19:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00052 for ; Fri, 14 Oct 2005 06:19:40 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQMpr-0006q7-2P for ipsec@ietf.org; Fri, 14 Oct 2005 06:30:48 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j9EAJcV3019498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Oct 2005 13:19:38 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9EAJcgB009752; Fri, 14 Oct 2005 13:19:38 +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: <17231.34362.449609.883247@fireball.kivinen.iki.fi> Date: Fri, 14 Oct 2005 13:19:38 +0300 From: Tero Kivinen To: Pasi.Eronen@nokia.com Subject: RE: [Ipsec] Key length attribute (was: Important changes in draft-hoffman-rfc3664bis; please review) In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, danmcd@sun.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > There was actually some discussion about this issue before; see the > "AES Algorithm Negotiation in IKE" thread in Oct-Nov 2004. The end > result of that discussion was that CTR/CCM/GCM use the key length > attribute just like CBC, but they define different transform IDs for > different ICV lengths (instead of defining a separate "ICV length" > transform attribute). The reasoning there was that use the key length attribute if suitable, but do not add any new attributes. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 14 06:40:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQMzZ-0004uq-Ic; Fri, 14 Oct 2005 06:40:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQMzX-0004ui-F7 for ipsec@megatron.ietf.org; Fri, 14 Oct 2005 06:40:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01277 for ; Fri, 14 Oct 2005 06:40:43 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQNAE-0007PD-Tz for ipsec@ietf.org; Fri, 14 Oct 2005 06:51:51 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j9EAeemv002067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Oct 2005 13:40:40 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9EAeeTD011031; Fri, 14 Oct 2005 13:40:40 +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: <17231.35624.243658.390308@fireball.kivinen.iki.fi> Date: Fri, 14 Oct 2005 13:40:40 +0300 From: Tero Kivinen To: Black_David@emc.com Subject: [Ipsec] Integrity and key length In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 20 min X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Black_David@emc.com writes: > > This is incorrect. The AES-based integrity and pseudo-random > > functions defined in this document always use a 128-bit key. In > > fact, there are currently no integrity or PRF algorithms that use > > the key length attribute (and we recommend that they should not > > be defined in the future either). > > Hmm ... draft-mcgrew-aes-gmac-esp-00.txt is using AES with a variable > key length in a MAC and is using the key length attribute. This didn't > come up with the AES XCBC MAC (RFC 3566) because its AES key length is > fixed at 128 bits. If the key length attribute is really a bad idea > for integrity algorithms, this draft will need to be certain to allocate > 3 transform identifiers for the possible 128 bit, 192 bit and 256 bit > key lengths. > > I thought I'd check here before sending the authors a strong suggestion > to allocate 3 transform identifiers (although they seem to be already > halfway there, if one compares Sections 9.3 and 13 of the draft). If we read the key length attribute description from the ikev2 draft, it says: ---------------------------------------------------------------------- - Key Length When using an Encryption Algorithm that has a variable length key, this attribute specifies the key length in bits. (MUST use network byte order). This attribute MUST NOT be used when the specified Encryption Algorithm uses a fixed length key. ---------------------------------------------------------------------- That seems to indicate it is only for encryption algorithm, not for MACs or PRFs. I would actually think it would be best to only select ONE key length to be used in the GMAC, similarly what was done RFC 3566. Is there really need to support other key lengths than 128 now? If so why was it enough to support only that in RFC3566? So my proposal would be that draft-mcgrew-aes-gmac-esp-00.txt is modified so that it DOES NOT use key lenght attribute, and it uses fixed 128 bit key for the AES. The output of the MAC is always 128 bits anyways, so I do not think we gain anything (provided AES is secure) by using longer keylenghts for the AES MACs. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 14 16:15:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVxc-0008LJ-Ua; Fri, 14 Oct 2005 16:15:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVxa-0008KB-Dr for ipsec@megatron.ietf.org; Fri, 14 Oct 2005 16:15:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14378 for ; Fri, 14 Oct 2005 16:15:16 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQW8I-00022C-AZ for ipsec@ietf.org; Fri, 14 Oct 2005 16:26:31 -0400 Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id j9EKEmwW031827 for ; Fri, 14 Oct 2005 15:14:48 -0500 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Fri, 14 Oct 2005 15:14:48 -0500 Message-ID: From: "James Comen (NC/TNT)" To: "'ipsec@ietf.org'" Date: Fri, 14 Oct 2005 15:14:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.5 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Ipsec] Pre-RFC3706 problems X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0188594755==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0188594755== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D0FB.E67477D9" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5D0FB.E67477D9 Content-Type: text/plain; charset="iso-8859-1" Hello, Prior to RFC3706, was waiting for IKE SA expiration the only way to deal with a dead/rebooted IKE peer (assuming different vendors so a proprietary solution was not possible). I know this is mentioned in RFC3706 but I was curious to learn if there were no other alternatives. If a remote peer rebooted and was not passive, could it intiate an IKE negotiation with initial contact? But, if the remote peer was passive or just died without reboot, would the local peer truly be limited to waiting till IKE SA expiry? Thank you, Jim Comen ------_=_NextPart_001_01C5D0FB.E67477D9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pre-RFC3706 problems

Hello,
Prior to RFC3706, was waiting for IKE = SA expiration the only way to deal with a dead/rebooted IKE peer = (assuming different vendors so a proprietary solution was not = possible).  I know this is mentioned in RFC3706 but I was curious = to learn if there were no other alternatives.

If a remote peer rebooted and was not = passive, could it intiate an IKE negotiation with initial = contact?
But, if the remote peer was passive = or just died without reboot, would the local peer truly be limited to = waiting till IKE SA expiry?

Thank you,
Jim Comen

------_=_NextPart_001_01C5D0FB.E67477D9-- --===============0188594755== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0188594755==-- From ipsec-bounces@ietf.org Fri Oct 14 19:06:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQYdK-00060v-S9; Fri, 14 Oct 2005 19:06:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQYdI-0005t7-IA for ipsec@megatron.ietf.org; Fri, 14 Oct 2005 19:06:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02666 for ; Fri, 14 Oct 2005 19:06:31 -0400 (EDT) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQYo5-0001RZ-QV for ipsec@ietf.org; Fri, 14 Oct 2005 19:17:47 -0400 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by kremlin.juniper.net with ESMTP; 14 Oct 2005 16:06:25 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,216,1125903600"; d="scan'208"; a="488818997:sNHT23048412" Received: from gluon.jnpr.net ([172.24.15.23]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 16:06:25 -0700 Received: from ghuang-lnx.netscreen.com ([10.150.65.191]) by gluon.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 Oct 2005 16:06:25 -0700 Subject: Re: [Ipsec] Pre-RFC3706 problems From: Geoffrey Huang To: "James Comen (NC/TNT)" In-Reply-To: References: Content-Type: text/plain Date: Fri, 14 Oct 2005 16:06:24 -0700 Message-Id: <1129331184.29936.5.camel@ghuang-lnx.juniper.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2005 23:06:25.0127 (UTC) FILETIME=[E67A0F70:01C5D113] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: "'ipsec@ietf.org'" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Fri, 2005-10-14 at 15:14 -0500, James Comen (NC/TNT) wrote: > Hello, > Prior to RFC3706, was waiting for IKE SA expiration the only way to > deal with a dead/rebooted IKE peer (assuming different vendors so a > proprietary solution was not possible). I know this is mentioned in > RFC3706 but I was curious to learn if there were no other > alternatives. > There was the heartbeats draft that Andrew Krywaniuk worked on. I'm not sure how many implementations there were, however. Of course, there was always Initial Contact, but again, the I don't think that many implementations did IC properly back then. (I have to say, however, that "back then" was before my time.) > If a remote peer rebooted and was not passive, could it intiate an IKE > negotiation with initial contact? I'm not sure what you mean by "passive," but yes, IC should help the situation. This assumes that the peer will reboot, however, or at least become reachable again. In some cases, the peer might become unreachable indefinitely. > But, if the remote peer was passive or just died without reboot, would > the local peer truly be limited to waiting till IKE SA expiry? > Yes, unless there was some manual intervention. -g > Thank you, > Jim Comen > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 14 19:32:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQZ2l-0007eB-7Y; Fri, 14 Oct 2005 19:32:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQZ2g-0007e3-RC for ipsec@megatron.ietf.org; Fri, 14 Oct 2005 19:32:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04347 for ; Fri, 14 Oct 2005 19:32:45 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQZDR-0002Go-4o for ipsec@ietf.org; Fri, 14 Oct 2005 19:44:01 -0400 Received: from elwamui-rustique.atl.sa.earthlink.net ([209.86.224.48]) by pop-knobcone.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EQZ2V-00050O-00; Fri, 14 Oct 2005 19:32:39 -0400 Message-ID: <30399617.1129332759373.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> Date: Fri, 14 Oct 2005 16:32:39 -0700 (GMT-07:00) From: "Scott G. Kelly" To: Geoffrey Huang , "James Comen (NC/TNT)" Subject: Re: [Ipsec] Pre-RFC3706 problems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-Spam-Score: 2.2 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: "'ipsec@ietf.org'" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Scott G. Kelly" List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org "Back then" I worked on a system that did a couple of things - first, rebooted systems would initiate IKE (sending an initial contact message in the process) if (1) they had outbound traffic requiring protection or (2) they received ESP or IKE from a known peer for which no SAs existed. Another thing we did was send pings through the phase 2 tunnels to detect black holes, tearing down SAs for which there was no other end. What we were doing was non-standard, and arguably, there were some security issues with the approaches. However, it kept customers a little bit happier. The lack of an interoperable approach ultimately led to RFC3706, but I imagine there are still proprietary solutions out there. -----Original Message----- From: Geoffrey Huang Sent: Oct 14, 2005 4:06 PM To: "James Comen (NC/TNT)" Cc: "'ipsec@ietf.org'" Subject: Re: [Ipsec] Pre-RFC3706 problems On Fri, 2005-10-14 at 15:14 -0500, James Comen (NC/TNT) wrote: > Hello, > Prior to RFC3706, was waiting for IKE SA expiration the only way to > deal with a dead/rebooted IKE peer (assuming different vendors so a > proprietary solution was not possible). I know this is mentioned in > RFC3706 but I was curious to learn if there were no other > alternatives. > There was the heartbeats draft that Andrew Krywaniuk worked on. I'm not sure how many implementations there were, however. Of course, there was always Initial Contact, but again, the I don't think that many implementations did IC properly back then. (I have to say, however, that "back then" was before my time.) > If a remote peer rebooted and was not passive, could it intiate an IKE > negotiation with initial contact? I'm not sure what you mean by "passive," but yes, IC should help the situation. This assumes that the peer will reboot, however, or at least become reachable again. In some cases, the peer might become unreachable indefinitely. > But, if the remote peer was passive or just died without reboot, would > the local peer truly be limited to waiting till IKE SA expiry? > Yes, unless there was some manual intervention. -g > Thank you, > Jim Comen > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 17 04:56:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQn8-0001sL-Kn; Mon, 17 Oct 2005 04:56:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERQn4-0001oz-E1 for ipsec@megatron.ietf.org; Mon, 17 Oct 2005 04:56:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26614 for ; Mon, 17 Oct 2005 04:56:11 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERQyL-0006BL-Lq for ipsec@ietf.org; Mon, 17 Oct 2005 05:07:59 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j9H8toxL027032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Oct 2005 11:55:50 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9H8tn5u002773; Mon, 17 Oct 2005 11:55:49 +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: <17235.26389.849867.410831@fireball.kivinen.iki.fi> Date: Mon, 17 Oct 2005 11:55:49 +0300 From: Tero Kivinen To: "Sawkins, Steve" Subject: RE: [Ipsec] Invalid Cookie In-Reply-To: <539E161543EA78418B9FF43566B975240E8299@SVRMAIL.apani.local> References: <539E161543EA78418B9FF43566B975240E8299@SVRMAIL.apani.local> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 24 min X-Total-Time: 80 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Sawkins, Steve writes: > > Note, that there are valid cases when the cookie can be changed too, > > i.e. if you change your cookie generation secret, all previous cookies > > are invalidated, and if someone just happened to have exchange going > > with you that cookie will be changed too. > > If the cookie generation secret is changed, do we need to abort any main > mode whose cookie used that secret and negotiate a new one or can we > issue another cookie for the existing main mode? The idea of cookie is to prove that the other end can reach your packets, meaning if the other end has been able to send you valid cookie (or any other message which proves they have seen your packets) at any time, that is fine, and that IKE SA exchange can continue. This includes all valid IKE_AUTH packets, i.e there is no point of tearing down any IKE SAs processing IKE_AUTH packets or any IKE SA which are already up. If the IKE_SA_INIT packet has cookie that is not valid (i.e. cookie generated by too old secret, or IP-addresses/ports do not match or something else), then you simply request a new cookie. That is fast operation, and does not consume resources. When to change cookie generation secret is really implementation dependent, but the best is probably change it every n seconds. This will fix the case where attacker collects valid cookies over long time. This will also fix the case where attacker floods lots of exchanges to you and make you to generate new secret (in case you used number of generated cookies as a limit) thus invalidating old valid exchanges too fast. You want to keep the cookies valid for several seconds, so that even the slowest round trip times links have time to be able to use the generated cookie. If you allow previous cookie secret too, then you can use shorter time period, as changing the cookie secret does not disrupt any valid on going exchanges. In that case 2-10 seconds would be suitable time period. If you do not allow previous secret, then you should change it less frequently, but just when the new exchange starts (i.e. just when the new cookie is generated), so you can give maximum time for that exchange to finish. The old exchanges are already invalidated, so better give this one max time. I.e. when generating new cookie, check if the last secret generation time was more than n seconds ago, and if so generate new secret, and set the generation time to be current time. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 17 05:46:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERRZr-0000lz-8E; Mon, 17 Oct 2005 05:46:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERRZo-0000lp-T7 for ipsec@megatron.ietf.org; Mon, 17 Oct 2005 05:46:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00193 for ; Mon, 17 Oct 2005 05:46:33 -0400 (EDT) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERRl6-0007yc-Sj for ipsec@ietf.org; Mon, 17 Oct 2005 05:58:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Oct 2005 02:49:39 -0700 Message-ID: Thread-Topic: L2TP/ IPsec Thread-Index: AcXTABcmQ4nqM9hYRA2az3JkLLsM+A== From: "Vishwas Manral" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] L2TP/ IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, RFC3193, "Securing L2TP using IPsec" states that "Transport mode MUST be supported; tunnel mode MAY be supported". However 2401bis states that=20 "When security is desired between two intermediate systems along a path (vs. end-to-end use of IPsec), transport mode MAY be used between security gateways or between a security gateway and a host." Should we actually make changes in RFC3193 for L2TP/IPsec support to make Transport mode a MUST and Tunnel mode a MAY? Thanks, Vishwas _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 17 06:29:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERSEq-0004XO-5G; Mon, 17 Oct 2005 06:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERSEo-0004VZ-09 for ipsec@megatron.ietf.org; Mon, 17 Oct 2005 06:29:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02202 for ; Mon, 17 Oct 2005 06:28:54 -0400 (EDT) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERSQ7-0000ge-Dt for ipsec@ietf.org; Mon, 17 Oct 2005 06:40:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] L2TP/ IPsec Date: Mon, 17 Oct 2005 03:32:09 -0700 Message-ID: Thread-Topic: [Ipsec] L2TP/ IPsec Thread-Index: AcXTABcmQ4nqM9hYRA2az3JkLLsM+AABV3PA From: "Vishwas Manral" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, The last sentence in the previous mail should have read: - Should changes be made in RFC2401bis (RFC3193) for L2TP/IPsec support to make Transport mode a MUST and Tunnel mode a MAY (or the other way around)? Besides RFC2401bis states that b) A security gateway MUST support tunnel mode and MAY support transport mode. If it supports transport mode, that should be used only when the security gateway is acting as a host, e.g., for network management, or to provide security between two intermediate systems along a path. Thanks, Vishwas -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Vishwas Manral Sent: Monday, October 17, 2005 3:20 PM To: ipsec@ietf.org Subject: [Ipsec] L2TP/ IPsec Hi, RFC3193, "Securing L2TP using IPsec" states that "Transport mode MUST be supported; tunnel mode MAY be supported". However 2401bis states that=20 "When security is desired between two intermediate systems along a path (vs. end-to-end use of IPsec), transport mode MAY be used between security gateways or between a security gateway and a host." Should we actually make changes in RFC3193 for L2TP/IPsec support to make Transport mode a MUST and Tunnel mode a MAY? Thanks, Vishwas _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 17 07:28:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERTA2-0003md-AU; Mon, 17 Oct 2005 07:28:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERT9z-0003mT-Rj for ipsec@megatron.ietf.org; Mon, 17 Oct 2005 07:28:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04752 for ; Mon, 17 Oct 2005 07:27:59 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERTLI-0002B2-MB for ipsec@ietf.org; Mon, 17 Oct 2005 07:39:50 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j9HBS1Il023112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Oct 2005 14:28:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9HBS1Bc004782; Mon, 17 Oct 2005 14:28:01 +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: <17235.35521.596432.159341@fireball.kivinen.iki.fi> Date: Mon, 17 Oct 2005 14:28:01 +0300 From: Tero Kivinen To: "Vishwas Manral" Subject: [Ipsec] L2TP/ IPsec In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Vishwas Manral writes: > RFC3193, "Securing L2TP using IPsec" states that "Transport mode MUST be > supported; tunnel mode MAY be supported". If I have understood correctly L2TP usage with IPsec then from the IPsec point of view the L2TP traffic originates and terminates from the IPsec node, i.e. it is not forwarded traffic. That is the reason why transport mode is used there. In the receiving end the IPsec decapsulation is done and then the packet is forwarded to the local application, that will then do the L2TP decapsulation and then send new (in a sense of IPsec) packet forward. > However 2401bis states that > "When security is > desired between two intermediate systems along a path (vs. end-to-end > use of IPsec), transport mode MAY be used between security gateways > or between a security gateway and a host." > > Should we actually make changes in RFC3193 for L2TP/IPsec support to > make Transport mode a MUST and Tunnel mode a MAY? I think the use of transport mode in the host to host application specific use is ok, even when the application happens to be L2TP which will then send/receive packets forward. I think the key issue is that L2TP packet is not same IP packet than what is decapsulated from inside of it. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 17 08:26:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERU4H-0001HL-KD; Mon, 17 Oct 2005 08:26:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERU4F-0001H8-A7 for ipsec@megatron.ietf.org; Mon, 17 Oct 2005 08:26:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08788 for ; Mon, 17 Oct 2005 08:26:08 -0400 (EDT) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERUFY-0004CV-P2 for ipsec@ietf.org; Mon, 17 Oct 2005 08:37:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] L2TP/ IPsec Date: Mon, 17 Oct 2005 05:29:21 -0700 Message-ID: Thread-Topic: [Ipsec] L2TP/ IPsec Thread-Index: AcXTDdqqptH6t0ovTym1XI67JWw1UAAAy/3A From: "Vishwas Manral" To: "Tero Kivinen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero, Thanks a lot for the reply. I agree with your reply that the packet is as if it is terminating/ originating at the gateway.=20 Further quoting the 2401bis: - Where traffic is destined for a security gateway, e.g., SNMP commands, the security gateway is acting as a host and transport mode is allowed.=20 The above seems to mean that the condition in such a case is a MAY condition not a MUST. The MAY vs. a MUST is my main concern. I agree the L2TP/ IPsec RFC refers to 2401 and not 2401bis. Thanks again, Vishwas -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi]=20 Sent: Monday, October 17, 2005 4:58 PM To: Vishwas Manral Cc: ipsec@ietf.org Subject: [Ipsec] L2TP/ IPsec Vishwas Manral writes: > RFC3193, "Securing L2TP using IPsec" states that "Transport mode MUST be > supported; tunnel mode MAY be supported". If I have understood correctly L2TP usage with IPsec then from the IPsec point of view the L2TP traffic originates and terminates from the IPsec node, i.e. it is not forwarded traffic. That is the reason why transport mode is used there. In the receiving end the IPsec decapsulation is done and then the packet is forwarded to the local application, that will then do the L2TP decapsulation and then send new (in a sense of IPsec) packet forward.=20 > However 2401bis states that=20 > "When security is > desired between two intermediate systems along a path (vs. end-to-end > use of IPsec), transport mode MAY be used between security gateways > or between a security gateway and a host." >=20 > Should we actually make changes in RFC3193 for L2TP/IPsec support to > make Transport mode a MUST and Tunnel mode a MAY? I think the use of transport mode in the host to host application specific use is ok, even when the application happens to be L2TP which will then send/receive packets forward. I think the key issue is that L2TP packet is not same IP packet than what is decapsulated from inside of it. --=20 kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 19 05:01:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES9p1-0004gH-Cz; Wed, 19 Oct 2005 05:01:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES9oz-0004g5-DI for ipsec@megatron.ietf.org; Wed, 19 Oct 2005 05:01:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00846 for ; Wed, 19 Oct 2005 05:01:09 -0400 (EDT) Received: from mailalarm.checkpoint.com ([194.29.32.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESA0d-0004DR-U8 for ipsec@ietf.org; Wed, 19 Oct 2005 05:13:23 -0400 Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by mailalarm.checkpoint.com (8.12.11/8.12.11) with ESMTP id j9J9Sbuc026313; Wed, 19 Oct 2005 11:28:37 +0200 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j9J913tD012234; Wed, 19 Oct 2005 11:01:04 +0200 (IST) Mime-Version: 1.0 (Apple Message framework v623) Content-Transfer-Encoding: 7bit Message-Id: <869701c0a01425a977a30e048c26cac6@checkpoint.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "'IPsec WG'" , "" From: Yoav Nir Date: Wed, 19 Oct 2005 11:01:04 +0200 X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Subject: [Ipsec] Questions about draft-eronen-ipsec-ikev2-multiple-auth-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi. I have several questions about this draft. 1. Having multiple authentication exchanges means you have several AUTH payloads. Are all of them signing or hashing the same string (message||nonce||ID)? 2. Suppose you use multiple EAP methods that do not generate keys. Are all the AUTH payloads signed with SK_pi and SK_pr? If the answer to both questions is yes, then the AUTH payload will be identical between exchanges. 3. If we're going to allow multiple authentication exchanges, why not also allow them to be separated by time (without the "ANOTHER_AUTH_FOLLOWS" notification) and then we will be able to do repeated authentication without tearing down all existing tunnels? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 19 10:04:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESEYt-0002TD-Qd; Wed, 19 Oct 2005 10:04:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESEYs-0002SF-47 for ipsec@megatron.ietf.org; Wed, 19 Oct 2005 10:04:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19268 for ; Wed, 19 Oct 2005 10:04:49 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESEkb-0004dS-7W for ipsec@ietf.org; Wed, 19 Oct 2005 10:17:06 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j9JE4XkO021585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Oct 2005 17:04:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9JE4U4t001616; Wed, 19 Oct 2005 17:04:30 +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: <17238.21102.935156.947460@fireball.kivinen.iki.fi> Date: Wed, 19 Oct 2005 17:04:30 +0300 From: Tero Kivinen To: Yoav Nir Subject: [Ipsec] Questions about draft-eronen-ipsec-ikev2-multiple-auth-00 In-Reply-To: <869701c0a01425a977a30e048c26cac6@checkpoint.com> References: <869701c0a01425a977a30e048c26cac6@checkpoint.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 13 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: 'IPsec WG' , "" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yoav Nir writes: > 1. Having multiple authentication exchanges means you have several AUTH > payloads. Are all of them signing or hashing the same string > (message||nonce||ID)? I would guess so, as the draft does not say anything about that. > 2. Suppose you use multiple EAP methods that do not generate keys. Are > all the AUTH payloads signed with SK_pi and SK_pr? If the answer to > both questions is yes, then the AUTH payload will be identical between > exchanges. Yes. Perhaps there should be something to differentiate them? > 3. If we're going to allow multiple authentication exchanges, why not > also allow them to be separated by time (without the > "ANOTHER_AUTH_FOLLOWS" notification) and then we will be able to do > repeated authentication without tearing down all existing tunnels? If I understood correctly what you asked, that would require completely new exchange to be defined. Actually I am not sure if even this draft should be using the normal exchange type, or whether it should have different exchange type number also. Anyways I also think that whole N(MULTIPLE_AUTH_SUPPORTED) notifies are compeltely useless, and should be removed. There is no need for them as all the new things happen in the notification payloads. There is no need to negotiate this feature. It would be completely different matter if the other end could somehow tell what authentication methods it wants the other end to use, but as it cannot with this protocol, then there is no need to negotiate support for this. So only thing that is needed is the N(ANOTHER_AUTH_FOLLOWS). If the other end does not support it, then it will simply finish the exchange without waiting for another auth, and as those ANOTHER_AUTH_FOLLOWS only gives extra authentications to the other end it does not really matter. I.e even if the client things that multiple authentications are needed, but if the server is happy after the first one, there is no reason for the client to tear the IKE SA down because of that. I am still not sure if this whole support is needed, those two AAA servers still needs to have some kind of trust relation ship, i.e. the NAPT AAA / NAP's Tunnel Endpoint needs to trust that 3rd Party AAA and 3rd Party Tunnel Endpoint do the second authentication correctly, and that they give valid values for to be used in the trafficl selectors etc (if I understood the scenario correctly). The 3rd party could simply also send the information needed for billing to the NAP too. This just again adds quite a lot of complexity to the protocol and HUGE amount of different options that needs to be tested. Currently you need to test 6 different authentication methods (psk-psk, cert-cert, psk-cert, cert-psk, eap-psk, epa-cert), and after this you need to test lot of different combinations to make sure everything works. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 25 09:21:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUOk6-0006Rw-4D; Tue, 25 Oct 2005 09:21:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUOk4-0006Ro-HI for ipsec@megatron.ietf.org; Tue, 25 Oct 2005 09:21:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16302 for ; Tue, 25 Oct 2005 09:21:13 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUOx0-0002OI-OC for ipsec@ietf.org; Tue, 25 Oct 2005 09:34:52 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9PDLJuH002492 for ; Tue, 25 Oct 2005 06:21:20 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 25 Oct 2005 06:21:16 -0700 To: IPsec WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Subject: [Ipsec] Easy issues from the IKEv2 clarifications document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Greetings again. The next rev of the IKEv2 clarifications document is making its way through the I-D pile and should be posted here soon. In the meantime, Pasi and I would like to knock off some of the open issues that are less contentious. The following three sections all relate to configuration payloads. Please let us know if you have any objection to the current wording. Thanks! 6.5. INTERNAL_IP4_NETMASK Section 3.15.1 defines the INTERNAL_IP4_NETMASK attribute, and says that "The internal network's netmask. Only one netmask is allowed in the request and reply messages (e.g., 255.255.255.0) and it MUST be used only with an INTERNAL_IP4_ADDRESS attribute". However, it is not clear what exactly this attribute means, as the concept of "netmask" is not very well defined for point-to-point links (unlike multi-access links, where it means "you can reach hosts inside this netmask directly using layer 2, instead of sending packets via a router"). Even if the operating system's TCP/IP stack requires a netmask to be configured, for point-to-point links it could be just set to 255.255.255.255. So, why is this information sent in IKEv2? One possible interpretation would be that the host is given a whole block of IP addresses instead of a single address. This is also what Framed-IP-Netmask does in [RADIUS], the IPCP "subnet mask" extension does in PPP [IPCPSubnet], and the prefix length in the IPv6 Framed- IPv6-Prefix attribute does in [RADIUS6]. However, nothing in the specification supports this interpretation, and discussions on the IPsec WG mailing list have confirmed it was not intended. Section 3.15.1 also says that multiple addresses are assigned using multiple INTERNAL_IP4/6_ADDRESS attributes. Currently, this document's interpretation is the following: INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET containing the same information ("send traffic to these addresses through me"), but also implies a link boundary. For instance, the client could use its own address and the netmask to calculate the broadcast address of the link. (Whether the gateway will actually deliver broadcast packets to other VPN clients and/or other nodes connected to this link is another matter.) An empty INTERNAL_IP4_NETMASK attribute can be included in a CFG_REQUEST to request this information (although the gateway can send the information even when not requested). However, it seems that non-empty values for this attribute do not make sense in CFG_REQUESTs. Fortunately, Section 4 clearly says that a minimal implementation does not need to include or understand the INTERNAL_IP4_NETMASK attribute, and thus this document recommends that implementations should not use the INTERNAL_IP4_NETMASK attribute or assume that the other peer supports it. (References: Charlie Kaufman's mail "RE: Proposed Last Call based revisions to IKEv2", 2004-05-27. Email discussion with Tero Kivinen, Jan 2005. Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and Implementation Guidelines", 2005-02-07. "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.) 6.6. Configuration payloads for IPv6 IKEv2 also defines configuration payloads for IPv6. However, they are based on the corresponding IPv4 payloads, and do not fully follow the "normal IPv6 way of doing things". A client can be assigned an IPv6 address using the INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange could look like this: CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) CP(CFG_REPLY) = INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) In particular, IPv6 stateless autoconfiguration or router advertisement messages are not used; neither is neighbor discovery. The client can also send a non-empty INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST to request a specific address or interface identifier. The gateway first checks if the specified address is acceptable, and if it is, returns that one. If the address was not acceptable, the gateway will attempt to use the interface identifier with some other prefix; if even that fails, the gateway will select another interface identifier. The INTERNAL_IP6_ADDRESS attribute also contains a prefix length field. When used in a CFG_REPLY, this corresponds to the INTERNAL_IP4_NETMASK attribute in the IPv4 case (and indeed, was called INTERNAL_IP6_NETMASK in earlier versions of the IKEv2 draft). See the previous section for more details. While this approach to configuring IPv6 addresses is reasonably simple, it has some limitations: IPsec tunnels configured using IKEv2 are not fully-featured "interfaces" in the IPv6 addressing architecture [IPv6Addr] sense. In particular, they do not necessarily have link-local addresses, and this may complicate the use of protocols that assume them, such as [MLDv2]. (Whether they are called "interfaces" in some particular operating system is a different issue.) (References: "VPN remote host configuration IPv6 ?" thread, May 2004. "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.) 6.9. Address assignment failures If the responder encounters an error while attempting to assign an IP address to the initiator, it responds with an INTERNAL_ADDRESS_FAILURE notification as described in Section 3.10.1. However, there are some more complex error cases. First, if the responder does not support configuration payloads at all, it can simply ignore all configuration payloads. This type of implementation never sends INTERNAL_ADDRESS_FAILURE notifications. If the initiator requires the assignment of an IP address, it will treat a response without CFG_REPLY as an error. A second case is where the responder does support configuration payloads, but only for particular type of addresses (IPv4 or IPv6). Section 4 says that "A minimal IPv4 responder implementation will ignore the contents of the CP payload except to determine that it includes an INTERNAL_IP4_ADDRESS attribute". If, for instance, the initiator includes both INTERNAL_IP4_ADDRESS and INTERNAL_IP6_ADDRESS in the CFG_REQUEST, an IPv4-only responder can thus simply ignore the IPv6 part and process the IPv4 request as usual. A third case is where the initiator requests multiple addresses of a type that the responder supports: what should happen if some (but not all) of the requests fail? It seems that an optimistic approach would be the best one here: if the responder is able to assign at least one address, it replies with those; it sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. (References: "ikev2 and internal_ivpn_address" thread, June 2005.) --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 25 09:41:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUP3F-0004VE-2J; Tue, 25 Oct 2005 09:41:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUP3D-0004SH-0g for ipsec@megatron.ietf.org; Tue, 25 Oct 2005 09:41:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17491 for ; Tue, 25 Oct 2005 09:41:00 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUPGA-0002xD-IY for ipsec@ietf.org; Tue, 25 Oct 2005 09:54:39 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j9PDf1IV018616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Oct 2005 16:41:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9PDf0GM027498; Tue, 25 Oct 2005 16:41:00 +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: <17246.13804.696588.436589@fireball.kivinen.iki.fi> Date: Tue, 25 Oct 2005 16:41:00 +0300 From: Tero Kivinen To: Paul Hoffman Subject: [Ipsec] Easy issues from the IKEv2 clarifications document In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 10 min X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: IPsec WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Paul Hoffman writes: > 6.6. Configuration payloads for IPv6 > > IKEv2 also defines configuration payloads for IPv6. However, they > are based on the corresponding IPv4 payloads, and do not fully follow > the "normal IPv6 way of doing things". > > A client can be assigned an IPv6 address using the > INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange could > look like this: > > CP(CFG_REQUEST) = > INTERNAL_IP6_ADDRESS() > INTERNAL_IP6_DNS() > TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > > CP(CFG_REPLY) = > INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) > INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) > TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) > TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > > In particular, IPv6 stateless autoconfiguration or router > advertisement messages are not used; neither is neighbor discovery. > > The client can also send a non-empty INTERNAL_IP6_ADDRESS attribute > in the CFG_REQUEST to request a specific address or interface > identifier. The gateway first checks if the specified address is > acceptable, and if it is, returns that one. If the address was not > acceptable, the gateway will attempt to use the interface identifier > with some other prefix; if even that fails, the gateway will select > another interface identifier. It would be good to have this default format as a first example, i.e: CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS(::20f:1fff:fe12:4749) INTERNAL_IP6_DNS() TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) CP(CFG_REPLY) = INTERNAL_IP6_ADDRESS(2001:DB8::20f:1fff:fe12:4749/64) INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) TSi = (0, 0-65535, 2001:DB8::20f:1fff:fe12:4749 - 2001:DB8::20f:1fff:fe12:4749) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) I.e. the client sends the 64 lower bits of the address, and the server will fill the prefix. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 25 09:54:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPFg-0001JE-M5; Tue, 25 Oct 2005 09:54:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPFf-0001J8-Hk for ipsec@megatron.ietf.org; Tue, 25 Oct 2005 09:54:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18532 for ; Tue, 25 Oct 2005 09:53:52 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUPSc-0003P3-Gn for ipsec@ietf.org; Tue, 25 Oct 2005 10:07:31 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9PDoKdr006838; Tue, 25 Oct 2005 16:50:26 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 16:54:00 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 16:54:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Easy issues from the IKEv2 clarifications document Date: Tue, 25 Oct 2005 16:54:07 +0300 Message-ID: Thread-Topic: [Ipsec] Easy issues from the IKEv2 clarifications document Thread-Index: AcXZako52wRU0g9nS8eQ05vwKH/hGQAALadQ To: X-OriginalArrivalTime: 25 Oct 2005 13:54:00.0649 (UTC) FILETIME=[8D5F5390:01C5D96B] X-Spam-Score: 0.5 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > It would be good to have this default format as a first example,=20 > i.e: >=20 > CP(CFG_REQUEST) =3D > INTERNAL_IP6_ADDRESS(::20f:1fff:fe12:4749) > INTERNAL_IP6_DNS() > TSi =3D (0, 0-65535,=20 > :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > TSr =3D (0, 0-65535, > :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) >=20 > CP(CFG_REPLY) =3D > INTERNAL_IP6_ADDRESS(2001:DB8::20f:1fff:fe12:4749/64) > INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) > TSi =3D (0, 0-65535, 2001:DB8::20f:1fff:fe12:4749 - > 2001:DB8::20f:1fff:fe12:4749) > TSr =3D (0, 0-65535, :: -=20 > FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) >=20 > I.e. the client sends the 64 lower bits of the address, and the=20 > server will fill the prefix.=20 Do you expect that implementations will actually use this feature? My guess would be that clients don't really care what interface identifier they get, and will be happy to let the gateway choose... (Except when they're also requesting also a particular prefix;=20 i.e., the same address they had previously.) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 25 10:17:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPcK-0001Cv-8f; Tue, 25 Oct 2005 10:17:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUPcJ-0001Cq-02 for ipsec@megatron.ietf.org; Tue, 25 Oct 2005 10:17:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19733 for ; Tue, 25 Oct 2005 10:17:16 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUPpH-00041J-3K for ipsec@ietf.org; Tue, 25 Oct 2005 10:30:55 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j9PEHSaf026874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Oct 2005 17:17:28 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9PEHRMr002089; Tue, 25 Oct 2005 17:17:27 +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: <17246.15991.873667.409666@fireball.kivinen.iki.fi> Date: Tue, 25 Oct 2005 17:17:27 +0300 From: Tero Kivinen To: Subject: RE: [Ipsec] Easy issues from the IKEv2 clarifications document In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > Tero Kivinen wrote: > > It would be good to have this default format as a first example, > > i.e: > > > > CP(CFG_REQUEST) = > > INTERNAL_IP6_ADDRESS(::20f:1fff:fe12:4749) > > INTERNAL_IP6_DNS() > > TSi = (0, 0-65535, > > :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > > TSr = (0, 0-65535, > > :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > > > > CP(CFG_REPLY) = > > INTERNAL_IP6_ADDRESS(2001:DB8::20f:1fff:fe12:4749/64) > > INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) > > TSi = (0, 0-65535, 2001:DB8::20f:1fff:fe12:4749 - > > 2001:DB8::20f:1fff:fe12:4749) > > TSr = (0, 0-65535, :: - > > FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > > > > I.e. the client sends the 64 lower bits of the address, and the > > server will fill the prefix. > > Do you expect that implementations will actually use this feature? > My guess would be that clients don't really care what interface > identifier they get, and will be happy to let the gateway choose... The IPv6 people said we must have this feature, and I assume they do expect it to be used. This is the way IPv6 networks are normally configured, so it would be logical to use this method here too. Note, that this will automatically give you same IPv6-address when connecting to same VPN having only one IPv6 prefix. And it does that without any need to remember the address used previously by the client, or mapping identities to the same ip-address in the server. If some implementation does not support this feature, I would consider that bad IPv6 implementation of IKEv2. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 25 12:21:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EURY0-0004Uz-LQ; Tue, 25 Oct 2005 12:21:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EURXz-0004Tl-8B for ipsec@megatron.ietf.org; Tue, 25 Oct 2005 12:21:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02722 for ; Tue, 25 Oct 2005 12:20:55 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EURkx-0001E9-Ar for ipsec@ietf.org; Tue, 25 Oct 2005 12:34:36 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9PGIpiH011084; Tue, 25 Oct 2005 19:18:52 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 19:21:07 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 19:21:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Easy issues from the IKEv2 clarifications document Date: Tue, 25 Oct 2005 19:21:06 +0300 Message-ID: Thread-Topic: [Ipsec] Easy issues from the IKEv2 clarifications document Thread-Index: AcXZbv9/0oCL7aUzQ26VFTM6fEIPWgADvPUw To: X-OriginalArrivalTime: 25 Oct 2005 16:21:07.0563 (UTC) FILETIME=[1A9F83B0:01C5D980] X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > The IPv6 people said we must have this feature, and I assume they do > expect it to be used. This is the way IPv6 networks are normally > configured, so it would be logical to use this method here too. This is the way IPv6 stateless configuration works, but IKEv2 configuration payloads involve state at the responder, and=20 are IMHO closer to DHCPv6 (which doesn't have this functionality). > Note, that this will automatically give you same IPv6-address when > connecting to same VPN having only one IPv6 prefix. And it does that > without any need to remember the address used previously by the > client, or mapping identities to the same ip-address in the server.=20 Some kind of state must be kept while the IKE_SA is alive, of course. And it may be desirable to maintain state slightly longer than that... The same address shouldn't be given to some other client too soon after it has been released; otherwise there can be "interesting" interactions with flow-related state in the network. > If some implementation does not support this feature, I would=20 > consider that bad IPv6 implementation of IKEv2.=20 Well, it looks like not supporting this would simplify implementations=20 without removing any useful functionality, so IMHO that sounds good, not bad... Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 25 13:04:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSDU-0005FD-Jp; Tue, 25 Oct 2005 13:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUSDS-0005Ew-Gu for ipsec@megatron.ietf.org; Tue, 25 Oct 2005 13:04:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05707 for ; Tue, 25 Oct 2005 13:03:48 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUSQR-0002eP-4w for ipsec@ietf.org; Tue, 25 Oct 2005 13:17:28 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j9PH3ei10961; Tue, 25 Oct 2005 19:03:40 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9PH3fja007742; Tue, 25 Oct 2005 19:03:41 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510251703.j9PH3fja007742@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Ipsec] Easy issues from the IKEv2 clarifications document In-reply-to: Your message of Tue, 25 Oct 2005 16:54:07 +0300. Date: Tue, 25 Oct 2005 19:03:41 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipsec@ietf.org, kivinen@iki.fi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: > I.e. the client sends the 64 lower bits of the address, and the > server will fill the prefix. Do you expect that implementations will actually use this feature? My guess would be that clients don't really care what interface identifier they get, and will be happy to let the gateway choose... (Except when they're also requesting also a particular prefix; i.e., the same address they had previously.) => in fact for privacy reasons some should exactly get any address but never the same one. As systems assigning addresses can try to provide stable addresses, mainly because it is the right thing when there is no privacy considerations, IMHO this feature will be used so should be documented in the example. Regards Francis.Dupont@enst-bretagne.fr PS: cf RFC 3041 for privacy and interface IDs. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 25 14:31:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTa3-00008o-Sy; Tue, 25 Oct 2005 14:31:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTa1-000077-AI for ipsec@megatron.ietf.org; Tue, 25 Oct 2005 14:31:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11100 for ; Tue, 25 Oct 2005 14:31:11 -0400 (EDT) Received: from coliposte.enst-bretagne.fr ([192.108.115.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUTn0-0005Ot-QH for ipsec@ietf.org; Tue, 25 Oct 2005 14:44:52 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.10.03) with ESMTP id j9PIVAhR028462; Tue, 25 Oct 2005 20:31:10 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.09.01) with ESMTP id j9PIU7ls028284; Tue, 25 Oct 2005 20:30:07 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9PITe8A008350; Tue, 25 Oct 2005 20:29:41 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510251829.j9PITe8A008350@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Ipsec] Easy issues from the IKEv2 clarifications document In-reply-to: Your message of Tue, 25 Oct 2005 19:21:06 +0300. Date: Tue, 25 Oct 2005 20:29:40 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ipsec@ietf.org, kivinen@iki.fi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: > The IPv6 people said we must have this feature, and I assume they do > expect it to be used. This is the way IPv6 networks are normally > configured, so it would be logical to use this method here too. This is the way IPv6 stateless configuration works, but IKEv2 configuration payloads involve state at the responder, and are IMHO closer to DHCPv6 (which doesn't have this functionality). => but DHCPv6 has IA_TA (the functionality is the RFC 3041 one). And it may be desirable to maintain state slightly longer than that... The same address shouldn't be given to some other client too soon after it has been released; otherwise there can be "interesting" interactions with flow-related state in the network. => hold down? > If some implementation does not support this feature, I would > consider that bad IPv6 implementation of IKEv2. Well, it looks like not supporting this would simplify implementations without removing any useful functionality, so IMHO that sounds good, not bad... => I have to recall that the privacy protection is a strong requirement in Europe. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 25 15:11:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUCs-0000EC-DM; Tue, 25 Oct 2005 15:11:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUUCq-0000E7-HX for ipsec@megatron.ietf.org; Tue, 25 Oct 2005 15:11:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13290 for ; Tue, 25 Oct 2005 15:11:18 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUUPq-0006Yi-5m for ipsec@ietf.org; Tue, 25 Oct 2005 15:24:59 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j9PIcAV31206; Tue, 25 Oct 2005 11:38:10 -0700 X-mProtect: <200510251838> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14184.americas.nokia.com (172.18.141.84, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdeNhgzA; Tue, 25 Oct 2005 11:38:08 PDT Message-ID: <435E8341.4010601@iprg.nokia.com> Date: Tue, 25 Oct 2005 12:10:57 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Ipsec] Easy issues from the IKEv2 clarifications document References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, kivinen@iki.fi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org section 5.3.2 of http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-01.txt might be relevant here. we discussed this quite a bit in the MIP6 WG and the conclusion was whats written in section 5.3.2. we decided to introduce a new attribute MIP6_HOME_PREFIX to first obtain the home prefix length and then auto-configure a home address. Vijay Pasi.Eronen@nokia.com wrote: > Tero Kivinen wrote: > >>It would be good to have this default format as a first example, >>i.e: >> >> CP(CFG_REQUEST) = >> INTERNAL_IP6_ADDRESS(::20f:1fff:fe12:4749) >> INTERNAL_IP6_DNS() >> TSi = (0, 0-65535, >> :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) >> TSr = (0, 0-65535, >> :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) >> >> CP(CFG_REPLY) = >> INTERNAL_IP6_ADDRESS(2001:DB8::20f:1fff:fe12:4749/64) >> INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) >> TSi = (0, 0-65535, 2001:DB8::20f:1fff:fe12:4749 - >> 2001:DB8::20f:1fff:fe12:4749) >> TSr = (0, 0-65535, :: - >> FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) >> >>I.e. the client sends the 64 lower bits of the address, and the >>server will fill the prefix. > > > Do you expect that implementations will actually use this feature? > My guess would be that clients don't really care what interface > identifier they get, and will be happy to let the gateway choose... > > (Except when they're also requesting also a particular prefix; > i.e., the same address they had previously.) > > Best regards, > Pasi > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 25 18:20:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUX9h-0006CV-QQ; Tue, 25 Oct 2005 18:20:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUX9f-00067Y-55 for ipsec@megatron.ietf.org; Tue, 25 Oct 2005 18:20:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18951 for ; Tue, 25 Oct 2005 18:20:11 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUXMg-0004J1-5W for ipsec@ietf.org; Tue, 25 Oct 2005 18:33:55 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j9PMJjA01885 for ; Wed, 26 Oct 2005 00:19:45 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9PMJj1f009967 for ; Wed, 26 Oct 2005 00:19:46 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510252219.j9PMJj1f009967@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@ietf.org Date: Wed, 26 Oct 2005 00:19:45 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ipsec] MIPv6 bootstrapping and IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org IKEv2 is assumed to become the default mechanism in MIPv6 bootstrapping, both because the MIPv6 security between a mobile node and its home agent (HA) is based on IPsec and because IKEv2 is efficient, provides configuration, support legacy authentication, etc. Look at draft-ietf-mip6-ikev2-ipsec-04.txt ... But something IKEv2 doesn't (yet!) know to do is the assignment of the HA address, mainly because when you are talking with the HA you already have its address... MIPv6 has some HA address discovery mechanisms (a problem very similar to the SG discovery) and is looking for HA (address) assignment mechanisms. HAs on the same link share an IPv6 anycast address (a group address like multicast but messages are delivered to one member of the group and the format is the same than for unicast. IPv6 anycasts share some properties with multicasts: they must not use as source addresses and a stream of messages is not required to be delivered to the same node). A proposal is the initiator (aka mobile node aka VPN client) sends the first message (IKE_SA_INIT) to the anycast address, the receiving HA forwards it to the "best" HA which answers using its own unicast address. The initiator keeps this address as the responder address for further messages. IMHO we should enforce Cookie mechanism in this case: - we always get a full IKE_SA_INIT exchange using the right addresses - we can't mess NAT detection or other things relying on addresses - an anycast address is a good target for attacks so to always consider it is under attack is just pessimism Is there a problem I couldn't see? Is it a good/bad/don't-care idea? (BTW it is not mine) Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 25 19:18:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUY3P-0006DR-QE; Tue, 25 Oct 2005 19:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUY3O-0006C6-3A for ipsec@megatron.ietf.org; Tue, 25 Oct 2005 19:18:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01534 for ; Tue, 25 Oct 2005 19:17:45 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUYGO-0000rH-G5 for ipsec@ietf.org; Tue, 25 Oct 2005 19:31:29 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j9PNHmYq031146; Wed, 26 Oct 2005 01:17:48 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j9PNHmOx031830; Wed, 26 Oct 2005 01:17:48 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 26 Oct 2005 01:17:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ipsec] MIPv6 bootstrapping and IKEv2 Date: Wed, 26 Oct 2005 01:17:48 +0200 Message-ID: Thread-Topic: [Ipsec] MIPv6 bootstrapping and IKEv2 Thread-Index: AcXZsxorx26fafz9SCOF09E6YY6ksgAAHoow From: "Tschofenig, Hannes" To: "Francis Dupont" , X-OriginalArrivalTime: 25 Oct 2005 23:17:48.0631 (UTC) FILETIME=[506BBE70:01C5D9BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org hi francis,=20 this idea sounds similar to ted: Fluhrer, S., "Tunnel Endpoint Discovery", draft-fluhrer-ted-00 = (expired), November 2001.=20 it is true that the bootstrapping solution for the split scenario does = not address the problem of finding the home agent. but, why is this even = necessary given the number of options you typically have? here is a = short list from a old version of the = :=20 9. Tunnel Endpoint Discovery The IKEv2 initiator needs to know the address of the IKEv2 responder for IKEv2 signaling. A number of ways can be used to provide the initiator with this information, for example: o Using off-band mechanisms, e.g., from the ISP's web page. o Using DNS to look up a service name by appending it to the DNS search path provided by DHCPv4 (e.g. "tunnel-service.example.com"). o Using a DHCP option. o Using a pre-configured or pre-determined IPv4 anycast address. o Using other, unspecified or proprietary methods such as TED (see [I-D.fluhrer-ted]). For the purpose of this document it is assumed that this address can be obtained somehow. Once the address has been learned, it is configured as the tunnel end-point for the configured IPv6-over-IPv4 tunnel. ... and i should add the recent proposal for the integrated scenario = using dhcp.=20 =20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > Im Auftrag von Francis Dupont > Gesendet: Mittwoch, 26. Oktober 2005 00:20 > An: ipsec@ietf.org > Betreff: [Ipsec] MIPv6 bootstrapping and IKEv2 >=20 >=20 > IKEv2 is assumed to become the default mechanism in MIPv6=20 > bootstrapping, > both because the MIPv6 security between a mobile node and its=20 > home agent > (HA) is based on IPsec and because IKEv2 is efficient, provides > configuration, support legacy authentication, etc. > Look at draft-ietf-mip6-ikev2-ipsec-04.txt ... >=20 > But something IKEv2 doesn't (yet!) know to do is the assignment of > the HA address, mainly because when you are talking with the HA > you already have its address... MIPv6 has some HA address discovery > mechanisms (a problem very similar to the SG discovery) and is looking > for HA (address) assignment mechanisms. >=20 > HAs on the same link share an IPv6 anycast address (a group address > like multicast but messages are delivered to one member of the group > and the format is the same than for unicast. IPv6 anycasts share some > properties with multicasts: they must not use as source addresses and > a stream of messages is not required to be delivered to the=20 > same node). >=20 > A proposal is the initiator (aka mobile node aka VPN client) sends > the first message (IKE_SA_INIT) to the anycast address, the receiving > HA forwards it to the "best" HA which answers using its own unicast > address. The initiator keeps this address as the responder address > for further messages. >=20 > IMHO we should enforce Cookie mechanism in this case: > - we always get a full IKE_SA_INIT exchange using the right addresses > - we can't mess NAT detection or other things relying on addresses > - an anycast address is a good target for attacks so to always > consider it is under attack is just pessimism >=20 > Is there a problem I couldn't see? Is it a good/bad/don't-care idea? > (BTW it is not mine) >=20 > Regards >=20 > Francis.Dupont@enst-bretagne.fr >=20 > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 26 04:13:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUgPE-0007KR-Fo; Wed, 26 Oct 2005 04:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUgP9-0007F3-6o for ipsec@megatron.ietf.org; Wed, 26 Oct 2005 04:13:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02669 for ; Wed, 26 Oct 2005 04:12:47 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUgcF-0000P3-KK for ipsec@ietf.org; Wed, 26 Oct 2005 04:26:37 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j9Q8C8A08888; Wed, 26 Oct 2005 10:12:08 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9Q8C8XY011727; Wed, 26 Oct 2005 10:12:08 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510260812.j9Q8C8XY011727@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Tschofenig, Hannes" Subject: Re: AW: [Ipsec] MIPv6 bootstrapping and IKEv2 In-reply-to: Your message of Wed, 26 Oct 2005 01:17:48 +0200. Date: Wed, 26 Oct 2005 10:12:08 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: this idea sounds similar to ted: => note that discovery is not assignment. MIPv6 has already two discovery mechanisms (ICMP anycast-based, DNS SRV RR). ... and i should add the recent proposal for the integrated scenario using dhcp => this proposal covers only a particular case. A HA assignment for IKEv2 should cover all the cases using IKEv2. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 26 06:14:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiIK-0004pf-JK; Wed, 26 Oct 2005 06:14:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUiII-0004pX-DW for ipsec@megatron.ietf.org; Wed, 26 Oct 2005 06:14:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09085 for ; Wed, 26 Oct 2005 06:13:50 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUiVR-000465-1I for ipsec@ietf.org; Wed, 26 Oct 2005 06:27:41 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j9QAE0wr026007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Oct 2005 13:14:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9QAE0rE018712; Wed, 26 Oct 2005 13:14:00 +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: <17247.22248.40150.67597@fireball.kivinen.iki.fi> Date: Wed, 26 Oct 2005 13:14:00 +0300 From: Tero Kivinen To: Subject: RE: [Ipsec] Easy issues from the IKEv2 clarifications document In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > Tero Kivinen wrote: > > > The IPv6 people said we must have this feature, and I assume they do > > expect it to be used. This is the way IPv6 networks are normally > > configured, so it would be logical to use this method here too. > > This is the way IPv6 stateless configuration works, but IKEv2 > configuration payloads involve state at the responder, and > are IMHO closer to DHCPv6 (which doesn't have this functionality). That feature were added because of the IPv6 people considered it bad to be like DHCPv6, and wanted it be closer to the stateless configuration. > > Note, that this will automatically give you same IPv6-address when > > connecting to same VPN having only one IPv6 prefix. And it does that > > without any need to remember the address used previously by the > > client, or mapping identities to the same ip-address in the server. > > Some kind of state must be kept while the IKE_SA is alive, of course. I mean over longer timeperiod, I mean when you disconnect, and come back 2 weeks later, you will still always get same IP-address. > And it may be desirable to maintain state slightly longer than that... > The same address shouldn't be given to some other client too soon > after it has been released; otherwise there can be "interesting" > interactions with flow-related state in the network. There is no point of ever giving the same IP-address to someone else than to the same client in the IPv6 case. > > If some implementation does not support this feature, I would > > consider that bad IPv6 implementation of IKEv2. > > Well, it looks like not supporting this would simplify implementations > without removing any useful functionality, so IMHO that sounds > good, not bad... It does provide useful functionality. I do consider the stability of the IP-address (even if the address is dynamic). That feature is in the IKEv2 already, and it is supposed to be used as I described it. I just think that as the clarification document adds more examples, it should be using the example of the desired operation of the protocol first. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 26 13:03:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUogX-0005Af-HU; Wed, 26 Oct 2005 13:03:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUogV-00059T-GA for ipsec@megatron.ietf.org; Wed, 26 Oct 2005 13:03:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07567 for ; Wed, 26 Oct 2005 13:03:15 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUotg-0001to-Nw for ipsec@ietf.org; Wed, 26 Oct 2005 13:17:10 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QH3NP8075691 for ; Wed, 26 Oct 2005 10:03:24 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 26 Oct 2005 10:03:22 -0700 To: IPsec WG From: The IESG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [Ipsec] Last Call: 'The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)' as a Proposed Standard On 1 July 2005 the IESG received a request to consider publication of draft-hoffman-rfc3664bis-03 as a standards-track RFC. Updates were made based on IETF Last Call comments, the -04 version of the document was discussed during the telechat of 1 September 2005. The document was approved, and placed in the the RFC Editor queue. On 29 September 2005, Paul Hoffman asked the IESG to rescind approval of the document due to an implementation issue that was discovered at the IKEv2 bake-off. The attached note describes this situation more completely. Now, version -05 has addressed this concern, and the IESG has been asked to consider publication of the updated document as a standards-track RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-11-23. The file can be obtained via http://www.ietf.org/internet-drafts/draft-hoffman-rfc3664bis-05.txt --- Message Rescinding Approval of draft-hoffman-rfc3664bis-04 --- To: IETF Announcement list From: IESG Date: Wed, 12 Oct 2005 11:22:01 -0400 Cc: iana@iana.org, rfc-editor@rfc-editor.org Subject: Rescinding Approval of draft-hoffman-rfc3664bis-04 On 1 July 2005 the IESG received a request from Paul Hoffman to consider publication of draft-hoffman-rfc3664bis-03 as a standards-track RFC. Updates were made based on IETF Last Call comments, the -04 version of the document was discussed during the telechat of 1 September 2005. The document was approved, and it is now in the RFC Editor queue. On 29 September 2005, Paul Hoffman asked the IESG to rescind approval of the document due to an implementation issue that was discovered at the IKEv2 bake-off. A summary of the problem is: In IKEv2 section 2.14 on generating keying material, it says: "If the negotiated prf takes a fixed length key and the lengths of Ni and Nr do not add up to that length, half the bits must come from Ni and half from Nr, taking the first bits of each." In section 2.15 on authentication, it says: "If the negotiated prf takes a fixed size key, the shared secret MUST be of that fixed size." In draft-hoffman-rfc3664bis-04 section 1.1 says: "This document specifies the same algorithm as RFC 3664 except that the restriction on keys having to be exactly 128 bits from [AES-XCBC-MAC] is removed. Implementations of RFC 3664 will have the same bits-on-the-wire results as this algorithm; the only difference is that keys that were not equal in length to 128 bits will no longer be rejected, but instead will be made 128 bits. The problem is that changing from fixed-key-size to variable-key-size changes the bits output from generating keying material. Because the nonces must each be at least 128 bits (from IKEv2 section 2.10), the lengths will never add up to the key length unless the key is 256 or longer. A new version of draft-hoffman-rfc3664bis has been posted that attempts to solve the problem. This new version will be the subject of a separate IETF Last Call and IESG action. Accordingly, the IESG agreed to rescind approval to publish draft-hoffman-rfc3664bis-04 as a standards-track RFC. This decision requires that the following action by the RFC Editor: Please remove draft-hoffman-rfc3664bis-04.txt from the RFC Editor queue and discontinue processing of the document. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 26 20:50:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUvyD-0005qG-MO; Wed, 26 Oct 2005 20:50:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUvyB-0005n8-AD for ipsec@megatron.ietf.org; Wed, 26 Oct 2005 20:50:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10447 for ; Wed, 26 Oct 2005 20:50:00 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUwBR-0000TZ-I6 for ipsec@ietf.org; Wed, 26 Oct 2005 21:03:57 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9R0o6rp037633 for ; Wed, 26 Oct 2005 17:50:08 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 26 Oct 2005 17:50:02 -0700 To: IPsec WG From: Internet-Drafts@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.3 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Ipsec] I-D ACTION:draft-eronen-ipsec-ikev2-clarifications-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IKEv2 Clarifications and Implementation Guidelines Author(s) : P. Hoffman, P. Eronen Filename : draft-eronen-ipsec-ikev2-clarifications-06.txt Pages : 52 Date : 2005-10-26 This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-clarifications-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-eronen-ipsec-ikev2-clarifications-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-eronen-ipsec-ikev2-clarifications-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 27 04:16:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV2vo-0003Ye-LQ; Thu, 27 Oct 2005 04:16:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV2vk-0003YQ-RR for ipsec@megatron.ietf.org; Thu, 27 Oct 2005 04:16:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15125 for ; Thu, 27 Oct 2005 04:15:57 -0400 (EDT) Received: from smtp.um.es ([155.54.212.105] helo=mail.um.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV393-0002Ej-RO for ipsec@ietf.org; Thu, 27 Oct 2005 04:29:59 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id DA3DD23C5DB for ; Thu, 27 Oct 2005 10:15:56 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03090-01-3 for ; Thu, 27 Oct 2005 10:15:56 +0200 (CEST) Received: from mistral.dif.um.es (mistral.dif.um.es [155.54.1.60]) by mail.um.es (Postfix) with ESMTP id B3B0B23C5DA for ; Thu, 27 Oct 2005 10:15:56 +0200 (CEST) Received: from pcalex (openikev2.dif.um.es [155.54.210.130]) by mistral.dif.um.es (Postfix) with ESMTP id 9856E1054023 for ; Thu, 27 Oct 2005 10:12:15 +0200 (CEST) From: Alejandro Perez Mendez To: IPsec WG Date: Thu, 27 Oct 2005 10:16:00 +0200 Message-Id: <1130400960.9099.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.8 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Ipsec] Rekeying IKE_SAs with the CREATE_CHILD_SA exhange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1987093083==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1987093083== Content-Type: multipart/alternative; boundary="=-3fGUE0+83Wo2kg7i0LwJ" --=-3fGUE0+83Wo2kg7i0LwJ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In order to get a better clarification document, we report a misprint found in the Appendix A. The clarifications document says in its section 5.1: << KEi and KEr are required for rekeying an IKE_SA.>> But in the "Appendix A. Exchanges and payloads" in the section "A.5. CREATE_CHILD_SA exchange for rekeying the IKE_SA" shows: << A.5. CREATE_CHILD_SA exchange for rekeying the IKE_SA =20 request --> SA, Ni, [KEi] =20 response <-- SA, Nr, [KEr] >> where KEi and KEr seems to be optionals. Regards! Alejandro P=C3=A9rez M=C3=A9ndez Pedro J. Fern=C3=A1ndez Ruiz --=-3fGUE0+83Wo2kg7i0LwJ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit In order to get a better clarification document, we report a misprint found in the Appendix A.

The clarifications document says in its section 5.1:
<< KEi and KEr are required for rekeying an IKE_SA.>>
But in the "Appendix A. Exchanges and payloads" in the section "A.5. CREATE_CHILD_SA exchange for rekeying the IKE_SA" shows:
<< A.5.  CREATE_CHILD_SA exchange for rekeying the IKE_SA

   request             --> SA, Ni, [KEi]

   response            <-- SA, Nr, [KEr] >>
where KEi and KEr seems to be optionals.

Regards!

Alejandro Pérez Méndez
Pedro J. Fernández Ruiz

--=-3fGUE0+83Wo2kg7i0LwJ-- --===============1987093083== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1987093083==-- From ipsec-bounces@ietf.org Thu Oct 27 06:41:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV5CM-00032X-TC; Thu, 27 Oct 2005 06:41:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV5CK-000304-Mv for ipsec@megatron.ietf.org; Thu, 27 Oct 2005 06:41:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20869 for ; Thu, 27 Oct 2005 06:41:12 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV5Pe-0005vf-4S for ipsec@ietf.org; Thu, 27 Oct 2005 06:55:16 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9RAd1Z8008732; Thu, 27 Oct 2005 13:39:01 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Oct 2005 13:41:18 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Oct 2005 13:41:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Rekeying IKE_SAs with the CREATE_CHILD_SA exhange Date: Thu, 27 Oct 2005 13:41:20 +0300 Message-ID: Thread-Topic: [Ipsec] Rekeying IKE_SAs with the CREATE_CHILD_SA exhange Thread-Index: AcXazz4LC+JuqQhfRU2iomXTXCKdgQAEXsMA To: , X-OriginalArrivalTime: 27 Oct 2005 10:41:17.0573 (UTC) FILETIME=[F6117350:01C5DAE2] X-Spam-Score: 0.3 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is actually one of those issues we haven't reached=20 consensus yet. It seems that we have consensus on the following: - It is mandatory to include one or more type 4 (D-H) transform=20 substructures in the SA payload when rekeying the IKE_SA (Section 3.3.3). - Doing a new Diffie-Hellman exchange is not mandatory when=20 rekeying the IKE_SA (e.g. Section 2.18 says that g^ir term is optional). Thus, although including a D-H transform substructure is mandatory, it can contain value "NONE". - Usually implementations will want to do a new D-H exchange when the IKE_SA is rekeyed; i.e., while NONE is allowed here,=20 it's probably not the most common case. - Doing D-H is not mandatory when rekeying or creating a CHILD_SA. =20 - When you're rekeying or creating a CHILD_SA, and you're not doing D-H, the KEi/KEr payloads are not included. My interpretation of the spec is that =20 - When you're rekeying the IKE_SA, and you're not doing D-H, the KEi/KEr payloads are not included. But at least Tero and Paul disagreed with this conclusion back in April (i.e., you have to include a dummy KEi/KEr payloads even when you're not doing D-H --- but only the IKE_SA case, not in the CHILD_SA case)... There hasn't been much discussion about this since, though.. Best regards, Pasi=20 -------------------- > From: Alejandro Perez Mendez > Sent: 27 October, 2005 11:16 > To: IPsec WG > Subject: [Ipsec] Rekeying IKE_SAs with the CREATE_CHILD_SA exhange > > In order to get a better clarification document, we report a > misprint found in the Appendix A. > =20 > The clarifications document says in its section 5.1: > > << KEi and KEr are required for rekeying an IKE_SA.>> > =20 > But in the "Appendix A. Exchanges and payloads" in the section > "A.5. CREATE_CHILD_SA exchange for rekeying the IKE_SA" shows: > > << A.5. CREATE_CHILD_SA exchange for rekeying the IKE_SA > > request --> SA, Ni, [KEi] > =20 > response <-- SA, Nr, [KEr] >> > =20 > where KEi and KEr seems to be optionals. > =20 > Regards! > =20 > Alejandro P=E9rez M=E9ndez > Pedro J. Fern=E1ndez Ruiz _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 27 12:42:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVAq1-0003lx-Gr; Thu, 27 Oct 2005 12:42:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVApz-0003la-IE for ipsec@megatron.ietf.org; Thu, 27 Oct 2005 12:42:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14105 for ; Thu, 27 Oct 2005 12:42:31 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVB3O-00036G-AY for ipsec@ietf.org; Thu, 27 Oct 2005 12:56:38 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j9RGgYWQ028533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Oct 2005 19:42:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9RGgYNC024635; Thu, 27 Oct 2005 19:42:34 +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: <17249.890.129697.738139@fireball.kivinen.iki.fi> Date: Thu, 27 Oct 2005 19:42:34 +0300 From: Tero Kivinen To: Pasi.Eronen@nokia.com Subject: RE: [Ipsec] Rekeying IKE_SAs with the CREATE_CHILD_SA exhange In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 5 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > My interpretation of the spec is that > > - When you're rekeying the IKE_SA, and you're not doing D-H, > the KEi/KEr payloads are not included. > > But at least Tero and Paul disagreed with this conclusion back > in April (i.e., you have to include a dummy KEi/KEr payloads > even when you're not doing D-H --- but only the IKE_SA case, > not in the CHILD_SA case)... Not dummy KEi/KEr payloads. I say that the Diffie-Hellman is mandatory when you rekey IKE_SA. There is no point of doing IKE SA rekey if you do not do Diffie-Hellman at the same time, as that means that breaking the original IKE SA protection will also reveal these keys. There is reasons to do IPsec SA rekeys without doing the Diffie-Hellman, but I do not think any of those reasons apply for the IKE SA. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 27 12:59:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVB6F-0003SW-86; Thu, 27 Oct 2005 12:59:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVB6D-0003R2-1x for ipsec@megatron.ietf.org; Thu, 27 Oct 2005 12:59:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15444 for ; Thu, 27 Oct 2005 12:59:16 -0400 (EDT) Received: from 84-121-24-204.onocable.ono.com ([84.121.24.204] helo=localhost.localdomain) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVBJW-0003lL-JI for ipsec@ietf.org; Thu, 27 Oct 2005 13:13:24 -0400 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id DD4778E3BB; Thu, 27 Oct 2005 18:59:00 +0200 (CEST) Subject: RE: [Ipsec] Rekeying IKE_SAs with the CREATE_CHILD_SA exhange From: Alejandro Perez Mendez To: Tero Kivinen In-Reply-To: <17249.890.129697.738139@fireball.kivinen.iki.fi> References: <17249.890.129697.738139@fireball.kivinen.iki.fi> Content-Type: text/plain Date: Thu, 27 Oct 2005 18:59:00 +0200 Message-Id: <1130432340.11096.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > Pasi.Eronen@nokia.com writes: > > My interpretation of the spec is that > > > > - When you're rekeying the IKE_SA, and you're not doing D-H, > > the KEi/KEr payloads are not included. > > > > But at least Tero and Paul disagreed with this conclusion back > > in April (i.e., you have to include a dummy KEi/KEr payloads > > even when you're not doing D-H --- but only the IKE_SA case, > > not in the CHILD_SA case)... > > Not dummy KEi/KEr payloads. I say that the Diffie-Hellman is mandatory > when you rekey IKE_SA. There is no point of doing IKE SA rekey if you > do not do Diffie-Hellman at the same time, as that means that breaking > the original IKE SA protection will also reveal these keys. > > There is reasons to do IPsec SA rekeys without doing the > Diffie-Hellman, but I do not think any of those reasons apply for the > IKE SA. I agree with both. I think that if DiffieHellman exchange is not mandatory when rekeying an IKE_SA, then if one doesn't want to perform that exchange he shouldn't include any KE payload. I also agree with Tero: there isn't any reason (IMHO) to make an IKE_SA rekey without a DiffieHellman exchange. -- Alejandro Perez Mendez _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 27 16:49:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVEgG-0005RD-Aj; Thu, 27 Oct 2005 16:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVEgF-0005Qu-3P for ipsec@megatron.ietf.org; Thu, 27 Oct 2005 16:48:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16330 for ; Thu, 27 Oct 2005 16:48:43 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVEte-0000Eh-EA for ipsec@ietf.org; Thu, 27 Oct 2005 17:02:52 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9RKZpL29042; Thu, 27 Oct 2005 13:35:51 -0700 (PDT) Message-ID: <43613A28.2070709@isi.edu> Date: Thu, 27 Oct 2005 13:35:52 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Ipsec] L2TP/ IPsec References: <17235.35521.596432.159341@fireball.kivinen.iki.fi> In-Reply-To: <17235.35521.596432.159341@fireball.kivinen.iki.fi> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tero Kivinen wrote: > Vishwas Manral writes: > >>RFC3193, "Securing L2TP using IPsec" states that "Transport mode MUST be >>supported; tunnel mode MAY be supported". > > If I have understood correctly L2TP usage with IPsec then from the > IPsec point of view the L2TP traffic originates and terminates from > the IPsec node, i.e. it is not forwarded traffic. That is true for all tunnels where the tunnel is created by a separate mechanism (e.g., RFC-3884). In those cases, it can be argued that the router is acting as a host (packet source/sink) for tunneled traffic. > That is the reason > why transport mode is used there. There are a few reasons why the difference is important, in particular in decoupling key selection from next-hop routing, where next-hop is determined by the tunnel endpoint. > In the receiving end the IPsec > decapsulation is done and then the packet is forwarded to the > local application, that will then do the L2TP decapsulation and then > send new (in a sense of IPsec) packet forward. > >>However 2401bis states that >> "When security is >> desired between two intermediate systems along a path (vs. end-to-end >> use of IPsec), transport mode MAY be used between security gateways >> or between a security gateway and a host." >> >>Should we actually make changes in RFC3193 for L2TP/IPsec support to >>make Transport mode a MUST and Tunnel mode a MAY? > > I think the use of transport mode in the host to host application > specific use is ok, even when the application happens to be L2TP which > will then send/receive packets forward. I think the key issue is that > L2TP packet is not same IP packet than what is decapsulated from > inside of it. I agree. However, the issue about MAY vs. MUST focuses on whether L2TP focuses on 2401 or 2401bis, as noted in a later post. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDYTonE5f5cImnZrsRAu60AJ9xOwcRmPgB9ni2wFqeNXjtqYWOXQCgkJAM 8biCLP7o/9YHqWD4bIV1hTo= =y1/i -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 28 04:35:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVPhi-0006hm-TR; Fri, 28 Oct 2005 04:35:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVPhg-0006h1-JT for ipsec@megatron.ietf.org; Fri, 28 Oct 2005 04:35:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01181 for ; Fri, 28 Oct 2005 04:34:56 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVPvC-0006Ln-ME for ipsec@ietf.org; Fri, 28 Oct 2005 04:49:12 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9S8Yx5O018383; Fri, 28 Oct 2005 11:35:02 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 11:35:01 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 11:35:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Rekeying IKE_SAs with the CREATE_CHILD_SA exhange Date: Fri, 28 Oct 2005 11:35:01 +0300 Message-ID: Thread-Topic: [Ipsec] Rekeying IKE_SAs with the CREATE_CHILD_SA exhange Thread-Index: AcXbFXFhkUv+4YYkSqqsgU2BUJcW1gAgvkaA To: X-OriginalArrivalTime: 28 Oct 2005 08:35:01.0812 (UTC) FILETIME=[7CF9CF40:01C5DB9A] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > Not dummy KEi/KEr payloads. I say that the Diffie-Hellman > is mandatory when you rekey IKE_SA.=20 Is this your interpretation about what the spec currently says, or a proposal to change the spec? It seems to be the latter, since section 2.18 does suggest that DH is=20 not mandatory: SKEYSEED =3D prf(SK_d (old), [g^ir (new)] | Ni | Nr) And if it's a change, the clarifications document is the wrong place to do it -- you'll have to take it to the spec authors and AD... > There is no point of doing IKE SA rekey if you do not do > Diffie-Hellman at the same time, as that means that breaking > the original IKE SA protection will also reveal these keys. > > There is reasons to do IPsec SA rekeys without doing the > Diffie-Hellman, but I do not think any of those reasons apply=20 > for the IKE SA. Hmm... what about the other direction? If you rekey the IKE_SA=20 without DH, and an attacker later gets the _new_ keys, does=20 he also get the old keys?=20 It seems the answer is no (assuming that you're not keeping the old DH private value around)... so rekeying the IKE_SA=20 without DH can be a useful operation, since it provides some kind of forward secrecy...? (However, it doesn't really matter if we don't fully agree=20 on how useful this is; what matters is agreement on what the spec actually says.)=20 Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 28 06:07:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVR8m-0006jp-JR; Fri, 28 Oct 2005 06:07:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVR8k-0006jc-Ay for ipsec@megatron.ietf.org; Fri, 28 Oct 2005 06:07:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05180 for ; Fri, 28 Oct 2005 06:06:57 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVRMI-0000Ez-B6 for ipsec@ietf.org; Fri, 28 Oct 2005 06:21:14 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9SA3L4l003484; Fri, 28 Oct 2005 13:03:25 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 13:07:06 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 13:07:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Easy issues from the IKEv2 clarifications document Date: Fri, 28 Oct 2005 13:06:50 +0300 Message-ID: Thread-Topic: [Ipsec] Easy issues from the IKEv2 clarifications document Thread-Index: AcXZknGjouMxspqrSLGw0IqzEkU77QCFHCbg To: X-OriginalArrivalTime: 28 Oct 2005 10:07:06.0378 (UTC) FILETIME=[59DFAEA0:01C5DBA7] X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Francis Dupont wrote: =20 > This is the way IPv6 stateless configuration works, but IKEv2 > configuration payloads involve state at the responder, and=20 > are IMHO closer to DHCPv6 (which doesn't have this functionality). > =20 > =3D> but DHCPv6 has IA_TA (the functionality is the RFC 3041 one). Hmm, you're right, temporary addresses for privacy reasons might be one good reason to use this feature (requesting particular interface identifier but not prefix).=20 So it seems the text in clarifications-06 is basically right about this, but should have an additional example explaining why this feature was done this way. I'll try to write something... Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 28 06:30:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRV5-0002ry-Dz; Fri, 28 Oct 2005 06:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRV3-0002ro-Gh for ipsec@megatron.ietf.org; Fri, 28 Oct 2005 06:30:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06224 for ; Fri, 28 Oct 2005 06:30:00 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVRia-0000qI-GT for ipsec@ietf.org; Fri, 28 Oct 2005 06:44:18 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j9SAUCG1028977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 13:30:12 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9SAUCLs005109; Fri, 28 Oct 2005 13:30:12 +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: <17249.64948.348410.521348@fireball.kivinen.iki.fi> Date: Fri, 28 Oct 2005 13:30:12 +0300 From: Tero Kivinen To: Subject: RE: [Ipsec] Rekeying IKE_SAs with the CREATE_CHILD_SA exhange In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 19 min X-Total-Time: 28 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > Tero Kivinen wrote: > > > Not dummy KEi/KEr payloads. I say that the Diffie-Hellman > > is mandatory when you rekey IKE_SA. > > Is this your interpretation about what the spec currently > says, or a proposal to change the spec? It seems to be > the latter, since section 2.18 does suggest that DH is > not mandatory: > > SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr) Yes, I think that picture is incorrect. > And if it's a change, the clarifications document is the > wrong place to do it -- you'll have to take it to the spec > authors and AD... We are doing all kind of similar changes in the clarification document already. I.e. Making one interpretation to be the one accepted one when the IKEv2 document has contradictional sections. I think the clarification document section 5.1. is now correct, i.e. key exchange payloads and Diffie-Hellman is required when rekeying IKE SA. > > > There is no point of doing IKE SA rekey if you do not do > > Diffie-Hellman at the same time, as that means that breaking > > the original IKE SA protection will also reveal these keys. > > > > There is reasons to do IPsec SA rekeys without doing the > > Diffie-Hellman, but I do not think any of those reasons apply > > for the IKE SA. > > Hmm... what about the other direction? If you rekey the IKE_SA > without DH, and an attacker later gets the _new_ keys, does > he also get the old keys? That depends how he manages to break the new keys. If the old SK_* data is removed from the memory before he gets hold of the new keys, then he will not get access to those old keys. If he manages to break the Diffie-Hellman of the original exchange, then he will get everything done by the peers after that point, including all later IKE SA rekeys which do not do Diffie-Hellman. > It seems the answer is no (assuming that you're not keeping > the old DH private value around)... so rekeying the IKE_SA > without DH can be a useful operation, since it provides some > kind of forward secrecy...? > > (However, it doesn't really matter if we don't fully agree > on how useful this is; what matters is agreement on what > the spec actually says.) Spec says that Diffie-Hellman Group is mandatory in the SA payloads negotiating IKE SA, and I think that strongly indicates that Diffie-Hellman is mandatory when creating or rekeying IKE SA. This is repeated 2 times in the IKEv2 document (section 3.3.2, and in 3.3.3). The only indication that it might be optional is the picture of the 2.18 having [] around it. Note that in 2.17 where it talks about IPsec SAs it explictly mentions that Diffie-Hellman is optional, and actually have 2 different pictures listing both cases. When we were creating IKEv2 we were trying to remove options as much as possible. This is one of those options that I do not think adds anything to the protocol, but is just one more useless option that needs to be tested. After the first interop of IKEv2 we decided that it is mandatory to do Diffie-Hellman, and in the last interop, I think everybody was doing that. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 28 07:58:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVSsK-00013K-2z; Fri, 28 Oct 2005 07:58:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVSsI-00013C-ES for ipsec@megatron.ietf.org; Fri, 28 Oct 2005 07:58:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09897 for ; Fri, 28 Oct 2005 07:58:03 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVT5m-00039K-W1 for ipsec@ietf.org; Fri, 28 Oct 2005 08:12:21 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9SBw8Xn013875; Fri, 28 Oct 2005 14:58:15 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 14:58:15 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 14:58:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Rekeying IKE_SAs with the CREATE_CHILD_SA exhange Date: Fri, 28 Oct 2005 14:58:14 +0300 Message-ID: Thread-Topic: [Ipsec] Rekeying IKE_SAs with the CREATE_CHILD_SA exhange Thread-Index: AcXbqqRdvXqg91SLRXy2sBztNM1cBgAA1q/w To: X-OriginalArrivalTime: 28 Oct 2005 11:58:15.0448 (UTC) FILETIME=[E0F30180:01C5DBB6] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > > Is this your interpretation about what the spec currently > > says, or a proposal to change the spec? It seems to be > > the latter, since section 2.18 does suggest that DH is=20 > > not mandatory: > >=20 > > SKEYSEED =3D prf(SK_d (old), [g^ir (new)] | Ni | Nr) >=20 > Yes, I think that picture is incorrect.=20 >=20 > > And if it's a change, the clarifications document is the > > wrong place to do it -- you'll have to take it to the spec > > authors and AD... >=20 > We are doing all kind of similar changes in the clarification=20 > document already. I.e. Making one interpretation to be the one=20 > accepted one when the IKEv2 document has contradictional sections. Except in this case, the IKEv2 document does not seem to have any contradictions. > I think the clarification document section 5.1. is now correct,=20 > i.e. key exchange payloads and Diffie-Hellman is required when=20 > rekeying IKE SA.=20 > > Spec says that Diffie-Hellman Group is mandatory in the SA payloads > negotiating IKE SA, and I think that strongly indicates that > Diffie-Hellman is mandatory when creating or rekeying IKE SA. The spec also says it's mandatory to include the ESN transform in=20 the SA payloads negotiating a CHILD_SA, but this does not imply=20 that the value "0" is not allowed. And there's no text saying that=20 the DH transform would be an exception where the value 0 is forbidden. > This is repeated 2 times in the IKEv2 document (section 3.3.2, and in > 3.3.3). The only indication that it might be optional is the picture > of the 2.18 having [] around it. Note that in 2.17 where it talks > about IPsec SAs it explictly mentions that Diffie-Hellman is optional, > and actually have 2 different pictures listing both cases. > > When we were creating IKEv2 we were trying to remove options as much > as possible. This is one of those options that I do not think adds > anything to the protocol, but is just one more useless option that > needs to be tested. >=20 > After the first interop of IKEv2 we decided that it is mandatory to do > Diffie-Hellman, and in the last interop, I think everybody was doing > that.=20 I agree with you that having this option is not very useful; what I don't agree is that this would be a "clarification" that can be just decided over coffee at an interop. The change history in the IKEv2 draft appendix strongly suggests that this was a technical decision made a long time ago: H.1 Changes from IKEv2-00 to IKEv2-01 February 2002 ... 6) Removed requirement that Diffie-Hellman be repeated when=20 rekeying IKE_SA. It might well be that the decision was not a good one, and needs=20 to be changed. But this should be done according to proper=20 procedures, just like the ESN transform change was done in March. In other words, the Area Director and (ex-)WG chairs need to=20 be in the loop, and preferably, a straw poll should be held on the mailing list to check consensus. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 28 09:09:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVTzQ-0006cU-Q9; Fri, 28 Oct 2005 09:09:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVTzP-0006cK-8Z for ipsec@megatron.ietf.org; Fri, 28 Oct 2005 09:09:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13380 for ; Fri, 28 Oct 2005 09:09:29 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVUCx-0004xT-M2 for ipsec@ietf.org; Fri, 28 Oct 2005 09:23:49 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j9SD9fEn025154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 16:09:41 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9SD9eFq027791; Fri, 28 Oct 2005 16:09:40 +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: <17250.8980.361891.445393@fireball.kivinen.iki.fi> Date: Fri, 28 Oct 2005 16:09:40 +0300 From: Tero Kivinen To: Subject: RE: [Ipsec] Rekeying IKE_SAs with the CREATE_CHILD_SA exhange In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min X-Spam-Score: 1.1 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > I agree with you that having this option is not very useful; what I > don't agree is that this would be a "clarification" that can be just > decided over coffee at an interop. The change history in the IKEv2 > draft appendix strongly suggests that this was a technical decision > made a long time ago: > > H.1 Changes from IKEv2-00 to IKEv2-01 February 2002 > ... > 6) Removed requirement that Diffie-Hellman be repeated when > rekeying IKE_SA. > > It might well be that the decision was not a good one, and needs > to be changed. But this should be done according to proper > procedures, just like the ESN transform change was done in March. I do not remember why this decision would have been made, but I think as this option just one option without any clear use, we should simply remove it. We can remove it when we are progressing IKEv2 protocol forward later in the standardization process (actually it will be removed automatically unless two implementations implements it). We did do lots of doing one thing, and then going back to the previous version while doing IKEv2, and this might be just one of the leftovers from those discussions. > In other words, the Area Director and (ex-)WG chairs need to > be in the loop, and preferably, a straw poll should be held > on the mailing list to check consensus. I do not think we can or will change the IKEv2 draft now, but we can add to the clarification document a text saying "this feature is not supposed to be used, no need to implement this". You can add text there saying, that you still think it is techincally allowed by the IKEv2 draft, but as it is useless to do IKE SA rekey without diffie-hellman, nobody should implement that feature. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 28 09:44:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUWX-000059-Qa; Fri, 28 Oct 2005 09:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUWV-00004z-QM for ipsec@megatron.ietf.org; Fri, 28 Oct 2005 09:43:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14942 for ; Fri, 28 Oct 2005 09:43:41 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVUk2-0005rX-Ee for ipsec@ietf.org; Fri, 28 Oct 2005 09:58:02 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9SDfXG9019239; Fri, 28 Oct 2005 16:41:33 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 16:43:54 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 16:43:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Rekeying IKE_SAs with the CREATE_CHILD_SA exhange Date: Fri, 28 Oct 2005 16:43:53 +0300 Message-ID: Thread-Topic: [Ipsec] Rekeying IKE_SAs with the CREATE_CHILD_SA exhange Thread-Index: AcXbwRUco3Zekl3fSt23ShFAKDx82QAA9/zQ To: X-OriginalArrivalTime: 28 Oct 2005 13:43:53.0897 (UTC) FILETIME=[A2F59190:01C5DBC5] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen: > I do not think we can or will change the IKEv2 draft now, but we can > add to the clarification document a text saying "this feature is not > supposed to be used, no need to implement this". You can add text > there saying, that you still think it is techincally allowed by the > IKEv2 draft, but as it is useless to do IKE SA rekey without > diffie-hellman, nobody should implement that feature.=20 Here's my proposal for text: There has been some confusion whether doing a new Diffie-Hellman exchange is mandatory when the IKE_SA is rekeyed. It seems that this case is allowed by the current IKEv2 specification. Section 2.18 shows the Diffie-Hellman term (g^ir) in brackets, and the change history appendix mentions this as one change between draft versions -00 and -01. Section 3.3.3 does not contradict this when it says that including the D-H transform is mandatory: although including the transform is mandatory, it can contain the value "NONE". However, having the option to skip the Diffie-Hellman exchange when rekeying the IKE_SA does not add useful functionality to the protocol. The main purpose of rekeying the IKE_SA is to ensure that the compromise of old keying material does not provide information about the current keys, or vice versa. This requires performing the Diffie-Hellman exchange when rekeying. Furthermore, it is likely that this option would have been removed from the protocol as unnecessary complexity had it been discussed earlier. Given this, we recommend that implementations should have a hard-coded policy that requires performing a new Diffie-Hellman exchange when rekeying the IKE_SA. In other words, the initiator should not propose the value "NONE" for the D-H transform, and the responder should not accept such a proposal. This policy also=20 implies that a succesful exchange rekeying the IKE_SA always=20 includes the KEi/KEr payloads. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 28 09:51:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUe8-0005Z6-Hs; Fri, 28 Oct 2005 09:51:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUe7-0005VL-4h for ipsec@megatron.ietf.org; Fri, 28 Oct 2005 09:51:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16483 for ; Fri, 28 Oct 2005 09:51:32 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVUrf-0006E6-MR for ipsec@ietf.org; Fri, 28 Oct 2005 10:05:52 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j9SDplda006874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 16:51:47 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9SDpliV023205; Fri, 28 Oct 2005 16:51:47 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17250.11507.403173.30822@fireball.kivinen.iki.fi> Date: Fri, 28 Oct 2005 16:51:47 +0300 From: Tero Kivinen To: Subject: RE: [Ipsec] Rekeying IKE_SAs with the CREATE_CHILD_SA exhange In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > There has been some confusion whether doing a new Diffie-Hellman > exchange is mandatory when the IKE_SA is rekeyed. > > It seems that this case is allowed by the current IKEv2 > specification. Section 2.18 shows the Diffie-Hellman term (g^ir) in > brackets, and the change history appendix mentions this as one > change between draft versions -00 and -01. Section 3.3.3 does not > contradict this when it says that including the D-H transform is > mandatory: although including the transform is mandatory, it can > contain the value "NONE". > > However, having the option to skip the Diffie-Hellman exchange > when rekeying the IKE_SA does not add useful functionality to the > protocol. The main purpose of rekeying the IKE_SA is to ensure that > the compromise of old keying material does not provide information > about the current keys, or vice versa. This requires performing the > Diffie-Hellman exchange when rekeying. Furthermore, it is likely > that this option would have been removed from the protocol as > unnecessary complexity had it been discussed earlier. > > Given this, we recommend that implementations should have a > hard-coded policy that requires performing a new Diffie-Hellman > exchange when rekeying the IKE_SA. In other words, the initiator > should not propose the value "NONE" for the D-H transform, and the > responder should not accept such a proposal. This policy also > implies that a succesful exchange rekeying the IKE_SA always > includes the KEi/KEr payloads. Looks good for me. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec