From owner-ipsec@lists.tislabs.com Mon Jul 1 06:35:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g61DZ4w18917; Mon, 1 Jul 2002 06:35:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05640 Mon, 1 Jul 2002 08:52:23 -0400 (EDT) Message-Id: <200207011035.GAA21362@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-cbc-04.txt Date: Mon, 01 Jul 2002 06:35:14 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The AES Cipher Algorithms and Their Use With IPsec Author(s) : S. Frankel, S. Kelly, R. Glenn Filename : draft-ietf-ipsec-ciph-aes-cbc-04.txt Pages : 16 Date : 28-Jun-02 This document describes the use of the AES Cipher Algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mecha- nism within the context of the IPsec Encapsulating Security Payload (ESP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-ipsec-ciph-aes-cbc-04.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-ietf-ipsec-ciph-aes-cbc-04.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020628141943.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-cbc-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628141943.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Jul 1 06:35:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g61DZ5w18922; Mon, 1 Jul 2002 06:35:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05631 Mon, 1 Jul 2002 08:51:22 -0400 (EDT) Message-Id: <200206292121.g5TLL7c4030137@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: Re: JFK negotiation Cc: dfaucher@lucent.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 29 Jun 2002 17:21:07 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > For JFK negotiations shouldn't message 4 contain as > its first field, Ni (to differentiate between different > parallel sessions)? We assume (unlike IKE) that the initiator will use different UDP ports. If the WG wants to do everything over the same port (e.g., 500-to-500), then Ni/Nr would be needed in message 4. -Angelos From owner-ipsec@lists.tislabs.com Mon Jul 1 06:35:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g61DZ8w18950; Mon, 1 Jul 2002 06:35:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05649 Mon, 1 Jul 2002 08:53:26 -0400 (EDT) Message-Id: <200207011035.GAA21411@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-sha-256-01.txt Date: Mon, 01 Jul 2002 06:35:24 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The HMAC-SHA-256-96 Algorithm and Its Use With IPsec Author(s) : S. Frankel, S. Kelly Filename : draft-ietf-ipsec-ciph-sha-256-01.txt Pages : 10 Date : 28-Jun-02 This document describes the use of the HMAC algorithm in conjunction with the SHA-256 algorithm as an experimental authentication mecha- nism within the context of the IPsec AH and ESP protocols. This algo- rithm is intended to provide data origin authentication and integrity protection. Given the current lack of practical experience with SHA-256, implementations based on this document will be experimental in nature, and implementation is not required in order to claim com- pliance with the IPsec proposed standards. The version of the HMAC- SHA-256 authenticator described in this document specifies truncation to 128 bits, and is therefore named HMAC-SHA-256-128. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-sha-256-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-ipsec-ciph-sha-256-01.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-ietf-ipsec-ciph-sha-256-01.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020628141953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-sha-256-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-sha-256-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020628141953.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Jul 1 06:40:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g61Dedw19374; Mon, 1 Jul 2002 06:40:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05685 Mon, 1 Jul 2002 09:04:27 -0400 (EDT) Date: 28 Jun 2002 20:01:06 -0400 Message-ID: <000301c21f00$11b179e0$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Karen Seo'" , " 'list'" Subject: RE: new version of ESP ID MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > A question was posed to the working group (6/17) as to whether to > change the SA demuxing values to allow use of the Source IP address > for source-specific multicast protocols. There has been no feedback > so far so no changes were made. I spoke with the original poster (who also works at Alcatel). It doesn't appear that the use of the source IP as a selector would affect normal IPsec operation, since you only need to apply the rule when you are doing SSM and when you are doing SSM you will know which addresses are unicast and which are SSM. Therefore, this sounds like a question for the MSec WG. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Karen Seo > Sent: Friday, June 28, 2002 6:55 PM > To: ipsec@lists.tislabs.com > Cc: skent@gto-mailer1.bbn.com; clynn@gto-mailer1.bbn.com; > kseo@gto-mailer1.bbn.com > Subject: new version of ESP ID > > > Folks, > > We have just submitted the following 2 drafts: > > 1. a revised version of the Internet Draft for the IP Encapsulating > Security Payload (ESP). It has only a couple of changes from the > previous version: > > A. Section 2.2.1 "Extended Sequence Number", paragraph 1 > Changed "SHOULD" to MUST" as follows: > > Old text: > "Use of an Extended Sequence Number (ESN) SHOULD be negotiated > by an SA management protocol, although it could also be part > of the configuration data for a manually configured SA." > > New text: > "Use of an Extended Sequence Number (ESN) MUST be negotiated > by an SA management protocol." > > B. Section 5 "Conformance Requirements". Added a default > key size of 128 bits for "AES in CBC mode". > > Old text: > "A compliant ESP implementation MUST support the following > mandatory-to-implement algorithms: > - AES in CBC mode" > > New text: > "A compliant ESP implementation MUST support the following > mandatory-to-implement algorithms: > - AES (with 128-bit keys) in CBC mode" > > 2. a revised version of the Internet Draft for the IP Authentication > Header (AH). It has only one change from the previous version: > > A. Section 2.5.1 "Extended Sequence Number", paragraph 1 > Changed "SHOULD" to MUST" as follows: > > Old text: > "Use of an Extended Sequence Number (ESN) SHOULD be negotiated > by an SA management protocol, although it could also be part > of the configuration data for a manually configured SA." > > New text: > "Use of an Extended Sequence Number (ESN) MUST be negotiated > by an SA management protocol." > > > A question was posed to the working group (6/17) as to whether to > change the SA demuxing values to allow use of the Source IP address > for source-specific multicast protocols. There has been no feedback > so far so no changes were made. > > Thank you, > Karen > > From owner-ipsec@lists.tislabs.com Mon Jul 1 09:09:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g61G9iw28305; Mon, 1 Jul 2002 09:09:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06095 Mon, 1 Jul 2002 11:24:09 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Mon, 1 Jul 2002 11:37:04 -0400 To: ipsec@lists.tislabs.com From: Karen Seo Subject: New IPsec ID -- draft-ietf-ipsec-esn-addendum-00.txt Cc: skent@bbn.com, clynn@bbn.com, kseo@gto-mailer1.bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Just FYI... On June 21, we submitted draft-ietf-ipsec-esn-addendum-00.txt to the Internet drafts secretariat. Abstract This document describes extensions to the Internet IP Security Domain of Interpretation for ISAKMP [DOI] that are needed to support negotiation of whether or not a Security Association will use Extended (64-bit) Sequence Numbers. (See [AH] and [ESP] for a description of Extended Sequence Numbers.) It should get out before the upcoming IETF meeting; but if for some reason it doesn't and you'd like a copy, please feel free to contact me and I'll send you a copy. It's only 5 pages long including all the copyright, etc. info. Karen From owner-ipsec@lists.tislabs.com Mon Jul 1 09:09:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g61G9jw28318; Mon, 1 Jul 2002 09:09:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06071 Mon, 1 Jul 2002 11:17:09 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Mon, 1 Jul 2002 11:30:42 -0400 To: ipsec@lists.tislabs.com From: Karen Seo Subject: Re: new version of ESP ID (plus new AH ID) Cc: skent@bbn.com, clynn@bbn.com, kseo@gto-mailer1.bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Sorry for any confusion caused by my previous message. In addition to a new ESP, the email mentioned that we'd submitted a new version of AH. The subject line should have said "new version of ESP and AH IDs". Karen From owner-ipsec@lists.tislabs.com Mon Jul 1 10:23:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g61HNZw02624; Mon, 1 Jul 2002 10:23:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06273 Mon, 1 Jul 2002 12:36:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Jul 2002 09:42:34 -0700 To: Karen Seo From: Mark Baugher Subject: Re: new version of ESP ID Cc: ipsec@lists.tislabs.com, skent@gto-mailer1.bbn.com, clynn@gto-mailer1.bbn.com, kseo@gto-mailer1.bbn.com, msec@securemulticast.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Karen, Steve, At 06:55 PM 6/28/2002 -0400, Karen Seo wrote: > > >A question was posed to the working group (6/17) as to whether to change >the SA demuxing values to allow use of the Source IP address for >source-specific multicast protocols. There has been no feedback so far so >no changes were made. I missed the 6/17 note. I have a few comments on use of the source IP address for source-specific multicast. First, section 2.2 deprecates sharing an SA among multiple senders to a multicast group and in effect mandates single-sender multicast for ESP groups. The same is true for AH. I'm aware of only one protocol, the VRRP specification, that is affected by this change. VRRP uses AH or ESP but allows multi-source multicast groups. We should notify the VRRP WG of this potential change. Second, I think there is an inconsistency between 2.2 and 3.4.2 in that 2.2 disallows sharing of an SA among multiple senders and 3.4.2 states that anti-replay SHOULD NOT be used in a multi-sender environment. Doesn't the first restriction obviate the need for the second? Finally, If we are going to restrict a multicast SA to single-source multicast groups, then I don't understand how we can avoid identifying associating that sender with the SA. If a member of the single-source multicast group who is not the authorized sender begins sending to that group, there is no way to identify this problem, which will likely break the anti-replay mechanism. regards, Mark >Thank you, >Karen > From owner-ipsec@lists.tislabs.com Mon Jul 1 11:24:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g61IOSw05164; Mon, 1 Jul 2002 11:24:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06532 Mon, 1 Jul 2002 13:42:35 -0400 (EDT) Message-Id: <4.3.2.7.2.20020701102526.04b8f538@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Jul 2002 10:35:03 -0700 To: annelies.van_moffaert@alcatel.be From: Mark Baugher Subject: Re: IPsec AH and ESP I-Ds; source address as possible SA selector for multicast SA? Cc: ipsec@lists.tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Annelies, Pardon my late response, I somehow misplaced this note. At 05:10 PM 6/17/2002 +0200, annelies.van_moffaert@alcatel.be wrote: >Dear all, > >Some time ago I posted a comment on the list regarding the new IPsec AH and >ESP I-Ds > draft-ietf-ipsec-rfc2402bis-00.txt and > draft-ietf-ipsec-esp-v3-02.txt > >In these drafts it is stated that for multicast the SPI in combination with >the destination IP address is used to select an SA. This can however lead >to ambiguity problems for SSM SAs (SSM = Source Specific Multicast). > >A range of multicast IP addresses is reserved for SSM. In SSM a group is >characterized by the pair (source IP address, destination IP address) and >every source can freely choose a destination IP address from the SSM range. >This means that it is possible that two different sources use the same >group address as IP destination address. >If the group controllers of the 2 would happen to choose the same SPI value >then the common receivers cannot distinguish between the SAs for the 2 >different groups since they have the smae SPI and the same destination IP >address. Yes, I think this could be a problem. A second potential problem that I mentioned in my previous message is when more that one sender sends to a single-source group. IGMPv3 provides a mechanism to prune unauthorized sources, but IGMPv2 might be used and the pruning may not occur because a particular receiver did not issue the request. In either case, the sequence number spaces will differ between the sources and cause problems at an unknowing reciever. >I think a good solution would be to include also the source address in the >SA selector for multicast SAs. This would also be very useful to protect >IGMP messages by means of IPsec AH. I favor this approach but it is not consistent with RFC2401. That's one issue. Another issue is whether we restrict SA's to be single-sender SAs if we associate the source address with the SA. In this case, the receiver can maintain a separate replay vector for each source. This approach won't scale to very large groups but will work for "small" and "moderate" size multi-sender groups. Mark >Steve Kent, author of the I-Ds, replied to me that it is up to the WG to >discuss this, hence my email... > >So I have to questions for the group: >Is the above mentioned problem already solved for the IPsec AH and ESP >I-Ds? and >Could the source IP address be included as SA selector? > >Kind regards, > Lies Van Moffaert. > > > > > >Stephen Kent on 03/05/2002 22:44:03 > > > > To: Annelies VAN MOFFAERT/BE/ALCATEL@ALCATEL > > cc: ipsec@lists.tislabs.com > > > > Subject: > > > > > > >At 2:51 PM +0200 4/30/02, annelies.van_moffaert@alcatel.be wrote: > >Hi Steven and all, > > > >I read the new IP Authentication Header I-D and I have a small question or > >remark about the multicast SAs. I saw that these are identified by the > >destination IP address > >and the SPI value and optionally, the protocol ID. > >I'm not sure whether this rules out all possible ambiguity for SSM. For >SSM > >the IP destination address does not need to be unique (if I remember > >correctly). A group session is in SSM identified by the pair (Source IP, > >Destination IP) and it is possible that 2 different sources choose the >same > >SSM group address as Destination IP address. The group controller of each > >will pick independently an SPI number. It's of course very unlikely but I > >think that it is then strictly speaking possible to have the same (SPI, > >Destination IP) pair for 2 different SSM sessions. In this case the > >receiver cannot differentiate between two different SAs since they have >the > >same identification pair (Destion IP, SPI). Is this correct or did I > >overlook something? > > > >Kind regards, > > Lies From owner-ipsec@lists.tislabs.com Mon Jul 1 13:59:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g61KxQw14766; Mon, 1 Jul 2002 13:59:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA12565 Mon, 1 Jul 2002 16:15:11 -0400 (EDT) Date: Mon, 1 Jul 2002 23:25:57 +0300 Message-Id: <200207012025.XAA01339@burp.tkv.asdf.org> From: Markku Savela To: mbaugher@cisco.com CC: annelies.van_moffaert@alcatel.be, ipsec@lists.tislabs.com In-reply-to: <4.3.2.7.2.20020701102526.04b8f538@mira-sjc5-6.cisco.com> (message from Mark Baugher on Mon, 01 Jul 2002 10:35:03 -0700) Subject: Re: IPsec AH and ESP I-Ds; source address as possible SA selector for multicast SA? References: <4.3.2.7.2.20020701102526.04b8f538@mira-sjc5-6.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Mark Baugher > >I think a good solution would be to include also the source address in the > >SA selector for multicast SAs. This would also be very useful to protect > >IGMP messages by means of IPsec AH. > > I favor this approach but it is not consistent with RFC2401. Nothing in RFC2401 prevents using source address as a selector. From owner-ipsec@lists.tislabs.com Mon Jul 1 20:44:21 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g623iLw00498; Mon, 1 Jul 2002 20:44:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA12997 Mon, 1 Jul 2002 22:48:27 -0400 (EDT) Message-ID: <3D211784.8010607@speakeasy.net> Date: Mon, 01 Jul 2002 20:01:24 -0700 From: Sankar Ramanoorthi User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020206 X-Accept-Language: en-us MIME-Version: 1.0 To: andrew.krywaniuk@alcatel.com CC: "'list'" Subject: Re: SOI QUESTIONS: 3.4 - 4.3 References: <001501c2207f$64faab00$0468e640@ca.alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I was asking about PFS for keepalive messages - I was assuming these are sent as notification messages using IKE SA. -- sankar ramamoorthi (sankarr@juniper.net) -- Andrew Krywaniuk wrote: >>If phase1 SA is used as the control channel for keep-alive messages, >>what are the implications with regard to PFS? That is, if PFS is used >>to rekey the ipsec session key after an interval for >>perfect-forward-secrecy, is it okay to continue using the phase1 SA >>for keep alive packets with out worrying about PFS? >> > >If the phase 2 is rekeyed using PFS as defined in IKEv1, where the new DH >key is deleted immediately, then you obviously get full PFS of the second >kind. > >If you were using the type of rekeying I was suggesting earlier, where the >new DH key is reused across multiple phase 2s and then deleted after a fixed >interval, you still get PFS of the second kind to within your PFS interval. > >Andrew >------------------------------------------- >There are no rules, only regulations. Luckily, >history has shown that with time, hard work, >and lots of love, anyone can be a technocrat. > > > > From owner-ipsec@lists.tislabs.com Tue Jul 2 00:31:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g627Vjw13708; Tue, 2 Jul 2002 00:31:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA13258 Tue, 2 Jul 2002 02:43:57 -0400 (EDT) Date: 2 Jul 2002 02:44:20 -0400 Message-ID: <001e01c22193$e56b5180$f86ce640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Sankar Ramanoorthi'" Cc: "'list'" Subject: RE: SOI QUESTIONS: 3.4 - 4.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3D211784.8010607@speakeasy.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Keepalive messages do not contain any secret information so PFS is not important. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: Sankar Ramanoorthi [mailto:sankar@speakeasy.net] > Sent: Monday, July 01, 2002 11:01 PM > To: andrew.krywaniuk@alcatel.com > Cc: 'list' > Subject: Re: SOI QUESTIONS: 3.4 - 4.3 > > > Hi, > > I was asking about PFS for keepalive messages - I was > assuming these are > sent as notification messages using IKE SA. > > -- sankar ramamoorthi (sankarr@juniper.net) -- > > > Andrew Krywaniuk wrote: > > >>If phase1 SA is used as the control channel for keep-alive messages, > >>what are the implications with regard to PFS? That is, if > PFS is used > >>to rekey the ipsec session key after an interval for > >>perfect-forward-secrecy, is it okay to continue using the phase1 SA > >>for keep alive packets with out worrying about PFS? > >> > > > >If the phase 2 is rekeyed using PFS as defined in IKEv1, > where the new DH > >key is deleted immediately, then you obviously get full PFS > of the second > >kind. > > > >If you were using the type of rekeying I was suggesting > earlier, where the > >new DH key is reused across multiple phase 2s and then > deleted after a fixed > >interval, you still get PFS of the second kind to within > your PFS interval. > > > >Andrew > >------------------------------------------- > >There are no rules, only regulations. Luckily, > >history has shown that with time, hard work, > >and lots of love, anyone can be a technocrat. > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Tue Jul 2 02:58:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g629w7w24805; Tue, 2 Jul 2002 02:58:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA13526 Tue, 2 Jul 2002 05:16:13 -0400 (EDT) From: annelies.van_moffaert@alcatel.be Subject: Source address as possible SA selector for multicast SA? To: Mark Baugher Cc: ipsec@lists.tislabs.com, msec@securemulticast.org Date: Tue, 2 Jul 2002 11:29:04 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/02/2002 11:29:06 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, Thanks for your comments. As far as scalability is concerned. I agree that one SA per sender doesn't scale well for groups with a very large number of senders. However would the alternative be not to use the anti-replay mechanism? Or to use one SA for the whole group but within this SA a seperate sequence number window per sender? The latter case keeps also state per sender. So I guess it is not perfect from a scalability point of view either and it doesn't solve a number of other issues that a seperate SA per sender perhaps could solve. In case the source address could (optionally) be used as SA selector this could also be used to authenticate IGMP messages. Note that this would not be restricted to multicast addresses in the SSM range only. Since IGMP messages are exchanged only locally between hosts and routers on the same subnet, it would be most logical and preferable, I think,that also the SAs that protect these IGMP messages would be completely managed locally. However there are IGMP messages that are sent to the group addresses that have members on the subnet. In other words, apart from the source of the multicast data, the IGMP routers are also `sources' of IP packets sent to this address. Hence if the IGMP SAs are set up locally and independently from the global owner then the same ambiguity problem as for independent SSM sources can occur. The latter problem is also discussed in the last update of the draft draft-irtf-gsec-igmpv3-security-issues-02.txt (only in version 2; this version will hopefully be soon available but I can of course always send it to interested people.) Kind regards, Annelies Van Moffaert Mark Baugher on 01/07/2002 19:35:03 To: Annelies VAN MOFFAERT/BE/ALCATEL@ALCATEL cc: ipsec@lists.tislabs.com Subject: Re: IPsec AH and ESP I-Ds; source address as possible SA selector for multicast SA? Annelies, Pardon my late response, I somehow misplaced this note. At 05:10 PM 6/17/2002 +0200, annelies.van_moffaert@alcatel.be wrote: >Dear all, > >Some time ago I posted a comment on the list regarding the new IPsec AH and >ESP I-Ds > draft-ietf-ipsec-rfc2402bis-00.txt and > draft-ietf-ipsec-esp-v3-02.txt > >In these drafts it is stated that for multicast the SPI in combination with >the destination IP address is used to select an SA. This can however lead >to ambiguity problems for SSM SAs (SSM = Source Specific Multicast). > >A range of multicast IP addresses is reserved for SSM. In SSM a group is >characterized by the pair (source IP address, destination IP address) and >every source can freely choose a destination IP address from the SSM range. >This means that it is possible that two different sources use the same >group address as IP destination address. >If the group controllers of the 2 would happen to choose the same SPI value >then the common receivers cannot distinguish between the SAs for the 2 >different groups since they have the smae SPI and the same destination IP >address. Yes, I think this could be a problem. A second potential problem that I mentioned in my previous message is when more that one sender sends to a single-source group. IGMPv3 provides a mechanism to prune unauthorized sources, but IGMPv2 might be used and the pruning may not occur because a particular receiver did not issue the request. In either case, the sequence number spaces will differ between the sources and cause problems at an unknowing reciever. >I think a good solution would be to include also the source address in the >SA selector for multicast SAs. This would also be very useful to protect >IGMP messages by means of IPsec AH. I favor this approach but it is not consistent with RFC2401. That's one issue. Another issue is whether we restrict SA's to be single-sender SAs if we associate the source address with the SA. In this case, the receiver can maintain a separate replay vector for each source. This approach won't scale to very large groups but will work for "small" and "moderate" size multi-sender groups. Mark >Steve Kent, author of the I-Ds, replied to me that it is up to the WG to >discuss this, hence my email... > >So I have to questions for the group: >Is the above mentioned problem already solved for the IPsec AH and ESP >I-Ds? and >Could the source IP address be included as SA selector? > >Kind regards, > Lies Van Moffaert. > > > > > >Stephen Kent on 03/05/2002 22:44:03 > > > > To: Annelies VAN MOFFAERT/BE/ALCATEL@ALCATEL > > cc: ipsec@lists.tislabs.com > > > > Subject: > > > > > > >At 2:51 PM +0200 4/30/02, annelies.van_moffaert@alcatel.be wrote: > >Hi Steven and all, > > > >I read the new IP Authentication Header I-D and I have a small question or > >remark about the multicast SAs. I saw that these are identified by the > >destination IP address > >and the SPI value and optionally, the protocol ID. > >I'm not sure whether this rules out all possible ambiguity for SSM. For >SSM > >the IP destination address does not need to be unique (if I remember > >correctly). A group session is in SSM identified by the pair (Source IP, > >Destination IP) and it is possible that 2 different sources choose the >same > >SSM group address as Destination IP address. The group controller of each > >will pick independently an SPI number. It's of course very unlikely but I > >think that it is then strictly speaking possible to have the same (SPI, > >Destination IP) pair for 2 different SSM sessions. In this case the > >receiver cannot differentiate between two different SAs since they have >the > >same identification pair (Destion IP, SPI). Is this correct or did I > >overlook something? > > > >Kind regards, > > Lies From owner-ipsec@lists.tislabs.com Tue Jul 2 08:57:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62Fvhw24396; Tue, 2 Jul 2002 08:57:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14130 Tue, 2 Jul 2002 11:05:20 -0400 (EDT) Message-Id: <4.3.2.7.2.20020702080307.04d2def8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 02 Jul 2002 08:16:04 -0700 To: Markku Savela From: Mark Baugher Subject: identifying IPsec SAs (was Re: IPsec AH and ESP I-Ds; source address as possible SA selector for multicast SA? Cc: annelies.van_moffaert@alcatel.be, ipsec@lists.tislabs.com In-Reply-To: <200207012025.XAA01339@burp.tkv.asdf.org> References: <4.3.2.7.2.20020701102526.04b8f538@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020701102526.04b8f538@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:25 PM 7/1/2002 +0300, Markku Savela wrote: > > From: Mark Baugher > > > >I think a good solution would be to include also the source address in the > > >SA selector for multicast SAs. This would also be very useful to protect > > >IGMP messages by means of IPsec AH. > > > > I favor this approach but it is not consistent with RFC2401. > >Nothing in RFC2401 prevents using source address as a selector. Annalies used the term "selector," I didn't. I wasn't referring to the SPD and how packets are selected for IPsec processing but rather how an SA is identified. Section 4.1 of RFC 2401 says that an IPsec SA is uniquely identified by the triple . The issue is whether we support multi-sender multicast groups: If we allow multiple senders to a multicast destination address, then a 4-tuple is needed . Otherwise, we lose replay protection. It's worse if the IPsec implementation does not correctly handle the case of multiple senders and attempts IPsec replay protection on two or more different sequence number spaces. Mark From owner-ipsec@lists.tislabs.com Tue Jul 2 09:05:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62G5dw25279; Tue, 2 Jul 2002 09:05:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14162 Tue, 2 Jul 2002 11:19:24 -0400 (EDT) Message-Id: <4.3.2.7.2.20020702081612.04a49dc8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 02 Jul 2002 08:30:35 -0700 To: Stephen Kent From: Mark Baugher Subject: Re: new version of ESP ID Cc: ipsec@lists.tislabs.com, msec@securemulticast.org In-Reply-To: References: <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, At 05:07 PM 7/1/2002 -0400, Stephen Kent wrote: >>Finally, If we are going to restrict a multicast SA to single-source >>multicast groups, then I don't understand how we can avoid identifying >>associating that sender with the SA. If a member of the single-source >>multicast group who is not the authorized sender begins sending to that >>group, there is no way to identify this problem, which will likely break >>the anti-replay mechanism. > > The SA for a single-sender, multicast SA should specify the address of > the one, authorized sender and that would be checked by each receiver. I'm okay with this. It limits us strictly to single-sender multicast groups. Given the complexities of multicast security, that's probably the best approach at least for the near term. Shouldn't we document this constraint in the ESP (and AH) I-Ds? That is, the receiver SHALL check the source address of a received packet to ensure that it is from the authorized sender for the particular SA? >This is separate from the fact that the IP source address is not (and >never has been) used in selecting the SA for inbound traffic, i.e., it is >the destination address and the SPI that are used for that demuxing. Yes, and this is consistent with what RFC 2401 says: "The concept is applicable in the point-to-multipoint case as well." We disallow having multiple senders share an SA. Annalies point was (if I understand her correctly) that we cannot have multiple SAs for a particular multicast destination address because the SPIs might collide. The SPIs might collide if different group controllers assign them independently. Do you agree? Mark >Steve From owner-ipsec@lists.tislabs.com Tue Jul 2 09:15:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62GFSw25980; Tue, 2 Jul 2002 09:15:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14175 Tue, 2 Jul 2002 11:23:27 -0400 (EDT) From: annelies.van_moffaert@alcatel.be Subject: Re: identifying IPsec SAs (was Re: IPsec AH and ESP I-Ds; source address as possible SA selector for multicast SA? To: Mark Baugher Cc: Markku Savela , ipsec@lists.tislabs.com Date: Tue, 2 Jul 2002 17:35:23 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/02/2002 17:35:25 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry if any confusion resulted from my choice of words. I also intended to address the way an SA is identified. Probably "selector" was not the appropriate term in that case. Lies. Mark Baugher on 02/07/2002 17:16:04 To: Markku Savela cc: Annelies VAN MOFFAERT/BE/ALCATEL@ALCATEL, ipsec@lists.tislabs.com Subject: identifying IPsec SAs (was Re: IPsec AH and ESP I-Ds; source address as possible SA selector for multicast SA? At 11:25 PM 7/1/2002 +0300, Markku Savela wrote: > > From: Mark Baugher > > > >I think a good solution would be to include also the source address in the > > >SA selector for multicast SAs. This would also be very useful to protect > > >IGMP messages by means of IPsec AH. > > > > I favor this approach but it is not consistent with RFC2401. > >Nothing in RFC2401 prevents using source address as a selector. Annalies used the term "selector," I didn't. I wasn't referring to the SPD and how packets are selected for IPsec processing but rather how an SA is identified. Section 4.1 of RFC 2401 says that an IPsec SA is uniquely identified by the triple . The issue is whether we support multi-sender multicast groups: If we allow multiple senders to a multicast destination address, then a 4-tuple is needed . Otherwise, we lose replay protection. It's worse if the IPsec implementation does not correctly handle the case of multiple senders and attempts IPsec replay protection on two or more different sequence number spaces. Mark From owner-ipsec@lists.tislabs.com Tue Jul 2 09:29:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62GTNw27092; Tue, 2 Jul 2002 09:29:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14234 Tue, 2 Jul 2002 11:44:46 -0400 (EDT) Date: Tue, 2 Jul 2002 18:57:52 +0300 Message-Id: <200207021557.SAA02464@burp.tkv.asdf.org> From: Markku Savela To: mbaugher@cisco.com CC: annelies.van_moffaert@alcatel.be, ipsec@lists.tislabs.com In-reply-to: <4.3.2.7.2.20020702080307.04d2def8@mira-sjc5-6.cisco.com> (message from Mark Baugher on Tue, 02 Jul 2002 08:16:04 -0700) Subject: Re: identifying IPsec SAs (was Re: IPsec AH and ESP I-Ds; source address as possible SA selector for multicast SA? References: <4.3.2.7.2.20020701102526.04b8f538@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020701102526.04b8f538@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020702080307.04d2def8@mira-sjc5-6.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Mark Baugher > Cc: annelies.van_moffaert@alcatel.be, ipsec@lists.tislabs.com > Content-Type: text/plain; charset="us-ascii"; format=flowed > > At 11:25 PM 7/1/2002 +0300, Markku Savela wrote: > > > From: Mark Baugher > > > > > >I think a good solution would be to include also the source address in the > > > >SA selector for multicast SAs. This would also be very useful to protect > > > >IGMP messages by means of IPsec AH. > > > > > > I favor this approach but it is not consistent with RFC2401. > > > >Nothing in RFC2401 prevents using source address as a selector. > > Annalies used the term "selector," I didn't. I wasn't referring to the SPD > and how packets are selected for IPsec processing but rather how an SA is > identified. Section 4.1 of RFC 2401 says that an IPsec SA is uniquely > identified by the triple . Yes, , but then SA is supposed to include additional parameters (as per RFC 2401) which are used to distinguish between different SA's. One of those parameters is the source address (other paramters are the ports and transport protocol). We could have multiple SA's with same destination (= multicast group), with different source address. The proposed IKEv2 TS payload almost gets it, but there may be some confusion about two "source addresses": (1) the source address of the IPSEC node and (2) the source address of the original packet. However, as IKEv2 may not be relevant here (for negotiating multicast SA's), this may not be an issue? From owner-ipsec@lists.tislabs.com Tue Jul 2 09:37:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62Gbgw27414; Tue, 2 Jul 2002 09:37:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14337 Tue, 2 Jul 2002 11:56:49 -0400 (EDT) From: annelies.van_moffaert@alcatel.be Subject: Re: [MSEC] Re: new version of ESP ID To: Mark Baugher Cc: Stephen Kent , ipsec@lists.tislabs.com, msec@securemulticast.org Date: Tue, 2 Jul 2002 18:09:11 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/02/2002 18:09:12 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark and Steve, I am not sure I completely understand your arguments. I would think that there is a difference between saying that 1. IPsec can only be used to protect SSM or single-source multicast groups and 2. When using IPsec to protect multicast traffic one should use a seperate SA per sender. In the second case there can be more than 1 sender allowed to send to the same group. Both legitimate senders and receivers should then e.g. authenticate to a common key server and the key server could create for each sender a seperate SA. Additionally the key server would push the SAs to the group of receivers. A concrete example could be hosts that all send IGMP messages to the group address to which all IGMP capable routers listen or PIM routers that all send PIM messages to the PIM group address. It could also be a multicast data service with more than one legitimate source (all sources should then probably be under the control of a single key server). Do you have scenario 1 in mind or scenario 2 or again something else? A second question I have relates to the statement that "the receiver SHALL check the source address to ensure that it is from the authorized sender". Isn't this a weak check given that a source address can be spoofed by a receiver who wants to impersonate the sender? Mark explained correctly my concern related to colliding SPI values when independent group controllers manage SAs for the same destination address. Thanks! ;-) I think this problem could be solved by adding the source address to the triplet (SPI, protocol, dest IP addr). Kind regards, Lies. Mark Baugher @securemulticast.org on 02/07/2002 17:30:35 Sent by: msec-admin@securemulticast.org To: Stephen Kent cc: ipsec@lists.tislabs.com, msec@securemulticast.org Subject: [MSEC] Re: new version of ESP ID Steve, At 05:07 PM 7/1/2002 -0400, Stephen Kent wrote: >>Finally, If we are going to restrict a multicast SA to single-source >>multicast groups, then I don't understand how we can avoid identifying >>associating that sender with the SA. If a member of the single-source >>multicast group who is not the authorized sender begins sending to that >>group, there is no way to identify this problem, which will likely break >>the anti-replay mechanism. > > The SA for a single-sender, multicast SA should specify the address of > the one, authorized sender and that would be checked by each receiver. I'm okay with this. It limits us strictly to single-sender multicast groups. Given the complexities of multicast security, that's probably the best approach at least for the near term. Shouldn't we document this constraint in the ESP (and AH) I-Ds? That is, the receiver SHALL check the source address of a received packet to ensure that it is from the authorized sender for the particular SA? >This is separate from the fact that the IP source address is not (and >never has been) used in selecting the SA for inbound traffic, i.e., it is >the destination address and the SPI that are used for that demuxing. Yes, and this is consistent with what RFC 2401 says: "The concept is applicable in the point-to-multipoint case as well." We disallow having multiple senders share an SA. Annalies point was (if I understand her correctly) that we cannot have multiple SAs for a particular multicast destination address because the SPIs might collide. The SPIs might collide if different group controllers assign them independently. Do you agree? Mark >Steve _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From owner-ipsec@lists.tislabs.com Tue Jul 2 09:42:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62Gg7w27749; Tue, 2 Jul 2002 09:42:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14320 Tue, 2 Jul 2002 11:55:48 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <4.3.2.7.2.20020702081612.04a49dc8@mira-sjc5-6.cisco.com> References: <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020702081612.04a49dc8@mira-sjc5-6.cisco.com> Date: Tue, 2 Jul 2002 12:01:11 -0400 To: Mark Baugher From: Stephen Kent Subject: Re: new version of ESP ID Cc: ipsec@lists.tislabs.com, msec@securemulticast.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:30 AM -0700 7/2/02, Mark Baugher wrote: >Steve, > >At 05:07 PM 7/1/2002 -0400, Stephen Kent wrote: > > >>>Finally, If we are going to restrict a multicast SA to >>>single-source multicast groups, then I don't understand how we can >>>avoid identifying associating that sender with the SA. If a >>>member of the single-source multicast group who is not the >>>authorized sender begins sending to that group, there is no way to >>>identify this problem, which will likely break the anti-replay >>>mechanism. >> >> The SA for a single-sender, multicast SA should specify the >>address of the one, authorized sender and that would be checked by >>each receiver. > >I'm okay with this. It limits us strictly to single-sender >multicast groups. Given the complexities of multicast security, >that's probably the best approach at least for the near term. >Shouldn't we document this constraint in the ESP (and AH) I-Ds? >That is, the receiver SHALL check the source address of a received >packet to ensure that it is from the authorized sender for the >particular SA? We can clarify this in 2401bis, but the requirement has always been present to match the received packet (inner header for tunnel mode) against the selectors for the SA, to ensure that the received traffic is consistent with the access controls negotiated for the SA. So, this is just a case where the admin should have set the SA selectors to specify a single IP sources address for inbound traffic. >>This is separate from the fact that the IP source address is not >>(and never has been) used in selecting the SA for inbound traffic, >>i.e., it is the destination address and the SPI that are used for >>that demuxing. > >Yes, and this is consistent with what RFC 2401 says: "The concept >is applicable in the point-to-multipoint case as well." We disallow >having multiple senders share an SA. Annalies point was (if I >understand her correctly) that we cannot have multiple SAs for a >particular multicast destination address because the SPIs might >collide. The SPIs might collide if different group controllers >assign them independently. Do you agree? I've always assumed that a single controller or coordinated set of controllers assigned SPIs for a given multicast address anyway. All the senders and receivers have to have the same SPI for the traffic, so I assumed the requisite level of coordination was not a problem. Steve From owner-ipsec@lists.tislabs.com Tue Jul 2 09:45:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62Gjbw27948; Tue, 2 Jul 2002 09:45:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14372 Tue, 2 Jul 2002 12:03:53 -0400 (EDT) Message-ID: <3D21D287.8B0CA939@columbia.sparta.com> Date: Tue, 02 Jul 2002 12:19:19 -0400 From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Baugher CC: Stephen Kent , ipsec@lists.tislabs.com, msec@securemulticast.org Subject: Re: new version of ESP ID References: <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020702081612.04a49dc8@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark and Steve, I agree that if only one sender is authorized than that sender should be indicated in the SA as policy that must be adhered to. This should not cause one to disallow multiple senders sharing an SA. The policy rule must be flexible enough to allow an entity, a list, a rule, a wildcard, etc. to cover all multicast scenarios. It would be a shame to break future advanced multicast uses. I agree with Annalies that anti-replay is still a problem. We all acknowledged that several years ago in smug. We also discussed the SPI collision problem at that time. The probability that two sender-specific SAs would be assigned the same SPI in the same destination (multicast) address space is rather slim. Do you anticipate using different group keys for each of those SAs? --- Andrea Mark Baugher wrote: > Steve, > > At 05:07 PM 7/1/2002 -0400, Stephen Kent wrote: > > > >>Finally, If we are going to restrict a multicast SA to single-source > >>multicast groups, then I don't understand how we can avoid identifying > >>associating that sender with the SA. If a member of the single-source > >>multicast group who is not the authorized sender begins sending to that > >>group, there is no way to identify this problem, which will likely break > >>the anti-replay mechanism. > > > > The SA for a single-sender, multicast SA should specify the address of > > the one, authorized sender and that would be checked by each receiver. > > I'm okay with this. It limits us strictly to single-sender multicast > groups. Given the complexities of multicast security, that's probably the > best approach at least for the near term. Shouldn't we document this > constraint in the ESP (and AH) I-Ds? That is, the receiver SHALL check the > source address of a received packet to ensure that it is from the > authorized sender for the particular SA? > > >This is separate from the fact that the IP source address is not (and > >never has been) used in selecting the SA for inbound traffic, i.e., it is > >the destination address and the SPI that are used for that demuxing. > > Yes, and this is consistent with what RFC 2401 says: "The concept is > applicable in the point-to-multipoint case as well." We disallow having > multiple senders share an SA. Annalies point was (if I understand her > correctly) that we cannot have multiple SAs for a particular multicast > destination address because the SPIs might collide. The SPIs might collide > if different group controllers assign them independently. Do you agree? > > Mark > > >Steve From owner-ipsec@lists.tislabs.com Tue Jul 2 10:32:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62HWFw01202; Tue, 2 Jul 2002 10:32:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14486 Tue, 2 Jul 2002 12:36:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3D21D287.8B0CA939@columbia.sparta.com> References: <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020702081612.04a49dc8@mira-sjc5-6.cisco.com> <3D21D287.8B0CA939@columbia.sparta.com> Date: Tue, 2 Jul 2002 12:38:52 -0400 To: Andrea Colegrove From: Stephen Kent Subject: Re: new version of ESP ID Cc: Mark Baugher , ipsec@lists.tislabs.com, msec@securemulticast.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:19 PM -0400 7/2/02, Andrea Colegrove wrote: >Mark and Steve, > I agree that if only one sender is authorized than that sender should be >indicated in the SA as policy that must be adhered to. This should not cause >one to disallow multiple senders sharing an SA. The policy rule must be >flexible enough to allow an entity, a list, a rule, a wildcard, etc. to cover >all multicast scenarios. It would be a shame to break future advanced >multicast uses. > I agree with Annalies that anti-replay is still a problem. We all >acknowledged that several years ago in smug. We also discussed the SPI >collision problem at that time. The probability that two sender-specific SAs >would be assigned the same SPI in the same destination (multicast) address >space is rather slim. Do you anticipate using different group keys >for each of >those SAs? > >--- Andrea Andrea, The current facilities in 2401 do not mandate support for lists of IP addresses for an SA, although that is a feature we plan to put in 2401bis. So, relative to current standards, there is no way to associate a list of authorized senders for a single SA. You can specify a single address, a range of addresses, or allow any address, but not an enumerated list. (This was a feature in the ID that was deleted before we went to RFC, to match what IKE could negotiate.) Every SA nominally has a different set of keys, and that's what IKE, IKE v2, and JFK provide. However one could imagine a key management protocol which created multiple SAs with a common key, e.g., for the purposes you cite here. However, I would not expect Ipsec to treat such SAs specially, e.g., to know that the keys are common and thus to svae state space as a result. In any case, we have always required that SPI assignment be coordinated for all parties using the same multicast address. This is essential for the reasons I cited in my recent, previous message. Thus I do not understand the notion of SPI collisions relative to a single multicast address, irrespective of whether there is one sender or multiple senders. Steve From owner-ipsec@lists.tislabs.com Tue Jul 2 10:32:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62HWPw01225; Tue, 2 Jul 2002 10:32:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14487 Tue, 2 Jul 2002 12:36:32 -0400 (EDT) Message-ID: <3D21D9AB.6070605@speakeasy.net> Date: Tue, 02 Jul 2002 09:49:47 -0700 From: Sankar Ramanoorthi User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020206 X-Accept-Language: en-us MIME-Version: 1.0 To: andrew.krywaniuk@alcatel.com CC: "'list'" Subject: Re: SOI QUESTIONS: 3.4 - 4.3 References: <001e01c22193$e56b5180$f86ce640@ca.alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Help me understand this assertion. Don't keepalive offer a listener a steady stream of resonably predicatble data for the duration of the IKE-SA's lifetime? Does it increase the possibility of IKE SA being compromised? If that possibility exists the value of PFS is lost since ipsec SA's are now open for man-in-the middle attack - right? Thanks, -- sankar ramamoorthi (sankarr@juniper.net) -- Andrew Krywaniuk wrote: >Keepalive messages do not contain any secret information so PFS is not >important. > >Andrew >------------------------------------------- >There are no rules, only regulations. Luckily, >history has shown that with time, hard work, >and lots of love, anyone can be a technocrat. > > > >>-----Original Message----- >>From: Sankar Ramanoorthi [mailto:sankar@speakeasy.net] >>Sent: Monday, July 01, 2002 11:01 PM >>To: andrew.krywaniuk@alcatel.com >>Cc: 'list' >>Subject: Re: SOI QUESTIONS: 3.4 - 4.3 >> >> >>Hi, >> >>I was asking about PFS for keepalive messages - I was >>assuming these are >>sent as notification messages using IKE SA. >> >>-- sankar ramamoorthi (sankarr@juniper.net) -- >> >> >>Andrew Krywaniuk wrote: >> >>>>If phase1 SA is used as the control channel for keep-alive messages, >>>>what are the implications with regard to PFS? That is, if >>>> >>PFS is used >> >>>>to rekey the ipsec session key after an interval for >>>>perfect-forward-secrecy, is it okay to continue using the phase1 SA >>>>for keep alive packets with out worrying about PFS? >>>> >>>If the phase 2 is rekeyed using PFS as defined in IKEv1, >>> >>where the new DH >> >>>key is deleted immediately, then you obviously get full PFS >>> >>of the second >> >>>kind. >>> >>>If you were using the type of rekeying I was suggesting >>> >>earlier, where the >> >>>new DH key is reused across multiple phase 2s and then >>> >>deleted after a fixed >> >>>interval, you still get PFS of the second kind to within >>> >>your PFS interval. >> >>>Andrew >>>------------------------------------------- >>>There are no rules, only regulations. Luckily, >>>history has shown that with time, hard work, >>>and lots of love, anyone can be a technocrat. >>> >>> >>> >>> >> >> > > > From owner-ipsec@lists.tislabs.com Tue Jul 2 10:42:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62HgFw01813; Tue, 2 Jul 2002 10:42:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14537 Tue, 2 Jul 2002 12:56:30 -0400 (EDT) Message-ID: <3D21DEB8.CF254EC1@columbia.sparta.com> Date: Tue, 02 Jul 2002 13:11:20 -0400 From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: Mark Baugher , ipsec@lists.tislabs.com, msec@securemulticast.org Subject: Re: new version of ESP ID References: <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020702081612.04a49dc8@mira-sjc5-6.cisco.com> <3D21D287.8B0CA939@columbia.sparta.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > Andrea, > > The current facilities in 2401 do not mandate support for lists of IP > addresses for an SA, although that is a feature we plan to put in > 2401bis. So, relative to current standards, there is no way to > associate a list of authorized senders for a single SA. You can > specify a single address, a range of addresses, or allow any address, > but not an enumerated list. (This was a feature in the ID that was > deleted before we went to RFC, to match what IKE could negotiate.) > Could the opaque value be used and decoded only by multicast aware versions? Or is general name flexible enough? Are there plans to expand the SPD facility to support more generic policy, as well? It appears that while RFC 2401 designates IKE as the default security management mechanism, allowing others, as a "MAY", multiple management mechanisms may be needed for different uses. (e.g., IKEv2 for gateways, JFK for small mobile devices, gdoi for single source multicast groups, KMI for government, etc.) These mechanisms may also have different policy needs. For example, GDOI might want to check that it has received out-of-band, a group policy token that is valid before proceeding to key distribution. It would probably be important to show that the correct management mechanism is selected according to policy and that the security operating assumptions for each is met. > > Every SA nominally has a different set of keys, and that's what IKE, > IKE v2, and JFK provide. However one could imagine a key management > protocol which created multiple SAs with a common key, e.g., for the > purposes you cite here. However, > I would not expect Ipsec to treat such SAs specially, e.g., to know > that the keys are common and thus to svae state space as a result. > > In any case, we have always required that SPI assignment be > coordinated for all parties using the same multicast address. This is > essential for the reasons I cited in my recent, previous message. > Thus I do not understand the notion of SPI collisions relative to a > single multicast address, irrespective of whether there is one sender > or multiple senders. > > Steve My thought was that if a lack of coordination did exist and if a collision did occur (two BIG ifs), then separate keys would cause decryption errors. A management channel could then rekey, including the SPI. --- Andrea From owner-ipsec@lists.tislabs.com Tue Jul 2 10:42:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62HgHw01825; Tue, 2 Jul 2002 10:42:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14531 Tue, 2 Jul 2002 12:55:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 2 Jul 2002 13:01:18 -0400 To: annelies.van_moffaert@alcatel.be From: Stephen Kent Subject: Re: [MSEC] Re: new version of ESP ID Cc: ipsec@lists.tislabs.com, msec@securemulticast.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:09 PM +0200 7/2/02, annelies.van_moffaert@alcatel.be wrote: >Mark and Steve, > >I am not sure I completely understand your arguments. I would think that >there is a difference between saying that >1. IPsec can only be used to protect SSM or single-source multicast groups >and >2. When using IPsec to protect multicast traffic one should use a seperate >SA per sender. > >In the second case there can be more than 1 sender allowed to send to the >same group. Both legitimate senders and receivers should then e.g. >authenticate to a common key server and the key server could create for >each sender a seperate SA. Additionally the key server would push the SAs >to the group of receivers. The second case would be consistent with the IPsec architecture. The common key server needs to assign the SPIs uniquely for the multicast group as well as provide keys to the group members. In this model, each SA has just one authorized sender and so anti-replay can be employed, and each receiver can use the SPD to constrain the source address appropriately. But, the granularity of the source authentication is still just the group, since each receiver also could send traffic claiming to be from the authorized sender. >A concrete example could be hosts that all send IGMP messages to the group >address to which all IGMP capable routers listen or PIM routers that all >send PIM messages to the PIM group address. It could also be a multicast >data service with more than one legitimate source (all sources should then >probably be under the control of a single key server). > >Do you have scenario 1 in mind or scenario 2 or again something else? > > >A second question I have relates to the statement that "the receiver SHALL >check the source address to ensure that it is from the authorized sender". >Isn't this a weak check given that a source address can be spoofed by a >receiver who wants to impersonate the sender? It is effective for unicast SAs, but it is a less effective control for multicast SAs, in so far as any multicast group member has the requisite key material to spoof. However I do not envision changing this general requirement to special case multicast SAs. As noted earlier, if you don't feel that the check is really useful in the multicast context, you can set the source address to be * for these SAs. >Mark explained correctly my concern related to colliding SPI values when >independent group controllers manage SAs for the same destination address. >Thanks! ;-) I think this problem could be solved by adding the source >address to the triplet (SPI, protocol, dest IP addr). What problem? We still require coordination for SPI management on a per multicast group address basis, so if you want to create multiple SAs for the multicast group, one per sender, why not use SPIs for this purpose. I am hesitant, to say the least, to impose a new, additional burden on all IPsec implementations to use sources addresses for demuxing, when the same effect can be achieved using the SPI. Steve From owner-ipsec@lists.tislabs.com Tue Jul 2 11:03:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62I3Iw02961; Tue, 2 Jul 2002 11:03:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14600 Tue, 2 Jul 2002 13:20:46 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> References: <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> Date: Mon, 1 Jul 2002 17:07:34 -0400 To: Mark Baugher From: Stephen Kent Subject: Re: new version of ESP ID Cc: ipsec@lists.tislabs.com, msec@securemulticast.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, >Karen, Steve, >At 06:55 PM 6/28/2002 -0400, Karen Seo wrote: >> >> >>A question was posed to the working group (6/17) as to whether to >>change the SA demuxing values to allow use of the Source IP address >>for source-specific multicast protocols. There has been no feedback >>so far so no changes were made. > >I missed the 6/17 note. I have a few comments on use of the source >IP address for source-specific multicast. > >First, section 2.2 deprecates sharing an SA among multiple senders >to a multicast group and in effect mandates single-sender multicast >for ESP groups. The same is true for AH. I'm aware of only one >protocol, the VRRP specification, that is affected by this change. >VRRP uses AH or ESP but allows multi-source multicast groups. We >should notify the VRRP WG of this potential change. OK. >Second, I think there is an inconsistency between 2.2 and 3.4.2 in >that 2.2 disallows sharing of an SA among multiple senders and 3.4.2 >states that anti-replay SHOULD NOT be used in a multi-sender >environment. Doesn't the first restriction obviate the need for the >second? Good point. We carried over the text without thinking through the implications of the previous change. >Finally, If we are going to restrict a multicast SA to single-source >multicast groups, then I don't understand how we can avoid >identifying associating that sender with the SA. If a member of the >single-source multicast group who is not the authorized sender >begins sending to that group, there is no way to identify this >problem, which will likely break the anti-replay mechanism. The SA for a single-sender, multicast SA should specify the address of the one, authorized sender and that would be checked by each receiver. This is separate from the fact that the IP source address is not (and never has been) used in selecting the SA for inbound traffic, i.e., it is the destination address and the SPI that are used for that demuxing. Steve From owner-ipsec@lists.tislabs.com Tue Jul 2 11:05:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62I5Sw03115; Tue, 2 Jul 2002 11:05:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14588 Tue, 2 Jul 2002 13:16:42 -0400 (EDT) Date: Tue, 2 Jul 2002 13:30:09 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SOI QUESTIONS: 3.4 - 4.3 In-Reply-To: <3D21D9AB.6070605@speakeasy.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 2 Jul 2002, Sankar Ramanoorthi wrote: > ...Don't keepalive offer a listener a > steady stream of resonably predicatble data for the duration of the > IKE-SA's lifetime? Only if one implements timed keepalives (as opposed to querying the other end only when there is reason to suspect it might be down). > Does it increase the possibility of IKE SA being compromised? It shouldn't. A *lot* of the IKE SA traffic is quite predictable. And one should not be protecting an IKE SA with a cipher that is seriously vulnerable to known-plaintext attacks (e.g., 1DES). Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Jul 2 11:05:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62I5iw03143; Tue, 2 Jul 2002 11:05:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14613 Tue, 2 Jul 2002 13:22:47 -0400 (EDT) Message-ID: <00c101c221c2$a9cd6ee0$0b00a8c0@BGABAYT20> From: "Benzy Gabay" To: Subject: question about re-keys Date: Tue, 2 Jul 2002 14:19:07 +0200 Organization: Maya Software Technologies Ltd. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00BE_01C221D3.6D178830" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00BE_01C221D3.6D178830 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit Clear DayHello, I'm not sure if this is the right place to post this question but here goes. I'm building a VPN client against CISCO VPN gateway (model 3000). I would like to know if the CISCO VPN should send a delete SA notification for any SA has finished. Let me remind that it happens both if there is a new tunnel (after re-key) and also if there was no re-key. Thanks Dana && Benzy ------=_NextPart_000_00BE_01C221D3.6D178830 Content-Type: text/x-vcard; name="Benzy Gabay.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Benzy Gabay.vcf" BEGIN:VCARD VERSION:2.1 N:Gabay;Ben;Zion;Mr. FN:Benzy Gabay NICKNAME:Blabber ORG:Maya Software Technologies;R&D, IPSec TITLE:Senior software developer TEL;WORK;VOICE:+972-9-956-0135 TEL;CELL;VOICE:+972-55-559248 TEL;WORK;FAX:+972-9-955-9654 ADR;WORK:;+972-9-956-0135;6 Galgalei Haplada, POB = 12899;Herzelia;;46733;Israel LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:+972-9-956-0135=3D0D=3D0A6 = Galgalei Haplada, POB 12899=3D0D=3D0AHerzelia 46733=3D0D=3D =3D0AIsrael ADR;HOME:;;;Tel-Aviv;;64511;Israel LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:Tel-Aviv 64511=3D0D=3D0AIsrael X-WAB-GENDER:2 URL;WORK:http://www.maya-st.com BDAY:19710119 EMAIL;PREF;INTERNET:bgabay@maya-st.com EMAIL;INTERNET:benzyg@hotmail.com REV:20020702T121906Z END:VCARD ------=_NextPart_000_00BE_01C221D3.6D178830-- From owner-ipsec@lists.tislabs.com Tue Jul 2 11:39:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62Idow05204; Tue, 2 Jul 2002 11:39:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14805 Tue, 2 Jul 2002 13:55:15 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3D21DEB8.CF254EC1@columbia.sparta.com> References: <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020702081612.04a49dc8@mira-sjc5-6.cisco.com> <3D21D287.8B0CA939@columbia.sparta.com> <3D21DEB8.CF254EC1@columbia.sparta.com> Date: Tue, 2 Jul 2002 14:04:25 -0400 To: Andrea Colegrove From: Stephen Kent Subject: Re: new version of ESP ID Cc: ipsec@lists.tislabs.com, msec@securemulticast.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:11 PM -0400 7/2/02, Andrea Colegrove wrote: >Stephen Kent wrote: > >> >> Andrea, >> >> The current facilities in 2401 do not mandate support for lists of IP >> addresses for an SA, although that is a feature we plan to put in >> 2401bis. So, relative to current standards, there is no way to >> associate a list of authorized senders for a single SA. You can >> specify a single address, a range of addresses, or allow any address, >> but not an enumerated list. (This was a feature in the ID that was >> deleted before we went to RFC, to match what IKE could negotiate.) >> > >Could the opaque value be used and decoded only by multicast aware >versions? Or >is general name flexible enough? Symbolic names in the SPD for S/D IP address selectors are mapped into specific addresses when an SA is established, so I don't know what you have in mind here. "Opaque" applies to port fields, but not IP addresses. (The text in 2401 is not clear enough about this, just as it needs to improve re the discussion of how symbolic names are used.) > >Are there plans to expand the SPD facility to support more generic policy, as >well? It appears that while RFC 2401 designates IKE as the default security >management mechanism, allowing others, as a "MAY", multiple >management mechanisms >may be needed for different uses. (e.g., IKEv2 for gateways, JFK for >small mobile >devices, gdoi for single source multicast groups, KMI for >government, etc.) These >mechanisms may also have different policy needs. For example, GDOI >might want to >check that it has received out-of-band, a group policy token that is >valid before >proceeding to key distribution. It would probably be important to >show that the >correct management mechanism is selected according to policy and >that the security >operating assumptions for each is met. IKEv2 and JFK are competing replacements for IKE v1. I don't see the split you allude to above, i.e., I expect the WG to select one replacement, because the choice affects not only the local device, but also any device with which it communicates. So a I can't have one protocol for security gateways and another for small, mobile devices, if these devices ever want to communicate with a computer behind a security gateway, for example. Nonetheless, your question is relevant. There is a distinction between what 2401 will mandate in terms of SPD capabilities, and what any key/SA management protocol provides. I think it is reasonable for IPsec to be able to use more than one key/SA management protocol, but the SPD should be uniform and the protocols should support what the SPD allows users to express. The concern I have re support of multicast is any imposition of new requirements on the "fast path" processing required of all IPsec implementations. As more of these move into hardware, to accommodate higher speeds, we cannot easily make changes on things such as SA demuxing without severely affecting this hardware. > > Every SA nominally has a different set of keys, and that's what IKE, > > IKE v2, and JFK provide. However one could imagine a key management >> protocol which created multiple SAs with a common key, e.g., for the >> purposes you cite here. However, >> I would not expect Ipsec to treat such SAs specially, e.g., to know >> that the keys are common and thus to svae state space as a result. >> >> In any case, we have always required that SPI assignment be >> coordinated for all parties using the same multicast address. This is >> essential for the reasons I cited in my recent, previous message. >> Thus I do not understand the notion of SPI collisions relative to a >> single multicast address, irrespective of whether there is one sender >> or multiple senders. >> >> Steve > >My thought was that if a lack of coordination did exist and if a collision did >occur (two BIG ifs), then separate keys would cause decryption errors. A >management channel could then rekey, including the SPI. I would like to continue with the assumption that the SPIs MUST be managed in a coordinated fashion for each, individual multicast group. A failure to coordinate will fail secure, which is the highest priority for IPsec, and hopefully the failure will allow affected subscribers to invoke management mecahnsisms to fix the problem. Steve From owner-ipsec@lists.tislabs.com Tue Jul 2 12:18:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62JIaw07448; Tue, 2 Jul 2002 12:18:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15017 Tue, 2 Jul 2002 14:39:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20020702095523.04a39ef8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 02 Jul 2002 11:48:52 -0700 To: From: Mark Baugher Subject: Re: [MSEC] Re: new version of ESP ID Cc: ipsec@lists.tislabs.com, msec@securemulticast.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Annalies, At 06:09 PM 7/2/2002 +0200, annelies.van_moffaert@alcatel.be wrote: >Mark and Steve, > >I am not sure I completely understand your arguments. I would think that >there is a difference between saying that >1. IPsec can only be used to protect SSM or single-source multicast groups >and >2. When using IPsec to protect multicast traffic one should use a seperate >SA per sender. > >In the second case there can be more than 1 sender allowed to send to the >same group. Both legitimate senders and receivers should then e.g. >authenticate to a common key server and the key server could create for >each sender a seperate SA. Additionally the key server would push the SAs >to the group of receivers. I think we need to introduce the constraint that one and only one controller or key server will establish SAs for a given multicast address for all multicast applications, or we would need to constrain multicast SAs to apply to SSM only. The latter seems to be a more robust approach to me. Sorry if I have not been clear about this. So, although the correct answer to your question is #2, #1 ensures that we won't have an SPI collision in the absence of a single controller per multicast group. It's true that a collision of SPIs is unlikely _if they are random_, but the SPI is not required to be random. Besides that, I think we want to avoid even unlikely failures. >A concrete example could be hosts that all send IGMP messages to the group >address to which all IGMP capable routers listen or PIM routers that all >send PIM messages to the PIM group address. It could also be a multicast >data service with more than one legitimate source (all sources should then >probably be under the control of a single key server). > >Do you have scenario 1 in mind or scenario 2 or again something else? > > >A second question I have relates to the statement that "the receiver SHALL >check the source address to ensure that it is from the authorized sender". >Isn't this a weak check given that a source address can be spoofed by a >receiver who wants to impersonate the sender? Yes, but this is always true since we use an HMAC for message authentication in IPsec rather than a digital signature. We must assume that group members are trusted not to impersonate one another. Otherwise IPsec message authentication is not secure. The sender check by the receiver protects the receiver from cases where some member is not impersonating an authorized sender, e.g. in a faulty implementation. Mark >Mark explained correctly my concern related to colliding SPI values when >independent group controllers manage SAs for the same destination address. >Thanks! ;-) I think this problem could be solved by adding the source >address to the triplet (SPI, protocol, dest IP addr). > >Kind regards, Lies. > > > > > > > >Mark Baugher @securemulticast.org on 02/07/2002 >17:30:35 > >Sent by: msec-admin@securemulticast.org > > >To: Stephen Kent >cc: ipsec@lists.tislabs.com, msec@securemulticast.org >Subject: [MSEC] Re: new version of ESP ID > > >Steve, > >At 05:07 PM 7/1/2002 -0400, Stephen Kent wrote: > > > > >>Finally, If we are going to restrict a multicast SA to single-source > >>multicast groups, then I don't understand how we can avoid identifying > >>associating that sender with the SA. If a member of the single-source > >>multicast group who is not the authorized sender begins sending to that > >>group, there is no way to identify this problem, which will likely break > >>the anti-replay mechanism. > > > > The SA for a single-sender, multicast SA should specify the address of > > the one, authorized sender and that would be checked by each receiver. > >I'm okay with this. It limits us strictly to single-sender multicast >groups. Given the complexities of multicast security, that's probably the >best approach at least for the near term. Shouldn't we document this >constraint in the ESP (and AH) I-Ds? That is, the receiver SHALL check the >source address of a received packet to ensure that it is from the >authorized sender for the particular SA? > > > >This is separate from the fact that the IP source address is not (and > >never has been) used in selecting the SA for inbound traffic, i.e., it is > >the destination address and the SPI that are used for that demuxing. > >Yes, and this is consistent with what RFC 2401 says: "The concept is >applicable in the point-to-multipoint case as well." We disallow having >multiple senders share an SA. Annalies point was (if I understand her >correctly) that we cannot have multiple SAs for a particular multicast >destination address because the SPIs might collide. The SPIs might collide >if different group controllers assign them independently. Do you agree? > >Mark > > > >Steve > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec From owner-ipsec@lists.tislabs.com Tue Jul 2 12:19:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62JJ5w07485; Tue, 2 Jul 2002 12:19:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14998 Tue, 2 Jul 2002 14:33:10 -0400 (EDT) Message-ID: <3D21F566.94EBB6C8@columbia.sparta.com> Date: Tue, 02 Jul 2002 14:48:06 -0400 From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com, msec@securemulticast.org Subject: Re: new version of ESP ID References: <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020702081612.04a49dc8@mira-sjc5-6.cisco.com> <3D21D287.8B0CA939@columbia.sparta.com> <3D21DEB8.CF254EC1@columbia.sparta.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, Stephen Kent wrote: > > > >Are there plans to expand the SPD facility to support more generic policy, as > >well? It appears that while RFC 2401 designates IKE as the default security > >management mechanism, allowing others, as a "MAY", multiple > >management mechanisms > >may be needed for different uses. (e.g., IKEv2 for gateways, JFK for > >small mobile > >devices, gdoi for single source multicast groups, KMI for > >government, etc.) These > >mechanisms may also have different policy needs. For example, GDOI > >might want to > >check that it has received out-of-band, a group policy token that is > >valid before > >proceeding to key distribution. It would probably be important to > >show that the > >correct management mechanism is selected according to policy and > >that the security > >operating assumptions for each is met. > > IKEv2 and JFK are competing replacements for IKE v1. I don't see the > split you allude to above, i.e., I expect the WG to select one > replacement, because the choice affects not only the local device, > but also any device with which it communicates. So a I can't have one > protocol for security gateways and another for small, mobile devices, > if these devices ever want to communicate with a computer behind a > security gateway, for example. > > Nonetheless, your question is relevant. There is a distinction > between what 2401 will mandate in terms of SPD capabilities, and what > any key/SA management protocol provides. I think it is reasonable for > IPsec to be able to use more than one key/SA management protocol, but > the SPD should be uniform and the protocols should support what the > SPD allows users to express. The concern I have re support of > multicast is any imposition of new requirements on the "fast path" > processing required of all IPsec implementations. As more of these > move into hardware, to accommodate higher speeds, we cannot easily > make changes on things such as SA demuxing without severely affecting > this hardware. Re: IKEv2 and JFK -- a couple of recent postings have mentioned the use of both. But, yes, I agree it would be an interoperability nightmare. Nevertheless, even the different domains of pairwise dynamic keying, single-source multicast, multi-sender multicast, pre-placed (if it survives) update management, and centralized keying, all have slightly different needs for the SPD. I would suspect that unless the policy issues were pushed up to the application layer, that the SPD will need to have a flexible format for any implementation. Indeed, I would suspect that for management purposes, it would even make sense in the future to take on standardized approaches for remote management of SPDs. (2401-bis). This complexity probably does fly in the face of the simplicity needed for high speed applications. --- Andrea From owner-ipsec@lists.tislabs.com Tue Jul 2 12:34:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62JYKw08186; Tue, 2 Jul 2002 12:34:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15049 Tue, 2 Jul 2002 14:54:13 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3D21F566.94EBB6C8@columbia.sparta.com> References: <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020702081612.04a49dc8@mira-sjc5-6.cisco.com> <3D21D287.8B0CA939@columbia.sparta.com> <3D21DEB8.CF254EC1@columbia.sparta.com> <3D21F566.94EBB6C8@columbia.sparta.com> Date: Tue, 2 Jul 2002 15:02:35 -0400 To: Andrea Colegrove From: Stephen Kent Subject: Re: new version of ESP ID Cc: ipsec@lists.tislabs.com, msec@securemulticast.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:48 PM -0400 7/2/02, Andrea Colegrove wrote: >Re: IKEv2 and JFK -- a couple of recent postings have mentioned the >use of both. >But, yes, I agree it would be an interoperability nightmare. > >Nevertheless, even the different domains of pairwise dynamic keying, >single-source >multicast, multi-sender multicast, pre-placed (if it survives) >update management, >and centralized keying, all have slightly different needs for the >SPD. I would >suspect that unless the policy issues were pushed up to the >application layer, that >the SPD will need to have a flexible format for any implementation. Indeed, I >would suspect that for management purposes, it would even make sense >in the future >to take on standardized approaches for remote management of SPDs. (2401-bis). > >This complexity probably does fly in the face of the simplicity >needed for high >speed applications. > >--- Andrea I think your final sentence is most telling. The changes we are anticipating for the SPD, in terms of selectors, are consistent with the excellent suggestion incorporated in JFK, and picked up by IKE v2, i.e., the uniform treatment for expressing concrete values (vs. symbolic names) for for address, port fields, and the protocol field. This already adds some complexity, but not as much as I think you may be suggesting for MSM. We can handle SSM with our current scheme, and since we don't know how to deal with various other IPsec problems in MSM (if we try to map an MSM group to a single SA), I think that hard case will be deferred for 2401bis. Steve From owner-ipsec@lists.tislabs.com Tue Jul 2 12:42:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62Jg8w08448; Tue, 2 Jul 2002 12:42:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15042 Tue, 2 Jul 2002 14:51:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20020702115642.04d72fa8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 02 Jul 2002 12:01:50 -0700 To: Markku Savela From: Mark Baugher Subject: Re: identifying IPsec SAs (was Re: IPsec AH and ESP I-Ds; source address as possible SA selector for multicast SA? Cc: ipsec@lists.tislabs.com In-Reply-To: <200207021557.SAA02464@burp.tkv.asdf.org> References: <4.3.2.7.2.20020702080307.04d2def8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020701102526.04b8f538@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020701102526.04b8f538@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020702080307.04d2def8@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Markku, I may be misunderstanding something about IPsec. By my reading of RFC 2401, the SA is uniquely identified by and it is not possible to install another SA having the same triple but with a different source address based upon some SPD entry. Mark At 06:57 PM 7/2/2002 +0300, Markku Savela wrote: > > From: Mark Baugher > > Cc: annelies.van_moffaert@alcatel.be, ipsec@lists.tislabs.com > > Content-Type: text/plain; charset="us-ascii"; format=flowed > > > > At 11:25 PM 7/1/2002 +0300, Markku Savela wrote: > > > > From: Mark Baugher > > > > > > > >I think a good solution would be to include also the source > address in the > > > > >SA selector for multicast SAs. This would also be very useful to > protect > > > > >IGMP messages by means of IPsec AH. > > > > > > > > I favor this approach but it is not consistent with RFC2401. > > > > > >Nothing in RFC2401 prevents using source address as a selector. > > > > Annalies used the term "selector," I didn't. I wasn't referring to the > SPD > > and how packets are selected for IPsec processing but rather how an SA is > > identified. Section 4.1 of RFC 2401 says that an IPsec SA is uniquely > > identified by the triple . > >Yes, , but then SA is supposed to include >additional parameters (as per RFC 2401) which are used to distinguish >between different SA's. One of those parameters is the source address >(other paramters are the ports and transport protocol). > >We could have multiple SA's with same destination (= multicast group), >with different source address. > >The proposed IKEv2 TS payload almost gets it, but there may be some >confusion about two "source addresses": (1) the source address of >the IPSEC node and (2) the source address of the original packet. > >However, as IKEv2 may not be relevant here (for negotiating multicast >SA's), this may not be an issue? From owner-ipsec@lists.tislabs.com Tue Jul 2 13:04:03 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62K42w09564; Tue, 2 Jul 2002 13:04:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15150 Tue, 2 Jul 2002 15:21:34 -0400 (EDT) Date: Tue, 2 Jul 2002 22:34:26 +0300 Message-Id: <200207021934.WAA02887@burp.tkv.asdf.org> From: Markku Savela To: mbaugher@cisco.com CC: ipsec@lists.tislabs.com In-reply-to: <4.3.2.7.2.20020702115642.04d72fa8@mira-sjc5-6.cisco.com> (message from Mark Baugher on Tue, 02 Jul 2002 12:01:50 -0700) Subject: Re: identifying IPsec SAs (was Re: IPsec AH and ESP I-Ds; source address as possible SA selector for multicast SA? References: <4.3.2.7.2.20020702080307.04d2def8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020701102526.04b8f538@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020701102526.04b8f538@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020702080307.04d2def8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020702115642.04d72fa8@mira-sjc5-6.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Mark Baugher > I may be misunderstanding something about IPsec. By my reading of RFC > 2401, the SA is uniquely identified by protocol> and it is not possible to install another SA having the same > triple but with a different source address based upon some SPD entry. I also (same Stephen Kent) assumed that there must be some entity that is responsible of actually creating and distributing the SA's for a specific multicast group, and therefore also assigns unique SPI for each SA. From owner-ipsec@lists.tislabs.com Tue Jul 2 14:21:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g62LLow16311; Tue, 2 Jul 2002 14:21:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15269 Tue, 2 Jul 2002 16:41:05 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15650.4893.673982.271999@pkoning.dev.equallogic.com> Date: Tue, 2 Jul 2002 16:54:53 -0400 From: Paul Koning To: mbaugher@cisco.com Cc: msa@burp.tkv.asdf.org, ipsec@lists.tislabs.com Subject: Re: identifying IPsec SAs (was Re: IPsec AH and ESP I-Ds; source address as possible SA selector for multicast SA? References: <4.3.2.7.2.20020702080307.04d2def8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020701102526.04b8f538@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020702115642.04d72fa8@mira-sjc5-6.cisco.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Mark" == Mark Baugher writes: Mark> Markku, I may be misunderstanding something about IPsec. By my Mark> reading of RFC 2401, the SA is uniquely identified by destination address, IPsec protocol> and it is not possible to install another SA having the protocol> same Mark> triple but with a different source address based upon some SPD Mark> entry. That's my reading as well. Mark> Mark At 06:57 PM 7/2/2002 +0300, Markku Savela wrote: >> Yes, , but then SA is supposed to >> include additional parameters (as per RFC 2401) which are used to >> distinguish between different SA's. One of those parameters is the >> source address (other paramters are the ports and transport >> protocol). >> >> We could have multiple SA's with same destination (= multicast >> group), with different source address. I don't see how that can be valid. Yes, once you find a particular SA, you then have a security policy that describes checks on source address, and lots of other things. But that's a filter, NOT a demultiplexing operation. paul From owner-ipsec@lists.tislabs.com Tue Jul 2 19:39:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g632dpw04434; Tue, 2 Jul 2002 19:39:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA15659 Tue, 2 Jul 2002 21:47:50 -0400 (EDT) MBOX-Line: From owner-ipsec@lists.tislabs.com Tue Jul 02 17:38:44 2002 From: annelies.van_moffaert@alcatel.be Subject: Re: [MSEC] Re: new version of ESP ID To: Mark Baugher Cc: Stephen Kent , ipsec@lists.tislabs.com, msec@securemulticast.org Date: Tue, 2 Jul 2002 18:09:11 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 07/02/2002 18:09:12 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark and Steve, I am not sure I completely understand your arguments. I would think that there is a difference between saying that 1. IPsec can only be used to protect SSM or single-source multicast groups and 2. When using IPsec to protect multicast traffic one should use a seperate SA per sender. In the second case there can be more than 1 sender allowed to send to the same group. Both legitimate senders and receivers should then e.g. authenticate to a common key server and the key server could create for each sender a seperate SA. Additionally the key server would push the SAs to the group of receivers. A concrete example could be hosts that all send IGMP messages to the group address to which all IGMP capable routers listen or PIM routers that all send PIM messages to the PIM group address. It could also be a multicast data service with more than one legitimate source (all sources should then probably be under the control of a single key server). Do you have scenario 1 in mind or scenario 2 or again something else? A second question I have relates to the statement that "the receiver SHALL check the source address to ensure that it is from the authorized sender". Isn't this a weak check given that a source address can be spoofed by a receiver who wants to impersonate the sender? Mark explained correctly my concern related to colliding SPI values when independent group controllers manage SAs for the same destination address. Thanks! ;-) I think this problem could be solved by adding the source address to the triplet (SPI, protocol, dest IP addr). Kind regards, Lies. Mark Baugher @securemulticast.org on 02/07/2002 17:30:35 Sent by: msec-admin@securemulticast.org To: Stephen Kent cc: ipsec@lists.tislabs.com, msec@securemulticast.org Subject: [MSEC] Re: new version of ESP ID Steve, At 05:07 PM 7/1/2002 -0400, Stephen Kent wrote: >>Finally, If we are going to restrict a multicast SA to single-source >>multicast groups, then I don't understand how we can avoid identifying >>associating that sender with the SA. If a member of the single-source >>multicast group who is not the authorized sender begins sending to that >>group, there is no way to identify this problem, which will likely break >>the anti-replay mechanism. > > The SA for a single-sender, multicast SA should specify the address of > the one, authorized sender and that would be checked by each receiver. I'm okay with this. It limits us strictly to single-sender multicast groups. Given the complexities of multicast security, that's probably the best approach at least for the near term. Shouldn't we document this constraint in the ESP (and AH) I-Ds? That is, the receiver SHALL check the source address of a received packet to ensure that it is from the authorized sender for the particular SA? >This is separate from the fact that the IP source address is not (and >never has been) used in selecting the SA for inbound traffic, i.e., it is >the destination address and the SPI that are used for that demuxing. Yes, and this is consistent with what RFC 2401 says: "The concept is applicable in the point-to-multipoint case as well." We disallow having multiple senders share an SA. Annalies point was (if I understand her correctly) that we cannot have multiple SAs for a particular multicast destination address because the SPIs might collide. The SPIs might collide if different group controllers assign them independently. Do you agree? Mark >Steve _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From owner-ipsec@lists.tislabs.com Wed Jul 3 06:40:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g63DeFw18372; Wed, 3 Jul 2002 06:40:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16626 Wed, 3 Jul 2002 08:43:51 -0400 (EDT) Message-Id: <200207031027.GAA03277@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-v3-03.txt Date: Wed, 03 Jul 2002 06:27:53 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent Filename : draft-ietf-ipsec-esp-v3-03.txt Pages : 41 Date : 02-Jul-02 This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and Ipv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document is based upon RFC 2406 (November 1998). Section 7 provides a brief review of the differences between this document and RFC 2406. Comments should be sent to Stephen Kent (kent@bbn.com). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-ipsec-esp-v3-03.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-ietf-ipsec-esp-v3-03.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020702150955.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v3-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v3-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020702150955.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Jul 3 06:42:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g63Dgnw18444; Wed, 3 Jul 2002 06:42:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16632 Wed, 3 Jul 2002 08:44:51 -0400 (EDT) Message-Id: <200207031027.GAA03263@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-rfc2402bis-01.txt Date: Wed, 03 Jul 2002 06:27:46 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Authentication Header Author(s) : S. Kent Filename : draft-ietf-ipsec-rfc2402bis-01.txt Pages : 30 Date : 02-Jul-02 This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document is based upon RFC 2402 (November 1998) [KA98c]. Section 7 provides a brief review of the differences between this document and RFC 2402. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-ipsec-rfc2402bis-01.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-ietf-ipsec-rfc2402bis-01.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020702150946.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-rfc2402bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020702150946.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Jul 3 06:57:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g63DvOw18833; Wed, 3 Jul 2002 06:57:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16699 Wed, 3 Jul 2002 09:13:00 -0400 (EDT) Date: Wed, 3 Jul 2002 15:26:27 +0200 (MET DST) Message-Id: <200207031326.PAA27596@hugo.int-evry.fr> From: Jean-Jacques Puig To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 4.1 Control channel vs. separate protocols In-Reply-To: References: Organization: =?UTF-8?B?RA==?= new, 55 unread, 85 total =?UTF-8?B?KDMxNS5hKQ==?= X-Mailer: Sylpheed version 0.6.1 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 4.1 Control channel vs. separate protocols > > 4.1.A) [Meta question, that will be answered by the other questions in > section 4.] Does SOI need a control channel for SA management? Or is > it acceptable to piggy back SA management as a part of other parts of > the SOI protocol? Setting a control channel seems reasonnable. It may be complex, but management of SAs (multiple SA handling, SAs states...) is a strong requirement, and the use of several protocols will mess it more. However, such a control channel is not necessarily a phase 1 SA, and a consistent approach must be followed concerning the control features on this channel. Are control features listed in 4.1 of SOI features comprehensive enough ? Are there other requirements for SA management ? Does SOI need to be able to tackle with future requirements on this spot at an expense of modularity ? -- Jean-Jacques Puig From owner-ipsec@lists.tislabs.com Wed Jul 3 07:44:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g63Eidw20912; Wed, 3 Jul 2002 07:44:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16804 Wed, 3 Jul 2002 09:58:22 -0400 (EDT) Date: Wed, 3 Jul 2002 16:11:12 +0200 (MET DST) Message-Id: <200207031411.QAA28045@hugo.int-evry.fr> From: Jean-Jacques Puig To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 4.2 Creating multiple SAs for a single pair of entities In-Reply-To: References: Organization: =?UTF-8?B?RA==?= X-Mailer: Sylpheed version 0.6.1 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 4.2 Creating multiple SAs for a single pair of entities > > 4.2.A) How important is it that SOI be able to create multiple SA's > between a pair of entities "cheaply"? QoS may require several SAs between a pair of entities. This would lead to a great usr of SA, most of which would be set up as a bundle by softwares, that is, as an instance, when the OS boots or when the PPP link is up, etc. Initiation of several phase 1 is out of question. Multiple phase 2 exponentiations will be expensive. Thus a cheap way for building multiple SAs is desirable. Anyway, if this feature is available, we can be sure it will be used. > 4.2.B) How often will usage scenarios of SOI need to generate multiple > SA's between a single pair of entites? It is difficult to know at the moment. Secure Remote Access scenarios will have to play it often. VPNs gateways could do it on reboot, but they are more likely to follow the classical 'expensive' way. End To End may have often/sometimes a need for it also. Endpoints tend to switch on and off all the time, and it may be usefull to set up multiple SAs quickly, ex for a soft which does visio and file transfert and will need differents crypto parameters for each. Many applications need multiple channels for differents purposes, cheap SAs building should be relevant for them. > Implications from the Scenarios: > > VPN: << total cost; this will be different for different mechanisms, which > results in a decision of scalability -vs- processing overhead. In > certain cases, it may be desirable to amortize the cost of the key > management across multiple tunnels.>>> [[[4.2]]] > > VPN, End-to-END, SRA : << tunnels between a pair of SGWs. Also, negotiation of IPsec tunnels > needs to accommodate QoS information, predominantly in the set of > selectors used to identify the contents of any particular IPsec > tunnel.>>> [[[4.2]]] > > SRA: << within the SOI exchange, it's strongly encouraged that the protocol > directly or indirectly associate a single user authentication exchange > with a group of IPsec tunnels between a client and an RAS.>>> > [[[4.2]]] > > SRA: << client to present its identity (or some "blob of bits" that the server > can correctly map to an identity) early in the exchange.>>> [[[4.2]]] > -- Jean-Jacques Puig From owner-ipsec@lists.tislabs.com Wed Jul 3 09:55:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g63GtHw28825; Wed, 3 Jul 2002 09:55:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16933 Wed, 3 Jul 2002 12:07:40 -0400 (EDT) Message-ID: <3D232451.3060807@isi.edu> Date: Wed, 03 Jul 2002 09:20:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-rfc2402bis-01.txt References: <200207031027.GAA03263@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Protocol Working Group of the IETF. > > Title : IP Authentication Header > Author(s) : S. Kent > Filename : draft-ietf-ipsec-rfc2402bis-01.txt > Pages : 30 > Date : 02-Jul-02 Hi, all, To start the discussion off, we'd certainly appreciate having section 3.1.2 at least say "MUST use tunnel mode or its equivalent, i.e., transport over 2003-style IP encapsulation". We have raised this issue before; details of why are in draft-touch-ipsec-vpn-03.txt (and we're hoping that 2401bis more directly addresses this issue). Joe From owner-ipsec@lists.tislabs.com Wed Jul 3 11:44:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g63IiOw05322; Wed, 3 Jul 2002 11:44:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17067 Wed, 3 Jul 2002 13:58:30 -0400 (EDT) Message-ID: From: "Paul Knight" To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-rfc2402bis-01.txt Date: Wed, 3 Jul 2002 14:03:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C222BB.E2397400" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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_01C222BB.E2397400 Content-Type: text/plain; charset="iso-8859-1" Hi all, Yes, this is a key issue in supporting dynamic routing inside IPsec-based VPNs. Applying IP-in-IP encapsulation (RFC 2003) before transport mode results in a packet which is the same as tunnel mode (satisfying any security issues), BUT allows routing (i.e., setting the encapsulating destination address to the known next-IPsec-hop) to be handled cleanly. Regards, Paul Knight > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Wednesday, July 03, 2002 12:21 PM > To: ipsec@lists.tislabs.com > Subject: Re: I-D ACTION:draft-ietf-ipsec-rfc2402bis-01.txt > > > Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > This draft is a work item of the IP Security Protocol > Working Group of the IETF. > > > > Title : IP Authentication Header > > Author(s) : S. Kent > > Filename : draft-ietf-ipsec-rfc2402bis-01.txt > > Pages : 30 > > Date : 02-Jul-02 > > Hi, all, > > To start the discussion off, we'd certainly appreciate having section > 3.1.2 at least say "MUST use tunnel mode or its equivalent, i.e., > transport over 2003-style IP encapsulation". > > We have raised this issue before; details of why are in > draft-touch-ipsec-vpn-03.txt > > (and we're hoping that 2401bis more directly addresses this issue). > > Joe > > > ------_=_NextPart_001_01C222BB.E2397400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-ipsec-rfc2402bis-01.txt Hi all, Yes, this is a key issue in supporting dynamic = routing inside IPsec-based VPNs. Applying IP-in-IP encapsulation = (RFC 2003) before transport mode results in a packet which is the same = as tunnel mode (satisfying any security issues), BUT allows routing = (i.e., setting the encapsulating destination address to the known = next-IPsec-hop) to be handled cleanly. Regards, Paul Knight > -----Original Message----- > From: Joe Touch [<3d.htm>mailto:touch@ISI.EDU] > Sent: Wednesday, July 03, 2002 12:21 PM > To: ipsec@lists.tislabs.com > Subject: Re: I-D = ACTION:draft-ietf-ipsec-rfc2402bis-01.txt > > > Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the = on-line > Internet-Drafts directories. > > This draft is a work item of the IP = Security Protocol > Working Group of the IETF. > > > > Title = : IP Authentication = Header > > = Author(s) : S. Kent > > = Filename : = draft-ietf-ipsec-rfc2402bis-01.txt > > Pages = : 30 > > Date = : 02-Jul-02 > > Hi, all, > > To start the discussion off, we'd certainly = appreciate having section > 3.1.2 at least say "MUST use tunnel mode = or its equivalent, i.e., > transport over 2003-style IP = encapsulation". > > We have raised this issue before; details of = why are in > draft-touch-ipsec-vpn-03.txt > > (and we're hoping that 2401bis more directly = addresses this issue). > > Joe > > > ------_=_NextPart_001_01C222BB.E2397400-- --=====================_88867715==_.ALT Content-Type: text/html; charset="us-ascii" Approved: Dob.ipsec >From majordomo-owner Wed Jul 3 13:49:26 2002 Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id NAA17046 Wed, 3 Jul 2002 13:49:26 -0400 (EDT) Received: by sentry.gw.tislabs.com; id OAA16773; Wed, 3 Jul 2002 14:02:41 -0400 (EDT) Received: from zcars04e.nortelnetworks.com(47.129.242.56) by sentry.gw.tislabs.com via smap (V5.5) id xma016769; Wed, 3 Jul 02 14:02:36 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g63I3EZ10431 for ; Wed, 3 Jul 2002 14:03:15 -0400 (EDT) Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 14:03:14 -0400 Message-ID: From: "Paul Knight" To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-rfc2402bis-01.txt Date: Wed, 3 Jul 2002 14:03:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C222BB.E2397400" 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_01C222BB.E2397400 Content-Type: text/plain; charset="iso-8859-1" Hi all, Yes, this is a key issue in supporting dynamic routing inside IPsec-based VPNs. Applying IP-in-IP encapsulation (RFC 2003) before transport mode results in a packet which is the same as tunnel mode (satisfying any security issues), BUT allows routing (i.e., setting the encapsulating destination address to the known next-IPsec-hop) to be handled cleanly. Regards, Paul Knight > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Wednesday, July 03, 2002 12:21 PM > To: ipsec@lists.tislabs.com > Subject: Re: I-D ACTION:draft-ietf-ipsec-rfc2402bis-01.txt > > > Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > This draft is a work item of the IP Security Protocol > Working Group of the IETF. > > > > Title : IP Authentication Header > > Author(s) : S. Kent > > Filename : draft-ietf-ipsec-rfc2402bis-01.txt > > Pages : 30 > > Date : 02-Jul-02 > > Hi, all, > > To start the discussion off, we'd certainly appreciate having section > 3.1.2 at least say "MUST use tunnel mode or its equivalent, i.e., > transport over 2003-style IP encapsulation". > > We have raised this issue before; details of why are in > draft-touch-ipsec-vpn-03.txt > > (and we're hoping that 2401bis more directly addresses this issue). > > Joe > > > ------_=_NextPart_001_01C222BB.E2397400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-ipsec-rfc2402bis-01.txt Hi all, Yes, this is a key issue in supporting dynamic = routing inside IPsec-based VPNs. Applying IP-in-IP encapsulation = (RFC 2003) before transport mode results in a packet which is the same = as tunnel mode (satisfying any security issues), BUT allows routing = (i.e., setting the encapsulating destination address to the known = next-IPsec-hop) to be handled cleanly. Regards, Paul Knight > -----Original Message----- > From: Joe Touch [<3d.htm>mailto:touch@ISI.EDU] > Sent: Wednesday, July 03, 2002 12:21 PM > To: ipsec@lists.tislabs.com > Subject: Re: I-D = ACTION:draft-ietf-ipsec-rfc2402bis-01.txt > > > Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the = on-line > Internet-Drafts directories. > > This draft is a work item of the IP = Security Protocol > Working Group of the IETF. > > > > Title = : IP Authentication = Header > > = Author(s) : S. Kent > > = Filename : = draft-ietf-ipsec-rfc2402bis-01.txt > > Pages = : 30 > > Date = : 02-Jul-02 > > Hi, all, > > To start the discussion off, we'd certainly = appreciate having section > 3.1.2 at least say "MUST use tunnel mode = or its equivalent, i.e., > transport over 2003-style IP = encapsulation". > > We have raised this issue before; details of = why are in > draft-touch-ipsec-vpn-03.txt > > (and we're hoping that 2401bis more directly = addresses this issue). > > Joe > > > ------_=_NextPart_001_01C222BB.E2397400-- --=====================_88867715==_.ALT-- From owner-ipsec@lists.tislabs.com Fri Jul 5 08:16:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g65FGJw22639; Fri, 5 Jul 2002 08:16:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20557 Fri, 5 Jul 2002 10:24:46 -0400 (EDT) Message-Id: <200207051033.GAA16946@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-properties-02.txt Date: Fri, 05 Jul 2002 06:33:23 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Security Properties of the IPsec Protocol Suite Author(s) : A. Krywaniuk Filename : draft-ietf-ipsec-properties-02.txt Pages : 19 Date : 03-Jul-02 This document describes the 'security properties' of the IPsec architecture and protocols, including ESP, AH, and IKE. By documenting these properties, we aim to provide a guide for users who wish to understand the abilities and limitations of the IPsec protocol suite. We also hope to provide motivation for future work in this area. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-properties-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-ipsec-properties-02.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-ietf-ipsec-properties-02.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020703131716.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-properties-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-properties-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020703131716.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jul 5 08:16:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g65FGMw22652; Fri, 5 Jul 2002 08:16:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20547 Fri, 5 Jul 2002 10:23:46 -0400 (EDT) Message-Id: <200207051033.GAA16908@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esn-addendum-00.txt Date: Fri, 05 Jul 2002 06:33:13 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Extended Sequence Number Addendum to IPsec DOI for ISAKMP Author(s) : S. Kent Filename : draft-ietf-ipsec-esn-addendum-00.txt Pages : 5 Date : 03-Jul-02 This document describes extensions to the Internet IP Security Domain of Interpretation for ISAKMP [DOI] that are needed to support negotiation of whether or not a Security Association will use Extended (64-bit) Sequence Numbers. (See [AH] and [ESP] for a description of Extended Sequence Numbers.) Comments should be sent to Stephen Kent (kent@bbn.com). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esn-addendum-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-ipsec-esn-addendum-00.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-ietf-ipsec-esn-addendum-00.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020703131657.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esn-addendum-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esn-addendum-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020703131657.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jul 5 08:16:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g65FGNw22653; Fri, 5 Jul 2002 08:16:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20548 Fri, 5 Jul 2002 10:23:52 -0400 (EDT) Message-Id: <200207051033.GAA16922@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-jfk-04.txt Date: Fri, 05 Jul 2002 06:33:18 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Just Fast Keying (JFK) Author(s) : W. Aiello, S. Bellovin et al. Filename : draft-ietf-ipsec-jfk-04.txt Pages : Date : 03-Jul-02 This draft discusses JFK, a key management protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-jfk-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-ipsec-jfk-04.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-ietf-ipsec-jfk-04.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020703135953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-jfk-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-jfk-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020703135953.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Jul 8 17:10:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g690Adw20374; Mon, 8 Jul 2002 17:10:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA00970 Mon, 8 Jul 2002 19:06:43 -0400 (EDT) Message-Id: <200207082320.g68NKZGF039788@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: IPsec and Mobile IPv6 Date: Tue, 09 Jul 2002 01:20:35 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The second version of my draft about IPsec and Mobile IPv6 is available (name : draft-dupont-ipsec-mipv6-01.txt). I added some proposals for IKEv2 (or for any new two-phase protocol) because the current specifications are both incomplete and insecure (because they are designed with the NAT traversal issue in the mind when mobility (or the dual problem, multihoming, which is already known from SCTP). I haven't seen the call for the agenda... I'd like to get some minutes (just to say you should read the draft) in the one phase/two phases discussion (the killer argument for one-phase protocol is the mobile can restart everything from scratch when it has moved. It works but of course it is always inefficient, etc). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Jul 9 10:31:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g69HV3w25214; Tue, 9 Jul 2002 10:31:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06609 Tue, 9 Jul 2002 12:35:40 -0400 (EDT) From: Bill Fenner Message-Id: <200207091649.JAA15469@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: kent@bbn.com Subject: Re: new version of ESP ID Cc: ipsec@lists.tislabs.com, msec@securemulticast.org References: <4.3.2.7.2.20020701090942.04d7cef8@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020702081612.04a49dc8@mira-sjc5-6.cisco.com> Date: Tue, 9 Jul 2002 09:49:15 -0700 Versions: dmail (solaris) 2.4c/makemail 2.9d Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >I've always assumed that a single controller or coordinated set of >controllers assigned SPIs for a given multicast address anyway. SSM changes the semantics of the multicast address space; it is now per-sender (i.e. source=S1 dest=G and source=S2 dest=G are two different "channels") in the SSM range. Thus, there can be no single coordinator for G and SPI conflicts can occur if S is not used for demultiplexing. Bill From owner-ipsec@lists.tislabs.com Tue Jul 9 10:38:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g69Hcaw25661; Tue, 9 Jul 2002 10:38:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06662 Tue, 9 Jul 2002 12:45:41 -0400 (EDT) From: Bill Fenner Message-Id: <200207091659.JAA15664@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: mbaugher@cisco.com Subject: Re: new version of ESP ID Cc: ipsec@lists.tislabs.com, msec@securemulticast.org Date: Tue, 9 Jul 2002 09:59:17 -0700 Versions: dmail (solaris) 2.4c/makemail 2.9d Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >First, section 2.2 deprecates sharing an SA among multiple senders to a >multicast group and in effect mandates single-sender multicast for ESP >groups. The same is true for AH. I'm aware of only one protocol, the VRRP >specification, that is affected by this change. VRRP uses AH or ESP but >allows multi-source multicast groups. We should notify the VRRP WG of this >potential change. I brought this up at the WG meeting in Minneapolis. Several protocols that send multicasts on a LAN use this model (VRRP, OSPFv3, PIM, IGMP come to mind). I'd like to see two possible modes for use with multicast: - anti-replay sequence number per sender, with a shared SA. - including the source address when demultiplexing to permit SSM semantics. I know that at least the first is completely opposite of the direction that the group has been going. However, especially with 64-bit anti-replay sequence numbers, it permits protocols to use a standard, existing protocol even when using static shared SAs. Yes, a static shared SA buys you much less protection than dynamically negotiated ones, but does that mean that it should be ruled out? Bill From owner-ipsec@lists.tislabs.com Wed Jul 10 10:38:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6AHcIw01511; Wed, 10 Jul 2002 10:38:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14513 Wed, 10 Jul 2002 12:40:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20020709135351.0251a3f0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Jul 2002 09:51:28 -0700 To: Bill Fenner From: Mark Baugher Subject: Re: new version of ESP ID Cc: ipsec@lists.tislabs.com, msec@securemulticast.org In-Reply-To: <200207091659.JAA15664@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:59 AM 7/9/2002 -0700, Bill Fenner wrote: > >First, section 2.2 deprecates sharing an SA among multiple senders to a > >multicast group and in effect mandates single-sender multicast for ESP > >groups. The same is true for AH. I'm aware of only one protocol, the VRRP > >specification, that is affected by this change. VRRP uses AH or ESP but > >allows multi-source multicast groups. We should notify the VRRP WG of this > >potential change. > >I brought this up at the WG meeting in Minneapolis. Several protocols >that send multicasts on a LAN use this model (VRRP, OSPFv3, PIM, >IGMP come to mind). Yes, of course, though a number of people think that IGMP security is needless (and voiced that in the last gsec meeting). You made an important point in your previous note about SSM and the usefulness of the source address to identifying the multicast SA. >I'd like to see two possible modes for use with multicast: >- anti-replay sequence number per sender, with a shared SA. >- including the source address when demultiplexing to permit SSM semantics. > >I know that at least the first is completely opposite of the direction >that the group has been going. However, especially with 64-bit anti-replay >sequence numbers, it permits protocols to use a standard, existing protocol >even when using static shared SAs. Yes, a static shared SA buys you much >less protection than dynamically negotiated ones, but does that mean that it >should be ruled out? I don't understand the distinction between static and dynamic SAs. Is the distinction between a single-sender multicast SA versus a multi-sender multicast SA? I think that it is a more robust solution to identify the multicast SA using the source address as well as the SPI and destination address. This is what many of us who worked in smug thought we would do with MESP. Now that Steve is addressing multicast in ESP and AH, it's not clear to me how msec should proceed with MESP. Mark > Bill From owner-ipsec@lists.tislabs.com Wed Jul 10 11:50:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6AIoVw08281; Wed, 10 Jul 2002 11:50:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14861 Wed, 10 Jul 2002 14:04:28 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 5.2 Scope of proposals Phone: (781) 391-3464 Message-Id: Date: Wed, 10 Jul 2002 14:17:48 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer this question: 5.2 Scope of proposals 5.2.A) Is it important to have predefined suites or a la carte selection of parameters? Implications from the scenarios: [none] From owner-ipsec@lists.tislabs.com Wed Jul 10 11:52:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6AIqZw08495; Wed, 10 Jul 2002 11:52:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14834 Wed, 10 Jul 2002 14:03:23 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 5.1 SA creation style: Cryptographic agreement Phone: (781) 391-3464 Message-Id: Date: Wed, 10 Jul 2002 14:17:08 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk After taking a few days off for the July 4th holidays, I'm restarting sending out SOI Questions. There only a couple more for us to tackle! Please discuss and answer this question: 5. SA creation style 5.1 Cryptographic agreement 5.1.A)Is negotiation for the algorithm suite required or not? 5.1.B) Is there ever a case when you want the initiator to have the "last word"? Implications from the scenarios: [none] From owner-ipsec@lists.tislabs.com Wed Jul 10 11:53:21 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6AIrKw08591; Wed, 10 Jul 2002 11:53:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14858 Wed, 10 Jul 2002 14:04:26 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 5.1.2 Agreement of IPsec SA cryptographic algorithms Phone: (781) 391-3464 Message-Id: Date: Wed, 10 Jul 2002 14:17:30 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer this question: 5.1.2 Agreement of IPsec SA cryptographic algorithms JFK's SA negotiation uses pre-defined suites, and Bob presents a single suite to Alice. In IKEv2 SA negotiation allows the two parties to agree on the most preferred parameters, the same as it does for key negotiation. 5.1.2.A) Is it important to allow negotiation of the SA algorithms? Implications from the scenarios: [none] From owner-ipsec@lists.tislabs.com Wed Jul 10 14:41:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6ALfKw21399; Wed, 10 Jul 2002 14:41:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15777 Wed, 10 Jul 2002 16:57:26 -0400 (EDT) Message-ID: <004801c22856$7aabe7a0$a9f22b42@mv.lucent.com> From: "David Faucher" To: References: Subject: Re: SOI QUESTION: 5.2 Scope of proposals Date: Wed, 10 Jul 2002 16:12:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk | | Please discuss and answer this question: | | 5.2 Scope of proposals | | 5.2.A) Is it important to have predefined suites or a la carte selection of | parameters? | In the interest of keeping it simple, I vote for predefined suites. | | Implications from the scenarios: | | [none] From owner-ipsec@lists.tislabs.com Wed Jul 10 18:10:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6B1Axw08445; Wed, 10 Jul 2002 18:10:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA16874 Wed, 10 Jul 2002 20:23:24 -0400 (EDT) Message-Id: <200207110036.g6B0a6Bx028990@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 5.2 Scope of proposals In-reply-to: Your message of "Wed, 10 Jul 2002 14:17:48 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 10 Jul 2002 20:36:05 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Theodore" == Theodore Ts'o writes: Theodore> 5.2.A) Is it important to have predefined suites or a la carte Theodore> selection of Theodore> parameters? Predefined suites. They are easier to program, easier to optomize, and easier to analyze. The combinatorics do *NOT* concern me, because the effort of the combinatorics of the testing exceeds any "hassle" in writing a couple more RFCs. Predefined suites are better for pretty much every scenarios. We NEED a MUST suite for end-to-end security to work. We need a backup suite to transition to should the initial suite turn out to be broken. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPSzS8oqHRg3pndX9AQFbTgP+N9P260BV1CuBNDogWSdCzpmK1r4Nh8rm A/69i+B7kIH2SsmpdDt9ZCLFazewEq/45xt9oZXPddTwGEHxtqeTuGVCrz1DqZYk zFzRoXfSEXxoGXfSADMVVTArqzdABnriFqJKrNszE/YBEichF5Gbva6KGwLTd9zz VsqayonHyXY= =k2bt -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Jul 10 20:55:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6B3t5w19566; Wed, 10 Jul 2002 20:55:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17788 Wed, 10 Jul 2002 23:08:46 -0400 (EDT) Message-ID: <3D2CF9E0.98CFE042@lucent.com> Date: Wed, 10 Jul 2002 23:22:08 -0400 From: Uri Blumenthal Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 5.2 Scope of proposals References: <200207110036.g6B0a6Bx028990@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson wrote: > Theodore> 5.2.A) Is it important to have predefined suites or a la carte > Theodore> selection of > Theodore> parameters? > > Predefined suites. > They are easier to program, easier to optomize, and easier to analyze. > ......... > Predefined suites are better for pretty much every scenarios. > > We NEED a MUST suite for end-to-end security to work. We need a backup > suite to transition to should the initial suite turn out to be broken. Predefined suites - for the reasons well outlined above. -- Regards, Uri -=-=-=<>=-=- From owner-ipsec@lists.tislabs.com Thu Jul 11 01:23:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6B8NBw19317; Thu, 11 Jul 2002 01:23:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA19417 Thu, 11 Jul 2002 03:35:53 -0400 (EDT) Message-ID: <3D2D38E1.5BB7F87D@F-Secure.com> Date: Thu, 11 Jul 2002 10:50:57 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Theodore Ts'o" CC: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 5.1 SA creation style: Cryptographic agreement References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2002 07:50:41.0696 (UTC) FILETIME=[A7A79200:01C228AF] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It might be good if IKE used ANSI X9.31, instead of PKCS#1. "There are three FIPS-approved algorithms for generating and verifying digital signatures: Digital Signature Algorithm (DSA), RSA (as specified in ANSI X9.31), and Elliptic Curve DSA (ECDSA; as specified in ANSI X9.62)." From: http://csrc.nist.gov/cryptval/dss.htm As to the negotiation of algorithms, I'd vote for specifying each algorithm separately, but specifying in some RFC that some specific combinations of algorithms must be supported. For example, an RFC might specify that "AES-128 in CBC mode, SHA-1 and group 5 MUST be supported by all implementations for both SOI and IPsec SAs". (Yes, I know about Orman's draft.) I see no practical problem in specifying algorithms in pretty much the same way as in IKEv1. The problems come from many manufacturers supporting different algorithms. Like some support LZS and others DEFLATE. Since I don't see why everybody would need to pay the license for LZS, I'd like to make DEFLATE support be must/should for ESP. I think the beef is what algorithms are used, and not so much how they are negotiated, although some flexibility to negotiate proprietary algorithms would be good. Ari Theodore Ts'o wrote: > > After taking a few days off for the July 4th holidays, I'm restarting > sending out SOI Questions. There only a couple more for us to tackle! > > Please discuss and answer this question: > > 5. SA creation style > > 5.1 Cryptographic agreement > > 5.1.A)Is negotiation for the algorithm suite required or not? > > 5.1.B) Is there ever a case when you want the initiator to have the "last > word"? > > Implications from the scenarios: > > [none] -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Thu Jul 11 08:45:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6BFjAw03306; Thu, 11 Jul 2002 08:45:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21811 Thu, 11 Jul 2002 10:53:24 -0400 (EDT) Message-Id: <200207111302.g6BD28T23011@mail.deldsl.com> Content-Type: text/plain; charset="iso-8859-15" From: venkat Reply-To: venkat@dexceldesigns.com Organization: Dexcel Electronics Designs (P) Ltd. To: ipsec@lists.tislabs.com Subject: NULL_ESP; why at all does it exist? Date: Thu, 11 Jul 2002 13:12:32 +0530 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Mailserver: Sent using PostMaster (v4.1.13) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Everbody, Could you answer these questions 1. During ESP packet generation, can the encryption be done with DES_CBC or 3DES_CBC and then provide authentication with NULL_ESP. 2. Is it required that we have to provide authentication with HMAC-MD5 or HMAC-SHA. i.e. ESP_AUTH part 3. Can NULL_ESP be used for providing authenticatoin at all, because I read somewhere that NULL_ESP can be used for this purpose. 4. Is NULL_ESP a void Transform, i.e. it doesn't do anything at all. 5. To provide authentication only in ESP, can we use Enc-> NULL_ESP and then Auth-> HMAC-MD5/SHA Awaiting replies - Venkat -------------------------------------------------------------- Dexcel Electronics Designs (P) Ltd., Bangalore, India From owner-ipsec@lists.tislabs.com Thu Jul 11 09:04:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6BG4aw04478; Thu, 11 Jul 2002 09:04:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22075 Thu, 11 Jul 2002 11:19:57 -0400 (EDT) From: Dilip Gudimetla Message-ID: <42F8E5E45F74D61183F80090277A3DDE2830F3@liam.cisco.com> To: ipsec@lists.tislabs.com Subject: Encrypted Client Notifications? Date: Thu, 11 Jul 2002 11:30:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi I am looking for a solution to send an encrypted notification of sizes upto 2K to IKE Peer after tunnel has established between peers. Especially looking for a way to notify IKE peer without using "IKE notify message" since the custom notifications may overburden the IKE. Do we have any accepted protocol to accomplish it or any thoughts? I appreciate your help. Thanks in advance, Dilip From owner-ipsec@lists.tislabs.com Thu Jul 11 10:13:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6BHDww09072; Thu, 11 Jul 2002 10:13:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22389 Thu, 11 Jul 2002 12:23:31 -0400 (EDT) Message-Id: <200207111638.AFJ97314@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 11 Jul 2002 09:23:41 -0700 To: venkat@dexceldesigns.com, ipsec@lists.tislabs.com From: Scott Fluhrer Subject: Re: NULL_ESP; why at all does it exist? In-Reply-To: <200207111302.g6BD28T23011@mail.deldsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:42 AM 7/11/02 , venkat wrote: >Hi Everbody, > >Could you answer these questions > >1. During ESP packet generation, can the encryption be done with DES_CBC or >3DES_CBC and then provide authentication with NULL_ESP. ESP_NULL does not provide authentication. You need an authentication transform to do that. > >2. Is it required that we have to provide authentication with HMAC-MD5 or >HMAC-SHA. i.e. ESP_AUTH part Yes, it is (except for the minor point that you are not limited to those two authentication transforms; you can use HMAC-RIPEMD or some other ESP authentication transform). > >3. Can NULL_ESP be used for providing authenticatoin at all, because I read >somewhere that NULL_ESP can be used for this purpose. It's provided because sometimes you really do want authentication but not privacy, and ESP is defined to include an "encryption" transform. Hence, a NULL "encryption" transform that does not provide privacy. Note that AH alone will also provide this, but there are cases where AH cannot be used. > >4. Is NULL_ESP a void Transform, i.e. it doesn't do anything at all. Well, it's the identity function. See RFC2410 for all the fun details. > >5. To provide authentication only in ESP, can we use Enc-> NULL_ESP and then >Auth-> HMAC-MD5/SHA Yes, that is allowed. > >Awaiting replies >- Venkat > >-------------------------------------------------------------- >Dexcel Electronics Designs (P) Ltd., Bangalore, India > From owner-ipsec@lists.tislabs.com Thu Jul 11 11:44:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6BIi4w13036; Thu, 11 Jul 2002 11:44:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22736 Thu, 11 Jul 2002 13:28:07 -0400 (EDT) Message-ID: From: Harshwardhan Mittal To: ipsec@lists.tislabs.com Subject: ipsec vs l2tp Date: Thu, 11 Jul 2002 22:51:56 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Everyone, I need some article on "IPSEC vs L2TP" any link is highly welcomed, thanks in advance.. Regards, Harsh From owner-ipsec@lists.tislabs.com Thu Jul 11 14:05:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6BL5vw18152; Thu, 11 Jul 2002 14:05:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23564 Thu, 11 Jul 2002 16:19:00 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 6.2 Port number Phone: (781) 391-3464 Message-Id: Date: Thu, 11 Jul 2002 16:32:21 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer the following question: 6.2 Port number 6.2.A) Should SOI use the same port as IKEv1? (See discussion in soi-features-01 the tradeoffs in this question). Implications from the Scenarios: [none] From owner-ipsec@lists.tislabs.com Thu Jul 11 14:05:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6BL5ww18163; Thu, 11 Jul 2002 14:05:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23557 Thu, 11 Jul 2002 16:18:01 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 5.3 SPD entries Phone: (781) 391-3464 Message-Id: Date: Thu, 11 Jul 2002 16:31:37 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer the following question: 5.3 SPD entries 5.3.A) Is it important in SOI to allow the the responder to accept a subset of the proposed SA, or should it be an all or nothing acceptance? 5.3.B) Should the SOI offer multiple selectors with specific ports and addresses, or a single selector with a range of ports and range of addresses? (complicated boolean complexity!) Implications from the scenarios: <<>> [[[5.3]]] From owner-ipsec@lists.tislabs.com Thu Jul 11 14:05:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6BL5vw18153; Thu, 11 Jul 2002 14:05:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23558 Thu, 11 Jul 2002 16:18:01 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 6. Wire protocol issues: Message Encoding Phone: (781) 391-3464 Message-Id: Date: Thu, 11 Jul 2002 16:32:01 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer the following question: 6. Wire protocol issues 6.1 Message encoding 6.1.A) Should SOI worry about aligning parts of messages on 2 and 4 byte boundaries? 6.1.B) Should SOI tag its protocol with version numbers? 6.1.C) Should SOI format be roughly the same as IKEv1? (See discussion in section 6.4, re: code preserving) Implications from the Scenarios: From owner-ipsec@lists.tislabs.com Thu Jul 11 15:19:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6BMJvw22775; Thu, 11 Jul 2002 15:19:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24001 Thu, 11 Jul 2002 17:32:43 -0400 (EDT) Date: 11 Jul 2002 17:32:48 -0400 Message-ID: <001201c22922$817f5db0$6568e640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Theodore Ts'o'" , " 'list'" Subject: SOI QUESTIONS: 5.1-5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 5.1.A)Is negotiation for the algorithm suite required or not? Yes. The idea that you can avoid negotiation in JFK is illusory. You either get negotiation in the exchange or in the meta-negotiation. > 5.1.B) Is there ever a case when you want the initiator to > have the "last > word"? I don't understand this question > 5.1.2 Agreement of IPsec SA cryptographic algorithms > > JFK's SA negotiation uses pre-defined suites, and Bob > presents a single > suite to Alice. In IKEv2 SA negotiation allows the two > parties to agree on > the most preferred parameters, the same as it does for key > negotiation. > > 5.1.2.A) Is it important to allow negotiation of the SA algorithms? Isn't this the same as 5.1.A? > 5.2.A) Is it important to have predefined suites or a la > carte selection of > parameters? I prefer to have so-called "GUI ciphersuites" where we allow negotiation of parameters on the wire, but define names for a few specific combinations. These common names could then be used in a GUI to ensure easy configuration of heterogeneous networks. The problem with ciphersuites has traditionally been that not everyone is going to agree on every parameter. Ciphersuites will force us to accomodate the lowest common denominator (or perhaps the highest common denominator). At least by making the algorithms negotiable on the wire, it's not such a forced decision. Whether the ciphersuite is virtual or sent on the wire doesn't make it any harder for you to optimize for that specific case. You can look for specific combinations of algorithms and instantiate an optimized subclass/code path. In practice, it's not IKE but ESP that really needs to be optimized, anyway. Most of us already have code for the IPsec transform part which handles both the generic case and optimized subcases. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Thu Jul 11 15:19:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6BMJvw22774; Thu, 11 Jul 2002 15:19:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24002 Thu, 11 Jul 2002 17:32:47 -0400 (EDT) Date: Fri, 12 Jul 2002 00:46:28 +0300 Message-Id: <200207112146.AAA27456@burp.tkv.asdf.org> From: Markku Savela To: tytso@mit.edu CC: ipsec@lists.tislabs.com In-reply-to: (tytso@mit.edu) Subject: Re: SOI QUESTION: 5.3 SPD entries References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > X-Authentication-Warning: burp.tkv.asdf.org: Host portal.gw.tislabs.com [192.94.214.101] claimed to be lists.tislabs.com > Please discuss and answer the following question: > > > 5.3 SPD entries > > 5.3.A) Is it important in SOI to allow the the responder to accept a subset > of the proposed SA, or should it be an all or nothing acceptance? > > 5.3.B) Should the SOI offer multiple selectors with specific ports and > addresses, or a single selector with a range of ports and range of > addresses? (complicated boolean complexity!) > > Implications from the scenarios: > > << subnets, a mechanism that allowed the negotiation of a list of phase 2 > identities will help to alleviate the number of IPsec tunnels that must > be created.>>> [[[5.3]]] Irrelevant. IKE does not need to check policy. Just recording my objection (no need to start discussion) :-) From owner-ipsec@lists.tislabs.com Thu Jul 11 15:47:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6BMlAw24543; Thu, 11 Jul 2002 15:47:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24183 Thu, 11 Jul 2002 18:04:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 11 Jul 2002 18:17:56 -0400 To: "Theodore Ts'o" From: Stephen Kent Subject: Re: SOI QUESTION: 5.3 SPD entries Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:31 PM -0400 7/11/02, Theodore Ts'o wrote: >Please discuss and answer the following question: > > >5.3 SPD entries > >5.3.A) Is it important in SOI to allow the the responder to accept a subset >of the proposed SA, or should it be an all or nothing acceptance? Subset acceptance sounds attractive, as a means of making it easier to coordinate SPDs, but it does complicate the system and I don't know if the new processing model we envision for 2401bis would accommodate subset acceptance. It requires further thought. > >5.3.B) Should the SOI offer multiple selectors with specific ports and >addresses, or a single selector with a range of ports and range of >addresses? (complicated boolean complexity!) Based on list reaction to earlier comments, and feedback that Cheryl reported at an IETF meeting some time ago, I think we anticipate that 2401bis will call for a uniform approach to selector specification (inspired by the JFK design). The approach is a list of ranges of values. a single value or a single range is a trivial form of this approach, consistent with current capabilities. the list feature allows enumeration of individual, non-contiguous values (e.g., different protocols or ports) and the list non-trivial ranges is the most complex form. > >Implications from the scenarios: > ><<subnets, a mechanism that allowed the negotiation of a list of phase 2 >identities will help to alleviate the number of IPsec tunnels that must >be created.>>> [[[5.3]]] this is one good example of where this form of selector is helpful, but it also applies when an application allows either UDP or TCP on the same ports, etc. From owner-ipsec@lists.tislabs.com Thu Jul 11 15:47:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6BMlAw24545; Thu, 11 Jul 2002 15:47:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24182 Thu, 11 Jul 2002 18:04:51 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 11 Jul 2002 18:18:48 -0400 To: "Theodore Ts'o" From: Stephen Kent Subject: Re: SOI QUESTION: 6. Wire protocol issues: Message Encoding Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:32 PM -0400 7/11/02, Theodore Ts'o wrote: >Please discuss and answer the following question: > > >6. Wire protocol issues > >6.1 Message encoding > >6.1.A) Should SOI worry about aligning parts of messages on 2 and 4 >byte boundaries? yes. > >6.1.B) Should SOI tag its protocol with version numbers? yes. > >6.1.C) Should SOI format be roughly the same as IKEv1? (See >discussion in section 6.4, re: code preserving) nice, but not absolutely critical From owner-ipsec@lists.tislabs.com Thu Jul 11 20:15:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6C3FRw11386; Thu, 11 Jul 2002 20:15:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA25480 Thu, 11 Jul 2002 22:23:02 -0400 (EDT) Message-Id: <200207120236.g6C2ZvSW024119@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 5.1-5.2 In-reply-to: Your message of "11 Jul 2002 17:32:48 EDT." <001201c22922$817f5db0$6568e640@ca.alcatel.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 11 Jul 2002 22:35:57 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Andrew" == Andrew Krywaniuk writes: >> 5.2.A) Is it important to have predefined suites or a la >> carte selection of >> parameters? Andrew> I prefer to have so-called "GUI ciphersuites" where we allow negotiation of Andrew> parameters on the wire, but define names for a few specific combinations. Andrew> These common names could then be used in a GUI to ensure easy configuration Andrew> of heterogeneous networks. The problem with ciphersuites has traditionally Andrew> been that not everyone is going to agree on every parameter. Ciphersuites Andrew> will force us to accomodate the lowest common denominator (or perhaps the I don't find this acceptable. 1) in order to avoid permitting users to shoot themselves in the foot, some GUI will have to *restrict* them to those ciphersuites. 2) Given the above, how do I test all combinations? Talk to your testing people on this. Let them make the decision. Suites rule. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Thu Jul 11 20:31:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6C3VZw12410; Thu, 11 Jul 2002 20:31:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA25638 Thu, 11 Jul 2002 22:45:05 -0400 (EDT) X-Authentication-Warning: kaakeli.ssh.fi: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15662.17753.30443.426549@kaakeli.ssh.fi> Date: Fri, 12 Jul 2002 05:56:25 +0300 From: Tero Kivinen To: tytso@mit.edu ("Theodore Ts'o"), ipsec@lists.tislabs.com Subject: SOI QUESTION: 5.1, 5.1.2, 5.2, 5.3, 6, 6.1, 6.2 X-Mailer: VM 7.00 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 25 min X-Total-Time: 33 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 5. SA creation style > 5.1 Cryptographic agreement > 5.1.A)Is negotiation for the algorithm suite required or not? Yes. > 5.1.B) Is there ever a case when you want the initiator to have the "last > word"? Initiator will always have the last word. It can simply just not use the SA created... I think that is enough for the initiator... > 5.1.2 Agreement of IPsec SA cryptographic algorithms > 5.1.2.A) Is it important to allow negotiation of the SA algorithms? Yes. > 5.2 Scope of proposals > 5.2.A) Is it important to have predefined suites or a la carte selection of > parameters? I like a better to have GUI suites and a la carte selection of algorithms inside the protocol. I myself think that a la carte selection is easier to implement and it will simplify the debugging, extensibility of the protocol and protocol specification itself, and it does not affect the implementation that much. The reason it is easier to debug is that for example our TLS library has 41 differnet suites now. Some of those are pretty wierd and I am not sure if anybody has tested them against someone else ever. We have tested them against ourselves, but that does not show problems like we had typo in the suite definiation once and that was found out few years after when someone had some wierd client actually using that suite... Testing 41 different suites manually is quite much work, and in that case you are going to implement test program to test them all automatically. If you are testing them automatically then it really doesn't matter if there is 41 or 100000 of them. For example my test program for isakmp by default test about 300 combinations, and given suitable parameters it will test all cipher sa combinations (2 exchange methods * 4 authentication methods * 11 ciphers * 4 hash algorithms * 8 groups * 6 cipher lengths = 2816 tests). Adding even more parameters it starts testing with different identity types etc and that will end up having about 100000 tests... So I think the number of suites is going to be too big for manual testing anyways and if you test them automatically it really doesn't matter how many of them there are. Also as I said we have now 41 different suites in the TLS library, but I don't know if that is up to date list. We might be missing some and when someone decides to add new suite like AES + MD5 then we need to update the suite list again to get them working. If the TLS would use the similar combinatory system the AES + MD5 would just simply work automatically, because we have both AES and MD5 support there already. > 5.3 SPD entries > 5.3.A) Is it important in SOI to allow the the responder to accept a subset > of the proposed SA, or should it be an all or nothing acceptance? Yes. It makes it easier if the both ends does not have to agree about the policy completely beforehand, thus if we can get it automatically recover for that kind of misconfigurations it is good... (i.e other end configure 192.168.0.0/16 and other end 196.168.2.0/256). > 5.3.B) Should the SOI offer multiple selectors with specific ports and > addresses, or a single selector with a range of ports and range of > addresses? (complicated boolean complexity!) I think the list of ranges as an only form is best. > 6. Wire protocol issues > 6.1 Message encoding > 6.1.A) Should SOI worry about aligning parts of messages on 2 and 4 > byte boundaries? No. Compared to encryption/decryption and Diffie-Hellman the misaligned data access doesn't really matter. Also the IKE packets are not sent or received that often. Adding padding after variable length data simply adds quite a lot of code and that normally means bugs. > 6.1.B) Should SOI tag its protocol with version numbers? Yes. > 6.1.C) Should SOI format be roughly the same as IKEv1? (See > discussion in section 6.4, re: code preserving) I think yes. There isn't actually anything that bad or complex in the basic packet/payload encoding. > 6.2 Port number > 6.2.A) Should SOI use the same port as IKEv1? (See discussion in > soi-features-01 the tradeoffs in this question). If the packet format is similar than IKEv1 then I think we should use the same port as it allows implementations supporting both versions faster fall back to old version (provided that the other end sends error notification when it receives IKEv2 packet). -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Jul 11 20:42:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6C3grw13145; Thu, 11 Jul 2002 20:42:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA25719 Thu, 11 Jul 2002 22:58:07 -0400 (EDT) From: "Jayant Shukla" To: "'Michael Richardson'" , Subject: RE: SOI QUESTION: 5.2 Scope of proposals Date: Thu, 11 Jul 2002 20:09:02 -0700 Message-ID: <000001c22951$798786d0$0402a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <200207110036.g6B0a6Bx028990@marajade.sandelman.ottawa.on.ca> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Michael Richardson > > >>>>> "Theodore" == Theodore Ts'o writes: > Theodore> 5.2.A) Is it important to have predefined suites or a la > carte > Theodore> selection of > Theodore> parameters? > > Predefined suites. > They are easier to program, easier to optomize, and easier to > analyze. > Definitely! > The combinatorics do *NOT* concern me, because the effort of the > combinatorics of the testing exceeds any "hassle" in writing a couple > more RFCs. > > Predefined suites are better for pretty much every scenarios. > > We NEED a MUST suite for end-to-end security to work. I don't completely agree. What you NEED is a centralized management for e2e security to work. A MUST suite only solves part of the e2e problem. Using the centralized management, you can always ensure that host policies and suits are in sync. > We need a backup > suite to transition to should the initial suite turn out to be broken. > If you know specifically what might turn out to be broken, one backup will suffice. Otherwise you will need more than one backup......... Regards, Jayant www.trlokom.com From owner-ipsec@lists.tislabs.com Thu Jul 11 21:48:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6C4lxw17015; Thu, 11 Jul 2002 21:47:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA26215 Thu, 11 Jul 2002 23:59:29 -0400 (EDT) Message-ID: From: Harshwardhan Mittal To: "'ipsec@lists.tislabs.com'" Subject: IPSEC for mobile IP Date: Fri, 12 Jul 2002 09:23:26 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Everyone, I am looking for the IPSEC and other VPN solutions for Mobile IP. Any information in this respect will be very useful for me, Thanks in advance. Regards, Harsh From owner-ipsec@lists.tislabs.com Fri Jul 12 01:08:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6C88Jw18269; Fri, 12 Jul 2002 01:08:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA27387 Fri, 12 Jul 2002 03:13:10 -0400 (EDT) Date: Fri, 12 Jul 2002 09:26:41 +0200 (MET DST) Message-Id: <200207120726.JAA02412@hugo.int-evry.fr> From: Jean-Jacques Puig To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 6.2 Port number In-Reply-To: References: Organization: =?UTF-8?B?RMOpcGFydGVtZW50?= Logiciels - =?UTF-8?B?UsOpc2VhdQ==?= x X-Mailer: Sylpheed version 0.6.1 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Please discuss and answer the following question: > > 6. Wire protocol issues > > 6.1 Message encoding > > 6.1.A) Should SOI worry about aligning parts of messages on 2 and 4 > byte boundaries? It would be nice. > 6.1.B) Should SOI tag its protocol with version numbers? Yes. > 6.1.C) Should SOI format be roughly the same as IKEv1? (See > discussion in section 6.4, re: code preserving) > > 6.2 Port number > > 6.2.A) Should SOI use the same port as IKEv1? (See discussion in > soi-features-01 the tradeoffs in this question). If keeping IKEv1 format may be done without drawbacks for SOI construction, then the same port should be used. But this 'versionning' issue is not a priority (for me). The process about it can be: a) Completing SOI format / exchanges design without any consideration of IKEv1 format. b) Afterward, is SOI format compatible with IKEv1's ? ->true: keep the same port. ->false: b.1) Can SOI format be slightly modified to match IKEv1's format ? ->true: modify and keep udp 500. ->false: initiate iana process for a new port. In a nutshell, formats matching is not, IMHO, a goal, but may be a nice side-effect of design. -- Jean-Jacques Puig From owner-ipsec@lists.tislabs.com Fri Jul 12 01:15:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6C8FPw19972; Fri, 12 Jul 2002 01:15:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA27466 Fri, 12 Jul 2002 03:29:10 -0400 (EDT) Date: Fri, 12 Jul 2002 09:42:21 +0200 (MET DST) Message-Id: <200207120742.JAA02539@hugo.int-evry.fr> From: Jean-Jacques Puig To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 5.3 SPD entries In-Reply-To: References: Organization: =?UTF-8?B?RMOpcGFydGVtZW50?= Logiciels - =?UTF-8?B?UsOpc2VhdQ==?= x X-Mailer: Sylpheed version 0.6.1 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Please discuss and answer the following question: > > 5.3 SPD entries > > 5.3.A) Is it important in SOI to allow the the responder to accept a subset > of the proposed SA, or should it be an all or nothing acceptance? All or nothing. > 5.3.B) Should the SOI offer multiple selectors with specific ports and > addresses, or a single selector with a range of ports and range of > addresses? (complicated boolean complexity!) List of ranges. > Implications from the scenarios: > > << subnets, a mechanism that allowed the negotiation of a list of phase 2 > identities will help to alleviate the number of IPsec tunnels that must > be created.>>> [[[5.3]]] > From owner-ipsec@lists.tislabs.com Fri Jul 12 01:47:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6C8ltw28656; Fri, 12 Jul 2002 01:47:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA27676 Fri, 12 Jul 2002 04:02:20 -0400 (EDT) Date: Fri, 12 Jul 2002 10:15:16 +0200 (MET DST) Message-Id: <200207120815.KAA02836@hugo.int-evry.fr> From: Jean-Jacques Puig To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 5.2 Scope of proposals In-Reply-To: References: Organization: =?UTF-8?B?RMOpcGFydGVtZW50?= Logiciels - =?UTF-8?B?UsOpc2VhdQ==?= x X-Mailer: Sylpheed version 0.6.1 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Please discuss and answer this question: > > 5.2 Scope of proposals > > 5.2.A) Is it important to have predefined suites or a la carte selection of > parameters? Suites should be enough: . I think there are currently in use a fairly little number of combinations of algorithms, and 'tuned home-made' combinations are usually not proven to add anything interesting, nor they are tested. . A la carte selection is expensive: the explosion of combinations of parameters does not help for communication setup, and the goal of an SA management protocol should be to setup or not to setup an SA, and not to search for a possible combination of parameters in order to ensure a setup. -- Jean-Jacques Puig From owner-ipsec@lists.tislabs.com Fri Jul 12 01:51:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6C8pdw29032; Fri, 12 Jul 2002 01:51:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA27623 Fri, 12 Jul 2002 03:56:17 -0400 (EDT) Message-ID: <3D2E8F0D.CB9D461F@F-Secure.com> Date: Fri, 12 Jul 2002 11:10:53 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Theodore Ts'o" CC: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION 6.1.c-6.2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2002 08:10:53.0967 (UTC) FILETIME=[A4A331F0:01C2297B] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Theodore Ts'o wrote: > 6.1.C) Should SOI format be roughly the same as IKEv1? (See > discussion in section 6.4, re: code preserving) > > 6.2 Port number > > 6.2.A) Should SOI use the same port as IKEv1? (See discussion in > soi-features-01 the tradeoffs in this question). > Instead of answering, let me pose another question here: Should SOI support NAT-traversal as defined by the following documents - draft-ietf-ipsec-udp-encaps-03.txt - draft-ietf-ipsec-nat-t-ike-03.txt ? The reason this is relevant is that if the answer is 'yes', the method specified in these documents can be simplified. I.e. the documents describe port floating in which the IKE changes the UDP port and IKE message formatting to include a non-ESP marker. The way to simplify this, should SOI choose to support this, would be a) choose a different port than 500 b) always put a non-ESP marker in the SOI packet, so it's always 'floated' This would simplify the protocol from using two ports to using just one, but with the cost of 4 bytes per every SOI packet, with or without NAT. Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Fri Jul 12 02:24:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6C9Nxw02497; Fri, 12 Jul 2002 02:24:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA27839 Fri, 12 Jul 2002 04:29:25 -0400 (EDT) Message-ID: <3D2E96D0.F98AD62E@F-Secure.com> Date: Fri, 12 Jul 2002 11:44:00 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Theodore Ts'o" CC: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 5.3 SPD entries References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2002 08:44:03.0359 (UTC) FILETIME=[466852F0:01C22980] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Theodore Ts'o wrote: > > Please discuss and answer the following question: > > 5.3 SPD entries > > 5.3.A) Is it important in SOI to allow the the responder to accept a subset > of the proposed SA, or should it be an all or nothing acceptance? > > 5.3.B) Should the SOI offer multiple selectors with specific ports and > addresses, or a single selector with a range of ports and range of > addresses? (complicated boolean complexity!) > > Implications from the scenarios: > > << subnets, a mechanism that allowed the negotiation of a list of phase 2 > identities will help to alleviate the number of IPsec tunnels that must > be created.>>> [[[5.3]]] It would be good to be able to configure a VPN client to be able to connect to 10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) and let the gateway figure out which of the network(s) is actually behind it, and return that subset in the return message. This would remove the need to pre-configure that information in the client. I know some vendors use config mode to convey that information from the gateway to the client, but that's not too nice a strategy for SOI. If the SA selectors must match correctly from the start, something config mode looking is likely to emerge. Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Fri Jul 12 02:32:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6C9W2w03215; Fri, 12 Jul 2002 02:32:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA27905 Fri, 12 Jul 2002 04:41:26 -0400 (EDT) Date: Fri, 12 Jul 2002 10:48:56 +0200 To: Harshwardhan Mittal Cc: ipsec@lists.tislabs.com Subject: Re: ipsec vs l2tp Message-ID: <20020712084856.GA2088@mccoy.bln.gelonet.local> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: =?iso-8859-1?Q?Mark-Andr=E9_Hopf?= Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu 11.07. 22:51, Harshwardhan Mittal wrote: > I need some article on "IPSEC vs L2TP" > > any link is highly welcomed, In case you mean 'IPsec with L2TP' I recommend RFC 3193. Mark -- mhopf@innominate.com dipl.-inf. Innominate Security Technologies AG software engineer networking people tel: +49.30.6392-3305 http://www.innominate.com/ From owner-ipsec@lists.tislabs.com Fri Jul 12 04:41:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CBf9w19800; Fri, 12 Jul 2002 04:41:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA28786 Fri, 12 Jul 2002 06:41:16 -0400 (EDT) Date: Fri, 12 Jul 2002 13:55:08 +0200 Message-Id: <200207121355.AA10813622@ismailia.ie-eg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "shsaad" Reply-To: To: ipsec@lists.tislabs.com CC: mittal@mihy.mot.com Subject: Re: IPSEC for mobile IP X-Mailer: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi IF I understand what you mean , I represent a company called esoft that makes a server appliance for VPN & Firewall , one of our server service is VPN Manager for Dynamic IP or Even VPN IPSEC or PPTP from clients behind NAT , please surf to www.esoft.com and click on VPN manager From owner-ipsec@lists.tislabs.com Fri Jul 12 05:45:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CCj6w27940; Fri, 12 Jul 2002 05:45:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA29197 Fri, 12 Jul 2002 07:53:35 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 6.3 Future versions of the protocols Phone: (781) 391-3464 Message-Id: Date: Fri, 12 Jul 2002 08:06:55 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here are the last set of questions, for your reading pleasure while you fly across the Pacific Ocean. :-) (Sorry I won't be able to join those of you who will be going to Yokohama; this will be the first IETF I've missed in something like ten years.) - Ted 6.3 Future versions of the protocols 6.3.A) Should SOI have a mechanism for demanding/requesting that a peer use a particular version of IKE/SOI to allow upgrading to new versions? Implications from the Scenarios: [none] From owner-ipsec@lists.tislabs.com Fri Jul 12 05:47:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CClZw28177; Fri, 12 Jul 2002 05:47:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA29198 Fri, 12 Jul 2002 07:53:35 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 6.4 Code-preservingness Phone: (781) 391-3464 Message-Id: Date: Fri, 12 Jul 2002 08:07:19 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer the following question: 6.4 Code-preservingness 6.4.A) Is it important that SOI allow some amounts of an IKEv1 implementation be reusable when creating an SOI implementation? Implications from the Scenarios: IPS: <<<[ietf-ips-security-xx.txt] discusses resource constraints, calling out the size for both code footprint and data as the most important criteria.>>> [[[6]]] From owner-ipsec@lists.tislabs.com Fri Jul 12 05:47:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CClZw28179; Fri, 12 Jul 2002 05:47:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA29212 Fri, 12 Jul 2002 07:54:34 -0400 (EDT) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: SOI QUESTION: 6.5 Extensibility of the protocols Phone: (781) 391-3464 Message-Id: Date: Fri, 12 Jul 2002 08:07:41 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please discuss and answer the following question (last one!): 6.5 Extensibility of the protocols 6.5.A) Should SOI have mechanisms for allowing extensions to the SOI protocol? 6.5.B) Should SOI need a way to mark new extensions as critical? (i.e. If you don't understand a critical extension you must fail the entire negotiation) Implications from the Scenarios: VPN, End-to-End, : <<>> [[[6.5]]] IPS: <<>> [[[6.5]]] PPVPN/MPLS: <<>> [[[6.5]]] Implications from the Scenarios: [none] From owner-ipsec@lists.tislabs.com Fri Jul 12 07:00:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CE0Sw03678; Fri, 12 Jul 2002 07:00:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29677 Fri, 12 Jul 2002 09:08:26 -0400 (EDT) Date: 12 Jul 2002 09:07:55 -0400 Message-ID: <000f01c229a5$23a1bca0$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Michael Richardson'" , " 'list'" Subject: RE: SOI QUESTIONS: 5.1-5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200207120236.g6C2ZvSW024119@marajade.sandelman.ottawa.on.ca> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I don't find this acceptable. > 1) in order to avoid permitting users to shoot themselves > in the foot, some > GUI will have to *restrict* them to those ciphersuites. The nice thing about GUI ciphersuites is that you could choose to implement only the 2 MUST IMPLEMENT combinations and nothing else, and you would be interoperable with everyone else, but other people could still implement the feature however they want. (Unless the aim of ciphersuites is to cripple everyone's implementation equally so that yours doesn't stand out for not giving the user the choice.) Part of the purpose of GUI ciphersuites is to give the user a convenient default configuration option. Of course they can still shoot themself in the foot if they try hard enough. ("I though ESP NULL was a block cipher...") > 2) Given the above, how do I test all combinations? > > Talk to your testing people on this. Let them make the decision. Our testers have a script for generating and negotiating every possible combination of algorithms. Personally, I don't think black box testing of this sort is very useful. It hearkens back to my previous example of the guy who wanted to test his FPGA DES implementation by trying every single key. I am more inclined to white box test all the important code paths. I would try each algorithm at least once. I would make sure to get at least one case where the keymat had to be stretched. I would try the largest key size to make sure no one hardcoded a buffer somewhere. Way back in the 80s (or perhaps even the 70s), someone invented the idea of modularity. Modularity makes testing every possible combination a luxury, rather than a necessity. The crypto code is first tested with known answer tests. Then the packet transform code is tested with the assumption that the crypto code works (perhaps using manual keying). Since the crypto is a black box, what you are testing is code that allocates buffers and moves memory around. A Neanderthal might "test" a gateway by first trying to eat it, then setting it on fire and finally by evaluating its potential as a weapon. In reality, random trial and error doesn't work so well. Proper testing requires human judgement, a knowledge of what the product is suppose to do, and some knowledge of how the code works internally. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael Richardson > Sent: Thursday, July 11, 2002 10:36 PM > To: ipsec@lists.tislabs.com > Subject: Re: SOI QUESTIONS: 5.1-5.2 > > > > >>>>> "Andrew" == Andrew Krywaniuk > writes: > >> 5.2.A) Is it important to have predefined suites or a la > >> carte selection of > >> parameters? > > Andrew> I prefer to have so-called "GUI ciphersuites" > where we allow negotiation of > Andrew> parameters on the wire, but define names for a > few specific combinations. > Andrew> These common names could then be used in a GUI to > ensure easy configuration > Andrew> of heterogeneous networks. The problem with > ciphersuites has traditionally > Andrew> been that not everyone is going to agree on every > parameter. Ciphersuites > Andrew> will force us to accomodate the lowest common > denominator (or perhaps the > > I don't find this acceptable. > 1) in order to avoid permitting users to shoot themselves > in the foot, some > GUI will have to *restrict* them to those ciphersuites. > > 2) Given the above, how do I test all combinations? > > Talk to your testing people on this. Let them make the decision. > > Suites rule. > > ] ON HUMILITY: to err is human. To moo, bovine. > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |net architect[ > ] mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |device driver[ > ] panic("Just another NetBSD/notebook using, kernel hacking, > security guy"); [ > From owner-ipsec@lists.tislabs.com Fri Jul 12 09:42:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CGgXw20842; Fri, 12 Jul 2002 09:42:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00754 Fri, 12 Jul 2002 11:54:14 -0400 (EDT) Date: Fri, 12 Jul 2002 12:07:58 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SOI QUESTION: 6.2 Port number In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 11 Jul 2002, Theodore Ts'o wrote: > 6.2.A) Should SOI use the same port as IKEv1? Desirable if the details permit software that is aware of SOI to easily tell the two protocols apart, e.g. version number in the same place or some other explicitly-defined, reliable strategy for distinguishing the two. Otherwise undesirable. Different protocols should have different ports. The "avoid timeout" argument in soi-features-01 assumes that the other end sends some sort of "huh?" reply on receiving stuff it doesn't understand. Some IKE implementations just log and discard, so a timeout is still needed. I would add: the SOI port should be solely for SOI (and possibly its ancestors/descendants). It should be off limits to other random protocols, e.g. NAT traversal. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Jul 12 09:48:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CGmYw21291; Fri, 12 Jul 2002 09:48:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00890 Fri, 12 Jul 2002 12:02:38 -0400 (EDT) Date: Fri, 12 Jul 2002 12:15:37 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: RE: SOI QUESTION: 5.2 Scope of proposals In-Reply-To: <000001c22951$798786d0$0402a8c0@trlhpc1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 11 Jul 2002, Jayant Shukla wrote: > > We NEED a MUST suite for end-to-end security to work. > > I don't completely agree. > What you NEED is a centralized management for e2e security to work... You're saying that it's completely impossible to design a protocol which will interoperate without centralized management? Why? We have many examples of Internet protocols which interoperate without any centralized management. There is no fundamental reason why crypto should not do likewise... and many reasons why it is highly desirable for it to do so. > MUST suite only solves part of the e2e problem. True. Other issues need solving too. They too can be solved. > Using the centralized > management, you can always ensure that host policies and suits are in > sync. Certain very important classes of communications problems inherently lack any centralized management. > > We need a backup > > suite to transition to should the initial suite turn out to be broken. > > If you know specifically what might turn out to be broken, one backup > will suffice. Otherwise you will need more than one backup......... Not necessarily. If the prime is AES+latestSHA, and the backup is 3DES+MD5, where is the common failure point? Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Jul 12 09:58:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CGwDw22035; Fri, 12 Jul 2002 09:58:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01008 Fri, 12 Jul 2002 12:14:48 -0400 (EDT) Date: Fri, 12 Jul 2002 12:28:02 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SOI QUESTION: 6. Wire protocol issues: Message Encoding In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 11 Jul 2002, Theodore Ts'o wrote: > 6.1.B) Should SOI tag its protocol with version numbers? Yes, in both directions. > 6.1.C) Should SOI format be roughly the same as IKEv1? (See > discussion in section 6.4, re: code preserving) It should be either (a) roughly the same as IKEv1 or (b) much simpler and cleaner. What should be avoided is inventing another complex mess; we already have one of those, and one is enough (or more than enough). Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Jul 12 09:59:07 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CGx6w22118; Fri, 12 Jul 2002 09:59:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01009 Fri, 12 Jul 2002 12:14:51 -0400 (EDT) Message-Id: <200207121627.g6CGREKc005574@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 6.5 Extensibility of the protocols In-reply-to: Your message of "Fri, 12 Jul 2002 08:07:41 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 12 Jul 2002 12:27:13 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Theodore" == Theodore Ts'o writes: Theodore> Please discuss and answer the following question (last one!): Theodore> 6.5 Extensibility of the protocols Theodore> 6.5.A) Should SOI have mechanisms for allowing extensions to the SOI Theodore> protocol? Yes. Otherwise, you have to ask question 6.3 again in five years. Theodore> 6.5.B) Should SOI need a way to mark new extensions as critical? Theodore> (i.e. If you don't understand a critical extension you must fail the Theodore> entire negotiation) Yes. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Fri Jul 12 10:10:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CHApw23476; Fri, 12 Jul 2002 10:10:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01078 Fri, 12 Jul 2002 12:21:59 -0400 (EDT) Message-Id: <200207121635.g6CGZ6sN005734@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTIONS: 5.1-5.2 In-reply-to: Your message of "12 Jul 2002 09:07:55 EDT." <000f01c229a5$23a1bca0$1e72788a@ca.alcatel.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 12 Jul 2002 12:35:05 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Andrew" == Andrew Krywaniuk writes: >> I don't find this acceptable. >> 1) in order to avoid permitting users to shoot themselves >> in the foot, some >> GUI will have to *restrict* them to those ciphersuites. Andrew> The nice thing about GUI ciphersuites is that you could choose to implement Andrew> only the 2 MUST IMPLEMENT combinations and nothing else, and you would be Andrew> interoperable with everyone else, but other people could still implement the Andrew> feature however they want. (Unless the aim of ciphersuites is to cripple Andrew> everyone's implementation equally so that yours doesn't stand out for not Andrew> giving the user the choice.) Part of the purpose of GUI Then how do you test all the code? >> 2) Given the above, how do I test all combinations? >> >> Talk to your testing people on this. Let them make the decision. Andrew> Our testers have a script for generating and negotiating every possible Andrew> combination of algorithms. Personally, I don't think black box testing of Andrew> this sort is very useful. I do. Particularly when certain *combinations* are accelerated by hardware. You have to make sure that you only use the hardware at the right times, and in the right modes. I have that script as well. I think that it is excessive featurism. Andrew> Way back in the 80s (or perhaps even the 70s), someone invented the idea of Andrew> modularity. Modularity makes testing every possible combination a luxury, Andrew> rather than a necessity. The crypto code is first tested with known answer Andrew> tests. Then the packet transform code is tested with the assumption that the Andrew> crypto code works (perhaps using manual keying). Since the crypto is a black Andrew> box, what you are testing is code that allocates buffers and moves memory It is a nice theory. It works a lot of the time. It also fails to catch interactions among different pieces of the system. *UNTIL* someone tries to optimize things. Or the GUI people are told my marketing to enable to FOO,BAR,BUMBLE combination because they need it for a demo, and none of *them* realize that this combination has never been tested. One might optimize because of code size (remember those PDA/phone people) from a generic base. The theory people also say that suites are a *LOT* easier to analyze. The hardware people like suites, because it makes their hardware simpler and provides them a better picture of what needs to be implemented. Remember that testing of the VHDL/Verilog has to be done TOO. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPS8FNoqHRg3pndX9AQGwZQQAspydOasCqMVpc+sFmrecxXXm92E1ssjJ t684G5lU/R/rzxcUy9y/INsjN9NVI97UPuOuT/8C50zZ8IYjR73QPI2yw0gBrMgm fllB8qDRsnfrJPukiyT6MJpw+OHqNTDHAvHqKWwhp3d96JpYC2ZKkSRLd8v0/WTM oP5K9nRrQhc= =0B6v -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Jul 12 11:10:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CIA1w00267; Fri, 12 Jul 2002 11:10:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01038 Fri, 12 Jul 2002 12:17:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20020712092005.0291c958@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Jul 2002 09:29:59 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: Agenda Items Solicitation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Both Ted and I have been on the road for the last 3-4 weeks and we failed to send this note earlier. If you have items you'd like to have on the agenda please let us know. We'll be working on the agenda right up to the Wed. meeting. thanks, Barb and Ted From owner-ipsec@lists.tislabs.com Fri Jul 12 14:16:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CLGvw19379; Fri, 12 Jul 2002 14:16:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02572 Fri, 12 Jul 2002 16:26:49 -0400 (EDT) Message-Id: <200207122039.g6CKd8R2010941@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 5.3 SPD entries In-reply-to: Your message of "Thu, 11 Jul 2002 16:31:37 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 12 Jul 2002 16:39:07 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Theodore" == Theodore Ts'o writes: Theodore> Please discuss and answer the following question: Theodore> 5.3 SPD entries Theodore> 5.3.A) Is it important in SOI to allow the the responder to Theodore> accept a subset Theodore> of the proposed SA, or should it be an all or nothing acceptance? yes. This is a major advantage to end-2-end systems such as Opportunistic Encryption. But, for this to work, the initiator needs to provide the responder with an indication of its intent - why is it negotiating at this time - I believe that this is best done by including L3/L4 headers from the packet that caused the negotiation to begin. If there is no such packet (i.e. this is a preconfigured "up" tunnel) then the responder needs to know that. The proposed policy will likely have to match (this is a local matter). Theodore> 5.3.B) Should the SOI offer multiple selectors with specific ports and Theodore> addresses, or a single selector with a range of ports and range of Theodore> addresses? (complicated boolean complexity!) We *do* need the boolean complexity. There should be only a single way to express selectors - ranges being the most general, even if most implementations will only permit strict netmasks for addresses. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPS8+aYqHRg3pndX9AQH5FQP/QLKK+GbzTESt0d5eRtZ0vjEa1gAHUnvN ppQgNAjz/Twr/KgGb4eYjxOzAesre3eHBB6cjmqz9O9EEtwrmaNwcT7A+orlWYlp jP39Y2IqHVLQ9MWNjcYZkagioNbbf4X/nKkv7PBxXundz4G7ntKs+oxYgABwLjC4 GBS3KQAQRUs= =lioa -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Jul 12 14:16:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CLGvw19380; Fri, 12 Jul 2002 14:16:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02621 Fri, 12 Jul 2002 16:34:50 -0400 (EDT) Message-Id: <200207122047.g6CKltiL011115@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 6.3 Future versions of the protocols In-reply-to: Your message of "Fri, 12 Jul 2002 08:06:55 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 12 Jul 2002 16:47:55 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Theodore" == Theodore Ts'o writes: Theodore> Here are the last set of questions, for your reading pleasure while you Theodore> fly across the Pacific Ocean. :-) (Sorry I won't be able to join those Theodore> of you who will be going to Yokohama; this will be the first IETF I've Theodore> missed in something like ten years.) Speaking of which - anyone got a multicast feed they could share? Theodore> 6.3 Future versions of the protocols Theodore> 6.3.A) Should SOI have a mechanism for demanding/requesting that a Theodore> peer use a particular version of IKE/SOI to allow upgrading to new Theodore> versions? I'm not sure that I understand the question. It presumes that SOI runs on the same port (which I support) and that it carry version info (also a good idea). Obviously when an IKEv1 initiators to a SOI, there are two possible responses: 1) responder drops to IKEv1 mode. 2) responder refuses to negotiate I don't see how we can tell an IKEv1 to do anything that it doesn't already do. (So, we can send an un-authenticated Notify that says "I only do SOI v2.6", but that's about it) When an SOI initiates to an IKEv1, if one is lucky, one gets an IKEv1 message complaining about wrong versions, etc. What else can one do there? Now, if you are talking about SOI v2 talking to SOIv3, we might design something. There is a third possibility: Always initiate with something that looks like IKEv1 with a proposal that is SOI specific, or a vendorID that says "I can do SOI". An aware responder then sees that and initiates or replies in a useful way to switch to SOI. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPS9AdoqHRg3pndX9AQHaCgP/TLXdI8YeN7h4fYrP6e9Xv7i7lVcRGmFU qrzCKVgh5Sw5ipbtpkzrAo2GYq/f73HQM1Dty0joe9AMvng4oVtRznRVRQmdSLiL 1zhE7mqdFDD0myWAyh4YxHy5aWSvKx2IR3Zmjd5uEk+eXcd1HHoMasXD/cfuY2GP IRh7w5mVTI0= =v3uS -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Jul 12 14:57:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CLvnw22781; Fri, 12 Jul 2002 14:57:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02953 Fri, 12 Jul 2002 17:18:58 -0400 (EDT) Message-Id: <200207122131.g6CLVpmK012157@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com CC: Barbara Fraser Subject: Re: Agenda Items Solicitation In-reply-to: Your message of "Fri, 12 Jul 2002 09:29:59 PDT." <4.3.2.7.2.20020712092005.0291c958@mira-sjc5-4.cisco.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 12 Jul 2002 17:31:51 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is only one agenda item: SOI. There should be *NO* presentations, just mike time. From owner-ipsec@lists.tislabs.com Fri Jul 12 15:18:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CMIDw25437; Fri, 12 Jul 2002 15:18:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA03047 Fri, 12 Jul 2002 17:35:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3D2E96D0.F98AD62E@F-Secure.com> References: <3D2E96D0.F98AD62E@F-Secure.com> Date: Fri, 12 Jul 2002 17:40:42 -0400 To: Ari Huttunen From: Stephen Kent Subject: Re: SOI QUESTION: 5.3 SPD entries Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:44 AM +0300 7/12/02, Ari Huttunen wrote: >Theodore Ts'o wrote: >> >> Please discuss and answer the following question: >> >> 5.3 SPD entries >> >> 5.3.A) Is it important in SOI to allow the the responder to accept a subset >> of the proposed SA, or should it be an all or nothing acceptance? >> >> 5.3.B) Should the SOI offer multiple selectors with specific ports and >> addresses, or a single selector with a range of ports and range of >> addresses? (complicated boolean complexity!) >> >> Implications from the scenarios: >> >> <<> subnets, a mechanism that allowed the negotiation of a list of phase 2 >> identities will help to alleviate the number of IPsec tunnels that must >> be created.>>> [[[5.3]]] > >It would be good to be able to configure a VPN client to be able >to connect to > 10.0.0.0 - 10.255.255.255 (10/8 prefix) > 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) > 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) >and let the gateway figure out which of the network(s) is actually >behind it, and return that subset in the return message. This would >remove the need to pre-configure that information in the client. >I know some vendors use config mode to convey that information from >the gateway to the client, but that's not too nice a strategy for SOI. >If the SA selectors must match correctly from the start, something >config mode looking is likely to emerge. I agree with the desirability of allowing subset selection, a point you and Michale have made. But in preparing 2401bis I need to have a simple algorithm for how the initiator deals with this reduction of scope in a proposal. I am especially concerned about what should happen if the reduced scope selector set is cached (for high performance in a security gateway) and if a subsequent packet arrives which would have matched the proposed, broader selector set, but not the narrower set that was negotiated. if we can get agreement on the required behavior in all cases, I'm amenable to making these sorts of changes, but a goal in the revision of 2401 is to make clearer exactly how an IPsec implementation must behave. Steve From owner-ipsec@lists.tislabs.com Fri Jul 12 15:20:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CMKmw25611; Fri, 12 Jul 2002 15:20:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA03092 Fri, 12 Jul 2002 17:40:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <4.3.2.7.2.20020709135351.0251a3f0@mira-sjc5-6.cisco.com> References: <4.3.2.7.2.20020709135351.0251a3f0@mira-sjc5-6.cisco.com> Date: Fri, 12 Jul 2002 17:54:33 -0400 To: Mark Baugher From: Stephen Kent Subject: Re: new version of ESP ID Cc: ipsec@lists.tislabs.com, msec@securemulticast.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, > >I don't understand the distinction between static and dynamic SAs. >Is the distinction between a single-sender multicast SA versus >a multi-sender multicast SA? > >I think that it is a more robust solution to identify the multicast >SA using the source address as well as the SPI and destination >address. This is what many of us who worked in smug thought we >would do with MESP. Now that Steve is addressing multicast in >ESP and AH, it's not clear to me how msec should proceed with >MESP. > There is a big distinction between single and multi-sender SAs, as we have discussed. One cannot make use of anti-replay for a multi-sender SA, unless we seriously change the model and I explained in my message to Bill why I don't think that's a reasonable change to pursue. I am opposed to the suggestion to use both source and destination address for demuxing multicast SAs, as it just adds to the comparisons that need to me made. As more folks go to high speed hardware implementations, using more fields for demuxing turns into more CAM entries, ... Why can't we swap destination address demuxing for source address demuxing for multicast? Steve From owner-ipsec@lists.tislabs.com Fri Jul 12 15:21:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CMLTw25660; Fri, 12 Jul 2002 15:21:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA03093 Fri, 12 Jul 2002 17:41:04 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200207091659.JAA15664@windsor.research.att.com> References: <200207091659.JAA15664@windsor.research.att.com> Date: Fri, 12 Jul 2002 17:50:16 -0400 To: Bill Fenner From: Stephen Kent Subject: Re: new version of ESP ID Cc: ipsec@lists.tislabs.com, msec@securemulticast.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:59 AM -0700 7/9/02, Bill Fenner wrote: > >First, section 2.2 deprecates sharing an SA among multiple senders to a >>multicast group and in effect mandates single-sender multicast for ESP >>groups. The same is true for AH. I'm aware of only one protocol, the VRRP >>specification, that is affected by this change. VRRP uses AH or ESP but >>allows multi-source multicast groups. We should notify the VRRP WG of this >>potential change. > >I brought this up at the WG meeting in Minneapolis. Several protocols >that send multicasts on a LAN use this model (VRRP, OSPFv3, PIM, >IGMP come to mind). > >I'd like to see two possible modes for use with multicast: >- anti-replay sequence number per sender, with a shared SA. >- including the source address when demultiplexing to permit SSM semantics. > >I know that at least the first is completely opposite of the direction >that the group has been going. However, especially with 64-bit anti-replay >sequence numbers, it permits protocols to use a standard, existing protocol >even when using static shared SAs. Yes, a static shared SA buys you much >less protection than dynamically negotiated ones, but does that mean that it >should be ruled out? > > Bill If we include the source address for multicast, to accommodate SSM, does that mean I don't have to pay attention to the destination for any multicast protocol. That would be a sort of equal tradeoff, moving from requiring that an SA be defined by source and SPI instead of destination and SPI, for multicast. But I don't want to make life more complex by requiring support for all three. The replay window per sender is more problematic. It breaks the simple model of one replay window per SA, and that could have very serious implications for hardware devices that choose to keep this data on chip. With a one-to-one correspondence between SAs and replay windows, it's easy to understand how to allocate space. But an unbounded number of senders on one SA, each with a separate replay window, is not attractive. If we use the source address plus SPI to define a multicast SA, then each sender gets its own SA and replay window, by definition. I don't want to see two modes for multicast. In general, we're trying to simplify IPsec requirements as we go along, and this would add complexity. Steve From owner-ipsec@lists.tislabs.com Fri Jul 12 16:59:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6CNxTw02059; Fri, 12 Jul 2002 16:59:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA03670 Fri, 12 Jul 2002 19:17:39 -0400 (EDT) Message-Id: <200207122330.g6CNUgL18716@sydney.East.Sun.COM> Date: Fri, 12 Jul 2002 19:30:40 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: new version of ESP ID To: fenner@research.att.com, kent@bbn.com Cc: ipsec@lists.tislabs.com, msec@securemulticast.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iIhgrK+GxLRYve7FFcQRaw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From: Stephen Kent Subject: Re: new version of ESP ID Cc: ipsec@lists.tislabs.com, msec@securemulticast.org If we include the source address for multicast, to accommodate SSM, does that mean I don't have to pay attention to the destination for any multicast protocol. That would be a sort of equal tradeoff, moving from requiring that an SA be defined by source and SPI instead of destination and SPI, for multicast. But I don't want to make life more complex by requiring support for all three. I don't think we can get away with that. (S,G1) would be a whole different set of members than (S,G2), and would therefore want to have different keys, etc. Radia From owner-ipsec@lists.tislabs.com Mon Jul 15 00:13:37 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6F7Daw08226; Mon, 15 Jul 2002 00:13:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA16679 Mon, 15 Jul 2002 02:10:58 -0400 (EDT) From: peter.mathes@gmx.de Date: Mon, 15 Jul 2002 08:24:09 +0200 (MEST) To: ipsec@lists.tislabs.com MIME-Version: 1.0 Subject: AES-CBC draft: Tunnel mode, TTL field of inner header X-Priority: 3 (Normal) X-Authenticated-Sender: #0001516144@gmx.net X-Authenticated-IP: [203.200.20.157] Message-ID: <21872.1026714249@www43.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear all, I just came across one point in the Internet Draft "The AES Cipher Algorithm and Its Use With IPsec", , June 2002 that made me wonder. In the last two test vectors (7&8) provided with the draft ESP packets in tunnel mode are encryted with AES-CBC. Although RFC 2401 specifies in (5.1.2) to decrement the TTL field of the inner header this is not done in the two mentioned test cases: ---------------- Case #7: Original packet: IP header (20 bytes): 45000054 09040000 4001f988 c0a87b03 c0a87bc8 ^^ . . . Pre-encryption Data with original IP header, padding, pad length and next header (96 bytes): 45000054 09040000 4001f988 c0a87b03 ... ^^ ------------------ And also the ciphertext is based on the plaintext with TTL = 40. Mistake? Changes in the specification? Thanks, Peter Mathes -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From owner-ipsec@lists.tislabs.com Mon Jul 15 02:49:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6F9niw26729; Mon, 15 Jul 2002 02:49:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA17095 Mon, 15 Jul 2002 05:02:18 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Subject: Re: Agenda Items Solicitation Date: Mon, 15 Jul 2002 02:15:26 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC105D017A7@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Agenda Items Solicitation thread-index: AcIp7WSXLFlpR9wxSBC09wdpMe4+dgB8PLlA From: "William Dixon" To: "Michael Richardson" , Cc: "Barbara Fraser" X-OriginalArrivalTime: 15 Jul 2002 09:15:26.0512 (UTC) FILETIME=[2817EB00:01C22BE0] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We don't have to spend meeting time on this, but can we get an update on: Status of draft-ietf-ipsec-ike-modp-groups-04.txt ? Status of AES counter mode ? I'm willing to do a 5min update on NAT-T as well - which I'll mail to the list. From owner-ipsec@lists.tislabs.com Mon Jul 15 04:06:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6FB6mw05215; Mon, 15 Jul 2002 04:06:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA17372 Mon, 15 Jul 2002 06:23:33 -0400 (EDT) Message-ID: <3D32A5A4.84E529EB@bstormnetworks.com> Date: Mon, 15 Jul 2002 03:36:21 -0700 From: "Scott G. Kelly" Organization: Black Storm Networks X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: peter.mathes@gmx.de CC: ipsec@lists.tislabs.com Subject: Re: AES-CBC draft: Tunnel mode, TTL field of inner header References: <21872.1026714249@www43.gmx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Peter, Looks like an oversight in the draft. Thanks for your thorough review - we'll get this corrected in the next revision. Scott peter.mathes@gmx.de wrote: > > Dear all, > I just came across one point in the Internet Draft "The AES Cipher Algorithm > and Its Use With IPsec", , June 2002 > that made me wonder. In the last two test vectors (7&8) provided with the > draft ESP packets in tunnel mode are encryted with AES-CBC. Although RFC 2401 > specifies in (5.1.2) to decrement the TTL field of the inner header this is not > done in the two mentioned test cases: > > ---------------- > Case #7: > > Original packet: > IP header (20 bytes): 45000054 09040000 4001f988 c0a87b03 c0a87bc8 > ^^ > . > . > . > > Pre-encryption Data with original IP header, padding, pad length and > next header (96 bytes): > 45000054 09040000 4001f988 c0a87b03 ... > ^^ > > ------------------ > > And also the ciphertext is based on the plaintext with TTL = 40. > > Mistake? Changes in the specification? > > Thanks, > Peter Mathes > > -- > GMX - Die Kommunikationsplattform im Internet. > http://www.gmx.net From owner-ipsec@lists.tislabs.com Mon Jul 15 06:31:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6FDVaw13910; Mon, 15 Jul 2002 06:31:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17560 Mon, 15 Jul 2002 08:39:51 -0400 (EDT) Message-ID: <3D32C61B.8020200@nomadiclab.com> Date: Mon, 15 Jul 2002 15:54:51 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020608 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com, ietf-send@standards.ericsson.net Subject: Reminder: Secure Neighbor Discovery (SEND) BOF tomorrow Tuesday at 5pm Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (Apologies for the cross posting.) Folks, I just want to remind you that a BOF on Securing IPv6 Neighbor Discovery (SeND) is going to talk place tomorrow (on Tuesday) at 5pm in room 303. The mailing list archive is available at http://standards.ericsson.net/lists/ietf-send/maillist.html There are only about 30 messages at the archive. Other than the archive, there aren't any specific web pages for the BOF, yet. The proposed charter can be found in a recent message, at http://standards.ericsson.net/lists/ietf-send/msg00029.html The BOF agenda, with the required reading list, is available at http://standards.ericsson.net/lists/ietf-send/msg00030.html We have only one hour available for the BOF, and a largish number of presentations. Thus, it is highly adviced to read the drafts beforehand. Most of the drafts are short; none of them are over 20 pages, and many less than 10. --Pekka Nikander (co-chair) From owner-ipsec@lists.tislabs.com Mon Jul 15 06:47:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6FDlMw14385; Mon, 15 Jul 2002 06:47:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17672 Mon, 15 Jul 2002 09:04:59 -0400 (EDT) Message-Id: <4.3.2.7.2.20020715085638.00b11210@email.nist.gov> X-Sender: sfrankel@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Jul 2002 09:07:06 -0400 To: peter.mathes@gmx.de From: Sheila Frankel Subject: Re: AES-CBC draft: Tunnel mode, TTL field of inner header Cc: ipsec@lists.tislabs.com, "Scott G. Kelly" In-Reply-To: <21872.1026714249@www43.gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear Peter, Thank you very much for your comment and your detailed reading of the draft. However, I believe that the test cases' TTLs in the draft are correct. In section 5.1.2.1, RFC 2401 says that the encapsulator decrements the TTL prior to forwarding. However, there is a caveat mentioned in Note 2: "Packets originating from the same node as the encapsulator do not have their TTL's decremented, as the sending node is originating the packet rather than forwarding it." This is the case in Test cases 7 & 8, since the source address in both the tunnel header and the inner header is the same. Sheila sheila.frankel@nist.gov At 02:24 AM 7/15/02, peter.mathes@gmx.de wrote: >Dear all, >I just came across one point in the Internet Draft "The AES Cipher Algorithm >and Its Use With IPsec", , June 2002 >that made me wonder. In the last two test vectors (7&8) provided with the >draft ESP packets in tunnel mode are encryted with AES-CBC. Although RFC 2401 >specifies in (5.1.2) to decrement the TTL field of the inner header this >is not >done in the two mentioned test cases: > >---------------- >Case #7: > >Original packet: >IP header (20 bytes): 45000054 09040000 4001f988 c0a87b03 c0a87bc8 > ^^ >. >. >. > >Pre-encryption Data with original IP header, padding, pad length and >next header (96 bytes): >45000054 09040000 4001f988 c0a87b03 ... > ^^ > >------------------ > >And also the ciphertext is based on the plaintext with TTL = 40. > > >Mistake? Changes in the specification? > > >Thanks, >Peter Mathes > > >-- >GMX - Die Kommunikationsplattform im Internet. >http://www.gmx.net From owner-ipsec@lists.tislabs.com Mon Jul 15 16:00:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6FN0mw09612; Mon, 15 Jul 2002 16:00:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18569 Mon, 15 Jul 2002 18:05:18 -0400 (EDT) Message-Id: <4.3.2.7.2.20020715151610.023d68d0@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Jul 2002 15:17:42 -0700 To: "William Dixon" From: Barbara Fraser Subject: Re: Agenda Items Solicitation Cc: "Michael Richardson" , In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC105D017A7@win-msg-01.wingro up.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm planning to spend a short amount of time reviewing the status on various documents. If you'd like to do 5 mins on NAT-T that would be fine. Barb At 02:15 AM 7/15/2002, William Dixon wrote: >We don't have to spend meeting time on this, but can we get an update >on: > >Status of draft-ietf-ipsec-ike-modp-groups-04.txt ? >Status of AES counter mode ? > >I'm willing to do a 5min update on NAT-T as well - which I'll mail to >the list. From owner-ipsec@lists.tislabs.com Tue Jul 16 03:44:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6GAihw28530; Tue, 16 Jul 2002 03:44:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA19454 Tue, 16 Jul 2002 05:35:18 -0400 (EDT) Message-Id: <4.3.2.7.2.20020716020635.02b86508@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Jul 2002 02:14:57 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: Draft Agenda for 7/17/02 Cc: byf@cisco.com, tytso@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Wednesday, July 17, 2002 1530-1730 Room 301/302 Draft Agenda Status of current docs: Fraser Updated AH draft: Kent IPsec and mobile IPv6: Dupont SOI discussion summary: Kaufman SOI Open mic SOI schedule From owner-ipsec@lists.tislabs.com Tue Jul 16 19:45:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H2jXw11887; Tue, 16 Jul 2002 19:45:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20741 Tue, 16 Jul 2002 21:59:55 -0400 (EDT) Message-Id: <200207170213.g6H2DNGF067275@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Theodore Ts'o" cc: ipsec@lists.tislabs.com Subject: Re: SOI QUESTION: 4.2 Creating multiple SAs for a single pair of entities In-reply-to: Your message of Tue, 25 Jun 2002 09:43:57 EDT. Date: Wed, 17 Jul 2002 04:13:23 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is needed by Mobile IPv6 (there should be at least 3 SA pairs between a Mobile Node and its Home Agent to protect Binding Updates, Return Routability test messages and prefix discovery). Regards Francis.Dupont@enst-bretagne.fr PS: they can't be merged in less than two pairs even using a protect everything policy. From owner-ipsec@lists.tislabs.com Tue Jul 16 21:17:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H4HMw13793; Tue, 16 Jul 2002 21:17:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA20860 Tue, 16 Jul 2002 23:34:10 -0400 (EDT) X-Authentication-Warning: kaakeli.ssh.fi: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15668.59539.503912.11677@kaakeli.ssh.fi> Date: Wed, 17 Jul 2002 06:46:27 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com, tytso@mit.edu ("Theodore Ts'o") Subject: Re: SOI QUESTION: 6.3, 6.4, 6.5 X-Mailer: VM 7.00 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 6.3 Future versions of the protocols > 6.3.A) Should SOI have a mechanism for demanding/requesting that a > peer use a particular version of IKE/SOI to allow upgrading to new > versions? I don't really understand the question... > 6.4 Code-preservingness > 6.4.A) Is it important that SOI allow some amounts of an IKEv1 > implementation be reusable when creating an SOI implementation? Yes. > 6.5 Extensibility of the protocols > 6.5.A) Should SOI have mechanisms for allowing extensions to the SOI > protocol? Yes, and we should define what to do with unknown extensions, ie what is expected behavior (ignore, return error, fail). > 6.5.B) Should SOI need a way to mark new extensions as critical? > (i.e. If you don't understand a critical extension you must fail the > entire negotiation) Yes. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jul 16 22:03:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H53mw14377; Tue, 16 Jul 2002 22:03:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA20977 Wed, 17 Jul 2002 00:18:19 -0400 (EDT) Message-Id: <200207170430.g6H4Umue010520@marajade.sandelman.ottawa.on.ca> To: IP Security List Subject: agenda? Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 17 Jul 2002 00:30:47 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Is there a final agenda for the session? (maybe I missed it?) I would ask that someone post it to the list if possible - the H.261 which I'm getting via unicast tunnel from Finland doesn't provide enough resolution to read the overhead. Even better is if someone will tell me what item we are on in IRC. The audio is... tolerable. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPTTy8YqHRg3pndX9AQHGUgQAo8Mv4Vrcf22o654aCWayL0vvoQUdA11s gmtsx1kwMmygzgzZVhL9+B1pB0ZeWJ3GfXbpsdiU1CKchpx/dlry0yGQUAykUu83 Z2lb7WsLq+2PtEwZ9yhGK2rVqOH9hWxSkwE5Z561HnJxeHvhLf8ZUKtYv3BAMKsD Sn9YPTMJlps= =C0wO -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Jul 16 23:35:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H6ZGw23738; Tue, 16 Jul 2002 23:35:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA21150 Wed, 17 Jul 2002 01:49:35 -0400 (EDT) Message-ID: <3D3508EC.4050805@kolumbus.fi> Date: Wed, 17 Jul 2002 09:04:28 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: ipsec@lists.tislabs.com Subject: Re: IPsec and Mobile IPv6 References: <200207082320.g68NKZGF039788@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.2 required=5.0 tests=GAPPY_TEXT version=2.20 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Francis, > The second version of my draft about IPsec and Mobile IPv6 is > available (name : draft-dupont-ipsec-mipv6-01.txt). Your draft looks like a very useful analysis of various cases regarding mobility and IPsec. But I still lack some practical background information so that this work could be taken in account in the relevant protocol descriptions. In particular, could you classify your recommendations as 1) Those that restate something which already is in the current protocol specifications (but perhaps not stated clearly enough). 2) Those which fix something that would break MIPv6 security. Draft draft-ietf-mobileip-ipv6-18.txt uses IPsec for a part of its security, namely for the HA - MN signaling. A more detailed description including SPD entries can be found from http://www.piuha.net/~jarkko/publications/mipv6/ipsec_usage.txt 3) Those which fix something that would break IPsec when used for protecting regular payload traffic in the presense of MIPv6. 4) Those that make IPsec work smoother, more efficiently, or with less configuration when used together with mobility or for the protection of mobility signaling. 5) Architectural long-term recommendations. 6) Something completely different. In particular class 2 is interesting for completing the MIPv6 work, as is class 3. From my initial understanding, your recommendations can be classified as follows: 1) A, C1, C2, E1, E2, E3, G, H, I, K, M, O, Q 2) P [makes use of IKE for HA-MN security hard -- this is very interesting, thanks!] 3) nothing? 4) B, F [and I think we were disagreeing on the mip list whether these two are good goals], L1, L2, R 5) nothing? 6) D [of course!], J unclear: N Is this correct? How do we go about fixing P, is your recommendation the only way to handle that? Is there anything in the MIPv6 documents that you'd like to clarify in class 1? Jari From owner-ipsec@lists.tislabs.com Wed Jul 17 00:46:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H7ktw04195; Wed, 17 Jul 2002 00:46:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA21269 Wed, 17 Jul 2002 02:57:44 -0400 (EDT) Message-ID: From: Russell Dietz To: ipsec@lists.tislabs.com Subject: SHA-256-128 Draft: Is this really required? Contradiction... Date: Wed, 17 Jul 2002 00:14:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Folks, In reviewing the latest SHA-256 draft, "The HMAC-SHA-256-128 Algorithm and Its Use With IPsec", , June 2002, I notice a contradiction and a point which I (and others) believe, eliminates the need for the document to progress, even as an experimental. In the draft, the authors state that... "HMAC-SHA-1-96 [HMAC-SHA] (Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH," RFC2404, November 1998.) provides sufficient security at a lower computational cost [then this SHA-2 draft]". ...the draft then states... "The goal of HMAC-SHA-256-128 is to ensure that the packet is authentic and cannot be modified in transit." ...this is the 'goal' of HMAC-SHA-1-96 as it stands today. In addition, while the new SHA-256 algorithm is definitely useful in other contexts, in fact there is no evidence that DRAFT-SHA-256 provides any meaningful additional cryptographic security over the HMAC-SHA-1-96 algorithm defined in RFC2404 and already in widespread use for packet authentication in IPSec. For all we know, quite the contrary may be true, as SHA-256 is a new transform and thus has seen considerably less public review so far than SHA1 has already received. In any case, it is extremely unlikely that HMAC-SHA1 will be the weak point in any system using IPSec. Hence, it is not clear that trying to improve its security makes any sense, given the costs and instability associated with such a change. Given this and the fact that SHA-256 is has no known cryptographic benefit to implementing this proposed standard, there is no reason, even on an experimental basis, for the IPSec WG to progress this document. Regards, Russell Dietz Hifn, Inc. 750 University Ave Los Gatos, CA, USA 95032-7695 Tel: +1 408 399-3623 pgp-fingerprint: CEE3 58B0 DD09 4EA5 7266 BF1E B5F6 4D1A 4AD1 65B4 From owner-ipsec@lists.tislabs.com Wed Jul 17 01:08:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H88aw08825; Wed, 17 Jul 2002 01:08:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA21394 Wed, 17 Jul 2002 03:20:50 -0400 (EDT) Message-Id: <200207170734.g6H7YYGF068039@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: ipsec@lists.tislabs.com Subject: Re: IPsec and Mobile IPv6 In-reply-to: Your message of Wed, 17 Jul 2002 09:04:28 +0300. <3D3508EC.4050805@kolumbus.fi> Date: Wed, 17 Jul 2002 09:34:34 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The security flawn with NAT traversal and IKE is described in: draft-dupont-transient-pseudonat-00.txt Francis.Dupont@enst-bretagne.fr PS: I don't know what to do for the future of this draft? From owner-ipsec@lists.tislabs.com Wed Jul 17 01:21:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H8Lew11204; Wed, 17 Jul 2002 01:21:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA21484 Wed, 17 Jul 2002 03:41:53 -0400 (EDT) Message-Id: <200207170753.g6H7ro8Z013283@marajade.sandelman.ottawa.on.ca> To: "Scott G. Kelly" CC: ipsec@lists.tislabs.com Subject: Re: agenda? In-reply-to: Your message of "Wed, 17 Jul 2002 00:40:12 PDT." <3D351F5C.451FE840@bstormnetworks.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 17 Jul 2002 03:53:49 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly writes: Scott> Hi Michael, Scott> I don't have IRC configured on my system, but wanted to check to Scott> see if Scott> anyone had responded, and/or if you have any concerns/questions Scott> you'd Scott> like to see addressed... Charlie's summary was very good. I'm happy about the schedule proposed. We call "preferred ID of responder" the "Me-Tarzan/You-Jane". This system is pretty important to us. There is a short writeup at: http://lists.freeswan.org/pipermail/design/2002-May/002514.html I concur with William - the requirements need to be finished. We need to write the Opportunistic Encryption scenario. A way to do versioning is CRITICAL. As are VENDOR extensions. Yes, a vendor extension may have the "critical" bit set - that means that if you don't get it you refuse to negotiate. I think that either I misunderstood Steve Bellovin, or he misunderstood what was said.... Oh, I concur with Eric Rescorla - the problem is the documents, and frankly, with the totally VAGUE PKI confusion, and certain PKI vendors who just don't get it. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPTUiioqHRg3pndX9AQFfIAQA1RzGvOi52o3NAkrAJD90srvHKPaW16sy u8Mq+7Ajhux+CDatGIUXqGq2ehG6J1ITyJRdTf0m7xxgYleSI5tIrEhX86+5RysE YNPX6dWTZqgGO17UikL4TkADk9zuPJtuS3jBji24L6VCbMFXqD77iqvwyhGwNitz 9QsrPX3bf8w= =exYV -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Jul 17 01:29:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H8Tuw12158; Wed, 17 Jul 2002 01:29:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA21513 Wed, 17 Jul 2002 03:51:52 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87060C06@SARATOGA> From: Gregory Lebovitz To: "'ipsec@lists.tislabs.com'" Subject: One base SOI ID? Humm Date: Wed, 17 Jul 2002 00:59:23 -0700 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Barbara just said that if more of this community were physically here at 54 in Yokohama, she would take a humm poll about whether to move forward with one SOI ID, one bail of hay. Here we go... "hum via email if you agree with the two ID authors coming back to the list with one ID for us to move forward discussing." Here's mine: HMMMMM!!! From owner-ipsec@lists.tislabs.com Wed Jul 17 08:41:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6HFfbw09962; Wed, 17 Jul 2002 08:41:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22231 Wed, 17 Jul 2002 10:48:20 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15669.34526.65000.894563@gargle.gargle.HOWL> Date: Wed, 17 Jul 2002 11:01:50 -0400 From: Paul Koning To: Gregory@netscreen.com Cc: ipsec@lists.tislabs.com Subject: Re: One base SOI ID? Humm References: <541402FFDC56DA499E7E13329ABFEA87060C06@SARATOGA> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 17 July 2002) by Gregory Lebovitz: > Barbara just said that if more of this community were physically here at 54 > in Yokohama, she would take a humm poll about whether to move forward with > one SOI ID, one bail of hay. > > Here we go... > > "hum via email if you agree with the two ID authors coming back to the list > with one ID for us to move forward discussing." > > Here's mine: HMMMMM!!! HMMMMM too. paul From owner-ipsec@lists.tislabs.com Wed Jul 17 16:23:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6HNNEw04725; Wed, 17 Jul 2002 16:23:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23192 Wed, 17 Jul 2002 18:35:37 -0400 (EDT) Message-ID: From: Russell Dietz To: "'ipsec@lists.tislabs.com'" Subject: RE: One base SOI ID? Humm Date: Wed, 17 Jul 2002 15:52:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'll and mine! HMMM! Russ -----Original Message----- From: Gregory Lebovitz [mailto:Gregory@netscreen.com] Sent: Wednesday, July 17, 2002 12:59 AM To: 'ipsec@lists.tislabs.com' Subject: One base SOI ID? Humm Importance: High Barbara just said that if more of this community were physically here at 54 in Yokohama, she would take a humm poll about whether to move forward with one SOI ID, one bail of hay. Here we go... "hum via email if you agree with the two ID authors coming back to the list with one ID for us to move forward discussing." Here's mine: HMMMMM!!! From owner-ipsec@lists.tislabs.com Wed Jul 17 17:11:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I0BZw05663; Wed, 17 Jul 2002 17:11:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA23244 Wed, 17 Jul 2002 19:25:47 -0400 (EDT) Message-Id: <200207172337.g6HNbVtx019857@marajade.sandelman.ottawa.on.ca> To: Francis Dupont cc: ipsec@lists.tislabs.com Subject: Re: IPsec and Mobile IPv6 In-reply-to: Your message of "Wed, 17 Jul 2002 09:34:34 +0200." <200207170734.g6H7YYGF068039@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 17 Jul 2002 19:37:30 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Francis, your draft is very short. My three sentence summary is: 1. NATs are devices in the path. 2. Any device in the path can perform a DoS attack or change IP addresses. 3. A number of protocols have been made NAT-friendly by removing the IP source address (and/or port) from within the protection, leaving those protocols open to "pseudo-NATs". As much as I dislike NAT .... I guess I'm just not very convinced this is a serious issue. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPTX/tYqHRg3pndX9AQGNdgQAkpJv5dPUnBjJcEqpIT0kwVyA0V9Z+n/Y XdWmnmqLlq4vVvuVsWIIPZtrZzRduavTkEW4j6cqhgu9OVuHh1c7B7GQR4rJJWeQ KzBvVXaFrm3qkW8gxBqaJBPVcCOel86ckHPxzZHNIr0E5y1gOWJD/AT0I92AlkKo sd3s7PgKMCs= =qhAu -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Jul 17 17:32:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I0WZw06026; Wed, 17 Jul 2002 17:32:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA23264 Wed, 17 Jul 2002 19:49:46 -0400 (EDT) Message-ID: From: Russell Dietz To: "'ipsec@lists.tislabs.com'" Subject: RE: One base SOI ID? Humm Date: Wed, 17 Jul 2002 17:07:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eh.. sorry... too early... please insert 'add' for 'and' Russ -----Original Message----- From: Russell Dietz Sent: Wednesday, July 17, 2002 3:46 PM To: 'ipsec@lists.tislabs.com' Subject: RE: One base SOI ID? Humm I'll and mine! HMMM! Russ -----Original Message----- From: Gregory Lebovitz [mailto:Gregory@netscreen.com] Sent: Wednesday, July 17, 2002 12:59 AM To: 'ipsec@lists.tislabs.com' Subject: One base SOI ID? Humm Importance: High Barbara just said that if more of this community were physically here at 54 in Yokohama, she would take a humm poll about whether to move forward with one SOI ID, one bail of hay. Here we go... "hum via email if you agree with the two ID authors coming back to the list with one ID for us to move forward discussing." Here's mine: HMMMMM!!! From owner-ipsec@lists.tislabs.com Wed Jul 17 17:58:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I0w1w06581; Wed, 17 Jul 2002 17:58:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA23390 Wed, 17 Jul 2002 20:18:55 -0400 (EDT) Message-ID: From: Russell Dietz To: IPSec Working Group , SAAG Subject: No need for SHA-2 Packet Authentication - Open Letter to the WG a nd Area Directors Date: Wed, 17 Jul 2002 17:35:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To the IPSec Working Group and Security Area Directors: The purpose of this letter is to comment on an existing Internet Draft, draft-ietf-ipsec-ciph-sha-256-00.txt, dated Nov 2001, co-authored by S. Frankel and S. Kelley. This draft, hereafter referred to as DRAFT-SHA-256 for brevity, defines how to use the new SHA-256 algorithm from NIST (FIPS 180-2) for packet authentication within the ESP and AH mechanisms of IPSec. Our basic argument here is that, while the new SHA-256 algorithm is definitely useful in other contexts, in fact there is no evidence that DRAFT-SHA-256 provides any meaningful additional cryptographic security over the HMAC-SHA-1-96 algorithm defined in RFC2406 and already in widespread use for packet authentication in IPSec. For all we know, quite the contrary may be true, as SHA-256 is a new transform and thus has seen considerably less public review so far than SHA1 has already received. In any case, it is extremely unlikely that HMAC-SHA1 will be the weak point in any system using IPSec. Hence, it is not clear that trying to improve its security makes any sense, given the costs and instability associated with such a change. Unfortunately, the current draft is misleading in this regard: "Using the SHA-256 block cipher, with its increased block size (512 bits) and increased hash length (256 bits), provides the new algorithm with the ability to withstand continuing advances in crypto-analytic techniques and computational capability. It also allows less frequent re-keying, which is useful for high-speed networks and high-volume applications." It is our belief that, as currently defined in DRAFT-SHA-256, the use of SHA-256 does not achieve any of these stated goals. First of all, the block size of SHA-256 (512 bits) is identical to that of SHA-1, so the first assertion in the quote above is simply false, although frankly it would have no relevance if true. Second, there is no known reason why DRAFT-SHA-256 would in fact allow less frequent rekeying, using either 32-bit or 64-bit sequence numbers. Finally, and most importantly, while it is true that SHA-256 can output 256 bits, in the current draft the HMAC-SHA-256 output is in fact truncated to 96 bits, as is HMAC-SHA-1 in RFC2406. For the HMAC-SHA-1-96 and DRAFT-SHA-256 algorithms, there is every reason to believe that the limiting factor in security is the number of bits of hash included in the packet, not the length before truncation. The best attacks known on HMAC-SHA-1-96 and DRAFT-SHA-256 depend only on the length after truncation, not the length before truncation. Hence, the HMAC-SHA-1-96 and DRAFT-SHA-256 have equivalent security against known attacks, and there seems to be little reason to prefer either one over the other, from a cryptographic perspective. For any given number of output bits, up to the SHA-1 limit of 160 bits, this would continue to be the case. If it was desired to have a MAC value longer than 160 bits, then the use of SHA-256 would likely be appropriate, but there is no apparent need for such a MAC tag length, according to current knowledge. It is possible that the draft was initiated from a fundamental misunderstanding of Figure 1 (page 3) of the NIST draft FIPS 180-2. This figure states that the "security" of SHA-1 is 80 bits, while the "security" of SHA-256 is 128 bits. A naive reading of this figure would thus lead one to conclude that only SHA-256 is appropriate for use with AES-128. However, the figure in question deals with the strength of the hash functions against collisions as part of a digital signature scheme. It is likely that the use of SHA-256 is very appropriate for the digital signatures used in the certificates of the IKE exchange used to generate AES-128 and HMAC-SHA-1-96 keys for ESP and AH. This is in fact the application for which SHA-256 was designed. However, while Figure 1 in FIPS 180-2 is correct for digital signatures, it has no direct relevance to the issue of packet authentication in ESP and AH as addressed in DRAFT-SHA-256. Packet authentication has a completely different attack model. In particular, there is no known feasible "birthday attack" problem in the packet authentication context, as has been shown by Krawczyk and others (e.g., "Keying Hash Functions for Message Authentication" by Bellare, Canetti, and Krawczyk, Crypto '96). Since HMAC-SHA1-96 (RFC2406) is already a "MUST" for IPSec compliance, all IPSec implementations, hardware or software, already have it and must continue to support it for many years to come. Any possible argument that somehow SHA-256 can replace SHA-1 to save hardware cost is thus extremely ill-founded. In fact, quite the opposite is true: adding DRAFT-SHA-256 as an IPSec option will only increase hardware cost, with no accompanying security benefit. We expect that if the WG approved DRAFT-SHA-256, it would be optional rather than mandatory. However, there would be a strong risk that vendors and their customers might feel compelled to use it out of a misunderstanding of the cryptographic issues. Already we have heard potential customers asking for support for DRAFT-SHA-256, with the rationale being, "if IETF approves it, it must be good". Our purpose in submitting this letter is to make sure that the IPSec working group has a reasonable understanding of the issues involved in DRAFT-SHA-256. If the WG decides to approve the draft, we strongly suggest that, at a bare minimum, a) the inaccurate claims discussed above should be corrected or removed, b) the document should be re-worked to clarify the fact that SHA1 is perfectly adequate, according to current knowledge, c) the resulting transform should be qualified as optional-to-implement, not mandatory, and d) the draft should make clear under what circumstances the transform is an option worth pursuing (e.g. if SHA-1 is broken by advances in cryptanalysis, but SHA-256 is not) However, given that there is no known cryptographic benefit to implementing this proposed standard, we respectfully submit that the IPSec WG should not approve this draft. Doug Whiting, dwhiting@hifn.com, Hifn David McGrew, mcgrew@cisco.com, Cisco Dave Wagner, daw@cs.berkeley.edu, UC Berkeley Russ Housely, rhousley@rsdsecurity.com, RSA Labs Niels Ferguson, niels@ferguson.net, MacFergus BV Thomas Hardjono, thomas.hardjono@verisign.com, Verisign Scott Fluhrer, fluhrer@cisco.com, Cisco Jesse Walker, jesse.walker@intel.com, Intel Mike Sabin, mike.sadin@worldnet.att.net, Independent Consultant John Kelsey, kelsey.j@ix.netcom.com, Certicom Russell Dietz, rdietz@hifn.com, Hifn Russell Dietz Hifn, Inc. pgp-fingerprint: CEE3 58B0 DD09 4EA5 7266 BF1E B5F6 4D1A 4AD1 65B4 From owner-ipsec@lists.tislabs.com Wed Jul 17 18:36:17 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I1aGw07540; Wed, 17 Jul 2002 18:36:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA23497 Wed, 17 Jul 2002 20:53:04 -0400 (EDT) From: "Don Wilder" To: "Gregory Lebovitz" , Subject: RE: One base SOI ID? Humm Date: Thu, 18 Jul 2002 10:06:14 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87060C06@SARATOGA> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ok... here's mine... HMMMMMM > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Gregory Lebovitz > Sent: Wednesday, July 17, 2002 4:59 PM > To: 'ipsec@lists.tislabs.com' > Subject: One base SOI ID? Humm > Importance: High > > > Barbara just said that if more of this community were physically > here at 54 > in Yokohama, she would take a humm poll about whether to move forward with > one SOI ID, one bail of hay. > > Here we go... > > "hum via email if you agree with the two ID authors coming back > to the list > with one ID for us to move forward discussing." > > Here's mine: HMMMMM!!! From owner-ipsec@lists.tislabs.com Wed Jul 17 19:10:14 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I2ADw08221; Wed, 17 Jul 2002 19:10:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA23552 Wed, 17 Jul 2002 21:31:11 -0400 (EDT) Message-ID: <3D361D54.3FC40941@lucent.com> Date: Wed, 17 Jul 2002 21:43:48 -0400 From: Uri Blumenthal Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: One base SOI ID? Humm References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russell Dietz wrote: > > I'll and mine! > > HMMM! I hummed there, and I'm humming here! HMMMMMMMMMMMM! -- Regards, Uri -=-=-=<>=-=- From owner-ipsec@lists.tislabs.com Wed Jul 17 19:22:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I2MBw08462; Wed, 17 Jul 2002 19:22:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA23600 Wed, 17 Jul 2002 21:42:17 -0400 (EDT) Message-Id: <200207180155.g6I1tdGF071018@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: IPsec and Mobile IPv6 In-reply-to: Your message of Wed, 17 Jul 2002 19:37:30 EDT. <200207172337.g6HNbVtx019857@marajade.sandelman.ottawa.on.ca> Date: Thu, 18 Jul 2002 03:55:39 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: My three sentence summary is: 1. NATs are devices in the path. 2. Any device in the path can perform a DoS attack or change IP addresses. 3. A number of protocols have been made NAT-friendly by removing the IP source address (and/or port) from within the protection, leaving those protocols open to "pseudo-NATs". => yes, the attack is the price to pay for the basic "NAT-traversal" feature. As much as I dislike NAT .... => I not only dislike them but I work in an environment without NATs 95% of the time. I guess I'm just not very convinced this is a serious issue. => I found this issue during a presentation of the NAT-traversal feature of Mobile IP(v4). I jumped on my laptop to signal it to the draft authors and they agree this is a serious issue so they updated their draft with a far larger "security consideration" section. The fact the same issue stands for IKE which is a security protocol IMHO is even more serious: I can't see why I have to pay such a price for a feature I don't use. Another argument: the address agility section is too vague about the properties of the addresses IKEv2 runs over. This must be cleanup and there is an opportunity to make it better: fulfill NAT-traversal, mobility and multi-homing requirements in the most secure ways for each. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Jul 17 19:28:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I2Sew08596; Wed, 17 Jul 2002 19:28:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA23629 Wed, 17 Jul 2002 21:49:20 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Re: One base SOI ID? Humm X-Mailer: Cue version 0.6 (020620-1817/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20020718110248R.sakane@kame.net> Date: Thu, 18 Jul 2002 11:02:48 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 50 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk before starting a poll to make one SOI or not. could we make the goal or the purpose of SOI as the IPsec WG ? the purpose of SOI, of course, is to establish SA. i mean, for examle, nowaday, there are several KMPs. they states own goals. KINK is designed to establish SA with low computational cost within a centrally managed environment. KINK darft draft-ietf-kink-kink-02.txt states: The performance goals of the protocol are to incur a low computational cost, to have low latency, to have a small footprint, and to avoid or minimize the use of public key operations. MIKEY is designed to establish SA between real-time multimedia applications. MIKEY draft draft-ietf-msec-mikey-03.txt states: The focus is on how to set up key management for secure multimedia sessions such that requirements in a heterogeneous environment are fulfilled. JFK also states the design goals in its drafts. i believe one important thing is "simplicity". only IKEv2 seems not to state its goals. in fact, IKEv2 drafts has the section of describing the goal in draft-ietf-ipsec-ikev2-02.txt. but it is different point from the goals stated by avobe three KMPs. my impression is that those who have each own scenario have required several proposal to SOI. it will cause SOI making fatty. to make the goal of SOI as the IPsec WG, we already have a hint in the section 9 of draft-ietf-ipsec-soi-features-01.txt. it categorizes features in the IKE requirements. 1 Virtual Private Network Site-to-Site Tunnels 2 Secure Remote Access 3 End-to-End Security 4 IP Storage 5 PPVPN/MPLS a fatty SOI could deal with all of them. but such SOI would have some issue after fall. i personally think that some key exchange protocols can be allowed to exist in the internet. if we would have some KMPs, then SOIs would be probably simple and publish to the internet quickly. OR if the goal of SOI in the IPsec WG would be more secure, more robust and all-in-one protocol, then we could have simpler KMP like JFK until new SOI would be published. //shoichi sakane From owner-ipsec@lists.tislabs.com Wed Jul 17 19:39:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I2ddw08883; Wed, 17 Jul 2002 19:39:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA23659 Wed, 17 Jul 2002 21:56:23 -0400 (EDT) Cc: IPSec Working Group , SAAG Message-ID: <3D36232E.93F7FB5F@lucent.com> Date: Wed, 17 Jul 2002 22:08:46 -0400 From: Uri Blumenthal Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Russell Dietz Original-CC: IPSec Working Group , SAAG Subject: Re: [saag] No need for SHA-2 Packet Authentication - Open Letter to the WG and Area Directors References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russell Dietz wrote: > Unfortunately, the current draft is misleading in this regard: > "Using the SHA-256 block cipher, with its increased block size (512 bits) > and increased hash length (256 bits), provides the new algorithm with the > ability to withstand continuing advances in crypto-analytic techniques and > computational capability............." > It is our belief that, as currently defined in DRAFT-SHA-256, the use of > SHA-256 does not achieve any of these stated goals. > > First of all, the block size of SHA-256 (512 bits) is identical to that of > SHA-1, so the first assertion in the quote above is simply false, although > frankly it would have no relevance if true. Second, there is no known > reason why DRAFT-SHA-256 would in fact allow less frequent rekeying, using > either 32-bit or 64-bit sequence numbers. Actually it's even worse than that. Yes, SHA-256 outputs twice as many bits as SHA-1. Sure, but who says those bits are RANDOM? Uncorrelated? The SHA family of functions is a Hash family, not PRF. Thus, longer output for re-keying purposes means exactly nothing. [It does make a difference for hash/MAC of course, but not rekeying.] [If I may toot my own horn here - please look at the PRF-from-MAC construct, that comes with formal security proofs, submitted by yours truly :-). It talks about hard random bits suitable for keying material.] Thanks! -- Regards, Uri -=-=-=<>=-=- From owner-ipsec@lists.tislabs.com Wed Jul 17 23:01:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I61xw13673; Wed, 17 Jul 2002 23:01:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA24019 Thu, 18 Jul 2002 01:18:49 -0400 (EDT) Date: 18 Jul 2002 01:18:27 -0400 Message-ID: <001e01c22e1a$8d01ad80$3568e640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Gregory Lebovitz'" , " 'list'" Subject: RE: One base SOI ID? Humm MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <541402FFDC56DA499E7E13329ABFEA87060C06@SARATOGA> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It seems that lots of people are already willing to add their support for this, but I don't really understand the question. Maybe some clarification of the poll is in order. What are we voting on exactly? 1. A single SOI protocol vs. 2 protocols? 2. A merged SOI base vs. using IKEv2 as the base? 3. A single SOI protocol vs. continued uncertainty? Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Gregory Lebovitz > Sent: Wednesday, July 17, 2002 3:59 AM > To: 'ipsec@lists.tislabs.com' > Subject: One base SOI ID? Humm > Importance: High > > > Barbara just said that if more of this community were > physically here at 54 > in Yokohama, she would take a humm poll about whether to move > forward with > one SOI ID, one bail of hay. > > Here we go... > > "hum via email if you agree with the two ID authors coming > back to the list > with one ID for us to move forward discussing." > > Here's mine: HMMMMM!!! > From owner-ipsec@lists.tislabs.com Wed Jul 17 23:01:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I61xw13672; Wed, 17 Jul 2002 23:01:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA24033 Thu, 18 Jul 2002 01:22:51 -0400 (EDT) Message-ID: From: Russell Dietz To: RJ Atkinson Cc: IPSec Working Group , SAAG Subject: RE: [saag] No need for SHA-2 Packet Authentication - Open Letter to the WG and Area Directors Date: Wed, 17 Jul 2002 22:39:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wednesday, July 17, 2002, at 09:42 PM, RJ Atkinson wrote: > Russell, > > I'm pretty indifferent to the topic of what ought or ought not be > mandatory-to-implement or maybe even standards-track RFC versus > informational RFC. I am remarkably indifferent to any of the > mathematical parts of your note or Uri's followup. > > I do feel pretty strongly that the above referenced draft ought to be > permitted to be published, at least as an Informational RFC, so that > those folks who choose to implement/deploy it can do so in an > interoperable manner. > > Trying to prevent people from publishing open specifications for > entirely optional-to-implement technology is NOT consistent with > the Internet tradition. I would hope that the RFC Editor would > apply their own good judgement to an individual request to publish > such a document as an Informational RFC if the situation should arise. > > Yours, > > Ran > rja@extremenetworks.com Hello Ran, I totally agree that the Internet tradition of allowing individuals to publish work should continue unchanged. I apologize if I gave off that impression in our note. That was not the intent. We need 'optional' features to be made available to the Internet community in order to allow for potential coordinated field 'trials' and interoperability. The facts around this draft are that it was added to the charter of the IPSec WG as part of the AES cipher support effort. (It is a WG draft!) That linkage has caused misinformation in the original draft to become perceived as pseudo-requirements. The general issue of WG drafts and the connection between this draft and the AES/FIPS 180-2 effort have created a great deal of confusion at some of the implementers. So... the concern is the linkage and the request by the user community for implementation as it is 'going to be a standard soon...' Hope this helps clarify things! Regards, Russ From owner-ipsec@lists.tislabs.com Wed Jul 17 23:06:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I66Pw14907; Wed, 17 Jul 2002 23:06:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA24046 Thu, 18 Jul 2002 01:27:52 -0400 (EDT) Date: 18 Jul 2002 01:27:29 -0400 Message-ID: <002001c22e1b$d0877c50$3568e640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Russell Dietz'" , " 'list'" Subject: RE: SHA-256-128 Draft: Is this really required? Contradiction... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I was originally opposed to SHA-2, but I got them impression from previous discussions at IETF meetings and on this list that SHA-2 was going to be faster than SHA-1. If that is not the case then I agree that there is no need for SHA-2. (Unless it is to match the security strength of large DH groups in key derivation, which, as we've discussed on this list before, is more a limitation of the key derivation algorithm than of the hash). Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Russell Dietz > Sent: Wednesday, July 17, 2002 3:15 AM > To: ipsec@lists.tislabs.com > Subject: SHA-256-128 Draft: Is this really required? Contradiction... > > > Hello Folks, > > In reviewing the latest SHA-256 draft, "The HMAC-SHA-256-128 > Algorithm and > Its Use With IPsec", , > June 2002, I > notice a contradiction and a point which I (and others) > believe, eliminates > the need for the document to progress, even as an experimental. > > In the draft, the authors state that... > > "HMAC-SHA-1-96 [HMAC-SHA] (Madson, C. and R. Glenn, "The Use of > HMAC-SHA-1-96 within ESP and AH," RFC2404, November 1998.) provides > sufficient security at a lower computational cost [then this > SHA-2 draft]". > > ...the draft then states... > > "The goal of HMAC-SHA-256-128 is to ensure that the packet is > authentic and > cannot be modified in transit." > > ...this is the 'goal' of HMAC-SHA-1-96 as it stands today. > > In addition, while the new SHA-256 algorithm is definitely > useful in other > contexts, in fact there is no evidence that DRAFT-SHA-256 provides any > meaningful additional cryptographic security over the HMAC-SHA-1-96 > algorithm defined in RFC2404 and already in widespread use for packet > authentication in IPSec. For all we know, quite the contrary > may be true, > as SHA-256 is a new transform and thus has seen considerably > less public > review so far than SHA1 has already received. In any case, > it is extremely > unlikely that HMAC-SHA1 will be the weak point in any system > using IPSec. > Hence, it is not clear that trying to improve its security > makes any sense, > given the costs and instability associated with such a change. > > Given this and the fact that SHA-256 is has no known > cryptographic benefit > to implementing this proposed standard, there is no reason, even on an > experimental basis, for the IPSec WG to progress this document. > > Regards, > > Russell Dietz > Hifn, Inc. > 750 University Ave > Los Gatos, CA, USA 95032-7695 > Tel: +1 408 399-3623 > pgp-fingerprint: CEE3 58B0 DD09 4EA5 7266 BF1E B5F6 4D1A 4AD1 65B4 > From owner-ipsec@lists.tislabs.com Wed Jul 17 23:17:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I6Hdw17994; Wed, 17 Jul 2002 23:17:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA24077 Thu, 18 Jul 2002 01:37:53 -0400 (EDT) Date: 18 Jul 2002 01:36:56 -0400 Message-ID: <002101c22e1d$22b016d0$3568e640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Theodore Ts'o'" , " 'list'" Subject: SOI QUESTION: 5.3-6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 5.3 SPD entries > > 5.3.A) Is it important in SOI to allow the the responder to > accept a subset > of the proposed SA, or should it be an all or nothing acceptance? That's a tough question. I'm tempted to say no instinctively because IKE should be doing policy agreement and not policy discovery. I think we have to look at the scenarios for this one. Why would you want to restrict an SA to a subset of the offered selectors? Is it because the initiator doesn't know the identity-IP binding? Or to enforce firewall rules? Or to set up QoS-specific SAs? Any one of these is a questionable motivation. I don't understand the rationale behind SINGLE-PAIR-REQUIRED from the IKEv2 draft. What's the point of this? (And why is it SINGLE-[IP-]PAIR-REQUIRED and not SINGLE-PORT-PAIR-REQUIRED?) When we discussed this basic issue on the list in August '01 the general consensus was that it is better to send all traffic on one SA in order to thwart traffic analysis. The only advantage to having separate SAs is to thwart attacks such as the one discovered by Scott Fluhrer. Now that we've discovered such an attack (and learned how to prevent it), is there any further use for this? > 5.3.B) Should the SOI offer multiple selectors with specific ports and > addresses, or a single selector with a range of ports and range of > addresses? (complicated boolean complexity!) I think we need to support lists of ranges of IPs, perhaps with the provision that they must be ordered sequentially. Lists of ranges is the most compact and unambiguous selector type. When we add the ports (a list of ranges of ports, I guess), I assume that the ports will apply to every IP in the list. I can't really think of any situations in which I would want to use port selectors with IP ranges, but apparently this is a requirement for IP storage (although I am fuzzy on the rationale for this). > 6.1 Message encoding > > 6.1.A) Should SOI worry about aligning parts of messages on 2 and 4 > byte boundaries? I guess that would be okay. We have seen some issues with this, although it's nothing that can't be avoided by careful programming. I think it would eat up a lot of extra space on the wire, though. > 6.1.B) Should SOI tag its protocol with version numbers? Yes. How can this not be obvious? > 6.1.C) Should SOI format be roughly the same as IKEv1? (See > discussion in section 6.4, re: code preserving) It would be nice. I see no real advantage to one encoding scheme over another, so why change? > 6.2 Port number > > 6.2.A) Should SOI use the same port as IKEv1? (See discussion in > soi-features-01 the tradeoffs in this question). I have no strong opinion on this. We're already going to be supporting multiple ports for NAT traversal anyway. > 6.3 Future versions of the protocols > > 6.3.A) Should SOI have a mechanism for demanding/requesting that a > peer use a particular version of IKE/SOI to allow upgrading to new > versions? Yes. > 6.4 Code-preservingness > > 6.4.A) Is it important that SOI allow some amounts of an IKEv1 > implementation be reusable when creating an SOI implementation? It has already become obvious to me that SOI is going to require quite a bit of rewriting, however when I have analyzed the changes I see that a lot of code is still going to be reusable. So yes. The more different the protocol is, the more changes will be required. > 6.5 Extensibility of the protocols > > 6.5.A) Should SOI have mechanisms for allowing extensions to the SOI > protocol? Unquestionably yes. This is an issue that I'm completely adamant about. Aside from just allowing experimental/proprietary features, the vendor id gives a smooth upgrade mechanism. Early on in the deployment of IKEv1, we had an issue where the spec changed, leaving us with deployed boxes that were incompatible with the new draft. This was before the invention of the vendor id and we needed a transition mechansim, so we were forced to come up with a fairly kludgy solution. A vendor id would have allowed us to detect incompatible versions in the field and adjust our behaviour accordingly. > 6.5.B) Should SOI need a way to mark new extensions as critical? > (i.e. If you don't understand a critical extension you must fail the > entire negotiation) Might as well. The argument that vendors will purposely set the critical bit in order to hinder interoperability is just silly. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. From owner-ipsec@lists.tislabs.com Wed Jul 17 23:25:21 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I6PLw19333; Wed, 17 Jul 2002 23:25:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA24108 Thu, 18 Jul 2002 01:46:52 -0400 (EDT) Message-ID: <9D048F4A422CD411A56500B0D0209C5B0458FA27@NS-CA> From: Michael Choung Shieh To: "'Shoichi Sakane '" , "'ipsec@lists.tislabs.com '" Subject: RE: One base SOI ID? Humm Date: Wed, 17 Jul 2002 22:57:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I too HUMMM..... I agree SOI may not replace all KMP. However, many agree there are not that many differences between JFK and IKEv2. The least thing I want is an intermitted KMP cause it costs too much effort for all devices to support 3 KMP (IKEv1, JFK, and SOI). Michael Shieh -----Original Message----- From: Shoichi Sakane To: ipsec@lists.tislabs.com Sent: 7/17/02 7:02 PM Subject: Re: One base SOI ID? Humm before starting a poll to make one SOI or not. could we make the goal or the purpose of SOI as the IPsec WG ? the purpose of SOI, of course, is to establish SA. i mean, for examle, nowaday, there are several KMPs. they states own goals. KINK is designed to establish SA with low computational cost within a centrally managed environment. KINK darft draft-ietf-kink-kink-02.txt states: The performance goals of the protocol are to incur a low computational cost, to have low latency, to have a small footprint, and to avoid or minimize the use of public key operations. MIKEY is designed to establish SA between real-time multimedia applications. MIKEY draft draft-ietf-msec-mikey-03.txt states: The focus is on how to set up key management for secure multimedia sessions such that requirements in a heterogeneous environment are fulfilled. JFK also states the design goals in its drafts. i believe one important thing is "simplicity". only IKEv2 seems not to state its goals. in fact, IKEv2 drafts has the section of describing the goal in draft-ietf-ipsec-ikev2-02.txt. but it is different point from the goals stated by avobe three KMPs. my impression is that those who have each own scenario have required several proposal to SOI. it will cause SOI making fatty. to make the goal of SOI as the IPsec WG, we already have a hint in the section 9 of draft-ietf-ipsec-soi-features-01.txt. it categorizes features in the IKE requirements. 1 Virtual Private Network Site-to-Site Tunnels 2 Secure Remote Access 3 End-to-End Security 4 IP Storage 5 PPVPN/MPLS a fatty SOI could deal with all of them. but such SOI would have some issue after fall. i personally think that some key exchange protocols can be allowed to exist in the internet. if we would have some KMPs, then SOIs would be probably simple and publish to the internet quickly. OR if the goal of SOI in the IPsec WG would be more secure, more robust and all-in-one protocol, then we could have simpler KMP like JFK until new SOI would be published. //shoichi sakane From owner-ipsec@lists.tislabs.com Thu Jul 18 01:03:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I83pw05213; Thu, 18 Jul 2002 01:03:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA24383 Thu, 18 Jul 2002 03:16:18 -0400 (EDT) Message-ID: <3D366E44.D25B5BF2@bstormnetworks.com> Date: Thu, 18 Jul 2002 00:29:08 -0700 From: "Scott G. Kelly" Organization: Black Storm Networks X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: andrew.krywaniuk@alcatel.com CC: "'Gregory Lebovitz'" , "'list'" Subject: SOI ID? Humm References: <001e01c22e1a$8d01ad80$3568e640@ca.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a good point. The question being asked here isn't the question I remember Barb being unwilling to call yesterday (due to lack of adequate representation here in Yokohama), though I could have missed something. Maybe we should let Barb and Ted frame the question for us when they are ready... Scott Andrew Krywaniuk wrote: > > It seems that lots of people are already willing to add their support for > this, but I don't really understand the question. > > Maybe some clarification of the poll is in order. What are we voting on > exactly? > > 1. A single SOI protocol vs. 2 protocols? > > 2. A merged SOI base vs. using IKEv2 as the base? > > 3. A single SOI protocol vs. continued uncertainty? > > Andrew > ------------------------------------------- > There are no rules, only regulations. Luckily, > history has shown that with time, hard work, > and lots of love, anyone can be a technocrat. > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Gregory Lebovitz > > Sent: Wednesday, July 17, 2002 3:59 AM > > To: 'ipsec@lists.tislabs.com' > > Subject: One base SOI ID? Humm > > Importance: High > > > > > > Barbara just said that if more of this community were > > physically here at 54 > > in Yokohama, she would take a humm poll about whether to move > > forward with > > one SOI ID, one bail of hay. > > > > Here we go... > > > > "hum via email if you agree with the two ID authors coming > > back to the list > > with one ID for us to move forward discussing." > > > > Here's mine: HMMMMM!!! > > From owner-ipsec@lists.tislabs.com Thu Jul 18 01:04:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6I84cw05512; Thu, 18 Jul 2002 01:04:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA24397 Thu, 18 Jul 2002 03:24:17 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87060C1F@SARATOGA> From: Gregory Lebovitz To: "'andrew.krywaniuk@alcatel.com'" , ipsec@lists.tislabs.com Subject: RE: One base SOI ID? Humm Date: Thu, 18 Jul 2002 00:31:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Number 3 - a single SOI protocol for wg to work on versus continuing with two bails of hay. -----Original Message----- From: Andrew Krywaniuk [mailto:andrew.krywaniuk@alcatel.com] Sent: Wednesday, July 17, 2002 10:18 PM To: 'Gregory Lebovitz'; 'list' Subject: RE: One base SOI ID? Humm It seems that lots of people are already willing to add their support for this, but I don't really understand the question. Maybe some clarification of the poll is in order. What are we voting on exactly? 1. A single SOI protocol vs. 2 protocols? 2. A merged SOI base vs. using IKEv2 as the base? 3. A single SOI protocol vs. continued uncertainty? Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Gregory Lebovitz > Sent: Wednesday, July 17, 2002 3:59 AM > To: 'ipsec@lists.tislabs.com' > Subject: One base SOI ID? Humm > Importance: High > > > Barbara just said that if more of this community were > physically here at 54 > in Yokohama, she would take a humm poll about whether to move > forward with > one SOI ID, one bail of hay. > > Here we go... > > "hum via email if you agree with the two ID authors coming > back to the list > with one ID for us to move forward discussing." > > Here's mine: HMMMMM!!! > From owner-ipsec@lists.tislabs.com Thu Jul 18 07:16:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6IEGuw05459; Thu, 18 Jul 2002 07:16:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25011 Thu, 18 Jul 2002 09:27:12 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15670.50517.128708.894181@pkoning.dev.equallogic.com> Date: Thu, 18 Jul 2002 09:40:37 -0400 From: Paul Koning To: andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com Subject: RE: One base SOI ID? Humm References: <541402FFDC56DA499E7E13329ABFEA87060C06@SARATOGA> <001e01c22e1a$8d01ad80$3568e640@ca.alcatel.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Andrew" == Andrew Krywaniuk writes: Andrew> Maybe some clarification of the poll is in order. What are we Andrew> voting on exactly? I'm not sure what the original question intended to ask, but here's my take on your variants: Andrew> 1. A single SOI protocol vs. 2 protocols? Single protocol. Having two protocols would be a major mistake. Andrew> 2. A merged SOI base vs. using IKEv2 as the base? You mean "merged" as in "JFK and IKEv2 blended together"? If so, then I'd say that doesn't sound like a recipe for rapid forward progress, unless I missed something. Andrew> 3. A single SOI protocol vs. continued uncertainty? The former, emphatically. This process has already taken an amazingly large amount of time. paul From owner-ipsec@lists.tislabs.com Thu Jul 18 09:52:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6IGq4w14876; Thu, 18 Jul 2002 09:52:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA25231 Thu, 18 Jul 2002 11:59:19 -0400 (EDT) Message-ID: <6F0AA176DA68704884B7507AE6907E180818D7@snake012.odetics.com> From: Christina Helbig To: "'Russell Dietz'" , IPSec Working Group , SAAG Subject: RE: No need for SHA-2 Packet Authentication - Open Letter to the WG a nd Area Directors Date: Thu, 18 Jul 2002 09:12:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Russell, I have looked to the available I-Ds and found only . In this draft a lot of your points is covered, e.g. the claim about re-keying is not more part of this draft, truncation is to 128 bit, comparison to SHA-1 is only about speed... Greetings Christina > -----Original Message----- > From: Russell Dietz [mailto:rdietz@hifn.com] > Sent: Wednesday, July 17, 2002 5:36 PM > To: IPSec Working Group; SAAG > Subject: No need for SHA-2 Packet Authentication - Open > Letter to the WG > a nd Area Directors > > > To the IPSec Working Group and Security Area Directors: > > The purpose of this letter is to comment on an existing > Internet Draft, > draft-ietf-ipsec-ciph-sha-256-00.txt, dated Nov 2001, > co-authored by S. > Frankel and S. Kelley. This draft, hereafter referred to as > DRAFT-SHA-256 > for brevity, defines how to use the new SHA-256 algorithm > from NIST (FIPS > 180-2) for packet authentication within the ESP and AH > mechanisms of IPSec. > > Our basic argument here is that, while the new SHA-256 algorithm is > definitely useful in other contexts, in fact there is no evidence that > DRAFT-SHA-256 provides any meaningful additional > cryptographic security over > the HMAC-SHA-1-96 algorithm defined in RFC2406 and already in > widespread use > for packet authentication in IPSec. For all we know, quite > the contrary may > be true, as SHA-256 is a new transform and thus has seen > considerably less > public review so far than SHA1 has already received. In any > case, it is > extremely unlikely that HMAC-SHA1 will be the weak point in > any system using > IPSec. Hence, it is not clear that trying to improve its > security makes any > sense, given the costs and instability associated with such a change. > > Unfortunately, the current draft is misleading in this regard: > "Using the SHA-256 block cipher, with its increased block > size (512 bits) > and increased hash length (256 bits), provides the new > algorithm with the > ability to withstand continuing advances in crypto-analytic > techniques and > computational capability. It also allows less frequent > re-keying, which is > useful for high-speed networks and high-volume applications." > It is our belief that, as currently defined in DRAFT-SHA-256, > the use of > SHA-256 does not achieve any of these stated goals. > > First of all, the block size of SHA-256 (512 bits) is > identical to that of > SHA-1, so the first assertion in the quote above is simply > false, although > frankly it would have no relevance if true. Second, there is no known > reason why DRAFT-SHA-256 would in fact allow less frequent > rekeying, using > either 32-bit or 64-bit sequence numbers. Finally, and most > importantly, > while it is true that SHA-256 can output 256 bits, in the > current draft the > HMAC-SHA-256 output is in fact truncated to 96 bits, as is > HMAC-SHA-1 in > RFC2406. For the HMAC-SHA-1-96 and DRAFT-SHA-256 algorithms, > there is every > reason to believe that the limiting factor in security is the > number of bits > of hash included in the packet, not the length before > truncation. The best > attacks known on HMAC-SHA-1-96 and DRAFT-SHA-256 depend only > on the length > after truncation, not the length before truncation. Hence, > the HMAC-SHA-1-96 > and DRAFT-SHA-256 have equivalent security against known > attacks, and there > seems to be little reason to prefer either one over the other, from a > cryptographic perspective. For any given number of output > bits, up to the > SHA-1 limit of 160 bits, this would continue to be the case. If it was > desired to have a MAC value longer than 160 bits, then the > use of SHA-256 > would likely be appropriate, but there is no apparent need > for such a MAC > tag length, according to current knowledge. > > It is possible that the draft was initiated from a fundamental > misunderstanding of Figure 1 (page 3) of the NIST draft FIPS > 180-2. This > figure states that the "security" of SHA-1 is 80 bits, while > the "security" > of SHA-256 is 128 bits. A naive reading of this figure would > thus lead one > to conclude that only SHA-256 is appropriate for use with > AES-128. However, > the figure in question deals with the strength of the hash > functions against > collisions as part of a digital signature scheme. It is > likely that the use > of SHA-256 is very appropriate for the digital signatures used in the > certificates of the IKE exchange used to generate AES-128 and > HMAC-SHA-1-96 > keys for ESP and AH. This is in fact the application for > which SHA-256 was > designed. > > However, while Figure 1 in FIPS 180-2 is correct for digital > signatures, it > has no direct relevance to the issue of packet authentication > in ESP and AH > as addressed in DRAFT-SHA-256. Packet authentication has a completely > different attack model. In particular, there is no known > feasible "birthday > attack" problem in the packet authentication context, as has > been shown by > Krawczyk and others (e.g., "Keying Hash Functions for Message > Authentication" by Bellare, Canetti, and Krawczyk, Crypto '96). > > Since HMAC-SHA1-96 (RFC2406) is already a "MUST" for IPSec > compliance, all > IPSec implementations, hardware or software, already have it and must > continue to support it for many years to come. Any possible > argument that > somehow SHA-256 can replace SHA-1 to save hardware cost is > thus extremely > ill-founded. In fact, quite the opposite is true: adding > DRAFT-SHA-256 as an > IPSec option will only increase hardware cost, with no > accompanying security > benefit. > > We expect that if the WG approved DRAFT-SHA-256, it would be > optional rather > than mandatory. However, there would be a strong risk that > vendors and > their customers might feel compelled to use it out of a > misunderstanding of > the cryptographic issues. Already we have heard potential > customers asking > for support for DRAFT-SHA-256, with the rationale being, "if > IETF approves > it, it must be good". > > Our purpose in submitting this letter is to make sure that > the IPSec working > group has a reasonable understanding of the issues involved in > DRAFT-SHA-256. If the WG decides to approve the draft, we > strongly suggest > that, at a bare minimum, > > a) the inaccurate claims discussed above should be corrected > or removed, > b) the document should be re-worked to clarify the fact that SHA1 is > perfectly adequate, according to current knowledge, > c) the resulting transform should be qualified as > optional-to-implement, not > mandatory, and > d) the draft should make clear under what circumstances the > transform is an > option worth pursuing (e.g. if SHA-1 is broken by advances in > cryptanalysis, > but SHA-256 is not) > > However, given that there is no known cryptographic benefit > to implementing > this proposed standard, we respectfully submit that the IPSec > WG should not > approve this draft. > > Doug Whiting, dwhiting@hifn.com, Hifn > David McGrew, mcgrew@cisco.com, Cisco > Dave Wagner, daw@cs.berkeley.edu, UC Berkeley > Russ Housely, rhousley@rsdsecurity.com, RSA Labs > Niels Ferguson, niels@ferguson.net, MacFergus BV > Thomas Hardjono, thomas.hardjono@verisign.com, Verisign > Scott Fluhrer, fluhrer@cisco.com, Cisco > Jesse Walker, jesse.walker@intel.com, Intel > Mike Sabin, mike.sadin@worldnet.att.net, Independent Consultant > John Kelsey, kelsey.j@ix.netcom.com, Certicom > Russell Dietz, rdietz@hifn.com, Hifn > > Russell Dietz > Hifn, Inc. > pgp-fingerprint: CEE3 58B0 DD09 4EA5 7266 BF1E B5F6 4D1A 4AD1 65B4 > From owner-ipsec@lists.tislabs.com Thu Jul 18 12:12:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6IJCsw21076; Thu, 18 Jul 2002 12:12:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25456 Thu, 18 Jul 2002 14:26:26 -0400 (EDT) To: ipsec@lists.tislabs.com Message-Id: <200207180658.CAA26619@nwmail.wh.lucent.com> Content-Type: text/plain; charset="koi8-r" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs Original-To: Subject: Re: SHA-256-128 Draft: Is this really required? Contradiction... Date: Thu, 18 Jul 2002 02:57:24 -0400 X-Mailer: KMail [version 1.3.2] References: <002001c22e1b$d0877c50$3568e640@ca.alcatel.com> In-Reply-To: <002001c22e1b$d0877c50$3568e640@ca.alcatel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id CAA24244 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thursday 18 July 2002 01:27, Andrew Krywaniuk wrote: > ............................. > that there is no need for SHA-2. (Unless it is to match the security > strength of large DH groups in key derivation............... But how so? How is it any stronger...? The size of the output of a hash function doesn't ensure larger quantity of randomness! SHA-256 has he same 512-bit input buffer. Correlation between its output bits (and whether it exists or not) is unknown. > which............is more a limitation of the key > derivation algorithm than of the hash). Yes! -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Thu Jul 18 12:12:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6IJCsw21074; Thu, 18 Jul 2002 12:12:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25439 Thu, 18 Jul 2002 14:25:23 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87060C06@SARATOGA> Subject: Re: One base SOI ID? Humm To: Gregory Lebovitz Cc: "'ipsec@lists.tislabs.com'" X-Mailer: Lotus Notes Build V60_M14_07042002 Release Candidate July 04, 2002 Message-ID: Date: Wed, 17 Jul 2002 21:08:25 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_M14_07142002 Release Candidate|July 14, 2002) at 07/17/2002 09:57:35 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Barbara just said that if more of this community were physically here at 54 > in Yokohama, she would take a humm poll about whether to move forward with > one SOI ID, one bail of hay. > > Here we go... > > "hum via email if you agree with the two ID authors coming back to the list > with one ID for us to move forward discussing." > > Here's mine: HMMMMM!!! If only life were so simple. Everyone agrees that there should be one ID. The donkey knows he wants hay. The donkey telling the hay to rearrange itself into one bail is unlikely to work. There aren't two authors. IVEv2 has 5 coauthors and JFK has 7. It was a challenge getting them to compromise among themselves. While over time, the two groups have moved towards one another, they are not going to reach agreement without more strong-arming than hums. One way to resolve this is for the working group to declare a winner. Another way (the Soloman approach) is to tell both groups that both proposals will be abandoned unless one group withdraws. I can't predict the outcome, but I don't recommend it. It's possible that a threat that the working group will declare a winner on some date (August 31st?) if consensus is not reached before that will inspire the groups to compromise (based on what they think their respective chances are of winning... like a plea bargain that both sides prefer to rolling the dice even if neither believes it is 'fair'). I propose that a good first step would be for each camp to choose a negotiator and commit (perhaps with reservations) to live with an agreement they reach. Haggling by email is hard. --Charlie Kaufman (ckaufman@notesdev.ibm.com) From owner-ipsec@lists.tislabs.com Thu Jul 18 12:12:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6IJCsw21075; Thu, 18 Jul 2002 12:12:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25481 Thu, 18 Jul 2002 14:27:25 -0400 (EDT) Message-ID: <3D369823.BF21FCC0@era.ericsson.se> Date: Thu, 18 Jul 2002 12:27:47 +0200 From: Mats =?iso-8859-1?Q?N=E4slund?= Organization: Ericsson Research X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Russell Dietz CC: IPSec Working Group , SAAG Subject: Re: [saag] No need for SHA-2 Packet Authentication - Open Letter to the WG and Area Directors References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Russell Dietz wrote: > > Unfortunately, the current draft is misleading in this regard: > "Using the SHA-256 block cipher, with its increased block size (512 bits) > and increased hash length (256 bits), provides the new algorithm with the > ability to withstand continuing advances in crypto-analytic techniques and > computational capability. It also allows less frequent re-keying, which is > useful for high-speed networks and high-volume applications." > It is our belief that, as currently defined in DRAFT-SHA-256, the use of > SHA-256 does not achieve any of these stated goals. If you want to view SHA-256 as a block cipher, the "512" is to be thought of as the key-size and the 160/256 (SHA1/SHA256) corresponds to the block size. Best, /Mats From owner-ipsec@lists.tislabs.com Thu Jul 18 12:13:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6IJDFw21118; Thu, 18 Jul 2002 12:13:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25430 Thu, 18 Jul 2002 14:24:21 -0400 (EDT) Message-Id: <200207170823.AEN11744@mira-sjc5-4.cisco.com> To: Francis Dupont cc: Jari Arkko , ipsec@lists.tislabs.com Subject: Re: IPsec and Mobile IPv6 In-Reply-To: Message from Francis Dupont of "Wed, 17 Jul 2002 09:34:34 +0200." <200207170734.g6H7YYGF068039@givry.rennes.enst-bretagne.fr> Date: Wed, 17 Jul 2002 04:26:00 -0400 From: Melinda Shore Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > PS: I don't know what to do for the future of this draft? I'd like to see it refined and then published as an informational RFC. We've been stymied by this problem in midcom for months and I think that the current draft of our STUN document does a pretty good job of describing the problem and providing crude mitigation of it, but it's specific to STUN and it's certainly not the first place people are going to look for a discussion of security exposures introduced by NAT. I don't think IPSec is the right working group for it, though. Melinda From owner-ipsec@lists.tislabs.com Thu Jul 18 12:13:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6IJDIw21128; Thu, 18 Jul 2002 12:13:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25424 Thu, 18 Jul 2002 14:23:22 -0400 (EDT) Message-ID: <3D35066C.4060900@piuha.net> Date: Wed, 17 Jul 2002 08:53:48 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: ipsec@lists.tislabs.com, "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: IPsec and Mobile IPv6 References: <200207082320.g68NKZGF039788@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.2 required=5.0 tests=GAPPY_TEXT version=2.20 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Francis, > The second version of my draft about IPsec and Mobile IPv6 is > available (name : draft-dupont-ipsec-mipv6-01.txt). (Sorry for the crosspost -- perhaps replies can go to the mobile ip list only.) Your draft looks like a very useful analysis of various cases regarding mobility and IPsec. But I still lack some practical background information so that this work could be taken in account in the relevant protocol descriptions. In particular, could you classify your recommendations as 1) Those that restate something which already is in the current protocol specifications (but perhaps not stated clearly enough). 2) Those which fix something that would break MIPv6 security. Draft draft-ietf-mobileip-ipv6-18.txt uses IPsec for a part of its security, namely for the HA - MN signaling. A more detailed description including SPD entries can be found from http://www.piuha.net/~jarkko/publications/mipv6/ipsec_usage.txt 3) Those which fix something that would break IPsec when used for protecting regular payload traffic in the presense of MIPv6. 4) Those that make IPsec work smoother, more efficiently, or with less configuration when used together with mobility or for the protection of mobility signaling. 5) Architectural long-term recommendations. 6) Something completely different. In particular class 2 is interesting for completing the MIPv6 work, as is class 3. From my initial understanding, your recommendations can be classified as follows: 1) A, C1, C2, E1, E2, E3, G, H, I, K, M, O, Q 2) P [makes use of IKE for HA-MN security hard -- this is very interesting, thanks!] 3) nothing? 4) B, F [and I think we were disagreeing on the mip list whether these two are good goals], L1, L2, R 5) nothing? 6) D [of course!], J unclear: N Is this correct? How do we go about fixing P, is your recommendation the only way to handle that? Is there anything in the MIPv6 documents that you'd like to clarify in class 1? Jari From owner-ipsec@lists.tislabs.com Thu Jul 18 12:13:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6IJDXw21143; Thu, 18 Jul 2002 12:13:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25457 Thu, 18 Jul 2002 14:26:32 -0400 (EDT) Date: Thu, 18 Jul 2002 01:47:23 -0400 Subject: Re: [saag] No need for SHA-2 Packet Authentication - Open Letter to the WG and Area Directors Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: IPSec Working Group , SAAG To: Russell Dietz From: RJ Atkinson In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thursday, July 18, 2002, at 01:39 AM, Russell Dietz wrote: > I totally agree that the Internet tradition of allowing individuals to > publish work should continue unchanged. I apologize if I gave off that > impression in our note. That was not the intent. We need 'optional' > features to be made available to the Internet community in order to > allow > for potential coordinated field 'trials' and interoperability. Thank you for that clarification. > The facts around this draft are that it was added to the charter of the > IPSec WG as part of the AES cipher support effort. (It is a WG draft!) > That > linkage has caused misinformation in the original draft to become > perceived > as pseudo-requirements. The general issue of WG drafts and the > connection > between this draft and the AES/FIPS 180-2 effort have created a great > deal > of confusion at some of the implementers. > > So... the concern is the linkage and the request by the user community > for > implementation as it is 'going to be a standard soon...' IETF is not the only standards-body existing. In particular, the US Government's standards (e.g. FIPS) in fact are going to be (or already are; I'm not 100% current on where NIST stands with this) requiring this hash along with AES for USG applications -- regardless of what the IETF decides should be in its Internet Standards-track specification set. So, purely speaking as a capitalist, if I were a vendor that planned to sell an IPsec-based product to the USG (not a small market and their checks don't bounce), I would want to implement this spec without regard to whether the IETF chose to make it an Internet Standards-track specification.[1] Now I'm not arguing for or against this particular draft going onto the IETF standards-track. I *am* gently suggesting that keeping it off the IETF standards-track is very *unlikely* to greatly reduce customer demand for this option. Now debates about whether my market analysis is correct are probably out of scope here, so maybe should be moved to private email or some other non-IETF context. Ran rja@extremenetworks.com [1] Extreme has no IPsec products. No need for anyone to spin up, this really is a hypothetical statement. :-) From owner-ipsec@lists.tislabs.com Thu Jul 18 12:14:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6IJEYw21171; Thu, 18 Jul 2002 12:14:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25453 Thu, 18 Jul 2002 14:26:24 -0400 (EDT) Date: Thu, 18 Jul 2002 00:41:35 -0400 Mime-Version: 1.0 (Apple Message framework v482) Cc: IPSec Working Group , SAAG Message-Id: In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: [saag] No need for SHA-2 Packet Authentication - Open Letter to the WG a nd Area Directors From: RJ Atkinson Content-Transfer-Encoding: 7bit To: Russell Dietz X-Mailer: Apple Mail (2.482) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wednesday, July 17, 2002, at 08:35 PM, Russell Dietz wrote: > To the IPSec Working Group and Security Area Directors: > > The purpose of this letter is to comment on an existing Internet Draft, > draft-ietf-ipsec-ciph-sha-256-00.txt, dated Nov 2001, co-authored by S. > Frankel and S. Kelley. This draft, hereafter referred to as > DRAFT-SHA-256 > for brevity, defines how to use the new SHA-256 algorithm from NIST > (FIPS > 180-2) for packet authentication within the ESP and AH mechanisms of > IPSec. Russell, I'm pretty indifferent to the topic of what ought or ought not be mandatory-to-implement or maybe even standards-track RFC versus informational RFC. I am remarkably indifferent to any of the mathematical parts of your note or Uri's followup. I do feel pretty strongly that the above referenced draft ought to be permitted to be published, at least as an Informational RFC, so that those folks who choose to implement/deploy it can do so in an interoperable manner. Trying to prevent people from publishing open specifications for entirely optional-to-implement technology is NOT consistent with the Internet tradition. I would hope that the RFC Editor would apply their own good judgement to an individual request to publish such a document as an Informational RFC if the situation should arise. Yours, Ran rja@extremenetworks.com From owner-ipsec@lists.tislabs.com Thu Jul 18 12:14:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6IJEZw21173; Thu, 18 Jul 2002 12:14:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25496 Thu, 18 Jul 2002 14:28:23 -0400 (EDT) Message-ID: <4D79C746863DD51197690002A52CDA00029BD76F@zcard0kc.ca.nortel.com> From: "Marc Desrosiers" To: "'Paul Koning'" , andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com Subject: RE: One base SOI ID? Humm Date: Thu, 18 Jul 2002 10:23:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22E65.CD4BF21A" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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_01C22E65.CD4BF21A Content-Type: text/plain; charset="iso-8859-1" An interesting discussion which seems to keep coming back again and again. IPsec has a mechanism to negotiate encryption; why not do the same for key management. Have the two ends negotiate based on what the session requires. As a default revert back to IKEv1 or a streamlined version of it. Marc DesRosiers -----Original Message----- From: Paul Koning [mailto:pkoning@equallogic.com] Sent: Thursday, July 18, 2002 9:41 AM To: andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com Subject: RE: One base SOI ID? Humm >>>>> "Andrew" == Andrew Krywaniuk writes: Andrew> Maybe some clarification of the poll is in order. What are we Andrew> voting on exactly? I'm not sure what the original question intended to ask, but here's my take on your variants: Andrew> 1. A single SOI protocol vs. 2 protocols? Single protocol. Having two protocols would be a major mistake. Andrew> 2. A merged SOI base vs. using IKEv2 as the base? You mean "merged" as in "JFK and IKEv2 blended together"? If so, then I'd say that doesn't sound like a recipe for rapid forward progress, unless I missed something. Andrew> 3. A single SOI protocol vs. continued uncertainty? The former, emphatically. This process has already taken an amazingly large amount of time. paul ------_=_NextPart_001_01C22E65.CD4BF21A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: One base SOI ID? Humm

An interesting discussion which seems to keep coming = back again and again.

IPsec has a mechanism to negotiate encryption; why = not do the same for key management. Have the two ends negotiate based = on what the session requires. As a default revert back to IKEv1 or a = streamlined version of it.

Marc DesRosiers

-----Original Message-----
From: Paul Koning [mailto:pkoning@equallogic.com= ]
Sent: Thursday, July 18, 2002 9:41 AM
To: andrew.krywaniuk@alcatel.com
Cc: ipsec@lists.tislabs.com
Subject: RE: One base SOI ID? Humm


>>>>> "Andrew" =3D=3D Andrew = Krywaniuk <andrew.krywaniuk@alcatel.com> writes:

 Andrew> Maybe some clarification of the poll = is in order. What are we
 Andrew> voting on exactly?

I'm not sure what the original question intended to = ask, but here's my
take on your variants:

 Andrew> 1. A single SOI protocol vs. 2 = protocols?

Single protocol.  Having two protocols would be = a major mistake.

 Andrew> 2. A merged SOI base vs. using IKEv2 = as the base?

You mean "merged" as in "JFK and IKEv2 = blended together"?  If so,
then I'd say that doesn't sound like a recipe for = rapid forward
progress, unless I missed something.

 Andrew> 3. A single SOI protocol vs. = continued uncertainty?

The former, emphatically.  This process has = already taken an amazingly
large amount of time. 

      paul

------_=_NextPart_001_01C22E65.CD4BF21A-- From owner-ipsec@lists.tislabs.com Thu Jul 18 18:37:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6J1bew07410; Thu, 18 Jul 2002 18:37:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA26193 Thu, 18 Jul 2002 20:41:37 -0400 (EDT) Message-Id: <4.3.2.7.1.20020718174234.00bcb100@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Jul 2002 17:54:13 -0700 To: ipsec@lists.tislabs.com From: Ramana Yarlagadda Subject: combined mode algo Cc: RHousley@rsasecurity.com, DWhiting@hifn.com, kent@bbn.com In-Reply-To: <6F0AA176DA68704884B7507AE6907E180818D7@snake012.odetics.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, The New version of ESP standard talks about the combined mode algorithm. Are there any standard combined mode algortithms? i was looking for the same , and came across CCM and AES-OCB. CCM is submitted to NIST but it;s not a standard yet. what are the algortim that IPSec planning to use in ESP. Can somebody tell me more about this. -thanks -ramana From owner-ipsec@lists.tislabs.com Thu Jul 18 18:43:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6J1hww07541; Thu, 18 Jul 2002 18:43:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA26214 Thu, 18 Jul 2002 21:02:39 -0400 (EDT) Date: Thu, 18 Jul 2002 18:15:53 -0700 (PDT) From: Jan Vilhuber To: "Theodore Ts'o" cc: Subject: Re: SOI QUESTION: 5.2 Scope of proposals In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I favor the in-between apprach Paul Hoffman proposed. But I don't feel strongly either way. jan On Wed, 10 Jul 2002, Theodore Ts'o wrote: > > Please discuss and answer this question: > > 5.2 Scope of proposals > > 5.2.A) Is it important to have predefined suites or a la carte selection of > parameters? > > > Implications from the scenarios: > > [none] > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Thu Jul 18 18:44:09 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6J1i9w07557; Thu, 18 Jul 2002 18:44:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA26220 Thu, 18 Jul 2002 21:03:40 -0400 (EDT) Date: Thu, 18 Jul 2002 18:17:17 -0700 (PDT) From: Jan Vilhuber To: "Theodore Ts'o" cc: Subject: Re: SOI QUESTION: 5.1.2 Agreement of IPsec SA cryptographic algorithms In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 10 Jul 2002, Theodore Ts'o wrote: > > Please discuss and answer this question: > > 5.1.2 Agreement of IPsec SA cryptographic algorithms > > JFK's SA negotiation uses pre-defined suites, and Bob presents a single > suite to Alice. In IKEv2 SA negotiation allows the two parties to agree on > the most preferred parameters, the same as it does for key negotiation. > > 5.1.2.A) Is it important to allow negotiation of the SA algorithms? > Yes. jan > Implications from the scenarios: > > [none] > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Thu Jul 18 18:51:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6J1pkw07711; Thu, 18 Jul 2002 18:51:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA26257 Thu, 18 Jul 2002 21:10:40 -0400 (EDT) Date: Thu, 18 Jul 2002 18:24:16 -0700 (PDT) From: Jan Vilhuber To: "Theodore Ts'o" cc: Subject: Re: SOI QUESTION: 5.3 SPD entries In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 11 Jul 2002, Theodore Ts'o wrote: > > Please discuss and answer the following question: > > > 5.3 SPD entries > > 5.3.A) Is it important in SOI to allow the the responder to accept a subset > of the proposed SA, or should it be an all or nothing acceptance? > Yes. It'll help configuration simplicity. > 5.3.B) Should the SOI offer multiple selectors with specific ports and > addresses, or a single selector with a range of ports and range of > addresses? (complicated boolean complexity!) > We'll need a combination of both to be able to specify discontiguous ranges of ports, which tends to happen with media broadcasts (h.323, etc..). jan > Implications from the scenarios: > > << subnets, a mechanism that allowed the negotiation of a list of phase 2 > identities will help to alleviate the number of IPsec tunnels that must > be created.>>> [[[5.3]]] > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Thu Jul 18 18:55:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6J1tvw07830; Thu, 18 Jul 2002 18:55:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA26269 Thu, 18 Jul 2002 21:12:41 -0400 (EDT) Date: Thu, 18 Jul 2002 18:26:43 -0700 (PDT) From: Jan Vilhuber To: "Theodore Ts'o" cc: Subject: Re: SOI QUESTION: 6. Wire protocol issues: Message Encoding In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 11 Jul 2002, Theodore Ts'o wrote: > > Please discuss and answer the following question: > > > 6. Wire protocol issues > > 6.1 Message encoding > > 6.1.A) Should SOI worry about aligning parts of messages on 2 and 4 > byte boundaries? > Yes. > 6.1.B) Should SOI tag its protocol with version numbers? > Of course (duh). > 6.1.C) Should SOI format be roughly the same as IKEv1? (See > discussion in section 6.4, re: code preserving) > Sure. It's not going to be cut-n-paste programming, but the closer the format, the better we can leverage what we already KNOW of IKE and how to implement it. jan > Implications from the Scenarios: > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Thu Jul 18 18:57:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6J1vjw07875; Thu, 18 Jul 2002 18:57:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA26281 Thu, 18 Jul 2002 21:14:42 -0400 (EDT) Date: Thu, 18 Jul 2002 18:28:20 -0700 (PDT) From: Jan Vilhuber To: "Theodore Ts'o" cc: Subject: Re: SOI QUESTION: 6.2 Port number In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 11 Jul 2002, Theodore Ts'o wrote: > > Please discuss and answer the following question: > > > 6.2 Port number > > 6.2.A) Should SOI use the same port as IKEv1? (See discussion in > soi-features-01 the tradeoffs in this question). > I don't feel strongly, but it seems to me that it would make incremental deployment much easier (clients that talk only v1 send v1 to the same port, and the server that talks v1 and v2 can do the appropriate thing; the situation is a bit more complex when the situation is reversed, but not onerously so). jan > Implications from the Scenarios: > > [none] > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Thu Jul 18 18:57:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6J1vqw07887; Thu, 18 Jul 2002 18:57:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA26293 Thu, 18 Jul 2002 21:16:43 -0400 (EDT) Date: Thu, 18 Jul 2002 18:30:14 -0700 (PDT) From: Jan Vilhuber To: "Theodore Ts'o" cc: Subject: Re: SOI QUESTION: 6.3 Future versions of the protocols In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 12 Jul 2002, Theodore Ts'o wrote: > > 6.3 Future versions of the protocols > > 6.3.A) Should SOI have a mechanism for demanding/requesting that a > peer use a particular version of IKE/SOI to allow upgrading to new > versions? > That sounds desirable. If it can easily and unambiguously be done by inference (i.e. without negotiation) that would be better. I suspect that's not possible. jan > Implications from the Scenarios: > > [none] > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Thu Jul 18 19:04:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6J24Uw08030; Thu, 18 Jul 2002 19:04:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA26316 Thu, 18 Jul 2002 21:21:45 -0400 (EDT) Date: Thu, 18 Jul 2002 18:35:27 -0700 (PDT) From: Jan Vilhuber To: "Theodore Ts'o" cc: Subject: Re: SOI QUESTION: 6.4 Code-preservingness In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 12 Jul 2002, Theodore Ts'o wrote: > > Please discuss and answer the following question: > > > 6.4 Code-preservingness > > 6.4.A) Is it important that SOI allow some amounts of an IKEv1 > implementation be reusable when creating an SOI implementation? > The large parts in IKE aren't IKE itself, but ASN.1, pkcs, x509, etc for certificates. Some of the crypto primitives are large (comparatively). The IKE code itself isn't that large and can be trimmed down by profiling. I don't think we want to constrain ourselves to making sure we can reuse existing code. Where it makes sense, sure. Where it doesn't amke sense, write new code. If the format of the messages (see previous message about wire format) is sufficiently the same, the new code is pretty trivial in that most implementors are already familiar with it. > > Implications from the Scenarios: > > IPS: <<<[ietf-ips-security-xx.txt] discusses resource constraints, > calling out the size for both code footprint and data as the most > important criteria.>>> [[[6]]] > I support all efforts to profile IKE, x.509, asn.1, etc. Not having to have a full asn.1 and x.509 parser would reduce code sizes tremendously. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Thu Jul 18 19:08:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6J28Tw08108; Thu, 18 Jul 2002 19:08:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA26331 Thu, 18 Jul 2002 21:26:46 -0400 (EDT) Date: Thu, 18 Jul 2002 18:40:06 -0700 (PDT) From: Jan Vilhuber To: "Theodore Ts'o" cc: Subject: Re: SOI QUESTION: 6.5 Extensibility of the protocols In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 12 Jul 2002, Theodore Ts'o wrote: > > Please discuss and answer the following question (last one!): > > > 6.5 Extensibility of the protocols > > 6.5.A) Should SOI have mechanisms for allowing extensions to the SOI > protocol? > Absolutely. Yes. Being able to prototype and roll out non-standard extension is how progress is made. Xauth and config-mode break that rule, of course (because they break interoperability). We wouldn't be able to talk about keepalives without having rolled it out as an extension, for example. That being said, there needs to be a better way than the vendor ID (I prefer radius' mechanism (attribute 26 Vendor Specific in rfc 2138); I can dig out my proposal to do such a mechanism in IKE if people are interested). > 6.5.B) Should SOI need a way to mark new extensions as critical? > (i.e. If you don't understand a critical extension you must fail the > entire negotiation) > Sounds good to me. I'm not a strong advocate of the critical bit, but I can see its value. jan > Implications from the Scenarios: > > VPN, End-to-End, : << parameters are needed in order to negotiate QoS characteristics for > the various tunnels.>>> [[[6.5]]] > > IPS: << requirements for an API, in order to provide a means of pushing > authentication information to the application (e.g. "this peer was > authenticated with this cert"), so the application can decide what types > of transactions are allowed by this peer.>>> [[[6.5]]] > > PPVPN/MPLS: << identifiers to also support an MPLS/VPN identifier (so the entity > doing the SPD check can be separated from the entity doing the > encapsulation).>>> [[[6.5]]] > > Implications from the Scenarios: > > [none] > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Thu Jul 18 20:44:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6J3igw10170; Thu, 18 Jul 2002 20:44:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA26655 Thu, 18 Jul 2002 23:02:28 -0400 (EDT) Message-Id: <3.0.3.32.20020718201652.012e3e70@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 18 Jul 2002 20:16:52 -0700 To: Charlie_Kaufman@notesdev.ibm.com, Gregory Lebovitz From: Alex Alten Subject: Re: One base SOI ID? Humm Cc: "'ipsec@lists.tislabs.com'" In-Reply-To: References: <541402FFDC56DA499E7E13329ABFEA87060C06@SARATOGA> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It sounds like the requirements were never really spec'd out. Why not specify the top 10 requirements, and then run a test/ runoff/review of the two proposals. The one that meets the 10 requirements the best should be the winner. - Alex At 09:08 PM 7/17/2002 -0400, Charlie_Kaufman@notesdev.ibm.com wrote: > > > > >> Barbara just said that if more of this community were physically here at >54 >> in Yokohama, she would take a humm poll about whether to move forward >with >> one SOI ID, one bail of hay. >> >> Here we go... >> >> "hum via email if you agree with the two ID authors coming back to the >list >> with one ID for us to move forward discussing." >> >> Here's mine: HMMMMM!!! > >If only life were so simple. Everyone agrees that there should be one ID. >The donkey knows he wants hay. The donkey telling the hay to rearrange >itself into one bail is unlikely to work. There aren't two authors. IVEv2 >has >5 coauthors and JFK has 7. It was a challenge getting them to compromise >among themselves. While over time, the two groups have moved towards >one another, they are not going to reach agreement without more >strong-arming than hums. > >One way to resolve this is for the working group to declare a winner. >Another way (the Soloman approach) is to tell both groups that both >proposals will be abandoned unless one group withdraws. I can't >predict the outcome, but I don't recommend it. > >It's possible that a threat that the working group will declare >a winner on some date (August 31st?) if consensus is not reached >before that will inspire the groups to compromise (based on what >they think their respective chances are of winning... like a plea >bargain that both sides prefer to rolling the dice even if neither >believes it is 'fair'). > >I propose that a good first step would be for each camp to >choose a negotiator and commit (perhaps with reservations) >to live with an agreement they reach. Haggling by email is >hard. > > --Charlie Kaufman > (ckaufman@notesdev.ibm.com) > -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Fri Jul 19 01:22:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6J8MUw08232; Fri, 19 Jul 2002 01:22:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA27066 Fri, 19 Jul 2002 03:30:58 -0400 (EDT) Date: 19 Jul 2002 03:30:17 -0400 Message-ID: <000b01c22ef6$22a64630$a472e640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Alex Alten'" Cc: "'list'" Subject: RE: One base SOI ID? Humm MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3.0.3.32.20020718201652.012e3e70@mail> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk That's really easy to say, but the IPsec working groups is everyone's favorite tourist trap, not a small group of like-minded individuals that formed a BOF yesterday. Part of the group wants simplicity and minimalism at all costs and part of the group wants features X, Y, and Z. The requirements process tends to break down when the top two requirements are mutually contradictory. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Alex Alten > Sent: Thursday, July 18, 2002 11:17 PM > To: Charlie_Kaufman@notesdev.ibm.com; Gregory Lebovitz > Cc: 'ipsec@lists.tislabs.com' > Subject: Re: One base SOI ID? Humm > > > It sounds like the requirements were never really spec'd out. > Why not specify the top 10 requirements, and then run a test/ > runoff/review of the two proposals. The one that meets the 10 > requirements the best should be the winner. > > - Alex > > At 09:08 PM 7/17/2002 -0400, Charlie_Kaufman@notesdev.ibm.com wrote: > > > > > > > > > >> Barbara just said that if more of this community were > physically here at > >54 > >> in Yokohama, she would take a humm poll about whether to > move forward > >with > >> one SOI ID, one bail of hay. > >> > >> Here we go... > >> > >> "hum via email if you agree with the two ID authors coming > back to the > >list > >> with one ID for us to move forward discussing." > >> > >> Here's mine: HMMMMM!!! > > > >If only life were so simple. Everyone agrees that there > should be one ID. > >The donkey knows he wants hay. The donkey telling the hay to > rearrange > >itself into one bail is unlikely to work. There aren't two > authors. IVEv2 > >has > >5 coauthors and JFK has 7. It was a challenge getting them > to compromise > >among themselves. While over time, the two groups have moved towards > >one another, they are not going to reach agreement without more > >strong-arming than hums. > > > >One way to resolve this is for the working group to declare a winner. > >Another way (the Soloman approach) is to tell both groups that both > >proposals will be abandoned unless one group withdraws. I can't > >predict the outcome, but I don't recommend it. > > > >It's possible that a threat that the working group will declare > >a winner on some date (August 31st?) if consensus is not reached > >before that will inspire the groups to compromise (based on what > >they think their respective chances are of winning... like a plea > >bargain that both sides prefer to rolling the dice even if neither > >believes it is 'fair'). > > > >I propose that a good first step would be for each camp to > >choose a negotiator and commit (perhaps with reservations) > >to live with an agreement they reach. Haggling by email is > >hard. > > > > --Charlie Kaufman > > (ckaufman@notesdev.ibm.com) > > > -- > > Alex Alten > Alten@ATTBI.com > From owner-ipsec@lists.tislabs.com Fri Jul 19 07:06:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6JE6kw05985; Fri, 19 Jul 2002 07:06:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27524 Fri, 19 Jul 2002 09:18:56 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60303C9DA@zcard0ke.ca.nortel.com> From: "Dennis Beard" To: Charlie_Kaufman@notesdev.ibm.com, Gregory Lebovitz Cc: "'ipsec@lists.tislabs.com'" Subject: RE: One base SOI ID? Humm Date: Thu, 18 Jul 2002 18:56:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22EAE.6B1ACE42" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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_01C22EAE.6B1ACE42 Content-Type: text/plain; charset="iso-8859-1" Another excellent point Charlie!! My observation all along was that there are today (and months ago) two protocol drafts that were mature. In my humble opinion, supported by my colleagues back home that will have to implement the next generation of IKE, the draft known as IKE v2 is a complete protocol specification and a relatively easy transition from v1. The comments from the list as summarized at the WG meeting this week were closely tracking what the v2 draft was already proposing (Charlie's opening observation before he presented the summary of comments). The current draft is good enough in our view and we would not like to see this IKEv2 draft become so homogenized with the other "bale of hay" as to render it unrecognizable from its current rendition. Keep up the good work Charlie for good protocols. Cheers, Dennis Beard Oh yeah, here's a mega HUMMM for v2. -----Original Message----- From: Charlie_Kaufman@notesdev.ibm.com [mailto:Charlie_Kaufman@notesdev.ibm.com] Sent: Wednesday, July 17, 2002 9:08 PM To: Gregory Lebovitz Cc: 'ipsec@lists.tislabs.com' Subject: Re: One base SOI ID? Humm > Barbara just said that if more of this community were physically here at 54 > in Yokohama, she would take a humm poll about whether to move forward with > one SOI ID, one bail of hay. > > Here we go... > > "hum via email if you agree with the two ID authors coming back to the list > with one ID for us to move forward discussing." > > Here's mine: HMMMMM!!! If only life were so simple. Everyone agrees that there should be one ID. The donkey knows he wants hay. The donkey telling the hay to rearrange itself into one bail is unlikely to work. There aren't two authors. IVEv2 has 5 coauthors and JFK has 7. It was a challenge getting them to compromise among themselves. While over time, the two groups have moved towards one another, they are not going to reach agreement without more strong-arming than hums. One way to resolve this is for the working group to declare a winner. Another way (the Soloman approach) is to tell both groups that both proposals will be abandoned unless one group withdraws. I can't predict the outcome, but I don't recommend it. It's possible that a threat that the working group will declare a winner on some date (August 31st?) if consensus is not reached before that will inspire the groups to compromise (based on what they think their respective chances are of winning... like a plea bargain that both sides prefer to rolling the dice even if neither believes it is 'fair'). I propose that a good first step would be for each camp to choose a negotiator and commit (perhaps with reservations) to live with an agreement they reach. Haggling by email is hard. --Charlie Kaufman (ckaufman@notesdev.ibm.com) ------_=_NextPart_001_01C22EAE.6B1ACE42 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: One base SOI ID? Humm

Another excellent point Charlie!!  My = observation all along was that there are today (and months ago) two = protocol drafts that were mature.  In my humble opinion, supported = by my colleagues back home that will have to implement the next = generation of IKE, the draft known as IKE v2 is a complete protocol = specification and a relatively easy transition from v1.  The = comments from the list as summarized at the WG meeting this week were = closely tracking what the v2 draft was already proposing (Charlie's = opening observation before he presented the summary of comments).  = The current draft is good enough in our view and we would not like to = see this IKEv2 draft become so homogenized with the other "bale of = hay" as to render it unrecognizable from its current = rendition.

Keep up the good work Charlie for good = protocols.

Cheers,

Dennis Beard

Oh yeah, here's a mega HUMMM for v2.

-----Original Message-----
From: Charlie_Kaufman@notesdev.ibm.com
[mailto:Charlie_Kaufman@= notesdev.ibm.com]
Sent: Wednesday, July 17, 2002 9:08 PM
To: Gregory Lebovitz
Cc: 'ipsec@lists.tislabs.com'
Subject: Re: One base SOI ID? Humm






> Barbara just said that if more of this community = were physically here at
54
> in Yokohama, she would take a humm poll about = whether to move forward
with
> one SOI ID, one bail of hay.
>
> Here we go...
>
> "hum via email if you agree with the two = ID authors coming back to the
list
> with one ID for us to move forward = discussing."
>
> Here's mine:    HMMMMM!!!

If only life were so simple. Everyone agrees that = there should be one ID.
The donkey knows he wants hay. The donkey telling = the hay to rearrange
itself into one bail is unlikely to work. There = aren't two authors. IVEv2
has
5 coauthors and JFK has 7. It was a challenge = getting them to compromise
among themselves. While over time, the two groups = have moved towards
one another, they are not going to reach agreement = without more
strong-arming than hums.

One way to resolve this is for the working group to = declare a winner.
Another way (the Soloman approach) is to tell both = groups that both
proposals will be abandoned unless one group = withdraws. I can't
predict the outcome, but I don't recommend = it.

It's possible that a threat that the working group = will declare
a winner on some date (August 31st?) if consensus is = not reached
before that will inspire the groups to compromise = (based on what
they think their respective chances are of = winning... like a plea
bargain that both sides prefer to rolling the dice = even if neither
believes it is 'fair').

I propose that a good first step would be for each = camp to
choose a negotiator and commit (perhaps with = reservations)
to live with an agreement they reach. Haggling by = email is
hard.

          = --Charlie Kaufman
         = (ckaufman@notesdev.ibm.com)

------_=_NextPart_001_01C22EAE.6B1ACE42-- From owner-ipsec@lists.tislabs.com Fri Jul 19 10:15:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6JHFTw26917; Fri, 19 Jul 2002 10:15:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28206 Fri, 19 Jul 2002 12:02:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <3.0.3.32.20020718201652.012e3e70@mail> References: <541402FFDC56DA499E7E13329ABFEA87060C06@SARATOGA> <3.0.3.32.20020718201652.012e3e70@mail> Date: Fri, 19 Jul 2002 09:16:22 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: One base SOI ID? Humm Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:16 PM -0700 7/18/02, Alex Alten wrote: >It sounds like the requirements were never really spec'd out. >Why not specify the top 10 requirements, and then run a test/ >runoff/review of the two proposals. The one that meets the 10 >requirements the best should be the winner. Errrr, that is what the past many weeks of questions from the WG chairs was doing. If you were following it, you would have seen that there was no unanimity among the WG about what are the requirements. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sat Jul 20 08:18:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6KFIXw11524; Sat, 20 Jul 2002 08:18:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA29777 Sat, 20 Jul 2002 10:27:13 -0400 (EDT) Message-Id: <4.3.2.7.2.20020720073224.02473a80@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 20 Jul 2002 07:38:10 -0700 To: Stephen Kent From: Mark Baugher Subject: Re: new version of ESP ID Cc: ipsec@lists.tislabs.com, msec@securemulticast.org In-Reply-To: References: <4.3.2.7.2.20020709135351.0251a3f0@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020709135351.0251a3f0@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, At 05:54 PM 7/12/2002 -0400, Stephen Kent wrote: >Mark, > >> >>I don't understand the distinction between static and dynamic SAs. >>Is the distinction between a single-sender multicast SA versus >>a multi-sender multicast SA? >> >>I think that it is a more robust solution to identify the multicast >>SA using the source address as well as the SPI and destination >>address. This is what many of us who worked in smug thought we >>would do with MESP. Now that Steve is addressing multicast in >>ESP and AH, it's not clear to me how msec should proceed with >>MESP. > >There is a big distinction between single and multi-sender SAs, as we have >discussed. One cannot make use of anti-replay for a multi-sender SA, >unless we seriously change the model and I explained in my message to Bill >why I don't think that's a reasonable change to pursue. I think I understand your rationale. We should at least document the fact that it may be necessary to identify the multicast ESP SA using the triple for source-specific multicast - for some applications. I think Bill and Radia's previous comments to this thread explain why. If all sources to a multicast address use the same group key controller, then I don't see a problem. If some sources to a multicast address use distinct group key controllers (e.g., each source acts as its own controller), then there is the potential for SPI collisions and means must be invented to handle these collisions. Mark >I am opposed to the suggestion to use both source and destination address >for demuxing multicast SAs, as it just adds to the comparisons that need >to me made. As more folks go to high speed hardware implementations, using >more fields for demuxing turns into more CAM entries, ... Why can't we >swap destination address demuxing for source address demuxing for multicast? > >Steve From owner-ipsec@lists.tislabs.com Sat Jul 20 23:52:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6L6qIw18486; Sat, 20 Jul 2002 23:52:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA00653 Sun, 21 Jul 2002 01:49:52 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <4.3.2.7.1.20020718174234.00bcb100@golf.cpgdesign.analog.com> References: <4.3.2.7.1.20020718174234.00bcb100@golf.cpgdesign.analog.com> Date: Sun, 21 Jul 2002 02:01:23 -0400 To: Ramana Yarlagadda From: Stephen Kent Subject: Re: combined mode algo Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 5:54 PM -0700 7/18/02, Ramana Yarlagadda wrote: >Hi, > >The New version of ESP standard talks about the combined mode >algorithm. Are there any standard combined mode algortithms? > >i was looking for the same , and came across CCM and AES-OCB. CCM is >submitted to NIST but it;s not a standard yet. > >what are the algortim that IPSec planning to use in ESP. > >Can somebody tell me more about this. > >-thanks >-ramana There are no agreed-to combined mode algorithms for IPsec yet. Steve From owner-ipsec@lists.tislabs.com Sun Jul 21 03:00:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6LA0Qw11922; Sun, 21 Jul 2002 03:00:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00850 Sun, 21 Jul 2002 05:13:33 -0400 (EDT) Message-Id: <3.0.3.32.20020721022754.01355d98@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sun, 21 Jul 2002 02:27:54 -0700 To: Paul Hoffman / VPNC , ipsec@lists.tislabs.com From: Alex Alten Subject: Re: One base SOI ID? Humm In-Reply-To: References: <3.0.3.32.20020718201652.012e3e70@mail> <541402FFDC56DA499E7E13329ABFEA87060C06@SARATOGA> <3.0.3.32.20020718201652.012e3e70@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:16 AM 7/19/2002 -0700, Paul Hoffman / VPNC wrote: >At 8:16 PM -0700 7/18/02, Alex Alten wrote: >>It sounds like the requirements were never really spec'd out. >>Why not specify the top 10 requirements, and then run a test/ >>runoff/review of the two proposals. The one that meets the 10 >>requirements the best should be the winner. > >Errrr, that is what the past many weeks of questions from the WG >chairs was doing. If you were following it, you would have seen that >there was no unanimity among the WG about what are the requirements. > Hmm... If that's the case then probably the only way to decide is to have the WG abide by the results of a coin toss. Good luck. - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Sun Jul 21 04:14:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6LBE1w17425; Sun, 21 Jul 2002 04:14:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA00958 Sun, 21 Jul 2002 06:23:48 -0400 (EDT) Message-Id: <3.0.3.32.20020721033734.013b19d8@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sun, 21 Jul 2002 03:37:34 -0700 To: Paul Hoffman / VPNC , ipsec@lists.tislabs.com From: Alex Alten Subject: Re: One base SOI ID? Humm In-Reply-To: References: <3.0.3.32.20020718201652.012e3e70@mail> <541402FFDC56DA499E7E13329ABFEA87060C06@SARATOGA> <3.0.3.32.20020718201652.012e3e70@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:16 AM 7/19/2002 -0700, Paul Hoffman / VPNC wrote: >At 8:16 PM -0700 7/18/02, Alex Alten wrote: >>It sounds like the requirements were never really spec'd out. >>Why not specify the top 10 requirements, and then run a test/ >>runoff/review of the two proposals. The one that meets the 10 >>requirements the best should be the winner. > >Errrr, that is what the past many weeks of questions from the WG >chairs was doing. If you were following it, you would have seen that >there was no unanimity among the WG about what are the requirements. > Paul, Forget my last email. Are you saying that the WG is trying to set the requirements *after* the two proposals have been presented already? If so, no wonder there is no unanimity. Each proposal's supporters now have too much sweat, pride and ego at stake. Hopefully it can be resolved quickly. The last cat fight I was involved with was security for SNMPv2. I'm not eager to repeat that bad experience. Again, good luck. - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Sun Jul 21 09:08:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6LG8Fw03659; Sun, 21 Jul 2002 09:08:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01212 Sun, 21 Jul 2002 11:21:25 -0400 (EDT) Message-Id: <200207211535.g6LFZJGF084332@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net cc: ipsec@lists.tislabs.com, "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: IPsec and Mobile IPv6 In-reply-to: Your message of Wed, 17 Jul 2002 08:53:48 +0300. <3D35066C.4060900@piuha.net> Date: Sun, 21 Jul 2002 17:35:19 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: I've revisited your classification: 1A) [Already in IPsec specs] C1, C2, G, H, I, J, L1, L2, M, Q, R 1B) [Already in Mobile IPv6 specs] A, E1, E2, E3, O 2) [Fixes for Mobile IPv6] N, P 3) [Fixes for IPsec in a Mobile IPv6 context] none 4) [IPsec improvements for Mobile IPv6] B, F, K 5) [Architectural long-term recommendations] Appendix B 6) [Other stuffs] D, Appendix D Is there anything in the MIPv6 documents that you'd like to clarify in class 1? => I believe we should make the mobile VPN a subset of Mobile IPv6. Mostly we have to relax the usage of tunnels between a CN and a MN, in current specifications we have for the CN: - if the packet is not genuine (i.e., is forwarded): * nothing if the CN is not the HA * tunneling if the CN is the HA - lookup in the binding cache per CN address * nothing is no entry found, fallback to the previous case on the HA * routing header if a valid entry is found. On a mobile VPN CNs have no BC and the SG takes the role of the HA but it puts all packets in the tunnel, so I propose to relax the Mobile IPv6 rules in two ways: - tunneling may replace the routing header (this is useful for the mobile to mobile case too) - the only mandatory usage of a routing header is for signaling (i.e., for genuine packets with a mobile header). For the MN, the obvious thing is to authorize tunneling in place of the HAO for non-signaling traffic. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sun Jul 21 09:37:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6LGbiw04162; Sun, 21 Jul 2002 09:37:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01249 Sun, 21 Jul 2002 11:55:29 -0400 (EDT) Message-Id: <200207202301.g6KN0av6005385@marajade.sandelman.ottawa.on.ca> To: "'ipsec@lists.tislabs.com'" Subject: Re: One base SOI ID? Humm In-reply-to: Your message of "Wed, 17 Jul 2002 21:08:25 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 20 Jul 2002 19:00:35 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charlie" == Charlie Kaufman writes: Charlie> itself into one bail is unlikely to work. There aren't two authors. IVEv2 Charlie> has Charlie> 5 coauthors and JFK has 7. It was a challenge getting them to compromise Charlie> among themselves. While over time, the two groups have moved towards Charlie> one another, they are not going to reach agreement without more Charlie> strong-arming than hums. A third way is to take the authors (all 12 of them), split them (randomly) into three teams of 4 (cause 5 and 7 is way too big), and tell each team to come to a new compromise. That might get us three drafts, but my bet is that at least one group will either deadlock, or will produce something identical to the other groups. The resulting hay bails may now not be so evenly distributed. Charlie> I propose that a good first step would be for each camp to Charlie> choose a negotiator and commit (perhaps with reservations) Charlie> to live with an agreement they reach. Haggling by email is Charlie> hard. Agreed. And meet in person for an extended period of time, and bring a moderator, but limit participation to 4 people max. ] Internet Security. Have encryption, will travel |1 Fish/2 Fish [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F [ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [ ] At the far end of some dark fiber - wait that's dirt! |for everyone [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPTnrkIqHRg3pndX9AQHS3QP9Ei4tg6ZI8tIJ49DzaIyXU/Ws/Q7hYKsJ c9QK93+NUFVftCbD2ZolAePRcdDZZlsrv96C74wxkVH0Qn+SXZF2k7+5XAePRH7P kVt/YkTrgaE+3/jNE94bDkkSyjX6+UOZHYCPKUL3/5AmHSXsXaA6dnVzuDP+Q2gF xoTG0YMaVmg= =Nlbo -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Jul 22 08:42:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6MFg9w19911; Mon, 22 Jul 2002 08:42:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02776 Mon, 22 Jul 2002 10:43:08 -0400 (EDT) From: "Stephane Beaulieu" To: "Theodore Ts'o" , Subject: RE: SOI QUESTION: 6.5 Extensibility of the protocols Date: Mon, 22 Jul 2002 10:57:07 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > 6.5 Extensibility of the protocols > > 6.5.A) Should SOI have mechanisms for allowing extensions to the SOI > protocol? Yes > > 6.5.B) Should SOI need a way to mark new extensions as critical? > (i.e. If you don't understand a critical extension you must fail the > entire negotiation) Yes > > Implications from the Scenarios: > > VPN, End-to-End, : << parameters are needed in order to negotiate QoS characteristics for > the various tunnels.>>> [[[6.5]]] > > IPS: << requirements for an API, in order to provide a means of pushing > authentication information to the application (e.g. "this peer was > authenticated with this cert"), so the application can decide what types > of transactions are allowed by this peer.>>> [[[6.5]]] > > PPVPN/MPLS: << identifiers to also support an MPLS/VPN identifier (so the entity > doing the SPD check can be separated from the entity doing the > encapsulation).>>> [[[6.5]]] > > Implications from the Scenarios: > > [none] From owner-ipsec@lists.tislabs.com Mon Jul 22 11:19:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6MIJjw27818; Mon, 22 Jul 2002 11:19:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03045 Mon, 22 Jul 2002 13:24:15 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869B3A@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Christina Helbig'" , "'Russell Dietz'" , IPSec Working Group , SAAG Subject: RE: [saag] RE: No need for SHA-2 Packet Authentication - Open Let ter to the WG a nd Area Directors Date: Mon, 22 Jul 2002 10:39:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Given that the only party for whom SHA-256 use is postulated as being mandated is the US federal government, has anyone from the US federal govt. actually stated that they intend to make SHA-256 a requirement over SHA-1? My understanding is that the new SHA hashes are supplemental to SHA-1 and that the accreditation for SHA-1 is unaffected (at least for the moment).Certainly one would hope to see DSA updated before SHA-1 is withdrawn! Has anyone heard different in this regard? Phill From owner-ipsec@lists.tislabs.com Mon Jul 22 12:51:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6MJpIw04440; Mon, 22 Jul 2002 12:51:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03180 Mon, 22 Jul 2002 14:59:03 -0400 (EDT) Message-Id: <4.3.2.7.2.20020722120501.0322f738@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Jul 2002 12:11:22 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: draft minutes from wg meeting Cc: byf@cisco.com, tytso@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi folks, Here are the draft minutes from the wg meeting. Please send any corrections to me in the next week. I plan to submit these along with the slides next Tuesday, July 30. Many thanks to Dennis Beard for taking such detailed notes! Barb Wednesday 7/17/02: IPsec WG (afternoon session) Minutes taken by: Dennis Beard Barbara Fraser and Ted Tso are the co-chairs of the IPsec WG. For this meeting, Barbara was the single Chair. The meeting began at 15:30. Status of current document - Barbara Fraser 15:30-15:35 Agenda bashing - Fraser 15:35-15:45 Status of current docs - Fraser 15:45-15:50 Nat-T - Dixon 15:50-16:00 IPsec and mobile IPv6 - Dupont 16:00-16:05 Latest AH draft - Kent 16:05-16:10 Multicast and IPsec - Kent 16:10-16:30 SOI Discussion Summary - Kaufman 16:30-17:15 Open Mic 17:15-17:30 SOI Proposed Schedule - Fraser 17:30 Adjourn NAT-T - William Dixon Due to a misunderstanding of presentation scheduling, William had no prepared charts. He did, however, brief the WG on the latest status concerning NAT-T drafts. The technical drafts are now in last call in the IPsec Working Group. They are: draft-ietf-ipsec-nat-t-ike-03.txt draft-ietf-ipsec-nat-reqts-01.txt draft-ietf-ipsec-udp-encaps-03.txt Latest changes include the following: Draft-03 versions submitted to update the author list and make some clarifications. The draft-ietf-ipsec-nat-t-ike-03.txt did change the Vendor-ID string to represent draft-03, although there are no changes that would make it interoperably different from draft-02, except the vendor ID. Vendors, which have implemented draft-02, should accept draft-02's vendor ID. If recent implementation was done according to draft-03, send the vendor ID for draft 02 as well to interoperate. Note however, the vendor ID string in draft 02 was wrong for the hash value. Implementers should use the MD5 hash hex value, not the string to interoperate with other implementations. Draft-ietf-ipsec-nat-reqts-01.txt was updated March '02. There are clarifications that could be made, but the authors are reviewing whether these are really needed. Authors will send a note to the IPsec WG list if the is a decision to update with these clarifications. There is a clarification email that is ready to be sent to the WG list to describe implementation techniques possible for multiple clients behind the same NAT going to the same destination. This was distributed on July 18th. There are a number of independent implementations of draft-02: SSH, Cisco, Microsoft at least. There were approximately 8 to 10 vendors total testing some part of an implementation last August with draft-01 UDP500. Interop Testing Draft-02 versions with UDP4500 have not been covered by a bakeoff. The bakeoff last August covered draft-01 that didn't use UDP4500 encapsulation. Vendors should be testing with each other. There is one IPR question that only implementers can answer. The answer should be reflected in their comments on the list, to WG chairs, ADs or IESG during this Last Call period: Whether SSH's IPR terms are too broad to be considered OK by the WG for a standards track RFC since it allegedly purports to cover technology that is mandatory to implement. This question comes up as a result of the recent (last 3 months) SAAG discussion (on SRP) on what IPR constraints are acceptable for technology that covers mandatory to implement features of IETF drafts. The concern is that the non-assert limitation is too broad, in that it covers all other IETF IP. The URL for IRP/SSH-NAT can be found at: http://www.ietf.org/ietf/IPR/SSH-NAT IPsec and mobile Ipv6 - Francis Dupont: draft-pdupont-ipsec-mipv6-01.txt Francis provided a quick summary on the status of his draft. One basic idea was to remove the "versus". The draft provides many small implementation choices. It seeks to remove double encapsulated (i.e. no tunnel in a tunnel) tunnels. The ultimate target: an endpoint address update exchange in SOI (next version of IKE). IKEv2 and mobile IPv6 Sec 2.11 address and port agility: IKE implicitly sets up ESP, AH and IPCOMP associations for the same IP address it runs over. Proposal; add an option to protect the transport address when NAT traversal is not wanted or required. Proposal; use only the SPI (i.e. cookies) to select the proper ISAKMP/IKE SA. A peer may change its transport address between "phase 2 exchanges. Proposal; add an optional return-routability check when a peer changes its transport address Proposal; add a new transport address update exchange to avoid the current mandatory and expensive rekeying. Steve Kent raised the following question. Francis mentioned a security flaw in relation to the tunnel over tunnel encapsulation scenario but the problem was not clearly articulated. It was offered as an observation by Steve Kent that the problem is not with the outer wrapper. Francis replies that it was an issue with traffic routing, not so much a security flaw per se but it may still lead to a DoS. Does this attack require a Man in the Middle Steve. Kent asks? WG Chair, Barbara Fraser, asks where is the threat draft. Francis says he will send this issue to the list for advisement. Next question from the floor: Jari Arkio asks, "Does this require code change in IPsec and/or IPv6? Francis Dupont replies that it is minimal in IPv6 but may have more changes in IPsec. Jari seeks further clarification: "in order to interoperate with IPv6 mobile node and the user wants to employ IPsec and the other node is IPv4, is there an interoperability problem? This issue wasn't resolved. Latest AH Draft - Steve Kent Continuation of revisions for AH and ESP. Revisions posted but received very few comments over the month. However, Steve did try to reflect changes in his briefing. There will be an IPsec DOI addendum for ESP option as requested by the WG co-chairs. Multicast and IPsec Multicast issue: Clarify SA identification, terminology change (authen->integrity). Change 64 bit sequence numbers. Identifying a multicast SA: A multicast SA was previously identified by destination IP address and SPI that assumed a single controller for a given multicast group. Suggestion was made to identify multicast SA by source address, to accommodate SSM. Later comments from the list suggest that both addresses plus SPI are needed to demux multicast SAs. Observation offered; where contradictory direction exist, Steve said he needs precise clarifications of what is needed for demuxing. Vendors are starting to put up requirement of speed for demux. Anti-reply For single multicast sender there is no issue. However, with multi-sender SAs is different. . Suggestions that receivers maintain a separate window for every sender would not scale well nor would there be many vendors willing to go down that complicated path. Therefore, the group will have to decide how to handle multi-sender SAs or just say no to the use of anti-replay. There were no questions for Steve. He did stress again that the WG needs to decide on some of the issues before the drafts can advance. SOI Discussion Summary - Charles Kaufman Charlie was "volunteered" to summarize the comments from the WG mailing list as related to the SOI requirements. The requirements for the next version of IKE have been sent to the list over the last several weeks by the WG co-chairs. This exercise was instituted to obtain a sense of what features the members would like to see in the next version. Charlie's opening observation was that as he examined the results from the mailing list closely, the overall consensuses leaned towards those requirements that are already articulated in the draft known as IKEv2. Charlie is one of the co-authors of that draft and is well versed on the details contained in that draft. For each of the requirement/feature questions sent out to the membership Charlie summarized those points. (See Charlie's slides) Angelos Keromytis made a clarifying point in regards to establishing an SA. The JFK draft states that under its SA establishment scenario, 4 messages are always used for this purpose. Angelos is a co-author of the JFK draft. Steve Bellovin, Security Area Director, strongly commented that any drafts that contained specific vendor extensions would cause the IESG to be concerned and may even cause it to be rejected. He states this in his capacity of Area Director, not as a co-author of the JFK draft. Greg Lebovitz asked Charlie. Kaufman whether NAT-T capabilities would be added to the drafts. Charlie replied that there is a plan to add it. However, both drafts as now written meet the requirements of the NAT- T specifications. Upon conclusion of the SOI summary, the Chair presented a timeline and plan for bringing the selection of the next version of IKE to a close with a definitive decision being made at or before the November IETF meeting in Atlanta. Those timelines are shown below. Aug 30: closure on SOI features Sept 30: SOI ID completed Oct 1-25: discussion on list Nov 4: updated ID Nov 18-22: Atlanta IETF meeting After the timeline was presented, the Chair opened the floor for discussion. Open Microphone Session Clearly, the most pressing concern of those gathered in the IPsec WG meeting was the SOI debate. The open microphone session lasted about 45 minutes and was exclusively related to SOI. Although the points of each opinioned varied, the common thread was that this process of selecting the next version had gone on long enough and that the membership wanted a selection to be made. There were comments that suggested enough work had been done on the drafts and that once the authors incorporate the changes derived from member comments regarding desired features, it was time for the co-chairs to make a decision. The suggestion that there could in fact be 2 SOIs was rejected as being too confusing to the outside Internet community and that only one draft should be approved even if that meant some form of merge or cooperation between the two draft teams. Jeff Schiller, Security Area Director, reinforced the concept of closure by indicating that he would make a decision if the WG were unable to decide by itself. The Chair indicated that closure would happen according to the timeline and plan announced earlier in the meeting. There being no further discussion, the meeting was adjourned. From owner-ipsec@lists.tislabs.com Mon Jul 22 20:32:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6N3WTw19123; Mon, 22 Jul 2002 20:32:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA03799 Mon, 22 Jul 2002 22:48:50 -0400 (EDT) From: "Housley, Russ" To: Russell Dietz Cc: ipsec@lists.tislabs.com, wpolk@nist.gov Message-Id: <5.1.0.14.2.20020718004351.02ea4b60@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 18 Jul 2002 00:46:46 -0400 Subject: Re: SHA-256-128 Draft: Is this really required? Contradiction... In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russell: I was making similar observations to Tim Polk from NIST last night. I had put him on the spot, but he could not come up with a reason to pursue this draft at the time. He agreed to ask other people at NIST why this draft is needed. Hopefully, someone from NIST will report the outcome of those discussions on this list. Russ At 12:14 AM 7/17/2002 -0700, Russell Dietz wrote: >Hello Folks, > >In reviewing the latest SHA-256 draft, "The HMAC-SHA-256-128 Algorithm and >Its Use With IPsec", , June 2002, I >notice a contradiction and a point which I (and others) believe, eliminates >the need for the document to progress, even as an experimental. > >In the draft, the authors state that... > >"HMAC-SHA-1-96 [HMAC-SHA] (Madson, C. and R. Glenn, "The Use of >HMAC-SHA-1-96 within ESP and AH," RFC2404, November 1998.) provides >sufficient security at a lower computational cost [then this SHA-2 draft]". > >...the draft then states... > >"The goal of HMAC-SHA-256-128 is to ensure that the packet is authentic and >cannot be modified in transit." > >...this is the 'goal' of HMAC-SHA-1-96 as it stands today. > >In addition, while the new SHA-256 algorithm is definitely useful in other >contexts, in fact there is no evidence that DRAFT-SHA-256 provides any >meaningful additional cryptographic security over the HMAC-SHA-1-96 >algorithm defined in RFC2404 and already in widespread use for packet >authentication in IPSec. For all we know, quite the contrary may be true, >as SHA-256 is a new transform and thus has seen considerably less public >review so far than SHA1 has already received. In any case, it is extremely >unlikely that HMAC-SHA1 will be the weak point in any system using IPSec. >Hence, it is not clear that trying to improve its security makes any sense, >given the costs and instability associated with such a change. > >Given this and the fact that SHA-256 is has no known cryptographic benefit >to implementing this proposed standard, there is no reason, even on an >experimental basis, for the IPSec WG to progress this document. > >Regards, > >Russell Dietz >Hifn, Inc. >750 University Ave >Los Gatos, CA, USA 95032-7695 >Tel: +1 408 399-3623 >pgp-fingerprint: CEE3 58B0 DD09 4EA5 7266 BF1E B5F6 4D1A 4AD1 65B4 From owner-ipsec@lists.tislabs.com Tue Jul 23 07:00:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6NE0Hw15493; Tue, 23 Jul 2002 07:00:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04739 Tue, 23 Jul 2002 09:10:15 -0400 (EDT) Message-ID: <008801c23250$de6c7ee0$0b00a8c0@BGABAYT20> From: "Benzy Gabay" To: Subject: padding in quick mode Date: Tue, 23 Jul 2002 15:57:22 +0200 Organization: Maya Software Technologies Ltd. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0085_01C23261.A1EC2720" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0085_01C23261.A1EC2720 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit Clear DayHi, Does anyone knows what should be the padding in quick mode packets while using DES , 3DES, AES ? Which type of modulo should I use (8 , 16, etc') Thanks ============================== Benzy Gabay R&D, IPSec team Maya Software Technologies Ltd. formerly Everbee Wireless Ltd. 6 Galgalei Haplada, POBox 12899 Herzliya 46733 Israel Tel +972-9-9560135 Fax +972-9-9559654 http://www.maya-st.com ------=_NextPart_000_0085_01C23261.A1EC2720 Content-Type: text/x-vcard; name="Benzy Gabay.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Benzy Gabay.vcf" BEGIN:VCARD VERSION:2.1 N:Gabay;Ben;Zion;Mr. FN:Benzy Gabay NICKNAME:Blabber ORG:Maya Software Technologies;R&D, IPSec TITLE:Senior software developer TEL;WORK;VOICE:+972-9-956-0135 TEL;CELL;VOICE:+972-55-559248 TEL;WORK;FAX:+972-9-955-9654 ADR;WORK:;+972-9-956-0135;6 Galgalei Haplada, POB = 12899;Herzelia;;46733;Israel LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:+972-9-956-0135=3D0D=3D0A6 = Galgalei Haplada, POB 12899=3D0D=3D0AHerzelia 46733=3D0D=3D =3D0AIsrael ADR;HOME:;;;Tel-Aviv;;64511;Israel LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:Tel-Aviv 64511=3D0D=3D0AIsrael X-WAB-GENDER:2 URL;WORK:http://www.maya-st.com BDAY:19710119 EMAIL;PREF;INTERNET:bgabay@maya-st.com EMAIL;INTERNET:benzyg@hotmail.com REV:20020723T135722Z END:VCARD ------=_NextPart_000_0085_01C23261.A1EC2720-- From owner-ipsec@lists.tislabs.com Tue Jul 23 07:00:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6NE0mw15514; Tue, 23 Jul 2002 07:00:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04733 Tue, 23 Jul 2002 09:09:13 -0400 (EDT) Date: Mon, 22 Jul 2002 18:13:55 -0400 Subject: Re: [saag] RE: No need for SHA-2 Packet Authentication - Open Let ter to the WG a nd Area Directors Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: IPSec Working Group , SAAG To: "Hallam-Baker, Phillip" From: RJ Atkinson In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869B3A@vhqpostal.verisign.com> Message-Id: <4FBA2A6A-9DC0-11D6-80FC-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Monday, July 22, 2002, at 01:39 , Hallam-Baker, Phillip wrote: > Given that the only party for whom SHA-256 use is postulated as being > mandated is the US federal government, has anyone from the US federal > govt. > actually stated that they intend to make SHA-256 a requirement over > SHA-1? Yes. I've heard from USG folks that NIST will be making SHA-256 a FIPS requirement (in at least some situations). I don't know whether or claim that such a decision would necessarily mean deprecating SHA-1. My own assumption is that more than one hash could co-exist, each with its own uses. > My understanding is that the new SHA hashes are supplemental to SHA-1 > and > that the accreditation for SHA-1 is unaffected (at least for the > moment).Certainly one would hope to see DSA updated before SHA-1 is > withdrawn! Requiring FOO in some applications would not necessarily imply deprecating BAR. I think you are coupling things together that are not necessarily coupled in the quoted text above. But, as I noted originally, USG customers might prefer SHA-256 over SHA-1-bis regardless of what the IETF says is an IETF standard. Ran rja@extremenetworks.com From owner-ipsec@lists.tislabs.com Tue Jul 23 08:21:35 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6NFLYw18115; Tue, 23 Jul 2002 08:21:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05017 Tue, 23 Jul 2002 10:32:47 -0400 (EDT) Message-Id: <200207231435.KAA14042@ietf.org> To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: The IESG SUBJECT: Last Call: More MODP Diffie-Hellman groups for IKE to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 23 Jul 2002 10:35:45 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has received a request from the IP Security Protocol Working Group to consider More MODP Diffie-Hellman groups for IKE as a Proposed Standard. 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 August 6, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-groups-04.txt From owner-ipsec@lists.tislabs.com Tue Jul 23 08:21:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6NFLrw18134; Tue, 23 Jul 2002 08:21:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05047 Tue, 23 Jul 2002 10:36:49 -0400 (EDT) Message-Id: <200207231448.AFR16384@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 23 Jul 2002 07:37:18 -0700 To: "Benzy Gabay" , From: Scott Fluhrer Subject: Re: padding in quick mode In-Reply-To: <008801c23250$de6c7ee0$0b00a8c0@BGABAYT20> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:57 AM 7/23/02 , Benzy Gabay wrote: >Clear DayHi, > >Does anyone knows what should be the padding in quick mode packets while >using DES , 3DES, AES ? If, by quick mode packets, you mean the IKE packets that make up a quick mode exchange, then the padding method is: All padding bytes, except for the last one, contain 0x00. The last byte of the padding contains the number of the padding bytes used, excluding the last one. Note that this means there will always be padding. Or, in other words, [00 00 .. 00 NN], where NN is one less than the total number of bytes of padding. You can have, at most, 1 block of padding. See RFC2409 for more details. If you mean the IPSec packets, then the padding method is: The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, ... Or, in other words, [01 02 03 .. NN], where NN is the total number of bytes of padding. If desired, you can have more than 1 block of padding. See RFC2406 for more details. >Which type of modulo should I use (8 , 16, etc') If you mean block size, then DES, 3DES has 8 byte blocks, and AES has 16 byte blocks. -- scott From owner-ipsec@lists.tislabs.com Tue Jul 23 09:05:43 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6NG5gw20596; Tue, 23 Jul 2002 09:05:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05192 Tue, 23 Jul 2002 11:18:21 -0400 (EDT) Message-Id: <200207231455.KAA15422@ietf.org> To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: The IESG SUBJECT: Last Call: The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 23 Jul 2002 10:55:29 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has received a request from the IP Security Protocol Working Group to consider The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec as a Proposed Standard. 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 August 6, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt From owner-ipsec@lists.tislabs.com Tue Jul 23 10:10:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6NHA4w25660; Tue, 23 Jul 2002 10:10:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05427 Tue, 23 Jul 2002 12:22:59 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: Vendor Extensions To: ipsec@lists.tislabs.com Cc: Steve Bellovin , jis@mit.edu X-Mailer: Lotus Notes Build V60_06142002 June 14, 2002 Message-ID: Date: Tue, 23 Jul 2002 11:44:39 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_M14_07142002 Release Candidate|July 14, 2002) at 07/23/2002 11:47:42 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Steve Bellovin, Security Area Director, strongly commented that any drafts > that contained specific vendor extensions would cause the IESG to be > concerned and may even cause it to be rejected. He states this in his > capacity of Area Director, not as a co-author of the JFK draft. Could we get clarification of IESG policy on vendor extensions and also feedback from the working group on their usefulness? IKEv1 contains an optional field called "Vendor Extensions" that a compliant implementation is required to ignore if it does not understand it. This is intended to allow people to build implementations that can either run the standard protocol or can smoothly negotiate over to proprietary protocol if both ends support it. It does not contain any registry of values assigned to any specific vendors. I don't know whether anyone uses this field in IKEv1. We copied it in IKEv2 since is seemed at least potentially useful without introducing any threats to interoperability of compliant implementations. My questions are: 1) Is anyone using the field in IKEv1? 2) Does anyone (besides me) feel the field is useful enough to leave it in IKEv2? 3) Does anyone feel the field adds unjustified complexity to the protocol and hence should be removed? 4) Is there some IESG policy that we should be aware of that might override working group consensus on the utility of such a field. I don't feel strongly about the need for such a field. Assuming we leave in the capability of non-critical extensions so that implementations of future standard versions of IKE can interoperate with implementations of this version, vendors will be able to accomplish what they want (albeit by violating the specification and with some risk of future interoperability problems). I don't like rules that were made to be broken, but I'd be happy to do it if it were working group consensus and willing to do it if it were IESG mandate. --Charlie Kaufman (ckaufman@notesdev.ibm.com) From owner-ipsec@lists.tislabs.com Tue Jul 23 11:23:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6NINrw28715; Tue, 23 Jul 2002 11:23:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05579 Tue, 23 Jul 2002 13:38:33 -0400 (EDT) Date: 23 Jul 2002 13:38:16 -0400 Message-ID: <003201c2326f$ba90b6c0$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Charlie Kaufman'" , " 'list'" Cc: "'Steve Bellovin'" , " 'Jeff Schiller'" Subject: RE: Vendor Extensions MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We use the vendor id payload, as does pretty much every other vendor that I know of. Anyone who has implemented NAT traversal is using them, as it is required by the spec. Without the vendor id, the situation would be much worse, as there would be no means to smoothly transition to the IANA-assigned numbers when they are available. We also use it to recognize our own implemetations in the field and enable some proprietary extentions. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of > Charlie_Kaufman@notesdev.ibm.com > Sent: Tuesday, July 23, 2002 11:45 AM > To: ipsec@lists.tislabs.com > Cc: Steve Bellovin; jis@mit.edu > Subject: Vendor Extensions > > > > > > > > Steve Bellovin, Security Area Director, strongly commented that any > drafts > > that contained specific vendor extensions would cause the IESG to be > > concerned and may even cause it to be rejected. He states > this in his > > capacity of Area Director, not as a co-author of the JFK draft. > > Could we get clarification of IESG policy on vendor > extensions and also > feedback from the working group on their usefulness? IKEv1 contains > an optional field called "Vendor Extensions" that a compliant > implementation is > required to ignore if it does not understand it. This is > intended to allow > people to build implementations that can either run the > standard protocol > or > can smoothly negotiate over to proprietary protocol if both > ends support > it. > > It does not contain any registry of values assigned to any specific > vendors. > > I don't know whether anyone uses this field in IKEv1. We > copied it in IKEv2 > since is seemed at least potentially useful without > introducing any threats > to > interoperability of compliant implementations. > > My questions are: > > 1) Is anyone using the field in IKEv1? > > 2) Does anyone (besides me) feel the field is useful enough > to leave it > in IKEv2? > > 3) Does anyone feel the field adds unjustified complexity to the > protocol and hence should be removed? > > 4) Is there some IESG policy that we should be aware of that > might override > working group consensus on the utility of such a field. > > I don't feel strongly about the need for such a field. > Assuming we leave in > the capability of non-critical extensions so that > implementations of future > standard versions of IKE > can interoperate with implementations of this version, > vendors will be able > to accomplish what they want (albeit by violating the > specification and > with > some risk of future interoperability problems). I don't like > rules that > were > made to be broken, but I'd be happy to do it if it were working group > consensus and willing to do it if it were IESG mandate. > > --Charlie Kaufman > (ckaufman@notesdev.ibm.com) > From owner-ipsec@lists.tislabs.com Tue Jul 23 11:27:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6NIRPw28809; Tue, 23 Jul 2002 11:27:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05570 Tue, 23 Jul 2002 13:34:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Tue, 23 Jul 2002 10:47:30 -0700 To: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Vendor Extensions Cc: Steve Bellovin , jis@mit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:44 AM -0400 7/23/02, Charlie_Kaufman@notesdev.ibm.com wrote: > > Steve Bellovin, Security Area Director, strongly commented that any >drafts >> that contained specific vendor extensions would cause the IESG to be >> concerned and may even cause it to be rejected. He states this in his > > capacity of Area Director, not as a co-author of the JFK draft. > >Could we get clarification of IESG policy on vendor extensions and also >feedback from the working group on their usefulness? Did Steve say "vendor extensions" or "specific vendor extensions"? Clarification would be helpful here. >1) Is anyone using the field in IKEv1? If you do packet dumps while watching many IPsec systems interoperate, you will see that many (possibly most) vendors use them in IKEv1. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jul 23 11:29:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6NITOw28838; Tue, 23 Jul 2002 11:29:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05591 Tue, 23 Jul 2002 13:39:34 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40D1CB479@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" Cc: IPSec Working Group , SAAG Subject: RE: [saag] RE: No need for SHA-2 Packet Authentication - Open Let ter to the WG a nd Area Directors Date: Tue, 23 Jul 2002 10:54:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This discussion is futile. If USG want to make a requirement in this area it is up to the USG to make the request to the working group, in particular it is the responsibility of NIST which has the primary responsibility for liasing with standards organizations. Phill > -----Original Message----- > From: RJ Atkinson [mailto:rja@extremenetworks.com] > Sent: Monday, July 22, 2002 6:14 PM > To: Hallam-Baker, Phillip > Cc: IPSec Working Group; SAAG > Subject: Re: [saag] RE: No need for SHA-2 Packet Authentication - Open > Let ter to the WG a nd Area Directors > > > > On Monday, July 22, 2002, at 01:39 , Hallam-Baker, Phillip wrote: > > Given that the only party for whom SHA-256 use is > postulated as being > > mandated is the US federal government, has anyone from the > US federal > > govt. > > actually stated that they intend to make SHA-256 a requirement over > > SHA-1? > > Yes. I've heard from USG folks that NIST will be making > SHA-256 a FIPS > requirement (in at least some situations). I don't know whether or > claim that > such a decision would necessarily mean deprecating SHA-1. My own > assumption > is that more than one hash could co-exist, each with its own uses. > > > My understanding is that the new SHA hashes are > supplemental to SHA-1 > > and > > that the accreditation for SHA-1 is unaffected (at least for the > > moment).Certainly one would hope to see DSA updated before SHA-1 is > > withdrawn! > > Requiring FOO in some applications would not necessarily imply > deprecating BAR. > I think you are coupling things together that are not > necessarily coupled > in the quoted text above. > > But, as I noted originally, USG customers might prefer SHA-256 over > SHA-1-bis > regardless of what the IETF says is an IETF standard. > > Ran > rja@extremenetworks.com > From owner-ipsec@lists.tislabs.com Tue Jul 23 11:55:11 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6NItAw01525; Tue, 23 Jul 2002 11:55:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05718 Tue, 23 Jul 2002 14:10:50 -0400 (EDT) Date: Tue, 23 Jul 2002 11:24:23 -0700 (PDT) From: Jan Vilhuber To: cc: , Steve Bellovin , Subject: Re: Vendor Extensions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 23 Jul 2002 Charlie_Kaufman@notesdev.ibm.com wrote: > > > > > > Steve Bellovin, Security Area Director, strongly commented that any > drafts > > that contained specific vendor extensions would cause the IESG to be > > concerned and may even cause it to be rejected. He states this in his > > capacity of Area Director, not as a co-author of the JFK draft. > > Could we get clarification of IESG policy on vendor extensions and also > feedback from the working group on their usefulness? IKEv1 contains > an optional field called "Vendor Extensions" that a compliant > implementation is > required to ignore if it does not understand it. This is intended to allow > people to build implementations that can either run the standard protocol > or > can smoothly negotiate over to proprietary protocol if both ends support > it. > > It does not contain any registry of values assigned to any specific > vendors. > > I don't know whether anyone uses this field in IKEv1. We copied it in IKEv2 > since is seemed at least potentially useful without introducing any threats > to > interoperability of compliant implementations. > > My questions are: > > 1) Is anyone using the field in IKEv1? > Yes. Xauth and config mode for one (whether that's a good thing is debatable). We used it extensively to gather experience with keepalive mechanisms, and others have used it to gather experience with new ciphers. This is extensively used. > 2) Does anyone (besides me) feel the field is useful enough to leave it > in IKEv2? > Absolutely, yes. A protocol that doesn't have ways of extending it is a dead protocol (from the start). And if there's no way to gather experiences with new mechanisms, that's bad, too. Let's face it: people will experiment with different stuff. Getting things standardized in the IETF is a gory process. You don't want to just voice an opinion, you want to back it up with implementational and deployment experience to make your case. Without some vendor extension (or private extension, if you want to make it sound less controversial), people will just use existing payload numbers from the reserved space, which will REALLY break interoperability big-time. > 3) Does anyone feel the field adds unjustified complexity to the > protocol and hence should be removed? > No, although I have some thoughts on an alternate vendor-id mechanism, similar to the one radius has, that is in my opinion a little clearer semantically (but no more or less powerful). jan > 4) Is there some IESG policy that we should be aware of that might override > working group consensus on the utility of such a field. > > I don't feel strongly about the need for such a field. Assuming we leave in > the capability of non-critical extensions so that implementations of future > standard versions of IKE > can interoperate with implementations of this version, vendors will be able > to accomplish what they want (albeit by violating the specification and > with > some risk of future interoperability problems). I don't like rules that > were > made to be broken, but I'd be happy to do it if it were working group > consensus and willing to do it if it were IESG mandate. > > --Charlie Kaufman > (ckaufman@notesdev.ibm.com) > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Tue Jul 23 12:28:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6NJSBw02964; Tue, 23 Jul 2002 12:28:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05846 Tue, 23 Jul 2002 14:40:07 -0400 (EDT) Date: Tue, 23 Jul 2002 14:51:11 -0400 Subject: Re: [saag] RE: No need for SHA-2 Packet Authentication - Open Let ter to the WG a nd Area Directors Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: IPSec Working Group , SAAG To: "Hallam-Baker, Phillip" From: RJ Atkinson In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40D1CB479@vhqpostal.verisign.com> Message-Id: <27E6A30F-9E6D-11D6-97EC-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tuesday, July 23, 2002, at 01:54 , Hallam-Baker, Phillip wrote: > This discussion is futile. Possibly. > If USG want to make a requirement in this area it is up to the USG to > make > the request to the working group, in particular it is the > responsibility of > NIST which has the primary responsibility for liasing with standards > organizations. IETF does not recognise organisational representation, only individual representation. Participation in IETF is entirely voluntary for everyone. Any organisation can create internal standards for itself without IETF if they choose to do so. It is preferable that IETF be open enough and productive enough that folks would choose to bring proposals to IETF, but it certainly is not a requirement that anyone bring their standards work to IETF. It would be quite reasonable for interested folks to publish an informational or experimental RFC should the IPsec WG choose not to standardise a particular transform of interest to some community of interested folks -- to circle back to the point I've been trying to make for the past several days. Ran rja@extremenetworks.com From owner-ipsec@lists.tislabs.com Tue Jul 23 13:01:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6NK1ew04975; Tue, 23 Jul 2002 13:01:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05937 Tue, 23 Jul 2002 15:17:35 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40D1CB4C2@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: RJ Atkinson , "Hallam-Baker, Phillip" Cc: IPSec Working Group , SAAG Subject: RE: [saag] RE: No need for SHA-2 Packet Authentication - Open Let ter to the WG a nd Area Directors Date: Tue, 23 Jul 2002 12:32:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Once again: 1. DoD may not be bound by NIST rules but AES/SHA-256 is a NIST standard. Ergo if DoD takes it into its head to demand a NIST standard it likely does so because it regards NISt to be authoritative. 2. IETF rules may state that working group members speak for themselves. However that does not mean that a working group should take a work item on the assertion by J. Random Bozo that the USG demands it when we can ask the organization that USG appointed to make such assertions. 3. USG policy (including DoD) is currently to use COTS wherever possible. If USG departments are having to specify non-standard extensions to COTS software and NIST has failed to even inform the standards body that they have a requirement then NIST is not doing its job. I pretty much dislike the way that this discussion takes place in which one party assumes the authority of USG when USG has said nothing on the matter at all, either directly or indirectly. If the obvious route of asking Tim Polk or Bill Burr what the situation is is considered objectionable something is wrong. Phill From owner-ipsec@lists.tislabs.com Tue Jul 23 14:03:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6NL3fw09207; Tue, 23 Jul 2002 14:03:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06049 Tue, 23 Jul 2002 16:14:59 -0400 (EDT) Date: Tue, 23 Jul 2002 16:12:37 -0400 Subject: Re: [saag] RE: No need for SHA-2 Packet Authentication - Open Let ter to the WG a nd Area Directors Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: IPSec Working Group , SAAG To: "Hallam-Baker, Phillip" From: RJ Atkinson In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40D1CB4C2@vhqpostal.verisign.com> Message-Id: <88807402-9E78-11D6-97EC-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tuesday, July 23, 2002, at 03:32 , Hallam-Baker, Phillip wrote: > 1. DoD may not be bound by NIST rules but AES/SHA-256 is a NIST > standard. > Ergo if DoD takes it into its head to demand a NIST standard it > likely does so because it regards NISt to be authoritative. Disagree. Any operator/user that requests something from its vendors or from IETF likely does so because they think it is a good idea for their situation. Clearly your mileage varies from mine on this aspect. > 2. IETF rules may state that working group members speak for themselves. > However that does not mean that a working group should take a work > item on the assertion by J. Random Bozo that the USG demands it when we > can > ask the organization that USG appointed to make such assertions. Being on the SAAG list only, I haven't seen anyone suggest that any WG *standardise* anything. No doubt I've missed some context here by not being on the IPsec WG list. RECAP: This thread was started on the SAAG list by someone suggesting *not standardising* something and further apparently (since clarified) trying to prevent that something from even being published. I responded saying that preventing publication was nearly always a bad idea and that market requirements tend to have a life of their own (largely independent of what standards bodies might proclaim from on high) -- with an example scenario. It appears that some folks (e.g. Phillip) misconstrued providing that example as a request for standardisation, which is unfortunate. SUMMARY: To be clear, and repetitive with my earlier note, I don't care one iota what does or doesn't get standardised for algorithms in IPsec. I'm totally indifferent to that dimension. I care a lot that people are allowed to publish reasonable documents as non-standard RFCs if IETF chooses not to standardise them. I also noted that RFC Editor has the power to make that decision to publish Informational or Experimental RFCs. > 3. USG policy (including DoD) is currently to use COTS wherever > possible. > If USG departments are having to specify non-standard extensions to > COTS software and NIST has failed to even inform the standards body that > they have a requirement then NIST is not doing its job. Or IETF hasn't done its job to listen to operators/users to get the right feature set into the standards. If the latter, no doubt that will be the first time that has happened in IETF in recent years. Any number of other things are also possibly happening in this situation. Since IETF does NOT have organisational members and IAB has no liaison established with NIST, it isn't obvious to me how "NIST" can officially communicate anything with IETF. So I don't see how criticising NIST (or folks who happen to work there) is either appropriate or helpful. I'll be putting future notes from Phillip on this thread into /dev/null, so he can have the last word and the SAAG list can resume its normal happy silence. :-) Cheers, Ran rja@extremenetworks.com From owner-ipsec@lists.tislabs.com Wed Jul 24 06:47:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6ODluw07285; Wed, 24 Jul 2002 06:47:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07778 Wed, 24 Jul 2002 09:00:22 -0400 (EDT) Message-Id: <200207241208.IAA02182@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Wed, 24 Jul 2002 08:08:15 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Using AES Counter Mode With IPsec ESP Author(s) : R. Housley Filename : draft-ietf-ipsec-ciph-aes-ctr-00.txt Pages : 12 Date : 23-Jul-02 This document describes the use of AES Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload confidentiality mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-ipsec-ciph-aes-ctr-00.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-ietf-ipsec-ciph-aes-ctr-00.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020723145528.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-ctr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020723145528.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Jul 24 10:58:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6OHwZw19713; Wed, 24 Jul 2002 10:58:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08259 Wed, 24 Jul 2002 12:42:06 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200207241208.IAA02182@ietf.org> References: <200207241208.IAA02182@ietf.org> Date: Wed, 24 Jul 2002 09:56:07 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Two AES encryption modes? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:08 AM -0400 7/24/02, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the IP Security Protocol Working Group >of the IETF. > > Title : Using AES Counter Mode With IPsec ESP > Author(s) : R. Housley > Filename : draft-ietf-ipsec-ciph-aes-ctr-00.txt > Pages : 12 > Date : 23-Jul-02 There are technical reasons why this WG might or might not want to have more than one AES encryption modes. I would like to bring up a non-technical reason why we wouldn't: interoperability. System A is marketed as doing AES. System B is marketed as doing AES. They won't interoperate unless they both do the same modes. Yes, we could demand that the users understand that "AES CBC" and "AES Counter" are different, and that when they hear "AES" they need to ask "which of the two AES modes do you mean"? That is a wholly unrealistic demand. As I understand it, the two modes have very different security properties, meaning that it would be unrealistic to require that any system that incorporated one had to incorporate both. Even if we went that route, it is unlikely that we could enforce (or even explain) why all proposals that included one should also include the other. Without a really, really strong security justification, the loss of understandable interoperability that comes with two different-but-similarly-named algorithms is not worth it. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jul 24 12:44:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6OJinw26742; Wed, 24 Jul 2002 12:44:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08411 Wed, 24 Jul 2002 14:43:32 -0400 (EDT) Content-return: allowed Date: Wed, 24 Jul 2002 14:57:21 -0400 From: "Waterhouse, Richard" Subject: RE: Two AES encryption modes? To: ipsec@lists.tislabs.com, Paul Hoffman / VPNC Message-id: <2575327B6755D211A0E100805F9FF9540DD82649@ndhmex02.ndhm.gsc.gte.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I would like to bring up a > non-technical reason why we wouldn't: interoperability. > >>> In my humble opinion it should be a requiremnent on Son of IKE that it be able to negotiate Mode. From owner-ipsec@lists.tislabs.com Wed Jul 24 13:26:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6OKQew28406; Wed, 24 Jul 2002 13:26:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08534 Wed, 24 Jul 2002 15:38:14 -0400 (EDT) Message-Id: <200207240131.g6O1UaKs008821@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Vendor Extensions In-reply-to: Your message of "Tue, 23 Jul 2002 11:44:39 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 23 Jul 2002 21:30:35 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charlie" == Charlie Kaufman writes: >> Steve Bellovin, Security Area Director, strongly commented that any Charlie> drafts >> that contained specific vendor extensions would cause the IESG to be >> concerned and may even cause it to be rejected. He states this in his >> capacity of Area Director, not as a co-author of the JFK draft. Charlie> Could we get clarification of IESG policy on vendor extensions and also Charlie> feedback from the working group on their usefulness? IKEv1 contains Charlie> an optional field called "Vendor Extensions" that a compliant Charlie> implementation is No, that's not correct. Payload #13 is Vendor ID. The Vendor ID qualifies the private use space. Charlie, Tero Kivinen and I suggested the current text back in early '97. Charlie> It does not contain any registry of values assigned to any specific Charlie> vendors. Nor need it, since the suggested values for the Vendor ID payload are MD5-hashes of version strings. They can in fact be anything, but since there are at least 96 bits of them, collision is unlikely. What you *CAN NOT* do is use more than one extension space. In general, this was suggested as a mechanism for vendors who had buggy products in the field to recognize the buggy product and enable "workaround code". This eliminates the problem where you can't fix the bug to become interoperable because doing so would screw the people who actually give you money. There was some feeling at the time that having an official list of implementations such that we could have such a registry would not be desirable to some - in particular to people in various research groups who might want to innovate without annoucing their existence. Charlie> I don't know whether anyone uses this field in IKEv1. We copied it in IKEv2 Charlie> since is seemed at least potentially useful without introducing any threats Charlie> to Charlie> interoperability of compliant implementations. Charlie> My questions are: Charlie> 1) Is anyone using the field in IKEv1? In practice it has been used extensively for testing of new features. In part this is due to the lack of a critical bit in the payloads. Charlie> 2) Does anyone (besides me) feel the field is useful enough to leave it Charlie> in IKEv2? Yes. We must have a way to innovate. This means either PPP-style vendor extension fields (probably stealing the PPP vendor space), or maintaining VID. I'm indifferent to which is done, but we need a way to qualify that when MCR's code says "magic payload 40045" it means something different than when Charlie's code says "magic payload 40045" Charlie> 4) Is there some IESG policy that we should be aware of that might override Charlie> working group consensus on the utility of such a field. ] Internet Security. Have encryption, will travel |1 Fish/2 Fish [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F [ ]mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [ ] At the far end of some dark fiber - wait that's dirt! |for everyone [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPT4DOYqHRg3pndX9AQFKnQQAjijvwsvLswdXRPn/bOgHVSXJldF0R0/q QJuNHVUJN8DWzToT4sb5eS7wFRUBB/kTctui3d8kqwYY8+O/FWsjhsZA58n/MI4q yDAooZz8WL1IOURstpEjkX2EvKoLgyyJyP6Z4onWalJyYMvxDjCm0baJ68tWPaC6 KwbjG6KNeLg= =SXFH -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Jul 24 14:00:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6OL0Iw28947; Wed, 24 Jul 2002 14:00:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08602 Wed, 24 Jul 2002 16:04:31 -0400 (EDT) From: "Housley, Russ" To: RJ Atkinson Cc: ipsec@lists.tislabs.com, saag@lists.tislabs.com Message-Id: <5.1.0.14.2.20020724140348.0212dd78@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 24 Jul 2002 14:13:03 -0400 Subject: Re: No need for SHA-2 Packet Authentication - Open Letter to the WG and Area Directors In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ran: We are not trying to stifle innovation, nor are we trying to suppress SHA-256. SHA-256 has an important place, but this is not it. SHA-256 was developed to support applications that need a longer output value. SHA-1 generates a 160-bit output value. In our view, SHA-1 should be used unless a longer output value is needed. In the proposal, the hash value is truncated to 128 bits, so there is no benefit from the more complicated hash function. I would support the use of SHA-256 if the final output were longer than 160 bits. Russ At 12:41 AM 7/18/2002 -0400, RJ Atkinson wrote: >On Wednesday, July 17, 2002, at 08:35 PM, Russell Dietz wrote: > >>To the IPSec Working Group and Security Area Directors: >> >>The purpose of this letter is to comment on an existing Internet Draft, >>draft-ietf-ipsec-ciph-sha-256-00.txt, dated Nov 2001, co-authored by S. >>Frankel and S. Kelley. This draft, hereafter referred to as DRAFT-SHA-256 >>for brevity, defines how to use the new SHA-256 algorithm from NIST (FIPS >>180-2) for packet authentication within the ESP and AH mechanisms of IPSec. > >Russell, > >I'm pretty indifferent to the topic of what ought or ought not be >mandatory-to-implement or maybe even standards-track RFC versus >informational RFC. I am remarkably indifferent to any of the >mathematical parts of your note or Uri's followup. > >I do feel pretty strongly that the above referenced draft ought to be >permitted to be published, at least as an Informational RFC, so that >those folks who choose to implement/deploy it can do so in an >interoperable manner. > >Trying to prevent people from publishing open specifications for >entirely optional-to-implement technology is NOT consistent with >the Internet tradition. I would hope that the RFC Editor would >apply their own good judgement to an individual request to publish >such a document as an Informational RFC if the situation should arise. > >Yours, > >Ran >rja@extremenetworks.com > > >_______________________________________________ >saag mailing list >saag@mit.edu >http://jis.mit.edu/mailman/listinfo/saag From owner-ipsec@lists.tislabs.com Wed Jul 24 14:30:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6OLUXw29584; Wed, 24 Jul 2002 14:30:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08555 Wed, 24 Jul 2002 15:46:18 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15679.1866.382899.842194@pkoning.dev.equallogic.com> Date: Wed, 24 Jul 2002 16:00:10 -0400 From: Paul Koning To: paul.hoffman@vpnc.org Cc: ipsec@lists.tislabs.com Subject: Re: Two AES encryption modes? References: <200207241208.IAA02182@ietf.org> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Hoffman" == VPNC writes: Hoffman> At 8:08 AM -0400 7/24/02, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the IP Security >> Protocol Working Group of the IETF. >> >> Title : Using AES Counter Mode With IPsec ESP Author(s) : >> R. Housley Filename : draft-ietf-ipsec-ciph-aes-ctr-00.txt Pages : >> 12 Date : 23-Jul-02 Hoffman> There are technical reasons why this WG might or might not Hoffman> want to have more than one AES encryption modes. I would Hoffman> like to bring up a non-technical reason why we wouldn't: Hoffman> interoperability. Hoffman> System A is marketed as doing AES. System B is marketed as Hoffman> doing AES. They won't interoperate unless they both do the Hoffman> same modes. Yes, we could demand that the users understand Hoffman> that "AES CBC" and "AES Counter" are different, and that Hoffman> when they hear "AES" they need to ask "which of the two AES Hoffman> modes do you mean"? That is a wholly unrealistic demand. DES and 3DES also have similar names. It does not make a whole lot of sense to object to a cipher system proposal on the grounds that its name sounds like another name. Hoffman> As I understand it, the two modes have very different Hoffman> security properties, meaning that it would be unrealistic to Hoffman> require that any system that incorporated one had to Hoffman> incorporate both. Even if we went that route, it is unlikely Hoffman> that we could enforce (or even explain) why all proposals Hoffman> that included one should also include the other. Why would we want to? The two systems indeed have different properties. In particular, they have different performance properties, which is one significant reason for proposing counter mode. What proposals a system makes is entirely its own choice. I would not require an implementation to support both modes, much less propose both -- no more than I would require an implementation to support, or propose, DES and 3DES both. Hoffman> Without a really, really strong security justification, the Hoffman> loss of understandable interoperability that comes with two Hoffman> different-but-similarly-named algorithms is not worth it. I disagree strongly. I don't think judging cipher algorithms on their name is a sensible policy. paul From owner-ipsec@lists.tislabs.com Wed Jul 24 14:30:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6OLUXw29585; Wed, 24 Jul 2002 14:30:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08661 Wed, 24 Jul 2002 16:47:46 -0400 (EDT) Date: Wed, 24 Jul 2002 23:01:19 +0200 (CEST) From: Bart Preneel To: Russell Dietz cc: IPSec Working Group , SAAG Subject: Re: No need for SHA-2 Packet Authentication - Open Letter to the WG and Area Directors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Two small corrections below. 1) Some attacks on MAC algorithms DO depend on the length after truncation, but not as claimed: there is an attack that becomes more efficient (for a given hash function) if this length increases! 2) Moreover, there is indeed a birthday attack on HMAC (the proof by Bellare et al. stops at the birtday bound). It is not a realistic attack, but a key search for a 128-bit key is not realistic either. This does not change the conclusion, but I believe that using incorrect arguments to support the correct conclusion is not really helpful. Bart Preneel ------------------------------------------------------------------------------- Katholieke Universiteit Leuven tel. +32 16 32 11 48 Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 69 Kasteelpark Arenberg 10, B-3001 Leuven-Heverlee, BELGIUM bart.preneel@esat.kuleuven.ac.be http://www.esat.kuleuven.ac.be/~preneel ------------------------------------------------------------------------------- On Wed, 17 Jul 2002, Russell Dietz wrote: > First of all, the block size of SHA-256 (512 bits) is identical to that of > SHA-1, so the first assertion in the quote above is simply false, although > frankly it would have no relevance if true. Second, there is no known > reason why DRAFT-SHA-256 would in fact allow less frequent rekeying, using > either 32-bit or 64-bit sequence numbers. Finally, and most importantly, > while it is true that SHA-256 can output 256 bits, in the current draft the > HMAC-SHA-256 output is in fact truncated to 96 bits, as is HMAC-SHA-1 in > RFC2406. For the HMAC-SHA-1-96 and DRAFT-SHA-256 algorithms, there is every > reason to believe that the limiting factor in security is the number of bits > of hash included in the packet, not the length before truncation. The best > attacks known on HMAC-SHA-1-96 and DRAFT-SHA-256 depend only on the length > after truncation, not the length before truncation. Hence, the HMAC-SHA-1-96 > and DRAFT-SHA-256 have equivalent security against known attacks, and there > seems to be little reason to prefer either one over the other, from a > cryptographic perspective. For any given number of output bits, up to the > SHA-1 limit of 160 bits, this would continue to be the case. If it was > desired to have a MAC value longer than 160 bits, then the use of SHA-256 > would likely be appropriate, but there is no apparent need for such a MAC > tag length, according to current knowledge. > > [...] > > However, while Figure 1 in FIPS 180-2 is correct for digital signatures, it > has no direct relevance to the issue of packet authentication in ESP and AH > as addressed in DRAFT-SHA-256. Packet authentication has a completely > different attack model. In particular, there is no known feasible "birthday > attack" problem in the packet authentication context, as has been shown by > Krawczyk and others (e.g., "Keying Hash Functions for Message > Authentication" by Bellare, Canetti, and Krawczyk, Crypto '96). > [...] The best known attacks on any iterated MAC algorithm with a k-bit key, an n-bit internal memory, and an m-bit result (some other conditions apply): guess the MAC value: probability of success 2**-m find the key by exhaustive search: 2**k birthday attack [1]: 2**(n/2) text-MAC pairs and 2**(n-m+1) chosen texts The best known attacks on HMAC-SHA-1-96: guess the MAC value: probability of success 2**-96 find a 160-bit key by exhaustive search: 2**160 birthday attack [1]: 2**80 known text-MAC pairs and 2**65 chosen texts It is safe to say that these attacks are infeasible or not relevant for at least 15 years, so there is no need to upgrade. The best known attacks on DRAFT-SHA-256 with an m-bit result: guess the MAC: probability of success 2**-m find a 256-bit key by exhaustive search: 2**256 birthday attack [1]: 2**128 text-MAC pairs and 2**(256-m+1) chosen texts I believe that the following holds: * It is likely that better attacks than the above attack exist for DRAFT-SHA-256. Note that the complexities are huge. * It is likely that DRAFT-SHA-256 is more secure than HMAC-SHA-1-96. * Both seem to offer a more than adequate security level (even if I would like to see more research on MAC-like properties of SHA-type hash functions). I agree that there is no cryptographic reason to upgrade. [1] B. Preneel, P.C. van Oorschot, "On the security of iterated Message Authentication Codes," IEEE Transactions on Information Theory, Vol. 45, No. 1, January 1999, pp. 188-199. ------------------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Wed Jul 24 14:30:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6OLUew29605; Wed, 24 Jul 2002 14:30:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08563 Wed, 24 Jul 2002 15:47:20 -0400 (EDT) Message-Id: <4.3.2.7.1.20020724125917.00e45bb0@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Jul 2002 13:00:19 -0700 To: Paul Hoffman / VPNC , ipsec@lists.tislabs.com From: Ramana Yarlagadda Subject: Re: Two AES encryption modes? In-Reply-To: References: <200207241208.IAA02182@ietf.org> <200207241208.IAA02182@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all What about the combined modes that AES support? -thanks -ramana From owner-ipsec@lists.tislabs.com Wed Jul 24 16:28:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6ONSow04008; Wed, 24 Jul 2002 16:28:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08922 Wed, 24 Jul 2002 18:39:18 -0400 (EDT) Message-ID: <3677E033A5F3D211AC4000A0C96B53EB0B684B61@fmsmsx94.fm.intel.com> From: "Herbert, Howard C" To: paul.hoffman@vpnc.org Cc: ipsec@lists.tislabs.com Subject: RE: Two AES encryption modes? Date: Wed, 24 Jul 2002 15:52:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with Paul Koning. Judging cipher algorithms on their names is NOT a sensible policy. AES in CTR mode and other "parallelizable" AES-based algorithms (e.g., PMAC) are the only viable algorithms that will support IPsec on 10 Gbit Ethernet systems like the ones that I am developing. Howard -----Original Message----- From: Paul Koning [mailto:pkoning@equallogic.com] Sent: Wednesday, July 24, 2002 1:00 PM To: paul.hoffman@vpnc.org Cc: ipsec@lists.tislabs.com Subject: Re: Two AES encryption modes? >>>>> "Hoffman" == VPNC writes: Hoffman> At 8:08 AM -0400 7/24/02, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the IP Security >> Protocol Working Group of the IETF. >> >> Title : Using AES Counter Mode With IPsec ESP Author(s) : >> R. Housley Filename : draft-ietf-ipsec-ciph-aes-ctr-00.txt Pages : >> 12 Date : 23-Jul-02 Hoffman> There are technical reasons why this WG might or might not Hoffman> want to have more than one AES encryption modes. I would Hoffman> like to bring up a non-technical reason why we wouldn't: Hoffman> interoperability. Hoffman> System A is marketed as doing AES. System B is marketed as Hoffman> doing AES. They won't interoperate unless they both do the Hoffman> same modes. Yes, we could demand that the users understand Hoffman> that "AES CBC" and "AES Counter" are different, and that Hoffman> when they hear "AES" they need to ask "which of the two AES Hoffman> modes do you mean"? That is a wholly unrealistic demand. DES and 3DES also have similar names. It does not make a whole lot of sense to object to a cipher system proposal on the grounds that its name sounds like another name. Hoffman> As I understand it, the two modes have very different Hoffman> security properties, meaning that it would be unrealistic to Hoffman> require that any system that incorporated one had to Hoffman> incorporate both. Even if we went that route, it is unlikely Hoffman> that we could enforce (or even explain) why all proposals Hoffman> that included one should also include the other. Why would we want to? The two systems indeed have different properties. In particular, they have different performance properties, which is one significant reason for proposing counter mode. What proposals a system makes is entirely its own choice. I would not require an implementation to support both modes, much less propose both -- no more than I would require an implementation to support, or propose, DES and 3DES both. Hoffman> Without a really, really strong security justification, the Hoffman> loss of understandable interoperability that comes with two Hoffman> different-but-similarly-named algorithms is not worth it. I disagree strongly. I don't think judging cipher algorithms on their name is a sensible policy. paul From owner-ipsec@lists.tislabs.com Wed Jul 24 19:13:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6P2Dtw06325; Wed, 24 Jul 2002 19:13:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA09165 Wed, 24 Jul 2002 21:28:49 -0400 (EDT) From: "David A. Mcgrew" To: Cc: Subject: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Wed, 24 Jul 2002 18:42:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ, I have several comments on draft-ietf-ipsec-ciph-aes-ctr-00.txt. It's clearly written and I value the effort that you've made to get the job done and establish some sort of compromise. However, there are two points on which the draft can be improved: packet expansion and strength against precomputation attacks. In the following, I lay out some arguments in favor of an implicit (rather than an explicit) IV, discuss interoperability with other counter mode versions, and mention some other points. First, a correction to the Security Section. In the last paragraph of Section 6, the draft is right to state that no more than 2^64 blocks should be encrypted with any fixed key. But the draft implies that this limitation can be avoided if implementations "make use of the longer AES key sizes." This is not right, the 2^64 limit applies to all key sizes. It does not apply to larger block sizes; however, the AES spec doesn't include the larger RIJDNAEL block sizes. In the same vein, the sentence "Additionally, AES with a 128-bit key is vulnerable to the birthday attack after 2^64 blocks" should read "Additionally, AES is vulnerable...". On the subject of packet expansion, the draft requires the use of an explicit IV that is eight bytes long and states that this overhead is acceptable. I disagree. Counter mode has the opportunity to provide zero expansion, and at Cisco we've regarded this property as important. The consumption of eight bytes per packet can have a significant impact on bandwidth, especially for protocols with short packets like voice over IP (RFC 1889). For example, RTP with the G.729 codec (as is commonly used) carries only twenty bytes of data per packet. This protocol is often used with link-layer header compression over WAN links (e.g. RFC2508); these compression methods are quite efficient, making the bandwidth degradation due to uncompressible fields (like the explicit IV) pronounced. I think that the zero-expansion property is important enough that I want to comment on the points that the rationale presents in favor of an explicit IV: Point 4. "The assignment of the per-packet counter block value needs to be inside the assurance boundary. Some implementations assign the sequence number inside the assurance boundary, but others do not." What implementations maintain the ESP sequence number outside of the security perimeter? Cisco does not do this, nor do any of the several of crypto hardware suppliers that we use. Counter mode ESP would be far simpler and more bandwidth efficient if the ESP sequence number were used as the per-packet counter value. In addition, other cryptographic mechanisms that require a nonce can use the sequence number for that purpose, if we are allowed to assume that the sequence number is actually unique. These mechanisms include ciphers like SEAL and Wegman-Carter based MACs like MMH. It's worth noting that we've implemented SEAL encryption using ESP, as described in the Stream Cipher ESP; this draft is now expired, but went through three revisions without this point about the sequence number and assurance boundary being raised. (The old draft is online at www.mindspring.com/~dmcgrew/draft-mcgrew-ipsec-scesp-02.txt if you're interested, and we'd be fine with re-issuing the draft were there is interest from other implementers.) Point 2. "Adders are simple and straightforward to implement, but due to carries, they do not execute in constant time. LSFRs offer an alternative that executes in constant time." However, the per-block increment operation is far more time critical than the per-packet increment operation! Since the block counter is a monotonically increasing integer, and it's presumably fast enough, it's hard to see how the fact cited in the draft supports the use of LFSRs for the per-packet field. Point 1. "... there is no advantage to selecting a mechanism that allows the decryptor to determine whether counter block values collide. Damage from the collision is done, whether the decryptor detects it or not." Yes, but the detection of a malfunctioning ESP sender could enable an administrator to shut off the errant device. Either the ESP CTR receiver or a passive security monitoring device such as a network IDS system can detect ESP sequence number re-use. When is the delayed detection of the failure of a security system worse than no detection? I don't disagree with Point 3 and Points 5 and 6 follow from the others. I would be surprised if other implementers in the WG favored the use of an unspecified explicit IV over the use of the sequence number as an implicit IV. At any rate, I think we've discussed the points well enough to allow others in the WG to chime in. On to other topics. The draft says in Section 6 that AES CTR MUST NOT be used with statically configured keys. I certainly agree that this is a good thing. However, RFC2401 requires implementations to support such keys, saying "This document requires support for both manual and automatic distribution of keys." Perhaps that RFC means that manual keying be provided only for some ciphers (the mandatory to implement ones?). At any rate, it would be good for the WG to decide what is meant and to document it somewhere. (The Stream Cipher ESP draft hit this same issue). On the subject of interoperability, the AES CTR draft could be implemented using draft-mcgrew-saag-icm-00.txt (the generic counter mode draft that I wrote last November, which also lines up with the AES CTR variant in draft-ietf-avt-srtp-05.txt), if the spec were bent hard enough. This bending would consist of defining the 'initial offset' to be equal to (flags, truncated_spi), and of course throwing the explicit IV in front of the ciphertext. All of the AES CTR specs that I've seen have managed to agree that the per-block counter be a big-endian integer in the least significant bits of the counter, which probably ensures that implementations can share keystream-generation components. OTOH, while the closeness of the various AES CTR specifications is a good thing, the fact that the initial offset is not random has a negative security impact. The WG may decide that it prefers simplicity to strength against precomputation attacks. If so, fine, but this subject needs to be discussed in the rationale. In Section 6 the draft says: "Thus, to avoid counter block collisions, ESP implementations that permit use of the same key for encrypting and decrypting packets with the same peer MUST ensure that the two peers assign different SPI values to the security association (SA)." Is it actually kosher for two SAs to share the same keys? SAs are simplex per RFC 2401, though they could in principle share a single key. However, I'd expect that if the architecture allowed such key-sharing that it would require that the SAs be in the same SA bundle so that when one SA reaches it usage limit its twin gets deleted as well. I'm not aware of any such language, which makes me suspicious about using the same keys twice. Now for the real nit: at the bottom of page 7, a typo: "It is inappropriate to use this m AES-CTR" Best regards, David -- David A. McGrew, Ph.D. Manager, Strategic Crypto Development IOS Technologies Division Cisco Systems, Inc. (301) 349 5815 From owner-ipsec@lists.tislabs.com Wed Jul 24 19:13:56 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6P2Dtw06329; Wed, 24 Jul 2002 19:13:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA09159 Wed, 24 Jul 2002 21:26:47 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87060C6D@SARATOGA> From: Gregory Lebovitz To: "'Paul Hoffman / VPNC'" , ipsec@lists.tislabs.com Subject: RE: Two AES encryption modes? Date: Wed, 24 Jul 2002 18:34:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If AES-CTR comes to fruition quickly, can someone put forth an argument for continuing to use AES-CBC? (To clarify, I am not challenging us to drop AES-CBC, I just want to hear cryptographers explain why we would/would not need both). -----Original Message----- From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] Sent: Wednesday, July 24, 2002 9:56 AM To: ipsec@lists.tislabs.com Subject: Two AES encryption modes? At 8:08 AM -0400 7/24/02, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the IP Security Protocol Working Group >of the IETF. > > Title : Using AES Counter Mode With IPsec ESP > Author(s) : R. Housley > Filename : draft-ietf-ipsec-ciph-aes-ctr-00.txt > Pages : 12 > Date : 23-Jul-02 There are technical reasons why this WG might or might not want to have more than one AES encryption modes. I would like to bring up a non-technical reason why we wouldn't: interoperability. System A is marketed as doing AES. System B is marketed as doing AES. They won't interoperate unless they both do the same modes. Yes, we could demand that the users understand that "AES CBC" and "AES Counter" are different, and that when they hear "AES" they need to ask "which of the two AES modes do you mean"? That is a wholly unrealistic demand. As I understand it, the two modes have very different security properties, meaning that it would be unrealistic to require that any system that incorporated one had to incorporate both. Even if we went that route, it is unlikely that we could enforce (or even explain) why all proposals that included one should also include the other. Without a really, really strong security justification, the loss of understandable interoperability that comes with two different-but-similarly-named algorithms is not worth it. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jul 24 19:33:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6P2XTw06696; Wed, 24 Jul 2002 19:33:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA09234 Wed, 24 Jul 2002 21:53:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <4.3.2.7.2.20020720073224.02473a80@mira-sjc5-6.cisco.com> References: <4.3.2.7.2.20020709135351.0251a3f0@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020709135351.0251a3f0@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020720073224.02473a80@mira-sjc5-6.cisco.com> Date: Wed, 24 Jul 2002 00:47:15 -0400 To: Mark Baugher From: Stephen Kent Subject: Re: new version of ESP ID Cc: ipsec@lists.tislabs.com, msec@securemulticast.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:38 AM -0700 7/20/02, Mark Baugher wrote: >Steve, > >At 05:54 PM 7/12/2002 -0400, Stephen Kent wrote: >>Mark, >> >>> >>>I don't understand the distinction between static and dynamic SAs. >>>Is the distinction between a single-sender multicast SA versus >>>a multi-sender multicast SA? >>> >>>I think that it is a more robust solution to identify the multicast >>>SA using the source address as well as the SPI and destination >>>address. This is what many of us who worked in smug thought we >>>would do with MESP. Now that Steve is addressing multicast in >>>ESP and AH, it's not clear to me how msec should proceed with >>>MESP. >> >>There is a big distinction between single and multi-sender SAs, as >>we have discussed. One cannot make use of anti-replay for a >>multi-sender SA, unless we seriously change the model and I >>explained in my message to Bill why I don't think that's a >>reasonable change to pursue. > >I think I understand your rationale. We should at least document >the fact that it may be necessary to identify the multicast ESP SA >using the triple for source-specific >multicast - for some applications. I think Bill and Radia's >previous comments to this thread explain why. If all sources to a >multicast address use the same group key controller, then I don't >see a problem. If some sources to a multicast address use distinct >group key controllers (e.g., each source acts as its own >controller), then there is the potential for SPI collisions and >means must be invented to handle these collisions. > >Mark Mark, I don't feel that we have a good enough answers to proceed, yet. We cannot proceed on the basis of "may be necessary." What we need is a concise description of what is required for multicast traffic demuxing, based on extant protocol standards, including how SPIs will be assigned in the context of these protocols. Implementors cannot reasonably deal with the current level of vague characterization of requirements floating around in this discussion. for example, if there are two group key controllers for a multicast session, and each assigns SPis independently to subscribers (and thus the collision potential), which SPI will a sender put in an outbound packet to ensure that all recipients will recognize it? Steve From owner-ipsec@lists.tislabs.com Wed Jul 24 21:16:40 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6P4Gdw08199; Wed, 24 Jul 2002 21:16:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA09476 Wed, 24 Jul 2002 23:29:50 -0400 (EDT) Message-Id: <200207250342.AFR68985@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 24 Jul 2002 20:30:41 -0700 To: Gregory Lebovitz , "'Paul Hoffman / VPNC'" , ipsec@lists.tislabs.com From: Scott Fluhrer Subject: RE: Two AES encryption modes? In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87060C6D@SARATOGA> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:34 PM 7/24/02 , Gregory Lebovitz wrote: >If AES-CTR comes to fruition quickly, can someone put forth an argument for >continuing to use AES-CBC? > >(To clarify, I am not challenging us to drop AES-CBC, I just want to hear >cryptographers explain why we would/would not need both). Well, last year I published "A tale of three transforms", which compared and contrasted three proposed AES based transforms on a variety of criteria. No one disagreed with it (or at least no one was willing to tell me about their disagreement). I went ahead and revised it by omitting any references to the IAPM transform (which is not currently under discussion), and modified the counter mode evaluation for Housley's proposal, which differs in a number of points from the initial proposal: The goal of this memo is help the IETF specify the AES based IPSec transform, by comparing and contrasting two specific proposals by a variety of criteria. Two draft RFCs have been published to specify how AES will be used within an IPSec transform. These two drafts are: A CBC mode draft (referred to as CBC within this memo): http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-04.txt A Counter mode draft (referred to as COUNTER within this memo): http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-00.txt The author welcomes any correction to these evaluations, and any additional criteria that these proposals should be evaluated against. A few notes on the ground rules used for these evaluations: We will assume that the IPSec SAs will require message authentication, and hence for the purposes of the evaluation, the CBC and COUNTER drafts will be used along with an authentication transform. We also note that there are a variety of ways to tweak these proposals to reduce some of the listed drawbacks. However, these tweaks tend to add drawbacks elsewhere. Because of this complexity, we will examine the proposals as written. The actual evaluations: Security Claims: Both transforms claim to offer privacy equivalent to the underlying block cipher (for the number of messages that IPSec can transmit before rekeying). Neither makes any authentication claims. Confidence in the Security Claims: This section is, necessarily, a matter of opinion. However, we all feel good with CBC -- we have used it with all previous block-cipher based transforms. We don't have as much experience with COUNTER mode, however, there is enough to feel comfortable with it. Completeness of Specification: CBC is a complete specification -- it appears that the authors have specified enough to allow interoperable implementations to be created. COUNTER also appears to be complete. Packet Size: COUNTER has the shortest packets -- there is a short (8 byte) IV and supports minimal padding. Hence, the overhead is 9-12 bytes, along with the overhead from the authentication transform. CBC is rather larger -- there is a 16 byte IV, 1-16 bytes of padding, and the overhead from the authentication transform. Speed of Software Implementation: Both transforms can be executed in approximately the same speed. However, both CBC and COUNTER also require authentication transforms to be executed. Speed of Hardware Implementation: This evaluation assumes an aggressively parallized hardware implementation. COUNTER is parallizable, but then brings us the question of how to make the authentication transform equally fast. CBC is necessarily slow in the encrypted direction, because the block cipher evaluations must be done serially. Intellectual Property Issues: There is no know intellection property issues with CBC or COUNTER, and there is sufficient prior art to make it quite unlikely that any will arise. Fit within Existing Security Architecture: CBC and COUNTER fit into the existing security architecture as encryption transforms. Strength against Faulty Implementations: By faulty implementation, we refer to accidental faults that allow implementations to interoperate, but cause security risks. We do not consider faults available to malicious implementations, as side channels exist independent of the transform. With CBC, the worst fault appears to be if the IV generation reuses the same IV. This would allow the attacker to see if the first blocks of the encrypted data are reused, however, this does not appear to be a severe problem. COUNTER has the most severe problems -- if a faulty keying mechanism reuses the same keys and IVs between sessions, then an attacker can gain considerable information on the encrypted data. From owner-ipsec@lists.tislabs.com Thu Jul 25 06:44:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PDi2w02163; Thu, 25 Jul 2002 06:44:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10438 Thu, 25 Jul 2002 08:57:37 -0400 (EDT) Message-Id: <200207251206.IAA29746@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-ecc-groups-04.txt Date: Thu, 25 Jul 2002 08:06:13 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Additional ECC Groups For IKE Author(s) : S. Blake-Wilson, D. Brown, Y. Poeluev, M. Salter Filename : draft-ietf-ipsec-ike-ecc-groups-04.txt Pages : 17 Date : 24-Jul-02 This document describes new ECC groups for use in IKE [IKE] in addition to the Oakley groups included therein. These groups are defined to align IKE with other ECC implementations and standards, and in addition, many of them provide higher strength than the Oakley groups. It should be noted that this document is not self-contained. It uses the notations and definitions of [IKE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ecc-groups-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-ipsec-ike-ecc-groups-04.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-ietf-ipsec-ike-ecc-groups-04.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020724142757.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-ecc-groups-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-ecc-groups-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020724142757.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Jul 25 07:46:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PEkIw04265; Thu, 25 Jul 2002 07:46:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10552 Thu, 25 Jul 2002 10:00:29 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60317303B@zcard0ke.ca.nortel.com> From: "Dennis Beard" To: Paul Hoffman / VPNC , Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Cc: Steve Bellovin , jis@mit.edu Subject: RE: Vendor Extensions Date: Thu, 25 Jul 2002 09:53:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C233E2.AB2613A0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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_01C233E2.AB2613A0 Content-Type: text/plain; charset="iso-8859-1" Hi Paul, I took the minutes of the IPsec WG meeting and Steve's comment was "specific" vendor extensions. In other words, if an implementation required the use of Acme company extension RG v.02 to make the protocol function properly, this would be considered "inappropriate". That's how I heard and interpreted his comment. Steve was very sure of his remarks as he quickly went to the microphone when the comment about vendor extensions was mentioned. Regards, Dennis Beard -----Original Message----- From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] Sent: Tuesday, July 23, 2002 1:48 PM To: Charlie_Kaufman@notesdev.ibm.com; ipsec@lists.tislabs.com Cc: Steve Bellovin; jis@mit.edu Subject: Re: Vendor Extensions At 11:44 AM -0400 7/23/02, Charlie_Kaufman@notesdev.ibm.com wrote: > > Steve Bellovin, Security Area Director, strongly commented that any >drafts >> that contained specific vendor extensions would cause the IESG to be >> concerned and may even cause it to be rejected. He states this in his > > capacity of Area Director, not as a co-author of the JFK draft. > >Could we get clarification of IESG policy on vendor extensions and also >feedback from the working group on their usefulness? Did Steve say "vendor extensions" or "specific vendor extensions"? Clarification would be helpful here. >1) Is anyone using the field in IKEv1? If you do packet dumps while watching many IPsec systems interoperate, you will see that many (possibly most) vendors use them in IKEv1. --Paul Hoffman, Director --VPN Consortium ------_=_NextPart_001_01C233E2.AB2613A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Vendor Extensions Hi Paul, I took the minutes of the IPsec WG meeting and = Steve's comment was "specific" vendor extensions. In = other words, if an implementation required the use of Acme company = extension RG v.02 to make the protocol function properly, this would be = considered "inappropriate". That's how I heard and = interpreted his comment. Steve was very sure of his remarks as he = quickly went to the microphone when the comment about vendor extensions = was mentioned. Regards, Dennis Beard -----Original Message----- From: Paul Hoffman / VPNC [<3d.htm>mailto:paul.hoffman@vpnc.org]<= /FONT> Sent: Tuesday, July 23, 2002 1:48 PM To: Charlie_Kaufman@notesdev.ibm.com; = ipsec@lists.tislabs.com Cc: Steve Bellovin; jis@mit.edu Subject: Re: Vendor Extensions At 11:44 AM -0400 7/23/02, = Charlie_Kaufman@notesdev.ibm.com wrote: > > Steve Bellovin, Security Area = Director, strongly commented that any >drafts >> that contained specific vendor = extensions would cause the IESG to be >> concerned and may even cause it to be = rejected. He states this in his > > capacity of Area Director, not as a = co-author of the JFK draft. > >Could we get clarification of IESG policy on = vendor extensions and also >feedback from the working group on their = usefulness? Did Steve say "vendor extensions" or = "specific vendor extensions"? Clarification would be helpful here. >1) Is anyone using the field in IKEv1? If you do packet dumps while watching many IPsec = systems interoperate, you will see that many (possibly most) = vendors use them in IKEv1. --Paul Hoffman, Director --VPN Consortium ------_=_NextPart_001_01C233E2.AB2613A0-- --=====================_6214125==_.ALT Content-Type: text/html; charset="us-ascii" Approved: Dob.ipsec >From majordomo-owner Thu Jul 25 09:40:06 2002 Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id JAA10520 Thu, 25 Jul 2002 09:40:06 -0400 (EDT) Received: by sentry.gw.tislabs.com; id JAA14232; Thu, 25 Jul 2002 09:53:54 -0400 (EDT) Received: from zcars04e.nortelnetworks.com(47.129.242.56) by sentry.gw.tislabs.com via smap (V5.5) id xma014223; Thu, 25 Jul 02 13:53:21 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6PDrZX11919; Thu, 25 Jul 2002 09:53:35 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jul 2002 09:53:34 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60317303B@zcard0ke.ca.nortel.com> From: "Dennis Beard" To: Paul Hoffman / VPNC , Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Cc: Steve Bellovin , jis@mit.edu Subject: RE: Vendor Extensions Date: Thu, 25 Jul 2002 09:53:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C233E2.AB2613A0" 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_01C233E2.AB2613A0 Content-Type: text/plain; charset="iso-8859-1" Hi Paul, I took the minutes of the IPsec WG meeting and Steve's comment was "specific" vendor extensions. In other words, if an implementation required the use of Acme company extension RG v.02 to make the protocol function properly, this would be considered "inappropriate". That's how I heard and interpreted his comment. Steve was very sure of his remarks as he quickly went to the microphone when the comment about vendor extensions was mentioned. Regards, Dennis Beard -----Original Message----- From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] Sent: Tuesday, July 23, 2002 1:48 PM To: Charlie_Kaufman@notesdev.ibm.com; ipsec@lists.tislabs.com Cc: Steve Bellovin; jis@mit.edu Subject: Re: Vendor Extensions At 11:44 AM -0400 7/23/02, Charlie_Kaufman@notesdev.ibm.com wrote: > > Steve Bellovin, Security Area Director, strongly commented that any >drafts >> that contained specific vendor extensions would cause the IESG to be >> concerned and may even cause it to be rejected. He states this in his > > capacity of Area Director, not as a co-author of the JFK draft. > >Could we get clarification of IESG policy on vendor extensions and also >feedback from the working group on their usefulness? Did Steve say "vendor extensions" or "specific vendor extensions"? Clarification would be helpful here. >1) Is anyone using the field in IKEv1? If you do packet dumps while watching many IPsec systems interoperate, you will see that many (possibly most) vendors use them in IKEv1. --Paul Hoffman, Director --VPN Consortium ------_=_NextPart_001_01C233E2.AB2613A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Vendor Extensions Hi Paul, I took the minutes of the IPsec WG meeting and = Steve's comment was "specific" vendor extensions. In = other words, if an implementation required the use of Acme company = extension RG v.02 to make the protocol function properly, this would be = considered "inappropriate". That's how I heard and = interpreted his comment. Steve was very sure of his remarks as he = quickly went to the microphone when the comment about vendor extensions = was mentioned. Regards, Dennis Beard -----Original Message----- From: Paul Hoffman / VPNC [<3d.htm>mailto:paul.hoffman@vpnc.org]<= /FONT> Sent: Tuesday, July 23, 2002 1:48 PM To: Charlie_Kaufman@notesdev.ibm.com; = ipsec@lists.tislabs.com Cc: Steve Bellovin; jis@mit.edu Subject: Re: Vendor Extensions At 11:44 AM -0400 7/23/02, = Charlie_Kaufman@notesdev.ibm.com wrote: > > Steve Bellovin, Security Area = Director, strongly commented that any >drafts >> that contained specific vendor = extensions would cause the IESG to be >> concerned and may even cause it to be = rejected. He states this in his > > capacity of Area Director, not as a = co-author of the JFK draft. > >Could we get clarification of IESG policy on = vendor extensions and also >feedback from the working group on their = usefulness? Did Steve say "vendor extensions" or = "specific vendor extensions"? Clarification would be helpful here. >1) Is anyone using the field in IKEv1? If you do packet dumps while watching many IPsec = systems interoperate, you will see that many (possibly most) = vendors use them in IKEv1. --Paul Hoffman, Director --VPN Consortium ------_=_NextPart_001_01C233E2.AB2613A0-- --=====================_6214125==_.ALT-- From owner-ipsec@lists.tislabs.com Thu Jul 25 07:56:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PEuWw04596; Thu, 25 Jul 2002 07:56:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10577 Thu, 25 Jul 2002 10:14:40 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15680.2800.509000.651699@gargle.gargle.HOWL> Date: Thu, 25 Jul 2002 10:28:00 -0400 From: Paul Koning To: Gregory@netscreen.com Cc: ipsec@lists.tislabs.com Subject: RE: Two AES encryption modes? References: <541402FFDC56DA499E7E13329ABFEA87060C6D@SARATOGA> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Excerpt of message (sent 24 July 2002) by Gregory Lebovitz: > If AES-CTR comes to fruition quickly, can someone put forth an argument for > continuing to use AES-CBC? > > (To clarify, I am not challenging us to drop AES-CBC, I just want to hear > cryptographers explain why we would/would not need both). Several possible reasons: 1. You have hardware that implements AES-CBC but not AES-CTR. 2. You want to use manual keying and therefore may send more than one packet with the same IV. With CBC that doesn't compromise the confidentiality of the data; with counter mode it does. In my view, #1 is a sufficient reason. paul From owner-ipsec@lists.tislabs.com Thu Jul 25 08:01:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PF15w04759; Thu, 25 Jul 2002 08:01:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10605 Thu, 25 Jul 2002 10:20:48 -0400 (EDT) From: "David A. Mcgrew" To: "Gregory Lebovitz" , Subject: RE: Two AES encryption modes? Date: Thu, 25 Jul 2002 07:34:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87060C6D@SARATOGA> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Gregory, > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Gregory Lebovitz > Sent: Wednesday, July 24, 2002 6:34 PM > To: 'Paul Hoffman / VPNC'; ipsec@lists.tislabs.com > Subject: RE: Two AES encryption modes? > > > If AES-CTR comes to fruition quickly, can someone put forth an > argument for > continuing to use AES-CBC? > > (To clarify, I am not challenging us to drop AES-CBC, I just want to hear > cryptographers explain why we would/would not need both). One consideration is the fact that draft-ietf-ipsec-ciph-aes-ctr-00.txt MUST NOT be used with manual keys. David From owner-ipsec@lists.tislabs.com Thu Jul 25 09:05:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PG5Zw08967; Thu, 25 Jul 2002 09:05:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10758 Thu, 25 Jul 2002 11:13:31 -0400 (EDT) Message-Id: <200207251527.g6PFRZB6006042@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Two AES encryption modes? In-reply-to: Your message of "Wed, 24 Jul 2002 14:57:21 EDT." <2575327B6755D211A0E100805F9FF9540DD82649@ndhmex02.ndhm.gsc.gte.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 25 Jul 2002 11:27:33 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Waterhouse," == Waterhouse, Richard writes: Paul> I would like to bring up a Paul> non-technical reason why we wouldn't: interoperability. Richard> In my humble opinion it should be a requiremnent on Son of IKE Richard> that it be able to negotiate Mode. Uh, they are really two different ciphers and should be treated like that. I'm pretty sure that we already decided that SOI would treat AES-128 and AES-256 as two entirely different ciphers as well. No argument about combinatorics. ] Internet Security. Have encryption, will travel |1 Fish/2 Fish [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F [ ]mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [ ] At the far end of some dark fiber - wait that's dirt! |for everyone [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPUAY4YqHRg3pndX9AQF1AQQAqftaYPWzkkAWbGz4fVC8MawYqOShsDpQ +DH2++NlpxJq4q2fhZRNNFLC9Ausa9DVxX+4faelvbgfVzuJUrjdn3pnFKufkkwN ri3XccbCjoD2UG7adpz7MZZs5Xwex1Gw82Zm87ZxEWZ2U5yAWJ8s50pWqPxZpdk0 +B+yB4lapxM= =j52p -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Jul 25 09:05:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PG5rw09020; Thu, 25 Jul 2002 09:05:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10770 Thu, 25 Jul 2002 11:17:32 -0400 (EDT) Message-Id: <5.0.2.1.0.20020725104935.027c0198@mail.ccs.neu.edu> X-Sender: noubir@mail.ccs.neu.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 25 Jul 2002 10:59:54 -0400 To: (Recipient list suppressed) From: "G. Noubir" Subject: ACM Workshop of Wireless Security (WiSE) [in conjuntion with ACM MobiCom'02] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----------------------------------------------------------------------- Please Accept Our Sincere Apologies Should you Receive Multiple Copies of this Announcement ----------------------------------------------------------------------- Call for Participation ACM Workshop on Wireless Security (WiSe) in conjunction with ACM MobiCom 2002 September 28, 2002 Atlanta, Georgia, U.S.A. http://www.crhc.uiuc.edu/~nhv/wise Sponsored by ACM SIGMOBILE A workshop on wireless security will be held in conjunction with ACM MobiCom 2002. The objective of this workshop is to bring together researchers from research communities in wireless networking, security, and dependability, with the goal of fostering interaction among them. With the increasing reliance on wireless networks, issues related to secure and dependable operation of such networks are gaining importance. For registration information, please visit http://www.crhc.uiuc.edu/~nhv/wise Preliminary Program -------------------------------------------------------------------------------- Paper Session 1 (8:30 - 10:00 a.m.) Securing Ad-Hoc Routing Protocols, M. Guerrero Zapata and N. Asokan (Nokia Research Center, Finland) Self-Organized Network Layer Security in Mobile Ad Hoc Networks, H. Yang, X. Meng and S. Lu (University of California at Los Angeles) An On-Demand Secure Routing Protocol Resilent to Byzantine Failures, B. Awerbuch, D. Holmer, C. Nita-Rotaru and H. Rubens (Johns Hopkins University) -------------------------------------------------------------------------------- Paper Session 2 (10:30 a.m. - 12:00 noon) Survivable Mobile Wireless Networks: Issues, Challenges, and Research Directions, R. Krishnan, R. Rosales Hain, A. W. Jackson, D. Levin, R. Ramanathan, J. Zao and J. P. G. Sterbenz (BBN Technologies) Secure Wireless Gateway, A. Godber and P. Dasgupta (Arizona State University) DoS and Authentication in Wireless Public Access Networks, D. B. Faria and D. R. Cheriton (Stanford University) -------------------------------------------------------------------------------- Poster session (1:00 - 2:15 p.m.) -------------------------------------------------------------------------------- Perspectives from Funding Agencies (2:15 - 3:00) Information Assurance and Research Opportunities, D. Maughan, Defence Advanced Research Projects Agency Title to be announced T. Znati, National Science Foundation and University of Pittsburgh -------------------------------------------------------------------------------- Paper Session 3 (3:30 - 5:30) A Distributed Monitoring Mechanism in Wireless Sensor Networks, C.-F. Hsin and M. Liu (University of Michigan at Ann Arbor) Using Signal Processing to Analyze Wireless Data Traffic, C. Partridge, D. Cousins, A. W. Jackson, R. Krishnan, T. Saxena, and W. T. Strayer (BBN Technologies) Securing IPv6 Neighor Discovery, J. Arkko (Ericsson Research NomadicLab), T. Aura (DoCoMoLabs U.S.A.), J. Kempf (Microsoft Research Cambridge), V.-M. Mantyla, P. Nikander (Ericsson Research NomadicLab) and M. Roe (DoCoMoLabs USA.) Performance Analysis of Elliptic Curve Cryptography for SSL, V. Gupta, S. Gupta, Sh. Chang and D. Stebila (Sun Microsystems) -------------------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Thu Jul 25 09:13:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PGDUw10061; Thu, 25 Jul 2002 09:13:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10746 Thu, 25 Jul 2002 11:08:30 -0400 (EDT) Message-Id: <200207251522.g6PFLxAc005914@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Two AES encryption modes? In-reply-to: Your message of "Wed, 24 Jul 2002 09:56:07 PDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 25 Jul 2002 11:21:57 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "VPNC" == VPNC writes: VPNC> At 8:08 AM -0400 7/24/02, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IP Security Protocol Working Group >> of the IETF. >> >> Title : Using AES Counter Mode With IPsec ESP >> Author(s) : R. Housley >> Filename : draft-ietf-ipsec-ciph-aes-ctr-00.txt >> Pages : 12 >> Date : 23-Jul-02 VPNC> There are technical reasons why this WG might or might not want to VPNC> have more than one AES encryption modes. I would like to bring up a VPNC> non-technical reason why we wouldn't: interoperability. VPNC> System A is marketed as doing AES. System B is marketed as doing AES. VPNC> They won't interoperate unless they both do the same modes. Yes, we VPNC> could demand that the users understand that "AES CBC" and "AES VPNC> Counter" are different, and that when they hear "AES" they need to VPNC> ask "which of the two AES modes do you mean"? That is a wholly VPNC> unrealistic demand. One solution is to make up two new names for them, neither of which is "AES". This is a marketing solution to a marketing problem. VPNC> Without a really, really strong security justification, the loss of VPNC> understandable interoperability that comes with two VPNC> different-but-similarly-named algorithms is not worth it. Fix the names. I propose "Ted" and "Barbara" as the new working names. They can fight over which one is more secure. ] Internet Security. Have encryption, will travel |1 Fish/2 Fish [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F [ ]mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [ ] At the far end of some dark fiber - wait that's dirt! |for everyone [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPUAXZYqHRg3pndX9AQHV5wP+ON/nBgehwk9btwl+cF4RZkwU7qmhXr/2 79fMKOkgkSHqZWk+A/iMuh93cZZWck70Fl+nttN27f3p6BPFYFU0xB12VCxZozfJ FyKIva+EkqJGG97/gEmDloHYrt109dG+JBaOgksc2XpE0xcNE38AIVA8I3wOR9r4 PA2UDLjn2q0= =qqDW -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Jul 25 09:59:26 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PGxPw13267; Thu, 25 Jul 2002 09:59:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10930 Thu, 25 Jul 2002 12:04:29 -0400 (EDT) Message-Id: <200207251618.g6PGI1wE024672@kebe.east.sun.com> Subject: Re: Two AES encryption modes? In-Reply-To: <200207251527.g6PFRZB6006042@marajade.sandelman.ottawa.on.ca> from Michael Richardson at "Jul 25, 2002 11:27:33 am" To: Michael Richardson Date: Thu, 25 Jul 2002 12:18:01 -0400 (EDT) CC: ipsec@lists.tislabs.com From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Uh, they are really two different ciphers and should be treated like that. I agree here w.r.t. AES-CBC vs. AES-Counter. OTOH... > I'm pretty sure that we already decided that SOI would treat AES-128 and > AES-256 as two entirely different ciphers as well. > No argument about combinatorics. WHAT!?! We already have Blowfish, which is variable key-sized, even though 2451 says its default is 128. We shouldn't need to break existing semantics for AES! Dan From owner-ipsec@lists.tislabs.com Thu Jul 25 11:28:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PISJw17754; Thu, 25 Jul 2002 11:28:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11166 Thu, 25 Jul 2002 13:42:59 -0400 (EDT) Message-Id: <200207251756.g6PHua8v009017@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Two AES encryption modes? In-reply-to: Your message of "Thu, 25 Jul 2002 12:18:01 EDT." <200207251618.g6PGI1wE024672@kebe.east.sun.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 25 Jul 2002 13:56:35 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Dan" == Dan McDonald writes: >> I'm pretty sure that we already decided that SOI would treat AES-128 and >> AES-256 as two entirely different ciphers as well. >> No argument about combinatorics. Dan> WHAT!?! We already have Blowfish, which is variable key-sized, even though Dan> 2451 says its default is 128. We shouldn't need to break existing semantics Dan> for AES! *Son-Of-Ike* You want to maintain that? WHY? I refuse to test my code for all the different key sizes available for BlowFish. I further refuse to even implement all of those combinations. Now, when I say "Blowfish" - do you really want users^H^H^H^H^Hmarketing to worry about the length you support? ] Internet Security. Have encryption, will travel |1 Fish/2 Fish [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F [ ]mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [ ] At the far end of some dark fiber - wait that's dirt! |for everyone [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPUA70IqHRg3pndX9AQElPQQA5AjkRcQIvPmRQWIduVGp1s9zv8QuVEh9 f+ZurNawD0vJel39NJfxqRT+/GIS23Yb2TY5uA5O/QthiASj722npnqkbzF/l4oq RCWxTbJcl6hXuvNmfVyD3xAaj7864ooMpWmWXrPTXdBsW2/tD6sseSG8R1vLO7/Z eaKc8Nncvm8= =9tzd -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Jul 25 11:28:23 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PISMw17772; Thu, 25 Jul 2002 11:28:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11134 Thu, 25 Jul 2002 13:33:46 -0400 (EDT) Date: 25 Jul 2002 13:33:02 -0400 Message-ID: <002f01c23401$5491ad00$d16fe640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Michael Richardson'" , " " Subject: RE: Two AES encryption modes? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200207251522.g6PFLxAc005914@marajade.sandelman.ottawa.on.ca> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is the type of problem that named ciphersuites will solve. I've been thinking a bit about the semantics of this, and I think we could come up with a pretty good naming scheme of the form . E.g.: IETF-ipsec high security '02 (chosen by WG, published in an RFC) US DoD FIPS standard '02 (chosen by a large customer, listed as a requirement) VPNC default '02 (chosen by a vendor consortium, published on their website) JoeBillyBob JBB's ciphersuite '02 (chosen by an individual, distributed to his friends) Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael Richardson > Sent: Thursday, July 25, 2002 11:22 AM > To: ipsec@lists.tislabs.com > Subject: Re: Two AES encryption modes? > > > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "VPNC" == VPNC writes: > VPNC> At 8:08 AM -0400 7/24/02, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line > Internet-Drafts > >> directories. > >> This draft is a work item of the IP Security Protocol > Working Group > >> of the IETF. > >> > >> Title : Using AES Counter Mode With IPsec ESP > >> Author(s) : R. Housley > >> Filename : draft-ietf-ipsec-ciph-aes-ctr-00.txt > >> Pages : 12 > >> Date : 23-Jul-02 > > VPNC> There are technical reasons why this WG might or > might not want to > VPNC> have more than one AES encryption modes. I would > like to bring up a > VPNC> non-technical reason why we wouldn't: interoperability. > > VPNC> System A is marketed as doing AES. System B is > marketed as doing AES. > VPNC> They won't interoperate unless they both do the > same modes. Yes, we > VPNC> could demand that the users understand that "AES > CBC" and "AES > VPNC> Counter" are different, and that when they hear > "AES" they need to > VPNC> ask "which of the two AES modes do you mean"? That > is a wholly > VPNC> unrealistic demand. > > One solution is to make up two new names for them, neither > of which is "AES". > This is a marketing solution to a marketing problem. > > VPNC> Without a really, really strong security > justification, the loss of > VPNC> understandable interoperability that comes with two > VPNC> different-but-similarly-named algorithms is not worth it. > > Fix the names. > > I propose "Ted" and "Barbara" as the new working names. > They can fight over > which one is more secure. > > ] Internet Security. Have encryption, will travel > |1 Fish/2 Fish [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |Red F./Blow F [ > ]mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |strong crypto [ > ] At the far end of some dark fiber - wait that's dirt! > |for everyone [ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > Comment: Finger me for keys > > iQCVAwUBPUAXZYqHRg3pndX9AQHV5wP+ON/nBgehwk9btwl+cF4RZkwU7qmhXr/2 > 79fMKOkgkSHqZWk+A/iMuh93cZZWck70Fl+nttN27f3p6BPFYFU0xB12VCxZozfJ > FyKIva+EkqJGG97/gEmDloHYrt109dG+JBaOgksc2XpE0xcNE38AIVA8I3wOR9r4 > PA2UDLjn2q0= > =qqDW > -----END PGP SIGNATURE----- > From owner-ipsec@lists.tislabs.com Thu Jul 25 11:42:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PIgTw18662; Thu, 25 Jul 2002 11:42:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11254 Thu, 25 Jul 2002 13:58:12 -0400 (EDT) Message-Id: <200207251811.g6PIBIc5009391@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Two AES encryption modes? In-reply-to: Your message of "25 Jul 2002 13:33:02 EDT." <002f01c23401$5491ad00$d16fe640@ca.alcatel.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 25 Jul 2002 14:11:17 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Andrew" == Andrew Krywaniuk writes: Andrew> This is the type of problem that named ciphersuites will solve. I've been Andrew> thinking a bit about the semantics of this, and I think we could come up Andrew> with a pretty good naming scheme of the form Andrew> . Other than the Y2K compliance needed, I like your proposal. I know that you have argued for having them at the GUI level, while I think that they should be negotiated directly. My belief is that one reason for resistance to getting the numbers assigned is that people believe that the IANA is hard to work with. Paul said that he was working to fix that. How is that going? It seems that a named ciphersuite needs an RFC to describe it anyway. Getting a number assigned seems simple to me. ] Internet Security. Have encryption, will travel |1 Fish/2 Fish [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F [ ]mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [ ] At the far end of some dark fiber - wait that's dirt! |for everyone [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPUA/QYqHRg3pndX9AQFifQP8DMg55+zgetSfETCyznpfeOfnlST0W+at 1eVjae6Dt9L7ls92+hVVGJd4EcQV3RjgJ1PJci048Om7AqPYhrhVtv/DsTr+bevR KMSCHRLjmnXeLx9xI7H2nSQu9ohnVpp2cPR1GPK3s7bzT3Oud1M4XOwlG0+SEarE j/LDSfPcWLQ= =IK/3 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Jul 25 13:08:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PK8Ew25771; Thu, 25 Jul 2002 13:08:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11402 Thu, 25 Jul 2002 15:15:21 -0400 (EDT) Date: 25 Jul 2002 15:14:30 -0400 Message-ID: <003001c2340f$81ec5c60$d16fe640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Michael Richardson'" , " 'list'" Subject: RE: Two AES encryption modes? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200207251811.g6PIBIc5009391@marajade.sandelman.ottawa.on.ca> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > It seems that a named ciphersuite needs an RFC to describe > it anyway. > Getting a number assigned seems simple to me. Not necessarily. Take a look at the list I sent earlier: IETF-ipsec high security '02 (chosen by WG, published in an RFC) US DoD FIPS standard '02 (chosen by a large customer, listed as a requirement) VPNC default '02 (chosen by a vendor consortium, published on their website) JoeBillyBob JBB's ciphersuite '02 (chosen by an individual, distributed to his friends) Only the first ciphersuite needs to be published in an RFC. The other ones are published on the DoD, VPNC, and joebillybob.com websites/technical publications respectively. If you use GUI ciphersuites there is no IANA registry, so there doesn't need to be a comprehensive list of all the possible ciphersuites. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael Richardson > Sent: Thursday, July 25, 2002 2:11 PM > To: ipsec@lists.tislabs.com > Subject: Re: Two AES encryption modes? > > > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Andrew" == Andrew Krywaniuk > writes: > Andrew> This is the type of problem that named > ciphersuites will solve. I've been > Andrew> thinking a bit about the semantics of this, and I > think we could come up > Andrew> with a pretty good naming scheme of the form > > Andrew> . > > Other than the Y2K compliance needed, I like your proposal. > > I know that you have argued for having them at the GUI > level, while I think > that they should be negotiated directly. My belief is that > one reason for > resistance to getting the numbers assigned is that people > believe that the > IANA is hard to work with. > > Paul said that he was working to fix that. How is that going? > > It seems that a named ciphersuite needs an RFC to describe > it anyway. > Getting a number assigned seems simple to me. > > ] Internet Security. Have encryption, will travel > |1 Fish/2 Fish [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |Red F./Blow F [ > ]mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |strong crypto [ > ] At the far end of some dark fiber - wait that's dirt! > |for everyone [ > > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3ia > Charset: latin1 > Comment: Finger me for keys > > iQCVAwUBPUA/QYqHRg3pndX9AQFifQP8DMg55+zgetSfETCyznpfeOfnlST0W+at > 1eVjae6Dt9L7ls92+hVVGJd4EcQV3RjgJ1PJci048Om7AqPYhrhVtv/DsTr+bevR > KMSCHRLjmnXeLx9xI7H2nSQu9ohnVpp2cPR1GPK3s7bzT3Oud1M4XOwlG0+SEarE > j/LDSfPcWLQ= > =IK/3 > -----END PGP SIGNATURE----- > From owner-ipsec@lists.tislabs.com Thu Jul 25 17:53:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6Q0rTw05989; Thu, 25 Jul 2002 17:53:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11863 Thu, 25 Jul 2002 20:05:15 -0400 (EDT) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Two AES encryption modes? Date: 26 Jul 2002 00:02:48 GMT Organization: University of California, Berkeley Lines: 12 Distribution: isaac Message-ID: References: <541402FFDC56DA499E7E13329ABFEA87060C6D@SARATOGA> <15680.2800.509000.651699@gargle.gargle.HOWL> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1027641768 2908 128.32.153.211 (26 Jul 2002 00:02:48 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 26 Jul 2002 00:02:48 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: >2. You want to use manual keying and therefore may send more than one > packet with the same IV. With CBC that doesn't compromise the > confidentiality of the data; with counter mode it does. Nitpick: CBC is not really as secure as one might like if IV's repeat, however it is true that IV reuse hurts CTR mode much worse than CBC mode. If you reuse the same IV with CBC mode, there is some minor compromise of message confidentiality (shared plaintext prefixes show through as shared prefixes in the ciphertexts); in comparison, IV reuse in CTR mode is more devastating (it reveals both plaintexts). From owner-ipsec@lists.tislabs.com Thu Jul 25 18:56:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6Q1uhw06924; Thu, 25 Jul 2002 18:56:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11961 Thu, 25 Jul 2002 21:12:54 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C0FC@CORPMX14> To: ipsec@lists.tislabs.com Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Thu, 25 Jul 2002 21:23:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A few comments on this from a co-chair of the IP Storage (ips) WG, which is *very* interested in AES Counter Mode - it will be a "SHOULD implement" requirement for the IP Storage protocols. - The primary motivation for IP Storage's interest in AES Counter mode is the perceived "need for speed". 3DES CBC is the "MUST implement" algorithm/mode, and we wanted the second choice of algorithm to scale to significantly higher speeds. Yes, there's a problem with getting a faster authentication transform, but that leaves one problem to solve as opposed to two, which sounds like progress - also see Howard Herbert's related email on this topic. - Packet expansion is not an issue for IP Storage because typical data transfer sizes are kilobytes and up. 8 bytes overhead on even a 1kB MTU is in the noise. IP Storage doesn't share voice over RTP's need to squeeze out every last possible byte of overhead. - IP Storage bans manual/static keying (MUST NOT use); pre-shared keying is ok. With IP Storage's potential/likelihood of transferring large amounts of data, an automatic rekeying mechanism is necessary (MUST implement) independent of whether AES Counter Mode is used or not. - Words fail me in reacting to Paul Hoffman's naming non-issue, but I like Michael Richardson's suggestion of renaming the AES mode to "Ted" and "Barbara" for marketing purposes :-). Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 FAX: +1 (508) 497-8018 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ipsec@lists.tislabs.com Fri Jul 26 04:41:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QBfxw23143; Fri, 26 Jul 2002 04:41:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA13010 Fri, 26 Jul 2002 06:55:08 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Charlie_Kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com, jis@mit.edu Subject: Re: Vendor Extensions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Jul 2002 07:09:13 -0400 Message-Id: <20020726110913.A12997B4D@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Charlie_Kaufman@notesdev.ibm.com writes: > > > > >> Steve Bellovin, Security Area Director, strongly commented that any >drafts >> that contained specific vendor extensions would cause the IESG to be >> concerned and may even cause it to be rejected. He states this in his >> capacity of Area Director, not as a co-author of the JFK draft. > >Could we get clarification of IESG policy on vendor extensions and also >feedback from the working group on their usefulness? Sorry we haven't answered yet. The IESG is actively discussing this and related issues. We hope to have an answer soon. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) From owner-ipsec@lists.tislabs.com Fri Jul 26 06:56:00 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QDtxw00151; Fri, 26 Jul 2002 06:55:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13228 Fri, 26 Jul 2002 09:07:25 -0400 (EDT) Message-ID: <6F0AA176DA68704884B7507AE6907E18091F4C@snake012.odetics.com> From: Klaus Helbig To: "'mcgrew@cisco.com'" Cc: "'ipsec@lists.tislabs.com'" Subject: re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Thu, 25 Jul 2002 14:45:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David, yes, I agree with you, I can not see any reason to use an external IV for AES CTR if algorithms easy can be defined for internal building of IV's with ESP sequence number and SPI. The only cryptographic requirement for the sequence of IV's is, that all the counter values, derived from all the IV's over all the ESP packets, transformed by AES, are different as long as one fixed key is used. Or more mathematical: Assume IV(i) with i=1,2,... is the sequence of IV's being used for the sequence of ESP packets ESP(i) with i=1,2,... and M is the maximal number of blocks of block size 128 bit allowed in an ESP packet. Assume CV(i,j) with j=1,2,...,M is the sequence of counter values for the ESP packet ESP(i), derived from IV(i) for i=1,2,.... The requirement then is for each fixed key CV( i, j ) != CV( k, l ) for all ( i, j ) != ( k, l ) with (i,k > 0), (0 < j,l <= M). Might I'm wrong but I think no reason exists to state "that no more than 2^64 blocks of block size 128 bits should be encrypted with any fixed key" as long as the requirement above is fulfilled. What means birthday attack in connection to the counter mode? I guess it means following. When more than 2^64 blocks have been encrypted with any fixed key then with higher probability exist equal block keys AES(Key, CV(i,j)) = AES(Key, CV(k,l)) for any (i,j) != (k,l) to encrypt the different plaintext blocks P(i,j) and P(k,l). How this property can be used? You must build all the xor sums (here + is used) of ciphertext blocks C(i,j)+C(k,l) = P(i,j)+AES(Key,CV(i,j))+P(k,l)+AES(Key,CV(k,l)) and test all this sums by statistical criteria's whether is C(i,j)+C(k,l) = P(i,j)+P(k,l) because of AES(Key, CV(i,j)) = AES(Key, CV(k,l)) for any (i,j) != (k,l). When you find such a pair of ciphertext blocks you get information about the plaintexts P(i,j) and P(k,l). I presume this attack is not applicable, in difference to the birthday attack by CBC where you can easy recognize identical ciphertext blocks and use this for the attack. Best regards Klaus F. Helbig VP Engineering Zyfer, Inc. (714) 780 7134 [mailto: kfh@zyfer.com] From owner-ipsec@lists.tislabs.com Fri Jul 26 07:33:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QEXJw00982; Fri, 26 Jul 2002 07:33:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13320 Fri, 26 Jul 2002 09:51:10 -0400 (EDT) From: "David A. Mcgrew" To: "Klaus Helbig" Cc: Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Fri, 26 Jul 2002 07:04:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <6F0AA176DA68704884B7507AE6907E18091F4C@snake012.odetics.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Klaus, thanks for your comments, more inline: > -----Original Message----- > From: Klaus Helbig [mailto:kfh@zyfer.com] > Sent: Thursday, July 25, 2002 2:46 PM > To: 'mcgrew@cisco.com' > Cc: 'ipsec@lists.tislabs.com' > Subject: re: draft-ietf-ipsec-ciph-aes-ctr-00.txt > > > > David, > > yes, I agree with you, I can not see any reason to use an external IV for > AES CTR if algorithms easy can be defined for internal building > of IV's with > ESP sequence number and SPI. The only cryptographic requirement for the > sequence of IV's is, that all the counter values, derived from > all the IV's > over all the ESP packets, transformed by AES, are different as long as one > fixed key is used. that's right. Additionally, some additional strength against attacks which rely on precomputation of a database to use during the attack stage can be gained by having the part of the counter be secret. > > Or more mathematical: > > Assume IV(i) with i=1,2,... is the sequence of IV's being used for the > sequence of ESP packets ESP(i) with i=1,2,... and M is the maximal number > of blocks of block size 128 bit allowed in an ESP packet. Assume CV(i,j) > with j=1,2,...,M is the sequence of counter values for the ESP packet > ESP(i), derived from IV(i) for i=1,2,.... The requirement then is for each > fixed key > > CV( i, j ) != CV( k, l ) > > for all ( i, j ) != ( k, l ) with (i,k > 0), (0 < j,l <= M). > > > Might I'm wrong but I think no reason exists to state "that no more than > 2^64 blocks of block size 128 bits should be encrypted with any fixed key" > as long as the requirement above is fulfilled. The limitation is necessary in order to ensure that the keystream generated by counter mode is indistinguishable from random. This is important because indistinguishability is the only practical definition of confidentiality. (Other definitions would require assumptions about the plaintext source and/or the attacker.) The best analysis of the security of counter mode, from which this limitation can be derived, is the paper of Bellare et. al., "A Concrete Security Treatment of Symmetric Encryption" (online at http://www.cs.ucsd.edu/users/mihir/papers/sym-enc.html). In this work, counter mode is described in the XOR and CTR ciphers. The limitation can be derived by using Theorems 11 and 13, setting parameters so that the advantage is about one, then solving for the number of known plaintexts. (Please note that those theorems assume that the encryption function is a pseudorandom function (PRF), not a pseudorandom permutation (PRP) like AES. To apply that analysis to a PRP, it's necessary to apply Proposition 8 from that paper.) > What means > birthday attack in > connection to the counter mode? I guess it means following. When more than > 2^64 blocks have been encrypted with any fixed key then with higher > probability exist equal block keys > > AES(Key, CV(i,j)) = AES(Key, CV(k,l)) for any (i,j) != (k,l) > > to encrypt the different plaintext blocks P(i,j) and P(k,l). > > How this property can be used? > You must build all the xor sums (here + is used) of ciphertext blocks > > C(i,j)+C(k,l) = P(i,j)+AES(Key,CV(i,j))+P(k,l)+AES(Key,CV(k,l)) > > and test all this sums by statistical criteria's whether is > > C(i,j)+C(k,l) = P(i,j)+P(k,l) > > because of > > AES(Key, CV(i,j)) = AES(Key, CV(k,l)) for any (i,j) != (k,l). > > When you find such a pair of ciphertext blocks you get > information about the > plaintexts P(i,j) and P(k,l). Yes, it's hard to describe a simple practical attack against counter mode which applies when the block-limit is not respected. I've thought of one, but Scott Fluhrer tells me that it seems contrived :-) > > I presume this attack is not applicable, in difference to the birthday > attack by CBC where you can easy recognize identical ciphertext blocks and > use this for the attack. That's right. Both counter mode and CBC are distinguishable after about 2^64 blocks. But if that limit is not respected, the attacks against CBC appear to be far more feasible and damaging than those against counter mode. David > > > Best regards > > Klaus F. Helbig > VP Engineering > Zyfer, Inc. > (714) 780 7134 > [mailto: kfh@zyfer.com] > > > > > From owner-ipsec@lists.tislabs.com Fri Jul 26 10:25:12 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QHPBw10014; Fri, 26 Jul 2002 10:25:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13618 Fri, 26 Jul 2002 12:32:29 -0400 (EDT) X-mProtect: <200207261645> Nokia Silicon Valley Messaging Protection Message-ID: <3D417CBB.2AB20AD8@iprg.nokia.com> Date: Fri, 26 Jul 2002 09:45:47 -0700 From: Mukesh Gupta Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ospf@discuss.microsoft.com, ipsec@lists.tislabs.com CC: nmelam@iprg.nokia.com Subject: Draft on providing Authentication/Confidentiality to OSPFv3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, We have submitted the following internet draft on providing Authentication/Confidentiality to OSPFv3 using IPsec. Version 01 of the draft is available at http://www.ietf.org/internet-drafts/draft-gupta-ospf-ospfv3-auth-01.txt We would highly appreciate comments/suggestions from everyone. Thanks. Mukesh & Suresh From owner-ipsec@lists.tislabs.com Fri Jul 26 10:39:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QHdXw10243; Fri, 26 Jul 2002 10:39:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13657 Fri, 26 Jul 2002 12:55:44 -0400 (EDT) X-Delivered-For: X-mProtect: <200207261709> Nokia Silicon Valley Messaging Protection Message-ID: <3D41824C.A571A674@iprg.nokia.com> Date: Fri, 26 Jul 2002 10:09:32 -0700 From: Mukesh Gupta Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Draft on providing Authentication/Confidentiality to OSPFv3 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, We have submitted the following internet draft on providing Authentication/Confidentiality to OSPFv3 using IPsec. Version 01 of the draft is available at http://www.ietf.org/internet-drafts/draft-gupta-ospf-ospfv3-auth-01.txt We would highly appreciate comments/suggestions from everyone. Thanks. Mukesh & Suresh From owner-ipsec@lists.tislabs.com Fri Jul 26 12:56:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QJuHw16931; Fri, 26 Jul 2002 12:56:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13820 Fri, 26 Jul 2002 15:05:54 -0400 (EDT) From: "Housley, Russ" To: Ramana Yarlagadda Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020726151631.02129768@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 26 Jul 2002 15:19:24 -0400 Subject: Re: Two AES encryption modes? In-Reply-To: <4.3.2.7.1.20020724125917.00e45bb0@golf.cpgdesign.analog.co m> References: <200207241208.IAA02182@ietf.org> <200207241208.IAA02182@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ramana: In a separate I-D, I plan to post a specification for using AES-CCM. For those that are interested, you can learn more about AES-CCM at http://csrc.nist.gov/encryption/modes/proposedmodes/ccm/ccm.pdf. Russ At 01:00 PM 7/24/2002 -0700, Ramana Yarlagadda wrote: >Hi all > >What about the combined modes that AES support? > >-thanks >-ramana From owner-ipsec@lists.tislabs.com Fri Jul 26 13:26:34 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QKQXw20250; Fri, 26 Jul 2002 13:26:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13882 Fri, 26 Jul 2002 15:41:06 -0400 (EDT) Message-Id: <4.3.2.7.1.20020726124924.00c4f830@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Jul 2002 12:54:09 -0700 To: "Housley, Russ" From: Ramana Yarlagadda Subject: Re: Two AES encryption modes? Cc: ipsec@lists.tislabs.com In-Reply-To: <5.1.0.14.2.20020726151631.02129768@exna07.securitydynamics .com> References: <4.3.2.7.1.20020724125917.00e45bb0@golf.cpgdesign.analog.co m> <200207241208.IAA02182@ietf.org> <200207241208.IAA02182@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Russ Thanks for your reply. We are developing AISIC solutions for Security applications and as part of this we implement Cryptographic algorithms in the hardware. ESP v2 talks about the combined mode algorithms and couldn't get any information about the algorithms that we must support for this. Can you throw some light on this. -cheers -ramana At 03:19 PM 7/26/02 -0400, Housley, Russ wrote: >Ramana: > >In a separate I-D, I plan to post a specification for using AES-CCM. > >For those that are interested, you can learn more about AES-CCM at >http://csrc.nist.gov/encryption/modes/proposedmodes/ccm/ccm.pdf. > >Russ > > >At 01:00 PM 7/24/2002 -0700, Ramana Yarlagadda wrote: >>Hi all >> >>What about the combined modes that AES support? >> >>-thanks >>-ramana From owner-ipsec@lists.tislabs.com Fri Jul 26 13:40:32 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QKeWw21191; Fri, 26 Jul 2002 13:40:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13947 Fri, 26 Jul 2002 15:56:51 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Fri, 26 Jul 2002 16:10:12 -0400 To: "David A. Mcgrew" From: Stephen Kent Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David, >On the subject of packet expansion, the draft requires the use of an >explicit IV that is eight bytes long and states that this overhead is >acceptable. I disagree. Counter mode has the opportunity to provide >zero expansion, and at Cisco we've regarded this property as >important. The consumption of eight bytes per packet can have a >significant impact on bandwidth, especially for protocols with short >packets like voice over IP (RFC 1889). For example, RTP with the >G.729 codec (as is commonly used) carries only twenty bytes of data >per packet. This protocol is often used with link-layer header >compression over WAN links (e.g. RFC2508); these compression methods >are quite efficient, making the bandwidth degradation due to >uncompressible fields (like the explicit IV) pronounced. I am surprised by your comment "at Cisco we've regarded this ..." This is the IETF and as you should know, corporate endorsements for technical positions are frowned upon. You should argue for this suggested change on its merits, not on the basis of a corporate position. I also am surprised that you cite a 20-byte "packet" size for RTP as an example. The 20 byte size makes an 8-byte IV seem very large indeed. But the 20-byte size is misleading, at best. Do these packets have no IP header? How about a UDP header. How about an ESP header & authentication trailer? How about the need to pad the ESP payload to a 4 byte boundary, which in this case adds 4 bytes to the payload? By the time you add all of these parts of the overall packet to the original 20-byte payload, the 8-byte IV is not so big an overhead anymore. Either your arithmetic is very sloppy, or you are being disingenuous. >I think that the zero-expansion property is important enough that I >want to comment on the points that the rationale presents in favor of >an explicit IV: > > Point 4. "The assignment of the per-packet counter block value > needs to be inside the assurance boundary. Some implementations > assign the sequence number inside the assurance boundary, but others > do not." What implementations maintain the ESP sequence number > outside of the security perimeter? Cisco does not do this, nor do > any of the several of crypto hardware suppliers that we use. This persistent reference to Cisco positions is annoying, at best. Cisco is but one of many implementors of IPsec. As we have discussed in the e-mail among the group working on this counter mode draft, any implementation that needs to mux an SA over multiple crypto chips needs to maintain the sequence number off chip. Apparently Cisco has chosen to offer only low assurance IPsec products, e.g,. FIPS level 2 at most, so the security perimeter is very large and thus the sequence number can be maintained within that boundary. But, to impose this assurance-limiting architecture on vendors who might wish to offer higher security implementations is inappropriate. > Counter mode ESP would be far simpler and more bandwidth efficient > if the ESP sequence number were used as the per-packet counter > value. In addition, other cryptographic mechanisms that require a > nonce can use the sequence number for that purpose, if we are > allowed to assume that the sequence number is actually unique. > These mechanisms include ciphers like SEAL and Wegman-Carter based > MACs like MMH. It's worth noting that we've implemented SEAL > encryption using ESP, as described in the Stream Cipher ESP; this > draft is now expired, but went through three revisions without this > point about the sequence number and assurance boundary being raised. > (The old draft is online at > www.mindspring.com/~dmcgrew/draft-mcgrew-ipsec-scesp-02.txt if > you're interested, and we'd be fine with re-issuing the draft were > there is interest from other implementers.) We're not discussing other algorithms or mode here, so none of this seems relevant to the discussion at hand. Also, if one choose to use sequence numbers for the per-packet counter inputs, I think it hard to argue that the result is far more complex that reusing the ESP sequence numbers for a function they were not designed to accommodate (from a security perspective). > Point 2. "Adders are simple and straightforward to implement, but > due to carries, they do not execute in constant time. LSFRs offer > an alternative that executes in constant time." However, the > per-block increment operation is far more time critical than the > per-packet increment operation! Since the block counter is a > monotonically increasing integer, and it's presumably fast enough, > it's hard to see how the fact cited in the draft supports the use of > LFSRs for the per-packet field. Your analysis ignores the difference in the size of the two counter values. The per-packet counter is 64 bits long, while the intra-packet counter is 32 bits, and at most 28 of those bits will ever be used. Thus the propagation times are not the same. However, you are correct in noting that the use of a LFSR would yield even greater benefit if it were employed to compute the intra-packet values. In the spirit of compromise, a spirit you have not shown in this activity, I did not press for using an LFSR for both values. The proposed compromise approach that Russ has documented allows designers more freedom, by allowing them to adopt any mechanism they wish for generating the per-packet counter input (subject to the usual uniqueness constraints) and does not require sender and receiver to negotiate a mechanism for intra-packet counter value generation. > Point 1. "... there is no advantage to selecting a mechanism that > allows the decryptor to determine whether counter block values > collide. Damage from the collision is done, whether the decryptor > detects it or not." Yes, but the detection of a malfunctioning ESP > sender could enable an administrator to shut off the errant device. > Either the ESP CTR receiver or a passive security monitoring device > such as a network IDS system can detect ESP sequence number re-use. > When is the delayed detection of the failure of a security system > worse than no detection? > >I don't disagree with Point 3 and Points 5 and 6 follow from the >others. > >I would be surprised if other implementers in the WG favored the use >of an unspecified explicit IV over the use of the sequence number as >an implicit IV. At any rate, I think we've discussed the points well >enough to allow others in the WG to chime in. You use the phrase "unspecified IV" as though it were a bad thing. In reality this approach, which Russ suggested, allows a designer to use whatever IV generation method works best in his/her context, without needing to get agreement among all designers, and without needing to coordinate with the peer implementation. Since it is ultimately the responsibility of the sender to ensure uniqueness for the per-packet value, this approach preserves the greatest flexibility. >On to other topics. The draft says in Section 6 that AES CTR MUST NOT >be used with statically configured keys. I certainly agree that this >is a good thing. However, RFC2401 requires implementations to support >such keys, saying "This document requires support for both manual and >automatic distribution of keys." Perhaps that RFC means that manual >keying be provided only for some ciphers (the mandatory to implement >ones?). At any rate, it would be good for the WG to decide what is >meant and to document it somewhere. (The Stream Cipher ESP draft hit >this same issue). Any algorithm/mode document can restrict support re manual keying when it is inappropriate for the algorithm/mode. We will clarify that point in 2401bis. I think it's worth pointing out to the WG that you and I disagreed on how to approach counter value generation from the beginning. You persuaded Russ to join the small group working on a counter mode draft, to contribute to the discussion. After coming up to speed on the issues, Russ proposed a compromise to the group, which everyone else agreed to. Now, since you didn't persuade Russ and the rest of group, you have taken the debate to the list, presenting arguments that are distorted and trying to invoke the imprimatur of your employer in an effort to persuade the WG to adopt your proposal. So much for compromise. Steve From owner-ipsec@lists.tislabs.com Fri Jul 26 14:18:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QLITw22332; Fri, 26 Jul 2002 14:18:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14023 Fri, 26 Jul 2002 16:28:09 -0400 (EDT) From: "Housley, Russ" To: Ramana Yarlagadda Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020726163827.033bc558@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 26 Jul 2002 16:41:44 -0400 Subject: Re: Two AES encryption modes? In-Reply-To: <4.3.2.7.1.20020726124924.00c4f830@golf.cpgdesign.analog.co m> References: <5.1.0.14.2.20020726151631.02129768@exna07.securitydynamics .com> <4.3.2.7.1.20020724125917.00e45bb0@golf.cpgdesign.analog.co m> <200207241208.IAA02182@ietf.org> <200207241208.IAA02182@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As one of its authors, I advocate CCM, which is unencumbered by patents. There are other alternatives, but you need to be careful of their patent status. You can find information about several choices at: http://csrc.nist.gov/encryption/modes/proposedmodes Russ At 12:54 PM 7/26/2002 -0700, Ramana Yarlagadda wrote: >Hi, Russ > >Thanks for your reply. We are developing AISIC solutions for Security >applications and as part of this we implement Cryptographic algorithms in >the hardware. > >ESP v2 talks about the combined mode algorithms and couldn't get any >information about the algorithms that we must support for this. > >Can you throw some light on this. > >-cheers >-ramana >At 03:19 PM 7/26/02 -0400, Housley, Russ wrote: >>Ramana: >> >>In a separate I-D, I plan to post a specification for using AES-CCM. >> >>For those that are interested, you can learn more about AES-CCM at >>http://csrc.nist.gov/encryption/modes/proposedmodes/ccm/ccm.pdf. >> >>Russ >> >> >>At 01:00 PM 7/24/2002 -0700, Ramana Yarlagadda wrote: >>>Hi all >>> >>>What about the combined modes that AES support? >>> >>>-thanks >>>-ramana From owner-ipsec@lists.tislabs.com Fri Jul 26 14:53:54 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QLrsw22886; Fri, 26 Jul 2002 14:53:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14081 Fri, 26 Jul 2002 17:03:14 -0400 (EDT) Message-Id: <4.3.2.7.1.20020726134302.00b6af00@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Jul 2002 14:15:45 -0700 To: "Housley, Russ" From: Ramana Yarlagadda Subject: Re: Two AES encryption modes? Cc: ipsec@lists.tislabs.com In-Reply-To: <5.1.0.14.2.20020726163827.033bc558@exna07.securitydynamics .com> References: <4.3.2.7.1.20020726124924.00c4f830@golf.cpgdesign.analog.co m> <5.1.0.14.2.20020726151631.02129768@exna07.securitydynamics .com> <4.3.2.7.1.20020724125917.00e45bb0@golf.cpgdesign.analog.co m> <200207241208.IAA02182@ietf.org> <200207241208.IAA02182@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Russ I have gone through your document. well but the question here is what is it IETF considering as combined mdoe algorithms. Like you said out of all the algorithms that i know CMM is is the only one which is not patented and the basical algorithms used in that are already approved by NIST. So i am trying to get more information before i consider this. -thanks -ramana At 04:41 PM 7/26/02 -0400, Housley, Russ wrote: >As one of its authors, I advocate CCM, which is unencumbered by >patents. There are other alternatives, but you need to be careful of >their patent status. You can find information about several choices at: > http://csrc.nist.gov/encryption/modes/proposedmodes > > >Russ > > >At 12:54 PM 7/26/2002 -0700, Ramana Yarlagadda wrote: >>Hi, Russ >> >>Thanks for your reply. We are developing AISIC solutions for Security >>applications and as part of this we implement Cryptographic algorithms in >>the hardware. >> >>ESP v2 talks about the combined mode algorithms and couldn't get any >>information about the algorithms that we must support for this. >> >>Can you throw some light on this. >> >>-cheers >>-ramana >>At 03:19 PM 7/26/02 -0400, Housley, Russ wrote: >>>Ramana: >>> >>>In a separate I-D, I plan to post a specification for using AES-CCM. >>> >>>For those that are interested, you can learn more about AES-CCM at >>>http://csrc.nist.gov/encryption/modes/proposedmodes/ccm/ccm.pdf. >>> >>>Russ >>> >>> >>>At 01:00 PM 7/24/2002 -0700, Ramana Yarlagadda wrote: >>>>Hi all >>>> >>>>What about the combined modes that AES support? >>>> >>>>-thanks >>>>-ramana From owner-ipsec@lists.tislabs.com Fri Jul 26 15:31:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QMVfw23548; Fri, 26 Jul 2002 15:31:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14115 Fri, 26 Jul 2002 17:33:17 -0400 (EDT) From: "Housley, Russ" To: Ramana Yarlagadda Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020726174635.0340e910@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 26 Jul 2002 17:46:59 -0400 Subject: Re: Two AES encryption modes? In-Reply-To: <4.3.2.7.1.20020726134302.00b6af00@golf.cpgdesign.analog.co m> References: <5.1.0.14.2.20020726163827.033bc558@exna07.securitydynamics .com> <4.3.2.7.1.20020726124924.00c4f830@golf.cpgdesign.analog.co m> <5.1.0.14.2.20020726151631.02129768@exna07.securitydynamics .com> <4.3.2.7.1.20020724125917.00e45bb0@golf.cpgdesign.analog.co m> <200207241208.IAA02182@ietf.org> <200207241208.IAA02182@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ramana: NIST has not approved any combined modes yet. Russ At 02:15 PM 7/26/2002 -0700, Ramana Yarlagadda wrote: >Hi, Russ > >I have gone through your document. well but the question here is what is >it IETF considering as combined mdoe algorithms. > >Like you said out of all the algorithms that i know CMM is is the only one >which is not patented and the basical algorithms used in that are already >approved by NIST. So i am trying to get more information before i consider >this. > >-thanks >-ramana >At 04:41 PM 7/26/02 -0400, Housley, Russ wrote: >>As one of its authors, I advocate CCM, which is unencumbered by >>patents. There are other alternatives, but you need to be careful of >>their patent status. You can find information about several choices at: >> http://csrc.nist.gov/encryption/modes/proposedmodes >> >> >>Russ >> >> >>At 12:54 PM 7/26/2002 -0700, Ramana Yarlagadda wrote: >>>Hi, Russ >>> >>>Thanks for your reply. We are developing AISIC solutions for Security >>>applications and as part of this we implement Cryptographic algorithms >>>in the hardware. >>> >>>ESP v2 talks about the combined mode algorithms and couldn't get any >>>information about the algorithms that we must support for this. >>> >>>Can you throw some light on this. >>> >>>-cheers >>>-ramana >>>At 03:19 PM 7/26/02 -0400, Housley, Russ wrote: >>>>Ramana: >>>> >>>>In a separate I-D, I plan to post a specification for using AES-CCM. >>>> >>>>For those that are interested, you can learn more about AES-CCM at >>>>http://csrc.nist.gov/encryption/modes/proposedmodes/ccm/ccm.pdf. >>>> >>>>Russ >>>> >>>> >>>>At 01:00 PM 7/24/2002 -0700, Ramana Yarlagadda wrote: >>>>>Hi all >>>>> >>>>>What about the combined modes that AES support? >>>>> >>>>>-thanks >>>>>-ramana From owner-ipsec@lists.tislabs.com Fri Jul 26 15:32:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QMWFw23566; Fri, 26 Jul 2002 15:32:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14133 Fri, 26 Jul 2002 17:44:20 -0400 (EDT) Message-Id: <200207262157.g6QLvXZs005900@thunk.east.sun.com> From: Bill Sommerfeld To: Dan McDonald cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Two AES encryption modes? In-Reply-To: Your message of "Thu, 25 Jul 2002 12:18:01 EDT." <200207251618.g6PGI1wE024672@kebe.east.sun.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 26 Jul 2002 17:57:33 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > I'm pretty sure that we already decided that SOI would treat AES-128 and > > AES-256 as two entirely different ciphers as well. > > No argument about combinatorics. > > WHAT!?! We already have Blowfish, which is variable key-sized, even though > 2451 says its default is 128. We shouldn't need to break existing semantics > for AES! "what Dan said". While it might have been cleaner to define separate DOI algorithm values for each supported keysize, that's not what was done in IKEv1. From owner-ipsec@lists.tislabs.com Fri Jul 26 15:48:27 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QMmQw23754; Fri, 26 Jul 2002 15:48:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14181 Fri, 26 Jul 2002 17:59:29 -0400 (EDT) Message-Id: <4.3.2.7.1.20020726151152.00db6b70@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Jul 2002 15:12:12 -0700 To: "Housley, Russ" From: Ramana Yarlagadda Subject: Re: Two AES encryption modes? Cc: ipsec@lists.tislabs.com In-Reply-To: <5.1.0.14.2.20020726174635.0340e910@exna07.securitydynamics .com> References: <4.3.2.7.1.20020726134302.00b6af00@golf.cpgdesign.analog.co m> <5.1.0.14.2.20020726163827.033bc558@exna07.securitydynamics .com> <4.3.2.7.1.20020726124924.00c4f830@golf.cpgdesign.analog.co m> <5.1.0.14.2.20020726151631.02129768@exna07.securitydynamics .com> <4.3.2.7.1.20020724125917.00e45bb0@golf.cpgdesign.analog.co m> <200207241208.IAA02182@ietf.org> <200207241208.IAA02182@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi , Russ Yes , but what i am saying is CCM is using the NIST approved algorithms as basic building blocks -thanks -ramana At 05:46 PM 7/26/02 -0400, Housley, Russ wrote: >Ramana: > >NIST has not approved any combined modes yet. > >Russ > > >At 02:15 PM 7/26/2002 -0700, Ramana Yarlagadda wrote: >>Hi, Russ >> >>I have gone through your document. well but the question here is what is >>it IETF considering as combined mdoe algorithms. >> >>Like you said out of all the algorithms that i know CMM is is the only >>one which is not patented and the basical algorithms used in that are >>already approved by NIST. So i am trying to get more information before i >>consider this. >> >>-thanks >>-ramana >>At 04:41 PM 7/26/02 -0400, Housley, Russ wrote: >>>As one of its authors, I advocate CCM, which is unencumbered by >>>patents. There are other alternatives, but you need to be careful of >>>their patent status. You can find information about several choices at: >>> http://csrc.nist.gov/encryption/modes/proposedmodes >>> >>> >>>Russ >>> >>> >>>At 12:54 PM 7/26/2002 -0700, Ramana Yarlagadda wrote: >>>>Hi, Russ >>>> >>>>Thanks for your reply. We are developing AISIC solutions for Security >>>>applications and as part of this we implement Cryptographic algorithms >>>>in the hardware. >>>> >>>>ESP v2 talks about the combined mode algorithms and couldn't get any >>>>information about the algorithms that we must support for this. >>>> >>>>Can you throw some light on this. >>>> >>>>-cheers >>>>-ramana >>>>At 03:19 PM 7/26/02 -0400, Housley, Russ wrote: >>>>>Ramana: >>>>> >>>>>In a separate I-D, I plan to post a specification for using AES-CCM. >>>>> >>>>>For those that are interested, you can learn more about AES-CCM at >>>>>http://csrc.nist.gov/encryption/modes/proposedmodes/ccm/ccm.pdf. >>>>> >>>>>Russ >>>>> >>>>> >>>>>At 01:00 PM 7/24/2002 -0700, Ramana Yarlagadda wrote: >>>>>>Hi all >>>>>> >>>>>>What about the combined modes that AES support? >>>>>> >>>>>>-thanks >>>>>>-ramana From owner-ipsec@lists.tislabs.com Fri Jul 26 17:07:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6R07ww27195; Fri, 26 Jul 2002 17:07:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA14344 Fri, 26 Jul 2002 19:17:00 -0400 (EDT) Message-Id: <200207262232.g6QMVfuV005259@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Two AES encryption modes? In-reply-to: Your message of "25 Jul 2002 15:14:30 EDT." <003001c2340f$81ec5c60$d16fe640@ca.alcatel.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 26 Jul 2002 18:31:41 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Andrew" == Andrew Krywaniuk writes: Andrew> Not necessarily. Take a look at the list I sent earlier: Andrew> IETF-ipsec high security '02 (chosen by WG, published in an RFC) Andrew> US DoD FIPS standard '02 (chosen by a large customer, listed as a Andrew> requirement) Andrew> VPNC default '02 (chosen by a vendor consortium, published on their Andrew> website) Andrew> JoeBillyBob JBB's ciphersuite '02 (chosen by an individual, distributed Andrew> to his friends) Andrew> Only the first ciphersuite needs to be published in an RFC. The other ones Andrew> are published on the DoD, VPNC, and joebillybob.com websites/technical Andrew> publications respectively. If you use GUI ciphersuites there is no IANA Andrew> registry, so there doesn't need to be a comprehensive list of all the Andrew> possible ciphersuites. There will nothing to help interoperability. It certainly won't help anyone get good support from hardware vendors. We are just wasting bits on EVERY wire to avoid writing what will be perhaps a dozen real drafts. After the first 6 or so submissions of AES-256/MD2 (not even HMAC), people will get bored with the concept. The only GUI ciphersuites used will be the IETF specified ones, and we'll have hundreds of lines of code in SOI that never get tested, except when Tero Kivinen initiates to the broadcast address at bakeoffs. ] Internet Security. Have encryption, will travel |1 Fish/2 Fish [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F [ ]mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [ ] At the far end of some dark fiber - wait that's dirt! |for everyone [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPUHNyoqHRg3pndX9AQHMTwQA7l9UUAbyhdgOFrbE31XCTrb/K49D2KPE uTT/YTktx8WXgs3ZJiZqcQcsanl9b7NeUQB0pWqOzzvcadUOa/1XHp0FrHD9XU1V 3OUg9Ww96qP6kGMznlAI6TQQpzgm12O4biNWWLQXNXMIXaLwsbeNcP8fzjEjIg9+ 0qOp83ZRU8Q= =ilr+ -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Jul 26 18:00:33 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6R10Ww27963; Fri, 26 Jul 2002 18:00:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA14495 Fri, 26 Jul 2002 20:16:17 -0400 (EDT) From: "David A. Mcgrew" To: "Stephen Kent" , Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Fri, 26 Jul 2002 17:30:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, I would be grateful if you would neither speculate on my personal motives nor cast aspersions on my employer. I refuse to be cast as a corporate shill for presenting technical arguments and asking for WG input. This discussion doesn't need to be adversarial. Let's just make sure that we've made our technical arguments clear to WG and leave it at that. Below I have responded to the technical comments: > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Friday, July 26, 2002 1:10 PM > To: David A. Mcgrew > Cc: ipsec@lists.tislabs.com > Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt > > > David, > > > > >On the subject of packet expansion, the draft requires the use of an > >explicit IV that is eight bytes long and states that this overhead is > >acceptable. I disagree. Counter mode has the opportunity to provide > >zero expansion, and at Cisco we've regarded this property as > >important. The consumption of eight bytes per packet can have a > >significant impact on bandwidth, especially for protocols with short > >packets like voice over IP (RFC 1889). For example, RTP with the > >G.729 codec (as is commonly used) carries only twenty bytes of data > >per packet. This protocol is often used with link-layer header > >compression over WAN links (e.g. RFC2508); these compression methods > >are quite efficient, making the bandwidth degradation due to > >uncompressible fields (like the explicit IV) pronounced. > > I am surprised by your comment "at Cisco we've regarded this ..." > This is the IETF and as you should know, corporate endorsements for > technical positions are frowned upon. You should argue for this > suggested change on its merits, not on the basis of a corporate > position. > > I also am surprised that you cite a 20-byte "packet" size for RTP as > an example. The 20 byte size makes an 8-byte IV seem very large > indeed. But the 20-byte size is misleading, at best. Do these packets > have no IP header? How about a UDP header. How about an ESP header & > authentication trailer? How about the need to pad the ESP payload to > a 4 byte boundary, which in this case adds 4 bytes to the payload? By > the time you add all of these parts of the overall packet to the > original 20-byte payload, the 8-byte IV is not so big an overhead > anymore. Either your arithmetic is very sloppy, or you are being > disingenuous. I stand by what I said: eight bytes is a significant bandwidth hit, especially for short packets, especially when header compression is used. As I said, the 20 bytes cited in the example is "data per packet". Headers will add a significant length, though this length can be reduced considerably in some cases through the use of header compression. The combination of short packets and header compression is common for VoIP. > > >I think that the zero-expansion property is important enough that I > >want to comment on the points that the rationale presents in favor of > >an explicit IV: > > > > Point 4. "The assignment of the per-packet counter block value > > needs to be inside the assurance boundary. Some implementations > > assign the sequence number inside the assurance boundary, but others > > do not." What implementations maintain the ESP sequence number > > outside of the security perimeter? Cisco does not do this, nor do > > any of the several of crypto hardware suppliers that we use. > > This persistent reference to Cisco positions is annoying, at best. > Cisco is but one of many implementors of IPsec. As we have discussed > in the e-mail among the group working on this counter mode draft, > any implementation that needs to mux an SA over multiple crypto chips > needs to maintain the sequence number off chip. I do not believe that this is a real problem, nor does anyone else with whom I have spoken, including hardware engineers with whom I have worked on high-speed AES counter mode designs. If you have a detailed technical analysis that you can provide, I would be happy to read it. Does our disagreement here come down to the fact that other implementers are not multiplexing keys across chips in their high speed designs? > Apparently Cisco has > chosen to offer only low assurance IPsec products, e.g,. FIPS level 2 > at most, so the security perimeter is very large and thus the > sequence number can be maintained within that boundary. But, to > impose this assurance-limiting architecture on vendors who might wish > to offer higher security implementations is inappropriate. What ESP implementations don't maintain the sequence number within the security perimeter? I am not aware of any. If you are, please let us know. > > > Counter mode ESP would be far simpler and more bandwidth efficient > > if the ESP sequence number were used as the per-packet counter > > value. In addition, other cryptographic mechanisms that require a > > nonce can use the sequence number for that purpose, if we are > > allowed to assume that the sequence number is actually unique. > > These mechanisms include ciphers like SEAL and Wegman-Carter based > > MACs like MMH. It's worth noting that we've implemented SEAL > > encryption using ESP, as described in the Stream Cipher ESP; this > > draft is now expired, but went through three revisions without this > > point about the sequence number and assurance boundary being raised. > > (The old draft is online at > > www.mindspring.com/~dmcgrew/draft-mcgrew-ipsec-scesp-02.txt if > > you're interested, and we'd be fine with re-issuing the draft were > > there is interest from other implementers.) > > We're not discussing other algorithms or mode here, so none of this > seems relevant to the discussion at hand. On the contrary, this is the central technical point to our disagreement. I maintain that it is important for an ESP implementation to be able to provide sequence numbers that are actually unique. This property is useful in counter mode and lots of other cryptographic mechanisms that are worth using in ESP. I'm puzzled by the claim that I shouldn't trust the sequence number. If cryptographic mechanisms can't trust the ESP sequence numbers to be unique, shouldn't this fact be reflected in the RFCs? And what can a sequence number be trusted for? > Also, if one choose to use > sequence numbers for the per-packet counter inputs, I think it hard > to argue that the result is far more complex that reusing the ESP > sequence numbers for a function they were not designed to accommodate > (from a security perspective). True enough, but an implementation which did that would need to maintain the sequence number within the security perimeter. > > > Point 2. "Adders are simple and straightforward to implement, but > > due to carries, they do not execute in constant time. LSFRs offer > > an alternative that executes in constant time." However, the > > per-block increment operation is far more time critical than the > > per-packet increment operation! Since the block counter is a > > monotonically increasing integer, and it's presumably fast enough, > > it's hard to see how the fact cited in the draft supports the use of > > LFSRs for the per-packet field. > > Your analysis ignores the difference in the size of the two counter > values. The per-packet counter is 64 bits long, while the > intra-packet counter is 32 bits, and at most 28 of those bits will > ever be used. Thus the propagation times are not the same. I stand by my analysis. I do not believe that a 64-bit integer increment function has a significant computational cost relative to that of an evaluation of the AES cipher. I would be surprised and very interested if you could cite work indicating otherwise. > > However, you are correct in noting that the use of a LFSR would yield > even greater benefit if it were employed to compute the intra-packet > values. In the spirit of compromise, a spirit you have not shown in > this activity, I did not press for using an LFSR for both values. The > proposed compromise approach that Russ has documented allows > designers more freedom, by allowing them to adopt any mechanism they > wish for generating the per-packet counter input (subject to the > usual uniqueness constraints) and does not require sender and > receiver to negotiate a mechanism for intra-packet counter value > generation. > > > > Point 1. "... there is no advantage to selecting a mechanism that > > allows the decryptor to determine whether counter block values > > collide. Damage from the collision is done, whether the decryptor > > detects it or not." Yes, but the detection of a malfunctioning ESP > > sender could enable an administrator to shut off the errant device. > > Either the ESP CTR receiver or a passive security monitoring device > > such as a network IDS system can detect ESP sequence number re-use. > > When is the delayed detection of the failure of a security system > > worse than no detection? > > > >I don't disagree with Point 3 and Points 5 and 6 follow from the > >others. > > > >I would be surprised if other implementers in the WG favored the use > >of an unspecified explicit IV over the use of the sequence number as > >an implicit IV. At any rate, I think we've discussed the points well > >enough to allow others in the WG to chime in. > > You use the phrase "unspecified IV" as though it were a bad thing. In > reality this approach, which Russ suggested, allows a designer to use > whatever IV generation method works best in his/her context, without > needing to get agreement among all designers, and without needing to > coordinate with the peer implementation. Since it is ultimately the > responsibility of the sender to ensure uniqueness for the per-packet > value, this approach preserves the greatest flexibility. Sure, it's flexible. "Conservative in what you send, liberal in what you accept" is a good way to design network gear. However, is it worth eight bytes of packet expansion? I think that it's a question worth asking to the WG. > > >On to other topics. The draft says in Section 6 that AES CTR MUST NOT > >be used with statically configured keys. I certainly agree that this > >is a good thing. However, RFC2401 requires implementations to support > >such keys, saying "This document requires support for both manual and > >automatic distribution of keys." Perhaps that RFC means that manual > >keying be provided only for some ciphers (the mandatory to implement > >ones?). At any rate, it would be good for the WG to decide what is > >meant and to document it somewhere. (The Stream Cipher ESP draft hit > >this same issue). > > Any algorithm/mode document can restrict support re manual keying > when it is inappropriate for the algorithm/mode. We will clarify that > point in 2401bis. > > I think it's worth pointing out to the WG that you and I disagreed on > how to approach counter value generation from the beginning. True. > You > persuaded Russ to join the small group working on a counter mode > draft, to contribute to the discussion. After coming up to speed on > the issues, Russ proposed a compromise to the group, which everyone > else agreed to. Now, since you didn't persuade Russ and the rest of > group, you have taken the debate to the list, presenting arguments > that are distorted and trying to invoke the imprimatur of your > employer in an effort to persuade the WG to adopt your proposal. That's not my perception of events, but then let's stick to technical discussion. > > So much for compromise. > > Steve Given the fact that no requirements have been put forward for counter mode, I think that it is sensible to operate by identifying the tradeoffs and asking for input from the WG. David From owner-ipsec@lists.tislabs.com Sat Jul 27 11:18:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6RIIOw26728; Sat, 27 Jul 2002 11:18:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15679 Sat, 27 Jul 2002 13:22:33 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15682.55839.956567.462699@pkoning.akdesign.com> Date: Sat, 27 Jul 2002 13:36:31 -0400 From: Paul Koning To: ramana.yarlagadda@analog.com Cc: ipsec@lists.tislabs.com Subject: Re: Two AES encryption modes? References: <4.3.2.7.1.20020726134302.00b6af00@golf.cpgdesign.analog.co m> <5.1.0.14.2.20020726163827.033bc558@exna07.securitydynamics .com> <4.3.2.7.1.20020726124924.00c4f830@golf.cpgdesign.analog.co m> <5.1.0.14.2.20020726151631.02129768@exna07.securitydynamics .com> <4.3.2.7.1.20020724125917.00e45bb0@golf.cpgdesign.analog.co m> <200207241208.IAA02182@ietf.org> <4.3.2.7.1.20020726151152.00db6b70@golf.cpgdesign.analog.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Ramana" == Ramana Yarlagadda writes: Ramana> Hi , Russ Yes , but what i am saying is CCM is using the NIST Ramana> approved algorithms as basic building blocks Keep in mind that this doesn't in itself mean much. It's possible to build an insecure mode on top of a secure cipher -- or to use a mode that can be secure incorrectly, thereby making it insecure. paul From owner-ipsec@lists.tislabs.com Sat Jul 27 18:10:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6S1Anw11234; Sat, 27 Jul 2002 18:10:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA16074 Sat, 27 Jul 2002 20:12:13 -0400 (EDT) Message-Id: <200207272146.g6RLjTB6011793@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Two AES encryption modes? In-reply-to: Your message of "Fri, 26 Jul 2002 17:57:33 EDT." <200207262157.g6QLvXZs005900@thunk.east.sun.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 27 Jul 2002 17:45:29 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bill" == Bill Sommerfeld writes: Bill> "what Dan said". While it might have been cleaner to define separate Bill> DOI algorithm values for each supported keysize, that's not what was Bill> done in IKEv1. I didn't say it was done that way in IKEv1. Can we agree that what was done in IKEv1 was silly? ] Internet Security. Have encryption, will travel |1 Fish/2 Fish [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F [ ]mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [ ] At the far end of some dark fiber - wait that's dirt! |for everyone [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPUMUdoqHRg3pndX9AQF5vAP9FcKdfe0Ez85FDi4TPZt1VNagiJAObOdO TLf8LZIMMRaV7c0W+nvXb9qXpI6fFC7e3coaDZTkC15hpyU8glQ+Lf5JHiWGUXiM LjqUVeRslXIeHTfudtBCLla80sRJRZaXwe7A2nQFxmLoqzKi6j1gLQrtiw3QFaE1 BLkbsXgz6Sc= =2Vnj -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Jul 29 04:31:42 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TBVfw16052; Mon, 29 Jul 2002 04:31:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA18340 Mon, 29 Jul 2002 06:35:37 -0400 (EDT) Message-ID: <3D451D84.30E23BE5@eim.surrey.ac.uk> Date: Mon, 29 Jul 2002 11:48:36 +0100 From: Haitham Cruickshank Organization: CCSR X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com, msec@securemulticast.org Subject: Re: [MSEC] Re: new version of ESP ID References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-98.9 required=7.0 tests=DOUBLE_CAPSWORD,USER_IN_WHITELIST version=2.31 X-Scanner: exiscan *17Z850-0000GP-00*hxSSBznRRds* (SECM, UniS) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Everybody, I have attended the ipsec meeting at the ieft 54 meeting and Steve Kent has presented some interworking problems with IP multicast. Is it possible to start a discussion on how to solve such problems. I can see two major multicast problems: 1. Scalability: For very large groups (thousands of members) or very dynamic multicast groups (frequent join and leaves), having a single group controller might not scale well specially for re-keying problem (changing keys when members join or leave). If this problems is true, then we need to have a distributed group controller/controllers and this brings new problems which has been discussed in some previous emails. 2. Anti-relay procedures for multiple senders: Steve has pointed (quite rightly) the problem that anti-replay procedures (receivers keeping track of sequence numbers and sequence number windows) works OK for unicast or single source multicast. The potential problem is having unbounded number of senders, where the ipsec receivers (especially hardware implementations) have to track of sequence numbers and sequence number windows for each individual senders. In my personal opinion, the anti-replay should be switched off for multi senders. Of course, this will weaken the security system against DOS attacks. Can ipsec and msec people express opinion on how to solve these issues. Thanks. Haitham Stephen Kent wrote: > At 6:09 PM +0200 7/2/02, annelies.van_moffaert@alcatel.be wrote: > >Mark and Steve, > > > >I am not sure I completely understand your arguments. I would think that > >there is a difference between saying that > >1. IPsec can only be used to protect SSM or single-source multicast groups > >and > >2. When using IPsec to protect multicast traffic one should use a seperate > >SA per sender. > > > >In the second case there can be more than 1 sender allowed to send to the > >same group. Both legitimate senders and receivers should then e.g. > >authenticate to a common key server and the key server could create for > >each sender a seperate SA. Additionally the key server would push the SAs > >to the group of receivers. > > The second case would be consistent with the IPsec architecture. The > common key server needs to assign the SPIs uniquely for the multicast > group as well as provide keys to the group members. In this model, > each SA has just one authorized sender and so anti-replay can be > employed, and each receiver can use the SPD to constrain the source > address appropriately. But, the granularity of the source > authentication is still just the group, since each receiver also > could send traffic claiming to be from the authorized sender. > > >A concrete example could be hosts that all send IGMP messages to the group > >address to which all IGMP capable routers listen or PIM routers that all > >send PIM messages to the PIM group address. It could also be a multicast > >data service with more than one legitimate source (all sources should then > >probably be under the control of a single key server). > > > >Do you have scenario 1 in mind or scenario 2 or again something else? > > > > > >A second question I have relates to the statement that "the receiver SHALL > >check the source address to ensure that it is from the authorized sender". > >Isn't this a weak check given that a source address can be spoofed by a > >receiver who wants to impersonate the sender? > > It is effective for unicast SAs, but it is a less effective control > for multicast SAs, in so far as any multicast group member has the > requisite key material to spoof. However I do not envision changing > this general requirement to special case multicast SAs. As noted > earlier, if you don't feel that the check is really useful in the > multicast context, you can set the source address to be * for these > SAs. > > >Mark explained correctly my concern related to colliding SPI values when > >independent group controllers manage SAs for the same destination address. > >Thanks! ;-) I think this problem could be solved by adding the source > >address to the triplet (SPI, protocol, dest IP addr). > > What problem? We still require coordination for SPI management on a > per multicast group address basis, so if you want to create multiple > SAs for the multicast group, one per sender, why not use SPIs for > this purpose. I am hesitant, to say the least, to impose a new, > additional burden on all IPsec implementations to use sources > addresses for demuxing, when the same effect can be achieved using > the SPI. > > Steve -- Dr. Haitham S. Cruickshank Senior Research Fellow in Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ From owner-ipsec@lists.tislabs.com Mon Jul 29 06:23:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TDNww21443; Mon, 29 Jul 2002 06:23:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18496 Mon, 29 Jul 2002 08:38:52 -0400 (EDT) Message-Id: <200207231455.KAA15422@ietf.org> To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com From: The IESG SUBJECT: Last Call: The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 23 Jul 2002 10:55:29 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has received a request from the IP Security Protocol Working Group to consider The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec as a Proposed Standard. 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 August 6, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt From owner-ipsec@lists.tislabs.com Mon Jul 29 06:23:59 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TDNxw21445; Mon, 29 Jul 2002 06:23:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18502 Mon, 29 Jul 2002 08:39:53 -0400 (EDT) Message-Id: <200207290017.UAA22847@nwmail.wh.lucent.com> Content-Type: text/plain; charset="koi8-r" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: saag@lists.tislabs.com Subject: Re: [saag] Re: No need for SHA-2 Packet Authentication - Open Letter to the WG and Area Directors Date: Sun, 28 Jul 2002 20:15:31 -0400 X-Mailer: KMail [version 1.3.2] Cc: ipsec@lists.tislabs.com References: <5.1.0.14.2.20020724140348.0212dd78@exna07.securitydynamics.com> In-Reply-To: <5.1.0.14.2.20020724140348.0212dd78@exna07.securitydynamics.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id UAA17500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wednesday 24 July 2002 14:13, Housley, Russ wrote: > .............. In our view, SHA-1 should be > used unless a longer output value is needed. In the proposal, the > hash value is truncated to 128 bits, so there is no benefit from the > more complicated hash function. > > I would support the use of SHA-256 if the final output were longer > than 160 bits. And to emphasize - it's for the cases when MAC of longer than 160 bits is needed, NOT when more than 160 bits of key material.... -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Mon Jul 29 06:24:02 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TDO2w21473; Mon, 29 Jul 2002 06:24:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18508 Mon, 29 Jul 2002 08:40:55 -0400 (EDT) From: Internet-Drafts@ietf.org Message-Id: <200207251206.IAA29746@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tislabs.com;;; Cc: ipsec@lists.tislabs.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-ecc-groups-04.txt Date: Thu, 25 Jul 2002 08:06:13 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Additional ECC Groups For IKE Author(s) : S. Blake-Wilson, D. Brown, Y. Poeluev, M. Salter Filename : draft-ietf-ipsec-ike-ecc-groups-04.txt Pages : 17 Date : 24-Jul-02 This document describes new ECC groups for use in IKE [IKE] in addition to the Oakley groups included therein. These groups are defined to align IKE with other ECC implementations and standards, and in addition, many of them provide higher strength than the Oakley groups. It should be noted that this document is not self-contained. It uses the notations and definitions of [IKE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ecc-groups-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-ipsec-ike-ecc-groups-04.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-ietf-ipsec-ike-ecc-groups-04.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020724142757.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-ecc-groups-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-ecc-groups-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020724142757.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Jul 29 07:38:48 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TEclw25016; Mon, 29 Jul 2002 07:38:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18675 Mon, 29 Jul 2002 09:51:28 -0400 (EDT) Message-Id: <4.2.2.20020729094726.013b78c0@pop.columbia.sparta.com> X-Sender: hh@pop.columbia.sparta.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 29 Jul 2002 09:51:56 -0400 To: Haitham Cruickshank , ipsec@lists.tislabs.com, msec@securemulticast.org From: Hugh Harney Subject: Re: [MSEC] Re: new version of ESP ID In-Reply-To: <3D451D84.30E23BE5@eim.surrey.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Haitham, I tend to agree with Steve. Large groups or dynamic groups will need distributed key and security management. I'd point out that GSAKMP (heavy and Lite) allow for distribution of the key and security management functions. One of the key points to setting up distributed management for large groups is ensuring that the system is secure. GSAKMP does this by incorporating a policy token in the key exchanges. On your second point anti-replay. I think the decision to switch off that feature is dependant on the system your protecting. In many cases, I'd do as you suggested, turn off the anti-replay. However, it depends on the threats to the system. Hugh ________________________________________________________ Hugh Harney hh@sparta.com 410-381-9400 x203 ________________________________________________________ From owner-ipsec@lists.tislabs.com Mon Jul 29 07:42:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TEg5w25094; Mon, 29 Jul 2002 07:42:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18739 Mon, 29 Jul 2002 09:57:30 -0400 (EDT) From: "Housley, Russ" To: "David A. Mcgrew" Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020729095412.02ecbc90@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 29 Jul 2002 09:59:41 -0400 Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: References: <6F0AA176DA68704884B7507AE6907E18091F4C@snake012.odetics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [Klaus] > > yes, I agree with you, I can not see any reason to use an external IV for > > AES CTR if algorithms easy can be defined for internal building of IV's > with > > ESP sequence number and SPI. The only cryptographic requirement for the > > sequence of IV's is, that all the counter values, derived from all the IV's > > over all the ESP packets, transformed by AES, are different as long as one > > fixed key is used. [David] >that's right. Additionally, some additional strength against attacks which >rely on precomputation of a database to use during the attack stage can be >gained by having the part of the counter be secret. We have discussed the inclusion of a secret component in the counter. It complicates the key management by requiring an additional secret value to be managed. If one is concerned about this type of dictionary attack, the use of a longer AES key provides more protection without imposing additional requirements on key management. Russ From owner-ipsec@lists.tislabs.com Mon Jul 29 09:10:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TGAEw28894; Mon, 29 Jul 2002 09:10:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18948 Mon, 29 Jul 2002 11:24:22 -0400 (EDT) Message-Id: <4.3.2.7.2.20020729071825.050bc8e0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 Jul 2002 08:35:22 -0700 To: Stephen Kent From: Mark Baugher Subject: Re: new version of ESP ID Cc: ipsec@lists.tislabs.com, msec@securemulticast.org In-Reply-To: References: <4.3.2.7.2.20020720073224.02473a80@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020709135351.0251a3f0@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020709135351.0251a3f0@mira-sjc5-6.cisco.com> <4.3.2.7.2.20020720073224.02473a80@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, At 12:47 AM 7/24/2002 -0400, Stephen Kent wrote: <...> >>I think I understand your rationale. We should at least document the >>fact that it may be necessary to identify the multicast ESP SA using the >>triple for source-specific multicast - for >>some applications. I think Bill and Radia's previous comments to this >>thread explain why. If all sources to a multicast address use the same >>group key controller, then I don't see a problem. If some sources to a >>multicast address use distinct group key controllers (e.g., each source >>acts as its own controller), then there is the potential for SPI >>collisions and means must be invented to handle these collisions. >> >>Mark > >Mark, > >I don't feel that we have a good enough answers to proceed, yet. We cannot >proceed on the basis of "may be necessary." What we need is a concise >description of what is required for multicast traffic demuxing, based on >extant protocol standards, including how SPIs will be assigned in the >context of these protocols. My reading of the new AH and ESP I-Ds is that they both support a multicast SA from a single sender to a multicast group address. Even this level of security has the important limitation that every member of the secure group has the key that is used for authenticating IPsec packets and a rogue member might use that key to impersonate a sender. Is this security in the new I-Ds useful? It would work for the one commercial multicast service I am familiar with that was offered by an international network service provider a few years back; this service allowed hosts to receive multicast but not send to a multicast address - there was only one sender. I am also aware of a couple of companies that enabled multicast on their campuses for briefings and trainings. I talked to more than a couple of companies who wanted only a single sender to a multicast address and wanted to configure their networks so hosts other than the single sender could not send. This desire did not come from any security awareness but to mitigate unauthorized, high-volume traffic on their networks. Will the new I-Ds support multicast in general? Extant standards support what might be called "any source multicast" so the restriction of not allowing multiple senders to a secure group means that IGMPv2 host semantics are not supported. If we identified a multicast IPsec SA with the source address, network address, and SPI, then we could assign an IPsec SA to an (S,G) without assuming that there is some central device allocating SPIs. This would support both IGMPv2 and IGMPv3 in my opinion. We still lack packet authentication unless all group members are trusted not to impersonate a source. VRRP, some routing protocols, and other applications assume that kind of trust. But at least some of these protocols (e.g. VRRP) have multiple S's sending to a single G. (the scheme in the new AH and ESP I-Ds could still work if we assume a central entity managing SPIs). What about using (G, SPI) and have a central entity manage SPI for G? There is no reason why a particular host S that sends to a group G cannot manage keys for (S,G). In this case, S would allocate the SPI. A large scale service, however, such as a Fortune 500 company that sends multicast training and briefing content to campuses and field offices, would likely operate a network operations center and use a specialized key server to allocate keys and SPI. Both scenaria are valid. But in general, (G, SPI) does not support Si and Sj managing keys for their own traffic. >Implementors cannot reasonably deal with the current level of vague >characterization of requirements floating around in this discussion. for >example, if there are two group key controllers for a multicast session, >and each assigns SPis independently to subscribers (and thus the collision >potential), which SPI will a sender put in an outbound packet to ensure >that all recipients will recognize it? One way to do it: sender Sj sends SPIj when there is an SA in place for at members of Sj, G. We can get this capability by including Sj to identify the IPsec multicast SA. This of course does not mean that a single SA services all senders to the particular multicast address; for that you would need to have a replay table. I think Bill asked for supporting (*, G) in addition to (S, G), but the former means that an IPsec host would need to support a replay list for every potential sender. Rather than do that, there can be an SA for each source. The new AH and ESP I-Ds accomplish this by limiting G to have one sender. I would not do it that way. I don't see any of this as urgent for IPsec because the new I-Ds still do not address a fundamental problem: Packet source authentication. I expect that this problem is in MSEC's realm. As I see it, you are addressing a subset of the requirements, which would be suitable for some environments, but which does not support nascent multicast standards such as IGMPv3. Nor does it support extant standards such as IGMPv2. Neither are securable in general anyway without multicast packet source authentication or some restriction on who can send. Mark >Steve From owner-ipsec@lists.tislabs.com Mon Jul 29 09:27:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TGRiw29365; Mon, 29 Jul 2002 09:27:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18991 Mon, 29 Jul 2002 11:44:29 -0400 (EDT) Message-Id: <200207291558.g6TFwRS4014883@kebe.east.sun.com> Subject: Re: Two AES encryption modes? In-Reply-To: from David Wagner at "Jul 26, 2002 00:02:48 am" To: David Wagner Date: Mon, 29 Jul 2002 11:58:27 -0400 (EDT) CC: ipsec@lists.tislabs.com From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David, > >2. You want to use manual keying and therefore may send more than one > > packet with the same IV. With CBC that doesn't compromise the > > confidentiality of the data; with counter mode it does. > > Nitpick: CBC is not really as secure as one might like if IV's repeat, > however it is true that IV reuse hurts CTR mode much worse than CBC mode. > > If you reuse the same IV with CBC mode, there is some minor compromise > of message confidentiality (shared plaintext prefixes show through as > shared prefixes in the ciphertexts); in comparison, IV reuse in CTR mode > is more devastating (it reveals both plaintexts). Manual keying does NOT, I repeat NOT mean identical IVs. The two implementations I worked on (NRL, Solaris) use random (for "random" == /dev/urandom strength) IVs regardless of how IPsec SAs are derived. Dan From owner-ipsec@lists.tislabs.com Mon Jul 29 10:57:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6THvsw06434; Mon, 29 Jul 2002 10:57:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19142 Mon, 29 Jul 2002 13:11:09 -0400 (EDT) Message-Id: <200207291724.g6THOJah012656@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Two AES encryption modes? In-reply-to: Your message of "Mon, 29 Jul 2002 11:58:27 EDT." <200207291558.g6TFwRS4014883@kebe.east.sun.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 29 Jul 2002 13:24:19 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Dan" == Dan McDonald writes: >> >2. You want to use manual keying and therefore may send more than one >> > packet with the same IV. With CBC that doesn't compromise the > >> confidentiality of the data; with counter mode it does. >> >> Nitpick: CBC is not really as secure as one might like if IV's repeat, >> however it is true that IV reuse hurts CTR mode much worse than CBC >> mode. >> >> If you reuse the same IV with CBC mode, there is some minor compromise >> of message confidentiality (shared plaintext prefixes show through as >> shared prefixes in the ciphertexts); in comparison, IV reuse in CTR >> mode is more devastating (it reveals both plaintexts). Dan> Manual keying does NOT, I repeat NOT mean identical IVs. The two Dan> implementations I worked on (NRL, Solaris) use random (for "random" Dan> == /dev/urandom strength) IVs regardless of how IPsec SAs are Dan> derived. I agree with you - implementations should never have to reuse IVs. The question is whether CTR mode is sufficiently robust that we need never standardize an AES CBC mode. The IV problem for CTR mode is lethal. The same behaviour applied to CBC mode is not much of a big deal. To me, this is a debate about how deep the security is - of course, use random IVs. Should something bad happen, and someone figure out either a way to influence the IVs, or the prng or hash that was used to generate turns out to be bad, then is there still anything to keep the barbarians out? ("You must be *#%&U*#$@{} random to storm this system") Those who derived the IV from ciphertext would get screwed if they didn't start with a random IV. FreeSWAN does start with a random initial IV. It now (as of last week, when we enabled the fix) uses a /dev/urandom seeded prng for IV generation. The people who I see that think that manually keying might be neat are the PDA/phone people who just need to authenticate back to a single gateway box. They might be in an environment where they haven't provided for any sources of randomness such that they'd even have a useful /dev/random. I think that they can, and should fix this - certainly a wireless device can just dd if=/dev/ether of=/dev/random - i.e. listen some static, but that may require some thinking in the driver... ] Internet Security. Have encryption, will travel |1 Fish/2 Fish [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F [ ]mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [ ] At the far end of some dark fiber - wait that's dirt! |for everyone [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPUV6QIqHRg3pndX9AQE+AwP9HTPiPJyGNw3/HX9Soa2Evw0GXuM0RM3y b9A9fP6cFIZG1T3IRTwcsoGmkage3kve/n3iY1cNgd7PtERCnLxBt+zTX3NNJS5a Tx6KWeLe1SU/Gp1gC+27ljHoMt+hRfKA3qUK1fUJmgKcK1GmVns4vqN72alPWydt gjP9xrmbqzg= =4nee -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Jul 29 11:51:04 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TIp3w12219; Mon, 29 Jul 2002 11:51:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19184 Mon, 29 Jul 2002 14:07:41 -0400 (EDT) From: "David A. Mcgrew" To: "Housley, Russ" Cc: , Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Mon, 29 Jul 2002 11:21:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <5.1.0.14.2.20020729095412.02ecbc90@exna07.securitydynamics.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ, thank you for your comments, more inline: > -----Original Message----- > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > Sent: Monday, July 29, 2002 7:00 AM > To: David A. Mcgrew > Cc: ipsec@lists.tislabs.com > Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt > > > [Klaus] > > > yes, I agree with you, I can not see any reason to use an > external IV for > > > AES CTR if algorithms easy can be defined for internal > building of IV's > > with > > > ESP sequence number and SPI. The only cryptographic > requirement for the > > > sequence of IV's is, that all the counter values, derived > from all the IV's > > > over all the ESP packets, transformed by AES, are different > as long as one > > > fixed key is used. > > [David] > >that's right. Additionally, some additional strength against > attacks which > >rely on precomputation of a database to use during the attack > stage can be > >gained by having the part of the counter be secret. > > We have discussed the inclusion of a secret component in the counter. It > complicates the key management by requiring an additional secret value to > be managed. I disagree with the supposition that including a secret component in the counter complicates key management. I'll explain what I'm thinking; please let me know if or where your assumptions are different. One simple way in which counter mode can include a secret component is to define that value to be part of the key. This method allows counter mode to use a secret component in the counter, while hiding that fact from a key management protocol. For example, define the format of the counter key to look like: +---------------+------------+ | AES Key | Offset | +---------------+------------+ where "Offset" is the secret counter component. The AES Key field would have a fixed length (as the draft has a distinct IANA transform number for each AES key length). The Offset could be fixed length (which is certainly simpler), or could have a variable length if that proves desirable. In any case, a variable-length Offset field would not introduce any ambiguity. The counter mode ESP transform gets to define what its key looks like; the above definition is perfectly valid. IKE is quite capable of dealing with the format above, since it can work with any key length cipher in ESP. I defer to Scott Fluhrer for more details, as he's implemented what I've described here (which he and I worked out in the summer of y2k, to give credit where it is due). I certainly agree that it would be overly complicated to expect a key management system to manage the 'secret counter component' as a distinct data type. But there's no reason to do that, since the simple key format described above works just as well. I fear that perhaps this point has been a source of miscommunication between us in the past. > If one is concerned about this type of dictionary > attack, the > use of a longer AES key provides more protection Yes, this is completely true. Using a bigger AES key also provides protection against precomputation attacks. However, this approach has some disadvantages. The computational cost of AES is greater for the 192-bit key and 256-bit key versions, by 20% and 40% respectively, making this approach less efficient than that of using a random offset. Also, a number of current AES implementations do not include the larger key sizes, and thus could not use this approach. In summary, my reasons for preferring the inclusion of a 'secret counter component' are that 1) it adds a significant amount of security against precomputation attacks, 2) it adds little or no computational cost, and 3) it fits easily into the current architecture. David From owner-ipsec@lists.tislabs.com Mon Jul 29 12:00:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TJ0mw12709; Mon, 29 Jul 2002 12:00:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19217 Mon, 29 Jul 2002 14:12:43 -0400 (EDT) Date: Mon, 29 Jul 2002 14:26:18 -0400 From: Ran Canetti Message-Id: <200207291826.OAA30424@ornavella.watson.ibm.com> To: H.Cruickshank@eim.surrey.ac.uk, ipsec@lists.tislabs.com, msec@securemulticast.org Subject: Re: [MSEC] Re: new version of ESP ID Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Haitham, Regarding the distributed controller issue. MSEC has set up for itself to first address the single controller setting, with the ideas that: 1) the single controller setting is complex and relevant enough 2) there can be many alternative ways to distribute the functionality of the controller. In the most part, this can be done in a "transparent" way as far as the group members are concerned. Furthermore, there seems to be less urgent need for standardization there. I suggest to limit further discussion of this issue to the msec list, no need to bother ipsec with this. Ran > From: Haitham Cruickshank > > ... > > 1. Scalability: For very large groups (thousands of members) or very dynamic > multicast groups (frequent join and leaves), having a single group controller > might not scale well specially for re-keying problem (changing keys when > members join or leave). If this problems is true, then we need to have a > distributed group controller/controllers and this brings new problems which has > been discussed in some previous emails. > > ... From owner-ipsec@lists.tislabs.com Mon Jul 29 12:00:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TJ0sw12723; Mon, 29 Jul 2002 12:00:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19287 Mon, 29 Jul 2002 14:17:46 -0400 (EDT) Date: 29 Jul 2002 14:17:08 -0400 Message-ID: <002001c2372c$27928e40$0468e640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Dan McDonald'" , " 'David Wagner'" Cc: "'list'" Subject: RE: Two AES encryption modes? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200207291558.g6TFwRS4014883@kebe.east.sun.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Manual keying does NOT, I repeat NOT mean identical IVs. The two > implementations I worked on (NRL, Solaris) use random (for "random" == > /dev/urandom strength) IVs regardless of how IPsec SAs are derived. I agree that fear of IV reuse is not a good enough to ban counter mode with manual keying. Manual keying, after all, does not mean that you never rekey; you may have multiple pre-installed SAs and you switch over after a fixed byte count. This implies that you need to keep a rough estimate of the byte count in non-volatile storage, so it should be always possible to calculate a unique counter value. Therefore, using random IVs would seem to be unnecessary. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan McDonald > Sent: Monday, July 29, 2002 11:58 AM > To: David Wagner > Cc: ipsec@lists.tislabs.com > Subject: Re: Two AES encryption modes? > > > David, > > > >2. You want to use manual keying and therefore may send > more than one > > > packet with the same IV. With CBC that doesn't compromise the > > > confidentiality of the data; with counter mode it does. > > > > Nitpick: CBC is not really as secure as one might like if > IV's repeat, > > however it is true that IV reuse hurts CTR mode much worse > than CBC mode. > > > > If you reuse the same IV with CBC mode, there is some minor > compromise > > of message confidentiality (shared plaintext prefixes show > through as > > shared prefixes in the ciphertexts); in comparison, IV > reuse in CTR mode > > is more devastating (it reveals both plaintexts). > > Manual keying does NOT, I repeat NOT mean identical IVs. The two > implementations I worked on (NRL, Solaris) use random (for "random" == > /dev/urandom strength) IVs regardless of how IPsec SAs are derived. > > Dan > From owner-ipsec@lists.tislabs.com Mon Jul 29 12:10:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TJARw13553; Mon, 29 Jul 2002 12:10:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19327 Mon, 29 Jul 2002 14:28:53 -0400 (EDT) Message-Id: <3.0.3.32.20020729114222.015fdaa8@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 29 Jul 2002 11:42:22 -0700 To: "Housley, Russ" , "David A. Mcgrew" From: Alex Alten Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Cc: ipsec@lists.tislabs.com In-Reply-To: <5.1.0.14.2.20020729095412.02ecbc90@exna07.securitydynamics .com> References: <6F0AA176DA68704884B7507AE6907E18091F4C@snake012.odetics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:59 AM 7/29/2002 -0400, Housley, Russ wrote: >[Klaus] >> > yes, I agree with you, I can not see any reason to use an external IV for >> > AES CTR if algorithms easy can be defined for internal building of IV's >> with >> > ESP sequence number and SPI. The only cryptographic requirement for the >> > sequence of IV's is, that all the counter values, derived from all the IV's >> > over all the ESP packets, transformed by AES, are different as long as one >> > fixed key is used. > >[David] >>that's right. Additionally, some additional strength against attacks which >>rely on precomputation of a database to use during the attack stage can be >>gained by having the part of the counter be secret. > >We have discussed the inclusion of a secret component in the counter. It >complicates the key management by requiring an additional secret value to >be managed. If one is concerned about this type of dictionary attack, the >use of a longer AES key provides more protection without imposing >additional requirements on key management. > >Russ > I believe someone already has stated the problem will be to prevent the counter from repeating (or being predictable) with the same key. It's entropy in practice may be fairly low. Also, there may be the fairly likely danger of shared keys across multiple hosts which is deadly if any IV values commonly repeat on different hosts (this helped to kill WEP). I think this is the crux of the matter, and I don't think this can be solved with a software PRNG algorithm. What I'd recommend is to try to pull it from hardware, like the Intel P4 supporting chipset. If this is not possible maybe a large random seed can be placed on each host, and the PRNG is then used to pseudo-randomly mix/fold the seed bits. One can get quite a few "unpredictable" random IV values that way. There will be an exponential decay in unpredictableness, but hopefull you can start high enough up on the curve for it to useful. Eventually the seed would need to be refreshed, but if it is infrequent enough it could be done by hand. The large seed should remain secret during its lifetime otherwise it will be subject to an inverse matrix precomputation attack. It would be ideal if the PRNG had a large set of random small seeds available to it as well, so that the start of it's cycle per new session would be unpredictable (it too needs to be refreshed periodically). - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Mon Jul 29 12:42:19 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TJgJw14704; Mon, 29 Jul 2002 12:42:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19397 Mon, 29 Jul 2002 14:53:08 -0400 (EDT) Date: 29 Jul 2002 14:52:03 -0400 Message-ID: <002101c23731$07ff9230$0468e640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Michael Richardson'" , " 'list'" Subject: RE: Two AES encryption modes? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200207262232.g6QMVfuV005259@marajade.sandelman.ottawa.on.ca> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If everyone wants to use the IETF-specified ones that will be great, but in the past it has been hard to get consensus on one ciphersuite that everyone can agree on. I don't relish leaving this up to a tyrany of the majority. There are always things that people want to make optional, such as IPCOMP or PFS. The bits on the wire issue is a red herring, unless you are also advocating using group 1 and preshared keys to save bandwidth. You are free to implement as few or as many ciphersuites as you want. I imagine you'd be considered compliant as long as you implement the WG-sanctioned ones. If another WG tries to standardize AES-256/MD2 it will never survive last call. And as I've said before, I don't buy your complaints about testing. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael Richardson > Sent: Friday, July 26, 2002 6:32 PM > To: ipsec@lists.tislabs.com > Subject: Re: Two AES encryption modes? > > > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Andrew" == Andrew Krywaniuk > writes: > Andrew> Not necessarily. Take a look at the list I sent earlier: > > Andrew> IETF-ipsec high security '02 (chosen by WG, > published in an RFC) > Andrew> US DoD FIPS standard '02 (chosen by a large > customer, listed as a > Andrew> requirement) > Andrew> VPNC default '02 (chosen by a vendor > consortium, published on their > Andrew> website) > Andrew> JoeBillyBob JBB's ciphersuite '02 (chosen by > an individual, distributed > Andrew> to his friends) > > Andrew> Only the first ciphersuite needs to be published > in an RFC. The other ones > Andrew> are published on the DoD, VPNC, and > joebillybob.com websites/technical > Andrew> publications respectively. If you use GUI > ciphersuites there is no IANA > Andrew> registry, so there doesn't need to be a > comprehensive list of all the > Andrew> possible ciphersuites. > > There will nothing to help interoperability. > It certainly won't help anyone get good support from > hardware vendors. > > We are just wasting bits on EVERY wire to avoid writing what will be > perhaps a dozen real drafts. > > After the first 6 or so submissions of AES-256/MD2 (not > even HMAC), people > will get bored with the concept. The only GUI ciphersuites > used will be the > IETF specified ones, and we'll have hundreds of lines of code > in SOI that > never get tested, except when Tero Kivinen initiates to the > broadcast address > at bakeoffs. > > ] Internet Security. Have encryption, will travel > |1 Fish/2 Fish [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |Red F./Blow F [ > ]mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |strong crypto [ > ] At the far end of some dark fiber - wait that's dirt! > |for everyone [ > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3ia > Charset: latin1 > Comment: Finger me for keys > > iQCVAwUBPUHNyoqHRg3pndX9AQHMTwQA7l9UUAbyhdgOFrbE31XCTrb/K49D2KPE > uTT/YTktx8WXgs3ZJiZqcQcsanl9b7NeUQB0pWqOzzvcadUOa/1XHp0FrHD9XU1V > 3OUg9Ww96qP6kGMznlAI6TQQpzgm12O4biNWWLQXNXMIXaLwsbeNcP8fzjEjIg9+ > 0qOp83ZRU8Q= > =ilr+ > -----END PGP SIGNATURE----- > From owner-ipsec@lists.tislabs.com Mon Jul 29 13:37:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TKb7w18924; Mon, 29 Jul 2002 13:37:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19500 Mon, 29 Jul 2002 15:42:29 -0400 (EDT) Message-Id: <4.3.2.7.2.20020729124940.01c22c20@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 Jul 2002 12:53:16 -0700 To: "David A. Mcgrew" From: Scott Fluhrer Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Cc: "Housley, Russ" , , In-Reply-To: References: <5.1.0.14.2.20020729095412.02ecbc90@exna07.securitydynamics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:21 AM 7/29/2002, David A. Mcgrew wrote: >Russ, > >thank you for your comments, more inline: > > > -----Original Message----- > > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > > Sent: Monday, July 29, 2002 7:00 AM > > To: David A. Mcgrew > > Cc: ipsec@lists.tislabs.com > > Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt > > > > > > [Klaus] > > > > yes, I agree with you, I can not see any reason to use an > > external IV for > > > > AES CTR if algorithms easy can be defined for internal > > building of IV's > > > with > > > > ESP sequence number and SPI. The only cryptographic > > requirement for the > > > > sequence of IV's is, that all the counter values, derived > > from all the IV's > > > > over all the ESP packets, transformed by AES, are different > > as long as one > > > > fixed key is used. > > > > [David] > > >that's right. Additionally, some additional strength against > > attacks which > > >rely on precomputation of a database to use during the attack > > stage can be > > >gained by having the part of the counter be secret. > > > > We have discussed the inclusion of a secret component in the counter. It > > complicates the key management by requiring an additional secret value to > > be managed. > >I disagree with the supposition that including a secret component in the >counter complicates key management. I'll explain what I'm thinking; please >let me know if or where your assumptions are different. > >One simple way in which counter mode can include a secret component is to >define that value to be part of the key. This method allows counter mode to >use a secret component in the counter, while hiding that fact from a key >management protocol. > >For example, define the format of the counter key to look like: > > +---------------+------------+ > | AES Key | Offset | > +---------------+------------+ > >where "Offset" is the secret counter component. The AES Key field would >have a fixed length (as the draft has a distinct IANA transform number for >each AES key length). The Offset could be fixed length (which is certainly >simpler), or could have a variable length if that proves desirable. In any >case, a variable-length Offset field would not introduce any ambiguity. > >The counter mode ESP transform gets to define what its key looks like; the >above definition is perfectly valid. IKE is quite capable of dealing with >the format above, since it can work with any key length cipher in ESP. I >defer to Scott Fluhrer for more details, as he's implemented what I've >described here (which he and I worked out in the summer of y2k, to give >credit where it is due). Yes, it is as Dave described it. A concrete example would be: the above mode with 128 bit AES keys and 64 bit secret counter offset would ask IKE for 192 bits of keying material, and interpret the first 128 bits as the AES key, and the last 64 bits as the offset. We would note that this uses 192 bits of keying material and delivers (at best) only 128 bits of strength -- I do not believe that is a serious (or even minor) problem. >I certainly agree that it would be overly complicated to expect a key >management system to manage the 'secret counter component' as a distinct >data type. But there's no reason to do that, since the simple key format >described above works just as well. I fear that perhaps this point has been >a source of miscommunication between us in the past. > > > If one is concerned about this type of dictionary > > attack, the > > use of a longer AES key provides more protection > >Yes, this is completely true. Using a bigger AES key also provides >protection against precomputation attacks. However, this approach has some >disadvantages. The computational cost of AES is greater for the 192-bit key >and 256-bit key versions, by 20% and 40% respectively, making this approach >less efficient than that of using a random offset. Also, a number of >current AES implementations do not include the larger key sizes, and thus >could not use this approach. > >In summary, my reasons for preferring the inclusion of a 'secret counter >component' are that 1) it adds a significant amount of security against >precomputation attacks, 2) it adds little or no computational cost, and 3) >it fits easily into the current architecture. > >David From owner-ipsec@lists.tislabs.com Mon Jul 29 14:03:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TL3Ow20650; Mon, 29 Jul 2002 14:03:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19595 Mon, 29 Jul 2002 16:15:53 -0400 (EDT) Date: Mon, 29 Jul 2002 16:29:54 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: RE: Two AES encryption modes? In-Reply-To: <002101c23731$07ff9230$0468e640@ca.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 29 Jul 2002, Andrew Krywaniuk wrote: > The bits on the wire issue is a red herring, unless you are also advocating > using group 1 and preshared keys to save bandwidth. Bits on the wire may be worth the cost in some contexts, but the cost cannot be ignored entirely, so long as IKE/SOI negotiations use UDP and thus can be crippled by fragmentation problems. "The cost is acceptable" is a legitimate position; "the cost is not important" is not. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jul 29 15:14:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TMERw23304; Mon, 29 Jul 2002 15:14:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA19762 Mon, 29 Jul 2002 17:08:22 -0400 (EDT) From: "David A. Mcgrew" To: "Alex Alten" Cc: Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Mon, 29 Jul 2002 14:19:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3.0.3.32.20020729114222.015fdaa8@mail> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex, > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Alex Alten > Sent: Monday, July 29, 2002 11:42 AM > To: Housley, Russ; David A. Mcgrew > Cc: ipsec@lists.tislabs.com > Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt > > > At 09:59 AM 7/29/2002 -0400, Housley, Russ wrote: > >[Klaus] > >> > yes, I agree with you, I can not see any reason to use an > external IV for > >> > AES CTR if algorithms easy can be defined for internal > building of IV's > >> with > >> > ESP sequence number and SPI. The only cryptographic > requirement for the > >> > sequence of IV's is, that all the counter values, derived > from all the > IV's > >> > over all the ESP packets, transformed by AES, are different > as long as > one > >> > fixed key is used. > > > >[David] > >>that's right. Additionally, some additional strength against > attacks which > >>rely on precomputation of a database to use during the attack > stage can be > >>gained by having the part of the counter be secret. > > > >We have discussed the inclusion of a secret component in the > counter. It > >complicates the key management by requiring an additional secret > value to > >be managed. If one is concerned about this type of dictionary > attack, the > >use of a longer AES key provides more protection without imposing > >additional requirements on key management. > > > >Russ > > > > I believe someone already has stated the problem will be to prevent the > counter > from repeating (or being predictable) with the same key. It's entropy in > practice > may be fairly low. Also, there may be the fairly likely danger > of shared keys > across multiple hosts which is deadly if any IV values commonly repeat on > different hosts (this helped to kill WEP). I think this is the > crux of the > matter, > and I don't think this can be solved with a software PRNG > algorithm. What I'd > recommend is to try to pull it from hardware, like the Intel P4 supporting > chipset. > If this is not possible maybe a large random seed can be placed on each > host, and > the PRNG is then used to pseudo-randomly mix/fold the seed bits. One can > get quite > a few "unpredictable" random IV values that way. There will be an > exponential > decay in unpredictableness, but hopefull you can start high enough up on > the curve > for it to useful. Eventually the seed would need to be refreshed, but if > it is > infrequent enough it could be done by hand. The large seed should remain > secret > during its lifetime otherwise it will be subject to an inverse matrix > precomputation > attack. It would be ideal if the PRNG had a large set of random small > seeds available > to it as well, so that the start of it's cycle per new session would be > unpredictable > (it too needs to be refreshed periodically). I think that the discussion is somewhat hard to follow, my apologies for the terseness of the mail that started this thread. Russ' draft requires distinct IV values, which implies that a deterministic mechanism must be used to produce them. The use of a true random number generator, as you'd suggest, would generate repeat values after 2^32 packets, with a high probability. Given the fact that using the same IV value twice in counter mode gives away the exor of the plaintexts, this is something that we want to avoid. Russ and I are in agreement that counter mode should be implemented using IVs generated by a deterministic algorithm. What I was proposing is that additional security against attacks which use precomputation (e.g. key-collision and time-memory tradeoff attacks) by making part of the counter secret, so that the adversary does not know all of the inputs to the AES cipher that are used to generate a particular range of keystream. David From owner-ipsec@lists.tislabs.com Mon Jul 29 15:38:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TMcuw23888; Mon, 29 Jul 2002 15:38:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA19851 Mon, 29 Jul 2002 17:53:38 -0400 (EDT) Date: 29 Jul 2002 17:53:10 -0400 Message-ID: <002801c2374a$55876780$0468e640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Henry Spencer'" , " 'IP Security List'" Subject: RE: Two AES encryption modes? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > "The cost is acceptable" is a legitimate position; "the cost is not > important" is not. A typical transform payload (including the header) for IKEv1 will run about 32 bytes for phase 1 and 24 bytes for phase 2. Eight bytes of that is the SA lifetime, which has been omitted from IKEv2. The real problem in terms of bandwidth consumption was permutation explosion, which has also been solved in IKEv2. This is completely drowned out by the cost of doing group 5 with certificates. I just generated a sample exchange: cert request = 97 bytes, key exchange = 196 bytes, certificate = 713 bytes, signature = 132 bytes. My claim is not so much that the cost is not important, but rather that it will be drowned out by other factors. The cost is acceptable by the same rationale that tells you if you're buying a Lambourghini then you shouldn't bother haggling over the cost of the radio. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Henry Spencer > Sent: Monday, July 29, 2002 4:30 PM > To: IP Security List > Subject: RE: Two AES encryption modes? > > > On 29 Jul 2002, Andrew Krywaniuk wrote: > > The bits on the wire issue is a red herring, unless you are > also advocating > > using group 1 and preshared keys to save bandwidth. > > Bits on the wire may be worth the cost in some contexts, but the cost > cannot be ignored entirely, so long as IKE/SOI negotiations > use UDP and > thus can be crippled by fragmentation problems. > > "The cost is acceptable" is a legitimate position; "the cost is not > important" is not. > > > Henry Spencer > > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Mon Jul 29 16:21:05 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TNL5w25454; Mon, 29 Jul 2002 16:21:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA19976 Mon, 29 Jul 2002 18:38:01 -0400 (EDT) Date: Mon, 29 Jul 2002 18:51:39 -0400 (EDT) From: Henry Spencer To: Andrew Krywaniuk cc: "'IP Security List'" Subject: RE: Two AES encryption modes? In-Reply-To: <002801c2374a$55876780$0468e640@ca.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 29 Jul 2002, Andrew Krywaniuk wrote: > A typical transform payload (including the header) for IKEv1 will run about > 32 bytes for phase 1 and 24 bytes for phase 2. Eight bytes of that is the SA > lifetime, which has been omitted from IKEv2. The real problem in terms of > bandwidth consumption was permutation explosion, which has also been solved > in IKEv2. Unless I've missed something, the use of suites rather than individual combinations of transforms -- which is precisely what we are debating -- is how that was solved. The problem with transforms is not that they are individually bulky, but that they come in swarms, not one at a time. > My claim is not so much that the cost is not important, but rather that it > will be drowned out by other factors... My claim is that you need to justify that more -- it's not a self-evident truth. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jul 29 16:27:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TNRvw25608; Mon, 29 Jul 2002 16:27:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA19993 Mon, 29 Jul 2002 18:43:01 -0400 (EDT) Message-Id: <3.0.3.32.20020729155630.013bbfc8@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 29 Jul 2002 15:56:30 -0700 To: "David A. Mcgrew" From: Alex Alten Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Cc: In-Reply-To: References: <3.0.3.32.20020729114222.015fdaa8@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks David, My misunderstanding of the IV generation details. I just read your other explanation of the secret starting offset for the IV sequence. In your/Fluher's design, is this offset generated separately from the key bits? What if the key is used repeatedly, or in the worst case shared among many hosts? What happens if a host reboots? Does the secret offset start at the same initial value? If not, how do you guarentee this? I think these questions still are valid even if you combine the offset with the ESP sequence number and SPI (since these may repeat also). WEP broke down with it's failure to answer these sorts of questions. BTW, I'm not completely clear on this aspect. Does the sender completely control the IV sequence generation? Can the receiver process incoming packets out-of-order or handle dropped packets? (Russ, I guess I'm responding to my internal mental "gestalt" of the various emails flying around. :-) Regards, - Alex At 02:19 PM 7/29/2002 -0700, David A. Mcgrew wrote: >Alex, > >> -----Original Message----- >> From: owner-ipsec@lists.tislabs.com >> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Alex Alten >> Sent: Monday, July 29, 2002 11:42 AM >> To: Housley, Russ; David A. Mcgrew >> Cc: ipsec@lists.tislabs.com >> Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt >> >> >> At 09:59 AM 7/29/2002 -0400, Housley, Russ wrote: >> >[Klaus] >> >> > yes, I agree with you, I can not see any reason to use an >> external IV for >> >> > AES CTR if algorithms easy can be defined for internal >> building of IV's >> >> with >> >> > ESP sequence number and SPI. The only cryptographic >> requirement for the >> >> > sequence of IV's is, that all the counter values, derived >> from all the >> IV's >> >> > over all the ESP packets, transformed by AES, are different >> as long as >> one >> >> > fixed key is used. >> > >> >[David] >> >>that's right. Additionally, some additional strength against >> attacks which >> >>rely on precomputation of a database to use during the attack >> stage can be >> >>gained by having the part of the counter be secret. >> > >> >We have discussed the inclusion of a secret component in the >> counter. It >> >complicates the key management by requiring an additional secret >> value to >> >be managed. If one is concerned about this type of dictionary >> attack, the >> >use of a longer AES key provides more protection without imposing >> >additional requirements on key management. >> > >> >Russ >> > >> >> I believe someone already has stated the problem will be to prevent the >> counter >> from repeating (or being predictable) with the same key. It's entropy in >> practice >> may be fairly low. Also, there may be the fairly likely danger >> of shared keys >> across multiple hosts which is deadly if any IV values commonly repeat on >> different hosts (this helped to kill WEP). I think this is the >> crux of the >> matter, >> and I don't think this can be solved with a software PRNG >> algorithm. What I'd >> recommend is to try to pull it from hardware, like the Intel P4 supporting >> chipset. >> If this is not possible maybe a large random seed can be placed on each >> host, and >> the PRNG is then used to pseudo-randomly mix/fold the seed bits. One can >> get quite >> a few "unpredictable" random IV values that way. There will be an >> exponential >> decay in unpredictableness, but hopefull you can start high enough up on >> the curve >> for it to useful. Eventually the seed would need to be refreshed, but if >> it is >> infrequent enough it could be done by hand. The large seed should remain >> secret >> during its lifetime otherwise it will be subject to an inverse matrix >> precomputation >> attack. It would be ideal if the PRNG had a large set of random small >> seeds available >> to it as well, so that the start of it's cycle per new session would be >> unpredictable >> (it too needs to be refreshed periodically). > >I think that the discussion is somewhat hard to follow, my apologies for the >terseness of the mail that started this thread. > >Russ' draft requires distinct IV values, which implies that a deterministic >mechanism must be used to produce them. The use of a true random number >generator, as you'd suggest, would generate repeat values after 2^32 >packets, with a high probability. Given the fact that using the same IV >value twice in counter mode gives away the exor of the plaintexts, this is >something that we want to avoid. > >Russ and I are in agreement that counter mode should be implemented using >IVs generated by a deterministic algorithm. What I was proposing is that >additional security against attacks which use precomputation (e.g. >key-collision and time-memory tradeoff attacks) by making part of the >counter secret, so that the adversary does not know all of the inputs to the >AES cipher that are used to generate a particular range of keystream. > >David > > -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Mon Jul 29 16:31:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TNVZw25675; Mon, 29 Jul 2002 16:31:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20007 Mon, 29 Jul 2002 18:47:00 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Clarification of potential NAT multiple client solutions Date: Mon, 29 Jul 2002 16:01:22 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1056BF00A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Clarification of potential NAT multiple client solutions thread-index: AcIemNcfjCPi5nBYTnWJp8WwORX//AIJcSNwBCT21uA= From: "Brian Swander" To: X-OriginalArrivalTime: 29 Jul 2002 23:01:19.0365 (UTC) FILETIME=[D9ADBB50:01C23753] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA20004 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We have had requests to clarify potential solutions to problem of multiple clients behind the same NAT simultaneously connecting to the same destination IP address. draft-ietf-ipsec-udp-encaps-03.txt sections 5.2 and 5.3 say you MUST avoid the problem. Therefore you must implement some kind of solution for this problem. If your solution is not to support the scenario, you can still interoperate with others and support just one client behind the same NAT with SA state to you at any one time. http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-03.txt As this isn't a wire protocol matter, but a local implementation matter, specification of the mechanisms do not belong in the draft itself. A list of options is below. And you'll see that this mail has been through our legal department because of there are some known and perhaps unknown IPR issues with implementation techniques. Choosing an option will likely depend on the scenarios for which you use/support IPsec NAT-T. This is not meant to be exhaustive, so other solutions may exist. Bottom line is that there are a variety of solutions for this scenario. So I don't see the IPR issues relating to solutions for this one scenario as blocking the progress of NAT-T drafts on standards track. For ESP transport mode: 1. implement a built-in NAT (network address translation) above IPsec decapsulation. SSH may have intellectual property rights relating to this implementation technique. See their IPR notice on the IETF web site for the details. 2. implement a built-in NAPT (network address port translation) above IPsec decapsulation. Microsoft may have intellectual property rights relating to this implementation technique. See the Microsoft IPR notice on the IETF web site for the details. 3. upper layer protocol awareness of the inbound & outbound IPsec SA (where it doesn't use source IP and source port as the session identifier. E.g. L2TP session ID mapped to the IPsec SA pair which doesn't use the UDP source port or source IP address for peer uniqueness) 4. application integration with IKE initiation such that it can rebind to a different source port if the IKE quick mode SA proposal is rejected by the responder, then repropose the new QM selector. Microsoft may have intellectual property rights relating to this implementation technique. See the Microsoft IPR notice on the IETF web site for the details. 5. an initiator may decide not to request transport mode once NAT is detected and instead request a tunnel mode SA. This may be a retry after transport mode is denied by the responder, or it may be the initiator's choice to propose a tunnel SA initially. This is no more difficult than knowing whether to propose transport mode or tunnel mode without NAT. If for some reason the responder prefers or requires tunnel mode for NAT traversal, it must reject the quick mode SA proposal for transport mode. 6. don't support the scenario of multiple clients behind the same NAT simultaneously. Simply fail the second attempt at Main Mode or the Quick Mode. A NAT-OA payload in Quick Mode would certainly be helpful to discover uniqueness of clients behind NATs. But you could persist the Main Mode NAT-D payload hash to determine the difference between a Main Mode rekey (same hash) with a new MM from a different peer behind the same NAT (different hash). Accept only 1 concurrent IKE SA from the same private IP address, leave the incoming address alone in the IP header, but fix the pseudoheader checksum for TCP & UDP. If you support multiple Main Modes, then an initial contact notify payload sent under the protection of the ISAKMP SA is valid only for the identity of the initiator, to delete prior Main Modes from that same identity and any related QM state for those Main Modes. Cleanup action due to initial contact can not be taken based on the source IP address of the initiator. For ESP tunnel mode: 1. same NAT option above 2. same NAPT options above 3. it may be feasible in some scenarios for upper layers to know the IPsec SA, be it transport mode or tunnel mode. 4. if an initiator is capable of draft-ietf-ipsec-dhcp-13.txt, then it supports the capability of being assigned an address through it's tunnel SA with the responder. The initiator may initially request an internal address via the DHCP-IPsec method, regardless of whether it knows it is behind a NAT. Or it may re-initiate an IKE quick mode negotiation for DHCP tunnel SA after the responder fails the quick mode SA transport mode proposal, either when NAT-OA payload is sent or because it discovers from NAT-D the initiator is behind a NAT and it's local configuration/policy will only accept draft-ietf-ipsec-dhcp-13.txt method of connecting through NAT. 5. don't support the scenario. If the initiator proposes tunnel mode, the responder is under no obligation to perform NAT on the tunneled traffic or to support draft-ietf-ipsec-dhcp-13.txt for assigning an address to the initiator. Rather it is the initiator's decision based on it's capabilities and the scenario of usage and it's configuration how best to encapsulate traffic once NAT is detected. Vendor ID payloads may be used to advertise certain capabilities to the initiator that are vendor or implementation specific. I'm required to append this clause by our legal department since this talks about implementation techniques, and notes IPR issues with some of these techniques: This is to advise the IETF that Microsoft believes it may have patent rights (patent(s) and/or patent application(s) pending or soon to be filed) that relate to the technologies discussed in this submission. Microsoft is willing to negotiate licenses with interested parties to such patent rights as follows:   If part(s) of this contribution is(are) included in an IETF standard and Microsoft has patent rights that are essential to implement such standard, Microsoft is prepared to grant a license to the necessary claims of Microsoft patent rights, to the extent that such claims are required to implement that IETF standard, on a royalty-free basis with other reasonable and non-discriminatory terms and conditions, provided a reciprocal license is granted to Microsoft for any patent claims necessary to implement the following IETF nat traversal drafts: draft-ietf-ipsec-nat-t-ike-03.txt and draft-ietf-ipsec-udp-encaps-03.txt. Microsoft's contribution and the information contained herein is provided on an "AS IS" basis and the contributors and Microsoft Corporation DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.   Any questions regarding this communication should be directed to:               Microsoft Standards Group             c/o Dawna Hoerle             Microsoft Corporation             One Microsoft Way             Bldg. 114/2306             Redmond, WA 98052 From owner-ipsec@lists.tislabs.com Mon Jul 29 16:36:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TNaRw25940; Mon, 29 Jul 2002 16:36:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20033 Mon, 29 Jul 2002 18:56:03 -0400 (EDT) Date: 29 Jul 2002 18:55:23 -0400 Message-ID: <002901c23753$0702c330$0468e640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Henry Spencer'" Cc: "'IP Security List'" Subject: RE: Two AES encryption modes? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >The real > problem in terms of > > bandwidth consumption was permutation explosion, which has > also been solved > > in IKEv2. > > Unless I've missed something, the use of suites rather than individual > combinations of transforms -- which is precisely what we are > debating -- > is how that was solved. The problem with transforms is not > that they are > individually bulky, but that they come in swarms, not one at a time. I guess you did miss something. The permutation explosion was solved in IKEv2 by making the encoding more compact. Instead of: IKEv1: (3DES and SHA) or (3DES and MD5) or (AES and SHA) or (AES and MD5) you now have: IKEv2: (3DES or AES) and (SHA or MD5) whereas with assigned ciphersuites you would have: xxx: 3DES_SHA or 3DES_MD5 or AES_SHA or AES_MD5 Add an optional IPCOMP and it gets worse. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: Henry Spencer [mailto:henry@spsystems.net] > Sent: Monday, July 29, 2002 6:52 PM > To: Andrew Krywaniuk > Cc: 'IP Security List' > Subject: RE: Two AES encryption modes? > > > On 29 Jul 2002, Andrew Krywaniuk wrote: > > A typical transform payload (including the header) for > IKEv1 will run about > > 32 bytes for phase 1 and 24 bytes for phase 2. Eight bytes > of that is the SA > > lifetime, which has been omitted from IKEv2. The real > problem in terms of > > bandwidth consumption was permutation explosion, which has > also been solved > > in IKEv2. > > Unless I've missed something, the use of suites rather than individual > combinations of transforms -- which is precisely what we are > debating -- > is how that was solved. The problem with transforms is not > that they are > individually bulky, but that they come in swarms, not one at a time. > > > My claim is not so much that the cost is not important, but > rather that it > > will be drowned out by other factors... > > My claim is that you need to justify that more -- it's not a > self-evident > truth. > > > Henry Spencer > > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Mon Jul 29 16:49:50 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6TNnnw26867; Mon, 29 Jul 2002 16:49:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA20107 Mon, 29 Jul 2002 19:10:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Mon, 29 Jul 2002 16:23:38 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Fwd: Last Call: The Group Domain of Interpretation to Proposed Standard Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is of interest to this WG if anyone still cares about DOIs... >To: IETF-Announce: ; >Cc: msec@securemulticast.org >From: The IESG >SUBJECT: Last Call: The Group Domain of Interpretation to Proposed > Standard >Reply-to: iesg@ietf.org >Date: Mon, 29 Jul 2002 17:22:28 -0400 >Sender: scoya@cnri.reston.va.us > > >The IESG has received a request from the Multicast Security Working Group >to consider The Group Domain of Interpretation > as a Proposed Standard. > >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 August 12, 2002. > >Files can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-05.txt From owner-ipsec@lists.tislabs.com Mon Jul 29 19:14:28 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6U2ERw00541; Mon, 29 Jul 2002 19:14:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20449 Mon, 29 Jul 2002 21:30:10 -0400 (EDT) Message-Id: <200207300143.g6U1hKwV022982@mail2.trpz.com> To: iesg@ietf.org cc: msec@securemulticast.org, ipsec@lists.tislabs.com Subject: Re: Last Call: The Group Domain of Interpretation to Proposed Standard MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1982.1027993326.1@tibernian.com> Date: Mon, 29 Jul 2002 18:42:06 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This draft piggybacks on top of IKE (RFC2409) by defining a new "phase 2" exchange to be protected by an IKE Security Association established in a "phase 1" exchange. There is currently a moratorium on doing this as was explained by Marcus Leech (then co-AD) on behalf of himself, Jeff Schiller and Steve Bellovin in a "Position Statement" mailed on August 2nd 2001 and partially excerpted here: "Despite the obviously complex nature of IKE, several proposals have been put forward to extend ISAKMP/IKE in various ways, for various purposes. Proposals such as IKECFG, XAUTH, Hybrid-AUTH, CRACK, and others do nothing to improve the complexity situation with regard to IKE as a whole. While many of these proposals are, individually, based on sound engineering and reasonably prudent practice, when cast in the larger context of IKE, it seems clear that they can do nothing to improve the complexity picture. "It is with that in mind that the Security Area directors in the IETF, with the consultation of appropriate people on the IESG and IAB, hereby place a temporary moratorium on the addition of new features to IKE. It is fairly clear that work on IKE should focus on fixing identified weaknesses in the protocol, rather than adding features that detract from the goal of simplicity and correctness. "We are concerned that trying to reuse too much of the IKE code base in new protocols -- PIC and GDOI come to mind -- will lead to more complex (and hence vulnerable) implementations. We suggest that implementors resist this temptation, with the obvious exception of common library functions that perform functions such as large modular exponentiations. Attempts to share state or to optimize message exchanges are likely to lead to disaster." GDOI does indeed share state from IKE. It requires the authenticated and secret keys IKE derives, among other things (like "cookies", etc). It was even explicitly mentioned in the Position Statement as a source of concern. I urge the IESG to reject the request to advance this draft to Proposed Standard as it will lead to more complex and vulnerable implementations and "likely lead to disaster." Dan. On Mon, 29 Jul 2002 14:22:28 PDT you wrote > > The IESG has received a request from the Multicast Security Working Group > to consider The Group Domain of Interpretation > as a Proposed Standard. > > 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 August 12, 2002. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-05.txt From owner-ipsec@lists.tislabs.com Mon Jul 29 19:24:24 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6U2ONw00698; Mon, 29 Jul 2002 19:24:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20465 Mon, 29 Jul 2002 21:43:11 -0400 (EDT) Date: Mon, 29 Jul 2002 21:56:38 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: RE: Two AES encryption modes? In-Reply-To: <002901c23753$0702c330$0468e640@ca.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 29 Jul 2002, Andrew Krywaniuk wrote: > > Unless I've missed something, the use of suites rather than individual > > combinations of transforms -- which is precisely what we are > > debating -- is how that was solved... > > I guess you did miss something. The permutation explosion was solved in > IKEv2 by making the encoding more compact... Thanks, I did either miss that or forget about it. However, I think "solved" may be too strong a word; I'd say "reduced". > whereas with assigned ciphersuites you would have: > xxx: 3DES_SHA or 3DES_MD5 or AES_SHA or AES_MD5 You're assuming that there aren't any "SHOULD support" standard cipher suites, so it is still necessary to list all supported possibilities. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Jul 30 01:34:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6U8YDw01815; Tue, 30 Jul 2002 01:34:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA21202 Tue, 30 Jul 2002 03:46:19 -0400 (EDT) Message-Id: <3.0.3.32.20020730010011.015fe528@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Tue, 30 Jul 2002 01:00:11 -0700 To: uri@bell-labs.com From: Alex Alten Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Cc: ipsec@lists.tislabs.com In-Reply-To: <200207300009.UAA26060@nwmail.wh.lucent.com> References: <3.0.3.32.20020729155630.013bbfc8@mail> <3.0.3.32.20020729114222.015fdaa8@mail> <3.0.3.32.20020729155630.013bbfc8@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Uri, At 08:07 PM 7/29/2002 -0400, Uri Blumenthal wrote: >On Monday 29 July 2002 18:56, Alex Alten wrote: >> Thanks David, >> >> My misunderstanding of the IV generation details. I just read your >> other explanation of the secret starting offset for the IV sequence. >> In your/Fluher's design, is this offset generated separately from >> the key bits? > >Depending on how the key bits are generated, it may not matter. >For example, if the key bits are produced by a crypto-strong PRNG, >then the offset can be taken from that stream. [I admit that I >personally would prefer a different source, possibly with a different >keying of that same PRNG.] Otherwise, there can be a big problem. > >> What if the key is used repeatedly, or in the worst case shared >> among many hosts? > >Shouldn't matter - because anyway the key is used for more than one >packet. What does matter is that the combination of Key+IV never >repeats. Good random seeding should take care of it, I think. > Yes, but how do you get good random seeding? This requires much more frequent reseeding than keys themselves need rekeying. A PRNG cannot produce more entropy than the original seed bits. This means that for a given key a significant fraction of the encrypted IV+cntr blocks from session to session will be likely to repeat. >> What happens if a host reboots? Does the secret >> offset start at the same initial value? If not, how do you >> guarentee this? > >Good questions. > >I'd say - seeding the generating PRNG with /dev/random output >after host reboot should give a reasonably good assurance. > >> BTW, I'm not completely clear on this aspect. Does the sender >> completely control the IV sequence generation? > >He better! OK. What if he's a $300 IPsec box? What guarentee do you have that the IV sequence generation is done well? What quality of random source can be expected on this low-end device? > >> Can the receiver process incoming packets out-of-order or handle >> dropped packets? > >Again, he better. What about fragmented packets? Regards, - Alex >-- >Regards, >Uri-David >-=-=-<>-=-=- > > -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Tue Jul 30 06:17:31 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UDHVw20781; Tue, 30 Jul 2002 06:17:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21734 Tue, 30 Jul 2002 08:28:56 -0400 (EDT) From: "David A. Mcgrew" To: "Alex Alten" Cc: Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Tue, 30 Jul 2002 05:43:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3.0.3.32.20020729155630.013bbfc8@mail> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex, > -----Original Message----- > From: Alex Alten [mailto:Alten@attbi.com] > Sent: Monday, July 29, 2002 3:57 PM > To: David A. Mcgrew > Cc: ipsec@lists.tislabs.com > Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt > > > Thanks David, > > My misunderstanding of the IV generation details. I just read your > other explanation of the secret starting offset for the IV sequence. > In your/Fluher's design, is this offset generated separately from > the key bits? no, it would be generated along with the key. In IKE, the counter mode key would be taken from the KEYMAT, then split into the AES Key and Offset fields. > > What if the key is used repeatedly, or in the worst case shared > among many hosts? What happens if a host reboots? Does the secret > offset start at the same initial value? If not, how do you > guarentee this? The Offset is defined to be part of the key, so if a key is reused, then the Offset is reused, and so forth. I think that your concern is over how a device can ensure that the IVs are unique. This is a point that deserves some attention (and of course is independent of the use of an offset field). A device can use checkpointing to ensure that it doesn't use the same IV value twice. Jesse Walker wrote a short description of periodic checkpointing and how it can be used in counter mode to address your concern, in a recent discussion on using that mode. It might be good to include something like that in a counter mode ESP draft. If the same counter mode key is used to encrypt traffic by two distinct senders, then some other mechanism is needed in order to ensure that keystream segments are disjoint. This can be done by including a field in the counter which has a distinct value for each distinct sender. Using a "sender id" field like this does allow the same counter mode key to be used by multiple encryptors while preserving security. In draft-ietf-ipsec-ciph-aes-ctr-00.txt, the lower 24 bits of the SPI are included in the counter. This field could be used as a sender-id, though doing so would mean that the same key would be used in different SAs. I'm not sure if the draft intends for the truncated SPI field to be used in this way. It's clear that using a single key to protect both directions of a duplex connection is intended, though I'm not sure what else is. There are some caveats with using the same key in multiple senders. The mechanism by which the sender-id values are generated and distributed must guarantee their uniqueness. The limitation that no more than 2^64 blocks can be encrypted must be coordinated across all senders, so that the limit is enforced on the sum total number of blocks encrypted. And of course the mechanism by which the keys are distributed must be secure. One advantage to using a single key for some number N of senders is that storage for N keys is saved. However, it's important to realize that the other information normally associated with an SA (which at a bare minimum includes the 64 bit sequence number and possibly some other 64 bits of information used to generate the IV) must still be stored. In some devices, all N values of the other SA data must be stored. So sharing keys across multiple senders can be penny-wise but pound-foolish, except in some extreme circumstances. Another case in which sharing a key across multiple senders can have an advantage is when its easier to distribute a single key, e.g. using a multicast channel. > > I think these questions still are valid even if you combine the > offset with the ESP sequence number and SPI (since these may > repeat also). WEP broke down with it's failure to answer these > sorts of questions. Agreed. > > BTW, I'm not completely clear on this aspect. Does the sender > completely control the IV sequence generation? Can the receiver > process incoming packets out-of-order or handle dropped packets? Yes, out-of-order packets can be dealt with. The counter mode definition in Russ's draft generates a keystream segment for each packet, essentially mapping an IV (and a secret key) to a particular segment of keystream. The order in which the segments are generated is unimportant. Security follows from the fact that the segments are disjoint and the IVs don't repeat. Regards, David > > (Russ, I guess I'm responding to my internal mental "gestalt" of > the various emails flying around. :-) > > Regards, > > - Alex > > > At 02:19 PM 7/29/2002 -0700, David A. Mcgrew wrote: > >Alex, > > > >> -----Original Message----- > >> From: owner-ipsec@lists.tislabs.com > >> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Alex Alten > >> Sent: Monday, July 29, 2002 11:42 AM > >> To: Housley, Russ; David A. Mcgrew > >> Cc: ipsec@lists.tislabs.com > >> Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt > >> > >> > >> At 09:59 AM 7/29/2002 -0400, Housley, Russ wrote: > >> >[Klaus] > >> >> > yes, I agree with you, I can not see any reason to use an > >> external IV for > >> >> > AES CTR if algorithms easy can be defined for internal > >> building of IV's > >> >> with > >> >> > ESP sequence number and SPI. The only cryptographic > >> requirement for the > >> >> > sequence of IV's is, that all the counter values, derived > >> from all the > >> IV's > >> >> > over all the ESP packets, transformed by AES, are different > >> as long as > >> one > >> >> > fixed key is used. > >> > > >> >[David] > >> >>that's right. Additionally, some additional strength against > >> attacks which > >> >>rely on precomputation of a database to use during the attack > >> stage can be > >> >>gained by having the part of the counter be secret. > >> > > >> >We have discussed the inclusion of a secret component in the > >> counter. It > >> >complicates the key management by requiring an additional secret > >> value to > >> >be managed. If one is concerned about this type of dictionary > >> attack, the > >> >use of a longer AES key provides more protection without imposing > >> >additional requirements on key management. > >> > > >> >Russ > >> > > >> > >> I believe someone already has stated the problem will be to prevent the > >> counter > >> from repeating (or being predictable) with the same key. It's > entropy in > >> practice > >> may be fairly low. Also, there may be the fairly likely danger > >> of shared keys > >> across multiple hosts which is deadly if any IV values > commonly repeat on > >> different hosts (this helped to kill WEP). I think this is the > >> crux of the > >> matter, > >> and I don't think this can be solved with a software PRNG > >> algorithm. What I'd > >> recommend is to try to pull it from hardware, like the Intel > P4 supporting > >> chipset. > >> If this is not possible maybe a large random seed can be placed on each > >> host, and > >> the PRNG is then used to pseudo-randomly mix/fold the seed > bits. One can > >> get quite > >> a few "unpredictable" random IV values that way. There will be an > >> exponential > >> decay in unpredictableness, but hopefull you can start high > enough up on > >> the curve > >> for it to useful. Eventually the seed would need to be > refreshed, but if > >> it is > >> infrequent enough it could be done by hand. The large seed > should remain > >> secret > >> during its lifetime otherwise it will be subject to an inverse matrix > >> precomputation > >> attack. It would be ideal if the PRNG had a large set of random small > >> seeds available > >> to it as well, so that the start of it's cycle per new session would be > >> unpredictable > >> (it too needs to be refreshed periodically). > > > >I think that the discussion is somewhat hard to follow, my > apologies for the > >terseness of the mail that started this thread. > > > >Russ' draft requires distinct IV values, which implies that a > deterministic > >mechanism must be used to produce them. The use of a true random number > >generator, as you'd suggest, would generate repeat values after 2^32 > >packets, with a high probability. Given the fact that using the same IV > >value twice in counter mode gives away the exor of the > plaintexts, this is > >something that we want to avoid. > > > >Russ and I are in agreement that counter mode should be implemented using > >IVs generated by a deterministic algorithm. What I was proposing is that > >additional security against attacks which use precomputation (e.g. > >key-collision and time-memory tradeoff attacks) by making part of the > >counter secret, so that the adversary does not know all of the > inputs to the > >AES cipher that are used to generate a particular range of keystream. > > > >David > > > > > -- > > Alex Alten > Alten@ATTBI.com > From owner-ipsec@lists.tislabs.com Tue Jul 30 07:14:49 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UEEmw26226; Tue, 30 Jul 2002 07:14:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA21986 Tue, 30 Jul 2002 09:31:34 -0400 (EDT) From: Lev.Finkel@ecitele.com Subject: [IPSec] : exchange mode - query To: ipsec@lists.tislabs.com Cc: Oleg.Litvak@ecitele.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Tue, 30 Jul 2002 09:22:26 +0300 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 07/30/2002 09:22:31 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, in the security consideration of some Internet drafts (e.g. Diameter) I found the statement that "When pre-shared keys are used for authentication, IKE Aggressive Mode SHOULD be used, and IKE Main Mode SHOULD NOT be used". Can someone explain why it's not recommended to use Main Mode with pre-shared keys? It will be nice to have a reference to such explanation in other docs. with regards, Lev Finkel From owner-ipsec@lists.tislabs.com Tue Jul 30 07:14:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UEErw26240; Tue, 30 Jul 2002 07:14:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA21979 Tue, 30 Jul 2002 09:30:35 -0400 (EDT) Date: Mon, 29 Jul 2002 16:18:00 -0400 From: "David R. Oran" To: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Message-ID: <1188236073.1027959480@OranLT.cisco.com> X-Mailer: Mulberry/3.0.0a3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not a crypto person, and I don't play one on TV. A message from this thread got forwarded to me, asking that I provide some background on one small item - whether short packets wrapped up in UDP/IP were common and important enough to be concerned about packet expansion of about 8 bytes. The following is snipped from the relevant message (which I believe was posted by Steve Kent, although I don't have the whole context so I can't be sure): > I also am surprised that you cite a 20-byte "packet" size for RTP as > an example. The 20 byte size makes an 8-byte IV seem very large > indeed. But the 20-byte size is misleading, at best. Do these packets > have no IP header? How about a UDP header. How about an ESP header & > authentication trailer? How about the need to pad the ESP payload to > a 4 byte boundary, which in this case adds 4 bytes to the payload? By > the time you add all of these parts of the overall packet to the > original 20-byte payload, the 8-byte IV is not so big an overhead > anymore. Either your arithmetic is very sloppy, or you are being > disingenuous. > There are a large number of deployed VoIP systems using Codecs like g.729 or G.723 and 20 ms. packetization period. This produces packets with a payload size of 10 bytes. When you add in the overhead of RTP, UDP, and IP this gives a total link TU of 60 bytes (20+8+12+10). Relative to 60 bytes, and 8 byte expansion is not all that large, but this is not the end of the story. People using high compression gain coders ALSO deploy CRTP, which does RTP+UDP+IP header compression, reducing the overhead to about 4 bytes (assuming PPP), and hence a 8 byte expansion is once again a significant amount of overhead. In the context of the current discussion, a naive IPSEC ESP encapsulation would negate nearly all of the compression gain (only the outer IP header would get compressed), so people have envisaged things like TCRTP to do the inner (IP+UDP+RTP compression first). Even with such tricks, the overhead of ESP is large for such applications. Which is one reason some of us went off and designed SRTP... Please forgive me if all of this is well known and understood by the IPSEC community. Dave. From owner-ipsec@lists.tislabs.com Tue Jul 30 07:19:47 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UEJkw26444; Tue, 30 Jul 2002 07:19:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA21980 Tue, 30 Jul 2002 09:30:35 -0400 (EDT) Cc: ipsec@lists.tislabs.com Message-Id: <200207300009.UAA26060@nwmail.wh.lucent.com> Content-Type: text/plain; charset="koi8-r" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: Alex Alten Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Mon, 29 Jul 2002 20:07:26 -0400 X-Mailer: KMail [version 1.3.2] Original-Cc: References: <3.0.3.32.20020729114222.015fdaa8@mail> <3.0.3.32.20020729155630.013bbfc8@mail> In-Reply-To: <3.0.3.32.20020729155630.013bbfc8@mail> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA20254 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Monday 29 July 2002 18:56, Alex Alten wrote: > Thanks David, > > My misunderstanding of the IV generation details. I just read your > other explanation of the secret starting offset for the IV sequence. > In your/Fluher's design, is this offset generated separately from > the key bits? Depending on how the key bits are generated, it may not matter. For example, if the key bits are produced by a crypto-strong PRNG, then the offset can be taken from that stream. [I admit that I personally would prefer a different source, possibly with a different keying of that same PRNG.] Otherwise, there can be a big problem. > What if the key is used repeatedly, or in the worst case shared > among many hosts? Shouldn't matter - because anyway the key is used for more than one packet. What does matter is that the combination of Key+IV never repeats. Good random seeding should take care of it, I think. > What happens if a host reboots? Does the secret > offset start at the same initial value? If not, how do you > guarentee this? Good questions. I'd say - seeding the generating PRNG with /dev/random output after host reboot should give a reasonably good assurance. > BTW, I'm not completely clear on this aspect. Does the sender > completely control the IV sequence generation? He better! > Can the receiver process incoming packets out-of-order or handle > dropped packets? Again, he better. -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Tue Jul 30 07:53:29 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UErTw27213; Tue, 30 Jul 2002 07:53:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22075 Tue, 30 Jul 2002 09:42:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20020730065043.04afccb8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Jul 2002 06:53:47 -0700 To: Dan Harkins From: Mark Baugher Subject: Re: Last Call: The Group Domain of Interpretation to Proposed Standard Cc: iesg@ietf.org, msec@securemulticast.org, ipsec@lists.tislabs.com In-Reply-To: <200207300143.g6U1hKwV022982@mail2.trpz.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan GDOI is not subject to ipsec moritoriums since it is a product of msec. You cite Steve Bellovin and Jeff Schiller. Steve is reviewing GDOI for us. Mark At 06:42 PM 7/29/2002 -0700, Dan Harkins wrote: > This draft piggybacks on top of IKE (RFC2409) by defining a new "phase 2" >exchange to be protected by an IKE Security Association established >in a "phase 1" exchange. There is currently a moratorium on doing this >as was explained by Marcus Leech (then co-AD) on behalf of himself, >Jeff Schiller and Steve Bellovin in a "Position Statement" mailed on >August 2nd 2001 and partially excerpted here: > > "Despite the obviously complex nature of IKE, several proposals have > been put forward to extend ISAKMP/IKE in various ways, for various > purposes. Proposals such as IKECFG, XAUTH, Hybrid-AUTH, CRACK, and > others do nothing to improve the complexity situation with regard to > IKE as a whole. While many of these proposals are, individually, > based on sound engineering and reasonably prudent practice, when cast > in the larger context of IKE, it seems clear that they can do nothing > to improve the complexity picture. > > "It is with that in mind that the Security Area directors in the IETF, > with the consultation of appropriate people on the IESG and IAB, hereby > place a temporary moratorium on the addition of new features to IKE. > It is fairly clear that work on IKE should focus on fixing identified > weaknesses in the protocol, rather than adding features that detract > from the goal of simplicity and correctness. > > "We are concerned that trying to reuse too much of the IKE > code base in new protocols -- PIC and GDOI come to mind -- > will lead to more complex (and hence vulnerable) implementations. > We suggest that implementors resist this temptation, with the > obvious exception of common library functions that perform > functions such as large modular exponentiations. Attempts > to share state or to optimize message exchanges are likely to > lead to disaster." > > GDOI does indeed share state from IKE. It requires the authenticated and >secret keys IKE derives, among other things (like "cookies", etc). It was >even explicitly mentioned in the Position Statement as a source of >concern. > > I urge the IESG to reject the request to advance this draft to Proposed >Standard as it will lead to more complex and vulnerable implementations >and "likely lead to disaster." > > Dan. > >On Mon, 29 Jul 2002 14:22:28 PDT you wrote > > > > The IESG has received a request from the Multicast Security Working Group > > to consider The Group Domain of Interpretation > > as a Proposed Standard. > > > > 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 August 12, 2002. > > > > Files can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-05.txt From owner-ipsec@lists.tislabs.com Tue Jul 30 08:17:39 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UFHcw27857; Tue, 30 Jul 2002 08:17:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22170 Tue, 30 Jul 2002 10:10:19 -0400 (EDT) Message-Id: <200207301406.KAA08853@nwmail.wh.lucent.com> Content-Type: text/plain; charset="koi8-r" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: Alex Alten Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Tue, 30 Jul 2002 10:04:30 -0400 X-Mailer: KMail [version 1.3.2] Cc: ipsec@lists.tislabs.com References: <3.0.3.32.20020729155630.013bbfc8@mail> <3.0.3.32.20020730010011.015fe528@mail> In-Reply-To: <3.0.3.32.20020730010011.015fe528@mail> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA22105 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tuesday 30 July 2002 04:00, Alex Alten wrote: > Hello Uri, Hi there! > >> What if the key is used repeatedly, or in the worst case shared > >> among many hosts? > > > >Shouldn't matter - because anyway the key is used for more than one > >packet. What does matter is that the combination of Key+IV never > >repeats. Good random seeding should take care of it, I think. > > Yes, but how do you get good random seeding? >From /dev/random on Unix. Let Windows people figure out for themselves. (:-) > This requires much > more frequent reseeding than keys themselves need rekeying. Huh? I don't get it. A PRNG once primed, can run for a long time, perhaps even until the next reboot. And in any case, /dev/random is there to provide when n eeded. > A PRNG > cannot produce more entropy than the original seed bits. PRNG isn't supposed to produce more entropy - just practically uncorrelated (with the actual entropy strength of uncorrelation) stream of bits. So what's new here and why is it an issue? You seem to be mixing the ultimate strength of the algorithm (which is not greater than the actual entropy of the key) with the practical correlation of the output bits. Example: PRNG is Rijndael in OFB mode. Key size is 256 bits. The actual entropy of that key is 102 bits. Used to produce 2MB of PR bits to encrypt 2MB of data. And 2MB more of PR bits to key another cipher suite. In this scenario what's the problem you were talking about? > This means > that for a given key a significant fraction of the encrypted IV+cntr > blocks from session to session will be likely to repeat. Depends on the PRNG of course - but shouldn't be any more likely to repeat than the output stream itself. BTW, who speaks of encrypted IV? > >> BTW, I'm not completely clear on this aspect. Does the sender > >> completely control the IV sequence generation? > > > >He better! > > OK. What if he's a $300 IPsec box? What guarentee do you have > that the IV sequence generation is done well? If it has hardware like that mentioned in RFC 1750 and software that follows that RFC - it's good enough for me. If it doesn't - I don't know. > What quality of random > source can be expected on this low-end device? See above. Plus, IV doesn't REALLY have to be random. It's something people are talking about now because of the threat brought up by S. Fluhrer when more than one user sits on one SA. Such a low-end device isn't very likely to run multiuser... As for the _really_ small devices (such as cell phones) - I'm investigating it now. > >> Can the receiver process incoming packets out-of-order or handle > >> dropped packets? > > > >Again, he better. > > What about fragmented packets? Good question - I don't know (and let somebody else worry about it, so feel free to offer suggestions :-). -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Tue Jul 30 08:48:08 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UFm7w28772; Tue, 30 Jul 2002 08:48:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22313 Tue, 30 Jul 2002 11:02:10 -0400 (EDT) From: "Housley, Russ" To: Scott Fluhrer Cc: Gregory Lebovitz , "'Paul Hoffman / VPNC'" , ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020730111338.0347eeb0@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Jul 2002 11:15:40 -0400 Subject: RE: Two AES encryption modes? In-Reply-To: <200207250342.AFR68985@mira-sjcm-3.cisco.com> References: <541402FFDC56DA499E7E13329ABFEA87060C6D@SARATOGA> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott: Thanks for updating your analysis. >Speed of Software Implementation: > >Both transforms can be executed in approximately the same speed. >However, both CBC and COUNTER also require authentication transforms to >be executed. In this area, I think that it is worth pointing out that the COUNTER key stream can be precomputed (at least on the encryptor side). While authentication must be performed when the packet is available, the key stream can be precomputed to allow for reduced latency. Russ From owner-ipsec@lists.tislabs.com Tue Jul 30 08:50:18 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UFoIw28854; Tue, 30 Jul 2002 08:50:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22314 Tue, 30 Jul 2002 11:02:11 -0400 (EDT) From: "Housley, Russ" To: "David A. Mcgrew" Cc: ipsec@lists.tislabs.com, sfluhrer@cisco.com Message-Id: <5.1.0.14.2.20020730090200.02142cf8@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Jul 2002 09:16:06 -0400 Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: References: <5.1.0.14.2.20020729095412.02ecbc90@exna07.securitydynamics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David: > > [Klaus] > > > > yes, I agree with you, I can not see any reason to use an external > IV for > > > > AES CTR if algorithms easy can be defined for internal building of > IV's with > > > > ESP sequence number and SPI. The only cryptographic requirement for the > > > > sequence of IV's is, that all the counter values, derived from all > the IV's > > > > over all the ESP packets, transformed by AES, are different as long > as one > > > > fixed key is used. > > > > [David] > > >that's right. Additionally, some additional strength against attacks > which > > >rely on precomputation of a database to use during the attack stage can be > > >gained by having the part of the counter be secret. > > > > We have discussed the inclusion of a secret component in the counter. It > > complicates the key management by requiring an additional secret value to > > be managed. > >I disagree with the supposition that including a secret component in the >counter complicates key management. I'll explain what I'm thinking; please >let me know if or where your assumptions are different. > >One simple way in which counter mode can include a secret component is to >define that value to be part of the key. This method allows counter mode to >use a secret component in the counter, while hiding that fact from a key >management protocol. > >For example, define the format of the counter key to look like: > > +---------------+------------+ > | AES Key | Offset | > +---------------+------------+ > >where "Offset" is the secret counter component. The AES Key field would >have a fixed length (as the draft has a distinct IANA transform number for >each AES key length). The Offset could be fixed length (which is certainly >simpler), or could have a variable length if that proves desirable. In any >case, a variable-length Offset field would not introduce any ambiguity. > >The counter mode ESP transform gets to define what its key looks like; the >above definition is perfectly valid. IKE is quite capable of dealing with >the format above, since it can work with any key length cipher in ESP. I >defer to Scott Fluhrer for more details, as he's implemented what I've >described here (which he and I worked out in the summer of y2k, to give >credit where it is due). > >I certainly agree that it would be overly complicated to expect a key >management system to manage the 'secret counter component' as a distinct >data type. But there's no reason to do that, since the simple key format >described above works just as well. I fear that perhaps this point has been >a source of miscommunication between us in the past. I agree that managing one secret value that is divided into two components within the encryption transform does not add any complication to the key management protocol. To the key management protocol, it appears to be one large key. > > If one is concerned about this type of dictionary attack, the > > use of a longer AES key provides more protection > >Yes, this is completely true. Using a bigger AES key also provides >protection against precomputation attacks. However, this approach has some >disadvantages. The computational cost of AES is greater for the 192-bit key >and 256-bit key versions, by 20% and 40% respectively, making this approach >less efficient than that of using a random offset. Also, a number of >current AES implementations do not include the larger key sizes, and thus >could not use this approach. If I understood Scott Fluhrer's follow-up message correctly, the use of 128-bit AES key coupled with an offset still only provides 128 bits of strength. Thus, the larger AES key sizes (and the additional rounds associated with them that account for the bulk of the added computational cost) are providing significantly more protection than the offset. >In summary, my reasons for preferring the inclusion of a 'secret counter >component' are that 1) it adds a significant amount of security against >precomputation attacks, 2) it adds little or no computational cost, and 3) >it fits easily into the current architecture. I understood these points from our discussions before I published the draft. As you know, I have spoken to Ron Rivest about this concept. He feels strongly that the use of a longer key is the correct countermeasure to precomputation attacks. This is the reason that I included all three AES key sizes in the draft. Russ From owner-ipsec@lists.tislabs.com Tue Jul 30 08:59:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UFxDw29053; Tue, 30 Jul 2002 08:59:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22315 Tue, 30 Jul 2002 11:02:12 -0400 (EDT) From: "Housley, Russ" To: "David A. Mcgrew" Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020730092306.0345bf68@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Jul 2002 10:23:08 -0400 Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David: Thank you for the careful reading of the draft. See my responses below. >I have several comments on draft-ietf-ipsec-ciph-aes-ctr-00.txt. It's >clearly written and I value the effort that you've made to get the >job done and establish some sort of compromise. However, there are >two points on which the draft can be improved: packet expansion and >strength against precomputation attacks. In the following, I lay out >some arguments in favor of an implicit (rather than an explicit) IV, >discuss interoperability with other counter mode versions, and mention >some other points. > >First, a correction to the Security Section. In the last paragraph of >Section 6, the draft is right to state that no more than 2^64 blocks >should be encrypted with any fixed key. But the draft implies that >this limitation can be avoided if implementations "make use of the >longer AES key sizes." This is not right, the 2^64 limit applies to >all key sizes. It does not apply to larger block sizes; however, the >AES spec doesn't include the larger RIJDNAEL block sizes. In the same >vein, the sentence "Additionally, AES with a 128-bit key is vulnerable >to the birthday attack after 2^64 blocks" should read "Additionally, >AES is vulnerable...". You are correct. I propose the following replacement paragraph: Additionally, since AES has a 128-bit block size, regardless of the mode employed, AES is vulnerable to a birthday attack after 2^64 blocks are encrypted with a single key. Since ESP with Enhanced Sequence Numbers allows for up to 2^64 packets in a single security association (SA), there is real potential for more than 2^64 blocks to be encrypted with one key. Implementations SHOULD generate a fresh key before 2^64 blocks are encrypted with the same key. Note that ESP with 32-bit Sequence Numbers will not exceed 2^64 blocks even if all of the packets are maximum-length Jumbograms. >On the subject of packet expansion, the draft requires the use of an >explicit IV that is eight bytes long and states that this overhead is >acceptable. I disagree. Counter mode has the opportunity to provide >zero expansion, and at Cisco we've regarded this property as >important. The consumption of eight bytes per packet can have a >significant impact on bandwidth, especially for protocols with short >packets like voice over IP (RFC 1889). For example, RTP with the >G.729 codec (as is commonly used) carries only twenty bytes of data >per packet. This protocol is often used with link-layer header >compression over WAN links (e.g. RFC2508); these compression methods >are quite efficient, making the bandwidth degradation due to >uncompressible fields (like the explicit IV) pronounced. > >I think that the zero-expansion property is important enough that I >want to comment on the points that the rationale presents in favor of >an explicit IV: > > Point 4. "The assignment of the per-packet counter block value > needs to be inside the assurance boundary. Some implementations > assign the sequence number inside the assurance boundary, but others > do not." What implementations maintain the ESP sequence number > outside of the security perimeter? Cisco does not do this, nor do > any of the several of crypto hardware suppliers that we use. > > Counter mode ESP would be far simpler and more bandwidth efficient > if the ESP sequence number were used as the per-packet counter > value. In addition, other cryptographic mechanisms that require a > nonce can use the sequence number for that purpose, if we are > allowed to assume that the sequence number is actually unique. > These mechanisms include ciphers like SEAL and Wegman-Carter based > MACs like MMH. It's worth noting that we've implemented SEAL > encryption using ESP, as described in the Stream Cipher ESP; this > draft is now expired, but went through three revisions without this > point about the sequence number and assurance boundary being raised. > (The old draft is online at > www.mindspring.com/~dmcgrew/draft-mcgrew-ipsec-scesp-02.txt if > you're interested, and we'd be fine with re-issuing the draft were > there is interest from other implementers.) > > > Point 2. "Adders are simple and straightforward to implement, but > due to carries, they do not execute in constant time. LSFRs offer > an alternative that executes in constant time." However, the > per-block increment operation is far more time critical than the > per-packet increment operation! Since the block counter is a > monotonically increasing integer, and it's presumably fast enough, > it's hard to see how the fact cited in the draft supports the use of > LFSRs for the per-packet field. > > > Point 1. "... there is no advantage to selecting a mechanism that > allows the decryptor to determine whether counter block values > collide. Damage from the collision is done, whether the decryptor > detects it or not." Yes, but the detection of a malfunctioning ESP > sender could enable an administrator to shut off the errant device. > Either the ESP CTR receiver or a passive security monitoring device > such as a network IDS system can detect ESP sequence number re-use. > When is the delayed detection of the failure of a security system > worse than no detection? > >I don't disagree with Point 3 and Points 5 and 6 follow from the >others. > >I would be surprised if other implementers in the WG favored the use >of an unspecified explicit IV over the use of the sequence number as >an implicit IV. At any rate, I think we've discussed the points well >enough to allow others in the WG to chime in. This debate has been the focus of the discussion between you and Steve Kent. A few others have offered opinions, but the vast majority of the WG has remained silent. One notable exception is the posting from David Black, who offered support for the explicit IV. So far, I do not see a consensus for overloading the semantics of the sequence number. However, I am sure the debate is not over yet. >On to other topics. The draft says in Section 6 that AES CTR MUST NOT >be used with statically configured keys. I certainly agree that this >is a good thing. However, RFC2401 requires implementations to support >such keys, saying "This document requires support for both manual and >automatic distribution of keys." Perhaps that RFC means that manual >keying be provided only for some ciphers (the mandatory to implement >ones?). At any rate, it would be good for the WG to decide what is >meant and to document it somewhere. (The Stream Cipher ESP draft hit >this same issue). It is my understanding that RFC 2401bis is being made more flexible in this area. Are you suggesting that the AES-CTR document should reference RFC 2401bis instead of RFC 2401? >On the subject of interoperability, the AES CTR draft could be >implemented using draft-mcgrew-saag-icm-00.txt (the generic counter >mode draft that I wrote last November, which also lines up with the >AES CTR variant in draft-ietf-avt-srtp-05.txt), if the spec were bent >hard enough. This bending would consist of defining the 'initial >offset' to be equal to (flags, truncated_spi), and of course throwing >the explicit IV in front of the ciphertext. All of the AES CTR specs >that I've seen have managed to agree that the per-block counter be a >big-endian integer in the least significant bits of the counter, which >probably ensures that implementations can share keystream-generation >components. > >OTOH, while the closeness of the various AES CTR specifications is a >good thing, the fact that the initial offset is not random has a >negative security impact. The WG may decide that it prefers >simplicity to strength against precomputation attacks. If so, fine, >but this subject needs to be discussed in the rationale. The content of the Rationale section comes from the email discussion regarding my proposed compromise. The major issue at that time was Explicit IVs, so it is not surprising that other aspects of the design rationale are slighted. First, I propose the following additional paragraph in the Security Considerations section: There are fairly generic precomputation attacks against all block cipher modes that allow a meet-in-the-middle attack against the key. These attacks require the creation and searching of huge tables of ciphertext associated with known plaintext and known keys. Assuming that the memory and processor resources are available for a precomputation attack, then the theoretical strength of AES-CTR (and any other block cipher mode) is limited to 2^(n/2) bits, where n is the number of bits in the key. The use of long keys is the best countermeasure to precomputation attacks. Therefore, implementations that employ 128-bit AES keys should take precautions to make the precomputation attacks more difficult. The concatenation of the Flags, Truncated SPI, and IV fields within the counter block can be thought of as a per-packet nonce. Repeated use of the same nonce value (even with different keys) ought to be avoided. One approach is to randomly assign SPI values; however, since the only 24 bits of the SPI are included in the nonce, a random SPI value provides limited additional security. I hope that this very brief description of precomputation attacks is sufficient. Next, I propose the following additional paragraph for the rationale section: No explicit countermeasures against precomputation attacks are included in the counter block construction. The use of long keys is the usual countermeasure to these attacks, and AES offers key sizes that thwart these attacks for many decades to come. >In Section 6 the draft says: > > "Thus, to avoid counter block collisions, ESP implementations that > permit use of the same key for encrypting and decrypting packets > with the same peer MUST ensure that the two peers assign different > SPI values to the security association (SA)." > >Is it actually kosher for two SAs to share the same keys? SAs are >simplex per RFC 2401, though they could in principle share a single >key. However, I'd expect that if the architecture allowed such >key-sharing that it would require that the SAs be in the same SA >bundle so that when one SA reaches it usage limit its twin gets >deleted as well. I'm not aware of any such language, which makes me >suspicious about using the same keys twice. I tried to point out that IKE would not generate such an SA. However, there are serious security concerns if the same key streams are used for encryption and decryption. I just wanted to make sure that no one did such a thing! >Now for the real nit: at the bottom of page 7, a typo: "It is >inappropriate to use this m AES-CTR" This will be fixed in the -01 draft. Russ From owner-ipsec@lists.tislabs.com Tue Jul 30 08:59:25 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UFxOw29065; Tue, 30 Jul 2002 08:59:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22312 Tue, 30 Jul 2002 11:02:04 -0400 (EDT) From: "Housley, Russ" To: "David A. Mcgrew" Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020730085158.0345f418@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Jul 2002 08:56:28 -0400 Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David: I want to respond to one point that was raised by your exchange with Steve Kent. > > Apparently Cisco has > > chosen to offer only low assurance IPsec products, e.g,. FIPS level 2 > > at most, so the security perimeter is very large and thus the > > sequence number can be maintained within that boundary. But, to > > impose this assurance-limiting architecture on vendors who might wish > > to offer higher security implementations is inappropriate. > >What ESP implementations don't maintain the sequence number within the >security perimeter? I am not aware of any. If you are, please let us >know. The consequences for reusing a sequence number are significantly different than the consequence of reusing a CTR mode key stream. Therefore, I think that it is worth a few extra bits of overhead to make sure that the per-packet value is managed inside the security boundary. Russ From owner-ipsec@lists.tislabs.com Tue Jul 30 09:03:20 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UG3Jw29150; Tue, 30 Jul 2002 09:03:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22383 Tue, 30 Jul 2002 11:16:13 -0400 (EDT) From: "Housley, Russ" To: Alex Alten Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020730112906.034dfd70@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Jul 2002 11:29:25 -0400 Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: <3.0.3.32.20020729155630.013bbfc8@mail> References: <3.0.3.32.20020729114222.015fdaa8@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:56 PM 7/29/2002 -0700, Alex Alten wrote: >BTW, I'm not completely clear on this aspect. Does the sender >completely control the IV sequence generation? Can the receiver >process incoming packets out-of-order or handle dropped packets? Yes. And, Yes. Russ From owner-ipsec@lists.tislabs.com Tue Jul 30 09:07:01 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UG71w29230; Tue, 30 Jul 2002 09:07:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22374 Tue, 30 Jul 2002 11:15:10 -0400 (EDT) Message-ID: <29B5A21C13C8D51190F900805F65B4EC39F575@rndex50.ottawa.mitel.com> From: "Dilkie, Lee" To: "'David R. Oran'" , ipsec@lists.tislabs.com Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Tue, 30 Jul 2002 11:28:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Which is one reason some of us went off and designed SRTP... Thank goodness someone said it. I've been biting my tongue since this thread started. Yes, the 8 bytes of IV *are* significient. SRTPs solution to use existing information in the packet to generate an implicit IV (and you avoid IV reuse too) and avoid *any* packet expansion is key to not wasting bandwidth and is absolutely necessary if you want to encourage(push) encryption of media streams (VoIP especially). Is it important that IPsec use implicit IVs? It would help but IPsec has other overheads that expands the packet already and you could well argue that it wouldn't make much of a difference (and therby justify SRTPs original reason for existance... that IPsec is just too big to use for VoIP). Do some math. One T1 (24 voice channels if configured for PSTN, 32 for european T1), 1536000 bps (more for our european friends). I'm ignoring media transport overhead, these numbers are better than they would be in real life. (assuming 20ms (50 fps) RTP packets, no header compression) G.729, 60 byte TU , 64 voice "channels" G.729, 68 byte TU (explicit IV), 56 voice "channels" (dunno 'bout you, but that 13 percent overhead seems significient to me) G.711(uncompressed), 210 byte TU, 18 "channels" (unhappy customer, gets less than PSTN T1) Things get better with header compression. Now try the same math with IPsec encrypted packets... -lee From owner-ipsec@lists.tislabs.com Tue Jul 30 09:19:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UGJjw29736; Tue, 30 Jul 2002 09:19:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22490 Tue, 30 Jul 2002 11:35:32 -0400 (EDT) X-Sent: 30 Jul 2002 15:48:53 GMT Message-ID: <0a9801c237e0$921be9a0$4864a8c0@VAIO> From: "Qiang Zhang" To: , Cc: References: Subject: Re: [IPSec] : exchange mode - query Date: Tue, 30 Jul 2002 11:48:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In mainmode, the responder has to use the initiators Source IP address in the IP header as identifier to search for preshared secret in the database. Thus not suitable for remote access scenarios. Q ----- Original Message ----- From: To: Cc: Sent: Tuesday, July 30, 2002 2:22 AM Subject: [IPSec] : exchange mode - query > Hi all, > > in the security consideration of some Internet drafts (e.g. Diameter) I > found the statement that "When pre-shared keys are used for authentication, > IKE Aggressive Mode SHOULD be used, and IKE Main Mode SHOULD NOT be used". > Can someone explain why it's not recommended to use Main Mode with > pre-shared keys? It will be nice to have a reference to such explanation in > other docs. > > with regards, > Lev Finkel > > From owner-ipsec@lists.tislabs.com Tue Jul 30 09:42:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UGg6w01822; Tue, 30 Jul 2002 09:42:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22442 Tue, 30 Jul 2002 11:28:20 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1056BF00A@win-msg-01.wingroup.windeploy.nt dev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC1056BF00A@win-msg-01.wingroup.windeploy.nt dev.microsoft.com> Date: Tue, 30 Jul 2002 08:41:38 -0700 To: "Brian Swander" , From: Paul Hoffman / VPNC Subject: Re: Clarification of potential NAT multiple client solutions Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thank you for the quite useful list of alternatives. And thank you for listing the believed IPR issues for them. This makes things much clearer to implementers. At 4:01 PM -0700 7/29/02, Brian Swander wrote: >As this isn't a wire protocol matter, but a local implementation >matter, specification of the mechanisms do not belong in the draft >itself. Now that I have seen the list, I would disagree. That section of the current document feels like a bit of hand-waving, and having this list there (or at least in an appendix) would clear up some of that. This is particularly important because when a user cannot set up an SA, the UI will probably give some reasoning that will likely be different between different vendors because they chose different strategies. Having this material available to all implementers in the eventual standard would be valuable. And, yes, you should keep in the IPR stuff, at least to mark the items for which IPR notices have been registered with the IETF. You don't have to say who or what, simply "An IPR notice for this options has been received by the IETF". --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jul 30 09:53:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UGr5w02097; Tue, 30 Jul 2002 09:53:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22607 Tue, 30 Jul 2002 12:00:03 -0400 (EDT) Date: Tue, 30 Jul 2002 12:13:50 -0400 (EDT) From: Henry Spencer To: Lev.Finkel@ecitele.com cc: ipsec@lists.tislabs.com Subject: Re: [IPSec] : exchange mode - query In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 30 Jul 2002 Lev.Finkel@ecitele.com wrote: > in the security consideration of some Internet drafts (e.g. Diameter) I > found the statement that "When pre-shared keys are used for authentication, > IKE Aggressive Mode SHOULD be used, and IKE Main Mode SHOULD NOT be used". > Can someone explain why it's not recommended to use Main Mode with > pre-shared keys? This is almost certainly the well-known protocol bug in Main Mode, which makes it impossible to examine any identity payloads sent by the other end until after you (somehow) pick the right preshared key. Given that you'd like to pick the key based on the other end's identity, and all you have to go on is its IP address (which is not always informative), this is awkward. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Jul 30 11:27:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UIRUw07924; Tue, 30 Jul 2002 11:27:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23010 Tue, 30 Jul 2002 13:36:24 -0400 (EDT) Message-Id: <200207301749.g6UHn6wV025743@mail2.trpz.com> To: Mark Baugher cc: iesg@ietf.org, msec@securemulticast.org, ipsec@lists.tislabs.com Subject: Re: Last Call: The Group Domain of Interpretation to Proposed Standard In-Reply-To: Your message of "Tue, 30 Jul 2002 06:53:47 PDT." <4.3.2.7.2.20020730065043.04afccb8@mira-sjc5-6.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <500.1028051042.1@tibernian.com> Date: Tue, 30 Jul 2002 10:47:51 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It is not an ipsec moratorium. That Position Statement applied to ipsra as well. It was a statement by the Area Directors of the Security Area of the IETF (which is where msec is) not a statement by the chairs of the IPsec Working Group. It explicitly said that GDOI will lead to "more complex and vulnerable implementations" and, since it undeniably shares IKE state, "to disaster". Nothing changed since that statement was made to nullify it. So if it was the position of _your_ Area Directors (who consulted the appropriate people in the IESG and IAB) then it must surely be their position now. Dan. On Tue, 30 Jul 2002 06:53:47 PDT you wrote > Dan > GDOI is not subject to ipsec moritoriums since it is a product of > msec. You cite Steve Bellovin and Jeff Schiller. Steve is reviewing GDOI > for us. > > Mark > At 06:42 PM 7/29/2002 -0700, Dan Harkins wrote: > > This draft piggybacks on top of IKE (RFC2409) by defining a new "phase 2" > >exchange to be protected by an IKE Security Association established > >in a "phase 1" exchange. There is currently a moratorium on doing this > >as was explained by Marcus Leech (then co-AD) on behalf of himself, > >Jeff Schiller and Steve Bellovin in a "Position Statement" mailed on > >August 2nd 2001 and partially excerpted here: > > > > "Despite the obviously complex nature of IKE, several proposals have > > been put forward to extend ISAKMP/IKE in various ways, for various > > purposes. Proposals such as IKECFG, XAUTH, Hybrid-AUTH, CRACK, and > > others do nothing to improve the complexity situation with regard to > > IKE as a whole. While many of these proposals are, individually, > > based on sound engineering and reasonably prudent practice, when cast > > in the larger context of IKE, it seems clear that they can do nothing > > to improve the complexity picture. > > > > "It is with that in mind that the Security Area directors in the IETF, > > with the consultation of appropriate people on the IESG and IAB, hereby > > place a temporary moratorium on the addition of new features to IKE. > > It is fairly clear that work on IKE should focus on fixing identified > > weaknesses in the protocol, rather than adding features that detract > > from the goal of simplicity and correctness. > > > > "We are concerned that trying to reuse too much of the IKE > > code base in new protocols -- PIC and GDOI come to mind -- > > will lead to more complex (and hence vulnerable) implementations. > > We suggest that implementors resist this temptation, with the > > obvious exception of common library functions that perform > > functions such as large modular exponentiations. Attempts > > to share state or to optimize message exchanges are likely to > > lead to disaster." > > > > GDOI does indeed share state from IKE. It requires the authenticated and > >secret keys IKE derives, among other things (like "cookies", etc). It was > >even explicitly mentioned in the Position Statement as a source of > >concern. > > > > I urge the IESG to reject the request to advance this draft to Proposed > >Standard as it will lead to more complex and vulnerable implementations > >and "likely lead to disaster." > > > > Dan. > > > >On Mon, 29 Jul 2002 14:22:28 PDT you wrote > > > > > > The IESG has received a request from the Multicast Security Working Group > > > to consider The Group Domain of Interpretation > > > as a Proposed Standard. > > > > > > 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 August 12, 2002. > > > > > > Files can be obtained via > > > http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-05.txt > From owner-ipsec@lists.tislabs.com Tue Jul 30 11:53:15 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UIrFw08381; Tue, 30 Jul 2002 11:53:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23082 Tue, 30 Jul 2002 14:08:45 -0400 (EDT) Message-ID: <3D46D93A.1101E851@cisco.com> Date: Tue, 30 Jul 2002 11:21:46 -0700 From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: iesg@ietf.org, msec@securemulticast.org, ipsec@lists.tislabs.com Subject: Re: Last Call: The Group Domain of Interpretation to Proposed Standard References: <200207300143.g6U1hKwV022982@mail2.trpz.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd like to address a couple of common misconceptions about GDOI. Dan Harkins wrote: > > This draft piggybacks on top of IKE (RFC2409) by defining a new "phase 2" > exchange to be protected by an IKE Security Association established > in a "phase 1" exchange. There is currently a moratorium on doing this > as was explained by Marcus Leech (then co-AD) on behalf of himself, > Jeff Schiller and Steve Bellovin in a "Position Statement" mailed on > August 2nd 2001 and partially excerpted here: GDOI does not actually define a new phase 2 of IKE. It does use IKE protocol definitions and structures. The GDOI protocol itself however seeks to separate itself from IKE in the following ways: * Uses a DOI which is discrete from the IPSEC DOI * Uses a different port (the draft specifies "MUST NOT run on port 500") * Specifies no additions to the namespaces or described in RFC 2407 or changes to the protocols described in RFC 2409 This is a new protocol, not an update to IKE. Brian > "Despite the obviously complex nature of IKE, several proposals have > been put forward to extend ISAKMP/IKE in various ways, for various > purposes. Proposals such as IKECFG, XAUTH, Hybrid-AUTH, CRACK, and > others do nothing to improve the complexity situation with regard to > IKE as a whole. While many of these proposals are, individually, > based on sound engineering and reasonably prudent practice, when cast > in the larger context of IKE, it seems clear that they can do nothing > to improve the complexity picture. > > "It is with that in mind that the Security Area directors in the IETF, > with the consultation of appropriate people on the IESG and IAB, hereby > place a temporary moratorium on the addition of new features to IKE. > It is fairly clear that work on IKE should focus on fixing identified > weaknesses in the protocol, rather than adding features that detract > from the goal of simplicity and correctness. > > "We are concerned that trying to reuse too much of the IKE > code base in new protocols -- PIC and GDOI come to mind -- > will lead to more complex (and hence vulnerable) implementations. > We suggest that implementors resist this temptation, with the > obvious exception of common library functions that perform > functions such as large modular exponentiations. Attempts > to share state or to optimize message exchanges are likely to > lead to disaster." > > GDOI does indeed share state from IKE. It requires the authenticated and > secret keys IKE derives, among other things (like "cookies", etc). It was > even explicitly mentioned in the Position Statement as a source of > concern. > > I urge the IESG to reject the request to advance this draft to Proposed > Standard as it will lead to more complex and vulnerable implementations > and "likely lead to disaster." > > Dan. > > On Mon, 29 Jul 2002 14:22:28 PDT you wrote > > > > The IESG has received a request from the Multicast Security Working Group > > to consider The Group Domain of Interpretation > > as a Proposed Standard. > > > > 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 August 12, 2002. > > > > Files can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-05.txt -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From owner-ipsec@lists.tislabs.com Tue Jul 30 11:54:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UIshw08412; Tue, 30 Jul 2002 11:54:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23061 Tue, 30 Jul 2002 14:01:39 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Subject: RE: Clarification of potential NAT multiple client solutions Date: Tue, 30 Jul 2002 11:09:40 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1083884FF@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Clarification of potential NAT multiple client solutions thread-index: AcI35XcKOpZNN1X3SOCR67WKPAQ0vgADkNtQ From: "William Dixon" To: "Paul Hoffman / VPNC" , "Brian Swander" , X-OriginalArrivalTime: 30 Jul 2002 18:08:34.0877 (UTC) FILETIME=[1ED74ED0:01C237F4] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, are suggesting that new error codes for notifies and the notify behavior be added to the nat-t spec as well ? The authors had consensus that we didn't want to do this. There are a lot of reasons why a quick mode might not be accepted irregardless of nat-t. And since notifies were optional anyway, we didn't see the need to add them to distinguish between failures due to different implementation techniques. -----Original Message----- From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] Sent: Tuesday, July 30, 2002 8:42 AM To: Brian Swander; ipsec@lists.tislabs.com Subject: Re: Clarification of potential NAT multiple client solutions Thank you for the quite useful list of alternatives. And thank you for listing the believed IPR issues for them. This makes things much clearer to implementers. At 4:01 PM -0700 7/29/02, Brian Swander wrote: >As this isn't a wire protocol matter, but a local implementation >matter, specification of the mechanisms do not belong in the draft >itself. Now that I have seen the list, I would disagree. That section of the current document feels like a bit of hand-waving, and having this list there (or at least in an appendix) would clear up some of that. This is particularly important because when a user cannot set up an SA, the UI will probably give some reasoning that will likely be different between different vendors because they chose different strategies. Having this material available to all implementers in the eventual standard would be valuable. And, yes, you should keep in the IPR stuff, at least to mark the items for which IPR notices have been registered with the IETF. You don't have to say who or what, simply "An IPR notice for this options has been received by the IETF". --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jul 30 12:53:52 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UJrqw12054; Tue, 30 Jul 2002 12:53:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23376 Tue, 30 Jul 2002 15:09:07 -0400 (EDT) Content-Class: urn:content-classes:message Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 MIME-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-ID: In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1056BF00A@win-msg-01.wingroup.windeploy.nt dev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC1056BF00A@win-msg-01.wingroup.windeploy.nt dev.microsoft.com> Date: Tue, 30 Jul 2002 08:41:38 -0700 To: "Brian Swander" , From: "Paul Hoffman / VPNC" Subject: Re: Clarification of potential NAT multiple client solutions Content-Type: text/plain; format=flowed; charset="us-ascii" X-OriginalArrivalTime: 30 Jul 2002 17:00:03.0684 (UTC) FILETIME=[8C610A40:01C237EA] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thank you for the quite useful list of alternatives. And thank you for listing the believed IPR issues for them. This makes things much clearer to implementers. At 4:01 PM -0700 7/29/02, Brian Swander wrote: >As this isn't a wire protocol matter, but a local implementation >matter, specification of the mechanisms do not belong in the draft >itself. Now that I have seen the list, I would disagree. That section of the current document feels like a bit of hand-waving, and having this list there (or at least in an appendix) would clear up some of that. This is particularly important because when a user cannot set up an SA, the UI will probably give some reasoning that will likely be different between different vendors because they chose different strategies. Having this material available to all implementers in the eventual standard would be valuable. And, yes, you should keep in the IPR stuff, at least to mark the items for which IPR notices have been registered with the IETF. You don't have to say who or what, simply "An IPR notice for this options has been received by the IETF". --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jul 30 12:53:53 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UJrqw12055; Tue, 30 Jul 2002 12:53:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23343 Tue, 30 Jul 2002 15:06:04 -0400 (EDT) Content-Class: urn:content-classes:message Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 From: "Housley, Russ" To: "Alex Alten" Cc: Message-ID: <5.1.0.14.2.20020730112906.034dfd70@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Jul 2002 11:29:25 -0400 Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: <3.0.3.32.20020729155630.013bbfc8@mail> References: <3.0.3.32.20020729114222.015fdaa8@mail> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" X-OriginalArrivalTime: 30 Jul 2002 16:15:01.0839 (UTC) FILETIME=[41F435F0:01C237E4] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:56 PM 7/29/2002 -0700, Alex Alten wrote: >BTW, I'm not completely clear on this aspect. Does the sender >completely control the IV sequence generation? Can the receiver >process incoming packets out-of-order or handle dropped packets? Yes. And, Yes. Russ From owner-ipsec@lists.tislabs.com Tue Jul 30 12:53:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UJruw12077; Tue, 30 Jul 2002 12:53:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23358 Tue, 30 Jul 2002 15:08:06 -0400 (EDT) Content-Class: urn:content-classes:message X-Sent: 30 Jul 2002 15:48:53 GMT Message-ID: <0a9801c237e0$921be9a0$4864a8c0@VAIO> From: "Qiang Zhang" To: , Cc: References: Subject: Re: [IPSec] : exchange mode - query Date: Tue, 30 Jul 2002 11:48:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-OriginalArrivalTime: 30 Jul 2002 16:38:24.0176 (UTC) FILETIME=[85CFDB00:01C237E7] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In mainmode, the responder has to use the initiators Source IP address in the IP header as identifier to search for preshared secret in the database. Thus not suitable for remote access scenarios. Q ----- Original Message ----- From: To: Cc: Sent: Tuesday, July 30, 2002 2:22 AM Subject: [IPSec] : exchange mode - query > Hi all, > > in the security consideration of some Internet drafts (e.g. Diameter) I > found the statement that "When pre-shared keys are used for authentication, > IKE Aggressive Mode SHOULD be used, and IKE Main Mode SHOULD NOT be used". > Can someone explain why it's not recommended to use Main Mode with > pre-shared keys? It will be nice to have a reference to such explanation in > other docs. > > with regards, > Lev Finkel > > From owner-ipsec@lists.tislabs.com Tue Jul 30 12:53:57 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UJrvw12079; Tue, 30 Jul 2002 12:53:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23337 Tue, 30 Jul 2002 15:03:01 -0400 (EDT) Message-Id: <200207301915.g6UJF5wV032034@mail2.trpz.com> To: Brian Weis cc: iesg@ietf.org, msec@securemulticast.org, ipsec@lists.tislabs.com Subject: Re: Last Call: The Group Domain of Interpretation to Proposed Standard In-Reply-To: Your message of "Tue, 30 Jul 2002 11:21:46 PDT." <3D46D93A.1101E851@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <769.1028056430.1@tibernian.com> Date: Tue, 30 Jul 2002 12:13:50 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You say it does not "define a new phase 2 of IKE" yet the introduction says, "The Phase 2 exchange is defined in this document...." You point out how no namespace changes to RFC2407 or RFC2409 are specified but leave out the changes to RFC2408 that are required. You mention that GDOI uses a different port yet all the problems and concerns regarding IKE that were laid out in the Position Statement do not vanish if IKE is run on a transport other than UDP port 500. But all these are red herrings. The key fact is that it shares considerable state with IKE. It also requires an IKE SA to protect the phase 2 exchange you define (despite your protests to the contrary) in the document. To quote section 6.1: "GDOI uses the Phase 1 exchanges defined in [RFC2409] to protect the GROUPKEY-PULL exchange. Therefore all security properties and considerations of those exchanges (as noted in [RFC2409]) are relevant for GDOI." It's all those security properties that are not supposed to be shared according to the Position Statement. GDOI does nothing to improve the complexity situation by grafting itself onto IKE, it merely inherits all the complexity and concerns that are giving people the heebie-geebies today. That should be indisputable. And that should be cause for rejection of GDOI as a Proposed Standard. Dan. On Tue, 30 Jul 2002 11:21:46 PDT you wrote > I'd like to address a couple of common misconceptions about GDOI. > > GDOI does not actually define a new phase 2 of IKE. It does use IKE > protocol definitions and structures. The GDOI protocol itself however > seeks to separate itself from IKE in the following ways: > > * Uses a DOI which is discrete from the IPSEC DOI > * Uses a different port (the draft specifies "MUST NOT run on port 500") > * Specifies no additions to the namespaces or described in RFC 2407 or > changes to the protocols described in RFC 2409 > > This is a new protocol, not an update to IKE. > > Brian > From owner-ipsec@lists.tislabs.com Tue Jul 30 12:59:45 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UJxiw12188; Tue, 30 Jul 2002 12:59:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23461 Tue, 30 Jul 2002 15:15:13 -0400 (EDT) Date: Tue, 30 Jul 2002 12:13:50 -0400 (EDT) From: Henry Spencer To: Lev.Finkel@ecitele.com cc: ipsec@lists.tislabs.com Subject: Re: [IPSec] : exchange mode - query In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 30 Jul 2002 17:07:49.0937 (UTC) FILETIME=[A2499A10:01C237EB] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 30 Jul 2002 Lev.Finkel@ecitele.com wrote: > in the security consideration of some Internet drafts (e.g. Diameter) I > found the statement that "When pre-shared keys are used for authentication, > IKE Aggressive Mode SHOULD be used, and IKE Main Mode SHOULD NOT be used". > Can someone explain why it's not recommended to use Main Mode with > pre-shared keys? This is almost certainly the well-known protocol bug in Main Mode, which makes it impossible to examine any identity payloads sent by the other end until after you (somehow) pick the right preshared key. Given that you'd like to pick the key based on the other end's identity, and all you have to go on is its IP address (which is not always informative), this is awkward. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Jul 30 13:01:38 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UK1cw12246; Tue, 30 Jul 2002 13:01:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23464 Tue, 30 Jul 2002 15:15:17 -0400 (EDT) Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: <200207301406.KAA08853@nwmail.wh.lucent.com> Content-Type: text/plain; charset="koi8-r" From: "Uri Blumenthal" Reply-To: Organization: Lucent Technologies / Bell Labs To: "Alex Alten" Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Tue, 30 Jul 2002 10:04:30 -0400 X-Mailer: KMail [version 1.3.2] Cc: References: <3.0.3.32.20020729155630.013bbfc8@mail> <3.0.3.32.20020730010011.015fe528@mail> In-Reply-To: <3.0.3.32.20020730010011.015fe528@mail> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA22105 X-OriginalArrivalTime: 30 Jul 2002 15:34:22.0276 (UTC) FILETIME=[93DC7040:01C237DE] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tuesday 30 July 2002 04:00, Alex Alten wrote: > Hello Uri, Hi there! > >> What if the key is used repeatedly, or in the worst case shared > >> among many hosts? > > > >Shouldn't matter - because anyway the key is used for more than one > >packet. What does matter is that the combination of Key+IV never > >repeats. Good random seeding should take care of it, I think. > > Yes, but how do you get good random seeding? >From /dev/random on Unix. Let Windows people figure out for themselves. (:-) > This requires much > more frequent reseeding than keys themselves need rekeying. Huh? I don't get it. A PRNG once primed, can run for a long time, perhaps even until the next reboot. And in any case, /dev/random is there to provide when n eeded. > A PRNG > cannot produce more entropy than the original seed bits. PRNG isn't supposed to produce more entropy - just practically uncorrelated (with the actual entropy strength of uncorrelation) stream of bits. So what's new here and why is it an issue? You seem to be mixing the ultimate strength of the algorithm (which is not greater than the actual entropy of the key) with the practical correlation of the output bits. Example: PRNG is Rijndael in OFB mode. Key size is 256 bits. The actual entropy of that key is 102 bits. Used to produce 2MB of PR bits to encrypt 2MB of data. And 2MB more of PR bits to key another cipher suite. In this scenario what's the problem you were talking about? > This means > that for a given key a significant fraction of the encrypted IV+cntr > blocks from session to session will be likely to repeat. Depends on the PRNG of course - but shouldn't be any more likely to repeat than the output stream itself. BTW, who speaks of encrypted IV? > >> BTW, I'm not completely clear on this aspect. Does the sender > >> completely control the IV sequence generation? > > > >He better! > > OK. What if he's a $300 IPsec box? What guarentee do you have > that the IV sequence generation is done well? If it has hardware like that mentioned in RFC 1750 and software that follows that RFC - it's good enough for me. If it doesn't - I don't know. > What quality of random > source can be expected on this low-end device? See above. Plus, IV doesn't REALLY have to be random. It's something people are talking about now because of the threat brought up by S. Fluhrer when more than one user sits on one SA. Such a low-end device isn't very likely to run multiuser... As for the _really_ small devices (such as cell phones) - I'm investigating it now. > >> Can the receiver process incoming packets out-of-order or handle > >> dropped packets? > > > >Again, he better. > > What about fragmented packets? Good question - I don't know (and let somebody else worry about it, so feel free to offer suggestions :-). -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Tue Jul 30 13:02:13 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UK2Cw12266; Tue, 30 Jul 2002 13:02:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23465 Tue, 30 Jul 2002 15:15:19 -0400 (EDT) Content-Class: urn:content-classes:message Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 From: "Housley, Russ" To: "David A. Mcgrew" Cc: , Message-ID: <5.1.0.14.2.20020730090200.02142cf8@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Jul 2002 09:16:06 -0400 Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: References: <5.1.0.14.2.20020729095412.02ecbc90@exna07.securitydynamics.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" X-OriginalArrivalTime: 30 Jul 2002 16:03:28.0756 (UTC) FILETIME=[A4D82340:01C237E2] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David: > > [Klaus] > > > > yes, I agree with you, I can not see any reason to use an external > IV for > > > > AES CTR if algorithms easy can be defined for internal building of > IV's with > > > > ESP sequence number and SPI. The only cryptographic requirement for the > > > > sequence of IV's is, that all the counter values, derived from all > the IV's > > > > over all the ESP packets, transformed by AES, are different as long > as one > > > > fixed key is used. > > > > [David] > > >that's right. Additionally, some additional strength against attacks > which > > >rely on precomputation of a database to use during the attack stage can be > > >gained by having the part of the counter be secret. > > > > We have discussed the inclusion of a secret component in the counter. It > > complicates the key management by requiring an additional secret value to > > be managed. > >I disagree with the supposition that including a secret component in the >counter complicates key management. I'll explain what I'm thinking; please >let me know if or where your assumptions are different. > >One simple way in which counter mode can include a secret component is to >define that value to be part of the key. This method allows counter mode to >use a secret component in the counter, while hiding that fact from a key >management protocol. > >For example, define the format of the counter key to look like: > > +---------------+------------+ > | AES Key | Offset | > +---------------+------------+ > >where "Offset" is the secret counter component. The AES Key field would >have a fixed length (as the draft has a distinct IANA transform number for >each AES key length). The Offset could be fixed length (which is certainly >simpler), or could have a variable length if that proves desirable. In any >case, a variable-length Offset field would not introduce any ambiguity. > >The counter mode ESP transform gets to define what its key looks like; the >above definition is perfectly valid. IKE is quite capable of dealing with >the format above, since it can work with any key length cipher in ESP. I >defer to Scott Fluhrer for more details, as he's implemented what I've >described here (which he and I worked out in the summer of y2k, to give >credit where it is due). > >I certainly agree that it would be overly complicated to expect a key >management system to manage the 'secret counter component' as a distinct >data type. But there's no reason to do that, since the simple key format >described above works just as well. I fear that perhaps this point has been >a source of miscommunication between us in the past. I agree that managing one secret value that is divided into two components within the encryption transform does not add any complication to the key management protocol. To the key management protocol, it appears to be one large key. > > If one is concerned about this type of dictionary attack, the > > use of a longer AES key provides more protection > >Yes, this is completely true. Using a bigger AES key also provides >protection against precomputation attacks. However, this approach has some >disadvantages. The computational cost of AES is greater for the 192-bit key >and 256-bit key versions, by 20% and 40% respectively, making this approach >less efficient than that of using a random offset. Also, a number of >current AES implementations do not include the larger key sizes, and thus >could not use this approach. If I understood Scott Fluhrer's follow-up message correctly, the use of 128-bit AES key coupled with an offset still only provides 128 bits of strength. Thus, the larger AES key sizes (and the additional rounds associated with them that account for the bulk of the added computational cost) are providing significantly more protection than the offset. >In summary, my reasons for preferring the inclusion of a 'secret counter >component' are that 1) it adds a significant amount of security against >precomputation attacks, 2) it adds little or no computational cost, and 3) >it fits easily into the current architecture. I understood these points from our discussions before I published the draft. As you know, I have spoken to Ron Rivest about this concept. He feels strongly that the use of a longer key is the correct countermeasure to precomputation attacks. This is the reason that I included all three AES key sizes in the draft. Russ From owner-ipsec@lists.tislabs.com Tue Jul 30 13:02:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UK2iw12280; Tue, 30 Jul 2002 13:02:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23525 Tue, 30 Jul 2002 15:19:19 -0400 (EDT) Content-Class: urn:content-classes:message Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 From: "Housley, Russ" To: "Scott Fluhrer" Cc: "Gregory Lebovitz" , "'Paul Hoffman / VPNC'" , Message-ID: <5.1.0.14.2.20020730111338.0347eeb0@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Jul 2002 11:15:40 -0400 Subject: RE: Two AES encryption modes? In-Reply-To: <200207250342.AFR68985@mira-sjcm-3.cisco.com> References: <541402FFDC56DA499E7E13329ABFEA87060C6D@SARATOGA> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" X-OriginalArrivalTime: 30 Jul 2002 16:34:14.0580 (UTC) FILETIME=[F10A8740:01C237E6] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott: Thanks for updating your analysis. >Speed of Software Implementation: > >Both transforms can be executed in approximately the same speed. >However, both CBC and COUNTER also require authentication transforms to >be executed. In this area, I think that it is worth pointing out that the COUNTER key stream can be precomputed (at least on the encryptor side). While authentication must be performed when the packet is available, the key stream can be precomputed to allow for reduced latency. Russ From owner-ipsec@lists.tislabs.com Tue Jul 30 13:02:46 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UK2kw12292; Tue, 30 Jul 2002 13:02:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23526 Tue, 30 Jul 2002 15:19:23 -0400 (EDT) Message-Id: <3.0.3.32.20020730123238.015fe528@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Tue, 30 Jul 2002 12:32:38 -0700 To: "Dilkie, Lee" , "'David R. Oran'" , ipsec@lists.tislabs.com From: Alex Alten Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: <29B5A21C13C8D51190F900805F65B4EC39F575@rndex50.ottawa.mite l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dilkie, Every since last call many years ago I have made it clear to this WG that I felt IPsec was too complex. It needs to go everywhere that IPv4 goes. Shimming in another protocol header makes that ideal goal impossible. IPsec will never be able to support in a practice many types of transport, application or routing/error/discovery protocols. It is time that we sit back and re-examine it. Instead of putting the extraordinary efforts into a new key exchange protocol, adding new ciphers, co-existing with NATs, etc., let us seriously consider a complete redesign. My understanding of the two arts is such that I am certain we could retrofit IPv4 in such a manner as to satisfy your needs as well as many others. We really need an elegant, simple, system solution that preserves the huge legacy infrastructure that rides on top of IPv4. Design goal #1 should be no new bytes added into or inserted after the IPv4 header. There I've said it. The emperor has no clothes. - Alex At 11:28 AM 7/30/2002 -0400, Dilkie, Lee wrote: >> Which is one reason some of us went off and designed SRTP... > >Thank goodness someone said it. I've been biting my tongue since this >thread started. Yes, the 8 bytes of IV *are* significient. SRTPs solution >to use existing information in the packet to generate an implicit IV (and >you avoid IV reuse too) and avoid *any* packet expansion is key to not >wasting bandwidth and is absolutely necessary if you want to encourage(push) >encryption of media streams (VoIP especially). > >Is it important that IPsec use implicit IVs? It would help but IPsec has >other overheads that expands the packet already and you could well argue >that it wouldn't make much of a difference (and therby justify SRTPs >original reason for existance... that IPsec is just too big to use for VoIP). > >Do some math. > >One T1 (24 voice channels if configured for PSTN, 32 for european T1), >1536000 bps (more for our european friends). I'm ignoring media transport >overhead, these numbers are better than they would be in real life. > >(assuming 20ms (50 fps) RTP packets, no header compression) > >G.729, 60 byte TU , 64 voice "channels" >G.729, 68 byte TU (explicit IV), 56 voice "channels" (dunno 'bout you, but >that 13 percent overhead seems significient to me) > >G.711(uncompressed), 210 byte TU, 18 "channels" (unhappy customer, gets >less than PSTN T1) > >Things get better with header compression. > >Now try the same math with IPsec encrypted packets... > > >-lee > -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Tue Jul 30 13:03:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UK3vw12317; Tue, 30 Jul 2002 13:03:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23495 Tue, 30 Jul 2002 15:18:24 -0400 (EDT) Content-Class: urn:content-classes:message Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 From: "Housley, Russ" To: "David A. Mcgrew" Cc: Message-ID: <5.1.0.14.2.20020730085158.0345f418@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Jul 2002 08:56:28 -0400 Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" X-OriginalArrivalTime: 30 Jul 2002 16:11:32.0087 (UTC) FILETIME=[C4EE9870:01C237E3] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David: I want to respond to one point that was raised by your exchange with Steve Kent. > > Apparently Cisco has > > chosen to offer only low assurance IPsec products, e.g,. FIPS level 2 > > at most, so the security perimeter is very large and thus the > > sequence number can be maintained within that boundary. But, to > > impose this assurance-limiting architecture on vendors who might wish > > to offer higher security implementations is inappropriate. > >What ESP implementations don't maintain the sequence number within the >security perimeter? I am not aware of any. If you are, please let us >know. The consequences for reusing a sequence number are significantly different than the consequence of reusing a CTR mode key stream. Therefore, I think that it is worth a few extra bits of overhead to make sure that the per-packet value is managed inside the security boundary. Russ From owner-ipsec@lists.tislabs.com Tue Jul 30 13:04:51 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UK4pw12338; Tue, 30 Jul 2002 13:04:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23533 Tue, 30 Jul 2002 15:20:18 -0400 (EDT) Content-Class: urn:content-classes:message Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: <29B5A21C13C8D51190F900805F65B4EC39F575@rndex50.ottawa.mitel.com> From: "Dilkie, Lee" To: "'David R. Oran'" , Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Tue, 30 Jul 2002 11:28:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 30 Jul 2002 16:19:38.0950 (UTC) FILETIME=[E71FFE60:01C237E4] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Which is one reason some of us went off and designed SRTP... Thank goodness someone said it. I've been biting my tongue since this thread started. Yes, the 8 bytes of IV *are* significient. SRTPs solution to use existing information in the packet to generate an implicit IV (and you avoid IV reuse too) and avoid *any* packet expansion is key to not wasting bandwidth and is absolutely necessary if you want to encourage(push) encryption of media streams (VoIP especially). Is it important that IPsec use implicit IVs? It would help but IPsec has other overheads that expands the packet already and you could well argue that it wouldn't make much of a difference (and therby justify SRTPs original reason for existance... that IPsec is just too big to use for VoIP). Do some math. One T1 (24 voice channels if configured for PSTN, 32 for european T1), 1536000 bps (more for our european friends). I'm ignoring media transport overhead, these numbers are better than they would be in real life. (assuming 20ms (50 fps) RTP packets, no header compression) G.729, 60 byte TU , 64 voice "channels" G.729, 68 byte TU (explicit IV), 56 voice "channels" (dunno 'bout you, but that 13 percent overhead seems significient to me) G.711(uncompressed), 210 byte TU, 18 "channels" (unhappy customer, gets less than PSTN T1) Things get better with header compression. Now try the same math with IPsec encrypted packets... -lee From owner-ipsec@lists.tislabs.com Tue Jul 30 13:07:55 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UK7tw12377; Tue, 30 Jul 2002 13:07:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23527 Tue, 30 Jul 2002 15:19:25 -0400 (EDT) Content-Class: urn:content-classes:message Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 From: "Housley, Russ" To: "David A. Mcgrew" Cc: Message-ID: <5.1.0.14.2.20020730092306.0345bf68@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Jul 2002 10:23:08 -0400 Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" X-OriginalArrivalTime: 30 Jul 2002 16:12:21.0494 (UTC) FILETIME=[E2618160:01C237E3] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David: Thank you for the careful reading of the draft. See my responses below. >I have several comments on draft-ietf-ipsec-ciph-aes-ctr-00.txt. It's >clearly written and I value the effort that you've made to get the >job done and establish some sort of compromise. However, there are >two points on which the draft can be improved: packet expansion and >strength against precomputation attacks. In the following, I lay out >some arguments in favor of an implicit (rather than an explicit) IV, >discuss interoperability with other counter mode versions, and mention >some other points. > >First, a correction to the Security Section. In the last paragraph of >Section 6, the draft is right to state that no more than 2^64 blocks >should be encrypted with any fixed key. But the draft implies that >this limitation can be avoided if implementations "make use of the >longer AES key sizes." This is not right, the 2^64 limit applies to >all key sizes. It does not apply to larger block sizes; however, the >AES spec doesn't include the larger RIJDNAEL block sizes. In the same >vein, the sentence "Additionally, AES with a 128-bit key is vulnerable >to the birthday attack after 2^64 blocks" should read "Additionally, >AES is vulnerable...". You are correct. I propose the following replacement paragraph: Additionally, since AES has a 128-bit block size, regardless of the mode employed, AES is vulnerable to a birthday attack after 2^64 blocks are encrypted with a single key. Since ESP with Enhanced Sequence Numbers allows for up to 2^64 packets in a single security association (SA), there is real potential for more than 2^64 blocks to be encrypted with one key. Implementations SHOULD generate a fresh key before 2^64 blocks are encrypted with the same key. Note that ESP with 32-bit Sequence Numbers will not exceed 2^64 blocks even if all of the packets are maximum-length Jumbograms. >On the subject of packet expansion, the draft requires the use of an >explicit IV that is eight bytes long and states that this overhead is >acceptable. I disagree. Counter mode has the opportunity to provide >zero expansion, and at Cisco we've regarded this property as >important. The consumption of eight bytes per packet can have a >significant impact on bandwidth, especially for protocols with short >packets like voice over IP (RFC 1889). For example, RTP with the >G.729 codec (as is commonly used) carries only twenty bytes of data >per packet. This protocol is often used with link-layer header >compression over WAN links (e.g. RFC2508); these compression methods >are quite efficient, making the bandwidth degradation due to >uncompressible fields (like the explicit IV) pronounced. > >I think that the zero-expansion property is important enough that I >want to comment on the points that the rationale presents in favor of >an explicit IV: > > Point 4. "The assignment of the per-packet counter block value > needs to be inside the assurance boundary. Some implementations > assign the sequence number inside the assurance boundary, but others > do not." What implementations maintain the ESP sequence number > outside of the security perimeter? Cisco does not do this, nor do > any of the several of crypto hardware suppliers that we use. > > Counter mode ESP would be far simpler and more bandwidth efficient > if the ESP sequence number were used as the per-packet counter > value. In addition, other cryptographic mechanisms that require a > nonce can use the sequence number for that purpose, if we are > allowed to assume that the sequence number is actually unique. > These mechanisms include ciphers like SEAL and Wegman-Carter based > MACs like MMH. It's worth noting that we've implemented SEAL > encryption using ESP, as described in the Stream Cipher ESP; this > draft is now expired, but went through three revisions without this > point about the sequence number and assurance boundary being raised. > (The old draft is online at > www.mindspring.com/~dmcgrew/draft-mcgrew-ipsec-scesp-02.txt if > you're interested, and we'd be fine with re-issuing the draft were > there is interest from other implementers.) > > > Point 2. "Adders are simple and straightforward to implement, but > due to carries, they do not execute in constant time. LSFRs offer > an alternative that executes in constant time." However, the > per-block increment operation is far more time critical than the > per-packet increment operation! Since the block counter is a > monotonically increasing integer, and it's presumably fast enough, > it's hard to see how the fact cited in the draft supports the use of > LFSRs for the per-packet field. > > > Point 1. "... there is no advantage to selecting a mechanism that > allows the decryptor to determine whether counter block values > collide. Damage from the collision is done, whether the decryptor > detects it or not." Yes, but the detection of a malfunctioning ESP > sender could enable an administrator to shut off the errant device. > Either the ESP CTR receiver or a passive security monitoring device > such as a network IDS system can detect ESP sequence number re-use. > When is the delayed detection of the failure of a security system > worse than no detection? > >I don't disagree with Point 3 and Points 5 and 6 follow from the >others. > >I would be surprised if other implementers in the WG favored the use >of an unspecified explicit IV over the use of the sequence number as >an implicit IV. At any rate, I think we've discussed the points well >enough to allow others in the WG to chime in. This debate has been the focus of the discussion between you and Steve Kent. A few others have offered opinions, but the vast majority of the WG has remained silent. One notable exception is the posting from David Black, who offered support for the explicit IV. So far, I do not see a consensus for overloading the semantics of the sequence number. However, I am sure the debate is not over yet. >On to other topics. The draft says in Section 6 that AES CTR MUST NOT >be used with statically configured keys. I certainly agree that this >is a good thing. However, RFC2401 requires implementations to support >such keys, saying "This document requires support for both manual and >automatic distribution of keys." Perhaps that RFC means that manual >keying be provided only for some ciphers (the mandatory to implement >ones?). At any rate, it would be good for the WG to decide what is >meant and to document it somewhere. (The Stream Cipher ESP draft hit >this same issue). It is my understanding that RFC 2401bis is being made more flexible in this area. Are you suggesting that the AES-CTR document should reference RFC 2401bis instead of RFC 2401? >On the subject of interoperability, the AES CTR draft could be >implemented using draft-mcgrew-saag-icm-00.txt (the generic counter >mode draft that I wrote last November, which also lines up with the >AES CTR variant in draft-ietf-avt-srtp-05.txt), if the spec were bent >hard enough. This bending would consist of defining the 'initial >offset' to be equal to (flags, truncated_spi), and of course throwing >the explicit IV in front of the ciphertext. All of the AES CTR specs >that I've seen have managed to agree that the per-block counter be a >big-endian integer in the least significant bits of the counter, which >probably ensures that implementations can share keystream-generation >components. > >OTOH, while the closeness of the various AES CTR specifications is a >good thing, the fact that the initial offset is not random has a >negative security impact. The WG may decide that it prefers >simplicity to strength against precomputation attacks. If so, fine, >but this subject needs to be discussed in the rationale. The content of the Rationale section comes from the email discussion regarding my proposed compromise. The major issue at that time was Explicit IVs, so it is not surprising that other aspects of the design rationale are slighted. First, I propose the following additional paragraph in the Security Considerations section: There are fairly generic precomputation attacks against all block cipher modes that allow a meet-in-the-middle attack against the key. These attacks require the creation and searching of huge tables of ciphertext associated with known plaintext and known keys. Assuming that the memory and processor resources are available for a precomputation attack, then the theoretical strength of AES-CTR (and any other block cipher mode) is limited to 2^(n/2) bits, where n is the number of bits in the key. The use of long keys is the best countermeasure to precomputation attacks. Therefore, implementations that employ 128-bit AES keys should take precautions to make the precomputation attacks more difficult. The concatenation of the Flags, Truncated SPI, and IV fields within the counter block can be thought of as a per-packet nonce. Repeated use of the same nonce value (even with different keys) ought to be avoided. One approach is to randomly assign SPI values; however, since the only 24 bits of the SPI are included in the nonce, a random SPI value provides limited additional security. I hope that this very brief description of precomputation attacks is sufficient. Next, I propose the following additional paragraph for the rationale section: No explicit countermeasures against precomputation attacks are included in the counter block construction. The use of long keys is the usual countermeasure to these attacks, and AES offers key sizes that thwart these attacks for many decades to come. >In Section 6 the draft says: > > "Thus, to avoid counter block collisions, ESP implementations that > permit use of the same key for encrypting and decrypting packets > with the same peer MUST ensure that the two peers assign different > SPI values to the security association (SA)." > >Is it actually kosher for two SAs to share the same keys? SAs are >simplex per RFC 2401, though they could in principle share a single >key. However, I'd expect that if the architecture allowed such >key-sharing that it would require that the SAs be in the same SA >bundle so that when one SA reaches it usage limit its twin gets >deleted as well. I'm not aware of any such language, which makes me >suspicious about using the same keys twice. I tried to point out that IKE would not generate such an SA. However, there are serious security concerns if the same key streams are used for encryption and decryption. I just wanted to make sure that no one did such a thing! >Now for the real nit: at the bottom of page 7, a typo: "It is >inappropriate to use this m AES-CTR" This will be fixed in the -01 draft. Russ From owner-ipsec@lists.tislabs.com Tue Jul 30 13:27:04 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UKR3w13119; Tue, 30 Jul 2002 13:27:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23658 Tue, 30 Jul 2002 15:40:38 -0400 (EDT) From: "Housley, Russ" To: "Dilkie, Lee" Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020730154915.03516eb0@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Jul 2002 15:54:13 -0400 Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: <29B5A21C13C8D51190F900805F65B4EC39F575@rndex50.ottawa.mite l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Based on this message thread, I conclude that ESP (regardless of the encryption algorithm, mode, or IV size) is considered too heavyweight for VoIP. As a result, they have invented a security protocol that meets their unique header compression requirements. If this is the case, then we seem to have reached consensus for the people that actually plan on using AES-CTR with ESP. Right? Russ At 11:28 AM 7/30/2002 -0400, Dilkie, Lee wrote: > > Which is one reason some of us went off and designed SRTP... > >Thank goodness someone said it. I've been biting my tongue since this >thread started. Yes, the 8 bytes of IV *are* significient. SRTPs solution >to use existing information in the packet to generate an implicit IV (and >you avoid IV reuse too) and avoid *any* packet expansion is key to not >wasting bandwidth and is absolutely necessary if you want to >encourage(push) encryption of media streams (VoIP especially). > >Is it important that IPsec use implicit IVs? It would help but IPsec has >other overheads that expands the packet already and you could well argue >that it wouldn't make much of a difference (and therby justify SRTPs >original reason for existance... that IPsec is just too big to use for VoIP). > >Do some math. > >One T1 (24 voice channels if configured for PSTN, 32 for european T1), >1536000 bps (more for our european friends). I'm ignoring media transport >overhead, these numbers are better than they would be in real life. > >(assuming 20ms (50 fps) RTP packets, no header compression) > >G.729, 60 byte TU , 64 voice "channels" >G.729, 68 byte TU (explicit IV), 56 voice "channels" (dunno 'bout you, but >that 13 percent overhead seems significient to me) > >G.711(uncompressed), 210 byte TU, 18 "channels" (unhappy customer, gets >less than PSTN T1) > >Things get better with header compression. > >Now try the same math with IPsec encrypted packets... > > >-lee From owner-ipsec@lists.tislabs.com Tue Jul 30 15:11:22 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UMBMw19015; Tue, 30 Jul 2002 15:11:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24111 Tue, 30 Jul 2002 17:15:49 -0400 (EDT) Date: Tue, 30 Jul 2002 17:29:07 -0400 (EDT) From: Henry Spencer To: Alex Alten cc: IP Security List Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: <3.0.3.32.20020730123238.015fe528@mail> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 30 Jul 2002, Alex Alten wrote: > We really need an elegant, simple, system solution that preserves the huge > legacy infrastructure that rides on top of IPv4. Design goal #1 should be > no new bytes added into or inserted after the IPv4 header. That would be a good trick, if you can do it. :-) Can you briefly summarize how you think this could be accomplished? Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Jul 30 15:38:36 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UMcaw19789; Tue, 30 Jul 2002 15:38:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24150 Tue, 30 Jul 2002 17:50:04 -0400 (EDT) Date: 30 Jul 2002 17:49:19 -0400 Message-ID: <000401c23812$f65c8320$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Alex Alten'" , " 'list'" Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-to: <3.0.3.32.20020730123238.015fe528@mail> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > We really need an elegant, simple, system solution that > preserves the huge > legacy infrastructure that rides on top of IPv4. Design goal > #1 should be > no new bytes added into or inserted after the IPv4 header. Blah, blah, blah. If there's one common thread to your posts, it seems to be that you would have done a much better job of designing IPsec than anyone else on this list. You might want to consider the fact that the biggest incompatibility between IPsec and NAT is that ESP runs on its own IP protocol instead of an assigned UDP port. That decision was no doubt motivated by the desire to avoid adding any new bytes into or after the IPv4 header. Your rants have the superficial appeal of an opinion that has never really been thought through. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Alex Alten > Sent: Tuesday, July 30, 2002 3:33 PM > To: Dilkie, Lee; 'David R. Oran'; ipsec@lists.tislabs.com > Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt > > > Dilkie, > > Every since last call many years ago I have made it clear to > this WG that > I felt IPsec was too complex. It needs to go everywhere that > IPv4 goes. > Shimming in another protocol header makes that ideal goal impossible. > IPsec will never be able to support in a practice many types of > transport, application or routing/error/discovery protocols. > > It is time that we sit back and re-examine it. Instead of putting the > extraordinary efforts into a new key exchange protocol, > adding new ciphers, > co-existing with NATs, etc., let us seriously consider a > complete redesign. > My understanding of the two arts is such that I am certain we > could retrofit > IPv4 in such a manner as to satisfy your needs as well as many others. > > We really need an elegant, simple, system solution that > preserves the huge > legacy infrastructure that rides on top of IPv4. Design goal > #1 should be > no new bytes added into or inserted after the IPv4 header. > > There I've said it. The emperor has no clothes. > > - Alex > > > At 11:28 AM 7/30/2002 -0400, Dilkie, Lee wrote: > >> Which is one reason some of us went off and designed SRTP... > > > >Thank goodness someone said it. I've been biting my tongue > since this > >thread started. Yes, the 8 bytes of IV *are* significient. > SRTPs solution > >to use existing information in the packet to generate an > implicit IV (and > >you avoid IV reuse too) and avoid *any* packet expansion is > key to not > >wasting bandwidth and is absolutely necessary if you want to > encourage(push) > >encryption of media streams (VoIP especially). > > > >Is it important that IPsec use implicit IVs? It would help > but IPsec has > >other overheads that expands the packet already and you > could well argue > >that it wouldn't make much of a difference (and therby justify SRTPs > >original reason for existance... that IPsec is just too big > to use for VoIP). > > > >Do some math. > > > >One T1 (24 voice channels if configured for PSTN, 32 for > european T1), > >1536000 bps (more for our european friends). I'm ignoring > media transport > >overhead, these numbers are better than they would be in real life. > > > >(assuming 20ms (50 fps) RTP packets, no header compression) > > > >G.729, 60 byte TU , 64 voice "channels" > >G.729, 68 byte TU (explicit IV), 56 voice "channels" (dunno > 'bout you, but > >that 13 percent overhead seems significient to me) > > > >G.711(uncompressed), 210 byte TU, 18 "channels" (unhappy > customer, gets > >less than PSTN T1) > > > >Things get better with header compression. > > > >Now try the same math with IPsec encrypted packets... > > > > > >-lee > > > -- > > Alex Alten > Alten@ATTBI.com > From owner-ipsec@lists.tislabs.com Tue Jul 30 16:32:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6UNW9w21780; Tue, 30 Jul 2002 16:32:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24134 Tue, 30 Jul 2002 17:41:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1083884FF@win-msg-01.wingroup.windeploy.nt dev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC1083884FF@win-msg-01.wingroup.windeploy.nt dev.microsoft.com> Date: Tue, 30 Jul 2002 14:49:47 -0700 To: "William Dixon" , "Brian Swander" , From: Paul Hoffman / VPNC Subject: RE: Clarification of potential NAT multiple client solutions Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:09 AM -0700 7/30/02, William Dixon wrote: >Paul, are suggesting that new error codes for notifies and the notify >behavior be added to the nat-t spec as well ? Nope. I am assuming that things will show up in debug logs. This WG hasn't ever been that clear about (or friendly to) error messages. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jul 30 21:16:41 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6V4Gfw01434; Tue, 30 Jul 2002 21:16:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA24804 Tue, 30 Jul 2002 23:26:14 -0400 (EDT) Message-Id: <200207301535.AFS81712@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 30 Jul 2002 08:22:48 -0700 To: "Housley, Russ" , Scott Fluhrer From: Scott Fluhrer Subject: RE: Two AES encryption modes? Cc: Gregory Lebovitz , "'Paul Hoffman / VPNC'" , ipsec@lists.tislabs.com In-Reply-To: <5.1.0.14.2.20020730111338.0347eeb0@exna07.securitydynamics .com> References: <200207250342.AFR68985@mira-sjcm-3.cisco.com> <541402FFDC56DA499E7E13329ABFEA87060C6D@SARATOGA> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 08:15 AM 7/30/02 , Housley, Russ wrote: >Scott: > >Thanks for updating your analysis. > >>Speed of Software Implementation: >> >>Both transforms can be executed in approximately the same speed. >>However, both CBC and COUNTER also require authentication transforms to >>be executed. > >In this area, I think that it is worth pointing out that the COUNTER key >stream can be precomputed (at least on the encryptor side). While >authentication must be performed when the packet is available, the key >stream can be precomputed to allow for reduced latency. Yes, this is an advantage, and I'll add it to the list the next time I publish it. In addition to the possibility for reduced latency, it also allows you to use CPU idle time to do some of the encryption work. -- scott From owner-ipsec@lists.tislabs.com Wed Jul 31 07:57:44 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6VEvhw02997; Wed, 31 Jul 2002 07:57:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26315 Wed, 31 Jul 2002 09:57:39 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15687.61478.928951.60182@pkoning.dev.equallogic.com> Date: Wed, 31 Jul 2002 10:11:50 -0400 From: Paul Koning To: rhousley@rsasecurity.com Cc: mcgrew@cisco.com, ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt References: <5.1.0.14.2.20020730092306.0345bf68@exna07.securitydynamics.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Housley," == Housley, Russ writes: >> First, a correction to the Security Section. In the last >> paragraph of Section 6, the draft is right to state that no more >> than 2^64 blocks should be encrypted with any fixed key. But the >> draft implies that this limitation can be avoided if >> implementations "make use of the longer AES key sizes." This is >> not right, the 2^64 limit applies to all key sizes. It does not >> apply to larger block sizes; however, the AES spec doesn't include >> the larger RIJDNAEL block sizes. In the same vein, the sentence >> "Additionally, AES with a 128-bit key is vulnerable to the >> birthday attack after 2^64 blocks" should read "Additionally, AES >> is vulnerable...". Housley,> You are correct. I propose the following replacement Housley,> paragraph: Housley,> Additionally, since AES has a 128-bit block size, Housley,> regardless of the mode employed, AES is vulnerable to a Housley,> birthday attack after 2^64 blocks are encrypted with a Housley,> single key. ... Is that actually correct for counter mode? The counter is not a random function, so the birthday paradox doesn't apply to the keystream. If I remember the discussion with David correctly, what IS true is that at around 2^64 blocks, counter mode (as well as the other modes) becomes "distinguishable" from a random string. And that's an interesting property from the point of view of security proofs, but I didn't think that it leads directly to an attack in the case of counter mode. So the recommendation is ok, but I think the reasoning might be restated. paul From owner-ipsec@lists.tislabs.com Wed Jul 31 11:44:06 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6VIi5w19330; Wed, 31 Jul 2002 11:44:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27014 Wed, 31 Jul 2002 13:55:26 -0400 (EDT) Message-ID: <018a01c238be$7c244a50$5a8b4789@pcuclinux> From: "Suresh Singh K." To: Subject: CERT REQ payload Handling Clarification Date: Wed, 31 Jul 2002 11:16:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi , Please clarify the following Issue for CERT REQ payload Handling : As the encoding of a CA 's DN into the CERT_REQ payload is done using BER ,one should be able to encode it using DER only (as DER is subset of BER). And the other end's BER decoding software should be able to decode the DER encoding. For decoding , we cannot assume that the other end with always encode the CA's DN in DER only. He can encode using the other two BER encoding method , in which case we should be able to decode any of the 3 encoding method for BER, including DER. Thanks in advance, Suresh From owner-ipsec@lists.tislabs.com Wed Jul 31 14:16:10 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6VLG9w06526; Wed, 31 Jul 2002 14:16:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27431 Wed, 31 Jul 2002 16:24:52 -0400 (EDT) Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <15687.61478.928951.60182@pkoning.dev.equallogic.com> Date: Wed, 31 Jul 2002 10:11:50 -0400 From: "Paul Koning" To: Cc: , Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt References: <5.1.0.14.2.20020730092306.0345bf68@exna07.securitydynamics.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid X-OriginalArrivalTime: 31 Jul 2002 15:18:35.0167 (UTC) FILETIME=[89C0D2F0:01C238A5] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Housley," == Housley, Russ writes: >> First, a correction to the Security Section. In the last >> paragraph of Section 6, the draft is right to state that no more >> than 2^64 blocks should be encrypted with any fixed key. But the >> draft implies that this limitation can be avoided if >> implementations "make use of the longer AES key sizes." This is >> not right, the 2^64 limit applies to all key sizes. It does not >> apply to larger block sizes; however, the AES spec doesn't include >> the larger RIJDNAEL block sizes. In the same vein, the sentence >> "Additionally, AES with a 128-bit key is vulnerable to the >> birthday attack after 2^64 blocks" should read "Additionally, AES >> is vulnerable...". Housley,> You are correct. I propose the following replacement Housley,> paragraph: Housley,> Additionally, since AES has a 128-bit block size, Housley,> regardless of the mode employed, AES is vulnerable to a Housley,> birthday attack after 2^64 blocks are encrypted with a Housley,> single key. ... Is that actually correct for counter mode? The counter is not a random function, so the birthday paradox doesn't apply to the keystream. If I remember the discussion with David correctly, what IS true is that at around 2^64 blocks, counter mode (as well as the other modes) becomes "distinguishable" from a random string. And that's an interesting property from the point of view of security proofs, but I didn't think that it leads directly to an attack in the case of counter mode. So the recommendation is ok, but I think the reasoning might be restated. paul From owner-ipsec@lists.tislabs.com Wed Jul 31 15:36:58 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6VMavw13331; Wed, 31 Jul 2002 15:36:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27710 Wed, 31 Jul 2002 17:43:35 -0400 (EDT) From: "Jayant Shukla" To: "'Brian Swander'" , Subject: RE: Clarification of potential NAT multiple client solutions Date: Wed, 31 Jul 2002 14:54:08 -0700 Message-ID: <000001c238dc$d94ba890$0402a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1056BF00A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Brian Swander > Bottom line is that there are a variety of solutions for this scenario. o.k.! > 3. upper layer protocol awareness of the inbound & outbound IPsec SA > (where it doesn't use source IP and source port as the session identifier. > E.g. L2TP session ID mapped to the IPsec SA pair which doesn't use the UDP > source port or source IP address for peer uniqueness) Why not just use IPsec pass-thru? Instead of mapping the L2TP ID to the IPsec SA, just use information from the IPsec SA. > 4. application integration with IKE initiation such that it can rebind to > a different source port if the IKE quick mode SA proposal is rejected by > the responder, then repropose the new QM selector. Microsoft may have > intellectual property rights relating to this implementation technique. > See the Microsoft IPR notice on the IETF web site for the details. Application port negotiation as part of IKE?? You are not serious, I hope! > 6. don't support the scenario of multiple clients behind the same NAT > simultaneously. Simply fail the second attempt at Main Mode or the Quick > Mode So, it is worse than IPsec pass-thru! Using IPsec pass-thru we can support multiple IPsec clients behind a NAT and every single NAT vendor has IPsec pass-thru implemented. What is the advantage of your solution over IPsec pass-thru? Regards, Jayant www.trlokom.com From owner-ipsec@lists.tislabs.com Wed Jul 31 16:05:16 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6VN5Fw15107; Wed, 31 Jul 2002 16:05:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27836 Wed, 31 Jul 2002 18:22:00 -0400 (EDT) Message-Id: <4.3.2.7.1.20020731153042.00c418b0@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Jul 2002 15:34:25 -0700 To: "Suresh Singh K." , From: Ramana Yarlagadda Subject: Re: CERT REQ payload Handling Clarification In-Reply-To: <018a01c238be$7c244a50$5a8b4789@pcuclinux> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I think we have to use only DER encoding here and not the BER. Becuase the protocol doesn't allow you to negotiate encoding method . And so BER encoding is not used in IKE. -cheers -ramana At 11:16 AM 7/31/02 -0700, Suresh Singh K. wrote: >Hi , > Please clarify the following Issue for CERT REQ payload Handling : > > As the encoding of a CA 's DN into the CERT_REQ payload >is done using BER ,one should be able to encode it using DER only >(as DER is subset of BER). And the other end's BER decoding software >should be able to decode the DER encoding. > For decoding , we cannot assume that the other end with always >encode the CA's DN in DER only. He can encode using the other >two BER encoding method , in which case we should be able to >decode any of the 3 encoding method for BER, including DER. > From owner-ipsec@lists.tislabs.com Wed Jul 31 23:06:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7166Tw27877; Wed, 31 Jul 2002 23:06:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA28590 Thu, 1 Aug 2002 01:19:24 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message Subject: RE: Clarification of potential NAT multiple client solutions Date: Wed, 31 Jul 2002 22:33:09 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC108388546@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Clarification of potential NAT multiple client solutions thread-index: AcI430837KQV5na7ScSUgPiIOkdcSwAPU9Iw From: "William Dixon" To: "Jayant Shukla" , "Brian Swander" , X-OriginalArrivalTime: 01 Aug 2002 05:33:25.0635 (UTC) FILETIME=[F5412530:01C2391C] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jayant, what exactly do you mean by the "ipsec-passthu" technique ? -----Original Message----- From: Jayant Shukla [mailto:jshukla@trlokom.com] Sent: Wednesday, July 31, 2002 2:54 PM To: Brian Swander; ipsec@lists.tislabs.com Subject: RE: Clarification of potential NAT multiple client solutions > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Brian Swander > Bottom line is that there are a variety of solutions for this scenario. o.k.! > 3. upper layer protocol awareness of the inbound & outbound IPsec SA > (where it doesn't use source IP and source port as the session identifier. > E.g. L2TP session ID mapped to the IPsec SA pair which doesn't use the UDP > source port or source IP address for peer uniqueness) Why not just use IPsec pass-thru? Instead of mapping the L2TP ID to the IPsec SA, just use information from the IPsec SA. > 4. application integration with IKE initiation such that it can rebind to > a different source port if the IKE quick mode SA proposal is rejected by > the responder, then repropose the new QM selector. Microsoft may have > intellectual property rights relating to this implementation technique. > See the Microsoft IPR notice on the IETF web site for the details. Application port negotiation as part of IKE?? You are not serious, I hope! > 6. don't support the scenario of multiple clients behind the same NAT > simultaneously. Simply fail the second attempt at Main Mode or the Quick > Mode So, it is worse than IPsec pass-thru! Using IPsec pass-thru we can support multiple IPsec clients behind a NAT and every single NAT vendor has IPsec pass-thru implemented. What is the advantage of your solution over IPsec pass-thru? Regards, Jayant www.trlokom.com From owner-ipsec@lists.tislabs.com Wed Jul 31 23:06:30 2002 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7166Tw27876; Wed, 31 Jul 2002 23:06:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA28610 Thu, 1 Aug 2002 01:24:28 -0400 (EDT) Message-ID: <002f01c2391d$d4081710$af64a8c0@pace.stpp.soft.net> From: "Amol Deshmukh" To: References: <018a01c238be$7c244a50$5a8b4789@pcuclinux> Subject: Keying Material Date: Thu, 1 Aug 2002 11:09:39 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am trying to interop, our IKE implementation with Cisco. From the keying material generated, the keys for encryption/authentication are created. There is no way to find out if the keys generated at both ends are the same. Could anyone please help me in this. Thanks in advance, -Amol.