From owner-ipsec@lists.tislabs.com Thu Aug 1 06:18: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 g71DIfw15310; Thu, 1 Aug 2002 06:18:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA29495 Thu, 1 Aug 2002 08:31:01 -0400 (EDT) Message-ID: <3D48CE05.B868C3A7@briank.com> Date: Wed, 31 Jul 2002 22:58:32 -0700 From: Brian Korver X-Mailer: Mozilla 4.78 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Suresh Singh K." CC: ipsec@lists.tislabs.com Subject: Re: CERT REQ payload Handling Clarification References: <018a01c238be$7c244a50$5a8b4789@pcuclinux> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "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. > > > Thanks in advance, > > Suresh > Suresh, I'm not aware of any restriction on DER vs. BER in the CERTREQ payload, but you're probably right that you can't assume the other end will always send DER. But that probably doesn't imply that you need to re-encode to DER. The most common case is that the sender has the CA certificate that contains the DN which is then used to populate the CERTREQ payload. In fact, I would guess that most implementations pull the DN directly from the certificate (byte-for-byte). It is likely that the CA used DER when it generated that certificate, but it isn't a given. Thus, the encoding of contents of the CERTREQ payload will depend on the encoding method that the CA used. This is probably a good thing in most cases, as the recipient of the CERTREQ payload will (must?) possess the CA certificate and will use the DN to find that certificate. It is highly unlikely that if the DN is not DER in the certificate, that a DER DN can be used as a key to lookup that certificate. -brian briank@briank.com From owner-ipsec@lists.tislabs.com Thu Aug 1 06:40: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 g71Deiw15732; Thu, 1 Aug 2002 06:40:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA29559 Thu, 1 Aug 2002 08:58:13 -0400 (EDT) From: "Stephane Beaulieu" To: "Amol Deshmukh" , Subject: RE: Keying Material Date: Thu, 1 Aug 2002 09:12:21 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <002f01c2391d$d4081710$af64a8c0@pace.stpp.soft.net> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Amol, We used to have bakeoffs to deal with such issues. Unfortunately, bakeoffs are rare these days because most vendors achieved good basic interoperability years and years ago. Probably the easiest way to do this is to try sending packets through and turning on debugging on the Cisco device. It won't give you the keys, but it'll tell you if authentication and/or decryption fail. If your keys are incorrect, try and try again. You might also want to try and interop with some of the open source IPsec implementations. You can probably modify their code to spew out the keys you're looking for. Good luck, Stephane. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Amol Deshmukh > Sent: Thursday, August 01, 2002 1:40 AM > To: ipsec@lists.tislabs.com > Subject: Keying Material > > > 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. > From owner-ipsec@lists.tislabs.com Thu Aug 1 07:44: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 g71EiYw20687; Thu, 1 Aug 2002 07:44:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29806 Thu, 1 Aug 2002 09:50:18 -0400 (EDT) Message-Id: <200208011403.g71E3b8Z024001@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: CERT REQ payload Handling Clarification In-reply-to: Your message of "Wed, 31 Jul 2002 15:34:25 PDT." <4.3.2.7.1.20020731153042.00c418b0@golf.cpgdesign.analog.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 01 Aug 2002 10:03:36 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Ramana" == Ramana Yarlagadda writes: Ramana> I think we have to use only DER encoding here and not the BER. Ramana> Becuase the protocol doesn't allow you to negotiate encoding method . Ramana> And so BER encoding is not used in IKE. DER is a subset of BER. Your parser should always expect BER. DER is required in certain situations, which would be well spelt out - typically under signatures. It would be nice if someone would write a seperate Informational document on using PKIX with IKE. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPUk/toqHRg3pndX9AQHtygQA3QTMux6TD7C7e5D4qLwhdvYxlwlzVWDW YOErouJn6am5IA54h1xCFtfz2rNJOY/t80pWNPEcOlrb3wz83WV5OaWQ1Ry9xuQf SxyTD7UfBYiDGH8N7lk/ZuKazuGun9RMW700v0ip/gh/hV/YjeJJyiXbcfArQtuQ 7iteqBAob/E= =jTaz -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Aug 1 08:22: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 g71FMnw22316; Thu, 1 Aug 2002 08:22:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00052 Thu, 1 Aug 2002 10:33:44 -0400 (EDT) Reply-To: From: "Rajesh Mohan" To: "'Amol Deshmukh'" , Subject: RE: Keying Material Date: Thu, 1 Aug 2002 20:10:30 +0530 Message-Id: <001f01c23969$62ec5540$7b06140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Amol, I would recommend you start with OpenBsd implementation. It definetly prints SKEYID and IV updates to log file. isakmpd man pages will tell you how to turn on log messages. HTH, -Rajesh M > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephane Beaulieu > Sent: Thursday, August 01, 2002 6:42 PM > To: Amol Deshmukh; ipsec@lists.tislabs.com > Subject: RE: Keying Material > > > Amol, > > We used to have bakeoffs to deal with such issues. > Unfortunately, bakeoffs > are rare these days because most vendors achieved good basic > interoperability years and years ago. > > Probably the easiest way to do this is to try sending packets > through and > turning on debugging on the Cisco device. It won't give you > the keys, but > it'll tell you if authentication and/or decryption fail. > > If your keys are incorrect, try and try again. > > You might also want to try and interop with some of the open > source IPsec > implementations. You can probably modify their code to spew > out the keys > you're looking for. > > Good luck, > Stephane. > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Amol Deshmukh > > Sent: Thursday, August 01, 2002 1:40 AM > > To: ipsec@lists.tislabs.com > > Subject: Keying Material > > > > > > 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. > > > *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ipsec@lists.tislabs.com Thu Aug 1 09:26: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 g71GQXw24472; Thu, 1 Aug 2002 09:26:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00205 Thu, 1 Aug 2002 11:36:15 -0400 (EDT) From: Brian Korver Message-Id: <200208011547.g71Fl2564891@oe8.briank.com> Subject: Re: CERT REQ payload Handling Clarification In-Reply-To: <200208011403.g71E3b8Z024001@marajade.sandelman.ottawa.on.ca> "from Michael Richardson at Aug 1, 2002 10:03:36 am" To: Michael Richardson Date: Thu, 1 Aug 2002 08:47:01 -0700 (PDT) CC: ipsec@lists.tislabs.com X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Richardson writes: > DER is a subset of BER. > Your parser should always expect BER. > > DER is required in certain situations, which would be well spelt out - > typically under signatures. > > It would be nice if someone would write a seperate Informational document > on using PKIX with IKE. Although it doesn't answer this question (yet), the intention of draft-ietf-ipsec-pki-profile-00.txt is to address these sorts of issues (of which there are many). -brian briank@briank.com From owner-ipsec@lists.tislabs.com Thu Aug 1 10:09: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 g71H9Fw27395; Thu, 1 Aug 2002 10:09:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00317 Thu, 1 Aug 2002 12:24:55 -0400 (EDT) From: "Jayant Shukla" To: "'William Dixon'" , "'Brian Swander'" , Subject: RE: Clarification of potential NAT multiple client solutions Date: Thu, 1 Aug 2002 09:35:55 -0700 Message-ID: <000001c23979$82517e00$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 In-reply-to: <2E33960095B58E40A4D3345AB9F65EC108388546@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi William, I am referring to the method used by NAT boxes to let IKE & IPsec traffic pass through based on cookies and SPI. It is the same method that caused problem for the earlier version of your draft that required eight bytes of zeros to be inserted after the UDP header. Regards, Jayant www.trlokom.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of William Dixon > Sent: Wednesday, July 31, 2002 10:33 PM > To: Jayant Shukla; Brian Swander; ipsec@lists.tislabs.com > Subject: RE: Clarification of potential NAT multiple client solutions > > > 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 Thu Aug 1 10:15: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 g71HFAw27991; Thu, 1 Aug 2002 10:15:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00329 Thu, 1 Aug 2002 12:32:57 -0400 (EDT) Message-Id: <200208011645.AFT49729@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 01 Aug 2002 09:33:33 -0700 To: , "Alex Alten" From: Scott Fluhrer Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Cc: In-Reply-To: <200207301406.KAA08853@nwmail.wh.lucent.com> References: <3.0.3.32.20020730010011.015fe528@mail> <3.0.3.32.20020729155630.013bbfc8@mail> <3.0.3.32.20020730010011.015fe528@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 07:04 AM 7/30/02 , Uri Blumenthal wrote: > >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. This appears that this needs to be emphasized -- CBC has IVs and the current counter mode draft has IVs, but they're not really the same thing, and they do not have the same constraints on them. A few months ago, I pointed out a weakness in CBC mode with predictable IVs. This weakness is specific to how CBC mode works, and counter mode with predictable IVs has no corresponding weakness. The only constraint on counter mode is that the IVs never repeat. -- scott From owner-ipsec@lists.tislabs.com Thu Aug 1 10:18: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 g71HIiw28104; Thu, 1 Aug 2002 10:18:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00336 Thu, 1 Aug 2002 12:33:59 -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="us-ascii" Subject: RE: Clarification of potential NAT multiple client solutions Date: Thu, 1 Aug 2002 09:48:06 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1056BF01B@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Clarification of potential NAT multiple client solutions thread-index: AcI5eeaIMDXip/uHRtu1hkwtzXi34QAAGKzA From: "Brian Swander" To: "Jayant Shukla" , "William Dixon" , X-OriginalArrivalTime: 01 Aug 2002 16:48:10.0885 (UTC) FILETIME=[38580B50:01C2397B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA00333 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are lots of problems with that form of passthru with transport mode. Just a couple: 1. if you have multiple simultaneous connections behind the NAT, the NAT will have difficulty mapping the unseen spis from the external host to the outgoing SPI it has seen since it only uses time proximity and no better smarts. This problem also exists for tunnel mode passthru. So it cannot claim to be an industrial strength solution. 2. Still have the demux issues of multiple clients behind the same NAT talking to the same external server 3. Still need to modify IKE to get the negotiation to succeed (QM proxies addrs at least) 4. Still need to deal with the incorrect transport layer xsum In short, passthru is potentially tolerable for tunnel mode in some scenarios, but fails pretty badly for transport. bs -----Original Message----- From: Jayant Shukla [mailto:jshukla@trlokom.com] Sent: Thursday, August 01, 2002 9:36 AM To: William Dixon; Brian Swander; ipsec@lists.tislabs.com Subject: RE: Clarification of potential NAT multiple client solutions Hi William, I am referring to the method used by NAT boxes to let IKE & IPsec traffic pass through based on cookies and SPI. It is the same method that caused problem for the earlier version of your draft that required eight bytes of zeros to be inserted after the UDP header. Regards, Jayant www.trlokom.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of William Dixon > Sent: Wednesday, July 31, 2002 10:33 PM > To: Jayant Shukla; Brian Swander; ipsec@lists.tislabs.com > Subject: RE: Clarification of potential NAT multiple client solutions > > > 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 Thu Aug 1 10:35: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 g71HZrw28875; Thu, 1 Aug 2002 10:35:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00376 Thu, 1 Aug 2002 12:44:14 -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: Thu, 1 Aug 2002 09:57:43 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC105D01802@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Clarification of potential NAT multiple client solutions thread-index: AcI5eeaIMDXip/uHRtu1hkwtzXi34QAABTWg From: "William Dixon" To: "Jayant Shukla" , "Brian Swander" , X-OriginalArrivalTime: 01 Aug 2002 16:57:44.0243 (UTC) FILETIME=[8E178830:01C2397C] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A few things that the solution the current drafts represent make it better than the NAT supporting IPsec pass-thru that you describe. While this link describes the limitations of the full and correctly implemented IPsec pass-thru solution, there are a few other things to note: http://www.impsec.org/linux/masquerade/VPN-howto/VPN-Masquerade-6.html#s s6.1 1. the requirements for this WG work state that a solution to the IPsec NAT compatibility problem requires no change to deployed NATs. 2. while some NATs today do support IPsec pass-thru, they do not all do it in the same way consistently, and it's certainly not something customers can depend on in the infrastructure. Despite the fact that many (most ?) NATs support a similar method for PPTP pass-thu, I hit the case all the time while traveling where one doesn't. Thus #1. Futher, our own internal testing of at least 8 or 10 NATs found discrepancies in their implementation. We didn't get into the details of the NAT vendors' code of course, but the different behavior was obvious in the impact to UDP500 encapsulation, thus we had to move it to another port. 3. NAT IPsec pass-thru has to guess on the inbound ESP SPI association to the right internal client. Given #2, this means they may only support 1 IPsec client behind the NAT, or they have to inhibit a new outbound IKE Main Mode SA (with responder cookie = 0 specifically) until they see an inbound ESP SPI they don't recognize. The requirements document states that multiple clients behind the same NAT (say a business scenario) must be able to connect to the same destination IP address. The limitation of pass-thru can introduce scaling problems in this scenario, both with the ability to initially connect and the ability to rekey Main Mode. Not all implementations keep the Main Mode active while quick mode is active. So a simple quick mode rekey may drive a new Main Mode. 4. if the NAT solely is responsible for the pass-thru hole, it can time out the hole. So keep-alives are required by the client. 5. the likelihood of both NATs supporting a compatible IPsec passthru in the double NAT case, is low. And still requires #4. -----Original Message----- From: Jayant Shukla [mailto:jshukla@trlokom.com] Sent: Thursday, August 01, 2002 9:36 AM To: William Dixon; Brian Swander; ipsec@lists.tislabs.com Subject: RE: Clarification of potential NAT multiple client solutions Hi William, I am referring to the method used by NAT boxes to let IKE & IPsec traffic pass through based on cookies and SPI. It is the same method that caused problem for the earlier version of your draft that required eight bytes of zeros to be inserted after the UDP header. Regards, Jayant www.trlokom.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of William Dixon > Sent: Wednesday, July 31, 2002 10:33 PM > To: Jayant Shukla; Brian Swander; ipsec@lists.tislabs.com > Subject: RE: Clarification of potential NAT multiple client solutions > > > 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 Thu Aug 1 11:09: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 g71I9Uw02468; Thu, 1 Aug 2002 11:09:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00518 Thu, 1 Aug 2002 13:27:46 -0400 (EDT) Message-ID: <037601c23983$cae59de0$5a8b4789@pcuclinux> From: "Suresh Singh K." To: "'Amol Deshmukh'" , References: <001f01c23969$62ec5540$7b06140a@future.futsoft.com> Subject: Re: Keying Material Date: Thu, 1 Aug 2002 10:49:26 -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, Rajesh's Idea 's is good. Alternatively, Racoon on FreeBsd 'll also print the SKEYIDs and IVs to log file. suresh ----- Original Message ----- From: "Rajesh Mohan" To: "'Amol Deshmukh'" ; Sent: Thursday, August 01, 2002 7:40 AM Subject: RE: Keying Material > Amol, > > I would recommend you start with OpenBsd implementation. It definetly prints > SKEYID and IV updates to log file. isakmpd man pages will tell you how to > turn on log messages. > > HTH, > -Rajesh M > > > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephane Beaulieu > > Sent: Thursday, August 01, 2002 6:42 PM > > To: Amol Deshmukh; ipsec@lists.tislabs.com > > Subject: RE: Keying Material > > > > > > Amol, > > > > We used to have bakeoffs to deal with such issues. > > Unfortunately, bakeoffs > > are rare these days because most vendors achieved good basic > > interoperability years and years ago. > > > > Probably the easiest way to do this is to try sending packets > > through and > > turning on debugging on the Cisco device. It won't give you > > the keys, but > > it'll tell you if authentication and/or decryption fail. > > > > If your keys are incorrect, try and try again. > > > > You might also want to try and interop with some of the open > > source IPsec > > implementations. You can probably modify their code to spew > > out the keys > > you're looking for. > > > > Good luck, > > Stephane. > > > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Amol Deshmukh > > > Sent: Thursday, August 01, 2002 1:40 AM > > > To: ipsec@lists.tislabs.com > > > Subject: Keying Material > > > > > > > > > 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. > > > > > > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > From owner-ipsec@lists.tislabs.com Thu Aug 1 14:56: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 g71Lucw13070; Thu, 1 Aug 2002 14:56:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00863 Thu, 1 Aug 2002 17:06:43 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15689.42558.510364.679796@pkoning.dev.equallogic.com> Date: Thu, 1 Aug 2002 17:21:02 -0400 From: Paul Koning To: rhousley@rsasecurity.com Cc: 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> <5.1.0.14.2.20020801171427.02133438@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: Housley,> Are you happy with the following replacement paragraph? Housley,> Additionally, since AES has a 128-bit block size, Housley,> regardless of the mode employed, the ciphertext generated Housley,> by AES encryption becomes distinguishable from random Housley,> values after 2^64 blocks are encrypted with a single key. Housley,> Since ESP with Enhanced Sequence Numbers allows for up to Housley,> 2^64 packets in a single security association (SA), there Housley,> is real potential for more than 2^64 blocks to be encrypted Housley,> with one key. Therefore, implementations SHOULD generate a Housley,> fresh key before 2^64 blocks are encrypted with the same Housley,> key. Note that ESP with 32-bit Sequence Numbers will not Housley,> exceed 2^64 blocks even if all of the packets are Housley,> maximum-length Jumbograms. Yes, that looks great; it covers all cases with a single description. paul From owner-ipsec@lists.tislabs.com Thu Aug 1 14:56: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 g71Lucw13069; Thu, 1 Aug 2002 14:56:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00857 Thu, 1 Aug 2002 17:03:36 -0400 (EDT) From: "Housley, Russ" To: Paul Koning Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020801171427.02133438@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 01 Aug 2002 17:16:11 -0400 Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: <15687.61478.928951.60182@pkoning.dev.equallogic.com> References: <5.1.0.14.2.20020730092306.0345bf68@exna07.securitydynamics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul: > >>>>> "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. Are you happy with the following replacement paragraph? Additionally, since AES has a 128-bit block size, regardless of the mode employed, the ciphertext generated by AES encryption becomes distinguishable from random values 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. Therefore, 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. Russ From owner-ipsec@lists.tislabs.com Thu Aug 1 21:35: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 g724Zqw25466; Thu, 1 Aug 2002 21:35:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA01578 Thu, 1 Aug 2002 23:45:36 -0400 (EDT) From: "Jayant Shukla" To: "'William Dixon'" , "'Brian Swander'" , Subject: RE: Clarification of potential NAT multiple client solutions Date: Thu, 1 Aug 2002 20:56:40 -0700 Message-ID: <000001c239d8$9bd37180$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: <2E33960095B58E40A4D3345AB9F65EC105D01802@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 William Dixon > Sent: Thursday, August 01, 2002 9:58 AM > > A few things that the solution the current drafts represent > make it better than the NAT supporting IPsec pass-thru that > you describe. While this link describes the limitations of > the full and correctly implemented IPsec pass-thru solution, > there are a few other things to > note: > > http://www.impsec.org/linux/masquerade/VPN-howto/VPN-Masquerad > e-6.html#s > s6.1 > > 1. the requirements for this WG work state that a solution to > the IPsec NAT compatibility problem requires no change to > deployed NATs. > The requirement of the working group also states that IKE cannot be modified. > 2. while some NATs today do support IPsec pass-thru, they do > not all do it in the same way consistently, Can you explain what you mean by consistently? Any solid observations that you can use to back up this claim? Over the last 1-2 years NAT vendors have learned a lot about IPsec pass thru and some of the earlier bugs have been fixed through firmware upgrades. > and it's > certainly not something customers can depend on in the > infrastructure. Despite the fact that many (most ?) NATs > support a similar method for PPTP pass-thu, I hit the case > all the time while traveling where one doesn't. Thus #1. PPTP never got standardized, so what you do expect? PPTP is published as informational RFC in IETF, and I think it is unreasonable of you to expect NAT vendors to support non-standard protocols. > Futher, our own internal testing of at least 8 or 10 NATs > found discrepancies in their implementation. We didn't get > into the details of the NAT vendors' code of course, but the > different behavior was obvious in the impact to UDP500 > encapsulation, thus we had to move it to another port. > You have not explained what this inconsistency is?! Did you check for firmware upgrades with those vendors? In our experience, we saw a more uniform behavior from varous NATs and we tested NATs from seven different vendors. > 3. NAT IPsec pass-thru has to guess on the inbound ESP SPI > association to the right internal client. It can be done systematically and does not have to be a guess. See my explanation down below or read the link you sent. > Given #2, this > means they may only support 1 IPsec client behind the NAT, or > they have to inhibit a new outbound IKE Main Mode SA (with > responder cookie = 0 specifically) until they see an inbound > ESP SPI they don't recognize. This is not true! You do realize that IKE sessions can be demultiplexed based on cookies? For IPsec messages, all the NAT gateway has to do is to allow the first outbound IPsec packet and inhibit new outbound IPsec connections until the first host to start an IPsec connection receives a reply. At that moment, the gateway knows the SPIs for that host's IPsec connection unambiguously. Continue this until all clients have IPsec session established. This can typically be done very fast and other clients should not see any significant delay. BTW, it is explained very well in the link you sent. > The requirements document > states that multiple clients behind the same NAT (say a > business scenario) must be able to connect to the same > destination IP address. IPsec pass-thru can enable multiple IPsec clients behind a NAT. The limitation of pass-thru can > introduce scaling problems in this scenario, both with the > ability to initially connect and the ability to rekey Main > Mode. Not all implementations keep the Main Mode active > while quick mode is active. So a simple quick mode rekey may > drive a new Main Mode. > This statement is grossly misinformed. Why do you keep bringing Main mode into this? See my explanation of how IPsec and IKE connections are de-multiplexed. > 4. if the NAT solely is responsible for the pass-thru hole, > it can time out the hole. So keep-alives are required by the client. > Not a valid arguement. Time-outs are absolutely necessary and you must live with them. Even if a time out occours, IPsec pass thru mechanism should re-establish the connection. In fact, your approach also is also faced with the time-out problem and needs keep-alives. > 5. the likelihood of both NATs supporting a compatible IPsec > passthru in the double NAT case, is low. And still requires #4. > This is very interesting! Are you saying that your method enables multiple initiator and responders to be behind NATs and still communicate to each other? If so, please explain. My guess is that you have a VPN gateway behind the other NAT that sits in the DMZ. All IKE/IPsec packets reach this gateway and therefore no demultiplexing is required. Regards, Jayant www.trlokom.com From owner-ipsec@lists.tislabs.com Fri Aug 2 06:26: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 g72DQrw13535; Fri, 2 Aug 2002 06:26:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02378 Fri, 2 Aug 2002 08:41:36 -0400 (EDT) Message-ID: <20020802125524.37705.qmail@web12205.mail.yahoo.com> Date: Fri, 2 Aug 2002 05:55:24 -0700 (PDT) From: Sami Vaarala Reply-To: silvere@iki.fi Subject: RE: Clarification of potential NAT multiple client solutions To: Jayant Shukla , "'William Dixon'" , "'Brian Swander'" , ipsec@lists.tislabs.com In-Reply-To: <000001c239d8$9bd37180$0402a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, > > Given #2, this > > means they may only support 1 IPsec client behind the NAT, or > > they have to inhibit a new outbound IKE Main Mode SA (with > > responder cookie = 0 specifically) until they see an inbound > > ESP SPI they don't recognize. > > This is not true! You do realize that IKE sessions can be > demultiplexed based on cookies? > > For IPsec messages, all the NAT gateway has to do is to allow > the first outbound IPsec packet and inhibit new outbound IPsec > connections until the first host to start an IPsec connection > receives a reply. >[snip] Just out of curiosity, could you explain what happens if: 1. there is no inbound traffic at all (i.e. a unidirectional protocol)? 2. there is inbound traffic but it takes a long time before it starts? 3. an attacker spoofs an IPsec packet with all fields otherwise as the NAT expects, but with a bogus SPI? (This packet would of course have to arrive before any proper response packet would reach the NAT.) Best regards, -Sami -- Sami Vaarala Senior System Architect Netseal __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From owner-ipsec@lists.tislabs.com Sun Aug 4 22:26: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 g755QQw29213; Sun, 4 Aug 2002 22:26:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA06407 Mon, 5 Aug 2002 00:14:59 -0400 (EDT) From: "Jayant Shukla" To: , "'William Dixon'" , "'Brian Swander'" , Subject: RE: Clarification of potential NAT multiple client solutions Date: Sun, 4 Aug 2002 21:26:23 -0700 Message-ID: <000001c23c38$41d0e700$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: <20020802125524.37705.qmail@web12205.mail.yahoo.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 Sami Vaarala > > Just out of curiosity, could you explain what happens if: > > 1. there is no inbound traffic at all (i.e. a unidirectional > protocol)? > You have TCP/UDP/ICMP. In case of TCP you get bidirectional traffic, hence no problem there. You also won't be sending ICMP messages right after IKE, unless your intentions are not very good. That leaves UDP. So, right after IKE, you start sending vast amounts of UDP packets?! Sounds very fishy to me. BTW, what application do you have in mind? > 2. there is inbound traffic but it takes a long time before > it starts? > You do realize that this question is almost identical to #1? What do you mean by long time? 1 second? 10 seconds? 30 seconds? If the reply takes too long, your TCP session will time out. IPsec pass-thru has a big enough time (about 1 min., but I am not certain) window to ensure that inbound traffic does arrive. > 3. an attacker spoofs an IPsec packet with all fields > otherwise as the > NAT expects, but with a bogus SPI? (This packet would of > course have > to arrive before any proper response packet would reach the NAT.) > This is interesting! Anytime you let NATs or any intermediate entity modify or route your packets, you have a potential DoS problem. I am sure you are familiar with a similar issue in NAT-T. Someone even wrote a draft about it. The attack on IPsec pass-thru as described by you has a very short time window where you can launch the attack. For NAT-T, you can launch the attack anytime. If the NAT-T people ever do figure out a proper solution, they most likely will face IPR issues as we have couple of patents pending to solve that problem. Anyway, the bottom line is that NAT-T has no advantages over a simple existing solution (IPsec pass-thru) that is widely deployed. In fact, it seems to be worse off that IPsec pass-thru. Regards, Jayant www.trlokom.com > -- > Sami Vaarala > Senior System Architect > Netseal > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better http://health.yahoo.com > From owner-ipsec@lists.tislabs.com Mon Aug 5 01:52: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 g758qfw00515; Mon, 5 Aug 2002 01:52:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA06647 Mon, 5 Aug 2002 03:53:33 -0400 (EDT) Message-ID: <20020805080755.75847.qmail@web12208.mail.yahoo.com> Date: Mon, 5 Aug 2002 01:07:55 -0700 (PDT) From: Sami Vaarala Reply-To: silvere@iki.fi Subject: RE: Clarification of potential NAT multiple client solutions To: Jayant Shukla , silvere@iki.fi, "'William Dixon'" , "'Brian Swander'" , ipsec@lists.tislabs.com In-Reply-To: <000001c23c38$41d0e700$0402a8c0@trlhpc1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, --- Jayant Shukla wrote: >[snip] > > 2. there is inbound traffic but it takes a long time before > > it starts? > You do realize that this question is almost identical to #1? > > What do you mean by long time? 1 second? 10 seconds? 30 seconds? > If the reply takes too long, your TCP session will time out. IPsec > pass-thru has a big enough time (about 1 min., but I am not certain) > window to ensure that inbound traffic does arrive. Not everyone uses TCP, so why make assumptions about uset traffic that can only turn out to be wrong? IPsec is not TCPsec. If the timeout is 1 minute, does this really mean that if I simply don't get a response packet (= the target doesn't have anything bound to the port and will either not send keepalives or its security policy requires another SA for the ICMP), *all* other hosts will be blocked from setting up connections for an entire minute? > > 3. an attacker spoofs an IPsec packet with all fields > > otherwise as the > > NAT expects, but with a bogus SPI? (This packet would of > > course have > > to arrive before any proper response packet would reach the NAT.) > > > > This is interesting! Anytime you let NATs or any intermediate > entity modify or route your packets, you have a potential DoS problem. I > am sure you are familiar with a similar issue in NAT-T. Someone even > wrote a draft about it. But isn't this problem magnified here? The attacker here needs much less knowledge to mount an attack; it simply suffices to forge packets with suitable addresses and any bogus SPI, right? The attacker doesn't need the capability to modify packets in flight, just being able to inject new packets is enough? If I understood your description correctly, the DoS problem (blocking new SAs from being formed) and the bogus SPI problem are quite serious. The problems are different and less severe with NAT-T. -Sami __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From owner-ipsec@lists.tislabs.com Mon Aug 5 08: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 g75FfAw25099; Mon, 5 Aug 2002 08:41:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07181 Mon, 5 Aug 2002 10:44:12 -0400 (EDT) From: "David A. Mcgrew" To: "Housley, Russ" Cc: Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Mon, 5 Aug 2002 07:58: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) In-reply-to: <5.1.0.14.2.20020730092306.0345bf68@exna07.securitydynamics.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ, > -----Original Message----- > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > Sent: Tuesday, July 30, 2002 7:23 AM > To: David A. Mcgrew > Cc: ipsec@lists.tislabs.com > Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt > > > 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. the text looks fine. I would prefer that the SHOULD be a MUST, because violating that limitation voids the security warranty, so to speak. Though current IPsec drafts do leave this sort of limitation to 'security policy', which is consistent with your approach. > > >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? Well, we don't want to add a normative dependency that might delay counter mode from progressing to RFC! Do you really think that it is necessary to reference the ID rather than the RFC in order to avoid manual key use with counter mode? If that's the case, we should perhaps change the text in the counter mode draft. It might be acceptable to say that "AES-CTR MUST NOT be used with manual keying, except for the purposes of testing", or something along that line. > > >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. Actually, the 24-bit truncated SPI values need not be random in order to protect against a precomputation attack. It is sufficient for those values to be used uniformly. An implementation which generates SPI values sequentially would reap the same benefit, if it generated all possible values (and didn't favor the initial portion of the sequence). But we can't rely on a SPI selection strategy for security anyway, since RFC2401 allows any SPI selection method, so it doesn't make much difference. > > 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. It written clearly, though I personally don't understand why an implementer would not include such protection. What other benefit is gained by not including that protection? It would be good to include that explanation, so that the WG can evaluate the tradeoffs that you've made. > > >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! Using the same counter mode key across multiple SAs is potentially dangerous, and the draft needs to be explicit on this. It's my impression that using the same key across multiple SAs is a false economy; I know many that agree with this statement, and a few that disagree with it. I don't care much either way, but we certainly need to make it clear to future implementers what they cannot do. The draft asks that IKE detect and correct collisions in truncated SPI values. To comply with this request, IKE implementations would need to change their behavior. I strongly suspect that it would be best to avoid any need to change IKE! thanks, David > > >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 Mon Aug 5 08:58: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 g75FwJw25831; Mon, 5 Aug 2002 08:58:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07215 Mon, 5 Aug 2002 11:05:18 -0400 (EDT) From: "David A. Mcgrew" To: "Housley, Russ" Cc: , Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Mon, 5 Aug 2002 08:19:39 -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: <5.1.0.14.2.20020730090200.02142cf8@exna07.securitydynamics.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ, sorry for the delayed response, I've been traveling. More inline: > -----Original Message----- > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > Sent: Tuesday, July 30, 2002 6:16 AM > To: David A. Mcgrew > Cc: ipsec@lists.tislabs.com; sfluhrer@cisco.com > Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt > > > 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. To be precise, using a 192-bit AES key rather than a 64-bit 'secret counter component' does not provide more security. This is because precomputation attacks are foiled equally well by either method, and the security level of a cryptosystem is determined by the minimum effective attack. A 192-bit AES key does potentially provide protection against more types of attacks, of course. I have a hard time seeing why we wouldn't want to include a portion in the counter that's unpredictable to an adversary. It has near-zero implementation cost and provides a non-trivial improvement in security. I can cite two other common ciphers which use the make-it-as-secure-as-practical design philosophy: triple-DES and RSA Security's DESX (http://www.rsasecurity.com/rsalabs/faq/3-2-7.html). In fact, the motivation for the secret counter component is directly analogous to that for DESX. From the URL above, "the main motivation for DESX was in providing a computationally simple way to dramatically improve on the resistance of DES to exhaustive key search attacks." Triple-DES uses a 168-bit key and provides no more than 112 bits of security (less in some circumstances, e.g. where the work of Stefan Lucks can be brought to bear). However, the fact that the number of bits in the key is larger than the effective security level is not a problem. That fact does not detract from the real security of the system, it's no harder for a key management protocol to generate the larger key than the smaller, and the security level of the algorithm is understood. > > >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 Using larger keys provides more security. If all costs were equal, no doubt implementers would adopt larger AES key sizes. However, costs aren't equal, since the cost (in sw clock cycles or hw gates) of the larger key sizes is greater than that of AES with 128-bit keys. Also, many implementations only include 128-bit AES (it's the default key size, and the only mandatory-to-implement key size), and many other specifications only mandate the implementation of that key size. The counter mode draft includes 128 bit keys as well. (Question: is this the mandatory-to-implement key size? Or will AES-192 be required?) I have a hard time understanding why we would not want to improve the security of AES-128 when simple and cheap methods that work well with IKE are known. thanks, David From owner-ipsec@lists.tislabs.com Mon Aug 5 09:08: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 g75G8Kw26217; Mon, 5 Aug 2002 09:08:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07259 Mon, 5 Aug 2002 11:17:22 -0400 (EDT) From: "David A. Mcgrew" To: "Housley, Russ" Cc: Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Mon, 5 Aug 2002 08:31:09 -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: <5.1.0.14.2.20020730085158.0345f418@exna07.securitydynamics.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ, > -----Original Message----- > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > Sent: Tuesday, July 30, 2002 5:56 AM > To: David A. Mcgrew > Cc: ipsec@lists.tislabs.com > Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt > > > 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. Agreed. > 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 But why not make the per-packet value that's managed within the security boundary be the sequence number? If an LFSR is used to generate explicit IVs, then it will need to be generated and managed within the security boundary. An LFSR is no easier to manage than an integer, since both types share the same properties w.r.t. the storage and movement of data. If the ESP sequence number is generated within the security boundary, it can be used to provide secure anti-replay protection as well as secure per-packet values for counter mode. David From owner-ipsec@lists.tislabs.com Mon Aug 5 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 g75HWPw01324; Mon, 5 Aug 2002 10:32:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07350 Mon, 5 Aug 2002 11:39:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 5 Aug 2002 11:49:27 -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 At 5:30 PM -0700 7/26/02, David A. Mcgrew wrote: >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. I agree that this debate should be technical, but your message clearly shows that you tried to bring the imprimatur of your employer into the discussion. Your behavior, in terms of the wording of the message, and in terms of the design team process, further earned you the personal criticisms I levied. Your indignant disclaimer is out of place. So, let's look at the technical arguments you made, my responses, and your comments to my responses. To avoid needless message expansion, I have summarized: On the topic of the overhead posed by an explicit vs. implicit IV, I questioned the 20-byte number you used as an example. Your rebuttal was vague and in no way countered my observation that the payload size you cited is a very misleading value. Dave Oran pointed out that header compression can reduce the IP header overhead, and the ESP header as well. But the UDP header is inside the encryption boundary, as are the ESP padding and pad length and NEXT field, and the ESP ICV is random. So, my point stands, i.e., either you were very careless in making the comparison between a 20-byte payload and an 8-byte IV, or you were intentionally skewing the argument. My point about inappropriately referring to your employer in this argument, presumably to lend it greater weight, also stands. With regard to the security evaluation boundary argument, the issue is exactly that sharing SA state, specifically sequence number values, across chip or PC board boundaries presents a limitation on performance. I serve (or have served) as a technical advisor to three different companies developing high speed crypto chips for IPsec. The hardware engineers in each company agree with my observation that is would be a fundamentally bad idea to try to maintain sequence number sync across chip/board boundaries, for very high speed implementations. Separartely, you maintained that your employer had not encountered any problems in this regard, and I countered that this was probably because your employer was not building high assurance products, and thus the security boundary was very large. A check of the FIPS 140-1 evaluated products list confirms my assertion about the assurance level of all Cisco evaluated products. Again, your response has not countered my criticisms. Instead you asked what vendors didn't maintain the sequence number within the security perimeter. That's not the point. The point is that, historically, there has been no need to maintain the ESP sequence counter within the perimeter for FIPS 140-1. But, reusing it for counter mode creates that need and adversely limits the design space for higher assurance products. The above argument segues into the disagreement re the pitfalls of reusing ESP sequence numbers for counter mode, and what I maintain is an irrelevant discussion of other crypto modes. You claim to not understand the security difference between sequence numbers used, optionally, for anti-replay, and unique values used as inputs to a crypto algorithm. The distinction is that the former use is of secondary security importance, as evidenced by the fact that it is an optional feature (for the receiver) and that is is outside the security evaluation boundary under 140-1/2. In contrast. the inputs for counter mode are security critical values that fall within the evaluation boundary for 140-1/2. As is so often the case, the term "trust" has no relevance here. The ESP sequence number plays a well-defined role, and reusing it for another purpose is a bad design approach, from a security standpoint. Ask one of your colleagues who has first hand experience with the security evaluation process; perhaps they can explain this notion better than I. With regard to the use of counters for per-packet and intra-packet inputs to counter mode, your response did not rebut my observation that the 2-fold difference in adder size was an issue ignore by your initial claim. You did respond to my observations about the greater flexibility afforded to a product designer by a per-packet input approach that allows the sender to choose whatever means of generating the value that meets the security and performance requirements for a product. Your response was as assertion that the 8-byte overhead of an explicit IV is not worth the flexibility. This is a value judgement, not a technical argument. However, I am annoyed by the way you tend to couch the argument, i.e., as though this is an extra 8 bytes, whereas the reality is that the same 8-byte overhead that has been the default for ESP (in CBC mode) since it became a standard. So the question is not whether to add 8 bytes, but whether there is a pressing need to remove 8 bytes. Finally, you dispute, thought only faintly, my characterization of the history of the design team and how we got to this point. There really is little ambiguity here. Russ was added to the team at your invitation. One might argue about whether you asked him to join in an effort to sway the team to your proposal. It is a fact, however, that Russ developed a compromise document, that the rest of the design team agreed to it, and that you choose to bring your arguments to the list in an effort to reject the compromise. Steve From owner-ipsec@lists.tislabs.com Mon Aug 5 13:09: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 g75K9Ww10271; Mon, 5 Aug 2002 13:09:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07933 Mon, 5 Aug 2002 15:09:41 -0400 (EDT) Date: Mon, 5 Aug 2002 12:24:04 -0700 (PDT) From: Jan Vilhuber To: "Housley, Russ" cc: "Dilkie, Lee" , Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: <5.1.0.14.2.20020730154915.03516eb0@exna07.securitydynamics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not so sure. SRTP and IPsec live in completely different domains, and voice over IPsec is still necessary, where a tunnel is necessary. SRTP does not tunnel. For example, you may already have an IPsec tunnel between a branch office and the home office. Running SRTP alongside that pre-existing tunnel does not work (because of the different address space in which the tunnel and the srtp session would exist. Yes, you COULD tunnel srtp through an IP-in-IP tunnel or GRE tunnel. But then you have to administer and configure two virtually identical tunnels, which I'm sure most administrators won't want to do. It would be preferable to tunnel voice over the same IPsec tunnel with minimal hit on packet expansion. In my mind, the trade off is operational complexity (i.e. 1 IPsec tunnel for regular data and one ipip tunnel for voice and signalling) versus minimal packet expansion (voice over the IPsec tunnel). Once you factor in some internal header-compression schemes (i.e. header-compress the packets going INTO the IPsec tunnel), voice over IPsec still sounds reasonable, because it mitigates most of the packet expansion caused by the ESP header. The smaller we can make the rest of the packet expansion (IV's authentication tags, etc), the better. jan On Tue, 30 Jul 2002, Housley, Russ wrote: > 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 > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Aug 5 13:22: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 g75KMrw11012; Mon, 5 Aug 2002 13:22:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07983 Mon, 5 Aug 2002 15:29:48 -0400 (EDT) From: "David A. Mcgrew" To: "Stephen Kent" Cc: Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Mon, 5 Aug 2002 12:44:00 -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, personal remarks elided, your technical comments and my responses below. Steve Kent wrote: > > On the topic of the overhead posed by an explicit vs. implicit IV, I > questioned the 20-byte number you used as an example. Your rebuttal > was vague and in no way countered my observation that the payload > size you cited is a very misleading value. Dave Oran pointed out that > header compression can reduce the IP header overhead, and the ESP > header as well. But the UDP header is inside the encryption boundary, > as are the ESP padding and pad length and NEXT field, and the ESP ICV > is random. So, my point stands, i.e., either you were very careless > in making the comparison between a 20-byte payload and an 8-byte IV, > or you were intentionally skewing the argument. No. Perhaps I should have provided more detail when I referred to RFC2507. >From Section 7.10: ... when the ESP Header is used in tunnel mode an entire IP packet is encrypted, and the headers of that packet MAY be compressed before the packet is encrypted at the entry point of the tunnel. Also, perhaps you are unaware of the work being done to compress headers inside of tunnels. Examples of this work include draft-ietf-avt-crtp-enhance-04.txt and draft-ietf-avt-tcrtp-06.txt, and much of the work of the Robust Header Compression (RHOC) WG is applicable as well. It's worth nothing that compression that can be used in conjunction with IPsec is an explicit goal of the RHOC WG. Many of these technologies were originally developed with voice over IP in mind, but can be used to general benefit, especially over wireless links. > With regard to the security evaluation boundary argument, the issue > is exactly that sharing SA state, specifically sequence number > values, across chip or PC board boundaries presents a limitation on > performance. I serve (or have served) as a technical advisor to three > different companies developing high speed crypto chips for IPsec. The > hardware engineers in each company agree with my observation that is > would be a fundamentally bad idea to try to maintain sequence number > sync across chip/board boundaries, for very high speed > implementations. Steve, I've participated in high speed hardware designs using AES counter mode, and we have not seen the limitation that you describe. I think that the best way to get to the root of our disagreement is for you to provide more details about the design that you have in mind. What are the goals to which that design is aiming (10 gigabits per second? 100 gigabits per second? 1 terabit per second?) and what assumptions does it make (use existing chips? use some particular ASIC technology or particular backplane?)? Why is it necessary to use the same key in different ASICs or boards (which is apparently driving your concern about sequence numbers), and why is it desirable to do so if those ASICs are within different security boundaries? If it is really necessary to have multiple senders for a single key, why not use a short sender-id value? Is the design that you describe in brief a proprietary one or an open one? If the latter, can you refer to an example in the published literature? Additionally, I do not understand your implicit contention that LFSR synchronization would be easier to maintain across chip or board boundaries than integer synchronization. The synch problem is fundamental to the movement of data, not to the algebraic mechanism by which a next-value is generated. > Separartely, you maintained that your employer had not encountered > any problems in this regard, and I countered that this was probably > because your employer was not building high assurance products, and > thus the security boundary was very large. A check of the FIPS 140-1 > evaluated products list confirms my assertion about the assurance > level of all Cisco evaluated products. The FIPS-140 evaluations of Cisco gear have no bearing on this discussion. It's worth pointing out that the approach of using the ESP sequence number as a per-packet counter does *not* decrease security, and that you have not even argued that it does. What you have argued is that that approach could prove limiting in a high-speed design - *not* that it is less secure. That approach does not limit the security of a system, and does not have any bearing on the FIPS-140-2 process. > Again, your response has not > countered my criticisms. Instead you asked what vendors didn't > maintain the sequence number within the security perimeter. That's > not the point. The point is that, historically, there has been no > need to maintain the ESP sequence counter within the perimeter for > FIPS 140-1. RFCs 2401 and 2406 state that "protection against replays" is one of the goals of IPsec and that ESP provides that service by using monotonically increasing sequence numbers. Given this fact, how can an implementer *not* put the ESP sequence number within the security perimeter? On a standards level, an ESP cipher can expect a sequence number to be unique. From RFC2406: 2.2 Sequence Number This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is mandatory and is always present even if the receiver does not elect to enable the anti-replay service for a specific SA. ... ... If anti-replay is enabled (the default), the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. > But, reusing it for counter mode creates that need and > adversely limits the design space for higher assurance products. I do not believe that the use of a monotonically increasing sequence number limits the design space. This is apparently the real source of our disagreements. > > The above argument segues into the disagreement re the pitfalls of > reusing ESP sequence numbers for counter mode, and what I maintain is > an irrelevant discussion of other crypto modes. You claim to not > understand the security difference between sequence numbers used, > optionally, for anti-replay, and unique values used as inputs to a > crypto algorithm. No, what I don't understand is the contention that the current standards do not mandate the uniqueness of the ESP sequence number. > The distinction is that the former use is of > secondary security importance, as evidenced by the fact that it is an > optional feature (for the receiver) and that is is outside the > security evaluation boundary under 140-1/2. In contrast. the inputs > for counter mode are security critical values that fall within the > evaluation boundary for 140-1/2. Sure, but the fact that anti-replay may be of lesser importance than confidentiality has no bearing on the fact that RFCs mandate the uniqueness of the ESP sequence numbers. > As is so often the case, the term > "trust" has no relevance here. The ESP sequence number plays a > well-defined role, and reusing it for another purpose is a bad design > approach, from a security standpoint. Including the ESP sequence number inside the security boundary *increases* security. > > With regard to the use of counters for per-packet and intra-packet > inputs to counter mode, your response did not rebut my observation > that the 2-fold difference in adder size was an issue ignore by your > initial claim. Fine, but that has nothing to do with the point that I was making: the performance advantage of a 64-bit LFSR over a 64-bit integer increment function is completely negligible when compared to the computational cost of the AES-encrypting a packet. This is an important point because draft-ietf-ipsec-ciph-aes-ctr-00.txt uses that performance advantage as a false premise in support of an argument as to why an implementer might want to use an LFSR rather than counter mode. > > You did respond to my observations about the greater flexibility > afforded to a product designer by a per-packet input approach that > allows the sender to choose whatever means of generating the value > that meets the security and performance requirements for a product. > Your response was as assertion that the 8-byte overhead of an > explicit IV is not worth the flexibility. This is a value judgement, > not a technical argument. However, I am annoyed by the way you tend > to couch the argument, i.e., as though this is an extra 8 bytes, > whereas the reality is that the same 8-byte overhead that has been > the default for ESP (in CBC mode) since it became a standard. So the > question is not whether to add 8 bytes, but whether there is a > pressing need to remove 8 bytes. Yes, reducing the encapsulation overhead of ESP while maintaining security is a worthwhile goal, in my opinion. David From owner-ipsec@lists.tislabs.com Mon Aug 5 19:55: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 g762tDw27813; Mon, 5 Aug 2002 19:55:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA08597 Mon, 5 Aug 2002 22:06:30 -0400 (EDT) MBOX-Line: From owner-ipsec@lists.tislabs.com Mon Aug 05 16:45:43 2002 From: "David A. Mcgrew" To: "Housley, Russ" Cc: , Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Mon, 5 Aug 2002 08:19:39 -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: <5.1.0.14.2.20020730090200.02142cf8@exna07.securitydynamics.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ, sorry for the delayed response, I've been traveling. More inline: > -----Original Message----- > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > Sent: Tuesday, July 30, 2002 6:16 AM > To: David A. Mcgrew > Cc: ipsec@lists.tislabs.com; sfluhrer@cisco.com > Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt > > > 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. To be precise, using a 192-bit AES key rather than a 64-bit 'secret counter component' does not provide more security. This is because precomputation attacks are foiled equally well by either method, and the security level of a cryptosystem is determined by the minimum effective attack. A 192-bit AES key does potentially provide protection against more types of attacks, of course. I have a hard time seeing why we wouldn't want to include a portion in the counter that's unpredictable to an adversary. It has near-zero implementation cost and provides a non-trivial improvement in security. I can cite two other common ciphers which use the make-it-as-secure-as-practical design philosophy: triple-DES and RSA Security's DESX (http://www.rsasecurity.com/rsalabs/faq/3-2-7.html). In fact, the motivation for the secret counter component is directly analogous to that for DESX. From the URL above, "the main motivation for DESX was in providing a computationally simple way to dramatically improve on the resistance of DES to exhaustive key search attacks." Triple-DES uses a 168-bit key and provides no more than 112 bits of security (less in some circumstances, e.g. where the work of Stefan Lucks can be brought to bear). However, the fact that the number of bits in the key is larger than the effective security level is not a problem. That fact does not detract from the real security of the system, it's no harder for a key management protocol to generate the larger key than the smaller, and the security level of the algorithm is understood. > > >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 Using larger keys provides more security. If all costs were equal, no doubt implementers would adopt larger AES key sizes. However, costs aren't equal, since the cost (in sw clock cycles or hw gates) of the larger key sizes is greater than that of AES with 128-bit keys. Also, many implementations only include 128-bit AES (it's the default key size, and the only mandatory-to-implement key size), and many other specifications only mandate the implementation of that key size. The counter mode draft includes 128 bit keys as well. (Question: is this the mandatory-to-implement key size? Or will AES-192 be required?) I have a hard time understanding why we would not want to improve the security of AES-128 when simple and cheap methods that work well with IKE are known. thanks, David From owner-ipsec@lists.tislabs.com Mon Aug 5 20:49: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 g763nOw29070; Mon, 5 Aug 2002 20:49:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA08727 Mon, 5 Aug 2002 23:08:35 -0400 (EDT) From: "Jayant Shukla" To: , Subject: RE: Clarification of potential NAT multiple client solutions Date: Mon, 5 Aug 2002 20:19:44 -0700 Message-ID: <000001c23cf8$1cc03630$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: <20020805080755.75847.qmail@web12208.mail.yahoo.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 Sami Vaarala > > Not everyone uses TCP, so why make assumptions about uset > traffic that can only turn out to be wrong? IPsec is not TCPsec. > These are very vague statements! You still have not answered my question! What application do you have in mind? > > But isn't this problem magnified here? The attacker here > needs much less knowledge to mount an attack; it simply > suffices to forge packets with suitable addresses and any > bogus SPI, right? The attacker doesn't need the capability > to modify packets in flight, just being able to inject new > packets is enough? > > If I understood your description correctly, the DoS problem > (blocking new SAs from being formed) and the bogus SPI > problem are quite serious. The problems are different and > less severe with NAT-T. > The origin of the problem is identical, and it is the NAT. In one case you have to send a packet a random SPI within a very short time interval and in the other case you can send a packet with spoofed source address _anytime_, but that packet must be based on a real packet. You can argue all you want as to which one is better/worse. The fact that attack can be launched anytime in case of NAT-T, makes it much worse in my opinion. Regards, Jayant www.trlokom.com > -Sami > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better http://health.yahoo.com > From owner-ipsec@lists.tislabs.com Tue Aug 6 11:47: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 g76Ilww25418; Tue, 6 Aug 2002 11:47:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10249 Tue, 6 Aug 2002 13:54:07 -0400 (EDT) Message-Id: <4.3.2.7.2.20020806110031.03309ec0@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Aug 2002 11:07:03 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: Son of Ike status Cc: tytso@mit.edu, byfraser@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Ted and I would like to update the working group on the status of the SOI work. After listening to the working group and after discussions between the JFK and IKEv2 teams, we will be moving forward using draft-ietf-ipsec-ikev2-02.txt as the starting document. An initial modification to the document will be to integrate ideas from JFK's approach of using 4 messages with a stateless cookie. Charlie Kaufman has agreed to be the document editor, and all other authors will be given due credit within the body of the document. Over the next couple of weeks, we will summarize the discussion on the mailing list over the past two months regarding SOI requirements to create a proposed requirements and design directions document. This will be sent to the list for comment and ultimately be used to provide direction for the SOI design effort. We would like to thank all members of both the JFK and the IKEv2 teams, and the members of the working group for the time and effort you have spent helping us move forward with SOI. This direction has the agreement of both the JFK and IKEv2 teams and also appears to represent the discussions within the working group. Best regards, Barb and Ted From owner-ipsec@lists.tislabs.com Tue Aug 6 12:49: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 g76JnXw29212; Tue, 6 Aug 2002 12:49:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10400 Tue, 6 Aug 2002 15:03:51 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 6 Aug 2002 15:15:54 -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 At 12:44 PM -0700 8/5/02, David A. Mcgrew wrote: >Steve, > >personal remarks elided, your technical comments and my responses below. > >Steve Kent wrote: >> >> On the topic of the overhead posed by an explicit vs. implicit IV, I >> questioned the 20-byte number you used as an example. Your rebuttal >> was vague and in no way countered my observation that the payload >> size you cited is a very misleading value. Dave Oran pointed out that >> header compression can reduce the IP header overhead, and the ESP >> header as well. But the UDP header is inside the encryption boundary, >> as are the ESP padding and pad length and NEXT field, and the ESP ICV >> is random. So, my point stands, i.e., either you were very careless >> in making the comparison between a 20-byte payload and an 8-byte IV, >> or you were intentionally skewing the argument. > >No. Perhaps I should have provided more detail when I referred to RFC2507. >>From Section 7.10: > > ... when the ESP Header is used in tunnel mode an entire IP > packet is encrypted, and the headers of that packet MAY be compressed > before the packet is encrypted at the entry point of the tunnel. > >Also, perhaps you are unaware of the work being done to compress headers >inside of tunnels. Examples of this work include >draft-ietf-avt-crtp-enhance-04.txt and draft-ietf-avt-tcrtp-06.txt, and much >of the work of the Robust Header Compression (RHOC) WG is applicable as >well. It's worth nothing that compression that can be used in conjunction >with IPsec is an explicit goal of the RHOC WG. Many of these technologies >were originally developed with voice over IP in mind, but can be used to >general benefit, especially over wireless links. I see that you elided my personal comments to make room for yours :-) The question here, David, is not what I or the WG is aware or unaware of. The question is why you chose to use an obviously misleading figure as a basis for the argument. If you wanted to make a precise argument about a realistic size for VoIP packets, before and after applying ESP, then you could have done so. You certainly have no trouble devoting considerable text to the math associated with the issue of how many blocks of data can be safely encrypted with counter mode. What we have seen in subsequent messages on this topic from others is that: - another protocol was developed to secure VoIP, specifically, calling into question whether we should bother trying to optimize ESP for this application - a very little analysis of the likely, average compression that may be obtained for SOME the headers that you omitted in your initial message - another message suggesting that well, maybe there is still a desire to have a very efficient version of ESP to use with VoIP, anyway - a message from the IP storage folks says, 8-bytes is not an issue for them What we still do not have is a concrete analysis of the percentage overhead that would be associated with use of an explicit vs. implicit IV, under various realistic cases, e.g., no compression, outer header compression only, inner and outer header compression, for VoIP. This analysis is what you should have provided in your message, or in any subsequent message, but it is still missing. > > With regard to the security evaluation boundary argument, the issue >> is exactly that sharing SA state, specifically sequence number >> values, across chip or PC board boundaries presents a limitation on >> performance. I serve (or have served) as a technical advisor to three >> different companies developing high speed crypto chips for IPsec. The >> hardware engineers in each company agree with my observation that is >> would be a fundamentally bad idea to try to maintain sequence number >> sync across chip/board boundaries, for very high speed >> implementations. > >Steve, I've participated in high speed hardware designs using AES counter >mode, and we have not seen the limitation that you describe. I think that >the best way to get to the root of our disagreement is for you to provide >more details about the design that you have in mind. What are the goals to >which that design is aiming (10 gigabits per second? 100 gigabits per >second? 1 terabit per second?) and what assumptions does it make (use >existing chips? use some particular ASIC technology or particular >backplane?)? Why is it necessary to use the same key in different ASICs or >boards (which is apparently driving your concern about sequence numbers), >and why is it desirable to do so if those ASICs are within different >security boundaries? If it is really necessary to have multiple senders for >a single key, why not use a short sender-id value? Is the design that you >describe in brief a proprietary one or an open one? If the latter, can you >refer to an example in the published literature? I have participated in 10 Gb/s IPsec chip designs, but this issue arises at lower speeds as well. You seem to have lost track of the underlying issue, an issue we discussed at length in the design team list, specifically in my message of May 17, 2002. At that time I pointed out the problem faced by PPVPN and other "aggregating" IPsec implementations, where there is a need to mux traffic from one SA over multiple chips/boards, to maximize throughput while minimizing hardware costs. Product developers trying to do this have discovered that it is infeasible (from a performance perspective) to maintain the shared state for each SA's sequence number since that state must be updated by multiple chips, perhaps on different PC boards, within a product, for each packet sent or received on an SA. The WG discussed this issue on the list over a year ago, when product developers first encountered the problem. The vendors were asking if the sequence numbers could be made optional, for the sender, to avoid the problem. The WG said no. The WG then strongly recommended managing the sequence numbers for each SA before sending the traffic for the SA to a crypto module (as viewed from the transmitter's perspective). This is the context that motivates managing these values off chip, although others may exist as well. This design strategy is consistent with security evaluation practices such as 140-1/2, i.e., it does not affect the security boundary for the product evaluation so long as the sequence number is used only for its originally defined purpose. >Additionally, I do not understand your implicit contention that LFSR >synchronization would be easier to maintain across chip or board boundaries >than integer synchronization. The synch problem is fundamental to the >movement of data, not to the algebraic mechanism by which a next-value is >generated. This is not an LFSR-specific issue. This too has been discussed on the design team mailing list. Your colleague, Scott Fluhrer, first suggested that one could use part of the counter for a per-chip ID, to avoid conflicts in the per-packet IV. One of the attractions of the compromise design that Russ proposed is that it allows the sender to include a per-chip value, if needed, as part of the per-packet IV, or to omit it if there is no need to mux an SA over multiple chips. This is essentially invisible to the receiver, who does not need to examine IV structure. One cannot make use of the same technique with the ESP sequence numbers, because the semantics for them require sequential generation of values. > > Separartely, you maintained that your employer had not encountered >> any problems in this regard, and I countered that this was probably >> because your employer was not building high assurance products, and >> thus the security boundary was very large. A check of the FIPS 140-1 >> evaluated products list confirms my assertion about the assurance > > level of all Cisco evaluated products. > >The FIPS-140 evaluations of Cisco gear have no bearing on this discussion. >It's worth pointing out that the approach of using the ESP sequence number >as a per-packet counter does *not* decrease security, and that you have not >even argued that it does. What you have argued is that that approach could >prove limiting in a high-speed design - *not* that it is less secure. That >approach does not limit the security of a system, and does not have any >bearing on the FIPS-140-2 process. YOU argued that maintaining ESP sequence numbers (that are used as counter mode inputs) within the security boundary was easy, based on Cisco's experience. Since the context of the discussion was the security issues associated with maintaining these values off chip, for the reasons explained (yet again) above, I responded that keeping the counters within the security boundary was easy only if one had a relatively broad security boundary, consistent with a low level of assurance, e.g., FIPS 140-1/2 level 2 or less. So, my observation about the evaluation of Cisco IPsec products is at level 2 is thoroughly relevant to this discussion, given your initial message on the topic. The use of these sequence numbers as counter inputs almost certainly does decrease security assurance, relative to current designs, whenever SAs have to be muxed across chips/boards. This is because the counters need to be managed off chip under these circumstances, for the reasons explained above, again. At best one might be able to maintain the currently attainable assurance level if the security boundary were extended to encompass the parts of the systems where the (now overused) sequence numbers were generated, but almost certainly at increased system costs/complexity. I believe we discussed this topic in the design team message exchanges earlier this year. > > Again, your response has not >> countered my criticisms. Instead you asked what vendors didn't >> maintain the sequence number within the security perimeter. That's >> not the point. The point is that, historically, there has been no >> need to maintain the ESP sequence counter within the perimeter for >> FIPS 140-1. > >RFCs 2401 and 2406 state that "protection against replays" is one of the >goals of IPsec and that ESP provides that service by using monotonically >increasing sequence numbers. Given this fact, how can an implementer *not* >put the ESP sequence number within the security perimeter? > > > >> But, reusing it for counter mode creates that need and >> adversely limits the design space for higher assurance products. > >I do not believe that the use of a monotonically increasing sequence number >limits the design space. This is apparently the real source of our >disagreements. > > > The above argument segues into the disagreement re the pitfalls of > > reusing ESP sequence numbers for counter mode, and what I maintain is >> an irrelevant discussion of other crypto modes. You claim to not >> understand the security difference between sequence numbers used, >> optionally, for anti-replay, and unique values used as inputs to a >> crypto algorithm. > >No, what I don't understand is the contention that the current standards do >not mandate the uniqueness of the ESP sequence number. > > > The distinction is that the former use is of >> secondary security importance, as evidenced by the fact that it is an >> optional feature (for the receiver) and that is is outside the >> security evaluation boundary under 140-1/2. In contrast. the inputs >> for counter mode are security critical values that fall within the >> evaluation boundary for 140-1/2. > >Sure, but the fact that anti-replay may be of lesser importance than >confidentiality has no bearing on the fact that RFCs mandate the uniqueness >of the ESP sequence numbers. > > > > As is so often the case, the term >> "trust" has no relevance here. The ESP sequence number plays a >> well-defined role, and reusing it for another purpose is a bad design >> approach, from a security standpoint. > >Including the ESP sequence number inside the security boundary *increases* >security. What the preceding text says is that you really do not understand FIPS 140-1/2! The security concerns for ESP sequence number values are NOT the same as for crypto inputs such as like IVs. This is not a matter of opinion; it is a clear cut evaluation criteria difference under FIPS 140-1/2. Ask anyone who is familiar with the criteria. Today, if an IPsec chip manages the sequence number on chip, the assurance level is potentially quite high, but this is irrelevant to FIPS evaluation, so long as the sequence number is NOT used as an input to the crypto function as an IV or equivalent. But, we have identified a set of scenarios where it is not feasaible to manage the sequence number on chip, as explained above. So, the WG suggested, over a year ago, that designers to to adopt a strategy that will require moving the sequence number off chip, under some circumstances. This posed no problem re basic crypto security, UNTIL you proposed using this sequence number as an input to counter mode. That adversely affects the security boundary and, the assurance for products. > > With regard to the use of counters for per-packet and intra-packet > > inputs to counter mode, your response did not rebut my observation >> that the 2-fold difference in adder size was an issue ignore by your >> initial claim. > >Fine, but that has nothing to do with the point that I was making: the >performance advantage of a 64-bit LFSR over a 64-bit integer increment >function is completely negligible when compared to the computational cost of >the AES-encrypting a packet. This is an important point because >draft-ietf-ipsec-ciph-aes-ctr-00.txt uses that performance advantage as a >false premise in support of an argument as to why an implementer might want >to use an LFSR rather than counter mode. The issue here is a subtle one, but the argument in Russ' ID is not incorrect, although it may be incomplete. Consider an IPsec device optimized for your favorite application, VoIP. Let's say that the encrypted payload, including all protocol headers and the ESP trailer is always between 16 and 32 bytes. I could design an IPsec device using a crypto chip that contains two AES cores. (Many high end crypto chips today employ multiple algorithm cores.) When I receive an outbound packet for an SA, I know I will need no more than 32 bytes of key stream, because of the limited application context for which I have optimized the device. I select the key for the SA and I generate a new, per-packet IV and use it to create key stream for both AES cores, in parallel, with the intra-packet counter values set to "0" and "1" (maybe hardwired). Now I can begin to encrypt that packet. When I am one ROUND into the encryption process, I am now ready to begin encrypting a new packet, perhaps for another SA. So, the time to generate the new per-packet IV might be bounded by the time to execute one ROUND of AES, rather than by a full, 12-round encryption process, as you suggest. This is one example where the time for per-packet IV generation might be as critical as the intra-packet counter update. I suspect there are others. > > You did respond to my observations about the greater flexibility > > afforded to a product designer by a per-packet input approach that >> allows the sender to choose whatever means of generating the value >> that meets the security and performance requirements for a product. >> Your response was as assertion that the 8-byte overhead of an >> explicit IV is not worth the flexibility. This is a value judgement, >> not a technical argument. However, I am annoyed by the way you tend >> to couch the argument, i.e., as though this is an extra 8 bytes, >> whereas the reality is that the same 8-byte overhead that has been >> the default for ESP (in CBC mode) since it became a standard. So the >> question is not whether to add 8 bytes, but whether there is a >> pressing need to remove 8 bytes. > >Yes, reducing the encapsulation overhead of ESP while maintaining security >is a worthwhile goal, in my opinion. Your proposal reduces security, in a range of real system implementations, in exchange for an 8-byte savings. We still don't have a firm percentage overhead we can assign to that 8-byte savings, in your favorite case, but we do know that it is tiny in most other contexts. You have argued for a very conservative bound on the number of packets that can be encrypted per SA, because you understand the potential adverse, theoretical consequences of sending more than 2^64 blocks, even though you cannot describe an attack that would exploit this potential weakness. On the other hand, experience has shown that the vast majority of security failures in deployed crypto systems arise not from subtle crypto vulnerabilities of the sort you are focusing on, but on system design and implementation vulnerabilities. My emphasis on not reusing the ESP sequence number, to save 8 bytes, is based on that latter set of concerns and a desire to offer an architecture that preserves maximum implementation and performance flexibility for developers, while not degrading security assurance. Steve From owner-ipsec@lists.tislabs.com Tue Aug 6 13:07: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 g76K7dw00579; Tue, 6 Aug 2002 13:07:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10445 Tue, 6 Aug 2002 15:25:56 -0400 (EDT) From: "David A. Mcgrew" To: "Stephen Kent" Cc: Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Tue, 6 Aug 2002 12:39:47 -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, this email is directed at the personal rather than technical comments that you made yesterday. > Finally, you dispute, thought only faintly, my characterization of > the history of the design team and how we got to this point. There > really is little ambiguity here. Russ was added to the team at your > invitation. One might argue about whether you asked him to join in an > effort to sway the team to your proposal. While I respect Russ, and his contribution to the debate has been positive, I did not invite him to be a co-author of the counter mode draft that Bob Moskowitz was editing. This should be obvious, since I never had the authority to appoint contributors or editors! Nor was I aware that Bob intended to turn over the document to Russ; like many, I found out about it after the fact. > It is a fact, however, that > Russ developed a compromise document, that the rest of the design > team agreed to it, By my count, there were seven people on the 'design team', two of whom wanted a secret counter component, two of whom expressed a desire to avoid packet expansion, and four of whom expressed agreement with the compromise outlined by Russ. But this fact is immaterial, since the counter mode document is a WG action item and as such is intended to represent the WG and not any particular subset of individuals. > and that you choose to bring your arguments to the > list in an effort to reject the compromise. > > Steve I participate in the IETF in order to promote open standards for useful new technologies. David From owner-ipsec@lists.tislabs.com Tue Aug 6 13:37: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 g76Kb1w01566; Tue, 6 Aug 2002 13:37:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10520 Tue, 6 Aug 2002 15:55:12 -0400 (EDT) Message-Id: <200208062008.g76K8o5k022093@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-reply-to: Your message of "Mon, 05 Aug 2002 12:24:04 PDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 06 Aug 2002 16:08:49 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jan" == Jan Vilhuber writes: Jan> I'm not so sure. SRTP and IPsec live in completely different domains, Jan> and voice over IPsec is still necessary, where a tunnel is Jan> necessary. SRTP does not tunnel. For example, you may already have an We are regularly doing 6 party VoIP (h.323, alas) conference calls over IPsec. There is an H.323 bridge (openmcu) on a box that does both the VoIP and IPsec. There is 3Mb/s in, 800kb/s out at the concentrator, and a range of 1M modem, T1, cable and ADSL at the other ends. Starting a download at the same time, can hurt. It isn't perfect, but most of this is due to the fact that we are not yet able to negotiate proper SLAs for the data with our ISPs. We have not yet enabled any IPcomp, mostly because of laziness, and also because we are doing this over Opportunistic Encryption, which does not negotiate IPcomp by default. So, I want to agree strongly with Jan: Many voice applications will occur over IPsec. Particularly ones where there is already IPsec infrastructure (tunnels). Branch office/HQ connections are logical situations where this makes a lot of sense - buy more bandwidth for the Internet connection, save on LD calls. But, this is too rich for many application spaces. Anything without wires. SRTP will continue to exist there. Desk VoIP boxes will likely have to support SRTP as well IPsec. What does this mean for AES-CTR mode to me: Anyone who *needs* AES-CTR mode, likely needs it because they have >1Gb/s links they want to secure. As such, I think that they have the bandwidth not to care. If AES-CTR mode is *the* AES mode that we suggest, then there may be some place for some other system that is more compact. That system likely doesn't even want to pay for the 8 byte IV that current 3DES-CBC has. The previous email went on to give numbers for how many channels one gets on a T1 with various encodings. This is relevant to telcos that are trying to replace TDM with packets. While they may have big pipes to fill, it isn't clear to me that they will be terminating all of these packets on the same piece of equipment - an OC-12-rate full of packets that terminate eventually on customer connected T1-rate equipment may not require AES-CTR mode. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPVAsz4qHRg3pndX9AQF0pgQAngiWQXSlenGntvBaOmWzQROHUhpG4DrT 8uPsJ9rxT5qPmNR3iSoXosKWRDoh91UwPBiQlyRf1Wgc7K76/HYhcftTt1R1UDFa O/blFqtqYOReFpmDkPQjyRpjHSPK0FXfJlze4owuEZWGwfhGNpAU1nFmhAEeK6Vi FVC/GVBM618= =ZlU2 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Aug 6 14:15: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 g76LFqw03012; Tue, 6 Aug 2002 14:15:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10591 Tue, 6 Aug 2002 16:31:29 -0400 (EDT) Date: Tue, 6 Aug 2002 13:45:16 -0700 (PDT) From: Jan Vilhuber To: Michael Richardson cc: Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: <200208062008.g76K8o5k022093@marajade.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 6 Aug 2002, Michael Richardson wrote: > > > >>>>> "Jan" == Jan Vilhuber writes: > Jan> I'm not so sure. SRTP and IPsec live in completely different domains, > Jan> and voice over IPsec is still necessary, where a tunnel is > Jan> necessary. SRTP does not tunnel. For example, you may already have an > > We are regularly doing 6 party VoIP (h.323, alas) conference calls over > IPsec. There is an H.323 bridge (openmcu) on a box that does both the VoIP > and IPsec. There is 3Mb/s in, 800kb/s out at the concentrator, and a range of > 1M modem, T1, cable and ADSL at the other ends. Starting a download at the > same time, can hurt. > > It isn't perfect, but most of this is due to the fact that we are not yet > able to negotiate proper SLAs for the data with our ISPs. > > We have not yet enabled any IPcomp, mostly because of laziness, and also > because we are doing this over Opportunistic Encryption, which does not > negotiate IPcomp by default. > >From what I've seen, IPcomp wouldn't help voip much. Most codecs are already compressed. On an internal alpha-test network we run (to our cisco telecommuters ;) we (the administrators for said alpha network) tried IPcomp once and it seemed to make voice quality worse. I suppose that's anecdotal evidence, not hard evidence, but there it is. jan > So, I want to agree strongly with Jan: > > Many voice applications will occur over IPsec. Particularly ones where > there is already IPsec infrastructure (tunnels). Branch office/HQ connections > are logical situations where this makes a lot of sense - buy more bandwidth > for the Internet connection, save on LD calls. > > But, this is too rich for many application spaces. Anything without > wires. SRTP will continue to exist there. Desk VoIP boxes will likely have to > support SRTP as well IPsec. > > What does this mean for AES-CTR mode to me: > > Anyone who *needs* AES-CTR mode, likely needs it because they have >1Gb/s > links they want to secure. As such, I think that they have the bandwidth not > to care. > > If AES-CTR mode is *the* AES mode that we suggest, then there may be some > place for some other system that is more compact. That system likely doesn't > even want to pay for the 8 byte IV that current 3DES-CBC has. > > The previous email went on to give numbers for how many channels one gets > on a T1 with various encodings. This is relevant to telcos that are trying to > replace TDM with packets. While they may have big pipes to fill, it isn't > clear to me that they will be terminating all of these packets on the same > piece of equipment - an OC-12-rate full of packets that terminate eventually on > customer connected T1-rate equipment may not require AES-CTR mode. > > ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Tue Aug 6 14:33: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 g76LXHw05084; Tue, 6 Aug 2002 14:33:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10695 Tue, 6 Aug 2002 16:53:42 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 6 Aug 2002 17:07:27 -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 At 12:39 PM -0700 8/6/02, David A. Mcgrew wrote: >Steve, > >this email is directed at the personal rather than technical comments that >you made yesterday. > >> Finally, you dispute, thought only faintly, my characterization of >> the history of the design team and how we got to this point. There >> really is little ambiguity here. Russ was added to the team at your >> invitation. One might argue about whether you asked him to join in an >> effort to sway the team to your proposal. > >While I respect Russ, and his contribution to the debate has been positive, >I did not invite him to be a co-author of the counter mode draft that Bob >Moskowitz was editing. This should be obvious, since I never had the >authority to appoint contributors or editors! Nor was I aware that Bob >intended to turn over the document to Russ; like many, I found out about it >after the fact. The text you quote above fro my message says nothing about Russ being named to edit the document. The WG chairs made that decision. I stated that you invited Russ to become a member of the design team. Why are you providing a response that does not address my comment? > > It is a fact, however, that >> Russ developed a compromise document, that the rest of the design >> team agreed to it, > >By my count, there were seven people on the 'design team', two of whom >wanted a secret counter component, two of whom expressed a desire to avoid >packet expansion, and four of whom expressed agreement with the compromise >outlined by Russ. But this fact is immaterial, since the counter mode >document is a WG action item and as such is intended to represent the WG and >not any particular subset of individuals. When Russ proposed the compromise design, only you objected. Niels Furgeson, Jesse Walker, Steve Bellovin, and I agreed with Russ. That's 5 out of 7, by my count. The various positions of the design team members prior to Russ' proposed compromise was not the point of my observation. You persist on trying to spin the discussion to suit your ends. Doesn't' this get tiring after a while? > > and that you choose to bring your arguments to the >> list in an effort to reject the compromise. >> >> Steve > >I participate in the IETF in order to promote open standards for useful new >technologies. > >David Those of us who have been working in the IETF to develop open standards for many years know to NEVER use our employer's name in an argument, generally know how to work out disagreements in design teams, and know how to accept compromises in an effort to make progress in working groups. The recent successful compromise between the JFK and IKE v2 design teams to create a next generation key management protocol for IPsec is a good example. These would be good skills for you to develop. Steve From owner-ipsec@lists.tislabs.com Tue Aug 6 15:36: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 g76MaGw08061; Tue, 6 Aug 2002 15:36:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10842 Tue, 6 Aug 2002 17:50:19 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Tue, 6 Aug 2002 15:04:19 -0700 To: Stephen Kent , "David A. Mcgrew" From: Paul Hoffman / VPNC 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 Er, how is the tone of the current thread helping the rest of us learn about the intricacies of the choices in counter mode so we can make a technically sound decision? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Aug 7 08:08: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 g77F82w19766; Wed, 7 Aug 2002 08:08:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12157 Wed, 7 Aug 2002 10:07:29 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E603330A1D@zcard0ke.ca.nortel.com> From: "Dennis Beard" To: Barbara Fraser Cc: ipsec@lists.tislabs.com Subject: RE: Son of Ike status Date: Tue, 6 Aug 2002 15:54:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23D83.1FE6ABBA" 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_01C23D83.1FE6ABBA Content-Type: text/plain; charset="iso-8859-1" Hello Barbara and Ted, I am very happy to read of your decision to use the IKEv2 draft as the starting document. I think that when this decision process is concluded, that draft will basically remain as written today with the inclusion of several JFK characteristics. A major decision criteria should be to protect those user organizations that have a legacy investment in IKEv1. Therefore, it is good to start with the v2 draft so that the similar payload formats and messages of v1 may be more easily utilized in the v2 era. Additionally, other important features such as two phases and protocol extensibility will be preserved. Regards, Dennis Beard For example, starting with the IKEv2 document as the base is great. That way we can use payload formats and messages similar to that in IKE etc. Of course, other important features such as two phases, protocol extensibility etc., will be left intact. -----Original Message----- From: Barbara Fraser [mailto:byfraser@cisco.com] Sent: Tuesday, August 06, 2002 2:07 PM To: ipsec@lists.tislabs.com Cc: tytso@mit.edu; byfraser@cisco.com Subject: Son of Ike status Hi, Ted and I would like to update the working group on the status of the SOI work. After listening to the working group and after discussions between the JFK and IKEv2 teams, we will be moving forward using draft-ietf-ipsec-ikev2-02.txt as the starting document. An initial modification to the document will be to integrate ideas from JFK's approach of using 4 messages with a stateless cookie. Charlie Kaufman has agreed to be the document editor, and all other authors will be given due credit within the body of the document. Over the next couple of weeks, we will summarize the discussion on the mailing list over the past two months regarding SOI requirements to create a proposed requirements and design directions document. This will be sent to the list for comment and ultimately be used to provide direction for the SOI design effort. We would like to thank all members of both the JFK and the IKEv2 teams, and the members of the working group for the time and effort you have spent helping us move forward with SOI. This direction has the agreement of both the JFK and IKEv2 teams and also appears to represent the discussions within the working group. Best regards, Barb and Ted ------_=_NextPart_001_01C23D83.1FE6ABBA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Son of Ike status

Hello Barbara and Ted,

I am very happy to read of your decision to use the = IKEv2 draft as the starting document.  I think that when this = decision process is concluded, that draft will basically remain as = written today with the inclusion of several JFK characteristics.  = A major decision criteria should be to protect those user organizations = that have a legacy investment in IKEv1.  Therefore, it is good to = start with the v2 draft so that the similar payload formats and = messages of v1 may be more easily utilized in the v2 era.  = Additionally, other important features such as two phases and protocol = extensibility will be preserved.

Regards,

Dennis Beard



For example, starting with the IKEv2 document as the = base is great. That
way we can use payload formats and messages similar = to that in IKE etc.
  Of course, other important features such as = two phases, protocol
extensibility etc., will be left intact.

-----Original Message-----
From: Barbara Fraser [mailto:byfraser@cisco.com]=
Sent: Tuesday, August 06, 2002 2:07 PM
To: ipsec@lists.tislabs.com
Cc: tytso@mit.edu; byfraser@cisco.com
Subject: Son of Ike status


Hi,

Ted and I would like to update the working group on = the status of the SOI
work. After listening to the working group and after = discussions between
the JFK and IKEv2 teams, we will be moving forward =
using  draft-ietf-ipsec-ikev2-02.txt as the = starting document. An initial
modification to the document will be to integrate = ideas from JFK's approach
of using 4 messages with a stateless cookie. Charlie = Kaufman has agreed to
be the document editor, and all other authors will = be given due credit
within the body of the document.

Over the next couple of weeks, we will summarize the = discussion on the
mailing list over the past two months regarding SOI = requirements to create
a proposed requirements and design directions = document.  This will be sent
to the list for comment and ultimately be used to = provide direction for the
SOI design effort.

We would like to thank all members of both the JFK = and the IKEv2 teams, and
the members of the working group for the time and = effort you have spent
helping us move forward with SOI. This direction has = the agreement of both
the JFK and IKEv2 teams and also appears to = represent the discussions
within the working group.

Best regards,
Barb and Ted

------_=_NextPart_001_01C23D83.1FE6ABBA-- From owner-ipsec@lists.tislabs.com Wed Aug 7 12:21: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 g77JLiw01871; Wed, 7 Aug 2002 12:21:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12598 Wed, 7 Aug 2002 14:25:32 -0400 (EDT) Message-ID: <39B01E2189D99F4B8C9612462DB3922A06226B1D@srv-exchange.adtran.com> From: DAVID LEE To: "IPSec List (E-mail)" Subject: SNMP Management for IPSec Devices Date: Wed, 7 Aug 2002 13:39:06 -0500 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 All, Looking at the standards page at VPN (http://www.vpnc.org/vpn-standards.html), all of the working drafts for IPSec MIB's have expired. Any ideas where I might find copies of these drafts? Is there any interest in SNMP management for IPSec devices? Thanks, dave <>< From owner-ipsec@lists.tislabs.com Wed Aug 7 13:00: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 g77K0ew03157; Wed, 7 Aug 2002 13:00:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA12657 Wed, 7 Aug 2002 15:15:54 -0400 (EDT) From: rks@cisco.com Date: Wed, 7 Aug 2002 12:29:42 -0700 (PDT) To: DAVID LEE cc: Cheryl Madson , Narasimha , Leo Temoshenko , "Barry L. Bruins" , Bret Harrison , "IPSec List (E-mail)" Subject: Re: SNMP Management for IPSec Devices In-Reply-To: <39B01E2189D99F4B8C9612462DB3922A06226B1D@srv-exchange.adtran.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi - On Wed, 7 Aug 2002, DAVID LEE wrote: > Looking at the standards page at VPN >(http://www.vpnc.org/vpn-standards.html), all of the working >drafts for IPSec MIB's have expired. Any ideas where I might >find copies of these drafts? Is there any interest in SNMP >management for IPSec devices? This has been on my to-do list for a while. In the short term, we will resubmit the draft of IPsec Flow Monitor MIB. In parallel, I am also trying to bring the best parts of the two proposals (TIm Jenkins et al and Chery Madson et al) to see if we can effect a happy reconciliation as was arrived at with SOI. I suspect that the two proposals differ because they have started out with completely different requirements. The first step, hence, would be to try to reconcile the requirements. We have discussed such a set internally and Cheryl Madson has agreed to send out a draft of this. Meanwhile, if someone could send me John Shriver's correct address, I'd greatly appreciate it. Thanks, Rk x77309 From owner-ipsec@lists.tislabs.com Wed Aug 7 13:31: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 g77KV7w05578; Wed, 7 Aug 2002 13:31:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA12724 Wed, 7 Aug 2002 15:44:06 -0400 (EDT) From: "David A. Mcgrew" To: "Paul Hoffman / VPNC" Cc: Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Wed, 7 Aug 2002 12:58:36 -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 Paul, paul.hoffman@vpnc.org wrote: > Er, how is the tone of the current thread helping the rest of us > learn about the intricacies of the choices in counter mode so we can > make a technically sound decision? Agreed, we need to keep the signal-to-noise ratio higher. I offer to provide a write-up summarizing the security properties of counter mode. David From owner-ipsec@lists.tislabs.com Wed Aug 7 14:18: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 g77LIkw08701; Wed, 7 Aug 2002 14:18:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA12932 Wed, 7 Aug 2002 16:36:54 -0400 (EDT) From: "Housley, Russ" To: "David A. Mcgrew" Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020806145848.035fd458@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 06 Aug 2002 15:02:11 -0400 Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: References: <5.1.0.14.2.20020730092306.0345bf68@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: > > >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! > >Using the same counter mode key across multiple SAs is potentially >dangerous, and the draft needs to be explicit on this. It's my impression >that using the same key across multiple SAs is a false economy; I know many >that agree with this statement, and a few that disagree with it. I don't >care much either way, but we certainly need to make it clear to future >implementers what they cannot do. > >The draft asks that IKE detect and correct collisions in truncated SPI >values. To comply with this request, IKE implementations would need to >change their behavior. I strongly suspect that it would be best to avoid >any need to change IKE! I do not believe that this is correct. It is my understanding that IKE establishes a separate key for encryption and decryption on the SA. This whole discussion applies only when the same key is used for encryption and decryption. Again, this paragraph was included to warn people who are using key management other than IKE. Russ From owner-ipsec@lists.tislabs.com Wed Aug 7 14:20: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 g77LKnw08778; Wed, 7 Aug 2002 14:20:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA12931 Wed, 7 Aug 2002 16:36:51 -0400 (EDT) From: "Housley, Russ" To: "David A. Mcgrew" Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020806145456.035bd1f0@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 06 Aug 2002 14:56:34 -0400 Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: References: <5.1.0.14.2.20020730092306.0345bf68@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 07:58 AM 8/5/2002 -0700, David A. Mcgrew wrote: > > 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. > >Actually, the 24-bit truncated SPI values need not be random in order to >protect against a precomputation attack. It is sufficient for those values >to be used uniformly. An implementation which generates SPI values >sequentially would reap the same benefit, if it generated all possible >values (and didn't favor the initial portion of the sequence). >But we can't rely on a SPI selection strategy for security anyway, since >RFC2401 allows any SPI selection method, so it doesn't make much difference. Good point. I reworded it to: 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 consecutively assign SPI values; however, since the only 24 bits of the SPI are included in the nonce, a SPI value provides limited additional security. Russ From owner-ipsec@lists.tislabs.com Wed Aug 7 14:20: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 g77LKsw08793; Wed, 7 Aug 2002 14:20:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA12919 Wed, 7 Aug 2002 16:36:46 -0400 (EDT) From: "Housley, Russ" To: "David A. Mcgrew" Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020806144838.035d31d0@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 06 Aug 2002 14:49:48 -0400 Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: References: <5.1.0.14.2.20020730092306.0345bf68@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: > > 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? > >Well, we don't want to add a normative dependency that might delay counter >mode from progressing to RFC! Do you really think that it is necessary to >reference the ID rather than the RFC in order to avoid manual key use with >counter mode? If that's the case, we should perhaps change the text in the >counter mode draft. It might be acceptable to say that "AES-CTR MUST NOT be >used with manual keying, except for the purposes of testing", or something >along that line. Since RFC 2401 is an informative reference (not a normative reference), I do not think we need to delay for the update. Russ From owner-ipsec@lists.tislabs.com Wed Aug 7 14:22: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 g77LMmw08881; Wed, 7 Aug 2002 14:22:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA12933 Wed, 7 Aug 2002 16:36:54 -0400 (EDT) From: "Housley, Russ" To: "David A. Mcgrew" Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020806150913.035fa7c8@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 06 Aug 2002 15:13:13 -0400 Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: References: <5.1.0.14.2.20020730085158.0345f418@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: > > The consequences for reusing a sequence number are significantly > > different than the consequence of reusing a CTR mode key stream. > >Agreed. > > > 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. > >But why not make the per-packet value that's managed within the security >boundary be the sequence number? If an LFSR is used to generate explicit >IVs, then it will need to be generated and managed within the security >boundary. An LFSR is no easier to manage than an integer, since both types >share the same properties w.r.t. the storage and movement of data. If the >ESP sequence number is generated within the security boundary, it can be >used to provide secure anti-replay protection as well as secure per-packet >values for counter mode. The point of the compromise it to accommodate both assurance implementation approaches and both IV generation approaches. In one of these four cases, the sequence number and the IV will be identical. In the other three cases, they will probably be different values. When the sequence number is assigned within the assurance boundary, and an integer counter is being used to generate the IV, the same value could be used for the sequence number and the IV. Of course, in my proposal, it gets carried twice in the packet. Russ From owner-ipsec@lists.tislabs.com Wed Aug 7 14:45: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 g77LjVw09553; Wed, 7 Aug 2002 14:45:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13017 Wed, 7 Aug 2002 17:00:06 -0400 (EDT) From: "David A. Mcgrew" To: "Housley, Russ" Cc: Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Date: Wed, 7 Aug 2002 14:13:37 -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: <5.1.0.14.2.20020806145848.035fd458@exna07.securitydynamics.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Russ, > -----Original Message----- > From: Housley, Russ [mailto:rhousley@rsasecurity.com] > Sent: Tuesday, August 06, 2002 12:02 PM > To: David A. Mcgrew > Cc: ipsec@lists.tislabs.com > Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt > > > David: > > > > >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! > > > >Using the same counter mode key across multiple SAs is potentially > >dangerous, and the draft needs to be explicit on this. It's my > impression > >that using the same key across multiple SAs is a false economy; > I know many > >that agree with this statement, and a few that disagree with it. I don't > >care much either way, but we certainly need to make it clear to future > >implementers what they cannot do. > > > >The draft asks that IKE detect and correct collisions in truncated SPI > >values. To comply with this request, IKE implementations would need to > >change their behavior. I strongly suspect that it would be best to avoid > >any need to change IKE! > > I do not believe that this is correct. It is my understanding that IKE > establishes a separate key for encryption and decryption on the SA. This > whole discussion applies only when the same key is used for > encryption and > decryption. > > Again, this paragraph was included to warn people who are using key > management other than IKE. Ah, I understand. I didn't get this from my read of the draft, but you're right. David From owner-ipsec@lists.tislabs.com Thu Aug 8 08: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 g78FdXw23927; Thu, 8 Aug 2002 08:39:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14625 Thu, 8 Aug 2002 10:50:27 -0400 (EDT) Date: Thu, 8 Aug 2002 11:02:11 -0400 From: Ran Canetti Message-Id: <200208081502.LAA28746@ornavella.watson.ibm.com> To: authtime@nist.gov, ietf-ipsra@vpnc.org, ietf-kink@vpnc.org, ietf-krb-wg@anl.gov, ietf-openpgp@imc.org, ietf-otp@research.telcordia.com, ietf-pkix@imc.org, ietf-sacred@imc.org, ietf-smime@imc.org, ietf-ssh@netbsd.org, ietf-tls@lists.certicom.com, ipsec-policy@vpnc.org, ipsec@lists.tislabs.com, msec@securemulticast.org, saag@mit.edu, w3c-ietf-xmldsig@w3.org Subject: A new crypto forum at the IRTF Cc: canetti@ornavella.watson.ibm.com, mcgrew@cisco.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, this note is to announce the formation of a new IRTF Research Group, called "Crypto Forum Research Group" (CFRG). The group is intended to answer the need for a single forum where cryptographers, network security experts, and protocol designers can exchange ideas and investigate the use of cryptographic techniques for network protocols in general and for the IETF in particular. CFRG is of course NOT intended as a replacement for the work done at the IETF Working Groups in standardizing actual protocols. Rather, it the group provides a forum where general techniques and tools can be developed and scrutinized to the benefit of multiple Working Groups. Apart from disseminating the understanding of cryptographic techniques within the IETF, the outputs of CFRG are expected to come in the form of informational RFCs (in the tradition of, e.g., RFCs 1321 [MD5] and 2104 [HMAC]). You are cordially invited to join the mailing list and bring forth the cryptographic question that deprived you of sleep lately. The list is open. To reduce spam, the chairs will moderate mails from non-members. For Charter, more information, and subscription instructions, see http://www.irtf.org/cfrg. Best, David Mcgrew and Ran Canetti, CFRG co-chairs. PS. We'd like to thank Mark Baugher for his great help in setting up the new research group. From owner-ipsec@lists.tislabs.com Thu Aug 8 12:11: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 g78JBQw06045; Thu, 8 Aug 2002 12:11:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15122 Thu, 8 Aug 2002 14:21:03 -0400 (EDT) Message-ID: <3D52A518.7C6CFD80@nist.gov> Date: Thu, 08 Aug 2002 13:06:32 -0400 From: "O. Kim" Organization: NIST X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com CC: okim@nist.gov Subject: IKE-SA Deletion Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The second paragraph in Section 2.8 (in the IKEV2 proposal) specifies: To rekey an IKE-SA, establish a new equivalent IKE-SA (see section 4 and 4.2 below) with the peer to whom the old IKE-SA is shared using a Phase 2 negotiation within the existing IKE-SA. An IKE-SA so created inherits all of the original IKE-SA's child SAs. Use the new IKE-SA for all control messages needed to maintain the child-SAs created by the old IKE-SA, and delete the old IKE-SA. Also, in Section 7.11 (Delete Payload), the second paragraph specifies: Deletion of the IKE-SA is indicated by a Protocol-Id of 0 (IKE) but no SPIs. Deletion which is concerned with a Child-SA, such as ESP or AH, will contain the Protocol-Id of that protocol (e.g. ESP, AH) and the SPI is the receiving entity's SPI(s). Section 2.8 does not specifically specify which IKE SA is used (e.g., new or old) for deletion of the old IKE SA. Also, it is not clear for the responder when to transfer (inherits) all the existing child SAs from the old IKE SA (e.g., once a new IKE SA has been established or an IKE Delete Payload is received). If the old IKE SA is used to delete itself, then a Delete Payload for the IKE SA needs no SPI as specified in Section 7.11 above. Then, the old SA needs to be valid for a certain amount of time after re-keying. If a new IKE SA is used to remove the old IKE SA and a Delete Payload does not specify SPI (the responder cookie), how is the responder supposed to know which IKE SA to be removed? Can somebody clarify on this? Thanks, Okhee NIST From owner-ipsec@lists.tislabs.com Fri Aug 9 12: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 g79Jg4w07523; Fri, 9 Aug 2002 12:42:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17134 Fri, 9 Aug 2002 14:34:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20020809114527.02e6bbb0@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Aug 2002 11:47:59 -0700 To: rks@cisco.com From: Barbara Fraser Subject: Re: SNMP Management for IPSec Devices Cc: DAVID LEE , Cheryl Madson , "IPSec List (E-mail)" In-Reply-To: References: <39B01E2189D99F4B8C9612462DB3922A06226B1D@srv-exchange.adtran.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ted and I were just discussing these documents. According to Uri, our MIB advisor, it's ok if the documents advance as they currently exist. Given that we're going to be needing new MIBs for SOI, does it make sense to spend the effort here? Earlier discussion on the list indicated that the flow monitoring MIB has been implemented by some number of folks. Barb At 12:29 PM 8/7/2002, rks@cisco.com wrote: >Hi - > > On Wed, 7 Aug 2002, DAVID LEE wrote: > > > Looking at the standards page at VPN > >(http://www.vpnc.org/vpn-standards.html), all of the working > >drafts for IPSec MIB's have expired. Any ideas where I might > >find copies of these drafts? Is there any interest in SNMP > >management for IPSec devices? > >This has been on my to-do list for a while. > >In the short term, we will resubmit the draft >of IPsec Flow Monitor MIB. In parallel, I am >also trying to bring the best parts of the two >proposals (TIm Jenkins et al and Chery Madson et al) >to see if we can effect a happy reconciliation >as was arrived at with SOI. > >I suspect that the two proposals differ because they >have started out with completely different requirements. >The first step, hence, would be to try to reconcile the >requirements. > >We have discussed such a set internally and Cheryl Madson >has agreed to send out a draft of this. Meanwhile, if >someone could send me John Shriver's correct address, >I'd greatly appreciate it. > >Thanks, > >Rk >x77309 From owner-ipsec@lists.tislabs.com Mon Aug 12 08:59: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 g7CFxKw12490; Mon, 12 Aug 2002 08:59:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21625 Mon, 12 Aug 2002 10:58:22 -0400 (EDT) Message-ID: <3D57D030.5CB81115@thematrix.ncsc.mil> Date: Mon, 12 Aug 2002 11:11:44 -0400 From: "Casimir A. Potyraj" X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Yogesh.Swami@nokia.com CC: ipsec@lists.tislabs.com Subject: Re: DOS attacks with Cookies References: <025E7DD4182874489CC2F61EE0FA19CEA7C4@daebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please ignore that previous send. Arrrg! sorry. --CP From owner-ipsec@lists.tislabs.com Mon Aug 12 08:59: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 g7CFxMw12501; Mon, 12 Aug 2002 08:59:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21619 Mon, 12 Aug 2002 10:53:21 -0400 (EDT) Message-ID: <3D57CF05.60949235@thematrix.ncsc.mil> Date: Mon, 12 Aug 2002 11:06:45 -0400 From: "Casimir A. Potyraj" X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Yogesh.Swami@nokia.com CC: ipsec@lists.tislabs.com Subject: Re: DOS attacks with Cookies References: <025E7DD4182874489CC2F61EE0FA19CEA7C4@daebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yogesh.Swami@nokia.com wrote: > > Hi, > > I have a question/comment on the use of Cookies for key exchange. I think there is a potential for very easy and more pointed DOS attacks with the present key exchange mechanisms. Let me give an example to explain this. > > Lets say Alice wants to establish a Phase-1 SA with Bob. Also, lets say Trudy--who wants to deny Alice any access to resources--can some how snoop Alice's packets. Also let the round trip time between Alice and Trudy be far less than the roundtrip time between Alice and Bob (say Trudy is on the same LAN as Alice for the sake of this example--but Trudy does not necessarily have to be on the same LAN, all she needs is a) ability to see Alice's packet and b) her round trip time to be less than that of Bob). > > When Alice sends her cookie, Trudy sees this packet coming on UDP 500, and quickly responds to Alice's cookie with a random cookie and sets the source IP address in her response packet to be that of Bob and sends it to Alice. > > Alice will receive this Cookie response from Trudy long before she can receive Bob's response and since Alice has no way of knowing if this cookie really came from Bob, she will respond to this cookie thinking this is a Legitimate response and proceed with the Deffie Hellmann exchange to Bob. > > When Bob receives this cookie, the cookies will not match (Since the cookie was generated by Trudy) and he will just reject the request thinking that Alice was trying to attack him. This way Trudy has successfully prevented Alice from having a secure channel with Bob. > > Question: What is Alice supposed to do when she receives a Duplicate Message with a Different Cookie from the same host? Please consider the case when there was a retransmission and the retransmitted packet got corrupted in the way and the two cookies--though legitimate--have different values. > > If Trudy can automate this process, she can deny access to anyone who she can snoop. If someone can write a worm that does this automatically and spread this across the internet (in this case on just needs to snoop the loop back interface and does not even need to see packet on the wire) one can create a lot more damage. > > If Alice and Bob were to be two SG (security gateways), then Trudy can virtually isolate every one behind Alice's SG from accessing Bob's resources. In the process of avoiding DOS attacks we have opened room for even worse attacks (this is worse because it could be targeted towards a particular set of people without affecting others. So, for example, if two companies want to vote for a merger one of them can prevent the other by simply not allowing any secure channel, while people from the other company can easily do so) > > I guess, the only solution is to do authentication before doing anything else -- in which case we don't need any cookies anymore and we can save a round trip too. Any comments? > > Thanks > Best Regards > Yogesh From owner-ipsec@lists.tislabs.com Mon Aug 12 11:15: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 g7CIFJw21126; Mon, 12 Aug 2002 11:15:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21841 Mon, 12 Aug 2002 13:24:56 -0400 (EDT) From: "Housley, Russ" To: Paul Koning Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020812132959.034c8430@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 12 Aug 2002 13:32:26 -0400 Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: <15698.29835.507253.798720@pkoning.dev.equallogic.com> References: <5.1.0.14.2.20020730092306.0345bf68@exna07.securitydynamics.com> <5.1.0.14.2.20020806145848.035fd458@exna07.securitydynamics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul: > >> The draft asks that IKE detect and correct collisions in truncated > >> SPI values. To comply with this request, IKE implementations > >> would need to change their behavior. I strongly suspect that it > >> would be best to avoid any need to change IKE! > > Housley,> I do not believe that this is correct. It is my > Housley,> understanding that IKE establishes a separate key for > Housley,> encryption and decryption on the SA. This whole discussion > Housley,> applies only when the same key is used for encryption and > Housley,> decryption. > >You should doublecheck this because my memory is getting rather rusty >here, but as I recall IKE will produce the same key for both >directions IF you use the same SPI. That's because the key is >produced from a hash that takes as inputs the phase 1 result (D-H and >all that) along with the chosen phase 2 SPI number. If both sides >allow the same number to be used then the same key results. > >The reason I remember this is that I ran into it when implementing >IPsec a few years ago, decided this was NOT a Good Thing, and took >steps to enforce different SPI values for the two directions. Good catch. I have changed the security considerations to reflect this situation. Here is the new text: Therefore, stream ciphers, including AES-CTR, should not be used with statically configured keys. It is inappropriate to use AES-CTR with statically configured keys. Extraordinary measures would be needed to prevent reuse of a counter block value with the static key across power cycles. To be safe, implementations MUST use fresh keys with AES-CTR. The Internet Key Exchange (IKE) protocol [IKE] can be used to establish fresh keys. When IKE is used to establish fresh keys between two peer entities, separate keys are established for the two traffic flows when each participant provides a different SPI values. However, if each participant provides the same SPI value, then the same key will be used for encrypting outbound traffic and decrypting incoming traffic, resulting in a high probability that the participants will select the same IV values for some packets. Therefore, when IKE is used with AES-CTR, the two participants MUST select different SPI values. When a mechanism other than IKE is used to establish fresh keys, and that mechanism establishes only a single key to encrypt packets, then there is a high probability that the peers will select the same IV values for some packets. Thus, to avoid counter block collisions, ESP implementations that permit use of the same key for encrypting outbound traffic and decrypting incoming traffic with the same peer MUST ensure that the two peers assign different SPI values to the security association (SA). Further, since the counter block only contains the least significant 24 bits of the SPI value, such implementations MUST ensure that the two SPI values differ in the least significant bits. Russ From owner-ipsec@lists.tislabs.com Mon Aug 12 14:29: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 g7CLTGw00952; Mon, 12 Aug 2002 14:29:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22119 Mon, 12 Aug 2002 16:37:24 -0400 (EDT) Message-Id: <5.1.0.14.2.20020812153543.03400a48@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 12 Aug 2002 15:41:20 -0400 To: ipsec@lists.tislabs.com From: "Housley, Russ" Subject: AES-CTR Initial Counter Block Value Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk draft-ietf-ipsec-ciph-aes-ctr-00.txt says: Block Counter The block counter field is the least significant 32 bits of the counter block. The block counter begins with the value of zero, and it is incremented to generate subsequent portions of the key stream. The block counter is a 32-bit big-Endian integer value. I am interested in hardware that will implement AES-CTR and CCM (see draft-housley-ccm-mode-00.txt). I missed a detail in trying to preserve compatibility, and while trying to generate test vectors for the -01 draft, I discovered it. I would like to begin the counter at one instead of zero. CCM uses the block with a zero counter value to encrypt the integrity check value. The proof was easier if the zero value was always used for this purpose. Russ From owner-ipsec@lists.tislabs.com Mon Aug 12 20:07: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 g7D37fw14106; Mon, 12 Aug 2002 20:07:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA22767 Mon, 12 Aug 2002 22:05:30 -0400 (EDT) MBOX-Line: From owner-ipsec@lists.tislabs.com Mon Aug 12 17:10:40 2002 Message-ID: <3D57CF05.60949235@thematrix.ncsc.mil> Date: Mon, 12 Aug 2002 11:06:45 -0400 From: "Casimir A. Potyraj" X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Yogesh.Swami@nokia.com CC: ipsec@lists.tislabs.com Subject: Re: DOS attacks with Cookies References: <025E7DD4182874489CC2F61EE0FA19CEA7C4@daebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yogesh.Swami@nokia.com wrote: > > Hi, > > I have a question/comment on the use of Cookies for key exchange. I think there is a potential for very easy and more pointed DOS attacks with the present key exchange mechanisms. Let me give an example to explain this. > > Lets say Alice wants to establish a Phase-1 SA with Bob. Also, lets say Trudy--who wants to deny Alice any access to resources--can some how snoop Alice's packets. Also let the round trip time between Alice and Trudy be far less than the roundtrip time between Alice and Bob (say Trudy is on the same LAN as Alice for the sake of this example--but Trudy does not necessarily have to be on the same LAN, all she needs is a) ability to see Alice's packet and b) her round trip time to be less than that of Bob). > > When Alice sends her cookie, Trudy sees this packet coming on UDP 500, and quickly responds to Alice's cookie with a random cookie and sets the source IP address in her response packet to be that of Bob and sends it to Alice. > > Alice will receive this Cookie response from Trudy long before she can receive Bob's response and since Alice has no way of knowing if this cookie really came from Bob, she will respond to this cookie thinking this is a Legitimate response and proceed with the Deffie Hellmann exchange to Bob. > > When Bob receives this cookie, the cookies will not match (Since the cookie was generated by Trudy) and he will just reject the request thinking that Alice was trying to attack him. This way Trudy has successfully prevented Alice from having a secure channel with Bob. > > Question: What is Alice supposed to do when she receives a Duplicate Message with a Different Cookie from the same host? Please consider the case when there was a retransmission and the retransmitted packet got corrupted in the way and the two cookies--though legitimate--have different values. > > If Trudy can automate this process, she can deny access to anyone who she can snoop. If someone can write a worm that does this automatically and spread this across the internet (in this case on just needs to snoop the loop back interface and does not even need to see packet on the wire) one can create a lot more damage. > > If Alice and Bob were to be two SG (security gateways), then Trudy can virtually isolate every one behind Alice's SG from accessing Bob's resources. In the process of avoiding DOS attacks we have opened room for even worse attacks (this is worse because it could be targeted towards a particular set of people without affecting others. So, for example, if two companies want to vote for a merger one of them can prevent the other by simply not allowing any secure channel, while people from the other company can easily do so) > > I guess, the only solution is to do authentication before doing anything else -- in which case we don't need any cookies anymore and we can save a round trip too. Any comments? > > Thanks > Best Regards > Yogesh From owner-ipsec@lists.tislabs.com Tue Aug 13 06: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 g7DDWEw06786; Tue, 13 Aug 2002 06:32:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA23744 Tue, 13 Aug 2002 08:41:25 -0400 (EDT) Date: 13 Aug 2002 12:26:27 -0000 Message-ID: <20020813122627.3824.qmail@webmail9.rediffmail.com> MIME-Version: 1.0 From: "mohanlal jangir" Reply-To: "mohanlal jangir" To: ipsec@lists.tislabs.com Subject: about SPD Content-type: text/plain; format=flowed Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, This question may be implementation specific; answer if it have significance. Most implementation have SPD entry like; for given selectors protect traffic by AH in transport mode and so on. Why this(how to protect) should be part of SPD. As long as I understand, it should be like this; for given selectors SPD should tell, "protect the traffic". And how to protect, should be part of SAs, if they exist. Regards mohanlal ******************************************* MOHAN LAL JANGIR M.Tech.(Computer Technology) INDIAN INSTITUTE OF TECHNOLOGY,DELHI Home page: http://mljangir.tripod.com ******************************************* From owner-ipsec@lists.tislabs.com Tue Aug 13 08:40: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 g7DFeAw16276; Tue, 13 Aug 2002 08:40:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24243 Tue, 13 Aug 2002 10:55:32 -0400 (EDT) Message-Id: <200208131509.g7DF9WZs002838@thunk.east.sun.com> From: Bill Sommerfeld To: "mohanlal jangir" cc: ipsec@lists.tislabs.com Subject: Re: about SPD In-Reply-To: Your message of "13 Aug 2002 12:26:27 -0000." <20020813122627.3824.qmail@webmail9.rediffmail.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 13 Aug 2002 11:09:32 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > This question may be implementation specific; answer if it > have significance. > Most implementation have SPD entry like; for given selectors > protect traffic by AH in transport mode and so on. Why this(how to > protect) should be part of SPD. SPD defines the policy; SA defines the mechanism. the SPD is long-lived; SA's are ephemeral -- created on demand, expire, are rekeyed, ... Different protocols, algorithms, and modes provide different protection (otherwise we could just use one algorithm and one mode); they are not always considered interchangable. (for instance, key lengths and perceived strength will differ from algorithm to algorithm). When dynamic key management is in use, the SPD tells key management what algorithms, modes, and protocols are acceptable; SA's are then created on demand as needed. From owner-ipsec@lists.tislabs.com Tue Aug 13 08:43: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 g7DFhEw16369; Tue, 13 Aug 2002 08:43:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24226 Tue, 13 Aug 2002 10:46:26 -0400 (EDT) From: "Housley, Russ" To: "David A. Mcgrew" Cc: ipsec@lists.tislabs.com, sfluhrer@cisco.com Message-Id: <5.1.0.14.2.20020813102102.03042618@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 13 Aug 2002 10:55:04 -0400 Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: References: <5.1.0.14.2.20020730090200.02142cf8@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: Sorry for the delay on response to this message. I have been traveling, and I wanted to confer with some other folks at RSA Labs before replying. Having finally done that, here is my reply. > > [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. > > [Russ] > > 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. > > [David] > > 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. > > > > I understand this proposal. And, in fact, to the key management protocol, there is no difference between the distribution of a short AES key with an offset and a long AES key. It is certainly preferable to managing a key and an offset as separate quantities. > > [Russ] > > If one is concerned about this type of dictionary attack, the > > use of a longer AES key provides more protection > > [David] > > 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. > > [Russ] > > 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. >[David] >To be precise, using a 192-bit AES key rather than a 64-bit 'secret >counter component' >does not provide more security. This is because precomputation attacks are >foiled equally well by either method, and the security level of a >cryptosystem is determined by the minimum effective attack. A 192-bit AES >key does potentially provide protection against more types of attacks, of >course. It seems to me that the inclusion of a public value that cannot be predicted by the attacker provides the same protection against precomputation attacks. That is the reason that the truncated SPI is included in the counter block in the current document. For the same reason, in the 802.11 WLAN context, the source MAC address is included. This was possible because the maximum packet size is much smaller, so only 16 bits are needed for the block counter. This value works well because it forces the attacker to build a separate (and huge) table for each possible packet source. I would prefer a larger unpredictable (to the attacker) value, but there is not room in the 128-bit counter block. Yet, increasing the attacker's table size to accommodate the possible SPI values seems to be a reasonable tradeoff. >[David] >I have a hard time seeing why we wouldn't want to include a portion in the >counter that's unpredictable to an adversary. It has near-zero >implementation cost and provides a non-trivial improvement in security. As explained above, I do want a value that is unpredictable to the attacker. There is no reason for it to be a secret value. The point is to thwart the precomputation attack by making the table size too huge to manage. >[David] >I can cite two other common ciphers which use the >make-it-as-secure-as-practical design philosophy: triple-DES and RSA >Security's DESX (http://www.rsasecurity.com/rsalabs/faq/3-2-7.html). In >fact, the motivation for the secret counter component is directly analogous >to that for DESX. From the URL above, "the main motivation for DESX was in >providing a computationally simple way to dramatically improve on the >resistance of DES to exhaustive key search attacks." > > I do not think that this a fair comparison. Larger key size was not an option for the DES environment. > > [David] > > 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. > > [Russ] > > 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. >[David] >Using larger keys provides more security. If all costs were equal, no doubt >implementers would adopt larger AES key sizes. However, costs aren't equal, >since the cost (in sw clock cycles or hw gates) of the larger key sizes is >greater than that of AES with 128-bit keys. Also, many implementations only >include 128-bit AES (it's the default key size, and the only >mandatory-to-implement key size), and many other specifications only mandate >the implementation of that key size. The counter mode draft includes 128 >bit keys as well. (Question: is this the mandatory-to-implement key size? >Or will AES-192 be required?) > >I have a hard time understanding why we would not want to improve the >security of AES-128 when simple and cheap methods that work well with IKE >are known. I feel that we have included a public value to increase the burden on the attacker that wishes to mount a precomputation attack. And, for those that feel this is an inadequate countermeasure, the use of a longer key is available, which is useful in countering more than just a precomputation attack. I think that 128-bit keys should be the mandatory to implement. I have not heard anyone argue for making any other key sizes mandatory. Russ From owner-ipsec@lists.tislabs.com Tue Aug 13 12:05: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 g7DJ5nw27600; Tue, 13 Aug 2002 12:05:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24775 Tue, 13 Aug 2002 14:13:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20020813111237.01c5e480@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Aug 2002 11:28:17 -0700 To: "Housley, Russ" From: Scott Fluhrer Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Cc: "David A. Mcgrew" , ipsec@lists.tislabs.com, sfluhrer@cisco.com In-Reply-To: <5.1.0.14.2.20020813102102.03042618@exna07.securitydynamics .com> References: <5.1.0.14.2.20020730090200.02142cf8@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 07:55 AM 8/13/2002, Housley, Russ wrote: >>[David] >>To be precise, using a 192-bit AES key rather than a 64-bit 'secret >>counter component' >>does not provide more security. This is because precomputation attacks are >>foiled equally well by either method, and the security level of a >>cryptosystem is determined by the minimum effective attack. A 192-bit AES >>key does potentially provide protection against more types of attacks, of >>course. > >It seems to me that the inclusion of a public value that cannot be >predicted by the attacker provides the same protection against >precomputation attacks. That is the reason that the truncated SPI is >included in the counter block in the current document. Just one obvious comment: if the security analysis of draft-ietf-ipsec-ciph-aes-ctr-00.txt was done under the assumption that (truncated) SPIs are unpredictable (or at least nonconstant), the draft should explicitly require that the (truncated) SPIs be unpredictable (or at least nonconstant). Currently, RFC2401, 2406 impose no such requirement on an implementation. -- scott From owner-ipsec@lists.tislabs.com Wed Aug 14 06:28: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 g7EDSvw15069; Wed, 14 Aug 2002 06:28:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA29325 Wed, 14 Aug 2002 08:37:36 -0400 (EDT) Date: 14 Aug 2002 09:26:28 -0000 Message-ID: <20020814092628.31728.qmail@webmail9.rediffmail.com> MIME-Version: 1.0 From: "mohanlal jangir" Reply-To: "mohanlal jangir" To: ipsec@lists.tislabs.com Subject: multiple policies or SA bundle !!! Content-type: text/plain; format=flowed Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, If a packet from one source to another destination is to be affored security as AH in transport followed by ESP in transport, then which is correcet answer: (assuming manual configuration only and both SAs do exist) A) For given packet selector, we have a SPD entry, that have SA bundle containing SAs, one for ESP and another for AH B) For given selector, we have a SPD entry, which points to one SA and the SPD entry points to another SPD entry, which points to second SA. C) Either way possible depending on implementation Thanks & Regards ******************************************* MOHAN LAL JANGIR M.Tech.(Computer Technology) INDIAN INSTITUTE OF TECHNOLOGY,DELHI Home page: http://mljangir.tripod.com ******************************************* From owner-ipsec@lists.tislabs.com Wed Aug 14 06:58: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 g7EDwLw18218; Wed, 14 Aug 2002 06:58:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29423 Wed, 14 Aug 2002 09:15:57 -0400 (EDT) From: "Housley, Russ" To: Scott Fluhrer Cc: "David A. Mcgrew" , ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020814090127.02102930@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 14 Aug 2002 09:06:37 -0400 Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: <4.3.2.7.2.20020813111237.01c5e480@mira-sjcm-3.cisco.com> References: <5.1.0.14.2.20020813102102.03042618@exna07.securitydynamics .com> <5.1.0.14.2.20020730090200.02142cf8@exna07.securitydynamics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott: >>>[David] >>>To be precise, using a 192-bit AES key rather than a 64-bit 'secret >>>counter component' >>>does not provide more security. This is because precomputation attacks are >>>foiled equally well by either method, and the security level of a >>>cryptosystem is determined by the minimum effective attack. A 192-bit AES >>>key does potentially provide protection against more types of attacks, of >>>course. >>[Russ] >>It seems to me that the inclusion of a public value that cannot be >>predicted by the attacker provides the same protection against >>precomputation attacks. That is the reason that the truncated SPI is >>included in the counter block in the current document. >[Scott] >Just one obvious comment: if the security analysis of >draft-ietf-ipsec-ciph-aes-ctr-00.txt was done under the assumption that >(truncated) SPIs are unpredictable (or at least nonconstant), the draft >should explicitly require that the (truncated) SPIs be unpredictable (or >at least nonconstant). Currently, RFC2401, 2406 impose no such >requirement on an implementation. [Russ] I have updated the last paragraph of the Design Rationale section to capture the sense of this discussion. I agree that corresponding changes to ESP would be desirable. The updated paragraph now says: The inclusion of the truncated SPI provides a weak countermeasure against precomputation attacks. For this countermeasure to be effective, the attacker must not be able to predict the least significant 24 bits of the SPI well in advance of security association establishment. The use of long keys provides a strong countermeasure to these attacks, and AES offers key sizes that thwart these attacks for many decades to come. Thanks for your review, Russ From owner-ipsec@lists.tislabs.com Wed Aug 14 12:07: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 g7EJ7Uw06551; Wed, 14 Aug 2002 12:07:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00038 Wed, 14 Aug 2002 14:09:35 -0400 (EDT) Message-ID: <3D5A8170.6CC5CA92@nist.gov> Date: Wed, 14 Aug 2002 12:12:32 -0400 From: "O. Kim" Organization: NIST X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Charlie_Kaufman@notesdev.ibm.com CC: ipsec@lists.tislabs.com Subject: Re: IKE-SA Deletion References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie_Kaufman@notesdev.ibm.com wrote: > > Thank you for the careful reading. The spec is ambiguous. What I had > in > mind was that the old IKE SA delete itself as a last act after the new > > one is acknowledged at both ends, thus not needing to specify an > SPI in the delete. If after the new SA has been > in place long enough that the two > ends can be confident that no messages are "in flight", the new SA > deletes itself, I believe no messages can be lost. > > Does this sound reasonable? If so, I can tighten the language. > Thank you for the response. Deletion of the old IKE SA would work fine as you explained. So, I assume that all the child SAs from the old IKE SA are transfered to the new IKE SA when the negotiation is complete. I would like to ask another question: After the new IKE SA inherits all the child SAs from the old SA, how are the message IDs assigned to those child SAs handled? Should the original message IDs continue to be used or new message IDs from the new IKE SA should be reassigned to those child SAs? If the original message IDs of the old child SAs are retained, the conflict of message ID between two (one of the old child SAs and a newly created IKE message) could occur (may have the same message ID). It may not happen in a real world, but it could happen in theory. This may affect interoperability in the future. Okhee NIST From owner-ipsec@lists.tislabs.com Thu Aug 15 07:42: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 g7FEgiw01679; Thu, 15 Aug 2002 07:42:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01873 Thu, 15 Aug 2002 09:29:08 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: Re: IKE-SA Deletion To: ipsec@lists.tislabs.com Cc: "O. Kim" X-Mailer: Lotus Notes Build V60_08092002NP August 09, 2002 Message-ID: Date: Wed, 14 Aug 2002 16:50:32 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_07302002NP|July 30, 2002) at 08/14/2002 04:48:20 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Thank you for the response. > Deletion of the old IKE SA would work fine as you explained. > So, I assume that all the child SAs from the old IKE SA are > transfered to the new IKE SA when the negotiation is complete. > After a new IKE SA is negotiated but before the old one is deleted, I would expect notifications, deletions, and creations of child SAs could occur on either the old or the new. I would not expect anyone to do this on purpose, but as with rollover of an ESP SA, accepting messages on either channel but sending only on the new one provides robustness in the case where network delays cause out of order delivery. > > I would like to ask another question: > > After the new IKE SA inherits all the child SAs from the old SA, > how are the message IDs assigned to those child SAs handled? > Should the original message IDs continue to be used or > new message IDs from the new IKE SA should be reassigned to > those child SAs? > The message IDs are sequence numbers associated with the IKE SA, and the number is reset to zero when a new IKE SA is negotiated. References to child SAs in IKE messages are always by child SA SPI. These would not change when the IKE SA is replaced. > If the original message IDs of the old child SAs are retained, > the conflict of message ID between two (one of the old child SAs and > a newly created IKE message) could occur (may have the same message ID). > It may not happen in a real world, but it could happen in theory. > This may affect interoperability in the future. The child SAs also have message IDs/sequence numbers whose processing is specified in ESP and AH. Those would not be affected by the IKE SA rekeying. A new IKE SA with new keys will repeat the message IDs of the old IKE SA, but there is no ambiguity because those numbers are only unique within an SA. --Charlie Kaufman This footnote confirms that either (1) this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses, (2) this email message was sent by a virus that appends this footnote, or (3) (most likely) the sender of this message is trying to raise awareness of how foolish it would be to place any confidence in footnotes like this. From owner-ipsec@lists.tislabs.com Thu Aug 15 07: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 g7FEgrw01698; Thu, 15 Aug 2002 07:42:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01856 Thu, 15 Aug 2002 09:27:08 -0400 (EDT) Reply-To: From: "Joseph D. Harwood" To: "IPsec" Subject: Reference Packets Date: Tue, 13 Aug 2002 17:21:05 -0700 Organization: Vesta Corporation Message-ID: <001401c24328$7b0a7170$beb9fea9@Yellowstone> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C242ED.CEAB9970" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C242ED.CEAB9970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We've generated a number of reference packets that contain valid permutations of: * Protocol (ESP, AH) * Mode (Tunnel, Transport) * Encryption Algorithm (NULL, DES-CBC, 3DES-CBC, AES128-CBC) * Authentication Algorithm (NULL, HMAC-MD5-96, HMAC-SHA-1-96) * IP Header Options * End Of Options * NOP * Security * Extended Security * Commercial Security * Router Alert * SDMD * Loose Source Route * Strict Source Route * Time Stamp * Record Route * Trace Route They can be downloaded from: http://www.vesta-corp.com/VestaRefPktParse_1_00.zip Everything needed to use them (pre- and post-processed packets, crypto keys, etc.) are in the zip file. Please contact me directly for questions, comments, etc. Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com ------=_NextPart_000_0015_01C242ED.CEAB9970 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We’ve generated a number of reference packets = that contain valid permutations of:

 

  • Protocol (ESP, AH)
  • Mode (Tunnel, Transport) =
  • Encryption Algorithm (NULL, DES-CBC, = 3DES-CBC, AES128-CBC)
  • Authentication Algorithm (NULL, = HMAC-MD5-96, HMAC-SHA-1-96)
  • IP Header Options
    • End Of Options
    • NOP
    • Security
    • Extended Security
    • Commercial Security
    • Router Alert
    • SDMD
    • Loose Source Route
    • Strict Source Route
    • Time Stamp
    • Record Route
    • Trace Route

 

They can be downloaded from:

 

http://www.vesta-corp.com/VestaRefPktParse_1_00.zip

 

Everything needed to use them (pre- and = post-processed packets, crypto keys, etc.) are in the zip file.  Please contact me directly for questions, comments, etc.

 

 

Best Regards,

Joseph D. Harwood

(408) 838-9434

jharwood@vesta-corp.com

www.vesta-corp.com

 

 

------=_NextPart_000_0015_01C242ED.CEAB9970-- From owner-ipsec@lists.tislabs.com Fri Aug 16 10:17: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 g7GHHZw29507; Fri, 16 Aug 2002 10:17:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04715 Fri, 16 Aug 2002 12:15:36 -0400 (EDT) Message-ID: <20020816162937.59021.qmail@web11508.mail.yahoo.com> Date: Fri, 16 Aug 2002 09:29:37 -0700 (PDT) From: Feng Ye Subject: IPSec NAT pass-through: how to do it? To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I am working on an access box which has NAT, and now we need to do IPSec pass through. We need to support multiple clients behind the box. The scenario is the user uses PC connect to the box and then to the company gateway. I read the UDP encapsulation draft, but I don't know it's the IPSec endpoints (PC, company security gateway) responsibility, or the NAT box's responsibility to implement the draft? Besides, how do I know if the company gateway has this feature (Is this draft widely used)? >From an earlier post, "Clarification of potential NAT multiple client solutions" by Mr. Brian Swander, seems there're other ways to do it. RFC draft (IPsec-nat compatibility reqts) also mentioned that there're ways like looking at cookie/SPI, but they has limitations. I don't know which way is better, UDP encap, or the hacker-like way? Besides, if SSH/Microsoft claims patent, how other vendors do this (like netopia, linksys, etc.)? Can somebody provide more detailed information or point me to somewhere? Besides, if somebody can provide consulting service please let me know. Since I am newbie to IPSec, any info is very appreciated! Thanks a lot! Feng __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From owner-ipsec@lists.tislabs.com Fri Aug 16 13:44: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 g7GKijw11084; Fri, 16 Aug 2002 13:44:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05122 Fri, 16 Aug 2002 15:41:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Fri, 16 Aug 2002 14:23:28 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: a lengthy analysis of counter mode and ESP Content-Type: multipart/alternative; boundary="============_-1182600273==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1182600273==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" We have been discussing how to make use of AES in counter mode with ESP. Several folks have told me that the discussion is not generally understandable, because of the many subtle issues involved and because when the discussion moved to the general IPsec list, from the design team list, we failed to do an adequate job of establishing context. So, this very lengthy message is an attempt to provide background and a more thorough discussion of the various technical issues associated with this complex topic. Hopefully, the WG as a whole will better understand the issues and be better positioned to make choices as a result of this analysis. Steve ---------- What is Counter Mode? To begin, we need to understand what counter mode (CM) is, at least relative to the process of encrypting packets. CM is not new (I believe it dates from about the mid 80's), although it is newer than the other modes commonly defined and used for block ciphers (which go back to the late 70's and very early 80's). To the best of my knowledge, CM was first used in a security protocol standard by the ATM Forum, in the early 90's, when they adopted it for use with DES. Note that CM can be used with any block cipher. It is generic, not unique to AES, although the size of the "counter" is a function of the block size and thus is somewhat a function of the specific block cipher employed. In CM a sequence of values is generated based on an algorithm (the choice of algorithm is one focus of our discussion), and then encrypted with a key using the basic block (sometimes referred to as electronic code book, or ECB) mode of the cipher. The output from this encryption process usually is referred to as the "key stream." The underlying block cipher is being used to generate a pseudorandom key stream, which is XORed with the plaintext to produce ciphertext. Decryption involves encrypting the same sequence of inputs to produce the same key stream, which is then XORed with the received ciphertext, to recover the transmitted plaintext. By the way, CM is not the only block cipher mode that operates this way. Output feedback mode (OFB) does the same thing, from a black box perspective, i.e., it acts as a pseudorandom number generator (PRNG) to produce key stream for XORing with data, to effect encryption and decryption. In both modes, the keystream is completely independent of the data being encrypted, an important feature that can significantly improve performance in some contexts. The primary reason for considering CM vs. OFB, from an engineering perspective, is the additional performance enhancing opportunities provided by CM, as described later. An essential requirement for CM (and OFB) is that the key stream generated using a specific key not be reused. Stripping off the key stream is easy for a wiretapper (just XORing), if he knows that reuse has occurred and has access to ciphertext that was encrypted under the reused keystream. (It's especially easy if the attacker knows which pairs of ciphertext outputs reflect the reuse.) Remember, that the keystream is just the result of encrypting a sequence of inputs provided to CM, one block at a time. Block ciphers are 1-to-1 and onto mappings. Thus, so long as the sequence of inputs is unique, under a selected key, the sequence of outputs will be unique as well. In the IPsec context, this translates into a requirement to generate unique input value sequences for each SA, since each SA uses a unique key. (As Scott pointed out, it is important to note in the CM spec that the key management procedure ensure uniqueness for each SA, including the common case of the two SAs that make up a full-duplex connection, since the adverse effects are so severe under CM.) Using CM with Packets (and cells) For use in a packet-oriented environment like IP, each input to the block cipher algorithm can be divided into two parts: a per-packet part and an intra-packet part. (It may be convenient, though not necessary, to think of the per-packet part as a set of high order bits for the input, and the intra-packet part as the low order bits.) The per-packet part of the input needs to be unique for each packet, much the same way as we use an IV for CBC or CFB mode. The intra-packet part of the input is used to generate keystream for the packet, a block at a time, for as many blocks as are needed to encrypt the packet. So long as the per-packet part of the input is unique for each packet, the intra-packet input can repeat, from one packet to the next (but not within a packet). This is OK because keystream uniqueness is guaranteed so long as the whole input to the block cipher is unique; even if two inputs differ by only one bit, that is enough to guarantee that the outputs (keystream in this case) will be distinct. For example, the intra-packet part of the input could start at 0 and count up by 1 for each block in a packet, until enough keystream is generated to encrypt the packet. This means that the intra-packet part of the input would repeat for each packet, but so long as the inter-packet input was unique, the keystream generated for each packet will be unique and thus not pose a security problem. For a receiver to decrypt a received packet, it must generate the same keystream as the one that the transmitter used to encrypt the packet. Thus the receiver must know the key being used, and it must be able to generate the same sequence of inputs for the block cipher. There are many ways to make this happen, depending on the context. When the ATM Forum selected CM for encrypting virtual circuits, it adopted a design that assumes that, most of the time, all cells on a VC are delivered in order, without loss. This means that if the transmitter and receiver know the starting value for the input to CM, and know the algorithm used to generate the sequence of inputs (and of course, both use the same key), each can generate the same input sequence to CM, and thus generate the same keystream, without transmitting any additional data. Moreover, in the ATM context, each cell is a fixed size (48 bytes plus header), so the amount of keystream needed to encrypt each cell is constant. This makes it especially easy for the transmitter and receiver to generate keystream for each cell in a synchronous fashion. ATM cells have no place to carry any data for synchronizing the receiver's crypto to the transmitter, but if one assumes perfect, ordered delivery, this is not a problem for CM. One might assume from the ATM example that CM was chosen because it requires no IV to be carried with each cell. But there are many other ways to encrypt cells or packets without carrying an IV, so long as the communication path generally delivers traffic in order and without loss. For example, some X.25 encryption devices developed in the 80's used CBC mode, and did not carry a per-packet IV. Each end transmitted an IV to the other when a call was established and ran CBC mode continuously on the data portion of each packet in the call. Thus CM is not uniquely attractive because of an ability to operate without transmission of explicit, per-packet crypto synch data. If packets can arrive out of order, then generally there is a need to carry data for per-packet crypto synch, or to have some other way for a receiver to know what keystream to create (for a mode like CM). At this point it is worth noting that the CM design adopted by the ATM Forum is not primarily based on a counter, per se. Rather it uses a linear feedback shift register (LFSR) to generate sequences of up to 2^21 inputs to the block cipher (enough for over 2^19 cells when using DES or 3DES). It also uses a counter as part of the input, to be able to "jump" forward in the input space, to facilitate resynchronization. I view this latter feature as a sort of "fix" for the fact that ATM VCs are not perfect after all. (Later we'll discuss why input generation using other than simple counters may be advantageous in some contexts.) The ATM use of CM is illustrative in that it represents a design for a specific network context. In the case of IP, we have a different context and thus a different set of requirements that influence the design. Specifically, in the IP context, we cannot assume ordered delivery of packets, nor can we assume no packet loss will occur. This implies that each packet must carry data to allow the receiver to synchronize the CM input, to generate the correct keystream for decrypting received packets. If we assume that the input consists of two parts, a per-packet part and an intra-packet part, it is obvious that we do not need to transmit the intra-packet part with each packet, so long as there is agreement on the algorithm used to generate the sequence of intra-packet values. In principle, one could negotiate the intra-packet sequence generation algorithm for each SA, and performance advantages could accrue from adopting that approach. For IPsec, I suggest that we not go all out for increased performance at the cost of increased complexity. If one chose to allow negotiation of per-SA, intra-packet sequence generation algorithms, the resulting complexity would be imposed on all implementations, because of the need to support a well-defined set of these algorithms at both transmitter and receiver. Thus I suggest that we stick with the simpler approach of defining exactly one method for generating the intra-packet input sequences, to ensure interoperability with minimal complexity. Given the above assumption about a pre-defined, standard algorithm for generating sequences for the intra-packet part of the CM input, we need to carry only the per-packet part of the CM input in each packet, much as we carry an IV with each packet in CBC mode. Note that since we must carry this value in each packet. The transmitter and receiver need not agree on how the value is generated. All we require is that the algorithm used by the transmitter generate a unique sequence of values under a single key, and that this sequence supports the maximum number of packets that we can send on an SA (2^32 or 2^64, depending on whether the ESN option is employed). The receiver need not be aware of the algorithm used by the transmitter; it is a local matter for the transmitter to generate the per-packet values and to ensure that they are unique. If the transmitter makes an error and duplicates a per-packet CM input value, the damage is done as soon as the packet with the duplicate counter input is sent. Even if a receiver could detect that a duplicate per-packet value had been used, e.g., because the receiver knew what algorithm the transmitter used to generate these values, it is not clear what the receiver would do. IPsec has adopted a design philosophy of not having receivers respond with error messages to what appear to be problems in received packets. (This is part of the design philosophy to avoid creating DoS opportunities.) Also, there are many ways in which such duplicates might escape detection by a receiver. For example, a transmitter might send each packet twice, once encrypted using the previous per-packet counter input, and once with a new per-packet input. This would result in duplicate keystream for every packet, a passive wiretapper's dream come true! Every packet would arrive and be decrypted properly by the receiver. Depending on how the per-packet counter input was managed, this might go completely unnoticed by the IPsec receiver, or the receiver might see the replicated packets as duplicated, and just discard them as part of the usual anti-replay mechanism. Failure of this sort, might well go undetected for some time. Note that, unlike the IV's used with CBC or CFB modes, there is not a requirement that the per-packet value used for CM be pseudorandom. An obvious candidate for such a value is a counter that increments by 1 for each newly transmitted packet. Since the preceding analysis indicated that generation of the per-packet values can be a purely local matter for the transmitter, there is not a requirement to mandate a standard mechanism for generating these values, although the standard could suggest some good ways of doing this. Also, if the implementation undergoes security evaluation, as described later, that evaluation will review the means used by the transmitter to ensure CM input uniqueness, irrespective of anything we state in an IETF standard. CM and Performance Performance considerations are the primary motivations for using a counter mode with a block cipher such as AES. The primary reason for the performance advantage of CM relative to other encryption modes derives from the fact that it has no feedback loop, e.g., in contrast to CFB, CBC or even OFB modes. In a mode that has a feedback loop, one must complete encryption of a block of data before using the result as an input to encrypting the next block of data. Even when a crypto mode does not directly encrypt data, e.g., OFB mode, the presence of a feedback loop in the mode requires that a block of data be processed all the way through the algorithm before the next block can be processed. Modern block ciphers involve multiple "rounds" of computation. In DES there were 16 rounds; in 3DES 48 rounds, and for AES (used with 128-bit keys) there are 12 rounds. As one tries to maximize performance in hardware or software, it is common to "unwind" the loop implied by the round structure. In hardware, this creates an opportunity to pipeline the encryption process. For example, in AES, after a 16-byte block of data has been input to a chip for processing, one round later another 16-byte block could be input, if there is no dependence on the encryption of the previous input. Thus, even though the first block is still being processed and will not be output until 11 more rounds have been completed, one can begin processing the next input block, if the mode permits. Thus an encryption mode that allows easy use of pipelining for encryption (and decryption) permits hardware implementations to speed up processing by a factor that reflects the number of rounds used by the basic block cipher, e.g., by a factor of 12 for AES. A feedback mode like CBC or CFB does not permit one to easily take advantage of pipelining, at least not for encrypting a single packet. In a straightforward implementation, one would have to wait until all the rounds were completed for encrypting the first block of input, before starting to encrypt the second block of data from the same packet, because the encrypted output from the first block is combined with the next input, to counter some forms of attacks. There are ways to try to overcome this limitation, e.g., by viewing a packet not as a single series of blocks of data, but rather viewing it as several series of blocks, interleaved in a fashion to account for the number of rounds in the algorithm. Techniques of this sort make use of multiple algorithm "cores," each a complete implementation of the block cipher, and thus makes use of parallelism as well as pipelining. Modern, high speed crypto chips often contain several algorithm cores, so this is not an unrealistic notion. For example, in the ATM case, since each cell contains a 48-byte payload, one could view the payload as composed of two sequences, each consisting of 3, 8-byte blocks, interleaved. One could use two algorithms implementations in parallel, to process each sequence, thus doubling the effective throughput. Or, the same payload could be viewed as 4 interleaved sequences of 2 blocks each, for even greater parallelism and improved throughput. However, this combination of pipelining and parallelism can get very complicated in a hurry. More importantly from a protocol standards and interoperability perspective, a receiver needs to know how the transmitter chose to "slice" the packet, in order to perform the decryption correctly. That is because the way the interleaving is performed must be duplicated by the receiver, in order to effect decryption. Interleaving is not a transparent way to increase performance; a receiver must know exactly what interleaving strategy was used by every transmitter from which it receives packets. This makes it less desirable in an open system environment, where we strive to remove barriers to interoperability. As a result complicated ways of trying to speed up encryption through interleaving of data while using feedback modes are not usually employed in standard protocols. (IPsec is striving to reduce the complexity mandated for all implementations, as evidenced in the new version of IKE, and the complexity of interleaving would be counter to this effort.) Thus it is common for a chip with multiple cores to be used to encrypt multiple packets in parallel, rather than trying to encrypt one packet in parallel. Note that if multiple packets from the same SA are encrypted in parallel, e.g., using multiple algorithm cores within a crypto chip, this internal parallelism can cause system-level problems. Consider the case where several short packets arrive for transmission on an SA after encryption has begun on a large packet. Encrypting multiple packets for the same SA in parallel could cause the short packets to be encrypted, transmitted, received and decrypted before the large packet was received at the destination IPsec implementation. IPsec can tolerate this sort of self-imposed reordering for small numbers of packets, nominally 64 per SA under the current recommendations. One can imagine cases where an IPsec receiver might start discarding large packets that arrive too late on an SA, because of using packet parallelism on a per-SA basis to improve performance. Also, TCP performance suffers when packets arrive out of order, so there is the potential that an attempt to improve IPsec performance, through internal parallelism on a per-SA basis, could ultimately degrade performance! Thus developers must exercise care in designing high speed IPsec devices, and they must understand how crypto chips work to achieve high speeds. In CM, taking advantage of pipelining and parallelism for an individual packet is much easier because of the lack of feedback. One can load the per-packet value into a core, and begin generating the keystream for a series of blocks. After the first round has completed, a new input can be loaded into the same core, to begin generating another part of the keystream. In the simplest case, one could pipeline 12 blocks worth of keystream generation for a single packet, using a single core, taking advantage of the 12 round depth of AES. The core could generate the sequence of intra-packet inputs, using whatever algorithm is defined for that purpose. If we are to make maximum use of a core, at some point it will be necessary to load a new input into a core for a different packet, while the core is still generating keystream for another packet, maybe even for a packet for another SA. Otherwise the core will be idle while we wait for up to 11 rounds (for AES) for the keystream for the previous packet to exit. This suggests that a crypto chip has to maintain some state for each core it contains, to remember which keystream outputs go with which packets on which SAs, in order to be able to get the most out of each core. So long as that state is completely local to the chip, this is feasible. Since crypto chips often contain multiple cores, it also is possible to improve throughput for a single packet by using parallelism within the chip. One might begin generating keystream in two or more cores, in parallel, for the same packet. This is not too hard for CM, unlike CBC or CFB mode, because we know what inputs to load into each core to generate keystream for different blocks within a packet. Also, the way we choose to do this at a transmitter will be invisible to a receiver, so long as we follow the same algorithm for generating the intra-packet input sequences. Thus transmitters and receivers can employ different numbers of cores, even different numbers of chips, to generate keystream in a deterministic fashion and still have the process work properly, with no additional coordination. This is an important feature: any approach we adopt for using CM in ESP should allow a transmitter maximum flexibility in optimizing performance, while ensuring that receivers need not be aware of the optimizations employed by the transmitter. For example, if a packet to be encrypted is 64 bytes long (more properly, 49-64 bytes in length), one could assign two crypto cores to the task of generating two blocks of keystream each, or assign four cores the task of assigning one block each. In the former case the whole packet can be encrypted in the time it takes for two rounds of AES, in the latter case, in the time for one round of AES. All that is required to make this work is to load the same inter-packet value into each core, and then to direct each core to use the appropriate offset into the packet for generating the right portion of the keystream. This use of both pipelining and parallelism makes CM very attractive as we try to create IPsec implementations that can operate at higher and higher speeds. At the same time that we try to preserve maximum flexibility for hardware implementations re performance, we don't want to adopt a scheme that will impose burdens on software implementations that may be peers. I believe this should be an important principle in our decisions. Finally, note that this sort of pipelining does not reduce the delay associated with multi-round encryption. It will still take 12 rounds to generate the keystream for a packet using AES with 128-bit keys. Parallelism helps with delay, and the ability to pre-compute keystream also can reduce delay. However, pre-computation of keystream in IPsec may be feasible only on some contexts, e.g., when the number of SAs is small and thus the burden of storing pre-computed keystream is not too great. CM and Overhead With this background, we can examine the issue that has generated considerable debate recently, namely how to manage the per-packet inputs for CM. There is agreement that the intra-packet input should just be a simple counter. To accommodate the largest possible jumbogram that IPv6 can represent, a 28-bit value will suffice, and we can represent it in a 32-bit field, as that is convenient for both hardware and software implementations. The disagreement has centered around the form that the per-packet input to CM should take. As noted earlier, this value need not be pseudorandom, unlike the recommendation for CBC and CFB modes. Some concerns have been expressed about using a simple counter here, because this means that subsequent inputs to CM will have a small Hamming distance. Conceivably, this might facilitate some forms of differential cryptanalysis, but AES is generally believed to be sufficiently strong so that this concern has generally been dismissed. So, there is agreement that a per-packet counter is sufficient. If one adopts a very conservative model of encryption security, then at most 2^64 blocks should be encrypted under a single key, which says that no more than 64 bits are needed to identify each packet in an SA. This is exactly the same size as the ESP extended sequence number, so that value is an obvious candidate for use as the per-packet CM input. It has the advantage that it is already carried in the ESP header for each packet, and thus its use does not add any overhead to the ESP packet structure for crypto synch purposes. The extent of the savings is subject to interpretation. CM has the property that one need not pad a packet to the block size in order to encrypt/decrypt it. Rather, one merely XORs as many bits as needed with the last block of a packet to encrypt/decrypt it. In the IPsec context we require that the ciphertext portion of a packet end on a 4-byte boundary, so this becomes the determining factor for padding in the context of CM encryption. So, already CM has an advantage over CBC which requires padding to a block boundary. Today, using DES or 3DES, this CBC padding adds 4 bytes to every packet, on average. CBC mode for AES would add 8 bytes of overhead. If we use the ESP sequence number as the per-packet input to CM, we can gain another 8-byte savings relative to DES/3DES CBC. There are several ways of looking at the overhead figures. Today we tolerate an average of 12 bytes of per-packet crypto overhead, using DES or 3DES CBC, an 8-byte IV plus the average 4-byte padding overhead. Moving to CM will shave this overhead by an average of 4 bytes (by removing the padding), a 1/3 savings, even if we carry an explicit 8-byte per-packet CM input. This analysis is accurate, but simplistic, as it looks only at the overhead due to the crypto mode. It ignores the overhead imposed by ESP. The ESP header is 8-bytes long (4-byte SPI and 4-byte explicit sequence number). Because of the 4-byte alignment requirement for the end of the ciphertext, and because the last two bytes of the ciphertext are part of the ESP trailer, an average of 4 bytes of overhead is added there as well. Then the ICV is attached, in the common (and recommended case) where integrity is employed. (Because CM provides NO protection of any form with regard to integrity, an ICV is critical when this mode is used.) The default ICV algorithms add an additional 12 bytes to the end of the packet. So, in aggregate, ESP typically adds 24 bytes to a packet, independent of the use of an explicit IV. In that context, an explicit 8-byte IV represents 1/4 of the total overhead added by ESP (24 bytes of pure ESP overhead, plus an 8-byte IV = 32 bytes.) If there is no compression of an (outer) IPv4 header, and if there are no options, which is typical, that header is 20 bytes long. A TCP header, inside the ESP payload, is 20 bytes (again, assuming no options). A UDP header is 8 bytes. (IPsec does not accommodate compression of transport layer headers; they are used for SA selection and the transmitter and for SA checking at the receiver, so any compression of these headers would become an integral part of security critical IPsec processing, not a generally desirable outcome.) The protocol overhead for a packet is 20+24 (or 8 for UDP) = 44 (or 28 for UDP) bytes, independent of any application data and prior to applying ESP. Other than VoIP, for which we have heard varying estimates of application data size, the typical minimum size packet is a TCP ACK, which is 44 bytes. The ESP overhead, at 24 bytes, makes for a minimum encrypted packet size of 68 bytes (sans IV). In that common context, the 8 added bytes for an explicit IV represents an 11.7% increase in packet size. Typical packet sizes tend to be much larger, with an attendant decrease in the percentage overhead attributable to ESP and to an explicit IV. In practice it seems that most IPsec traffic is carried in tunnel mode, which adds another 20-byte inner IP header, which would bring the IV overhead down to about 9%. (The use of tunnel mode is required for the common case of remote user access, and for inter-site VPNs. It also seems to be used as a default in many implementations, where transport mode would suffice.) I leave it to others to provide analogous estimates for the VoIP case, with appropriate assumptions about what compression is applied where, and under what circumstances, and whether this requires use of any compression algorithms that must be licensed. But, it seems clear that in a very large number of common IPsec uses, the overhead associated with carriage of an explicit IV is fairly small. None of this analysis is intended to suggest that we should be cavalier about the overhead associated with IPsec. When I developed the extended sequence number (ESN) option for AH and ESP, I chose to not carry an extra 4 bytes of sequence number for several reasons. There is an obvious desire to maintain backward compatibility for the on the wire format, and to minimize overhead. Perhaps the most important reason for making the added 4 bytes for the ESN be implicit rather than explicit, is to preserve the 8-btye alignment for the beginning of payload, consistent with IPv6 requirements. But the overhead imposed by these 4 bytes would not, by itself, justify the added complexity that results from making them implicit. In the same vein, I suggest that we not introduce undue complexity to IPsec in an effort to save 8 more bytes per packet, since it represents a fairly small overhead in the vast majority of circumstances. CM & System Security When we consider the use of an explicit vs. an implicit IV for CM, we also need to examine system security issues. Some of these issues are rather subtle and thus require a detailed explanation, much like the description of CM and how it can be used to achieve higher performance. Management of the ESP sequence number is well defined by RFC 2402 & 2406, and management of the ESN is defined in 2402/2406bis. A separate counter must be maintained for each SA, and recall that an SA is a unidirectional connection. The sequence number begins at 0; the first transmitted packet carrying a value of 1, and the value is not allowed to cycle for an SA. Thus a new SA must be created prior to transmitting a packet with the sequence number value of 2^32 (or with the implied value of 2^64 in the case of the ESN option.) The purpose of the sequence number is to allow a receiver to detect and reject replayed packets, e.g., as a countermeasure to DoS attacks. As currently defined and used, e.g., with CBC mode, it has no implications for the security of the cryptography employed with IPsec. Thus a failure by a transmitter to properly manage the sequence number will not result in a violation of the confidentiality, integrity, or authentication guarantees associated with use of ESP. In this sense, the anti-replay feature of ESP is a secondary security function. As a result of this well-defined and limited security use for the sequence number, its management is outside of the scope of the FIPS 140-1/2 crypto module evaluation criteria. These criteria focus on security functionality and assurance directly related to the management of crypto keys, on the correct implementation and operation of crypto algorithms, and on related aspects of crypto module security. These evaluation criteria does NOT address security issues associated with a protocol like IPsec, even though a number of IPsec implementations make use of crypto modules that have been evaluated under FIPS 140-1/2. It is appropriate that these IPsec products cite FIPS 140 evaluation ratings in product brochures even though this evaluation does not address the other security features of IPsec. (The evaluation criteria applies to both hardware and software modules and thus is widely applicable.) Keep this in mind as we discuss implementation options for management of ESP sequence numbers. Some crypto chips that have been designed expressly for IPsec manage the ESP sequence number on chip. This is a good security design approach which makes it unlikely that the sequence number will be mismanaged, e.g., that the same sequence number will be assigned to multiple packets. However, it is not always possible to manage the sequence number for an SA on a chip. Vendors developing IPsec products have sometimes found it necessary to use multiple chips, perhaps spread over more than one (printed circuit) board to provide crypto support for traffic from one SA. An obvious context in which this has arisen is in PPVPN products, where many subscriber data streams come together in a product and the goal is to multiplex these data streams over a pool of crypto chips. The motivations here are the same one that cause ISPs to aggregate traffic at a POP using a hierarchy of routers and switches. In such contexts it is uneconomical to devote a crypto chip/module to each subscriber. Sharing of a pool of crypto resources allows traffic for any SA to be assigned to any available crypto chip. This requires that the keys for each SA be available to each crypto chip. Because keys are constant for the life of an SA, this is easy accomplished by replicating the key material on each chip. Management of sequence numbers poses a problem in this context if one tries to manage them on the crypto chips. This is because this per-SA data changes every time a packet is transmitted on an SA and it is generally impractical to update the data and make it available to all the crypto chips in a timely fashion. Although the PPVPN context is the one that first brought this issue to our attention, it is anticipated that there may be other contexts in which traffic for an SA may be directed to different chips at different times. It is a generic design strategy for scaling a system to accommodate higher traffic volumes without dedicating crypto chips to each possible traffic source. When this issue was raised on the IPsec mailing list over a year ago, the advice provided by the WG to vendors who encountered this problem was to move management of the sequence numbers out of the crypto chips. For each SA there is a point in the system where the traffic is mapped to the SA and at that point one can assign the sequence number to what will become an ESP packet, without any synchronization problems. This approach does reduce the assurance with which sequence numbers are managed, relative to on-chip management, but because the security function offered by sequence numbers is quite limited, this is not viewed as a problem. If we make use of the ESP sequence number as the per-packet input to CM, the situation changes. In this case, the sequence number is a critical security parameter for the encryption algorithm, as noted earlier. This is because encrypting two packets under the same key with the same per-packet CM input results in duplicate keystream and a serious compromise of confidentiality. Moreover, because the sequence number is clearly visible in the packet, a wiretapper would know precisely when this occurred, if it happened. If the ESP sequence number is used as the per-packet input in CM, then management of the sequence number falls within the scope of a FIPS 140-1/2 evaluation. This means that the security boundary for evaluation of a product must encompass management of the sequence number. If sequence numbers are managed on crypto chips, this is not a problem. But, if a product wants to manage sequence numbers off chip, e.g., to better support scaling in the ways described above, then the security evaluation boundary will have to encompass a much larger portion of the IPsec product. In many instances, this will likely limit the level of assurance at which a product can be evaluated. In pragmatic terms, the security of the encryption process will almost certainly be lower, because the per-packet CM input is now managed in a less secure fashion. Some products might even forgo FIPS evaluation entirely, because if the security evaluation boundary grow to encompass most of the product software, any change in that software voids the evaluation! This also creates a potentially very odd situation: if an IPsec product supports both CM and CBC modes, the security of the product might vary depending on which mode was used. This could arise if the security critical inputs to the encryption mode were managed in different places. For example, for CBC mode on-chip IV generation could be very secure, but off-chip sequence number management would result in lower assurance for CM, if the sequence number were used as the per-packet input. This discussion of security evaluation boundaries is not based on arbitrary evaluation criteria. It has a very pragmatic basis. Experience has shown that many, if not most, of the security vulnerabilities that arise in fielded products are a result of implementation errors. Increasing the size of the security boundary either reduces the likely level of assurance that is achieved, or increases the costs associated with engineering the product (for a fixed level of assurance). In general, architectural approaches that make it easy to do a good job of ensuring keystream uniqueness, make it more likely that a product will not have vulnerabilities due to keystream generation failures. To put this issue in perspective, the current ID warns implementers against generating keystream for more than 2^64 blocks (not packets), even though we do not know of any specific vulnerabilities that could be exploited if this limit is exceeded. Yet we understand precisely what attacks could result if keystream is reused. Thus it makes sense to adopt approaches to keystream management that do not make it harder to do this task in a very secure fashion. This analysis argues for adopting an approach to generating the per-packet CM input in a fashion that can be uniformly secure, irrespective of whether the ESP sequence number is managed on chip or off. For performance reasons, one would like an approach that allows multiple chips to generate keystream for packets transmitted on the same SA, while ensuring no keystream reuse and without having to synchronize values (across chips) that change on a per-packet basis. If one carries an explicit, per-packet IV, these goals can be achieved. There are several ways one can generate the per-packet IV in a secure fashion across multiple chips. For example, one can assign a distinct, small ID number to each chip (or each core on a chip), and include that number as part of a 64-bit IV. This ensures that each chip can generate a unique IV sequence in a purely local fashion, using the per-chip (or per-core) ID as part of the IV. There is no need to specify in a standard what portion of the IV is devoted to a per-chip ID, since to a receiver the whole IV is opaque. This means that an IPsec implementation that has just one chip can use the whole IV as a counter or an LFSR, while a multi-chip implementation can assign as many bits as are needed to allow for maximum, per-SA parallelism. This is precisely the sort of opportunity for local optimization, with no adverse implications for receiver implementation choices, that one should strive for in a standard. Counters vs. Linear Feedback Shift Registers (LFSRs) Finally, there has been discussion of the merits of using counters vs. LFSR to generate CM input sequences. LFSRs were used in the ATM Forum standard for CM encryption. They exhibit advantages, relative to adders, for generating a sequence of inputs in very high performance hardware. The time required by an LFSR to generate the next value in the sequence is constant, very small, and the hardware required is also minimal. In contrast, if one generates a sequence of inputs using a counter, the counter must allow for time to propagate carries, and the counter is bigger than an LFSR, for comparable input sizes. (One can diminish the delay attributable to carry propagation by devoting more gates to the adder, but it is not likely to be faster than an LFSR generating the same size sequence, and it will certainly be bigger in gate count.) Note that these arguments do not apply to software implementations, especially ones making use of general purpose processors. In those implementations, an LFSR would generally be slower than use of a counter, given the availability of a 32 or 64-bit adder in the CPU. Software implementations are not capable of very high performance, and so there is no motivation to optimize for use of software with an LFSR. But it is important to not burden software implementations that communicate with very high performance hardware. In the context of ESP, we argued that it is important to use a well-defined, standard way to generate the intra-packet input sequences. We also argued that it is preferable to have just one way to do this. Using an LFSR here would yield performance benefits, but these benefits may not be great, since the intra-packet sequences need be only 28-bit values. Also, we want to preserve flexibility for transmitters with regard to keystream generation. It does not seem easy to standardize a means for using LFSRs for intra-packet keystream generation. This leads to the suggestion to use a (28-bit) counter for this part of the CM input. However, generation of per-packet (vs. intra-packet) inputs to CM does not have to be standardized, as explained in earlier analysis. We also have seen how some implementations might need to generate a new per-packet input as fast as an AES implementation can perform one round, the same speed at which the intra-packet sequences need to be generated. Thus it is attractive to allow for use of LFSRs to generate per-packet inputs, i.e., IVs. Note too that because the per-packet values are bigger (64-bits vs. 28-bits), the performance and gate count advantages for an LFSR vs. a counter can be greater, at least in principle, for hardware. By allowing an implementer the freedom to choose how to generate these IVs, no constraints (other than uniqueness) are imposed, and there is no adverse effect on receivers, to whom these values are opaque. Thus a software implementation that receives packets from a hardware implementation using an LFSR for IVs is not affected by the transmitters implementation choice. The same is true in the other direction, i.e., use of a counter for IV generation does not affect a receiver. The Bottom Line The preceding, lengthy analysis has indicated why it is preferable to carry an explicit IV for per-packet synchronization for CM, in a range of contexts. Using explicit IVs allows product designers flexibility for improving encryption performance, while maintaining or improving security, relative to reusing the ESP sequence number as an IV. Reusing the ESP sequence number in this fashion precludes some designs that increase performance, as illustrated in the analysis. In some contexts, e.g., PPVPN designs, reuse of the sequence number will either make FIPS 140 evaluation harder and more expensive, or will reduce the security assurance level of products, when this mode is employed. The only downside to this choice is the overhead associated with the IV. This overhead is, on average, less than what most IPsec implementations currently experience with DES/3DES CBC, because CM does not require block size padding. On a percentage basis, the overhead of an explicit IV is typically quite small. We have been told that in the VoIP context even this small overhead is a concern, but we have no detailed analysis of the extent of the overhead relative to overall packets size. We also have been told that these concerns have lead to development of an alternative security protocol SRTP, which is optimized for VoIP. I believe IPsec should not skew its use of CM to better support any one application, even an important one like VoIP, especially given the possibility of using an alternative security protocol. --============_-1182600273==_ma============ Content-Type: text/html; charset="us-ascii" a lengthy analysis of counter mode and ESP
We have been discussing how to make use of AES in counter mode with ESP.  Several folks have told me that the discussion is not generally understandable, because of the many subtle issues involved and because when the discussion moved to the general IPsec list, from the design team list, we failed to do an adequate job of establishing context. So, this very lengthy message is an attempt to provide background and a more thorough discussion of the various technical issues associated with this complex topic.  Hopefully, the WG as a whole will better understand the issues and be better positioned to make choices as a result of this analysis.

Steve
----------



What is Counter Mode?

To begin, we need to understand what counter mode (CM) is, at least relative to the process of encrypting packets. CM is not new (I believe it dates from about the mid 80's), although it is newer than the other modes commonly defined and used for block ciphers (which go back to the late 70's and very early 80's). To the best of my knowledge, CM was first used in a security protocol standard by the ATM Forum, in the early 90's, when they adopted it for use with DES.

Note that CM can be used with any block cipher. It is generic, not unique to AES, although the size of the "counter" is a function of the block size and thus is somewhat a function of the specific block cipher employed. In CM a sequence of values is generated based on an algorithm (the choice of algorithm is one focus of our discussion), and then encrypted with a key using the basic block (sometimes referred to as electronic code book, or ECB) mode of the cipher. The output from this encryption process usually is  referred to as the "key stream." The underlying block cipher is being used to generate a pseudorandom key stream, which is XORed with the plaintext to produce ciphertext. Decryption involves encrypting the same sequence of inputs to produce the same key stream, which is then XORed with the received ciphertext, to recover the transmitted plaintext.

By the way, CM is not the only block cipher mode that operates this way. Output feedback mode (OFB) does the same thing, from a black box perspective, i.e., it acts as a pseudorandom number generator (PRNG) to produce key stream for XORing with data, to effect encryption and decryption. In both modes, the keystream is completely independent of the data being encrypted, an important feature that can significantly improve performance in some contexts. The primary reason for considering CM vs. OFB, from an engineering perspective, is the additional performance enhancing opportunities provided by CM, as described later.

An essential requirement for CM (and OFB) is that the key stream generated using a specific key not be reused. Stripping off the key stream is easy for a wiretapper (just XORing), if he knows that reuse has occurred and has access to ciphertext that was encrypted under the reused keystream. (It's especially easy if the attacker knows which pairs of ciphertext outputs reflect the reuse.)

Remember, that the keystream is just the result of encrypting a sequence of inputs provided to CM, one block at a time. Block ciphers are 1-to-1 and onto mappings. Thus, so long as the sequence of inputs is unique, under a selected key, the sequence of outputs will be unique as well. In the IPsec context, this translates into a requirement to generate unique input value sequences for each SA, since each SA uses a unique key. (As Scott pointed out, it is important to note in the CM spec that the key management procedure ensure uniqueness for each SA, including the common case of the two SAs that make up a full-duplex connection, since the adverse effects are so severe under CM.)


Using CM with Packets (and cells)

For use in a packet-oriented environment like IP, each input to the block cipher algorithm can be divided into two parts: a per-packet part and an intra-packet part. (It may be convenient, though not necessary, to think of the per-packet part as a set of high order bits for the input, and the intra-packet part as the low order bits.) The per-packet part of the input needs to be unique for each packet, much the same way as we use an IV for CBC or CFB mode. The intra-packet part of the input is used to generate keystream for the packet, a block at a time, for as many blocks as are needed to encrypt the packet. So long as the per-packet part of the input is unique for each packet, the intra-packet input can repeat, from one packet to the next (but not within a packet). This is OK because keystream uniqueness is guaranteed so long as the whole input to the block cipher is unique; even if two inputs differ by only one bit, that is enough to guarantee that the outputs (keystream in this case) will be distinct.

For example, the intra-packet part of the input could start at 0 and count up by 1 for each block in a packet, until enough keystream is generated to encrypt the packet. This means that the intra-packet part of the input would repeat for each packet, but so long as the inter-packet input was unique, the keystream generated for each packet will be unique and thus not pose a security problem.

For a receiver to decrypt a received packet, it must generate the same keystream as the one that the transmitter used to encrypt the packet. Thus the receiver must know the key being used, and it must be able to generate the same sequence of inputs for the block cipher. There are many ways to make this happen, depending on the context.

When the ATM Forum selected CM for encrypting virtual circuits, it adopted a design that assumes that, most of the time, all cells on a VC are delivered in order, without loss. This means that if the transmitter and receiver know the starting value for the input to CM, and know the algorithm used to generate the sequence of inputs (and of course, both use the same key), each can generate the same input sequence to CM, and thus generate the same keystream, without transmitting any additional data. Moreover, in the ATM context, each cell is a fixed size (48 bytes plus header), so the amount of keystream needed to encrypt each cell is constant. This makes it especially easy for the transmitter and receiver to generate keystream for each cell in a synchronous fashion. ATM cells have no place to carry any data for synchronizing the receiver's crypto to the transmitter, but if one assumes perfect, ordered delivery, this is not a problem for CM.

One might assume from the ATM example that CM was chosen because it requires no IV to be carried with each cell. But there are many other ways to encrypt cells or packets without carrying an IV, so long as the communication  path generally delivers traffic in order and without loss. For example, some X.25 encryption devices developed in the 80's used CBC mode, and did not carry a per-packet IV. Each end transmitted an IV to the other when a call was established and ran CBC mode continuously on the data portion of each packet in the call. Thus CM is not uniquely attractive because of an ability to operate without transmission of explicit, per-packet crypto synch data. If packets can arrive out of order, then generally there is a need to carry data for per-packet crypto synch, or to have some other way for a receiver to know what keystream to create (for a mode like CM).

At this point it is worth noting that the CM design adopted by the ATM Forum is not primarily based on a counter, per se. Rather it uses a linear feedback shift register (LFSR) to generate sequences of up to 2^21 inputs to the block cipher (enough for over 2^19 cells when using DES or 3DES). It also uses a counter as part of the input, to be able to "jump" forward in the input space, to facilitate resynchronization. I view this latter feature as a sort of "fix" for the fact that ATM VCs are not perfect after all. (Later we'll discuss why input generation using other than simple counters may be advantageous in some contexts.)

The ATM use of CM is illustrative in that it represents a design for a specific network context. In the case of IP, we have a different context and thus a different set of requirements that influence the design. Specifically, in the IP context, we cannot assume ordered delivery of packets, nor can we assume no packet loss will occur. This implies that each packet must carry data to allow the receiver to synchronize the CM input, to generate the correct keystream for decrypting received packets.

If we assume that the input consists of two parts, a per-packet part and an intra-packet part, it is obvious that we do not need to transmit the intra-packet part with each packet, so long as there is agreement on the algorithm used to generate the sequence of intra-packet values. In principle, one could negotiate the intra-packet sequence generation algorithm for each SA, and performance advantages could accrue from adopting that approach. For IPsec, I suggest that we not go all out for increased performance at the cost of increased complexity. If one chose to allow negotiation of per-SA, intra-packet sequence generation algorithms, the resulting complexity would be imposed on all implementations, because of the need to support a well-defined set of these algorithms at both transmitter and receiver. Thus I suggest that we stick with the simpler approach of defining exactly one method for generating the intra-packet input sequences, to ensure interoperability with minimal complexity.

Given the above assumption about a pre-defined, standard algorithm for generating sequences for the intra-packet part of the CM input, we need to carry only the per-packet part of the CM input in each packet, much as we carry an IV with each packet in CBC mode. Note that since we must carry this value in each packet. The transmitter and receiver need not agree on how the value is generated. All we require is that the algorithm used by the transmitter generate a unique sequence of values under a single key, and that this sequence supports the maximum number of packets that we can send on an SA (2^32 or 2^64, depending on whether the ESN option is employed). The receiver need not be aware of the algorithm used by the transmitter; it is a local matter for the transmitter to generate the per-packet values and to ensure that they are unique.

If the transmitter makes an error and duplicates a per-packet CM input value, the damage is done as soon as the packet with the duplicate counter input is sent. Even if a receiver could detect that a duplicate per-packet value had been used, e.g., because the receiver knew what algorithm the transmitter used to generate these values, it is not clear what the receiver would do. IPsec has adopted a design philosophy of not having receivers respond with error messages to what appear to be problems in received packets. (This is part of the design philosophy to avoid creating DoS opportunities.)  Also, there are many ways in which such duplicates might escape detection by a receiver. For example, a transmitter might send each packet twice, once encrypted using the previous per-packet counter input, and once with a new per-packet input. This would result in duplicate keystream for every packet, a passive wiretapper's dream come true! Every packet would arrive and be decrypted properly by the receiver. Depending on how the per-packet counter input was managed, this might go completely unnoticed by the IPsec receiver, or the receiver might see the replicated packets as duplicated, and just discard them as part of the usual anti-replay mechanism. Failure of this sort, might well go undetected for some time.

Note that, unlike the IV's used with CBC or CFB modes, there is not a requirement that the per-packet value used for CM be pseudorandom. An obvious candidate for such a value is a counter that increments by 1 for each newly transmitted packet. Since the preceding analysis indicated that generation of the per-packet values can be a purely local matter for the transmitter, there is not a requirement to mandate a standard mechanism for generating these values, although the standard could suggest some good ways of doing this. Also, if the implementation undergoes security evaluation, as described later, that evaluation will review the means used by the transmitter to ensure CM input uniqueness, irrespective of anything we state in an IETF standard.


CM and Performance

Performance considerations are the primary motivations for using a counter mode with a block cipher such as AES. The primary reason for the performance advantage of CM relative to other encryption modes derives from the fact that it has no feedback loop, e.g., in contrast to CFB, CBC or even OFB modes. In a mode that has a feedback loop, one must complete encryption of a block of data before using the result as an input to encrypting the next block of data. Even when a crypto mode does not directly encrypt data, e.g., OFB mode, the presence of a feedback loop in the mode requires that a block of data be processed all the way through the algorithm before the next block can be processed.

Modern block ciphers involve multiple "rounds" of computation. In DES there were 16 rounds; in 3DES 48 rounds, and for AES (used with 128-bit keys) there are 12 rounds. As one tries to maximize performance in hardware or software, it is common to "unwind" the loop implied by the round structure. In hardware, this creates an opportunity to pipeline the encryption process. For example, in AES, after a 16-byte block of data has been input to a chip for processing, one round later another 16-byte block could be input, if there is no dependence on the encryption of the previous input. Thus, even though the first block is still being processed and will not be output until 11 more rounds have been completed, one can begin processing the next input block, if the mode permits.
Thus an encryption mode that allows easy use of pipelining for encryption (and decryption) permits hardware implementations to speed up processing by a factor that reflects the number of rounds used by the basic block cipher, e.g., by a factor of 12 for AES.

A feedback mode like CBC or CFB does not permit one to easily take advantage of pipelining, at least not for encrypting a single packet. In a straightforward implementation, one would have to wait until all the rounds were completed for encrypting the first block of input, before starting to encrypt the second block of data from the same packet, because the encrypted output from the first block is combined with the next input, to counter some forms of attacks.

There are ways to try to overcome this limitation, e.g., by viewing a packet not as a single series of blocks of data, but rather viewing it as several series of blocks, interleaved in a fashion to account for the number of rounds in the algorithm.
Techniques of this sort make use of multiple algorithm "cores," each a complete implementation of the block cipher, and thus makes use of parallelism as well as pipelining. Modern, high speed crypto chips often contain several algorithm cores, so this is not an unrealistic notion. For example, in the ATM case, since each cell contains a 48-byte payload, one could view the payload as composed of two sequences, each consisting of 3, 8-byte blocks, interleaved. One could use two algorithms implementations in parallel, to process each sequence, thus doubling the effective throughput. Or, the same payload could be viewed as 4 interleaved sequences of 2 blocks each, for even greater parallelism and improved throughput. However, this combination of pipelining and parallelism can get very complicated in a hurry.

More importantly from a protocol standards and interoperability perspective, a receiver needs to know how the transmitter chose to "slice" the packet, in order to perform the decryption correctly. That is because the way the interleaving is performed must be duplicated by the receiver, in order to effect decryption. Interleaving is not a transparent way to increase performance; a receiver must know exactly what interleaving strategy was used by every transmitter from which it receives packets. This makes it less desirable in an open system environment, where we strive to remove barriers to interoperability. As a result complicated ways of trying to speed up encryption through interleaving of data while using feedback modes are not usually employed in standard protocols. (IPsec is striving to reduce the complexity mandated for all implementations, as evidenced in the new version of IKE, and the complexity of interleaving would be counter to this effort.) Thus it is common for a chip with multiple cores to be used to encrypt multiple packets in parallel, rather than trying to encrypt one packet in parallel.

Note that if multiple packets from the same SA are encrypted in parallel, e.g., using multiple algorithm cores within a crypto chip, this internal parallelism can cause system-level problems.
Consider the case where several short packets arrive for transmission on an SA after encryption has begun on a large packet. Encrypting multiple packets for the same SA in parallel could cause the short packets to be encrypted, transmitted, received and decrypted before the large packet was received at the destination IPsec implementation. IPsec can tolerate this sort of self-imposed reordering for small numbers of packets, nominally 64 per SA under the current recommendations. One can imagine cases where an IPsec receiver might start discarding large packets that arrive too late on an SA, because of using packet parallelism on a per-SA basis to improve performance. Also, TCP performance suffers when packets arrive out of order, so there is the potential that an attempt to improve IPsec performance, through internal parallelism on a per-SA basis, could ultimately degrade performance! Thus developers must exercise care in designing high speed IPsec devices, and they must understand how crypto chips work to achieve high speeds.

In CM, taking advantage of pipelining and parallelism for an individual packet is much easier because of the lack of feedback. One can load the per-packet value into a core, and begin generating the keystream for a series of blocks. After the first round has completed, a new input can be loaded into the same core, to begin generating another part of the keystream. In the simplest case, one could pipeline 12 blocks worth of keystream generation for a single packet, using a single core, taking advantage of the 12 round depth of AES. The core could generate the sequence of intra-packet inputs, using whatever algorithm is defined for that purpose.

If we are to make maximum use of a core, at some point it will be necessary to load a new input into a core for a different packet, while the core is still generating keystream for another packet, maybe even for a packet for another SA. Otherwise the core will be idle while we wait for up to 11 rounds (for AES) for the keystream for the previous packet to exit. This suggests that a crypto chip has to maintain some state for each core it contains, to remember which keystream outputs go with which packets on which SAs, in order to be able to get the most out of each core. So long as that state is completely local to the chip, this is feasible.

Since crypto chips often contain multiple cores, it also is possible to improve throughput for a single packet by using parallelism within the chip. One might begin generating keystream in two or more cores, in parallel, for the same packet. This is not too hard for CM, unlike CBC or CFB mode, because we know what inputs to load into each core to generate keystream for different blocks within a packet. Also, the way we choose to do this at a transmitter will be invisible to a receiver, so long as we follow the same algorithm for generating the intra-packet input sequences. Thus transmitters and receivers can employ different numbers of cores, even different numbers of chips, to generate keystream in a deterministic fashion and still have the process work properly, with no additional coordination. This is an important feature: any approach we adopt for using CM in ESP should allow a transmitter maximum flexibility in optimizing performance, while ensuring that receivers need not be aware of the optimizations employed by the transmitter.

For example, if a packet to be encrypted is 64 bytes long (more properly, 49-64 bytes in length), one could assign two crypto cores to the task of generating two blocks of keystream each, or assign four cores the task of assigning one block each. In the former case the whole packet can be encrypted in the time it takes for two rounds of AES, in the latter case, in the time for one round of AES. All that is required to make this work is to load the same inter-packet value into each core, and then to direct each core to use the appropriate offset into the packet for generating the right portion of the keystream. This use of both pipelining and parallelism makes CM very attractive as we try to create IPsec implementations that can operate at higher and higher speeds. At the same time that we try to preserve maximum flexibility for hardware implementations re performance, we don't want to adopt a scheme that will impose burdens on software implementations that may be peers. I believe this should be an important principle in our decisions.

Finally, note that this sort of pipelining does not reduce the delay associated with multi-round encryption. It will still take 12 rounds to generate the keystream for a packet using AES with 128-bit keys. Parallelism helps with delay, and the ability to pre-compute keystream also can reduce delay. However, pre-computation of keystream in IPsec may be feasible only on some contexts, e.g., when the number of SAs is small and thus the burden of storing pre-computed keystream is not too great.


CM and Overhead

With this background, we can examine the issue that has generated considerable debate recently, namely how to manage the per-packet inputs for CM. There is agreement that the intra-packet input should just be a simple counter. To accommodate the largest possible jumbogram that IPv6 can represent, a 28-bit value will suffice, and we can represent it in a 32-bit field, as that is convenient for both hardware and software implementations.

The disagreement has centered around the form that the per-packet input to CM should take. As noted earlier, this value need not be pseudorandom, unlike the recommendation for CBC and CFB modes. Some concerns have been expressed about using a simple counter here, because this means that subsequent inputs to CM will have a small Hamming distance. Conceivably, this might facilitate some forms of differential cryptanalysis, but AES is generally believed to be sufficiently strong so that this concern has generally been dismissed. So, there is agreement that a per-packet counter is sufficient.

If one adopts a very conservative model of encryption security, then at most 2^64 blocks should be encrypted under a single key, which says that no more than 64 bits are needed to identify each packet in an SA. This is exactly the same size as the ESP extended sequence number, so that value is an obvious candidate for use as the per-packet CM input. It has the advantage that it is already carried in the ESP header for each packet, and thus its use does not add any overhead to the ESP packet structure for crypto synch purposes. The extent of the savings is subject to interpretation.

CM has the property that one need not pad a packet to the block size in order to encrypt/decrypt it. Rather, one merely XORs as many bits as needed with the last block of a packet to encrypt/decrypt it. In the IPsec context we require that the ciphertext portion of a packet end on a 4-byte boundary, so this becomes the determining factor for padding in the context of CM encryption. So, already CM has an advantage over CBC which requires padding to a block boundary. Today, using DES or 3DES, this CBC padding adds 4 bytes to every packet, on average. CBC mode for AES would add 8 bytes of overhead. If we use the ESP sequence number as the per-packet input to CM, we can gain another 8-byte savings relative to DES/3DES CBC.

There are several ways of looking at the overhead figures. Today we tolerate an average of 12 bytes of per-packet crypto overhead, using DES or 3DES CBC, an 8-byte IV plus the average 4-byte padding overhead.  Moving to CM will shave this overhead by an average of 4 bytes (by removing the padding), a 1/3 savings, even if we carry an explicit 8-byte per-packet CM input. This analysis is accurate, but simplistic, as it looks only at the overhead due to the crypto mode. It ignores the overhead imposed by ESP.

The ESP header is 8-bytes long (4-byte SPI and 4-byte explicit sequence number). Because of the 4-byte alignment requirement for the end of the ciphertext, and because the last two bytes of the ciphertext are part of the ESP trailer, an average of 4 bytes of overhead is added there as well. Then the ICV is attached, in the common (and recommended case) where integrity is employed. (Because CM provides NO protection of any form with regard to integrity, an ICV is critical when this mode is used.) The default ICV algorithms add an additional 12 bytes to the end of the packet. So, in aggregate, ESP typically adds 24 bytes to a packet, independent of the use of an explicit IV. In that context, an explicit 8-byte IV represents 1/4 of the total overhead added by ESP (24 bytes of pure ESP overhead, plus an 8-byte IV = 32 bytes.)

If there is no compression of an (outer) IPv4 header, and if there are no options, which is typical, that header is 20 bytes long. A TCP header, inside the ESP payload, is 20 bytes (again, assuming no options). A UDP header is 8 bytes. (IPsec does not accommodate compression of transport layer headers; they are used for SA selection and the transmitter and for SA checking at the receiver, so any compression of these headers would become an integral part of security critical IPsec processing, not a generally desirable outcome.) The protocol overhead for a packet is 20+24 (or 8 for UDP) = 44 (or 28 for UDP)  bytes, independent of any application data and prior to applying ESP. Other than VoIP, for which we have heard varying estimates of application data size, the typical minimum size packet is a TCP ACK, which is 44 bytes. The ESP overhead, at 24 bytes, makes for a minimum encrypted packet size of 68 bytes (sans IV). In that common context, the 8 added bytes for an explicit IV represents an 11.7% increase in packet size. Typical packet sizes tend to be much larger, with an attendant decrease in the percentage overhead attributable to ESP and to an explicit IV.

In practice it seems that most IPsec traffic is carried in tunnel mode, which adds another 20-byte inner IP header, which would bring the IV overhead down to about 9%. (The use of tunnel mode is required for the common case of remote user access, and for inter-site VPNs. It also seems to be used as a default in many implementations, where transport mode would suffice.) I leave it to others to provide analogous estimates for the VoIP case, with appropriate assumptions about what compression is applied where, and under what circumstances, and whether this requires use of any compression algorithms that must be licensed. But, it seems clear that in a very large number of common IPsec uses, the overhead associated with carriage of an explicit IV is fairly small.

None of this analysis is intended to suggest that we should be cavalier about the overhead associated with IPsec. When I developed the extended sequence number (ESN) option for AH and ESP, I chose to not carry an extra 4 bytes of sequence number for several reasons.  There is an obvious desire to maintain backward compatibility for the on the wire format, and to minimize overhead. Perhaps the most important reason for making the added 4 bytes for the ESN be implicit rather than explicit, is to preserve the 8-btye alignment for the beginning of payload, consistent with IPv6 requirements. But the overhead imposed by these 4 bytes would not, by itself, justify the added complexity that results from making them implicit. In the same vein, I suggest that we not introduce undue complexity to IPsec in an effort to save 8 more bytes per packet, since it represents a fairly small overhead in the vast majority of circumstances.


CM & System Security

When we consider the use of an explicit vs. an implicit IV for CM, we also need to examine system security issues. Some of these issues are rather subtle and thus require a detailed explanation, much like the description of CM and how it can be used to achieve higher performance.

Management of the ESP sequence number is well defined by RFC 2402 & 2406, and management of the ESN is defined in 2402/2406bis. A separate counter must be maintained for each SA, and recall that an SA is a unidirectional connection. The sequence number begins at 0; the first transmitted packet carrying a value of 1, and the value is not allowed to cycle for an SA. Thus a new SA must be created prior to transmitting a packet with the sequence number value of 2^32 (or with the implied value of 2^64 in the case of the ESN option.)

The purpose of the sequence number is to allow a receiver to detect and reject replayed packets, e.g., as a countermeasure to DoS attacks. As currently defined and used, e.g., with CBC mode, it has no implications for the security of the cryptography employed with IPsec. Thus a failure by a transmitter to properly manage the sequence number will not result in a violation of the confidentiality, integrity, or authentication guarantees associated with use of ESP. In this sense, the anti-replay feature of ESP is a secondary security function.

As a result of this well-defined and limited security use for the sequence number, its management is outside of the scope of the FIPS 140-1/2 crypto module evaluation criteria. These criteria focus on security functionality and assurance directly related to the management of crypto keys, on the correct implementation and operation of crypto algorithms, and on related aspects of crypto module security. These evaluation criteria does NOT address security issues associated with a protocol like IPsec, even though a number of IPsec implementations make use of crypto modules that have been evaluated under FIPS 140-1/2. It is appropriate that these IPsec products cite FIPS 140 evaluation ratings in product brochures even though this evaluation does not address the other security features of IPsec. (The evaluation criteria applies to both hardware and software modules and thus is widely applicable.) Keep this in mind as we discuss implementation options for management of ESP sequence numbers.

Some crypto chips that have been designed expressly for IPsec manage the ESP sequence number on chip. This is a good security design approach which makes it unlikely that the sequence number will be mismanaged, e.g., that the same sequence number will be assigned to multiple packets. However, it is not always possible to manage the sequence number for an SA on a chip. Vendors developing IPsec products have sometimes found it necessary to use multiple chips, perhaps spread over more than one (printed circuit) board to provide crypto support for traffic from one SA. An obvious context in which this has arisen is in PPVPN products, where many subscriber data streams come together in a product and the goal is to multiplex these data streams over a pool of crypto chips. The motivations here are the same one that cause ISPs to aggregate traffic at a POP using a hierarchy of routers and switches. In such contexts it is uneconomical to devote a crypto chip/module to each subscriber.

Sharing of a pool of crypto resources allows traffic for any SA to be assigned to any available crypto chip. This requires that the keys for each SA be available to each crypto chip. Because keys are constant for the life of an SA, this is easy accomplished by replicating the key material on each chip. Management of sequence numbers poses a problem in this context if one tries to manage them on the crypto chips. This is because this per-SA data changes every time a packet is transmitted on an SA and it is generally impractical to update the data and make it available to all the crypto chips in a timely fashion.

Although the PPVPN context is the one that first brought this issue to our attention, it is anticipated that there may be other contexts in which traffic for an SA may be directed to different chips at different times. It is a generic design strategy for scaling a system to accommodate higher traffic volumes without dedicating crypto chips to each possible traffic source.

When this issue was raised on the IPsec mailing list over a year ago, the advice provided by the WG to vendors who encountered this problem was to move management of the sequence numbers out of the crypto chips. For each SA there is a point in the system where the traffic is mapped to the SA and at that point one can assign the sequence number to what will become an ESP packet, without any synchronization problems. This approach does reduce the assurance with which sequence numbers are managed, relative to on-chip management, but because the security function offered by sequence numbers is quite limited, this is not viewed as a problem.

If we make use of the ESP sequence number as the per-packet input to CM, the situation changes. In this case, the sequence number is a critical security parameter for the encryption algorithm, as noted earlier. This is because encrypting two packets under the same key with the same per-packet CM input results in duplicate keystream and a serious compromise of confidentiality. Moreover, because the sequence number is clearly visible in the packet, a wiretapper would know precisely when this occurred, if it happened. If the ESP sequence number is used as the per-packet input in CM, then management of the sequence number falls within the scope of a FIPS 140-1/2 evaluation. This means that the security boundary for evaluation of a product must encompass management of the sequence number.

If sequence numbers are managed on crypto chips, this is not a problem. But, if a product wants to manage sequence numbers off chip, e.g., to better support scaling in the ways described above, then the security evaluation boundary will have to encompass a much larger portion of the IPsec product. In many instances, this will likely limit the level of assurance at which a product can be evaluated. In pragmatic terms, the security of the encryption process will almost certainly be lower, because the per-packet CM input is now managed in a less secure fashion. Some products might even forgo FIPS evaluation entirely, because if the security evaluation boundary grow to encompass most of the product software, any change in that software voids the evaluation!

This also creates a potentially very odd situation: if an IPsec product supports both CM and CBC modes, the security of the product might vary depending on which mode was used. This could arise if the security critical inputs to the encryption mode were managed in different places. For example, for CBC mode on-chip IV generation could be very secure, but off-chip sequence number management would result in lower assurance for CM, if the sequence number were used as the per-packet input.

This discussion of security evaluation boundaries is not based on arbitrary evaluation criteria. It has a very pragmatic basis. Experience has shown that many, if not most, of the security vulnerabilities that arise in fielded products are a result of implementation errors. Increasing the size of the security boundary either reduces the likely level of assurance that is achieved, or increases the costs associated with engineering the product (for a fixed level of assurance). In general, architectural approaches that make it easy to do a good job of ensuring keystream uniqueness, make it more likely that a product will not have vulnerabilities due to keystream generation failures.

To put this issue in perspective, the current ID warns implementers against generating keystream for more than 2^64 blocks (not packets), even though we do not know of any specific vulnerabilities that could be exploited if this limit is exceeded. Yet we understand precisely what attacks could result if keystream is reused. Thus it makes sense to adopt approaches to keystream management that do not make it harder to do this task in a very secure fashion.

This analysis argues for adopting an approach to generating the per-packet CM input in a fashion that can be uniformly secure, irrespective of whether the ESP sequence number is managed on chip or off. For performance reasons, one would like an approach that allows multiple chips to generate keystream for packets transmitted on the same SA, while ensuring no keystream reuse and without having to synchronize values (across chips) that change on a per-packet basis. If one carries an explicit, per-packet IV, these goals can be achieved.

There are several ways one can generate the per-packet IV in a secure fashion across multiple chips. For example, one can assign a distinct, small ID number to each chip (or each core on a chip), and include that number as part of a 64-bit IV. This ensures that each chip can generate a unique IV sequence in a purely local fashion, using the per-chip (or per-core) ID as part of the IV. There is no need to specify in a standard what portion of the IV is devoted to a per-chip ID, since to a receiver the whole IV is opaque. This means that an IPsec implementation that has just one chip can use the whole IV as a counter or an LFSR, while a multi-chip implementation can assign as many bits as are needed to allow for maximum, per-SA parallelism. This is precisely the sort of opportunity for local optimization, with no adverse implications for receiver implementation choices, that one should strive for in a standard.


Counters vs. Linear Feedback Shift Registers (LFSRs)

Finally, there has been discussion of the merits of using counters vs. LFSR to generate CM input sequences. LFSRs were used in the ATM Forum standard for CM encryption. They exhibit advantages, relative to adders, for generating a sequence of inputs in very high performance hardware. The time required by an LFSR to generate the next value in the sequence is constant, very small, and the hardware required is also minimal. In contrast, if one generates a sequence of inputs using a counter, the counter must allow for time to propagate carries, and the counter is bigger than an LFSR, for comparable input sizes. (One can diminish the delay attributable to carry propagation by devoting more gates to the adder, but it is not likely to be faster than an LFSR generating the same size sequence, and it will certainly be bigger in gate count.)

Note that these arguments do not apply to software implementations, especially ones making use of general purpose processors. In those implementations, an LFSR would generally be slower than use of a counter, given the availability of a 32 or 64-bit adder in the CPU. Software implementations are not capable of very high performance, and so there is no motivation to optimize for use of software with an LFSR. But it is important to not burden software implementations that communicate with very high performance hardware.

In the context of ESP, we argued that it is important to use a well-defined, standard way to generate the intra-packet input sequences. We also argued that it is preferable to have just one way to do this. Using an LFSR here would yield performance benefits, but these benefits may not be great, since the intra-packet sequences need be only 28-bit values. Also, we want to preserve flexibility for transmitters with regard to keystream generation. It does not seem easy to standardize a means for using LFSRs for intra-packet keystream generation. This leads to the suggestion to use a (28-bit) counter for this part of the CM input.

However, generation of per-packet (vs. intra-packet) inputs to CM does not have to be standardized, as explained in earlier analysis. We also have seen how some implementations might need to generate a new per-packet input as fast as an AES implementation can perform one round, the same speed at which the intra-packet sequences need to be generated. Thus it is attractive to allow for use of LFSRs to generate per-packet inputs, i.e., IVs. Note too that because the per-packet values are bigger (64-bits vs. 28-bits), the performance and gate count advantages for an LFSR vs. a counter can be greater, at least in principle, for hardware.

By allowing an implementer the freedom to choose how to generate these IVs, no constraints (other than uniqueness) are imposed, and there is no adverse effect on receivers, to whom these values are opaque. Thus a software implementation that receives packets from a hardware implementation using an LFSR for IVs is not affected by the transmitters implementation choice. The same is true in the other direction, i.e., use of a counter for IV generation does not affect a receiver.


The Bottom Line

The preceding, lengthy analysis has indicated why it is preferable to carry an explicit IV for per-packet synchronization for CM, in a range of contexts. Using explicit IVs allows product designers flexibility for improving encryption performance, while maintaining or improving security, relative to reusing the ESP sequence number as an IV. Reusing the ESP sequence number in this fashion precludes some designs that increase performance, as illustrated in the analysis. In some contexts, e.g., PPVPN designs, reuse of the sequence number will either make FIPS 140 evaluation harder and more expensive, or will reduce the security assurance level of products, when this mode is employed.

The only downside to this choice is the overhead associated with the IV. This overhead is, on average, less than what most IPsec implementations currently experience with DES/3DES CBC, because CM does not require block size padding. On a percentage basis, the overhead of an explicit IV is typically quite small. We have been told that in the VoIP context even this small overhead is a concern, but we have no detailed analysis of the extent of the overhead relative to overall packets size.  We also have been told that these concerns have lead to development of an alternative security protocol SRTP, which is optimized for VoIP. I believe IPsec should not skew its use of CM to better support any one application, even an important one like VoIP, especially given the possibility of using an alternative security protocol.
--============_-1182600273==_ma============-- From owner-ipsec@lists.tislabs.com Sun Aug 18 15:47: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 g7IMlDw07989; Sun, 18 Aug 2002 15:47:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08062 Sun, 18 Aug 2002 17:39:34 -0400 (EDT) To: DAVID LEE Cc: "IPSec List (E-mail)" Subject: Re: SNMP Management for IPSec Devices References: <39B01E2189D99F4B8C9612462DB3922A06226B1D@srv-exchange.adtran.com> From: Wes Hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: Sun, 18 Aug 2002 14:53:27 -0700 In-Reply-To: <39B01E2189D99F4B8C9612462DB3922A06226B1D@srv-exchange.adtran.com> (DAVID LEE's message of "Wed, 7 Aug 2002 13:39:06 -0500") Message-ID: Lines: 11 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.5 (bamboo, i686-pc-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> On Wed, 7 Aug 2002 13:39:06 -0500 , DAVID LEE said: DAVID> Is there any interest in SNMP management for IPSec devices? Note that the ipsp working group has a policy configuration MIB going forward in it, in addition to the monitoring MIBs that have been produced by this WG. -- Wes Hardaker Network Associates Laboratories From owner-ipsec@lists.tislabs.com Sun Aug 18 23:28: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 g7J6Sow29954; Sun, 18 Aug 2002 23:28:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA08827 Mon, 19 Aug 2002 01:34:24 -0400 (EDT) From: "Jayant Shukla" To: "'Feng Ye'" , Subject: RE: IPSec NAT pass-through: how to do it? Date: Sun, 18 Aug 2002 22:46:18 -0700 Message-ID: <000001c24743$bd9d2a90$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: <20020816162937.59021.qmail@web11508.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If you are building an access box with NAT and no IPsec, all you need to do is implement IPsec pass-thru and not even think about UDP encapsulation. There is some explanation of IPsec pass-thru in the "Clarification of potential NAT..." thread. If you have any questions, feel free to send an e-mail. As far as patent issue is concerned, you won't have to worry a thing because IPsec pass-thru does not infringe on "patents" of MS and SSH. All NAT vendors (linksys etc.) implement IPsec pass-thru. Regards, Jayant www.trlokom.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Feng Ye > Sent: Friday, August 16, 2002 9:30 AM > To: ipsec@lists.tislabs.com > Subject: IPSec NAT pass-through: how to do it? > > Hello, > > I am working on an access box which has NAT, and now > we need to do IPSec pass through. We need to support > multiple clients behind the box. The scenario is the > user uses PC connect to the box and then to the > company gateway. > > I read the UDP encapsulation draft, but I don't know > it's the IPSec endpoints (PC, company security > gateway) responsibility, or the NAT box's > responsibility to implement the draft? Besides, how do > I know if the company gateway has this feature (Is > this draft widely used)? > > From an earlier post, "Clarification of potential NAT > multiple client solutions" by Mr. Brian Swander, seems > there're other ways to do it. RFC draft (IPsec-nat > compatibility reqts) also mentioned that there're ways > like looking at cookie/SPI, but they has limitations. > > I don't know which way is better, UDP encap, or the > hacker-like way? Besides, if SSH/Microsoft claims > patent, how other vendors do this (like netopia, > linksys, etc.)? > > Can somebody provide more detailed information or > point me to somewhere? Besides, if somebody can > provide consulting service please let me know. > > Since I am newbie to IPSec, any info is very > appreciated! > > Thanks a lot! > > Feng > > __________________________________________________ > Do You Yahoo!? > HotJobs - Search Thousands of New Jobs > http://www.hotjobs.com From owner-ipsec@lists.tislabs.com Mon Aug 19 09:30: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 g7JGU4w10147; Mon, 19 Aug 2002 09:30:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10111 Mon, 19 Aug 2002 11:31:02 -0400 (EDT) Date: Mon, 19 Aug 2002 10:42:51 -0500 (CDT) From: Nitin H Vaidya To: , Subject: Wireless Security workshop -- advance registration deadline soon Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Advance registration deadline soon (visit http://www.crhc.uiuc.edu/~nhv/wise for more information) --------------------------------------------------------------- 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) -------------------------------------------------------------------------------- Poster session (10:15 - 11:15 p.m.) -------------------------------------------------------------------------------- Invited Presentations (11:15 - 12:15) Information Assurance and Research Opportunities, D. Maughan, Defence Advanced Research Projects Agency Perspectives on Wireless Security T. Znati, National Science Foundation and University of Pittsburgh -------------------------------------------------------------------------------- Paper Session 2 (1:30 - 3:00) 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) -------------------------------------------------------------------------------- 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 (Microsoft Research Cambridge), J. Kempf (DoCoMoLabs U.S.A.), V.-M. Mantyla, P. Nikander (Ericsson Research NomadicLab) and M. Roe (Microsoft Research Cambridge) 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 Mon Aug 19 12:30: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 g7JJUUn19802; Mon, 19 Aug 2002 12:30:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10460 Mon, 19 Aug 2002 14:43:05 -0400 (EDT) Date: Mon, 19 Aug 2002 11:39:50 -0700 (PDT) Message-Id: <200208191839.g7JIdoQ15907@boreas.isi.edu> From: Clifford Neuman To: ipsec@lists.tislabs.com Subject: CFP - Symposium on Network & Distributed Systems Security Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Internet Society's (ISOC) annual Symposium on Network and Distributed System Security (NDSS) brings together innovative and forward thinking members of the Internet community including leading-edge security researchers and implementers, globally-recognized security-technology experts, and users from both the private and public sectors who design, develop, exploit, and deploy the technologies that define network and distributed system security. If you are working on new and practical approaches to security problems that are endemic to network and distributed systems, we invite you to participate in NDSS'03 by submitting one or more technical papers and/or panel proposals. Submission details may be found at: http://www.isoc.org/isoc/conferences/ndss/03/cfp.shtml NDSS'03 will again be held for three days in San Diego, California in February, 2003. One day of tutorials will be followed by two days of technical sessions including refereed papers, invited talks, and panel discussions and debates. Please be aware that the NDSS'03 cut off date for paper and panel submission is August 30, 2002. All accepted papers will be published in The NDSS Proceedings by the Internet Society. There will also be an Outstanding Paper Award presented at the Symposium to the author(s). Submitted papers should not have been previously published or be submitted simultaneously to a journal or to another symposium or workshop with a published proceedings. Please consider joining us at NDSS'03. We look forward to hearing from you! Clifford Neuman, Information Sciences Institute, University of Southern California General Chair, NDSS'03 Virgil Gligor, University of Maryland Michael Reiter, Carnegie Mellon University Program Chairs, NDSS'03 From owner-ipsec@lists.tislabs.com Mon Aug 19 14:04: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 g7JL4Dn25456; Mon, 19 Aug 2002 14:04:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10651 Mon, 19 Aug 2002 16:19:01 -0400 (EDT) From: "Geoffrey Huang" To: Subject: DPD as informational Date: Mon, 19 Aug 2002 13:31:07 -0700 Message-ID: <001b01c247bf$58ca3e10$85d46b80@ghuanginspiron> 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.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi there, The document draft-ietf-ipsec-dpd-00.txt has expired, and I'm considering moving forward with it at least as an informational document. Are there any comments or opinions about this? -g From owner-ipsec@lists.tislabs.com Tue Aug 20 14:18: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 g7KLI4229206; Tue, 20 Aug 2002 14:18:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA12870 Tue, 20 Aug 2002 16:17:19 -0400 (EDT) Date: 20 Aug 2002 16:15:18 -0400 Message-ID: <003b01c24886$4f0aa370$6b6fe640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Barbara Fraser'" , " " Cc: tytso@mit.edu Subject: RE: Son of Ike status 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: <4.3.2.7.2.20020806110031.03309ec0@mira-sjc5-4.cisco.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Over the next couple of weeks, we will summarize the > discussion on the > mailing list over the past two months regarding SOI > requirements to create > a proposed requirements and design directions document. Well, it's been a couple of weeks and we haven't heard any more details about the plan for SOI. I was particularly interested in the comment below: > An initial > modification to the document will be to integrate ideas from > JFK's approach > of using 4 messages with a stateless cookie. This is going to give us half-encrypted/half-plaintext messages, right? 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 Barbara Fraser > Sent: Tuesday, August 06, 2002 2:07 PM > To: ipsec@lists.tislabs.com > Cc: tytso@mit.edu; byfraser@cisco.com > Subject: Son of Ike status > > > Hi, > > Ted and I would like to update the working group on the > status of the SOI > work. After listening to the working group and after > discussions between > the JFK and IKEv2 teams, we will be moving forward > using draft-ietf-ipsec-ikev2-02.txt as the starting > document. An initial > modification to the document will be to integrate ideas from > JFK's approach > of using 4 messages with a stateless cookie. Charlie Kaufman > has agreed to > be the document editor, and all other authors will be given > due credit > within the body of the document. > > Over the next couple of weeks, we will summarize the > discussion on the > mailing list over the past two months regarding SOI > requirements to create > a proposed requirements and design directions document. This > will be sent > to the list for comment and ultimately be used to provide > direction for the > SOI design effort. > > We would like to thank all members of both the JFK and the > IKEv2 teams, and > the members of the working group for the time and effort you > have spent > helping us move forward with SOI. This direction has the > agreement of both > the JFK and IKEv2 teams and also appears to represent the discussions > within the working group. > > Best regards, > Barb and Ted > From owner-ipsec@lists.tislabs.com Wed Aug 21 09:19: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 g7LGJc223766; Wed, 21 Aug 2002 09:19:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14798 Wed, 21 Aug 2002 11:16:17 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <003b01c24886$4f0aa370$6b6fe640@ca.alcatel.com> Subject: RE: Son of Ike status To: andrew.krywaniuk@alcatel.com Cc: "'Barbara Fraser'" , ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, tytso@mit.edu X-Mailer: Lotus Notes Build V60_08092002NP August 09, 2002 Message-ID: Date: Wed, 21 Aug 2002 11:24:55 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_08152002NP|August 15, 2002) at 08/21/2002 11:24:12 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > An initial > > modification to the document will be to integrate ideas from > > JFK's approach > > of using 4 messages with a stateless cookie. > > This is going to give us half-encrypted/half-plaintext messages, right? Yes. That is an unfortunate cost. My plan was to say that messages could be half-encrypted/half-plaintext where the first half would always be plaintext and the second half encrypted and integrity protected. The encryption syntax would be the same as before but would start not immediately after the header but rather at the beginning of a particular playload type - that payload being whatever happened to appear first in the part of the message we wanted to encrypt. I was planning to say that only message 3 in the exchange could be so encoded... other messages had to be all cleartext or all plain. There are other possibilities. This was the one I thought would be simplest to implement. I am open to other suggestions. --Charlie This footnote confirms that either (1) this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses, (2) this email message was sent by a virus that appends this footnote, or (3) (most likely) the sender of this message is trying to raise awareness of how foolish it would be to place any confidence in footnotes like this. From owner-ipsec@lists.tislabs.com Wed Aug 21 13:44: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 g7LKi0208806; Wed, 21 Aug 2002 13:44:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15316 Wed, 21 Aug 2002 15:55:21 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Wed, 21 Aug 2002 13:09:06 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: RE: Son of Ike status Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:24 AM -0400 8/21/02, Charlie_Kaufman@notesdev.ibm.com wrote: >My plan was to say that messages could be half-encrypted/half-plaintext >where the first half would always be plaintext and the second half >encrypted and integrity protected. The encryption syntax would be the same >as before but would start not immediately after the header but rather >at the beginning of a particular playload type - that payload being >whatever >happened to appear first in the part of the message we wanted to encrypt. An alternative is to have a payload called something like "Encrypted stuff" that contains other payloads. Recursion of this payload would be unneeded and should be prohibited. >I was planning to say that only message 3 in the exchange could be so >encoded... other messages had to be all cleartext or all plain. An advantage of having messages 3 and 4 have the same structure (clear payloads and one encrypted enclosing payload) is that the responder could send informational messages in the clear in message 4, such as "your key is in the wrong group and therefore I couldn't encrypt with it" or "your message 3 appears to be bogus, go away". --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Aug 21 17:24: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 g7M0Ov215858; Wed, 21 Aug 2002 17:24:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA15697 Wed, 21 Aug 2002 19:33:11 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: Subject: RE: Son of Ike status To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_08092002NP August 09, 2002 Message-ID: Date: Wed, 21 Aug 2002 19:46:43 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_08152002NP|August 15, 2002) at 08/21/2002 07:41:30 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >My plan was to say that messages could be half-encrypted/half-plaintext > >where the first half would always be plaintext and the second half > >encrypted and integrity protected. The encryption syntax would be the same > >as before but would start not immediately after the header but rather > >at the beginning of a particular playload type - that payload being > >whatever > >happened to appear first in the part of the message we wanted to encrypt. > > An alternative is to have a payload called something like "Encrypted > stuff" that contains other payloads. Recursion of this payload would > be unneeded and should be prohibited. I considered that, but judged it to be marginally more complicated. Its advantage and its disadvantage is that it invites having more than one encrypted block and having unencrypted information before and after the encrypted information. It seemed like flexibility that we didn't need but that people would have to code for. > >I was planning to say that only message 3 in the exchange could be so > >encoded... other messages had to be all cleartext or all plain. > > An advantage of having messages 3 and 4 have the same structure > (clear payloads and one encrypted enclosing payload) is that the > responder could send informational messages in the clear in message > 4, such as "your key is in the wrong group and therefore I couldn't > encrypt with it" or "your message 3 appears to be bogus, go away". If we can encrypt any of message 4, we can encrypt all of it. In message 4 encryption is optional - certain errors would not be encrypted. But I can't think of any reason message 4 would be partially encrypted. Can you? --Charlie This footnote confirms that either (1) this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses, (2) this email message was sent by a virus that appends this footnote, or (3) (most likely) the sender of this message is trying to raise awareness of how foolish it would be to place any confidence in footnotes like this. From owner-ipsec@lists.tislabs.com Wed Aug 21 19:33: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 g7M2Xr218009; Wed, 21 Aug 2002 19:33:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA16011 Wed, 21 Aug 2002 21:46:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Wed, 21 Aug 2002 19:00:33 -0700 To: Charlie_Kaufman@notesdev.ibm.com From: Paul Hoffman / VPNC Subject: RE: Son of Ike status Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:46 PM -0400 8/21/02, Charlie_Kaufman@notesdev.ibm.com wrote: >I considered that, but judged it to be marginally more complicated. >Its advantage and its disadvantage is that it invites having more >than one encrypted block and having unencrypted information before >and after the encrypted information. It seemed like flexibility that we >didn't need but that people would have to code for. One of the nice things of IKEv2 is that there is much less flexibility in the messages; this leads to better interoperability. It is quite easy for the spec to say that message 3 can only have one encrypted blob, just like it is in JFKr. >If we can encrypt any of message 4, we can encrypt all of it. In message >4 encryption is optional - certain errors would not be encrypted. But >I can't think of any reason message 4 would be partially encrypted. >Can you? Nope. I was proposing that both messages 3 and 4 have the encrypted blob be optional, and only present if there is no error. The current IKEv2 draft doesn't specify well what to do with errors in messages 3 and 4, which will of course lead to lack of interoperability not al that different than with IKEv1. If we could tighten this up now, it would be great. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Aug 22 09:18: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 g7MGIo208948; Thu, 22 Aug 2002 09:18:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17631 Thu, 22 Aug 2002 11:27:20 -0400 (EDT) Message-ID: From: Chris Trobridge To: Stephen Kent , ipsec@lists.tislabs.com Subject: RE: a lengthy analysis of counter mode and ESP Date: Thu, 22 Aug 2002 16:13:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C249EE.756FA3D0" 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_01C249EE.756FA3D0 Content-Type: text/plain; charset="iso-8859-1" I had a look at the paper and, assuming I interpreted it correctly, the gist of it is that you can differentiate between counter-mode key stream and a purely random sequence because a counter-mode key doesn't exhibit the birthday paradox. This assumes that you have a counter-mode oracle that can provide the key stream. Does anyone have any idea of the signficance of this property? Chris -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: 16 August 2002 19:23 To: ipsec@lists.tislabs.com Subject: a lengthy analysis of counter mode and ESP We have been discussing how to make use of AES in counter mode with ESP. Several folks have told me that the discussion is not generally understandable, because of the many subtle issues involved and because when the discussion moved to the general IPsec list, from the design team list, we failed to do an adequate job of establishing context. So, this very lengthy message is an attempt to provide background and a more thorough discussion of the various technical issues associated with this complex topic. Hopefully, the WG as a whole will better understand the issues and be better positioned to make choices as a result of this analysis. Steve ---------- To put this issue in perspective, the current ID warns implementers against generating keystream for more than 2^64 blocks (not packets), even though we do not know of any specific vulnerabilities that could be exploited if this limit is exceeded. Yet we understand precisely what attacks could result if keystream is reused. Thus it makes sense to adopt approaches to keystream management that do not make it harder to do this task in a very secure fashion. ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept for Content Security threats, including computer viruses. http://www.baltimore.com ------_=_NextPart_001_01C249EE.756FA3D0 Content-Type: text/html; charset="iso-8859-1" I had a look at the paper and, assuming I interpreted it correctly, the gist of it is that you can differentiate between counter-mode key stream and a purely random sequence because a counter-mode key doesn't exhibit the birthday paradox. This assumes that you have a counter-mode oracle that can provide the key stream. Does anyone have any idea of the signficance of this property? Chris -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: 16 August 2002 19:23 To: ipsec@lists.tislabs.com Subject: a lengthy analysis of counter mode and ESP We have been discussing how to make use of AES in counter mode with ESP. Several folks have told me that the discussion is not generally understandable, because of the many subtle issues involved and because when the discussion moved to the general IPsec list, from the design team list, we failed to do an adequate job of establishing context. So, this very lengthy message is an attempt to provide background and a more thorough discussion of the various technical issues associated with this complex topic. Hopefully, the WG as a whole will better understand the issues and be better positioned to make choices as a result of this analysis. Steve ---------- To put this issue in perspective, the current ID warns implementers against generating keystream for more than 2^64 blocks (not packets), even though we do not know of any specific vulnerabilities that could be exploited if this limit is exceeded. Yet we understand precisely what attacks could result if keystream is reused. Thus it makes sense to adopt approaches to keystream management that do not make it harder to do this task in a very secure fashion. ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept for Content Security threats, including computer viruses. http://www.baltimore.com ------_=_NextPart_001_01C249EE.756FA3D0-- --=====================_97525273==_.ALT Content-Type: text/html; charset="us-ascii" Approved: Dob.ipsec >From majordomo-owner Thu Aug 22 10:57:10 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 KAA17539 Thu, 22 Aug 2002 10:57:10 -0400 (EDT) Received: by sentry.gw.tislabs.com; id LAA21486; Thu, 22 Aug 2002 11:11:42 -0400 (EDT) Received: from mailhost.baltimore.com(193.41.18.2) by sentry.gw.tislabs.com via smap (V5.5) id xma021482; Thu, 22 Aug 02 15:11:38 GMT Message-ID: From: Chris Trobridge To: Stephen Kent , ipsec@lists.tislabs.com Subject: RE: a lengthy analysis of counter mode and ESP Date: Thu, 22 Aug 2002 16:13:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C249EE.756FA3D0" 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_01C249EE.756FA3D0 Content-Type: text/plain; charset="iso-8859-1" I had a look at the paper and, assuming I interpreted it correctly, the gist of it is that you can differentiate between counter-mode key stream and a purely random sequence because a counter-mode key doesn't exhibit the birthday paradox. This assumes that you have a counter-mode oracle that can provide the key stream. Does anyone have any idea of the signficance of this property? Chris -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: 16 August 2002 19:23 To: ipsec@lists.tislabs.com Subject: a lengthy analysis of counter mode and ESP We have been discussing how to make use of AES in counter mode with ESP. Several folks have told me that the discussion is not generally understandable, because of the many subtle issues involved and because when the discussion moved to the general IPsec list, from the design team list, we failed to do an adequate job of establishing context. So, this very lengthy message is an attempt to provide background and a more thorough discussion of the various technical issues associated with this complex topic. Hopefully, the WG as a whole will better understand the issues and be better positioned to make choices as a result of this analysis. Steve ---------- To put this issue in perspective, the current ID warns implementers against generating keystream for more than 2^64 blocks (not packets), even though we do not know of any specific vulnerabilities that could be exploited if this limit is exceeded. Yet we understand precisely what attacks could result if keystream is reused. Thus it makes sense to adopt approaches to keystream management that do not make it harder to do this task in a very secure fashion. ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept for Content Security threats, including computer viruses. http://www.baltimore.com ------_=_NextPart_001_01C249EE.756FA3D0 Content-Type: text/html; charset="iso-8859-1" I had a look at the paper and, assuming I interpreted it correctly, the gist of it is that you can differentiate between counter-mode key stream and a purely random sequence because a counter-mode key doesn't exhibit the birthday paradox. This assumes that you have a counter-mode oracle that can provide the key stream. Does anyone have any idea of the signficance of this property? Chris -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: 16 August 2002 19:23 To: ipsec@lists.tislabs.com Subject: a lengthy analysis of counter mode and ESP We have been discussing how to make use of AES in counter mode with ESP. Several folks have told me that the discussion is not generally understandable, because of the many subtle issues involved and because when the discussion moved to the general IPsec list, from the design team list, we failed to do an adequate job of establishing context. So, this very lengthy message is an attempt to provide background and a more thorough discussion of the various technical issues associated with this complex topic. Hopefully, the WG as a whole will better understand the issues and be better positioned to make choices as a result of this analysis. Steve ---------- To put this issue in perspective, the current ID warns implementers against generating keystream for more than 2^64 blocks (not packets), even though we do not know of any specific vulnerabilities that could be exploited if this limit is exceeded. Yet we understand precisely what attacks could result if keystream is reused. Thus it makes sense to adopt approaches to keystream management that do not make it harder to do this task in a very secure fashion. ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept for Content Security threats, including computer viruses. http://www.baltimore.com ------_=_NextPart_001_01C249EE.756FA3D0-- --=====================_97525273==_.ALT-- From owner-ipsec@lists.tislabs.com Fri Aug 23 04:44: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 g7NBiw219394; Fri, 23 Aug 2002 04:44:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA19727 Fri, 23 Aug 2002 06:49:32 -0400 (EDT) Content-return: allowed Date: Fri, 23 Aug 2002 07:03:48 -0400 From: "Waterhouse, Richard" Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt To: ipsec@lists.tislabs.com Message-id: <2575327B6755D211A0E100805F9FF9540E3455B4@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 Michael Richardson wrote > Anyone who *needs* AES-CTR mode, likely needs it because they have >1Gb/s > links they want to secure. As such, I think that they have the bandwidth > not > to care. > >>> There is another application area that can benefit from CTR mode. CTR doesn't do error extension. If you are working in a noisy environment, have an application that can tolerate errors (but still don't want a bit error to multiply), need confidentiality but can do without authentication (e.g., you assure through other means that the plaintext is inaccessible), CTR would be an appropriate choice. (Yes I know this violates a MUST in the current draft, but that MUST leaves the developer without a mode appropriate for use in noisy environments.) From owner-ipsec@lists.tislabs.com Fri Aug 23 05:53: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 g7NCrf222830; Fri, 23 Aug 2002 05:53:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19860 Fri, 23 Aug 2002 08:07:26 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Waterhouse, Richard" Cc: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Aug 2002 08:21:25 -0400 Message-Id: <20020823122125.88C087B4C@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <2575327B6755D211A0E100805F9FF9540E3455B4@ndhmex02.ndhm.gsc.gte.com> , "Waterhouse, Richard" writes: >Michael Richardson wrote > >> Anyone who *needs* AES-CTR mode, likely needs it because they have >1Gb/s >> links they want to secure. As such, I think that they have the bandwidth >> not >> to care. >> > >>> There is another application area that can benefit from CTR >mode. CTR doesn't do error extension. If you are working in a noisy >environment, have an application that can tolerate errors (but still don't >want a bit error to multiply), need confidentiality but can do without >authentication (e.g., you assure through other means that the plaintext is >inaccessible), CTR would be an appropriate choice. (Yes I know this violates >a MUST in the current draft, but that MUST leaves the developer without a >mode appropriate for use in noisy environments.) > > The proper solution in that sort of environment is forward error correction. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) From owner-ipsec@lists.tislabs.com Fri Aug 23 06:26: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 g7NDQ5224274; Fri, 23 Aug 2002 06:26:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19923 Fri, 23 Aug 2002 08:44:51 -0400 (EDT) Content-return: allowed Date: Fri, 23 Aug 2002 08:59:26 -0400 From: "Waterhouse, Richard" Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt To: "Steven M. Bellovin" Cc: ipsec@lists.tislabs.com Message-id: <2575327B6755D211A0E100805F9FF9540E345632@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 Perhaps I'm overlooking something obvious here, but The FEC has to be external to ESP for it to prevent authentication failure at the ESP level. But I'm unaware of any provision within IP for FECs. Where would one apply such an FEC in the protocol stack at the transmitting ESP host/gateway that will make it through to the recipient ESP host/gateway? > ---------- > From: Steven M. Bellovin[SMTP:smb@research.att.com] > Sent: Friday, August 23, 2002 8:21 AM > To: Waterhouse, Richard > Cc: ipsec@lists.tislabs.com > Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt > > In message > <2575327B6755D211A0E100805F9FF9540E3455B4@ndhmex02.ndhm.gsc.gte.com> > , "Waterhouse, Richard" writes: > >> > > >>> There is another application area that can benefit from CTR > >mode. CTR doesn't do error extension. If you are working in a noisy > >environment, have an application that can tolerate errors (but still > don't > >want a bit error to multiply), need confidentiality but can do without > >authentication (e.g., you assure through other means that the plaintext > is > >inaccessible), CTR would be an appropriate choice. (Yes I know this > violates > >a MUST in the current draft, but that MUST leaves the developer without a > >mode appropriate for use in noisy environments.) > > > > > The proper solution in that sort of environment is forward error > correction. > > --Steve Bellovin, http://www.research.att.com/~smb (me) > http://www.wilyhacker.com ("Firewalls" book) > > From owner-ipsec@lists.tislabs.com Fri Aug 23 07:31: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 g7NEVF229818; Fri, 23 Aug 2002 07:31:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20163 Fri, 23 Aug 2002 09:47:00 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <2575327B6755D211A0E100805F9FF9540E3455B4@ndhmex02.ndhm.gsc.gte.com> References: <2575327B6755D211A0E100805F9FF9540E3455B4@ndhmex02.ndhm.gsc.gte.com> Date: Fri, 23 Aug 2002 09:58:32 -0400 To: "Waterhouse, Richard" From: Stephen Kent Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:03 AM -0400 8/23/02, Waterhouse, Richard wrote: >Michael Richardson wrote > >> Anyone who *needs* AES-CTR mode, likely needs it because they have >1Gb/s >> links they want to secure. As such, I think that they have the bandwidth >> not >> to care. >> > >>> There is another application area that can benefit from CTR >mode. CTR doesn't do error extension. If you are working in a noisy >environment, have an application that can tolerate errors (but still don't >want a bit error to multiply), need confidentiality but can do without >authentication (e.g., you assure through other means that the plaintext is >inaccessible), CTR would be an appropriate choice. (Yes I know this violates >a MUST in the current draft, but that MUST leaves the developer without a >mode appropriate for use in noisy environments.) Richard, There are other modes that offer no error extension as well, but at lower performance. OFB has been around for 20+ years. But, as you noted, there is a strong sentiment in thw WG against using crypto modes that offer no integrity support, while also not using an explicit integrity mechanism, because of attacks that can undermine confidentiality. Steve From owner-ipsec@lists.tislabs.com Fri Aug 23 08:20: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 g7NFKI204833; Fri, 23 Aug 2002 08:20:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20298 Fri, 23 Aug 2002 10:36:56 -0400 (EDT) Date: Fri, 23 Aug 2002 10:50:47 -0400 (EDT) From: Henry Spencer To: "Waterhouse, Richard" cc: "Steven M. Bellovin" , ipsec@lists.tislabs.com Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: <2575327B6755D211A0E100805F9FF9540E345632@ndhmex02.ndhm.gsc.gte.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 23 Aug 2002, Waterhouse, Richard wrote: > The FEC has to be external to ESP for it to prevent authentication failure > at the ESP level. But I'm unaware of any provision within IP for FECs. Where > would one apply such an FEC in the protocol stack at the transmitting ESP > host/gateway that will make it through to the recipient ESP host/gateway? The "noisy environment" is a link-level problem, not an IP-level problem, so it can be, should be, and is, solved with FEC at the link level. That is the right approach for a number of reasons, not least the need to tailor the FEC to the characteristics of the noise environment. By the way, the reason for making authentication a MUST is that there are effective active attacks against confidentiality without it. You don't *get* reliable confidentiality without authentication. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Aug 23 11:48: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 g7NImv217124; Fri, 23 Aug 2002 11:48:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20819 Fri, 23 Aug 2002 14:00:36 -0400 (EDT) Message-Id: <200208231814.g7NIEKfX026762@marajade.sandelman.ottawa.on.ca> To: "Waterhouse, Richard" cc: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-reply-to: Your message of "Fri, 23 Aug 2002 07:03:48 EDT." <2575327B6755D211A0E100805F9FF9540E3455B4@ndhmex02.ndhm.gsc.gte.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 23 Aug 2002 14:14:20 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Waterhouse" == Waterhouse, Richard writes: Waterhouse> There is another application area that can benefit from CTR Waterhouse> mode. CTR doesn't do error extension. If you are working in a Waterhouse> noisy environment, have an application that can tolerate Waterhouse> errors (but still don't want a bit error to multiply), need Waterhouse> confidentiality but can do without authentication (e.g., you I understand what you are saying, and it would apply to things like link encryption, where one uses a continuous CTR mode. I do not believe that it applies to packet oriented networks. Packets are either accepted in their entirety, or discarded (and retransmitted). While it might be that some media applications are such that a corrupted, un-authenticatable packet is better than no packet at all, such applications would also, by extension, be vulnerable to introduction of bogus packets, and general denial of service on them. I would suggest that such a security model is outside the scope of the current ESP transform - i.e. we are talking about more than just swapping 3DES for AES-CTR in the cipher table. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPWZ7doqHRg3pndX9AQHxVgQApnIcxZZwi5Wrk6yLxrXrg6RkuRNdvjBO DVxbsE43vBbduXrpBUF8GDo4v9RVGE3RX1SGgYSMuCsQRrGcb+wHoa5H7D/Sc46b 57kO6bGSr4PLMpQBYKuaFK/2Tx55DM52R2hw4hQ8UeDnBxFuy9hMenh//0Vmn1n2 BmSqiGotNSU= =MKfs -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Aug 23 13:32: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 g7NKWd225209; Fri, 23 Aug 2002 13:32:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21061 Fri, 23 Aug 2002 15:46:00 -0400 (EDT) Message-Id: <3.0.3.32.20020823125836.014123d8@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 23 Aug 2002 12:58:36 -0700 To: Stephen Kent , ipsec@lists.tislabs.com From: Alex Alten Subject: Re: a lengthy analysis of counter mode and ESP In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, I liked this analysis. Well written, I learned something from it. Maybe you should submit this as an informational RFC. - Alex At 02:23 PM 8/16/2002 -0400, Stephen Kent wrote: > Hopefully, the WG as a whole will better understand the issues and be >better positioned to make choices as a result of this analysis. > > Steve > ---------- -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Fri Aug 23 18:58: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 g7O1wM207776; Fri, 23 Aug 2002 18:58:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA21526 Fri, 23 Aug 2002 21:15:30 -0400 (EDT) Message-Id: <3.0.3.32.20020823182802.0126ab18@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 23 Aug 2002 18:28:02 -0700 To: Michael Richardson , ipsec@lists.tislabs.com From: Alex Alten Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: <200208062008.g76K8o5k022093@marajade.sandelman.ottawa.on.c a> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 04:08 PM 8/6/2002 -0400, Michael Richardson wrote: ... > Anyone who *needs* AES-CTR mode, likely needs it because they have >1Gb/s >links they want to secure. As such, I think that they have the bandwidth not >to care. Micahael, Are you implying that AES-CTR on a modern Intel CPU can handle more than 1 Gb/s Ethernet? Is this because the IV stays in L1 cache? Right now my direct measurements using AES-ECB (Dr. Gladman's C implementation) indicates that for all practical purposes, even Fast Ethernet (100 Mb/s) is still out of reach of a typical host computer. - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Sat Aug 24 13:05: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 g7OK5Q215247; Sat, 24 Aug 2002 13:05:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA22734 Sat, 24 Aug 2002 15:09:17 -0400 (EDT) Message-Id: <200208241923.g7OJNBZf001129@marajade.sandelman.ottawa.on.ca> To: Alex Alten cc: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-reply-to: Your message of "Fri, 23 Aug 2002 18:28:02 PDT." <3.0.3.32.20020823182802.0126ab18@mail> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 24 Aug 2002 15:23:10 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Alex" == Alex Alten writes: >> Anyone who *needs* AES-CTR mode, likely needs it because they have >> >1Gb/s links they want to secure. As such, I think that they have the >> bandwidth not to care. Alex> Micahael, Alex> Are you implying that AES-CTR on a modern Intel CPU can handle more Alex> than 1 Gb/s Ethernet? Is this because the IV stays in L1 cache? I'm not making any claim about hardware or software implementations. My understanding is that AES-CTR mode is implemented more cheaply than AES-CBC mode. Whether this is hardware or software is simply a question of what year it is. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPWfdHIqHRg3pndX9AQG4pAP7B36RhJomb6WcMVHmNO8FF/N05LFAJFdm bp24a6l8D9dBZ81PNQBTnTc4a1ZDLxX6eyvpHIbdPU1l7vO3FZIw4NsNHW//H8E4 WW35l1k2eHtdpITF8BY1fIlqmWjyGRpvh78eBykFLJkeCPZoCRpgvgll+irGbngY 7LGp5mrkeJo= =LNZk -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sat Aug 24 18:54: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 g7P1sY202016; Sat, 24 Aug 2002 18:54:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA23289 Sat, 24 Aug 2002 21:05:22 -0400 (EDT) Message-Id: <200208250119.g7P1JNL26857@sydney.East.Sun.COM> Date: Sat, 24 Aug 2002 21:19:21 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Avoiding tricking IKE v2 nodes into talking v1 To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BuU/iT/FAkQftxmf7Y0UlA== 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 In IKEv2, we were careful to specify how to safely negotiate new versions in the future. There's a bit in v2 saying "I could be speaking a higher version number". That way if two version 3 nodes are attempting to talk, and an attacker (or Maxwell) throws away the version 3 messages, and the nodes try to talk version 2 instead, they will know they could be speaking a higher version, and try again with version 3. But since the IKEv1 spec didn't have any such bit, we assumed there was nothing we could do about the possibility of two v2 nodes being tricked into talking v1. But then I noticed the feature in SSL that cleverly manages to have SSLv3 nodes talk SSLv2, but recognize that they could be speaking v3, in a way that didn't require any modifications to v2 (it's amazingly cute how they do it). Inspired by SSL, it seems like it might be nice to find some hack so that IKE version 2 capable nodes won't get tricked into talking IKEv1. Currently the v2 spec says that you try to talk v2, and if you don't get a response, you try talking v1. The IKEv1 spec is not very explicit about things like how to handle receipt of nonzero reserved bits (it says "must be zero", but doesn't say "must be ignored upon receipt"). Otherwise, we could use a reserved bit in IKEv1 similar to what we defined in IKEv2. But given that it looks like it might be dangerous to fool with reserved bits in v1, is there some other method that would be guaranteed not to upset any current implementations? One thing I could imagine is defining a dummy crypto algorithm. When the initiator proposes that algorithm, it means "I'm sending you v1 messages since you didn't answer my v2 messages, but I am capable of speaking v2". If Bob speaks v2 and gets an IKE_SA_init from Alice with that dummy crypto algorithm, I'd suggest that Bob should choose that dummy crypto algorithm, which tells Alice "let's start over with v2". Alice then should abort the v1 IKE, and start up again with a v2 IKE. What do people think? Is there a more elegant way of doing this? Is it not worth the work? Also, while I'm asking...would any IKEv1 implementations crash or do something possibly even worse if they receive an version 2 IKE_SA_init? I assume they either reject or ignore such messages, because otherwise it would be a trivial denial of service attack on IKEv1. Radia From owner-ipsec@lists.tislabs.com Sat Aug 24 21:43: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 g7P4hd208661; Sat, 24 Aug 2002 21:43:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA23532 Sat, 24 Aug 2002 23:58:15 -0400 (EDT) Message-Id: <3.0.3.32.20020824211140.013d8ed0@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sat, 24 Aug 2002 21:11:40 -0700 To: Michael Richardson From: Alex Alten Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Cc: ipsec@lists.tislabs.com In-Reply-To: <200208241923.g7OJNBZf001129@marajade.sandelman.ottawa.on.c a> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:23 PM 8/24/2002 -0400, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >>>>>> "Alex" == Alex Alten writes: > >> Anyone who *needs* AES-CTR mode, likely needs it because they have > >> >1Gb/s links they want to secure. As such, I think that they have the > >> bandwidth not to care. > > Alex> Micahael, > > Alex> Are you implying that AES-CTR on a modern Intel CPU can handle more > Alex> than 1 Gb/s Ethernet? Is this because the IV stays in L1 cache? > > I'm not making any claim about hardware or software implementations. >My understanding is that AES-CTR mode is implemented more cheaply >than AES-CBC mode. Whether this is hardware or software is simply a question >of what year it is. > This is a flippant answer. What year it is also determines the expected data rate that most PCs use. This year it is still 100 Mbps. In a 3-5 years it will be 1 Gbps. Therefore it is always the year of hardware, never of software. And, ipso facto, only 1/1000 of the installed base of PCs will use AES with IPsec. But hey, at least it pays the bills of a Canadian who doesn't give a damn about the costs incurred by the tens of thousands of financially hurting firms with over 100+ million PCs attached to the Internet. - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Sat Aug 24 23:50: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 g7P6o3217146; Sat, 24 Aug 2002 23:50:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA23775 Sun, 25 Aug 2002 02:04:34 -0400 (EDT) Date: Sun, 25 Aug 2002 02:18:32 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: hardware vs software (was Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt) In-Reply-To: <3.0.3.32.20020824211140.013d8ed0@mail> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 24 Aug 2002, Alex Alten wrote: > What year it is also determines the expected data rate that most PCs use. > This year it is still 100 Mbps. No, this year it is still 10 Mbps. 100 Mbps is coming on strong, but I doubt that it even has a majority of the jacks, let alone "most". (A lot of 10/100 interfaces currently run at 10, because that's what the local network infrastructure supports.) Don't confuse what's selling best with what's used most; there *is* a time lag there, even though it's shorter in computing than elsewhere. The 10->100 transition is well underway but by no means complete, partly because a lot of users don't *need* 100 that much. It's only quite recently that the costs of 100 have come down to the point that ordinary users are buying 10/100 hubs and such by default, instead of by specific need only. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Aug 26 04:15: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 g7QBFs223545; Mon, 26 Aug 2002 04:15:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA25937 Mon, 26 Aug 2002 06:14:02 -0400 (EDT) Content-return: allowed Date: Mon, 26 Aug 2002 06:28:22 -0400 From: "Waterhouse, Richard" Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt To: Henry Spencer Cc: "Steven M. Bellovin" , ipsec@lists.tislabs.com Message-id: <2575327B6755D211A0E100805F9FF9540E345969@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 > On Fri, 23 Aug 2002, Waterhouse, Richard wrote: > > The FEC has to be external to ESP for it to prevent authentication > failure > > at the ESP level. But I'm unaware of any provision within IP for FECs. > Where > > would one apply such an FEC in the protocol stack at the transmitting > ESP > > host/gateway that will make it through to the recipient ESP > host/gateway? > Henry Spencer replied > The "noisy environment" is a link-level problem, not an IP-level problem, > so it can be, should be, and is, solved with FEC at the link level. That > is the right approach for a number of reasons, not least the need to > tailor the FEC to the characteristics of the noise environment. > >>> In an ideal world this would be true. But in the real world there are a lot of networks (e.g., radio and wireless) where non-trivial noise is still seen by the higher layers. Therefore, even though it's not ideal, applications that need to run in such environments have to do FEC/CRC end-to-end. And they can't do it if the data carried in the packets is discarded, and not passed up, because of an ESP level authentication function. > By the way, the reason for making authentication a MUST is that there are > effective active attacks against confidentiality without it. You don't > *get* reliable confidentiality without authentication. > >>> This should be a security policy issue to be negotiated. If I have other mechanisms at higher layers that can compensate, I should be able to set my policy to negotiate AES CTR without authentication. From owner-ipsec@lists.tislabs.com Mon Aug 26 05:04: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 g7QC4x224669; Mon, 26 Aug 2002 05:04:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA26032 Mon, 26 Aug 2002 07:22:22 -0400 (EDT) Message-ID: From: Harshwardhan Mittal To: "'ipsec@lists.tislabs.com'" Subject: Minimum set of crypto algos for ipsec implementaion Date: Mon, 26 Aug 2002 16:45:32 +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 All, Can Anyone tell me what minimum set of cryptographic algorithms required to implement standard compliance IPSec and IKE. I mean which algorithms are mandactory to support and what are the prescribed key lengths. Also what AH and ESP modes and IKE phases needs to be implemented. Thanks in advance. Regards, Harsh Mittal From owner-ipsec@lists.tislabs.com Mon Aug 26 05:07: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 g7QC7o224746; Mon, 26 Aug 2002 05:07:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA26044 Mon, 26 Aug 2002 07:27:22 -0400 (EDT) Message-Id: <3.0.3.32.20020826044016.00feb710@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 26 Aug 2002 04:40:16 -0700 To: Henry Spencer , IP Security List From: Alex Alten Subject: Re: hardware vs software (was Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt) In-Reply-To: References: <3.0.3.32.20020824211140.013d8ed0@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The 50% cross over from 10 to 100 has already occurred for new Fast Ethernet NICs. Giga-Ethernet is now about 5-10% with 50% crossover in new NICs around 2005 or 2006. Installed PC base usually takes about 7-8 years to completely change over (about a 12% scrap rate). Network upgrades are every 7-8 years, a relic of telecom upgrade cycle. If crypto is in sw then all installed base is a factor, hw crypto can only be delivered in new NICs. I doubt one can get old 10 Mbps LANs to upgrade with new crypto NICs, they only will spend $5/NIC max. The rough rule of thumb I use with software crypto in network stack is that it must run well on 5 yr old hardware (to cover 80% of installed base). This means 200 Mhz PCs. In this case, AES is maybe 1/4 or 1/3 of the CPU at 10 Mbps data transfer rates. Just barely acceptable. Extrapolating this means that 2 GHz PCs are where AES finally is OK in software for Fast Ethernet, but it will be 5 yrs before 2/3rds of installed PC base is this fast. Forget GigaEthernet for 10 years. Now one can see why the "active" installed base of DES/3DES IPsec has probably not exceeded 100,000 PCs, 1/1000 of all Internet hosts. Despite AES 5x speed up over DES, I think it is not quite fast enough either. Once you are forced to use hardware, then the uptake drops to much less than 1%. I think IPsec is really stuck in a deep hole, unless a cipher (or a mode?) can be found that runs 10x faster than AES in software. Then we can in a practical manner cover the majority of the PC installed base now. - Alex At 02:18 AM 8/25/2002 -0400, Henry Spencer wrote: >On Sat, 24 Aug 2002, Alex Alten wrote: >> What year it is also determines the expected data rate that most PCs use. >> This year it is still 100 Mbps. > >No, this year it is still 10 Mbps. 100 Mbps is coming on strong, but I >doubt that it even has a majority of the jacks, let alone "most". (A lot >of 10/100 interfaces currently run at 10, because that's what the local >network infrastructure supports.) Don't confuse what's selling best with >what's used most; there *is* a time lag there, even though it's shorter in >computing than elsewhere. > >The 10->100 transition is well underway but by no means complete, partly >because a lot of users don't *need* 100 that much. It's only quite >recently that the costs of 100 have come down to the point that ordinary >users are buying 10/100 hubs and such by default, instead of by specific >need only. > > Henry Spencer > henry@spsystems.net > > -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Mon Aug 26 06:31: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 g7QDVE227427; Mon, 26 Aug 2002 06:31:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26266 Mon, 26 Aug 2002 08:46:32 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <200208241923.g7OJNBZf001129@marajade.sandelman.ottawa.on.ca> References: <200208241923.g7OJNBZf001129@marajade.sandelman.ottawa.on.ca> Date: Mon, 26 Aug 2002 08:40:34 -0400 To: Michael Richardson From: Stephen Kent Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:23 PM -0400 8/24/02, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >>>>>> "Alex" == Alex Alten writes: > >> Anyone who *needs* AES-CTR mode, likely needs it because they have > >> >1Gb/s links they want to secure. As such, I think that they have the > >> bandwidth not to care. > > Alex> Micahael, > > Alex> Are you implying that AES-CTR on a modern Intel CPU can handle more > Alex> than 1 Gb/s Ethernet? Is this because the IV stays in L1 cache? > > I'm not making any claim about hardware or software implementations. >My understanding is that AES-CTR mode is implemented more cheaply >than AES-CBC mode. Whether this is hardware or software is simply a question >of what year it is. > I don't think we can say that CTR mode is easier to implement in software than CBC mode. CTR mode probably isn't any faster than CBC, in general, in software, since software can't generally take advantage of the pipelining or parallelism. Steve From owner-ipsec@lists.tislabs.com Mon Aug 26 06:40: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 g7QDeO227666; Mon, 26 Aug 2002 06:40:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26289 Mon, 26 Aug 2002 09:00:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <3.0.3.32.20020826044016.00feb710@mail> References: <3.0.3.32.20020824211140.013d8ed0@mail> <3.0.3.32.20020826044016.00feb710@mail> Date: Mon, 26 Aug 2002 09:10:51 -0400 To: Alex Alten From: Stephen Kent Subject: Re: hardware vs software (was Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt) Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex, I agree that software would be hard pressed to keep up with very high speed LANs, but it is also fair to note that not all traffic merits IPsec protection. For example, I would expect to use S/MIME for e-mail, not bother securing NNTP, and most folks will continue to use SSL for web traffic. Also, workstations are not always transmitting or receiving packets, so the percentage of a CPU devoted to crypto needs to be tempered by that observation as well. Steve From owner-ipsec@lists.tislabs.com Mon Aug 26 07:27: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 g7QERY229233; Mon, 26 Aug 2002 07:27:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26578 Mon, 26 Aug 2002 09:39:11 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15722.13021.536965.640668@pkoning.dev.equallogic.com> Date: Mon, 26 Aug 2002 09:53:33 -0400 From: Paul Koning To: Richard.Waterhouse@GDC4S.Com Cc: henry@spsystems.net, smb@research.att.com, ipsec@lists.tislabs.com Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt References: <2575327B6755D211A0E100805F9FF9540E345969@ndhmex02.ndhm.gsc.gte.com> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Richard" == Richard Waterhouse writes: Richard> Henry Spencer replied >> The "noisy environment" is a link-level problem, not an IP-level >> problem, so it can be, should be, and is, solved with FEC at the >> link level. That is the right approach for a number of reasons, >> not least the need to tailor the FEC to the characteristics of the >> noise environment. >> Richrd> In an ideal world this would be true. But in the real world Richard> there are a Richard> lot of networks (e.g., radio and wireless) where non-trivial Richard> noise is still seen by the higher layers. Therefore, even Richard> though it's not ideal, applications that need to run in such Richard> environments have to do FEC/CRC end-to-end. And they can't Richard> do it if the data carried in the packets is discarded, and Richard> not passed up, because of an ESP level authentication Richard> function. I assume then that you would propose doing authentication (e.g., ESP with null encryption) above the FEC layers, end to end? If so, then this will only work if you can guarantee that the pipe between those authentication endpoints will never be shared, otherwise you have just made the encryption useless via the Bellovin attack. paul From owner-ipsec@lists.tislabs.com Mon Aug 26 07:39: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 g7QEdm229637; Mon, 26 Aug 2002 07:39:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26672 Mon, 26 Aug 2002 09:51:25 -0400 (EDT) Date: Mon, 26 Aug 2002 17:06:21 +0300 (FLE Daylight Time) From: Arne Ansper To: Stephen Kent cc: Michael Richardson , Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: Message-ID: X-X-Sender: arne@kiku.itsise MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-info: Headers changed by Barricade Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I don't think we can say that CTR mode is easier to implement in > software than CBC mode. CTR mode probably isn't any faster than CBC, > in general, in software, since software can't generally take > advantage of the pipelining or parallelism. yes it can. for example, we have implemented IDEA and Rijandel using Pentium MMX assembler instructions. 4 blocks are encrypted at the same time. using CBC mode we can use this optimization only for encryption. using CTR mode we can use this optimization for decryption too. another idea: one can use the CTR mode to reduce the latency of the encryption process. you can use the idle CPU cycles for producing the encrypted stream of bytes. when the packet arrives you can just XOR it with precomputed data. this way, you can use the spare memory to decrese the latency of your device. you cannot do this with CBC mode. when you use only CTR mode, you don't need decryption routines :) helps to save couple of kilobytes of code memory. arne From owner-ipsec@lists.tislabs.com Mon Aug 26 08:56: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 g7QFuj201923; Mon, 26 Aug 2002 08:56:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27024 Mon, 26 Aug 2002 11:07:21 -0400 (EDT) Date: Mon, 26 Aug 2002 11:21:58 -0400 (EDT) From: Henry Spencer To: "Waterhouse, Richard" cc: ipsec@lists.tislabs.com Subject: RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: <2575327B6755D211A0E100805F9FF9540E345969@ndhmex02.ndhm.gsc.gte.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 26 Aug 2002, Waterhouse, Richard wrote: > ...applications that need to run in such environments have to do FEC/CRC > end-to-end. And they can't do it if the data carried in the packets is > discarded, and not passed up, because of an ESP level authentication > function. Then the right thing to do is to do encryption and authentication end-to-end as well, *above* the error-correction layer. > > By the way, the reason for making authentication a MUST is that there are > > effective active attacks against confidentiality without it. You don't > > *get* reliable confidentiality without authentication. > > > >>> This should be a security policy issue to be negotiated. If I have other > mechanisms at higher layers that can compensate... How do mechanisms at higher layers "compensate" for easily-breakable encryption? I can't make any sense of this; can you elaborate? Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Aug 26 10:37: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 g7QHbN204581; Mon, 26 Aug 2002 10:37:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27400 Mon, 26 Aug 2002 12:48:34 -0400 (EDT) Message-Id: <200208261700.g7QH0cIn000340@fatty.lounge.org> To: Radia Perlman - Boston Center for Networking Cc: ipsec@lists.tislabs.com Subject: Re: Avoiding tricking IKE v2 nodes into talking v1 In-Reply-To: Your message of "Sat, 24 Aug 2002 21:19:21 EDT." <200208250119.g7P1JNL26857@sydney.East.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <338.1030381238.1@tibernian.com> Date: Mon, 26 Aug 2002 10:00:38 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The complaint about IKEv1 is that it is too complex and hard to understand, not that it is insecure. So I don't see falling back to IKEv1 as a real problem. If something really has to be done I suggest we come up with an IKEv1 "vendor ID" payload that says something like "I can actually speak a higher version of IKE". This payload would be sent in the 5th and 6th message in Main Mode or the 2nd and 3rd in Aggressive Mode. Most implementations can handle "vendor ID" payloads in these parts of the exchanges. Regarding your question about an IKEv1 implementation that crashes or worse if they receive an IKEv2 IKE_SA_init message, while the IKEv1 spec does not proscribe such behavior it also doesn't explicitly prohibit it (another area in which it is vague) but I'd argue that any implementation that crashed (or worse) for any reason is broken. There was a very popular IP stack that used to crash when it received the "Christmas Tree" packet (all options, lights, bells and whistles turned on). That wasn't a problem with IP, it was a problem with that implementation. Similarly with IKEv1, if it crashes upon receipt of unexpected input it's not a problem with the protocol it's a problem with the implementation. Dan. On Sat, 24 Aug 2002 21:19:21 EDT you wrote > In IKEv2, we were careful to specify how to safely negotiate > new versions in the future. There's a bit in v2 saying "I could be > speaking a higher version number". That way if two version 3 nodes > are attempting to talk, and an attacker (or Maxwell) throws away the > version 3 messages, and the nodes try to talk version 2 instead, > they will know they could be speaking a higher version, and try again > with version 3. > > But since the IKEv1 spec didn't have any such bit, we assumed there > was nothing we could do about the possibility of two v2 nodes being > tricked into talking v1. But then I noticed the feature in SSL > that cleverly manages to have SSLv3 nodes talk SSLv2, but recognize > that they could be speaking v3, in a way that didn't require any > modifications to v2 (it's amazingly cute how they do it). > > Inspired by SSL, it seems like it might be nice to find some hack > so that IKE version 2 capable nodes won't get tricked into talking IKEv1. > Currently the v2 spec says that you try to talk v2, and if you don't > get a response, you try talking v1. > > The IKEv1 spec is not very explicit about things like how to handle > receipt of nonzero reserved bits (it says "must be zero", > but doesn't say "must be ignored upon receipt"). Otherwise, we could > use a reserved bit in IKEv1 similar to what we defined in IKEv2. > > But given that it looks like it might be dangerous to fool with reserved > bits in v1, is there some other method that would be guaranteed not to > upset any current implementations? > > One thing I could imagine is defining a dummy crypto algorithm. When > the initiator proposes that algorithm, it means "I'm sending you v1 messages > since you didn't answer my v2 messages, but I am capable of speaking > v2". If Bob speaks v2 and gets an IKE_SA_init from Alice with that > dummy crypto algorithm, I'd suggest that Bob should choose that dummy > crypto algorithm, which tells Alice "let's start over with v2". Alice > then should abort the v1 IKE, and start up again with a v2 IKE. > > What do people think? Is there a more elegant way of doing this? Is it not worth the work? > > Also, while I'm asking...would any IKEv1 implementations crash or > do something possibly even worse if they receive an version 2 IKE_SA_init? > I assume they either reject or ignore such messages, because otherwise > it would be a trivial denial of service attack on IKEv1. > > Radia > From owner-ipsec@lists.tislabs.com Mon Aug 26 10:54: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 g7QHsH205018; Mon, 26 Aug 2002 10:54:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27489 Mon, 26 Aug 2002 13:07:59 -0400 (EDT) Message-Id: <200208261716.NAA14827@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-nat-reqts-02.txt Date: Mon, 26 Aug 2002 13:16:32 -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 : IPsec-NAT Compatibility Requirements Author(s) : B. Aboba, W. Dixon Filename : draft-ietf-ipsec-nat-reqts-02.txt Pages : 16 Date : 2002-8-26 Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of VPNs is to provide telecommuter access to the corporate Intranet. Today NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier to deployment of IPsec in one of its principal uses. This draft describes known incompatibilities between NAT and IPsec, and describes the requirements for addressing them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-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-nat-reqts-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-nat-reqts-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: <2002-8-26124431.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-nat-reqts-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-nat-reqts-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-26124431.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Aug 26 11:01: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 g7QI10205209; Mon, 26 Aug 2002 11:01:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27522 Mon, 26 Aug 2002 13:18:04 -0400 (EDT) Message-ID: <4D79C746863DD51197690002A52CDA00029BD8D1@zcard0kc.ca.nortel.com> From: "Marc Desrosiers" To: "'Radia Perlman - Boston Center for Networking'" , ipsec@lists.tislabs.com Subject: RE: Avoiding tricking IKE v2 nodes into talking v1 Date: Mon, 26 Aug 2002 13:02:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24D21.DCB83256" 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_01C24D21.DCB83256 Content-Type: text/plain; charset="iso-8859-1" It is an great idea to have the ability to state what version you are capable of supporting, I would suggest extending the concept to a byte level to provide the ability to state what other method you can support for key management to accommodate things like KINK, PF_KEY, others. Why limit ourselves... Marc DesRosiers -----Original Message----- From: Radia Perlman - Boston Center for Networking [mailto:Radia.Perlman@sun.com] Sent: Saturday, August 24, 2002 9:19 PM To: ipsec@lists.tislabs.com Subject: Avoiding tricking IKE v2 nodes into talking v1 In IKEv2, we were careful to specify how to safely negotiate new versions in the future. There's a bit in v2 saying "I could be speaking a higher version number". That way if two version 3 nodes are attempting to talk, and an attacker (or Maxwell) throws away the version 3 messages, and the nodes try to talk version 2 instead, they will know they could be speaking a higher version, and try again with version 3. But since the IKEv1 spec didn't have any such bit, we assumed there was nothing we could do about the possibility of two v2 nodes being tricked into talking v1. But then I noticed the feature in SSL that cleverly manages to have SSLv3 nodes talk SSLv2, but recognize that they could be speaking v3, in a way that didn't require any modifications to v2 (it's amazingly cute how they do it). Inspired by SSL, it seems like it might be nice to find some hack so that IKE version 2 capable nodes won't get tricked into talking IKEv1. Currently the v2 spec says that you try to talk v2, and if you don't get a response, you try talking v1. The IKEv1 spec is not very explicit about things like how to handle receipt of nonzero reserved bits (it says "must be zero", but doesn't say "must be ignored upon receipt"). Otherwise, we could use a reserved bit in IKEv1 similar to what we defined in IKEv2. But given that it looks like it might be dangerous to fool with reserved bits in v1, is there some other method that would be guaranteed not to upset any current implementations? One thing I could imagine is defining a dummy crypto algorithm. When the initiator proposes that algorithm, it means "I'm sending you v1 messages since you didn't answer my v2 messages, but I am capable of speaking v2". If Bob speaks v2 and gets an IKE_SA_init from Alice with that dummy crypto algorithm, I'd suggest that Bob should choose that dummy crypto algorithm, which tells Alice "let's start over with v2". Alice then should abort the v1 IKE, and start up again with a v2 IKE. What do people think? Is there a more elegant way of doing this? Is it not worth the work? Also, while I'm asking...would any IKEv1 implementations crash or do something possibly even worse if they receive an version 2 IKE_SA_init? I assume they either reject or ignore such messages, because otherwise it would be a trivial denial of service attack on IKEv1. Radia ------_=_NextPart_001_01C24D21.DCB83256 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Avoiding tricking IKE v2 nodes into talking v1 It is an great idea to have the ability to state what = version you are capable of supporting, I would suggest extending the = concept to a byte level to provide the ability to state what other = method you can support for key management to accommodate things like = KINK, PF_KEY, others. Why limit ourselves... Marc DesRosiers -----Original Message----- From: Radia Perlman - Boston Center for = Networking [<3d.htm>mailto:Radia.Perlman@sun.com]<= /FONT> Sent: Saturday, August 24, 2002 9:19 PM To: ipsec@lists.tislabs.com Subject: Avoiding tricking IKE v2 nodes into talking = v1 In IKEv2, we were careful to specify how to safely = negotiate new versions in the future. There's a bit in v2 = saying "I could be speaking a higher version number". That way if = two version 3 nodes are attempting to talk, and an attacker (or Maxwell) = throws away the version 3 messages, and the nodes try to talk = version 2 instead, they will know they could be speaking a higher = version, and try again with version 3. But since the IKEv1 spec didn't have any such bit, we = assumed there was nothing we could do about the possibility of two = v2 nodes being tricked into talking v1. But then I noticed the = feature in SSL that cleverly manages to have SSLv3 nodes talk = SSLv2, but recognize that they could be speaking v3, in a way that didn't = require any modifications to v2 (it's amazingly cute how they do = it). Inspired by SSL, it seems like it might be nice to = find some hack so that IKE version 2 capable nodes won't get = tricked into talking IKEv1. Currently the v2 spec says that you try to talk v2, = and if you don't get a response, you try talking v1. The IKEv1 spec is not very explicit about things like = how to handle receipt of nonzero reserved bits (it says "must = be zero", but doesn't say "must be ignored upon = receipt"). Otherwise, we could use a reserved bit in IKEv1 similar to what we = defined in IKEv2. But given that it looks like it might be dangerous to = fool with reserved bits in v1, is there some other method that would be = guaranteed not to upset any current implementations? One thing I could imagine is defining a dummy crypto = algorithm. When the initiator proposes that algorithm, it means = "I'm sending you v1 messages since you didn't answer my v2 messages, but I am = capable of speaking v2". If Bob speaks v2 and gets an IKE_SA_init = from Alice with that dummy crypto algorithm, I'd suggest that Bob should = choose that dummy crypto algorithm, which tells Alice "let's = start over with v2". Alice then should abort the v1 IKE, and start up again = with a v2 IKE. What do people think? Is there a more elegant way of = doing this? Is it not worth the work? Also, while I'm asking...would any IKEv1 = implementations crash or do something possibly even worse if they receive an = version 2 IKE_SA_init? I assume they either reject or ignore such messages, = because otherwise it would be a trivial denial of service attack on = IKEv1. Radia ------_=_NextPart_001_01C24D21.DCB83256-- --=====================_449718591==_.ALT Content-Type: text/html; charset="us-ascii" Approved: Dob.ipsec >From majordomo-owner Mon Aug 26 12:48:30 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 MAA27390 Mon, 26 Aug 2002 12:48:30 -0400 (EDT) Received: by sentry.gw.tislabs.com; id NAA10536; Mon, 26 Aug 2002 13:03:08 -0400 (EDT) Received: from zcars04e.nortelnetworks.com(47.129.242.56) by sentry.gw.tislabs.com via smap (V5.5) id xma010528; Mon, 26 Aug 02 17:02:28 GMT Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g7QH2eb11285; Mon, 26 Aug 2002 13:02:40 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Aug 2002 13:02:44 -0400 Message-ID: <4D79C746863DD51197690002A52CDA00029BD8D1@zcard0kc.ca.nortel.com> From: "Marc Desrosiers" To: "'Radia Perlman - Boston Center for Networking'" , ipsec@lists.tislabs.com Subject: RE: Avoiding tricking IKE v2 nodes into talking v1 Date: Mon, 26 Aug 2002 13:02:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24D21.DCB83256" 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_01C24D21.DCB83256 Content-Type: text/plain; charset="iso-8859-1" It is an great idea to have the ability to state what version you are capable of supporting, I would suggest extending the concept to a byte level to provide the ability to state what other method you can support for key management to accommodate things like KINK, PF_KEY, others. Why limit ourselves... Marc DesRosiers -----Original Message----- From: Radia Perlman - Boston Center for Networking [mailto:Radia.Perlman@sun.com] Sent: Saturday, August 24, 2002 9:19 PM To: ipsec@lists.tislabs.com Subject: Avoiding tricking IKE v2 nodes into talking v1 In IKEv2, we were careful to specify how to safely negotiate new versions in the future. There's a bit in v2 saying "I could be speaking a higher version number". That way if two version 3 nodes are attempting to talk, and an attacker (or Maxwell) throws away the version 3 messages, and the nodes try to talk version 2 instead, they will know they could be speaking a higher version, and try again with version 3. But since the IKEv1 spec didn't have any such bit, we assumed there was nothing we could do about the possibility of two v2 nodes being tricked into talking v1. But then I noticed the feature in SSL that cleverly manages to have SSLv3 nodes talk SSLv2, but recognize that they could be speaking v3, in a way that didn't require any modifications to v2 (it's amazingly cute how they do it). Inspired by SSL, it seems like it might be nice to find some hack so that IKE version 2 capable nodes won't get tricked into talking IKEv1. Currently the v2 spec says that you try to talk v2, and if you don't get a response, you try talking v1. The IKEv1 spec is not very explicit about things like how to handle receipt of nonzero reserved bits (it says "must be zero", but doesn't say "must be ignored upon receipt"). Otherwise, we could use a reserved bit in IKEv1 similar to what we defined in IKEv2. But given that it looks like it might be dangerous to fool with reserved bits in v1, is there some other method that would be guaranteed not to upset any current implementations? One thing I could imagine is defining a dummy crypto algorithm. When the initiator proposes that algorithm, it means "I'm sending you v1 messages since you didn't answer my v2 messages, but I am capable of speaking v2". If Bob speaks v2 and gets an IKE_SA_init from Alice with that dummy crypto algorithm, I'd suggest that Bob should choose that dummy crypto algorithm, which tells Alice "let's start over with v2". Alice then should abort the v1 IKE, and start up again with a v2 IKE. What do people think? Is there a more elegant way of doing this? Is it not worth the work? Also, while I'm asking...would any IKEv1 implementations crash or do something possibly even worse if they receive an version 2 IKE_SA_init? I assume they either reject or ignore such messages, because otherwise it would be a trivial denial of service attack on IKEv1. Radia ------_=_NextPart_001_01C24D21.DCB83256 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Avoiding tricking IKE v2 nodes into talking v1 It is an great idea to have the ability to state what = version you are capable of supporting, I would suggest extending the = concept to a byte level to provide the ability to state what other = method you can support for key management to accommodate things like = KINK, PF_KEY, others. Why limit ourselves... Marc DesRosiers -----Original Message----- From: Radia Perlman - Boston Center for = Networking [<3d.htm>mailto:Radia.Perlman@sun.com]<= /FONT> Sent: Saturday, August 24, 2002 9:19 PM To: ipsec@lists.tislabs.com Subject: Avoiding tricking IKE v2 nodes into talking = v1 In IKEv2, we were careful to specify how to safely = negotiate new versions in the future. There's a bit in v2 = saying "I could be speaking a higher version number". That way if = two version 3 nodes are attempting to talk, and an attacker (or Maxwell) = throws away the version 3 messages, and the nodes try to talk = version 2 instead, they will know they could be speaking a higher = version, and try again with version 3. But since the IKEv1 spec didn't have any such bit, we = assumed there was nothing we could do about the possibility of two = v2 nodes being tricked into talking v1. But then I noticed the = feature in SSL that cleverly manages to have SSLv3 nodes talk = SSLv2, but recognize that they could be speaking v3, in a way that didn't = require any modifications to v2 (it's amazingly cute how they do = it). Inspired by SSL, it seems like it might be nice to = find some hack so that IKE version 2 capable nodes won't get = tricked into talking IKEv1. Currently the v2 spec says that you try to talk v2, = and if you don't get a response, you try talking v1. The IKEv1 spec is not very explicit about things like = how to handle receipt of nonzero reserved bits (it says "must = be zero", but doesn't say "must be ignored upon = receipt"). Otherwise, we could use a reserved bit in IKEv1 similar to what we = defined in IKEv2. But given that it looks like it might be dangerous to = fool with reserved bits in v1, is there some other method that would be = guaranteed not to upset any current implementations? One thing I could imagine is defining a dummy crypto = algorithm. When the initiator proposes that algorithm, it means = "I'm sending you v1 messages since you didn't answer my v2 messages, but I am = capable of speaking v2". If Bob speaks v2 and gets an IKE_SA_init = from Alice with that dummy crypto algorithm, I'd suggest that Bob should = choose that dummy crypto algorithm, which tells Alice "let's = start over with v2". Alice then should abort the v1 IKE, and start up again = with a v2 IKE. What do people think? Is there a more elegant way of = doing this? Is it not worth the work? Also, while I'm asking...would any IKEv1 = implementations crash or do something possibly even worse if they receive an = version 2 IKE_SA_init? I assume they either reject or ignore such messages, = because otherwise it would be a trivial denial of service attack on = IKEv1. Radia ------_=_NextPart_001_01C24D21.DCB83256-- --=====================_449718591==_.ALT-- From owner-ipsec@lists.tislabs.com Mon Aug 26 11:16: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 g7QIG8205549; Mon, 26 Aug 2002 11:16:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27594 Mon, 26 Aug 2002 13:34:23 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200208261700.g7QH0cIn000340@fatty.lounge.org> References: <200208261700.g7QH0cIn000340@fatty.lounge.org> Date: Mon, 26 Aug 2002 10:48:44 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Avoiding tricking IKE v2 nodes into talking v1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:00 AM -0700 8/26/02, Dan Harkins wrote: > If something really has to be done I suggest we come up with an >IKEv1 "vendor ID" payload that says something like "I can actually >speak a higher version of IKE". This payload would be sent in the >5th and 6th message in Main Mode or the 2nd and 3rd in Aggressive >Mode. This sounds like the cleanest approach, and it matches what most implementations use vendor ID payloads for. >Most implementations can handle "vendor ID" payloads in these >parts of the exchanges. If the WG is worried about this, VPNC could probably test this fairly quickly among our members' products. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Aug 26 12: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 g7QJ15207310; Mon, 26 Aug 2002 12:01:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27895 Mon, 26 Aug 2002 14:18:18 -0400 (EDT) Message-ID: <007c01c24d2f$554174f0$d3f22b42@mv.lucent.com> From: "David Faucher" To: , "Paul Hoffman / VPNC" References: <200208261700.g7QH0cIn000340@fatty.lounge.org> Subject: Re: Avoiding tricking IKE v2 nodes into talking v1 Date: Mon, 26 Aug 2002 13:35:14 -0500 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since Vendor ID payloads are not authenticated, wouldn't this scheme be suspectible to an active attack where the IKEv1 vendor ID payload is removed. ----- Original Message ----- From: "Paul Hoffman / VPNC" To: Sent: Monday, August 26, 2002 12:48 PM Subject: Re: Avoiding tricking IKE v2 nodes into talking v1 | At 10:00 AM -0700 8/26/02, Dan Harkins wrote: | > If something really has to be done I suggest we come up with an | >IKEv1 "vendor ID" payload that says something like "I can actually | >speak a higher version of IKE". This payload would be sent in the | >5th and 6th message in Main Mode or the 2nd and 3rd in Aggressive | >Mode. | | This sounds like the cleanest approach, and it matches what most | implementations use vendor ID payloads for. | | >Most implementations can handle "vendor ID" payloads in these | >parts of the exchanges. | | If the WG is worried about this, VPNC could probably test this fairly | quickly among our members' products. | | --Paul Hoffman, Director | --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Aug 26 12:31: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 g7QJVk208234; Mon, 26 Aug 2002 12:31:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28015 Mon, 26 Aug 2002 14:47:58 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15722.31581.257104.413889@pkoning.dev.equallogic.com> Date: Mon, 26 Aug 2002 15:02:53 -0400 From: Paul Koning To: dharkins@tibernian.com Cc: Radia.Perlman@sun.com, ipsec@lists.tislabs.com Subject: Re: Avoiding tricking IKE v2 nodes into talking v1 References: <200208250119.g7P1JNL26857@sydney.East.Sun.COM> <200208261700.g7QH0cIn000340@fatty.lounge.org> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan Harkins writes: Dan> The complaint about IKEv1 is that it is too complex and hard to Dan> understand, not that it is insecure. So I don't see falling back Dan> to IKEv1 as a real problem. Dan> If something really has to be done I suggest we come up with an Dan> IKEv1 "vendor ID" payload that says something like "I can Dan> actually speak a higher version of IKE". This payload would be Dan> sent in the 5th and 6th message in Main Mode or the 2nd and 3rd Dan> in Aggressive Mode. Most implementations can handle "vendor ID" Dan> payloads in these parts of the exchanges. But vendor ID payloads don't announce any protocol action, they only set a namespace for subsequent private payloads. You can only have one at a time, so this approach wouldn't work if someone is already using the vendor ID payload for some other purpose. Dan> Regarding your question about an IKEv1 implementation that Dan> crashes or worse if they receive an IKEv2 IKE_SA_init message, Dan> while the IKEv1 spec does not proscribe such behavior it also Dan> doesn't explicitly prohibit it (another area in which it is Dan> vague) but I'd argue that any implementation that crashed (or Dan> worse) for any reason is broken. Exactly. I don't see any reason for the IKE spec to say that. This rule is true for every protocol. If you crash because of something you received, you're broken, end of discussion. One could put that statement in every protocol spec but it would just be duplicating a statement of the obvious... paul From owner-ipsec@lists.tislabs.com Mon Aug 26 12:33: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 g7QJXU208305; Mon, 26 Aug 2002 12:33:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28029 Mon, 26 Aug 2002 14:50:02 -0400 (EDT) Message-Id: <200208261902.g7QJ2SIn000639@fatty.lounge.org> To: "Marc Desrosiers" Cc: "'Radia Perlman - Boston Center for Networking'" , ipsec@lists.tislabs.com Subject: Re: Avoiding tricking IKE v2 nodes into talking v1 In-Reply-To: Your message of "Mon, 26 Aug 2002 13:02:36 EDT." <4D79C746863DD51197690002A52CDA00029BD8D1@zcard0kc.ca.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <637.1030388548.1@tibernian.com> Date: Mon, 26 Aug 2002 12:02:28 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk KINK should be using a different port than IKEv* and PF_KEY is an internal issue which should have no impact on the protocol. A good reason to limit ourselves is that we've gone down that road before and we decided to turn around and try another route. One of the reasons IKEv1 is so complicated is the desire for it to not limit itself. We all now almost universally agree that was a mistake. Dan. On Mon, 26 Aug 2002 13:02:36 EDT you wrote > 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_01C24D21.DCB83256 > Content-Type: text/plain; > charset="iso-8859-1" > > It is an great idea to have the ability to state what version you are > capable of supporting, I would suggest extending the concept to a byte level > to provide the ability to state what other method you can support for key > management to accommodate things like KINK, PF_KEY, others. Why limit > ourselves... > > Marc DesRosiers > > -----Original Message----- > From: Radia Perlman - Boston Center for Networking > [mailto:Radia.Perlman@sun.com] > Sent: Saturday, August 24, 2002 9:19 PM > To: ipsec@lists.tislabs.com > Subject: Avoiding tricking IKE v2 nodes into talking v1 > > > In IKEv2, we were careful to specify how to safely negotiate > new versions in the future. There's a bit in v2 saying "I could be > speaking a higher version number". That way if two version 3 nodes > are attempting to talk, and an attacker (or Maxwell) throws away the > version 3 messages, and the nodes try to talk version 2 instead, > they will know they could be speaking a higher version, and try again > with version 3. > > But since the IKEv1 spec didn't have any such bit, we assumed there > was nothing we could do about the possibility of two v2 nodes being > tricked into talking v1. But then I noticed the feature in SSL > that cleverly manages to have SSLv3 nodes talk SSLv2, but recognize > that they could be speaking v3, in a way that didn't require any > modifications to v2 (it's amazingly cute how they do it). > > Inspired by SSL, it seems like it might be nice to find some hack > so that IKE version 2 capable nodes won't get tricked into talking IKEv1. > Currently the v2 spec says that you try to talk v2, and if you don't > get a response, you try talking v1. > > The IKEv1 spec is not very explicit about things like how to handle > receipt of nonzero reserved bits (it says "must be zero", > but doesn't say "must be ignored upon receipt"). Otherwise, we could > use a reserved bit in IKEv1 similar to what we defined in IKEv2. > > But given that it looks like it might be dangerous to fool with reserved > bits in v1, is there some other method that would be guaranteed not to > upset any current implementations? > > One thing I could imagine is defining a dummy crypto algorithm. When > the initiator proposes that algorithm, it means "I'm sending you v1 messages > since you didn't answer my v2 messages, but I am capable of speaking > v2". If Bob speaks v2 and gets an IKE_SA_init from Alice with that > dummy crypto algorithm, I'd suggest that Bob should choose that dummy > crypto algorithm, which tells Alice "let's start over with v2". Alice > then should abort the v1 IKE, and start up again with a v2 IKE. > > What do people think? Is there a more elegant way of doing this? > Is it not worth the work? > > Also, while I'm asking...would any IKEv1 implementations crash or > do something possibly even worse if they receive an version 2 IKE_SA_init? > I assume they either reject or ignore such messages, because otherwise > it would be a trivial denial of service attack on IKEv1. > > Radia > > > ------_=_NextPart_001_01C24D21.DCB83256 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > RE: Avoiding tricking IKE v2 nodes into talking v1 > > It is an great idea to have the ability to state what = version you are capab >le of supporting, I would suggest extending the = concept to a byte level to p >rovide the ability to state what other = method you can support for key manage >ment to accommodate things like = KINK, PF_KEY, others. Why limit ourselves... > > Marc DesRosiers > > -----Original Message----- > From: Radia Perlman - Boston Center for = Networking > [<3d.htm>mailto:Radia.Perlman@sun.com]<= /FONT> > Sent: Saturday, August 24, 2002 9:19 PM > To: ipsec@lists.tislabs.com > Subject: Avoiding tricking IKE v2 nodes into talking = v1 > > In IKEv2, we were careful to specify how to safely = negotiate > new versions in the future. There's a bit in v2 = saying "I could be > speaking a higher version number". That way if = two version 3 nodes > are attempting to talk, and an attacker (or Maxwell) = throws away the > version 3 messages, and the nodes try to talk = version 2 instead, > they will know they could be speaking a higher = version, and try again > with version 3. > > But since the IKEv1 spec didn't have any such bit, we = assumed there > was nothing we could do about the possibility of two = v2 nodes being > tricked into talking v1. But then I noticed the = feature in SSL > that cleverly manages to have SSLv3 nodes talk = SSLv2, but recognize > that they could be speaking v3, in a way that didn't = require any > modifications to v2 (it's amazingly cute how they do = it). > > Inspired by SSL, it seems like it might be nice to = find some hack > so that IKE version 2 capable nodes won't get = tricked into talking IKEv1. > Currently the v2 spec says that you try to talk v2, = and if you don't > get a response, you try talking v1. > > The IKEv1 spec is not very explicit about things like = how to handle > receipt of nonzero reserved bits (it says "must = be zero", > but doesn't say "must be ignored upon = receipt"). Otherwise, we could > use a reserved bit in IKEv1 similar to what we = defined in IKEv2. > > But given that it looks like it might be dangerous to = fool with reserved > bits in v1, is there some other method that would be = guaranteed not to > upset any current implementations? > > One thing I could imagine is defining a dummy crypto = algorithm. When > the initiator proposes that algorithm, it means = "I'm sending you v1 message >s > since you didn't answer my v2 messages, but I am = capable of speaking > v2". If Bob speaks v2 and gets an IKE_SA_init = from Alice with that > dummy crypto algorithm, I'd suggest that Bob should = choose that dummy > crypto algorithm, which tells Alice "let's = start over with v2". Alice > then should abort the v1 IKE, and start up again = with a v2 IKE. > > What do people think? Is there a more elegant way of = doing this? > Is it not worth the work? > Also, while I'm asking...would any IKEv1 = implementations crash or > do something possibly even worse if they receive an = version 2 IKE_SA_init? > I assume they either reject or ignore such messages, = because otherwise > it would be a trivial denial of service attack on = IKEv1. > > Radia > ------_=_NextPart_001_01C24D21.DCB83256-- > > --=====================_449718591==_.ALT > Content-Type: text/html; charset="us-ascii" > > Approved: Dob.ipsec > >From majordomo-owner Mon Aug 26 12:48:30 2002 > Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [19 >2.94.214.100]) > by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id MAA27390 > Mon, 26 Aug 2002 12:48:30 -0400 (EDT) > Received: by sentry.gw.tislabs.com; id NAA10536; Mon, 26 Aug 2002 13:03:08 -0 >400 (EDT) > Received: from zcars04e.nortelnetworks.com(47.129.242.56) by sentry.gw.tislab >s.com via smap (V5.5) > id xma010528; Mon, 26 Aug 02 17:02:28 GMT > Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69] >) > by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g >7QH2eb11285; > Mon, 26 Aug 2002 13:02:40 -0400 (EDT) > Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) > id ; Mon, 26 Aug 2002 13:02:44 -0400 > Message-ID: <4D79C746863DD51197690002A52CDA00029BD8D1@zcard0kc.ca.nortel.com> > From: "Marc Desrosiers" > To: "'Radia Perlman - Boston Center for Networking'" , > ipsec@lists.tislabs.com > Subject: RE: Avoiding tricking IKE v2 nodes into talking v1 > Date: Mon, 26 Aug 2002 13:02:36 -0400 > MIME-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2653.19) > Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C24D21.DCB83256" > > 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_01C24D21.DCB83256 > Content-Type: text/plain; > charset="iso-8859-1" > > It is an great idea to have the ability to state what version you are > capable of supporting, I would suggest extending the concept to a byte level > to provide the ability to state what other method you can support for key > management to accommodate things like KINK, PF_KEY, others. Why limit > ourselves... > > Marc DesRosiers > > -----Original Message----- > From: Radia Perlman - Boston Center for Networking > [mailto:Radia.Perlman@sun.com] > Sent: Saturday, August 24, 2002 9:19 PM > To: ipsec@lists.tislabs.com > Subject: Avoiding tricking IKE v2 nodes into talking v1 > > > In IKEv2, we were careful to specify how to safely negotiate > new versions in the future. There's a bit in v2 saying "I could be > speaking a higher version number". That way if two version 3 nodes > are attempting to talk, and an attacker (or Maxwell) throws away the > version 3 messages, and the nodes try to talk version 2 instead, > they will know they could be speaking a higher version, and try again > with version 3. > > But since the IKEv1 spec didn't have any such bit, we assumed there > was nothing we could do about the possibility of two v2 nodes being > tricked into talking v1. But then I noticed the feature in SSL > that cleverly manages to have SSLv3 nodes talk SSLv2, but recognize > that they could be speaking v3, in a way that didn't require any > modifications to v2 (it's amazingly cute how they do it). > > Inspired by SSL, it seems like it might be nice to find some hack > so that IKE version 2 capable nodes won't get tricked into talking IKEv1. > Currently the v2 spec says that you try to talk v2, and if you don't > get a response, you try talking v1. > > The IKEv1 spec is not very explicit about things like how to handle > receipt of nonzero reserved bits (it says "must be zero", > but doesn't say "must be ignored upon receipt"). Otherwise, we could > use a reserved bit in IKEv1 similar to what we defined in IKEv2. > > But given that it looks like it might be dangerous to fool with reserved > bits in v1, is there some other method that would be guaranteed not to > upset any current implementations? > > One thing I could imagine is defining a dummy crypto algorithm. When > the initiator proposes that algorithm, it means "I'm sending you v1 messages > since you didn't answer my v2 messages, but I am capable of speaking > v2". If Bob speaks v2 and gets an IKE_SA_init from Alice with that > dummy crypto algorithm, I'd suggest that Bob should choose that dummy > crypto algorithm, which tells Alice "let's start over with v2". Alice > then should abort the v1 IKE, and start up again with a v2 IKE. > > What do people think? Is there a more elegant way of doing this? > Is it not worth the work? > > Also, while I'm asking...would any IKEv1 implementations crash or > do something possibly even worse if they receive an version 2 IKE_SA_init? > I assume they either reject or ignore such messages, because otherwise > it would be a trivial denial of service attack on IKEv1. > > Radia > > > ------_=_NextPart_001_01C24D21.DCB83256 > Content-Type: text/html; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > RE: Avoiding tricking IKE v2 nodes into talking v1 > > It is an great idea to have the ability to state what = version you are capab >le of supporting, I would suggest extending the = concept to a byte level to p >rovide the ability to state what other = method you can support for key manage >ment to accommodate things like = KINK, PF_KEY, others. Why limit ourselves... > > Marc DesRosiers > > -----Original Message----- > From: Radia Perlman - Boston Center for = Networking > [<3d.htm>mailto:Radia.Perlman@sun.com]<= /FONT> > Sent: Saturday, August 24, 2002 9:19 PM > To: ipsec@lists.tislabs.com > Subject: Avoiding tricking IKE v2 nodes into talking = v1 > > In IKEv2, we were careful to specify how to safely = negotiate > new versions in the future. There's a bit in v2 = saying "I could be > speaking a higher version number". That way if = two version 3 nodes > are attempting to talk, and an attacker (or Maxwell) = throws away the > version 3 messages, and the nodes try to talk = version 2 instead, > they will know they could be speaking a higher = version, and try again > with version 3. > > But since the IKEv1 spec didn't have any such bit, we = assumed there > was nothing we could do about the possibility of two = v2 nodes being > tricked into talking v1. But then I noticed the = feature in SSL > that cleverly manages to have SSLv3 nodes talk = SSLv2, but recognize > that they could be speaking v3, in a way that didn't = require any > modifications to v2 (it's amazingly cute how they do = it). > > Inspired by SSL, it seems like it might be nice to = find some hack > so that IKE version 2 capable nodes won't get = tricked into talking IKEv1. > Currently the v2 spec says that you try to talk v2, = and if you don't > get a response, you try talking v1. > > The IKEv1 spec is not very explicit about things like = how to handle > receipt of nonzero reserved bits (it says "must = be zero", > but doesn't say "must be ignored upon = receipt"). Otherwise, we could > use a reserved bit in IKEv1 similar to what we = defined in IKEv2. > > But given that it looks like it might be dangerous to = fool with reserved > bits in v1, is there some other method that would be = guaranteed not to > upset any current implementations? > > One thing I could imagine is defining a dummy crypto = algorithm. When > the initiator proposes that algorithm, it means = "I'm sending you v1 message >s > since you didn't answer my v2 messages, but I am = capable of speaking > v2". If Bob speaks v2 and gets an IKE_SA_init = from Alice with that > dummy crypto algorithm, I'd suggest that Bob should = choose that dummy > crypto algorithm, which tells Alice "let's = start over with v2". Alice > then should abort the v1 IKE, and start up again = with a v2 IKE. > > What do people think? Is there a more elegant way of = doing this? > Is it not worth the work? > > Also, while I'm asking...would any IKEv1 = implementations crash or > do something possibly even worse if they receive an = version 2 IKE_SA_init? > I assume they either reject or ignore such messages, = because otherwise > it would be a trivial denial of service attack on = IKEv1. > > Radia > ------_=_NextPart_001_01C24D21.DCB83256-- > > --=====================_449718591==_.ALT-- > From owner-ipsec@lists.tislabs.com Mon Aug 26 12:43: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 g7QJhS208705; Mon, 26 Aug 2002 12:43:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA28098 Mon, 26 Aug 2002 15:01:15 -0400 (EDT) Date: Mon, 26 Aug 2002 12:15:24 -0700 (PDT) From: Jan Vilhuber To: Paul Koning cc: , , Subject: Re: Avoiding tricking IKE v2 nodes into talking v1 In-Reply-To: <15722.31581.257104.413889@pkoning.dev.equallogic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 26 Aug 2002, Paul Koning wrote: > >>>>> "Dan" == Dan Harkins writes: > > Dan> The complaint about IKEv1 is that it is too complex and hard to > Dan> understand, not that it is insecure. So I don't see falling back > Dan> to IKEv1 as a real problem. > > Dan> If something really has to be done I suggest we come up with an > Dan> IKEv1 "vendor ID" payload that says something like "I can > Dan> actually speak a higher version of IKE". This payload would be > Dan> sent in the 5th and 6th message in Main Mode or the 2nd and 3rd > Dan> in Aggressive Mode. Most implementations can handle "vendor ID" > Dan> payloads in these parts of the exchanges. > > But vendor ID payloads don't announce any protocol action, they only > set a namespace for subsequent private payloads. You can only have > one at a time Where does it say this? I see no reason why you couldn't have 15 vendor-id payloads in message 5 or 6 (or anywhere else for that matter). Also, I don't see why a vendor-id is narrowly defined as "set a namespace for subsequent private payloads" (unless I missed a section in the IKE spec). I see them as announcing any capability you like, with or without additional private payloads. Using the vendor-id make a lot of sense to me (modulo the "it's not authenticated" bit). jan >, so this approach wouldn't work if someone is already > using the vendor ID payload for some other purpose. > > Dan> Regarding your question about an IKEv1 implementation that > Dan> crashes or worse if they receive an IKEv2 IKE_SA_init message, > Dan> while the IKEv1 spec does not proscribe such behavior it also > Dan> doesn't explicitly prohibit it (another area in which it is > Dan> vague) but I'd argue that any implementation that crashed (or > Dan> worse) for any reason is broken. > > Exactly. I don't see any reason for the IKE spec to say that. This > rule is true for every protocol. If you crash because of something > you received, you're broken, end of discussion. One could put that > statement in every protocol spec but it would just be duplicating a > statement of the obvious... > > paul > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Mon Aug 26 12:50: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 g7QJoK208892; Mon, 26 Aug 2002 12:50:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA28124 Mon, 26 Aug 2002 15:03:19 -0400 (EDT) Date: Mon, 26 Aug 2002 12:17:36 -0700 (PDT) From: Jan Vilhuber To: Dan Harkins cc: Marc Desrosiers , "'Radia Perlman - Boston Center for Networking'" , Subject: Re: Avoiding tricking IKE v2 nodes into talking v1 In-Reply-To: <200208261902.g7QJ2SIn000639@fatty.lounge.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 26 Aug 2002, Dan Harkins wrote: > KINK should be using a different port than IKEv* It does (or should or will): "9. Transport Considerations KINK uses UDP on port [XXX -- TBA by IANA] to transport its messages. " I assume "TBD by IANA" means != UDP 500. jan > and PF_KEY is an > internal issue which should have no impact on the protocol. A good > reason to limit ourselves is that we've gone down that road before > and we decided to turn around and try another route. One of the reasons > IKEv1 is so complicated is the desire for it to not limit itself. We all > now almost universally agree that was a mistake. > > Dan. > > On Mon, 26 Aug 2002 13:02:36 EDT you wrote > > 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_01C24D21.DCB83256 > > Content-Type: text/plain; > > charset="iso-8859-1" > > > > It is an great idea to have the ability to state what version you are > > capable of supporting, I would suggest extending the concept to a byte level > > to provide the ability to state what other method you can support for key > > management to accommodate things like KINK, PF_KEY, others. Why limit > > ourselves... > > > > Marc DesRosiers > > > > -----Original Message----- > > From: Radia Perlman - Boston Center for Networking > > [mailto:Radia.Perlman@sun.com] > > Sent: Saturday, August 24, 2002 9:19 PM > > To: ipsec@lists.tislabs.com > > Subject: Avoiding tricking IKE v2 nodes into talking v1 > > > > > > In IKEv2, we were careful to specify how to safely negotiate > > new versions in the future. There's a bit in v2 saying "I could be > > speaking a higher version number". That way if two version 3 nodes > > are attempting to talk, and an attacker (or Maxwell) throws away the > > version 3 messages, and the nodes try to talk version 2 instead, > > they will know they could be speaking a higher version, and try again > > with version 3. > > > > But since the IKEv1 spec didn't have any such bit, we assumed there > > was nothing we could do about the possibility of two v2 nodes being > > tricked into talking v1. But then I noticed the feature in SSL > > that cleverly manages to have SSLv3 nodes talk SSLv2, but recognize > > that they could be speaking v3, in a way that didn't require any > > modifications to v2 (it's amazingly cute how they do it). > > > > Inspired by SSL, it seems like it might be nice to find some hack > > so that IKE version 2 capable nodes won't get tricked into talking IKEv1. > > Currently the v2 spec says that you try to talk v2, and if you don't > > get a response, you try talking v1. > > > > The IKEv1 spec is not very explicit about things like how to handle > > receipt of nonzero reserved bits (it says "must be zero", > > but doesn't say "must be ignored upon receipt"). Otherwise, we could > > use a reserved bit in IKEv1 similar to what we defined in IKEv2. > > > > But given that it looks like it might be dangerous to fool with reserved > > bits in v1, is there some other method that would be guaranteed not to > > upset any current implementations? > > > > One thing I could imagine is defining a dummy crypto algorithm. When > > the initiator proposes that algorithm, it means "I'm sending you v1 messages > > since you didn't answer my v2 messages, but I am capable of speaking > > v2". If Bob speaks v2 and gets an IKE_SA_init from Alice with that > > dummy crypto algorithm, I'd suggest that Bob should choose that dummy > > crypto algorithm, which tells Alice "let's start over with v2". Alice > > then should abort the v1 IKE, and start up again with a v2 IKE. > > > > What do people think? Is there a more elegant way of doing this? > > Is it not worth the work? > > > > Also, while I'm asking...would any IKEv1 implementations crash or > > do something possibly even worse if they receive an version 2 IKE_SA_init? > > I assume they either reject or ignore such messages, because otherwise > > it would be a trivial denial of service attack on IKEv1. > > > > Radia > > > > > > ------_=_NextPart_001_01C24D21.DCB83256 > > Content-Type: text/html; > > charset="iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > > > > > > RE: Avoiding tricking IKE v2 nodes into talking v1 > > > > It is an great idea to have the ability to state what = version you are capab > >le of supporting, I would suggest extending the = concept to a byte level to p > >rovide the ability to state what other = method you can support for key manage > >ment to accommodate things like = KINK, PF_KEY, others. Why limit ourselves... > > > > Marc DesRosiers > > > > -----Original Message----- > > From: Radia Perlman - Boston Center for = Networking > > [<3d.htm>mailto:Radia.Perlman@sun.com]<= /FONT> > > Sent: Saturday, August 24, 2002 9:19 PM > > To: ipsec@lists.tislabs.com > > Subject: Avoiding tricking IKE v2 nodes into talking = v1 > > > > In IKEv2, we were careful to specify how to safely = negotiate > > new versions in the future. There's a bit in v2 = saying "I could be > > speaking a higher version number". That way if = two version 3 nodes > > are attempting to talk, and an attacker (or Maxwell) = throws away the > > version 3 messages, and the nodes try to talk = version 2 instead, > > they will know they could be speaking a higher = version, and try again > > with version 3. > > > > But since the IKEv1 spec didn't have any such bit, we = assumed there > > was nothing we could do about the possibility of two = v2 nodes being > > tricked into talking v1. But then I noticed the = feature in SSL > > that cleverly manages to have SSLv3 nodes talk = SSLv2, but recognize > > that they could be speaking v3, in a way that didn't = require any > > modifications to v2 (it's amazingly cute how they do = it). > > > > Inspired by SSL, it seems like it might be nice to = find some hack > > so that IKE version 2 capable nodes won't get = tricked into talking IKEv1. > > Currently the v2 spec says that you try to talk v2, = and if you don't > > get a response, you try talking v1. > > > > The IKEv1 spec is not very explicit about things like = how to handle > > receipt of nonzero reserved bits (it says "must = be zero", > > but doesn't say "must be ignored upon = receipt"). Otherwise, we could > > use a reserved bit in IKEv1 similar to what we = defined in IKEv2. > > > > But given that it looks like it might be dangerous to = fool with reserved > > bits in v1, is there some other method that would be = guaranteed not to > > upset any current implementations? > > > > One thing I could imagine is defining a dummy crypto = algorithm. When > > the initiator proposes that algorithm, it means = "I'm sending you v1 message > >s > > since you didn't answer my v2 messages, but I am = capable of speaking > > v2". If Bob speaks v2 and gets an IKE_SA_init = from Alice with that > > dummy crypto algorithm, I'd suggest that Bob should = choose that dummy > > crypto algorithm, which tells Alice "let's = start over with v2". Alice > > then should abort the v1 IKE, and start up again = with a v2 IKE. > > > > What do people think? Is there a more elegant way of = doing this? > > Is it not worth the work? > > > Also, while I'm asking...would any IKEv1 = implementations crash or > > do something possibly even worse if they receive an = version 2 IKE_SA_init? > > I assume they either reject or ignore such messages, = because otherwise > > it would be a trivial denial of service attack on = IKEv1. > > > > Radia > > ------_=_NextPart_001_01C24D21.DCB83256-- > > > > --=====================_449718591==_.ALT > > Content-Type: text/html; charset="us-ascii" > > > > Approved: Dob.ipsec > > >From majordomo-owner Mon Aug 26 12:48:30 2002 > > Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [19 > >2.94.214.100]) > > by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id MAA27390 > > Mon, 26 Aug 2002 12:48:30 -0400 (EDT) > > Received: by sentry.gw.tislabs.com; id NAA10536; Mon, 26 Aug 2002 13:03:08 -0 > >400 (EDT) > > Received: from zcars04e.nortelnetworks.com(47.129.242.56) by sentry.gw.tislab > >s.com via smap (V5.5) > > id xma010528; Mon, 26 Aug 02 17:02:28 GMT > > Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69] > >) > > by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g > >7QH2eb11285; > > Mon, 26 Aug 2002 13:02:40 -0400 (EDT) > > Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) > > id ; Mon, 26 Aug 2002 13:02:44 -0400 > > Message-ID: <4D79C746863DD51197690002A52CDA00029BD8D1@zcard0kc.ca.nortel.com> > > From: "Marc Desrosiers" > > To: "'Radia Perlman - Boston Center for Networking'" , > > ipsec@lists.tislabs.com > > Subject: RE: Avoiding tricking IKE v2 nodes into talking v1 > > Date: Mon, 26 Aug 2002 13:02:36 -0400 > > MIME-Version: 1.0 > > X-Mailer: Internet Mail Service (5.5.2653.19) > > Content-Type: multipart/alternative; > > boundary="----_=_NextPart_001_01C24D21.DCB83256" > > > > 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_01C24D21.DCB83256 > > Content-Type: text/plain; > > charset="iso-8859-1" > > > > It is an great idea to have the ability to state what version you are > > capable of supporting, I would suggest extending the concept to a byte level > > to provide the ability to state what other method you can support for key > > management to accommodate things like KINK, PF_KEY, others. Why limit > > ourselves... > > > > Marc DesRosiers > > > > -----Original Message----- > > From: Radia Perlman - Boston Center for Networking > > [mailto:Radia.Perlman@sun.com] > > Sent: Saturday, August 24, 2002 9:19 PM > > To: ipsec@lists.tislabs.com > > Subject: Avoiding tricking IKE v2 nodes into talking v1 > > > > > > In IKEv2, we were careful to specify how to safely negotiate > > new versions in the future. There's a bit in v2 saying "I could be > > speaking a higher version number". That way if two version 3 nodes > > are attempting to talk, and an attacker (or Maxwell) throws away the > > version 3 messages, and the nodes try to talk version 2 instead, > > they will know they could be speaking a higher version, and try again > > with version 3. > > > > But since the IKEv1 spec didn't have any such bit, we assumed there > > was nothing we could do about the possibility of two v2 nodes being > > tricked into talking v1. But then I noticed the feature in SSL > > that cleverly manages to have SSLv3 nodes talk SSLv2, but recognize > > that they could be speaking v3, in a way that didn't require any > > modifications to v2 (it's amazingly cute how they do it). > > > > Inspired by SSL, it seems like it might be nice to find some hack > > so that IKE version 2 capable nodes won't get tricked into talking IKEv1. > > Currently the v2 spec says that you try to talk v2, and if you don't > > get a response, you try talking v1. > > > > The IKEv1 spec is not very explicit about things like how to handle > > receipt of nonzero reserved bits (it says "must be zero", > > but doesn't say "must be ignored upon receipt"). Otherwise, we could > > use a reserved bit in IKEv1 similar to what we defined in IKEv2. > > > > But given that it looks like it might be dangerous to fool with reserved > > bits in v1, is there some other method that would be guaranteed not to > > upset any current implementations? > > > > One thing I could imagine is defining a dummy crypto algorithm. When > > the initiator proposes that algorithm, it means "I'm sending you v1 messages > > since you didn't answer my v2 messages, but I am capable of speaking > > v2". If Bob speaks v2 and gets an IKE_SA_init from Alice with that > > dummy crypto algorithm, I'd suggest that Bob should choose that dummy > > crypto algorithm, which tells Alice "let's start over with v2". Alice > > then should abort the v1 IKE, and start up again with a v2 IKE. > > > > What do people think? Is there a more elegant way of doing this? > > Is it not worth the work? > > > > Also, while I'm asking...would any IKEv1 implementations crash or > > do something possibly even worse if they receive an version 2 IKE_SA_init? > > I assume they either reject or ignore such messages, because otherwise > > it would be a trivial denial of service attack on IKEv1. > > > > Radia > > > > > > ------_=_NextPart_001_01C24D21.DCB83256 > > Content-Type: text/html; > > charset="iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > > > > > > RE: Avoiding tricking IKE v2 nodes into talking v1 > > > > It is an great idea to have the ability to state what = version you are capab > >le of supporting, I would suggest extending the = concept to a byte level to p > >rovide the ability to state what other = method you can support for key manage > >ment to accommodate things like = KINK, PF_KEY, others. Why limit ourselves... > > > > Marc DesRosiers > > > > -----Original Message----- > > From: Radia Perlman - Boston Center for = Networking > > [<3d.htm>mailto:Radia.Perlman@sun.com]<= /FONT> > > Sent: Saturday, August 24, 2002 9:19 PM > > To: ipsec@lists.tislabs.com > > Subject: Avoiding tricking IKE v2 nodes into talking = v1 > > > > In IKEv2, we were careful to specify how to safely = negotiate > > new versions in the future. There's a bit in v2 = saying "I could be > > speaking a higher version number". That way if = two version 3 nodes > > are attempting to talk, and an attacker (or Maxwell) = throws away the > > version 3 messages, and the nodes try to talk = version 2 instead, > > they will know they could be speaking a higher = version, and try again > > with version 3. > > > > But since the IKEv1 spec didn't have any such bit, we = assumed there > > was nothing we could do about the possibility of two = v2 nodes being > > tricked into talking v1. But then I noticed the = feature in SSL > > that cleverly manages to have SSLv3 nodes talk = SSLv2, but recognize > > that they could be speaking v3, in a way that didn't = require any > > modifications to v2 (it's amazingly cute how they do = it). > > > > Inspired by SSL, it seems like it might be nice to = find some hack > > so that IKE version 2 capable nodes won't get = tricked into talking IKEv1. > > Currently the v2 spec says that you try to talk v2, = and if you don't > > get a response, you try talking v1. > > > > The IKEv1 spec is not very explicit about things like = how to handle > > receipt of nonzero reserved bits (it says "must = be zero", > > but doesn't say "must be ignored upon = receipt"). Otherwise, we could > > use a reserved bit in IKEv1 similar to what we = defined in IKEv2. > > > > But given that it looks like it might be dangerous to = fool with reserved > > bits in v1, is there some other method that would be = guaranteed not to > > upset any current implementations? > > > > One thing I could imagine is defining a dummy crypto = algorithm. When > > the initiator proposes that algorithm, it means = "I'm sending you v1 message > >s > > since you didn't answer my v2 messages, but I am = capable of speaking > > v2". If Bob speaks v2 and gets an IKE_SA_init = from Alice with that > > dummy crypto algorithm, I'd suggest that Bob should = choose that dummy > > crypto algorithm, which tells Alice "let's = start over with v2". Alice > > then should abort the v1 IKE, and start up again = with a v2 IKE. > > > > What do people think? Is there a more elegant way of = doing this? > > Is it not worth the work? > > > > Also, while I'm asking...would any IKEv1 = implementations crash or > > do something possibly even worse if they receive an = version 2 IKE_SA_init? > > I assume they either reject or ignore such messages, = because otherwise > > it would be a trivial denial of service attack on = IKEv1. > > > > Radia > > ------_=_NextPart_001_01C24D21.DCB83256-- > > > > --=====================_449718591==_.ALT-- > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Mon Aug 26 13:06: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 g7QK6f209304; Mon, 26 Aug 2002 13:06:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA28233 Mon, 26 Aug 2002 15:22:36 -0400 (EDT) Date: Mon, 26 Aug 2002 12:36:57 -0700 (PDT) From: Jan Vilhuber To: Paul Koning cc: , , Subject: Re: Avoiding tricking IKE v2 nodes into talking v1 In-Reply-To: <15722.33383.135931.269027@pkoning.dev.equallogic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 26 Aug 2002, Paul Koning wrote: > >>>>> "Jan" == Jan Vilhuber writes: > > Jan> On Mon, 26 Aug 2002, Paul Koning wrote: > >> But vendor ID payloads don't announce any protocol action, they > >> only set a namespace for subsequent private payloads. You can > >> only have one at a time > > Jan> Where does it say this? I see no reason why you couldn't have 15 > Jan> vendor-id payloads in message 5 or 6 (or anywhere else for that > Jan> matter). > > Jan> Also, I don't see why a vendor-id is narrowly defined as "set a > Jan> namespace for subsequent private payloads" (unless I missed a > Jan> section in the IKE spec). I see them as announcing any > Jan> capability you like, with or without additional private > Jan> payloads. > > Ok, that's what I get for relying on memory rather than re-reading the > words line by line... :-( > > Yes, it does say you can have more than one. When you do that, it > isn't clear to me which namespace then applies to the private payload > numbers. (The one immediately preceding it in the bytestream???) > Yes, you're absolutely right. But if all you are announcing is 'capability' rather than needing more payloads, you should be OK. I agree it's suboptimal. I've never liked the vendor-id for that reason (and one of these days I'll actually write up my counter- proposal based on the radius vendor-specific attribute)... > The spec does say that the payload announces an instance of an > implementation, which isn't the same thing as announcing a request for > a feature or action. But I suppose it's reasonable enough to stretch > it that far. > Modulo the namespace confusion, as you point out. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Mon Aug 26 13: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 g7QK8J209355; Mon, 26 Aug 2002 13:08:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA28186 Mon, 26 Aug 2002 15:18:22 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15722.33383.135931.269027@pkoning.dev.equallogic.com> Date: Mon, 26 Aug 2002 15:32:55 -0400 From: Paul Koning To: vilhuber@cisco.com Cc: dharkins@tibernian.com, Radia.Perlman@sun.com, ipsec@lists.tislabs.com Subject: Re: Avoiding tricking IKE v2 nodes into talking v1 References: <15722.31581.257104.413889@pkoning.dev.equallogic.com> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Jan" == Jan Vilhuber writes: Jan> On Mon, 26 Aug 2002, Paul Koning wrote: >> But vendor ID payloads don't announce any protocol action, they >> only set a namespace for subsequent private payloads. You can >> only have one at a time Jan> Where does it say this? I see no reason why you couldn't have 15 Jan> vendor-id payloads in message 5 or 6 (or anywhere else for that Jan> matter). Jan> Also, I don't see why a vendor-id is narrowly defined as "set a Jan> namespace for subsequent private payloads" (unless I missed a Jan> section in the IKE spec). I see them as announcing any Jan> capability you like, with or without additional private Jan> payloads. Ok, that's what I get for relying on memory rather than re-reading the words line by line... :-( Yes, it does say you can have more than one. When you do that, it isn't clear to me which namespace then applies to the private payload numbers. (The one immediately preceding it in the bytestream???) The spec does say that the payload announces an instance of an implementation, which isn't the same thing as announcing a request for a feature or action. But I suppose it's reasonable enough to stretch it that far. paul From owner-ipsec@lists.tislabs.com Mon Aug 26 13:50: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 g7QKoF210466; Mon, 26 Aug 2002 13:50:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28469 Mon, 26 Aug 2002 16:05:32 -0400 (EDT) Date: Mon, 26 Aug 2002 23:20:26 +0300 (FLE Daylight Time) From: Arne Ansper To: Stephen Kent cc: Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: Message-ID: X-X-Sender: arne@kiku.itsise MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-info: Headers changed by Barricade Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > assembler instructions. 4 blocks are encrypted at the same time. using CBC > mode we can use this optimization only for encryption. using CTR mode we > can use this optimization for decryption too. small correction. of course it's decryption that we can speed up, not encryption. arne From owner-ipsec@lists.tislabs.com Mon Aug 26 13:58: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 g7QKwi210765; Mon, 26 Aug 2002 13:58:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28539 Mon, 26 Aug 2002 16:16:42 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <15722.33383.135931.269027@pkoning.dev.equallogic.com> References: <15722.31581.257104.413889@pkoning.dev.equallogic.com> <15722.33383.135931.269027@pkoning.dev.equallogic.com> Date: Mon, 26 Aug 2002 13:30:34 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Avoiding tricking IKE v2 nodes into talking v1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:32 PM -0400 8/26/02, Paul Koning wrote: >Yes, it does say you can have more than one. And there are lots of implementations that send out more than one in a message. In our interop tests so far, no implementation has had a problem with receiving more than one vendor ID. (And, yes, that's all public information, including the Vendor ID payloads that various implementations are passing.) --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Aug 26 15:16: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 g7QMGp212710; Mon, 26 Aug 2002 15:16:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA28810 Mon, 26 Aug 2002 17:30:22 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 26 Aug 2002 17:40:09 -0400 To: Arne Ansper 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 At 5:06 PM +0300 8/26/02, Arne Ansper wrote: > > I don't think we can say that CTR mode is easier to implement in >> software than CBC mode. CTR mode probably isn't any faster than CBC, >> in general, in software, since software can't generally take >> advantage of the pipelining or parallelism. > >yes it can. > >for example, we have implemented IDEA and Rijandel using Pentium MMX >assembler instructions. 4 blocks are encrypted at the same time. using CBC >mode we can use this optimization only for encryption. using CTR mode we >can use this optimization for decryption too. I was puzzled until I saw your corrected message :-)! yes, parallel decryption (though not encryption) is possible for CBC mode. Good point about the ability to take advantage of parallelism of some instruction sets in general purpose PCs! long ago I coded DES for a Cray and was amazed how one could take advantage of the 64-bit wide registers and the well-advertised pipelining features of the multiple executing units. >another idea: one can use the CTR mode to reduce the latency of the >encryption process. you can use the idle CPU cycles for producing the >encrypted stream of bytes. when the packet arrives you can just XOR it >with precomputed data. this way, you can use the spare memory to decrese >the latency of your device. you cannot do this with CBC mode. Yes, CTR mode, or any stream cipher mode without feedback, e.g., OFB mode, can precompute keystream and thus reduce delay. This can be done for both transmitter and receiver IF the kesyteam generation algorithm uses values that both transmitter and receiver know in advance. There are various contexts in which this is useful, although it may not be practical in the general IPsec context, where the number of SAs might be large and packet loss of out of order arrival might negate the advantage of precomputation. However, Russ Housley pointed out to me that in 602.11 nets, communication is typically between each PC and the station, not peer-to-peer, and out of order delivery is not likely, although packet loss may occur. A PC can precompute keystream for the pair of "SAs" it has with the station since the number of associations is so small. A station needs more memory and horsepower to be able to take advantage of this opportunity, but it may be feasible there too. Paul Hoffman noted that these optimizations also may apply in the iSCSI context, where per-node SA fan out is likely to be very low. >when you use only CTR mode, you don't need decryption routines :) helps to >save couple of kilobytes of code memory. True, but also true for OFB and CFB, i.e., any mode in which the base algorithm is used as a keystream generator at both ends. Steve From owner-ipsec@lists.tislabs.com Tue Aug 27 01:26: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 g7R8Q4204430; Tue, 27 Aug 2002 01:26:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA00047 Tue, 27 Aug 2002 03:25:46 -0400 (EDT) Date: Tue, 27 Aug 2002 09:35:57 +0200 From: Jean-Jacques Puig To: Dan Harkins Cc: Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com Subject: Re: Avoiding tricking IKE v2 nodes into talking v1 Message-ID: <20020827073557.GA23388@charlie.int-evry.fr> References: <200208250119.g7P1JNL26857@sydney.East.Sun.COM> <200208261700.g7QH0cIn000340@fatty.lounge.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200208261700.g7QH0cIn000340@fatty.lounge.org> User-Agent: Mutt/1.3.28i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, On Mon, Aug 26, 2002 at 10:00:38AM -0700, Dan Harkins wrote: > The complaint about IKEv1 is that it is too complex and hard to > understand, not that it is insecure. So I don't see falling back > to IKEv1 as a real problem. > > If something really has to be done I suggest we come up with an > IKEv1 "vendor ID" payload that says something like "I can actually > speak a higher version of IKE". This payload would be sent in the > 5th and 6th message in Main Mode or the 2nd and 3rd in Aggressive > Mode. Most implementations can handle "vendor ID" payloads in these > parts of the exchanges. I wonder if the use Notification Payload (ISAKMP - 3.14) with a new Notify Message Type (some values were kept for future use) would work also. Is this payload in use in IKEv1 ? Or is it not related to IKEv1 ? > > Regarding your question about an IKEv1 implementation that crashes > or worse if they receive an IKEv2 IKE_SA_init message, while the > IKEv1 spec does not proscribe such behavior it also doesn't explicitly > prohibit it (another area in which it is vague) but I'd argue that > any implementation that crashed (or worse) for any reason is broken. > There was a very popular IP stack that used to crash when it received > the "Christmas Tree" packet (all options, lights, bells and whistles > turned on). That wasn't a problem with IP, it was a problem with that > implementation. Similarly with IKEv1, if it crashes upon receipt of > unexpected input it's not a problem with the protocol it's a problem > with the implementation. Crashing is obviously an implementation issue. Though developers may expect protocols designers to be explicits enough on the behavior of the protocol or to kindly give information of a failback behavior. I think implementing IKEv1 is a nightmare, and 'out of the norm' protocol behaviors are here quite likely to produce unexpected results. -- Jean-Jacques Puig From owner-ipsec@lists.tislabs.com Tue Aug 27 10:03: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 g7RH3Z210813; Tue, 27 Aug 2002 10:03:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01004 Tue, 27 Aug 2002 12:02:52 -0400 (EDT) Message-Id: <3.0.3.32.20020823125836.014123d8@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 23 Aug 2002 12:58:36 -0700 To: Stephen Kent , ipsec@lists.tislabs.com From: Alex Alten Subject: Re: a lengthy analysis of counter mode and ESP In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, I liked this analysis. Well written, I learned something from it. Maybe you should submit this as an informational RFC. - Alex At 02:23 PM 8/16/2002 -0400, Stephen Kent wrote: > Hopefully, the WG as a whole will better understand the issues and be >better positioned to make choices as a result of this analysis. > > Steve > ---------- -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Tue Aug 27 15:05: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 g7RM5e200360; Tue, 27 Aug 2002 15:05:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01464 Tue, 27 Aug 2002 17:17:22 -0400 (EDT) From: "Housley, Russ" To: Stephen Kent Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020827165406.03057820@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 27 Aug 2002 16:56:59 -0400 Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: References: <200208241923.g7OJNBZf001129@marajade.sandelman.ottawa.on.ca> <200208241923.g7OJNBZf001129@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve: I disagree. AES-CTR only uses the AES encrypt operation for both packet encryption and decryption. Since AES encrypt and AES decrypt are quite different, unlike DES where they were nearly identical, there can be a considerable savings in code size and development time for AES-CTR since AES-CBC used both AES encrypt and decrypt operations. Russ At 08:40 AM 8/26/2002 -0400, Stephen Kent wrote: >At 3:23 PM -0400 8/24/02, Michael Richardson wrote: >>-----BEGIN PGP SIGNED MESSAGE----- >> >> >>>>>>> "Alex" == Alex Alten writes: >> >> Anyone who *needs* AES-CTR mode, likely needs it because they have >> >> >1Gb/s links they want to secure. As such, I think that they have the >> >> bandwidth not to care. >> >> Alex> Micahael, >> >> Alex> Are you implying that AES-CTR on a modern Intel CPU can handle >> more >> Alex> than 1 Gb/s Ethernet? Is this because the IV stays in L1 cache? >> >> I'm not making any claim about hardware or software implementations. >>My understanding is that AES-CTR mode is implemented more cheaply >>than AES-CBC mode. Whether this is hardware or software is simply a question >>of what year it is. > >I don't think we can say that CTR mode is easier to implement in software >than CBC mode. CTR mode probably isn't any faster than CBC, in general, in >software, since software can't generally take advantage of the pipelining >or parallelism. > >Steve From owner-ipsec@lists.tislabs.com Tue Aug 27 19:07: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 g7S27e213233; Tue, 27 Aug 2002 19:07:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01848 Tue, 27 Aug 2002 20:20:06 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <5.1.0.14.2.20020827165406.03057820@exna07.securitydynamics.com> References: <200208241923.g7OJNBZf001129@marajade.sandelman.ottawa.on.ca> <200208241923.g7OJNBZf001129@marajade.sandelman.ottawa.on.ca> <5.1.0.14.2.20020827165406.03057820@exna07.securitydynamics.com> Date: Tue, 27 Aug 2002 20:34:44 -0400 To: "Housley, Russ" From: Stephen Kent Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:56 PM -0400 8/27/02, Housley, Russ wrote: >Steve: > >I disagree. AES-CTR only uses the AES encrypt operation for both >packet encryption and decryption. Since AES encrypt and AES decrypt >are quite different, unlike DES where they were nearly identical, >there can be a considerable savings in code size and development >time for AES-CTR since AES-CBC used both AES encrypt and decrypt >operations. > >Russ > Russ, Yes, that point has been made and I concur that, relative to CBC, a CTR or an OFB mode implementation is simpler because only the encrypt operation needs be created. I doubt that this will be an issue in the IPsec context, unless we mandate ONLY CTR, since modes like CBC do require both encrypt and decrypt codebooks, but your point is correct. Steve From owner-ipsec@lists.tislabs.com Tue Aug 27 21:26: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 g7S4QM218532; Tue, 27 Aug 2002 21:26:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA02108 Tue, 27 Aug 2002 23:42:54 -0400 (EDT) Date: Tue, 27 Aug 2002 21:55:59 -0600 Message-Id: <200208280355.g7S3txf06032@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rhousley@rsasecurity.com Cc: kent@bbn.com, ipsec@lists.tislabs.com In-reply-to: Yourmessage <5.1.0.14.2.20020827165406.03057820@exna07.securitydynamics.com> Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt Sender: owner-ipsec@lists.tislabs.com Precedence: bulk AES decryption isn't all that different from encryption; the algorithm has only a minor difference and the rest is in tables. Shouldn't really make any noticeable difference in code size or development time. Hilarie In due time, on Tue, 27 Aug 2002 at 16:56:59 -0400 Housley, Russ asserted: > Steve: > I disagree. AES-CTR only uses the AES encrypt operation for both packet > encryption and decryption. Since AES encrypt and AES decrypt are quite > different, unlike DES where they were nearly identical, there can be a > considerable savings in code size and development time for AES-CTR since > AES-CBC used both AES encrypt and decrypt operations. > Russ > At 08:40 AM 8/26/2002 -0400, Stephen Kent wrote: > >At 3:23 PM -0400 8/24/02, Michael Richardson wrote: > >>-----BEGIN PGP SIGNED MESSAGE----- > >> > >> > >>>>>>> "Alex" == Alex Alten writes: > >> >> Anyone who *needs* AES-CTR mode, likely needs it because they have > >> >> >1Gb/s links they want to secure. As such, I think that they have the > >> >> bandwidth not to care. > >> > >> Alex> Micahael, > >> > >> Alex> Are you implying that AES-CTR on a modern Intel CPU can handle > >> more > >> Alex> than 1 Gb/s Ethernet? Is this because the IV stays in L1 cache? > >> > >> I'm not making any claim about hardware or software implementations. > >>My understanding is that AES-CTR mode is implemented more cheaply > >>than AES-CBC mode. Whether this is hardware or software is simply a question > >>of what year it is. > > > >I don't think we can say that CTR mode is easier to implement in software > >than CBC mode. CTR mode probably isn't any faster than CBC, in general, in > >software, since software can't generally take advantage of the pipelining > >or parallelism. > > > >Steve From owner-ipsec@lists.tislabs.com Wed Aug 28 07:48: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 g7SEmJ210258; Wed, 28 Aug 2002 07:48:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03305 Wed, 28 Aug 2002 09:54:01 -0400 (EDT) Message-Id: <200208271844.OAA06546@ietf.org> From: Phil Roberts To: "IETF.WG.Participants":;;;;@tislabs.com;;; Subject: Nomcom call for volunteers Date: Tue, 27 Aug 2002 14:44:44 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. From owner-ipsec@lists.tislabs.com Wed Aug 28 08:39: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 g7SFd4213859; Wed, 28 Aug 2002 08:39:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03486 Wed, 28 Aug 2002 10:55:43 -0400 (EDT) Message-Id: <5.0.2.1.0.20020828104614.05041eb8@mail.ccs.neu.edu> X-Sender: noubir@mail.ccs.neu.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 28 Aug 2002 10:49:53 -0400 To: mobile-ip@sunroof.eng.sun.com, ipsec@lists.tislabs.com From: "G. Noubir" Subject: Wireless Security workshop -- advance registration deadline soon [August 31] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Advance registration deadline soon (visit http://www.crhc.uiuc.edu/~nhv/wise for more information) --------------------------------------------------------------- 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.) Session Chair: David B. Johnson (Rice University) Securing Ad-Hoc Routing Protocols, Manel Guerrero Zapata and N. Asokan (Nokia Research Center, Finland) Self-Organized Network Layer Security in Mobile Ad Hoc Networks, Hao Yang, Xiaoqiao Meng and Songwu Lu (University of California at Los Angeles) An On-Demand Secure Routing Protocol Resilent to Byzantine Failures, Baruch Awerbuch, David Holmer, Cristina Nita-Rotaru and Herbert Rubens (Johns Hopkins University) -------------------------------------------------------------------------------- Poster Session (10:15 - 11:15 a.m.) Self-Organized Public-Key Management in Ad Hoc Wireless Networks, S. Capkun, L. Buttyan and J.-P. Hubaux (Swiss Federal Institute of Technology - Lausanne) Providing Multi-Layer Security Support for Wireless Communications Across Multiple Domains, J. Kong, M. Gerla, R. Gadh, B. S. Prahbu (University of California, Los Angeles) Reflection: Secure, Lightweight Wireless Network Administration, J. W. Mickens, B. D. Noble, A. J. Lanzone, K.-Y. Tye (University of Michigan, Ann Arbor) Risk Based Probabilistic Routing for Ad-Hoc Networks, Z. Yu, T. Jiang, X. Wu and W. A. Arbaugh (University of Maryland, College Park) Performance Evaluation of Secure Routing for Mobile Ad Hoc Networks, P. Papadimitratos and Z. J. Haas (Cornell University) Security Protocol for Charging and Participation Incentive in Ad Hoc Stub Network, B. Lamparter, K. Paul, D. Westhoff (NEC Europe Ltd.) -------------------------------------------------------------------------------- Invited Presentations (11:15 a.m. - 12:15 p.m.) Session Chair: Brian Van Leeuwen (Sandia National Laboratories) Information Assurance and Research Opportunities, Douglas Maughan, Defence Advanced Research Projects Agency Perspectives on Wireless Security, Taieb Znati, National Science Foundation and University of Pittsburgh -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Paper Session 2 (1:30 - 3:00 p.m.) Session Chair: Chip Elliott (BBN Technologies) Survivable Mobile Wireless Networks: Issues, Challenges, and Research Directions, Rajesh Krishnan, Regina Rosales Hain, Alden W. Jackson, David Levin, Ram Ramanathan, John Zao and James P. G. Sterbenz (BBN Technologies) Secure Wireless Gateway, Austin Godber and Partha Dasgupta (Arizona State University) DoS and Authentication in Wireless Public Access Networks, Daniel B. Faria and David R. Cheriton (Stanford University) -------------------------------------------------------------------------------- Paper Session 3 (3:30 - 5:30 p.m.) Session Chair: Yair Amir (Johns Hopkins University) A Distributed Monitoring Mechanism in Wireless Sensor Networks, Chih-fan Hsin and Mingyan Liu (University of Michigan at Ann Arbor) Using Signal Processing to Analyze Wireless Data Traffic, Craig Partridge, David Cousins, Alden W. Jackson, Rajesh Krishnan, Tushar Saxena, and W. Timothy Strayer (BBN Technologies) Securing IPv6 Neighor Discovery, Jari Arkko (Ericsson Research NomadicLab), Tuomas Aura (Microsoft Research Cambridge), James Kempf (DoCoMoLabs U.S.A.), Vesa-Matti Mantyla, Pekka Nikander (Ericsson Research NomadicLab) and Michael Roe (Microsoft Research Cambridge) Performance Analysis of Elliptic Curve Cryptography for SSL, Vipul Gupta, Sumit Gupta, Sheueling Chang and Douglas Stebila (Sun Microsystems) -------------------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Wed Aug 28 08:52: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 g7SFqv214955; Wed, 28 Aug 2002 08:52:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03516 Wed, 28 Aug 2002 11:07:49 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <200208250119.g7P1JNL26857@sydney.East.Sun.COM> Subject: Re: Avoiding tricking IKE v2 nodes into talking v1 To: Radia Perlman - Boston Center for Networking Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_08092002NP August 09, 2002 Message-ID: Date: Tue, 27 Aug 2002 23:20:54 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_08262002NP|August 26, 2002) at 08/28/2002 11:16:46 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > One thing I could imagine is defining a dummy crypto algorithm. When > the initiator proposes that algorithm, it means "I'm sending you v1 messages > since you didn't answer my v2 messages, but I am capable of speaking > v2". If Bob speaks v2 and gets an IKE_SA_init from Alice with that > dummy crypto algorithm, I'd suggest that Bob should choose that dummy > crypto algorithm, which tells Alice "let's start over with v2". Alice > then should abort the v1 IKE, and start up again with a v2 IKE. I believe this would work. > If something really has to be done I suggest we come up with an > IKEv1 "vendor ID" payload that says something like "I can actually > speak a higher version of IKE". This payload would be sent in the > 5th and 6th message in Main Mode or the 2nd and 3rd in Aggressive > Mode. Most implementations can handle "vendor ID" payloads in these > parts of the exchanges. I believe this would not work. Using IKEv1 in aggressive mode (which as I understand it is what people actually use), vendor ID payloads are neither signed nor integrity protected. That means anyone clever enough to get in the middle to force a downgrade could also delete the vendor IDs undetected. > I wonder if the use Notification Payload (ISAKMP - 3.14) with a new > Notify Message Type (some values were kept for future use) would work > also. Is this payload in use in IKEv1 ? Or is it not related to IKEv1 ? I don't believe this would work either. In IKEv1, Notification is not reliable, so an attacker who deleted the Notify payloads would escape detection. > Regarding your question about an IKEv1 implementation that crashes > or worse if they receive an IKEv2 IKE_SA_init message, while the > IKEv1 spec does not proscribe such behavior it also doesn't explicitly > prohibit it (another area in which it is vague) but I'd argue that > any implementation that crashed (or worse) for any reason is broken. It's not a question of the spec; it's a question of buggy implementations (or even legal behavior that interacts badly with the new version). For example, an implementation that gets an ill-formed UDP packet on port 500 might conclude that it is under attack and refuse all traffic from the source IP address for 5 minutes. Probably not a wise thing to do, but I can see how someone might have thought it was a good idea. If an IKEv2 IKE-SA-init packet parses as bad and shuts the node off, that would argue for a bilingual implementation trying to negotiate IKEv1 first. If there were known buggy implementations that crashed on certain invalid inputs, it's their fault, but we would be rude to specify such a format in IKEv2. Unfortunately, I suspect there is no way to detect such things except by testing, and by then it will be too late. > The complaint about IKEv1 is that it is too complex and hard to > understand, not that it is insecure. So I don't see falling back > to IKEv1 as a real problem. That's true, and argues for ignoring the problem. This is one of those theoretical attacks that would rarely be useful, and the main argument for preventing it is that we can. The argument against is that it adds a couple more paragraphs to the spec, a little more code to every implementation, and risks messing up existing buggy implementations. I'd happily go either way (now I'm being the donkey). --charlie From owner-ipsec@lists.tislabs.com Wed Aug 28 10:53: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 g7SHr8224079; Wed, 28 Aug 2002 10:53:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03951 Wed, 28 Aug 2002 13:02:29 -0400 (EDT) Message-Id: <200208281717.g7SHHCwV030285@mail2.trpz.com> To: Charlie_Kaufman@notesdev.ibm.com cc: ipsec@lists.tislabs.com Subject: Re: Avoiding tricking IKE v2 nodes into talking v1 In-Reply-To: Your message of "Tue, 27 Aug 2002 23:20:54 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <560.1030554918.1@tibernian.com> Date: Wed, 28 Aug 2002 10:15:19 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 27 Aug 2002 23:20:54 EDT you wrote > > > One thing I could imagine is defining a dummy crypto algorithm. When > > the initiator proposes that algorithm, it means "I'm sending you v1 > messages > > since you didn't answer my v2 messages, but I am capable of speaking > > v2". If Bob speaks v2 and gets an IKE_SA_init from Alice with that > > dummy crypto algorithm, I'd suggest that Bob should choose that dummy > > crypto algorithm, which tells Alice "let's start over with v2". Alice > > then should abort the v1 IKE, and start up again with a v2 IKE. > > I believe this would work. > > > If something really has to be done I suggest we come up with an > > IKEv1 "vendor ID" payload that says something like "I can actually > > speak a higher version of IKE". This payload would be sent in the > > 5th and 6th message in Main Mode or the 2nd and 3rd in Aggressive > > Mode. Most implementations can handle "vendor ID" payloads in these > > parts of the exchanges. > > I believe this would not work. Using IKEv1 in aggressive mode (which as I > understand it is what people actually use), vendor ID payloads are neither > signed nor integrity protected. That means anyone clever enough to get in > the middle to force a downgrade could also delete the vendor IDs > undetected. Good point. I actually think that what people actually use is Main Mode but if it won't work in both then it isn't a solution. > > I wonder if the use Notification Payload (ISAKMP - 3.14) with a new > > Notify Message Type (some values were kept for future use) would work > > also. Is this payload in use in IKEv1 ? Or is it not related to IKEv1 ? > > I don't believe this would work either. In IKEv1, Notification is not > reliable, so an attacker who deleted the Notify payloads would escape > detection. > > > Regarding your question about an IKEv1 implementation that crashes > > or worse if they receive an IKEv2 IKE_SA_init message, while the > > IKEv1 spec does not proscribe such behavior it also doesn't explicitly > > prohibit it (another area in which it is vague) but I'd argue that > > any implementation that crashed (or worse) for any reason is broken. > > It's not a question of the spec; it's a question of buggy implementations > (or even legal behavior that interacts badly with the new version). For > example, an implementation that gets an ill-formed UDP packet on port > 500 might conclude that it is under attack and refuse all traffic from > the source IP address for 5 minutes. Probably not a wise thing to do, > but I can see how someone might have thought it was a good idea. If an > IKEv2 IKE-SA-init packet parses as bad and shuts the node off, that would > argue for a bilingual implementation trying to negotiate IKEv1 first. > If there were known buggy implementations that crashed on certain > invalid inputs, it's their fault, but we would be rude to specify such > a format in IKEv2. Unfortunately, I suspect there is no way to detect > such things except by testing, and by then it will be too late. I cannot see an argument for a bilingual implementation to negotiate IKEv1 first because there might be some broken code out there that does something that is not specified in IKEv1 and you admit is unwise. People that do unwise things that are also not required/recommended/otherwise in the spec should be put into the position of fixing their code. But now that we're into "what if"s: What if an implementation refuses negotiation when it receives a crypto algorithm it does not understand? That too is not a wise thing to do but I can see how someone might've thought that was a good idea. In fact, I saw it happen at a bakeoff. Since the vendor ID thing won't work another solution to this (if a solution is necessary) is to say that when an IKEv2 capable implementation speaks IKEv1 that the nonce it produces have a recognizable pattern in first N bits. If an IKEv2 capable implementation was speaking IKEv1 and the nonce it received from the peer had the proscribed pattern the attack would be detected. The nonce can be 8-256 bytes in IKEv1 so there is plenty of room to have both a fixed pattern and some randomness. This is sort of like the cute solution Radia was talking about in SSL. Of course, there are those implementations out there that crash when they receive a nonce whose length is greater than 20 bytes.... Dan. From owner-ipsec@lists.tislabs.com Wed Aug 28 18:28: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 g7T1S4217875; Wed, 28 Aug 2002 18:28:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA04736 Wed, 28 Aug 2002 20:32:56 -0400 (EDT) From: "Housley, Russ" To: "The Purple Streak, Hilarie Orman" Cc: ipsec@lists.tislabs.com Message-Id: <5.1.0.14.2.20020828203948.0352cf40@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 28 Aug 2002 20:41:48 -0400 Subject: Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt In-Reply-To: <200208280355.g7S3txf06032@localhost.localdomain> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hilarie: Some people that have done implementations tell me otherwise. Since I do not have firsthand experience, I will let them speak for themselves (if they are on this list). Russ At 09:55 PM 8/27/2002 -0600, The Purple Streak, Hilarie Orman wrote: >AES decryption isn't all that different from encryption; the algorithm >has only a minor difference and the rest is in tables. Shouldn't >really make any noticeable difference in code size or development time. > >Hilarie > >In due time, on Tue, 27 Aug 2002 at 16:56:59 -0400 Housley, Russ >asserted: > > > Steve: > > > I disagree. AES-CTR only uses the AES encrypt operation for both packet > > encryption and decryption. Since AES encrypt and AES decrypt are quite > > different, unlike DES where they were nearly identical, there can be a > > considerable savings in code size and development time for AES-CTR since > > AES-CBC used both AES encrypt and decrypt operations. > > > Russ > > > At 08:40 AM 8/26/2002 -0400, Stephen Kent wrote: > > >At 3:23 PM -0400 8/24/02, Michael Richardson wrote: > > >>-----BEGIN PGP SIGNED MESSAGE----- > > >> > > >> > > >>>>>>> "Alex" == Alex Alten writes: > > >> >> Anyone who *needs* AES-CTR mode, likely needs it because > they have > > >> >> >1Gb/s links they want to secure. As such, I think that they > have the > > >> >> bandwidth not to care. > > >> > > >> Alex> Micahael, > > >> > > >> Alex> Are you implying that AES-CTR on a modern Intel CPU can > handle > > >> more > > >> Alex> than 1 Gb/s Ethernet? Is this because the IV stays in L1 > cache? > > >> > > >> I'm not making any claim about hardware or software implementations. > > >>My understanding is that AES-CTR mode is implemented more cheaply > > >>than AES-CBC mode. Whether this is hardware or software is simply a > question > > >>of what year it is. > > > > > >I don't think we can say that CTR mode is easier to implement in > software > > >than CBC mode. CTR mode probably isn't any faster than CBC, in > general, in > > >software, since software can't generally take advantage of the > pipelining > > >or parallelism. > > > > > >Steve From owner-ipsec@lists.tislabs.com Thu Aug 29 08:07: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 g7TF7q217225; Thu, 29 Aug 2002 08:07:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12797 Thu, 29 Aug 2002 10:15:53 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: Last ditch proposal for crypto suites To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_08272002NP August 27, 2002 Message-ID: Date: Wed, 28 Aug 2002 23:19:04 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_08272002NP|August 27, 2002) at 08/29/2002 10:24:35 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The discussion of crypto suites vs. ala carte algorithm negotiation in IKEv2 was frustrating. I think most people like suites better (in the possibly unrealistic belief that we can keep the number of suites manageably small), but the advocates for ala carte negotiation were more adament about its necessity. I read the conclusion as leave the negotiation as it is (ala carte). The specification for SA proposal payload in the IKEv2 document is 9 pages long, and they are frightening pages. It was a message from Angelos Keromytis saying that it gave him a headache that inspired me to make one more last ditch proposal. There is a way to get the best of both worlds (and the worst of both worlds). The IKEv2 specification could specify how to negotiate suites and ala carte, where the suites are mandatory to implement and the ala carte negotiation is optional. If it turns out that the optimists are right and the number of suites actually implemented is small, the ala carte might not be implemented and could fade away. If the pessimists are right and ala carte was necessary, the ability to negotiate suites adds only minor complexity to the spec and to implementations. It's the worst of both worlds because it would make the spec longer and more complex. There might be a way to move the optional ala carte negotiation to an Appendix or something so that at least some people would ignore it and think the spec less intimidating. Some implementers would not implement it and simplify their lives. The suites would be more likely to pass interoperability testing more easily, since there are fewer things to get wrong. A concrete proposal: The SA payload contains a series of proposals. Each proposal has a fixed header and a variable length list of transforms. The fixed harder is eight bytes long - four of those bytes are Proposal #, Protocol-ID, SPI Size, and # of Transforms. Protocol-IDs are defined for IKE, ESP, AH, and IPcomp. I propose that we define a new Protocol-ID that means crypto suite, and that for that value the SPI Size and # of Transforms are replaced with a two byte suite number. The suite number would define the actual Protocol-ID, SPI Size, # of Transforms, and all of the Transforms and their attributes. The entire proposal would be 8 bytes for an IKE proposal, 12 bytes for an ESP or AH proposal (including 4 byte SPI), and 14 bytes for an ESP w/IPcomp proposal (including 4 byte ESP SPI and 2 byte IPcomp SPI). An implementation MUST recognise and be able to accept the mandatory suites, and must be able to skip over non-suite proposals if it chooses not to parse them. This would be relatively simple to code. What do you think? --Charlie Kaufman From owner-ipsec@lists.tislabs.com Thu Aug 29 08:44: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 g7TFiI219466; Thu, 29 Aug 2002 08:44:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12902 Thu, 29 Aug 2002 10:57:22 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869B84@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Charlie_Kaufman@notesdev.ibm.com'" , ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites Date: Thu, 29 Aug 2002 08:13:16 -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 There is another option, specify suites only for the IPSEC negotiation mechanism and leave a-la-carte to out of band negotiation. My experience with HTTP is that attempts to do in band negotiation over unrestricted sets fails miserably in the non-security context. Trying to do this and manage the threat of a downgrade attack is going to be worse. Are there real end users who want a la carte? Obviously the hoardes of itinerant cryptographers hawking their scheme of the week are going to be in favor of a mechanism that supports their scheme, but end users? My experience is that there is almost no variation in the cryptosuites in actual use: 3DES, SHA-1, RSA, HMAC. Obviously we anticipate the emergence of AES but I doubt that that will end up doing more than add an extra couple of options. One option and a pretty good one in my view is to say that if someone wants to have unlimited flexibility then they can negotiate it through IKEv1. In fact they can implement the full ISAKMP framework and negotiate the mechanism by which the negotiate the negotiation of the mechanism for negotiation of the algorithms to be selected for the cryptosuites to be used in negotiation. Let us never forget that the point of IKE2 is that we want to drain the damn swamp. Another option that would allow support for the itinerant cryptographic community would be to push the definition of the cryptosuites into the PKI. For example an OID in a certificate, descriptor record in the DNS, XKMS property etc. Phill > -----Original Message----- > From: Charlie_Kaufman@notesdev.ibm.com > [mailto:Charlie_Kaufman@notesdev.ibm.com] > Sent: Wednesday, August 28, 2002 11:19 PM > To: ipsec@lists.tislabs.com > Subject: Last ditch proposal for crypto suites > > > > > > > The discussion of crypto suites vs. ala carte algorithm negotiation in > IKEv2 was frustrating. I think most people like suites better (in the > possibly unrealistic belief that we can keep the number of suites > manageably small), but the advocates for ala carte > negotiation were more > adament about its necessity. I read the conclusion as leave > the negotiation > as it is (ala carte). The specification for SA proposal payload in the > IKEv2 document is 9 pages long, and they are frightening > pages. It was a > message from Angelos Keromytis saying that it gave him a headache that > inspired me to make one more last ditch proposal. > > There is a way to get the best of both worlds (and the worst of both > worlds). The IKEv2 specification could specify how to > negotiate suites and > ala carte, where the suites are mandatory to implement and > the ala carte > negotiation is optional. If it turns out that the optimists > are right and > the number of suites actually implemented is small, the ala > carte might not > be implemented and could fade away. If the pessimists are > right and ala > carte was necessary, the ability to negotiate suites adds only minor > complexity to the spec and to implementations. > > It's the worst of both worlds because it would make the spec > longer and > more complex. There might be a way to move the optional ala carte > negotiation to an Appendix or something so that at least some > people would > ignore it and think the spec less intimidating. Some > implementers would not > implement it and simplify their lives. The suites would be > more likely to > pass interoperability testing more easily, since there are > fewer things to > get wrong. > > A concrete proposal: > > The SA payload contains a series of proposals. Each proposal > has a fixed > header and a variable length list of transforms. The fixed harder is > eight bytes long - four of those bytes are Proposal #, > Protocol-ID, SPI > Size, and # of Transforms. Protocol-IDs are defined for IKE, > ESP, AH, and > IPcomp. I propose that we define a new Protocol-ID that means > crypto suite, > and that for that value the SPI Size and # of Transforms are > replaced with > a two byte suite number. The suite number would define the actual > Protocol-ID, SPI Size, # of Transforms, and all of the > Transforms and their > attributes. The entire proposal would be 8 bytes for an IKE > proposal, 12 > bytes for an ESP or AH proposal (including 4 byte SPI), and > 14 bytes for an > ESP w/IPcomp proposal (including 4 byte ESP SPI and 2 byte > IPcomp SPI). > > An implementation MUST recognise and be able to accept the mandatory > suites, and must be able to skip over non-suite proposals if > it chooses not > to parse them. This would be relatively simple to code. > > What do you think? > > --Charlie Kaufman > From owner-ipsec@lists.tislabs.com Thu Aug 29 09:06: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 g7TG6P220500; Thu, 29 Aug 2002 09:06:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12971 Thu, 29 Aug 2002 11:21:35 -0400 (EDT) Message-ID: <3D6E3D83.7070601@nortelnetworks.com> Date: Thu, 29 Aug 2002 11:28:03 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Before discussing suites vs. ala carte, I see the word *optional* cropping again. I believe it should be either-or, not both with one of them as optional. Suites are already part of another popular protocol, so we don't all need to implement them in IKEv2, to make the comparison. From what I understand from the concrete proposal below, a compliant implementation MUST recognize suites as well as ala carte proposals. How does this make life any easier for anyone? regards, Lakshminath PS: Do I hear a request for recount on this issue :-) ? Charlie_Kaufman@notesdev.ibm.com wrote: > > > > The discussion of crypto suites vs. ala carte algorithm negotiation in > IKEv2 was frustrating. I think most people like suites better (in the > possibly unrealistic belief that we can keep the number of suites > manageably small), but the advocates for ala carte negotiation were more > adament about its necessity. I read the conclusion as leave the negotiation > as it is (ala carte). The specification for SA proposal payload in the > IKEv2 document is 9 pages long, and they are frightening pages. It was a > message from Angelos Keromytis saying that it gave him a headache that > inspired me to make one more last ditch proposal. > > There is a way to get the best of both worlds (and the worst of both > worlds). The IKEv2 specification could specify how to negotiate suites and > ala carte, where the suites are mandatory to implement and the ala carte > negotiation is optional. If it turns out that the optimists are right and > the number of suites actually implemented is small, the ala carte might not > be implemented and could fade away. If the pessimists are right and ala > carte was necessary, the ability to negotiate suites adds only minor > complexity to the spec and to implementations. > > It's the worst of both worlds because it would make the spec longer and > more complex. There might be a way to move the optional ala carte > negotiation to an Appendix or something so that at least some people would > ignore it and think the spec less intimidating. Some implementers would not > implement it and simplify their lives. The suites would be more likely to > pass interoperability testing more easily, since there are fewer things to > get wrong. > > A concrete proposal: > > The SA payload contains a series of proposals. Each proposal has a fixed > header and a variable length list of transforms. The fixed harder is > eight bytes long - four of those bytes are Proposal #, Protocol-ID, SPI > Size, and # of Transforms. Protocol-IDs are defined for IKE, ESP, AH, and > IPcomp. I propose that we define a new Protocol-ID that means crypto suite, > and that for that value the SPI Size and # of Transforms are replaced with > a two byte suite number. The suite number would define the actual > Protocol-ID, SPI Size, # of Transforms, and all of the Transforms and their > attributes. The entire proposal would be 8 bytes for an IKE proposal, 12 > bytes for an ESP or AH proposal (including 4 byte SPI), and 14 bytes for an > ESP w/IPcomp proposal (including 4 byte ESP SPI and 2 byte IPcomp SPI). > > An implementation MUST recognise and be able to accept the mandatory > suites, and must be able to skip over non-suite proposals if it chooses not > to parse them. This would be relatively simple to code. > > What do you think? > > --Charlie Kaufman > > > From owner-ipsec@lists.tislabs.com Thu Aug 29 09:17: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 g7TGHX221415; Thu, 29 Aug 2002 09:17:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12989 Thu, 29 Aug 2002 11:29:38 -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 Subject: Re: Last ditch proposal for crypto suites Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Aug 2002 11:44:21 -0400 Message-Id: <20020829154421.281587B4C@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Charlie_Kaufman@notesdev.ibm.com writes: > > > > >The discussion of crypto suites vs. ala carte algorithm negotiation in >IKEv2 was frustrating. I think most people like suites better (in the >possibly unrealistic belief that we can keep the number of suites >manageably small), but the advocates for ala carte negotiation were more >adament about its necessity. You know my opinion -- scrap a la carte. But let me ask the question differently: Paul Hoffman, in your interoperability tests do you see many different combinations actually used? Or don't your tests go there? As for the specific suggestion -- I think I'd rather keep a la carte, rather than the hybrid suggestion. I fear the complexity, not just of having both sets of code, but also of being able to cope correctly with an offer or a response that specified one a la carte entry *and* one suite. I think the potential for bugs there is high. But if we want to go there, we need to specify precisely how to deal with the situation. In particular, we need to specify the rules on how to decide which to accept, and what to do if there is an apparent conflict in a response. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) From owner-ipsec@lists.tislabs.com Thu Aug 29 10:02: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 g7TH24224586; Thu, 29 Aug 2002 10:02:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13163 Thu, 29 Aug 2002 12:18:11 -0400 (EDT) Message-ID: <003701c24f79$fc3564f0$d8f22b42@mv.lucent.com> From: "David Faucher" To: , References: Subject: Re: Last ditch proposal for crypto suites Date: Thu, 29 Aug 2002 11:34:42 -0500 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk | | The discussion of crypto suites vs. ala carte algorithm negotiation in | IKEv2 was frustrating. I think most people like suites better (in the | possibly unrealistic belief that we can keep the number of suites | manageably small), but the advocates for ala carte negotiation were more | adament about its necessity. I read the conclusion as leave the negotiation | as it is (ala carte). The specification for SA proposal payload in the | IKEv2 document is 9 pages long, and they are frightening pages. It was a | message from Angelos Keromytis saying that it gave him a headache that | inspired me to make one more last ditch proposal. | Keep it simple, use suites. For those who think that a la carte is necessary, create a Vendor ID and use the private namespace. From owner-ipsec@lists.tislabs.com Thu Aug 29 10:06: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 g7TH68225006; Thu, 29 Aug 2002 10:06:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13191 Thu, 29 Aug 2002 12:22:14 -0400 (EDT) From: rcharlet@SonicWALL.com X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Last ditch proposal for crypto suites Date: Thu, 29 Aug 2002 09:36:05 -0700 Message-ID: Thread-Topic: Last ditch proposal for crypto suites Thread-Index: AcJPdXhfbsM+pZXdTT233UXVwBKjrAABEO0A To: , X-OriginalArrivalTime: 29 Aug 2002 16:36:28.0394 (UTC) FILETIME=[39316CA0:01C24F7A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA13188 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, What would happen if we have a MUST implement crypto suite that one day is shown to be no-longer trustworthy? -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Ricky Charlet rcharlet@sonicwall.com USA (408) 962-8711 -----Original Message----- From: Charlie_Kaufman@notesdev.ibm.com [mailto:Charlie_Kaufman@notesdev.ibm.com] Sent: Wednesday, August 28, 2002 8:19 PM To: ipsec@lists.tislabs.com Subject: Last ditch proposal for crypto suites The discussion of crypto suites vs. ala carte algorithm negotiation in IKEv2 was frustrating. I think most people like suites better (in the possibly unrealistic belief that we can keep the number of suites manageably small), but the advocates for ala carte negotiation were more adament about its necessity. I read the conclusion as leave the negotiation as it is (ala carte). The specification for SA proposal payload in the IKEv2 document is 9 pages long, and they are frightening pages. It was a message from Angelos Keromytis saying that it gave him a headache that inspired me to make one more last ditch proposal. There is a way to get the best of both worlds (and the worst of both worlds). The IKEv2 specification could specify how to negotiate suites and ala carte, where the suites are mandatory to implement and the ala carte negotiation is optional. If it turns out that the optimists are right and the number of suites actually implemented is small, the ala carte might not be implemented and could fade away. If the pessimists are right and ala carte was necessary, the ability to negotiate suites adds only minor complexity to the spec and to implementations. It's the worst of both worlds because it would make the spec longer and more complex. There might be a way to move the optional ala carte negotiation to an Appendix or something so that at least some people would ignore it and think the spec less intimidating. Some implementers would not implement it and simplify their lives. The suites would be more likely to pass interoperability testing more easily, since there are fewer things to get wrong. A concrete proposal: The SA payload contains a series of proposals. Each proposal has a fixed header and a variable length list of transforms. The fixed harder is eight bytes long - four of those bytes are Proposal #, Protocol-ID, SPI Size, and # of Transforms. Protocol-IDs are defined for IKE, ESP, AH, and IPcomp. I propose that we define a new Protocol-ID that means crypto suite, and that for that value the SPI Size and # of Transforms are replaced with a two byte suite number. The suite number would define the actual Protocol-ID, SPI Size, # of Transforms, and all of the Transforms and their attributes. The entire proposal would be 8 bytes for an IKE proposal, 12 bytes for an ESP or AH proposal (including 4 byte SPI), and 14 bytes for an ESP w/IPcomp proposal (including 4 byte ESP SPI and 2 byte IPcomp SPI). An implementation MUST recognise and be able to accept the mandatory suites, and must be able to skip over non-suite proposals if it chooses not to parse them. This would be relatively simple to code. What do you think? --Charlie Kaufman From owner-ipsec@lists.tislabs.com Thu Aug 29 10:38: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 g7THch227850; Thu, 29 Aug 2002 10:38:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13291 Thu, 29 Aug 2002 12:49:29 -0400 (EDT) Message-Id: <200208291703.g7TH3UL02850@sydney.East.Sun.COM> Date: Thu, 29 Aug 2002 13:03:30 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: Last ditch proposal for crypto suites To: ipsec@lists.tislabs.com, ldondeti@nortelnetworks.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: m7kZRGQWeE0Yo3GIu0BmXA== 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: Lakshminath Dondeti From what I understand from the concrete proposal below, a compliant implementation MUST recognize suites as well as ala carte proposals. How does this make life any easier for anyone? regards, Lakshminath As I read Charlie's concrete proposal, it says that an implementation can choose to implement only suites. Only the suites would be mandatory to implement, and the only a la carte code necessary would be the ability to skip over the a la carte stuff. I remember in person, and at the mike at meetings, enough people arguing for a la carte that we didn't switch, but I don't remember who was arguing for it. I think the argument was that the number of suites defined tends to grow exponentially, especially with new vanity crypto algorithms, but I'd think whoever defined the vanity algorithm could choose which hash, signature scheme, etc., went with it, and wouldn't need that algorithm in combination with lots of choices. I did enjoy the quote Charlie put into the spec until the rest of us noticed and made him take it out..."Assembly of SA payload requires great peace of mind" (paraphrase of quote from Zen and the Art of Motorcycle Maintenance). :-) Radia From owner-ipsec@lists.tislabs.com Thu Aug 29 10:42: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 g7THgr227962; Thu, 29 Aug 2002 10:42:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13297 Thu, 29 Aug 2002 12:50:31 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: rcharlet@SonicWALL.com Cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Aug 2002 13:03:59 -0400 Message-Id: <20020829170359.E23C97B4C@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , r charlet@SonicWALL.com writes: >Howdy, > > What would happen if we have a MUST implement crypto suite that one day > is shown to be no-longer trustworthy? We deprecate it and define a new one. The same applies to a mandatory-to-implement a la carte algorithm, such as DES... You do make a good point, though: the document should say (for algorithms or suites) that "implementations SHOULD provide a way for administrators to disable use of certain choices, even if their implementation is mandatory per this or other RFCs". --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) From owner-ipsec@lists.tislabs.com Thu Aug 29 10: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 g7THi5228012; Thu, 29 Aug 2002 10:44:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13329 Thu, 29 Aug 2002 12:55:34 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <20020829154421.281587B4C@berkshire.research.att.com> References: <20020829154421.281587B4C@berkshire.research.att.com> Date: Thu, 29 Aug 2002 10:06:33 -0700 To: "Steven M. Bellovin" , Charlie_Kaufman@notesdev.ibm.com From: Paul Hoffman / VPNC Subject: Re: Last ditch proposal for crypto suites 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 -0400 8/29/02, Steven M. Bellovin wrote: >You know my opinion -- scrap a la carte. But let me ask the question >differently: Paul Hoffman, in your interoperability tests do you see >many different combinations actually used? Or don't your tests go >there? We see a huge amount of variation. Of the systems that have GUIs, I have seen - default of DES and MD5 - default of DES and SHA-1 - default of TripleDES and SHA-1 - no options: always does TripleDES and SHA-1 and probably some others I have forgotten. Note that some of these systems have GUIs that only allow single choices for the administrator, but send out multiple proposals anyway ("in order to increase interoperability", I am told). Almost every system allows different settings for Phase 1 and Phase 2, and on the ones I tinkered with, none warned if you used DES in Phase 1 and TripleDES in Phase 2. Based on this and the agony I hear from users, I'm a strong proponent of suites. >As for the specific suggestion -- I think I'd rather keep a la carte, >rather than the hybrid suggestion. I fear the complexity, not just of >having both sets of code, but also of being able to cope correctly with >an offer or a response that specified one a la carte entry *and* one >suite. I think the potential for bugs there is high. But if we want >to go there, we need to specify precisely how to deal with the >situation. In particular, we need to specify the rules on how to >decide which to accept, and what to do if there is an apparent conflict >in a response. We agree here. And I agree with what Phill said: if you need a la carte for some reason, use IKEv1. IKEv2 should be simple, and suites are simpler. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Aug 29 10:45: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 g7THjL228099; Thu, 29 Aug 2002 10:45:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13330 Thu, 29 Aug 2002 12:55:34 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Thu, 29 Aug 2002 10:10:03 -0700 To: rcharlet@SonicWALL.com, , From: Paul Hoffman / VPNC Subject: RE: Last ditch proposal for crypto suites Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:36 AM -0700 8/29/02, rcharlet@SonicWALL.com wrote: > What would happen if we have a MUST implement crypto suite >that one day is shown to be no-longer trustworthy? The exact same thing that would happen if we had a la carte and had a MUST implement single option that was shown to be un-trustworthy: users would have to use a non-mandatory one, and we would want to change the mandatory one. No one is suggesting that if we go to suites that there would be only one suite. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Aug 29 10:58: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 g7THw5229121; Thu, 29 Aug 2002 10:58:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13474 Thu, 29 Aug 2002 13:09:53 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Paul Hoffman / VPNC Cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Aug 2002 13:24:19 -0400 Message-Id: <20020829172419.3DF707B4C@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Paul Hoffman / VPNC writes : >At 11:44 AM -0400 8/29/02, Steven M. Bellovin wrote: >>You know my opinion -- scrap a la carte. But let me ask the question >>differently: Paul Hoffman, in your interoperability tests do you see >>many different combinations actually used? Or don't your tests go >>there? > >We see a huge amount of variation. Of the systems that have GUIs, I have seen >- default of DES and MD5 >- default of DES and SHA-1 >- default of TripleDES and SHA-1 >- no options: always does TripleDES and SHA-1 >and probably some others I have forgotten. > >Note that some of these systems have GUIs that only allow single >choices for the administrator, but send out multiple proposals anyway >("in order to increase interoperability", I am told). > >Almost every system allows different settings for Phase 1 and Phase >2, and on the ones I tinkered with, none warned if you used DES in >Phase 1 and TripleDES in Phase 2. > >Based on this and the agony I hear from users, I'm a strong proponent >of suites. If I understand you correctly, you're saying that implementors and/or administrators are making different choices on what combinations to offer, thus hurting interoperability? That suggests that even if we stick with a la carte, we should specify which combinations MUST be offered, from among the standard algorithms (subject to administrator security override, of course). Aside -- and donning my AD hat for a moment -- I've become increasing concerned about interoperability. We need to ensure that our standards, as well as being technical correct and secure, specify a minimum set of mandatory-to-implement mechanisms that will always be there. Specs that say "you can solve this problem by doing (a) or (b)" are not acceptable, since different vendors will make different choices. Empirically, we didn't get this right in IPsec. Let's fix that now -- and precisely how we fix it, with suites or with better specification of how a la carte choices should be assembled, is less important from that perspective. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) From owner-ipsec@lists.tislabs.com Thu Aug 29 10:58: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 g7THw5229122; Thu, 29 Aug 2002 10:58:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13452 Thu, 29 Aug 2002 13:08:48 -0400 (EDT) Message-ID: <3D6E5696.7060904@nortelnetworks.com> Date: Thu, 29 Aug 2002 13:15:02 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Radia Perlman - Boston Center for Networking CC: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites References: <200208291703.g7TH3UL02850@sydney.East.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk One of the advantages of suites is that the SA payload will become compact, and perhaps there will be better interoperability. By allowing both, and having to be able to process both (ok, skip over in case of a la carte transforms), we begin to lose some of the above benefits. Also, as Steve Bellovin pointed out, the "hybrid" approach may result in buggy code. My point is that we should get a consensus of the WG, pick one of the two approaches, and be done with this discussion once and for all. regards, Lakshminath Radia Perlman - Boston Center for Networking wrote: > From: Lakshminath Dondeti > > From what I understand from the concrete proposal below, a compliant > implementation MUST recognize suites as well as ala carte proposals. > How does this make life any easier for anyone? > > regards, > Lakshminath > > As I read Charlie's concrete proposal, it says that an implementation > can choose to implement only suites. Only the suites would be mandatory > to implement, and the only a la carte code necessary would be the ability > to skip over the a la carte stuff. > > I remember in person, and at the mike at meetings, enough people arguing > for a la carte that we didn't switch, but I don't remember who was arguing > for it. I think the argument was that the number of suites defined tends > to grow exponentially, especially with new vanity crypto algorithms, but > I'd think whoever defined the vanity algorithm could choose which hash, > signature scheme, etc., went with it, and wouldn't need that algorithm > in combination with lots of choices. > > I did enjoy the quote Charlie put into the spec until the rest of us > noticed and made him take it out..."Assembly of SA payload requires > great peace of mind" (paraphrase of quote from Zen and the Art > of Motorcycle Maintenance). :-) > > Radia > > > From owner-ipsec@lists.tislabs.com Thu Aug 29 11:04: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 g7TI4D229527; Thu, 29 Aug 2002 11:04:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13535 Thu, 29 Aug 2002 13:16:00 -0400 (EDT) Message-Id: <200208291730.AGA15406@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 29 Aug 2002 10:15:27 -0700 To: rcharlet@SonicWALL.com, , From: Scott Fluhrer Subject: RE: Last ditch proposal for crypto suites In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:36 AM 8/29/02 , rcharlet@SonicWALL.com wrote: >Howdy, > > What would happen if we have a MUST implement crypto suite that one day is shown to be no-longer trustworthy? What happened when we had a MUST implement transform (ESP_DES) that one day was shown to be no-longer trustworthy (e.g. by the EFF DES-cracker)? -- scott From owner-ipsec@lists.tislabs.com Thu Aug 29 11:11: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 g7TIB4200100; Thu, 29 Aug 2002 11:11:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13534 Thu, 29 Aug 2002 13:15:56 -0400 (EDT) Date: 29 Aug 2002 13:13:16 -0400 Message-ID: <000a01c24f7f$5f4d2f50$1e72788a@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'Charlie Kaufman'" , " 'list'" Subject: RE: Last ditch proposal for crypto suites 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 It was my experience with IKEv1 that the crypto algorithm negotiation was accomplished by many people with very few errors. This, despite the fact that the naming and organization of the payloads is rather confusing. (Why is an SA a list of proposals rather than a proposal being a list of SAs or [better] a proposal-list being a list of bundles? Why is there two levels of indirection with the proposal+transform when there could have been only one?) I should also point out that 4 of the 9 pages are taken up with DOI-style lists, such as the following: For Transform Type 1 (Encryption Algorithm), defined Transform-IDs are: Name Number Defined In RESERVED 0 ENCR_DES_IV64 1 (RFC1827) ENCR_DES 2 (RFC2405) ENCR_3DES 3 (RFC2451) ENCR_RC5 4 (RFC2451) ENCR_IDEA 5 (RFC2451) ENCR_CAST 6 (RFC2451) ENCR_BLOWFISH 7 (RFC2451) ENCR_3IDEA 8 (RFC2451) ENCR_DES_IV32 9 ENCR_RC4 10 ENCR_NULL 11 (RFC2410) ENCR_AES_128 12 values 12-240 are reserved to IANA. Values 241-255 are for private use among mutually consenting parties. Does that give you a headache? 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 Aug 29 11:26: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 g7TIQm201010; Thu, 29 Aug 2002 11:26:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13676 Thu, 29 Aug 2002 13:38:17 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15726.24444.437415.245341@pkoning.dev.equallogic.com> Date: Thu, 29 Aug 2002 13:53:00 -0400 From: Paul Koning To: pbaker@verisign.com Cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites References: <2F3EC696EAEED311BB2D009027C3F4F405869B84@vhqpostal.verisign.com> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If I heard Charlie right, the ability to handle a la carte negotiation would be optional, so if it turns out to be necessary after all, there would have to be a mad scramble to implement in in all the implementations that had left it out at first. Ok, so be it. One data point: in a past life when I implemented IPsec, we effectively implemented suites. The management interface had a MIB table of "crypto profiles" -- table rows with a name and a choice for each of the transforms. We supplied a default set of profiles, the obvious suspects: default-auth (md5 only); default-weak (md5 and des); default-strong (md5 and 3des). I don't remember anyone ever adding profiles to that list, unless they were testing oddball setups at bakeoff meetings... So I would argue that the suite approach is the best way to meet customer needs. paul From owner-ipsec@lists.tislabs.com Thu Aug 29 11:33: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 g7TIXm201484; Thu, 29 Aug 2002 11:33:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13682 Thu, 29 Aug 2002 13:39:17 -0400 (EDT) Message-Id: <200208291753.g7THrgve004220@marajade.sandelman.ottawa.on.ca> To: Charlie_Kaufman@notesdev.ibm.com cc: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites In-reply-to: Your message of "Wed, 28 Aug 2002 23:19:04 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 29 Aug 2002 13:53:42 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charlie" == Charlie Kaufman writes: Charlie> There is a way to get the best of both worlds (and the worst of Charlie> both worlds). The IKEv2 specification could specify how to Charlie> negotiate suites and ala carte, where the suites are mandatory Charlie> to implement and the ala carte negotiation is optional. If it Charlie> turns out that the optimists are right and the number of suites Charlie> actually implemented is small, the ala carte might not be Charlie> implemented and could fade away. If the pessimists are right and Charlie> ala carte was necessary, the ability to negotiate suites adds Charlie> only minor complexity to the spec and to implementations. There are some additional testing complexity, and or some wording complexity. Specifically, what if the initiator proposes an "a la carte" of 3DES/MD5/LZS, which happens to be suite #5, and the responder has not implemented a la carte negotiation. Do we mandate that the responder must understand this? I don't think so. Or do we mandate that the the initiator may not do that? That's complicated code that for the initiator, but at least it is their choice to implement the a-la-carte stuff. Andrew K and I had lunch the other week to talk about ciphersuites. We agree that suites are necessary, and should be the primary thing that is presented to users. Andrew prefers that it is limited to the UI. I am concerned about testing, about bakeoffs, and about cryptoanalysis. UI cyphersuites can deal with some of this, and Andrew made good points that the algorithms are rather modular and unit testing can be done piecemeal. However, testing of hardware does not work that way. Charlie> A concrete proposal: I like your proposal very much. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPW5fo4qHRg3pndX9AQFDvgQA41KcwTJ1W9d89A07jwGwT3BIgnRfcXwl M9CgTmfzXQ0z4hyNN+ZVHEa5Qy5x/W+XJB2bfz2Za7v7foKl/sb4agDdL10z9p77 2R7fpZIn89h9ro+KnUZdSVxbWWL2saOYft7M+p9+MZnITxvh18Ba+nVZGJhR+Rrm xvhjtbWHOVs= =IfPI -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Aug 29 11:38: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 g7TIcO201809; Thu, 29 Aug 2002 11:38:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13743 Thu, 29 Aug 2002 13:45:38 -0400 (EDT) Message-Id: <200208291759.g7THxVEN004251@marajade.sandelman.ottawa.on.ca> To: Lakshminath Dondeti cc: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites In-reply-to: Your message of "Thu, 29 Aug 2002 11:28:03 EDT." <3D6E3D83.7070601@nortelnetworks.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 29 Aug 2002 13:59:31 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Lakshminath" == Lakshminath Dondeti writes: Lakshminath> From what I understand from the concrete proposal below, a Lakshminath> compliant implementation MUST recognize suites as well as Lakshminath> ala carte proposals. How does this make life any easier for Lakshminath> anyone? No, you got it backwards. You MUST implement suites. You MAY implement a la carte. If you choose not to implement a la carte, you MUST be able to parse enough to skip them. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPW5hAYqHRg3pndX9AQGaaQQAyE2dcZhFus5hRSTaX9S7Th3x62rnH9K+ nAVO/y7ZUcPCbql/X5hzlXNf+Ep2PJSiXuIK4twU6IOb5LEgosYtEDntLIEGGyqp G1II9Xu4KmmhIbCx+6AT9VsfytLfvyA6NX80+O2coVVxQkkU2j4UwAmBR6Ljen3w jVefi05lqqk= =gGOX -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Aug 29 11:44: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 g7TIiA202014; Thu, 29 Aug 2002 11:44:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13805 Thu, 29 Aug 2002 13:49:47 -0400 (EDT) Message-Id: <200208291803.g7TI3UBj004356@marajade.sandelman.ottawa.on.ca> To: rcharlet@SonicWALL.com cc: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites In-reply-to: Your message of "Thu, 29 Aug 2002 09:36:05 PDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 29 Aug 2002 14:03:30 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "rcharlet" == rcharlet writes: rcharlet> Howdy, rcharlet> What would happen if we have a MUST implement crypto suite that rcharlet> one day is shown to be no-longer trustworthy? You parsed the proposal wrong. You MUST implement crypto suite *parsing*. What algorithms you will *agree* to is a matter of configuration. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPW5h8IqHRg3pndX9AQGFiwP+MVHikj9i7P0al4fp19biCK9uDGMYYTzb HcI/qn+Llv7vxbnmVGIEcR5NlLE6UR22c5uIyI6rJzk+9G579qoIg/g6Tw1cxLZM sgx8tAlEpbwsVxrrWBEMivTDseaqvdSEv4fiYWi8dBybeNDKUzK3ZzDt2VD3S+cc nNz/iStpzJk= =Otsq -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Aug 29 11:50: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 g7TIoU202359; Thu, 29 Aug 2002 11:50:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13851 Thu, 29 Aug 2002 13:56:53 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40DF2DB84@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Paul Koning , pbaker@verisign.com Cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites Date: Thu, 29 Aug 2002 11:12:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If a configuration has not been tested then it should not be offered. So the folk who really think they need to use WAZOO, their bespoke public crypto scheme should test WAZOO + AES + SHA1. The folk who really think they need GUMPF symmetric encryption should check that with RSA and SHA1. Somehow the fact that suites would force the WAZOO and GUMPF people to test their two implementations against each other makes me feel happier about things rather than worse. Phill > -----Original Message----- > From: Paul Koning [mailto:pkoning@equallogic.com] > Sent: Thursday, August 29, 2002 1:53 PM > To: pbaker@verisign.com > Cc: Charlie_Kaufman@notesdev.ibm.com; ipsec@lists.tislabs.com > Subject: RE: Last ditch proposal for crypto suites > > > If I heard Charlie right, the ability to handle a la carte negotiation > would be optional, so if it turns out to be necessary after all, there > would have to be a mad scramble to implement in in all the > implementations that had left it out at first. > > Ok, so be it. > > One data point: in a past life when I implemented IPsec, we > effectively implemented suites. The management interface had a MIB > table of "crypto profiles" -- table rows with a name and a choice for > each of the transforms. We supplied a default set of profiles, the > obvious suspects: default-auth (md5 only); default-weak (md5 and des); > default-strong (md5 and 3des). I don't remember anyone ever adding > profiles to that list, unless they were testing oddball setups at > bakeoff meetings... > > So I would argue that the suite approach is the best way to meet > customer needs. > > paul > From owner-ipsec@lists.tislabs.com Thu Aug 29 11:50: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 g7TIog202384; Thu, 29 Aug 2002 11:50:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13852 Thu, 29 Aug 2002 13:56:54 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40DF2DB83@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Paul Hoffman / VPNC , "Steven M. Bellovin" , Charlie_Kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites Date: Thu, 29 Aug 2002 11:12:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Note that some of these systems have GUIs that only allow single > choices for the administrator, but send out multiple proposals anyway > ("in order to increase interoperability", I am told). Or maybe so that if an algorithm is compromised we give the attacker the maximum possible opportunity to exploit it. My experience dealing with remediation of various crypto failures and bugs is that the less flexible the end applications are the better the chance there is of finding an interim fix. For example recently there was a bug discovered that made use of the fact that an application had two separate code paths for dealing with a particular function. There was a serious bug in one path, however it is possible to prevent the bug being exploited in future by forcing the app to always choose the safe code path. An algorithm suite compromise is in my view separate from an algorithm compromise. It is fairly rare that an algorithm is broken completely all in one go. With MD4 we got five years warning that there was likely a problem. Even with a protocol as baddly broken as WEP remediation is possible that makes the attackers job a lot harder by careful configuration. While security through obscurity, patch and mend etc are bad design, they are often the only available practice. At some point IPSEC (or something like it) is going to be ubiquitous on cheap devices where recall of faulty product is not an option. Phill From owner-ipsec@lists.tislabs.com Thu Aug 29 12:03: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 g7TJ3m203461; Thu, 29 Aug 2002 12:03:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13976 Thu, 29 Aug 2002 14:10:21 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15726.26374.217496.318208@pkoning.dev.equallogic.com> Date: Thu, 29 Aug 2002 14:25:10 -0400 From: Paul Koning To: rcharlet@SonicWALL.com Cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites References: X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "rcharlet" == rcharlet writes: rcharlet> Howdy, What would happen if we have a MUST implement crypto rcharlet> suite that one day is shown to be no-longer trustworthy? Same as what happens now (e.g., DES) -- after a delay (months, years, decades) it is deprecated and moves to "historic". paul From owner-ipsec@lists.tislabs.com Thu Aug 29 12:37: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 g7TJbu205712; Thu, 29 Aug 2002 12:37:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14332 Thu, 29 Aug 2002 14:46:38 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15726.28503.743046.423387@pkoning.dev.equallogic.com> Date: Thu, 29 Aug 2002 15:00:39 -0400 From: Paul Koning To: Radia.Perlman@sun.com Cc: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites References: <200208291703.g7TH3UL02850@sydney.East.Sun.COM> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Radia" == Radia Perlman <- Boston Center for Networking > writes: Radia> I remember in person, and at the mike at meetings, enough Radia> people arguing for a la carte that we didn't switch, but I Radia> don't remember who was arguing for it. I think the argument Radia> was that the number of suites defined tends to grow Radia> exponentially, especially with new vanity crypto algorithms, ... That sounds like an *excellent* argument in favor of suites. Based on previous experience, I can see an argument right now for at most 3 mandatory suites (esp sha1 alone, sha1 with 3des, sha1 with aes) and less than 10 optional ones (the above with md5 instead of sha1, basically). The "exponential" argument sounds like a red herring. paul From owner-ipsec@lists.tislabs.com Thu Aug 29 13:01: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 g7TK1p207242; Thu, 29 Aug 2002 13:01:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14621 Thu, 29 Aug 2002 15:10:24 -0400 (EDT) Date: Thu, 29 Aug 2002 12:25:05 -0700 (PDT) From: Jan Vilhuber To: cc: Subject: Re: Last ditch proposal for crypto suites 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'll toss in my 2c (plus some ;): Let's pick one way. PLEASE don't do both, just to appease one side or the other. I am marginally more in favor of a-la-carte and Paul's proposal of defining combinations at the UI level (which also translates into the 'testing' level). But I don't feel that strongly and if consensus is suites, I'll definitely live (and, as someone else pointed out, we can use vendor-id and private-range suite numbers to test out other private vanity-suites ;). But please not both. Let's pick one. jan On Wed, 28 Aug 2002 Charlie_Kaufman@notesdev.ibm.com wrote: > > > > > The discussion of crypto suites vs. ala carte algorithm negotiation in > IKEv2 was frustrating. I think most people like suites better (in the > possibly unrealistic belief that we can keep the number of suites > manageably small), but the advocates for ala carte negotiation were more > adament about its necessity. I read the conclusion as leave the negotiation > as it is (ala carte). The specification for SA proposal payload in the > IKEv2 document is 9 pages long, and they are frightening pages. It was a > message from Angelos Keromytis saying that it gave him a headache that > inspired me to make one more last ditch proposal. > > There is a way to get the best of both worlds (and the worst of both > worlds). The IKEv2 specification could specify how to negotiate suites and > ala carte, where the suites are mandatory to implement and the ala carte > negotiation is optional. If it turns out that the optimists are right and > the number of suites actually implemented is small, the ala carte might not > be implemented and could fade away. If the pessimists are right and ala > carte was necessary, the ability to negotiate suites adds only minor > complexity to the spec and to implementations. > > It's the worst of both worlds because it would make the spec longer and > more complex. There might be a way to move the optional ala carte > negotiation to an Appendix or something so that at least some people would > ignore it and think the spec less intimidating. Some implementers would not > implement it and simplify their lives. The suites would be more likely to > pass interoperability testing more easily, since there are fewer things to > get wrong. > > A concrete proposal: > > The SA payload contains a series of proposals. Each proposal has a fixed > header and a variable length list of transforms. The fixed harder is > eight bytes long - four of those bytes are Proposal #, Protocol-ID, SPI > Size, and # of Transforms. Protocol-IDs are defined for IKE, ESP, AH, and > IPcomp. I propose that we define a new Protocol-ID that means crypto suite, > and that for that value the SPI Size and # of Transforms are replaced with > a two byte suite number. The suite number would define the actual > Protocol-ID, SPI Size, # of Transforms, and all of the Transforms and their > attributes. The entire proposal would be 8 bytes for an IKE proposal, 12 > bytes for an ESP or AH proposal (including 4 byte SPI), and 14 bytes for an > ESP w/IPcomp proposal (including 4 byte ESP SPI and 2 byte IPcomp SPI). > > An implementation MUST recognise and be able to accept the mandatory > suites, and must be able to skip over non-suite proposals if it chooses not > to parse them. This would be relatively simple to code. > > What do you think? > > --Charlie Kaufman > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Thu Aug 29 13:20: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 g7TKKY207816; Thu, 29 Aug 2002 13:20:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14771 Thu, 29 Aug 2002 15:33:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <20020829172419.3DF707B4C@berkshire.research.att.com> References: <20020829172419.3DF707B4C@berkshire.research.att.com> Date: Thu, 29 Aug 2002 12:47:23 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Last ditch proposal for crypto suites Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:24 PM -0400 8/29/02, Steven M. Bellovin wrote: >If I understand you correctly, you're saying that implementors and/or >administrators are making different choices on what combinations to >offer, thus hurting interoperability? Partially right. The other part that is making interoperability hard is that there are options for both Phase 1 and Phase 2. Almost no one in their right mind would really mean that Phase 1 be protected with DES and Phase 2 be protected with TripleDES, but many UIs make that easy to do. If we go with suites, I strongly suspect this WG will pick sensible ones. Having ten or twenty choices is not a problem if they are clearly named, such as "Suite A". If a GUI wants to say "Suite A (TripleDES, SHA-1, Group 2, no PFS)" that's fine, but for a VPN administrator talking to another administrator to be able to be able to say "use Suite D" would make interop incredibly simpler. > That suggests that even if we >stick with a la carte, we should specify which combinations MUST be >offered, from among the standard algorithms (subject to administrator >security override, of course). And thereby get into GUI messes. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Aug 29 13:44: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 g7TKis209256; Thu, 29 Aug 2002 13:44:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14936 Thu, 29 Aug 2002 15:55:19 -0400 (EDT) Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60383717E@zcard0ke.ca.nortel.com> From: "Dennis Beard" To: "Steven M. Bellovin" , Charlie_Kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites Date: Thu, 29 Aug 2002 15:54:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24F95.E88A4F58" 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_01C24F95.E88A4F58 Content-Type: text/plain Hello, I agree with Charlie's proposal (below) as written. I think this is the simplest way to go and maintains the essences of compactness of the SA pay load part of the protocol as pointed out earlier by L. Dondeti. Too many options makes the protocol complicated and difficult to implement. At most, the suite should have no more than 2 algorithm capabilities that can operate in symmetric or asymmetric conditions - light weight w/ minimum footprint, and robust such as AES (Marc Desoriers). Steve Bellovin makes a good point about interoperability. To the extent that IKEv2 specifies a very tight set of suites and their attributes, the more interoperability we will achieve because choice is finitely contained. We are the Standards organization so we should specify and let the world follow. This is what Charlie wrote: "I propose that we define a new Protocol-ID that means crypto suite, and that for that value the SPI Size and # of Transforms are replaced with a two byte suite number. The suite number would define the actual Protocol-ID, SPI Size, # of Transforms, and all of the Transforms and their attributes. The entire proposal would be 8 bytes for an IKE proposal, 12 bytes for an ESP or AH proposal (including 4 byte SPI), and 14 bytes for an ESP w/IPcomp proposal (including 4 byte ESP SPI and 2 byte IPcomp SPI)." No hybrid please - unless it's corn. Cheers, Dennis Beard -----Original Message----- From: Steven M. Bellovin [mailto:smb@research.att.com] Sent: Thursday, August 29, 2002 11:44 AM To: Charlie_Kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites In message , Charlie_Kaufman@notesdev.ibm.com writes: > > > > >The discussion of crypto suites vs. ala carte algorithm negotiation in >IKEv2 was frustrating. I think most people like suites better (in the >possibly unrealistic belief that we can keep the number of suites >manageably small), but the advocates for ala carte negotiation were >more adament about its necessity. You know my opinion -- scrap a la carte. But let me ask the question differently: Paul Hoffman, in your interoperability tests do you see many different combinations actually used? Or don't your tests go there? As for the specific suggestion -- I think I'd rather keep a la carte, rather than the hybrid suggestion. I fear the complexity, not just of having both sets of code, but also of being able to cope correctly with an offer or a response that specified one a la carte entry *and* one suite. I think the potential for bugs there is high. But if we want to go there, we need to specify precisely how to deal with the situation. In particular, we need to specify the rules on how to decide which to accept, and what to do if there is an apparent conflict in a response. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) ------_=_NextPart_001_01C24F95.E88A4F58 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Last ditch proposal for crypto suites Hello, I agree with Charlie's proposal (below) as = written. I think this is the simplest way to go and maintains the = essences of compactness of the SA pay load part of the protocol as = pointed out earlier by L. Dondeti. Too many options makes the = protocol complicated and difficult to implement. At most, the = suite should have no more than 2 algorithm capabilities that can = operate in symmetric or asymmetric conditions - light weight w/ minimum = footprint, and robust such as AES (Marc Desoriers). Steve = Bellovin makes a good point about interoperability. To the extent = that IKEv2 specifies a very tight set of suites and their attributes, = the more interoperability we will achieve because choice is finitely = contained. We are the Standards organization so we should specify = and let the world follow. This is what Charlie wrote: "I propose that we define a new Protocol-ID that = means crypto suite, and that for that value the SPI Size and # of = Transforms are replaced with a two byte suite number. The suite number = would define the actual Protocol-ID, SPI Size, # of Transforms, and all = of the Transforms and their attributes. The entire proposal would be 8 = bytes for an IKE proposal, 12 bytes for an ESP or AH proposal = (including 4 byte SPI), and 14 bytes for an ESP w/IPcomp proposal (including 4 byte ESP SPI and 2 byte IPcomp = SPI)." No hybrid please - unless it's corn. Cheers, Dennis Beard -----Original Message----- From: Steven M. Bellovin [<3d.htm>mailto:smb@research.att.com] = Sent: Thursday, August 29, 2002 11:44 AM To: Charlie_Kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites = In message = > > > >The discussion of crypto suites vs. ala carte = algorithm negotiation in >IKEv2 was frustrating. I think most people like = suites better (in the >possibly unrealistic belief that we can keep the = number of suites >manageably small), but the advocates for ala = carte negotiation were >more adament about its necessity. You know my opinion -- scrap a la carte. But = let me ask the question differently: Paul Hoffman, in your = interoperability tests do you see many different combinations actually used? Or = don't your tests go there? As for the specific suggestion -- I think I'd rather = keep a la carte, rather than the hybrid suggestion. I fear the = complexity, not just of having both sets of code, but also of being able to = cope correctly with an offer or a response that specified one a la carte = entry *and* one suite. I think the potential for bugs there is = high. But if we want to go there, we need to specify precisely how to = deal with the situation. In particular, we need to specify = the rules on how to decide which to accept, and what to do if there is = an apparent conflict in a response. = --Steve = Bellovin, <3d.htm>http://www.research.att.com/~smb (me) = <3d.htm>http://www.wilyhacker.com ("Firewalls" = book) ------_=_NextPart_001_01C24F95.E88A4F58-- From owner-ipsec@lists.tislabs.com Thu Aug 29 13:45: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 g7TKjq209340; Thu, 29 Aug 2002 13:45:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14915 Thu, 29 Aug 2002 15:55:15 -0400 (EDT) Date: Thu, 29 Aug 2002 15:54:55 -0400 From: Mouse Subject: Re: Last ditch proposal for crypto suites In-reply-to: <20020829172419.3DF707B4C@berkshire.research.att.com> To: ipsec@lists.tislabs.com Reply-to: uri@optonline.net Message-id: <0H1M00JP4FKAN2@mta1.srv.hcvlny.cv.net> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=windows-1251 Content-transfer-encoding: 7BIT References: <20020829172419.3DF707B4C@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thursday 29 August 2002 13:24, Steven M. Bellovin wrote: > >Based on .......... the agony I hear from users, I'm a strong > > proponent of suites. > > If I understand you correctly, you're saying that implementors and/or > administrators are making different choices on what combinations to > offer, thus hurting interoperability? That suggests that even if we > stick with a la carte, we should specify which combinations MUST be > offered, from among the standard algorithms (subject to administrator > security override, of course). Yes. > Aside -- and donning my AD hat for a moment -- I've become increasing > concerned about interoperability. We need to ensure that our > standards, as well as being technical correct and secure, specify > a minimum set of mandatory-to-implement mechanisms that will always > be there. I'm afraid it means - we must do suites. I myself am concerned that my pet crypto algorithms might not be there - but still analyzing and standardizing suites seems a much better idea than a-la carte. -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Thu Aug 29 13:45: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 g7TKjq209341; Thu, 29 Aug 2002 13:45:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14937 Thu, 29 Aug 2002 15:55:20 -0400 (EDT) Message-ID: <4D79C746863DD51197690002A52CDA00029BD902@zcard0kc.ca.nortel.com> From: "Marc Desrosiers" To: "'Paul Koning'" , rcharlet@SonicWALL.com Cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites Date: Thu, 29 Aug 2002 16:01:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24F96.CFB16696" 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_01C24F96.CFB16696 Content-Type: text/plain; charset="iso-8859-1" Yes but now you have to create a new suite because the bundle that also contained RSA and AES (as an example) has been deprecated. If you now want to support AES or RSA you have to point to a new suite. How do you maintain interoperability during the transition period? Marc DesRosiers -----Original Message----- From: Paul Koning [mailto:pkoning@equallogic.com] Sent: Thursday, August 29, 2002 2:25 PM To: rcharlet@SonicWALL.com Cc: Charlie_Kaufman@notesdev.ibm.com; ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites >>>>> "rcharlet" == rcharlet writes: rcharlet> Howdy, What would happen if we have a MUST implement crypto rcharlet> suite that one day is shown to be no-longer trustworthy? Same as what happens now (e.g., DES) -- after a delay (months, years, decades) it is deprecated and moves to "historic". paul ------_=_NextPart_001_01C24F96.CFB16696 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Last ditch proposal for crypto suites Yes but now you have to create a new suite because = the bundle that also contained RSA and AES (as an example) has been = deprecated. If you now want to support AES or RSA you have to point to = a new suite. How do you maintain interoperability during the transition = period? Marc DesRosiers -----Original Message----- From: Paul Koning [<3d.htm>mailto:pkoning@equallogic.com= ] Sent: Thursday, August 29, 2002 2:25 PM To: rcharlet@SonicWALL.com Cc: Charlie_Kaufman@notesdev.ibm.com; = ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto = suites >>>>> "rcharlet" =3D=3D = rcharlet writes: rcharlet> Howdy, What would happen if we = have a MUST implement crypto rcharlet> suite that one day is shown to be = no-longer trustworthy? Same as what happens now (e.g., DES) -- after a delay = (months, years, decades) it is deprecated and moves to = "historic". = paul ------_=_NextPart_001_01C24F96.CFB16696-- From owner-ipsec@lists.tislabs.com Thu Aug 29 13:56: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 g7TKu8209968; Thu, 29 Aug 2002 13:56:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15012 Thu, 29 Aug 2002 16:12:37 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <20020829172419.3DF707B4C@berkshire.research.att.com> Subject: Re: Last ditch proposal for crypto suites To: "Steven M. Bellovin" Cc: ipsec@lists.tislabs.com, Paul Hoffman / VPNC X-Mailer: Lotus Notes Build V60_08092002NP August 09, 2002 Message-ID: Date: Thu, 29 Aug 2002 16:24:38 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_08272002NP|August 27, 2002) at 08/29/2002 04:20:58 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > That suggests that even if we > stick with a la carte, we should specify which combinations MUST be > offered, from among the standard algorithms (subject to administrator > security override, of course). > > Aside -- and donning my AD hat for a moment -- I've become increasing > concerned about interoperability. We need to ensure that our > standards, as well as being technical correct and secure, specify > a minimum set of mandatory-to-implement mechanisms that will always be > there. Specs that say "you can solve this problem by doing (a) or (b)" > are not acceptable, since different vendors will make different choices. Absolutely. That's a given whatever else we decide to do. If the spec says you MAY do (a) or (b), then the spec must also say that you MUST accept both (a) and (b) should the other end choose them. The current draft mandates a single suite even though it is expressed ala carte. It's AES128, SHA-1, D-H w/1536 bit fixed p, X.509 certs, and RSA keys. The current draft *claims* that the mandatory algorithms for ESP and AH are specified in those documents. Is that true? If not, would it be appropriate to list mandatory algorithms for them here? I would like for it to be impossible to be compliant without being interoperable with everything else that is compliant. (This at the level of implementations not deployments... this is a security protocol after all and you have to be able to configure the system to refuse to talk to peers that don't have keys you like). --Charlie Opinions expressed may not even by mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Thu Aug 29 14:02: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 g7TL22210362; Thu, 29 Aug 2002 14:02:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15096 Thu, 29 Aug 2002 16:17:51 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15726.33988.758784.876722@pkoning.dev.equallogic.com> Date: Thu, 29 Aug 2002 16:32:04 -0400 From: Paul Koning To: mdesros@nortelnetworks.com Cc: rcharlet@SonicWALL.com, Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites References: <4D79C746863DD51197690002A52CDA00029BD902@zcard0kc.ca.nortel.com> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Marc" == Marc Desrosiers writes: Marc> Yes but now you have to create a new suite because the bundle Marc> that also contained RSA and AES (as an example) has been Marc> deprecated. If you now want to support AES or RSA you have to Marc> point to a new suite. How do you maintain interoperability Marc> during the transition period? I don't understand. Start with a suite: ESP: DES and SHA-1. Discover that DES is no good (ok, that's very old news). Define a new suite: ESP: AES and SHA-1. Relabel that one mandatory, the DES suite deprecated. You can now use the new suite with new implementations, and you're stuck with the old crufty suite with implementations that offer nothing better. That works just fine. It works at least as well as the current situation with DES. paul From owner-ipsec@lists.tislabs.com Thu Aug 29 14:15: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 g7TLFB211955; Thu, 29 Aug 2002 14:15:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15175 Thu, 29 Aug 2002 16:31:02 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40DF2DBF0@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Paul Koning , Radia.Perlman@sun.com Cc: ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites Date: Thu, 29 Aug 2002 13:46:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I consider the exponential growth of suites under vanity crypto is the reason to go for suites. If the products are going to be tested, vanity crypto results in exponential testing requirements. Cutting an OID is way less work than doing a test properly. Basically with suites the window for vanity crypto is going to be much smaller. That is a good thing. Phill > -----Original Message----- > From: Paul Koning [mailto:pkoning@equallogic.com] > Sent: Thursday, August 29, 2002 3:01 PM > To: Radia.Perlman@sun.com > Cc: ipsec@lists.tislabs.com > Subject: Re: Last ditch proposal for crypto suites > > > >>>>> "Radia" == Radia Perlman <- Boston Center for > Networking > writes: > > Radia> I remember in person, and at the mike at meetings, enough > Radia> people arguing for a la carte that we didn't switch, but I > Radia> don't remember who was arguing for it. I think the argument > Radia> was that the number of suites defined tends to grow > Radia> exponentially, especially with new vanity crypto > algorithms, ... > > That sounds like an *excellent* argument in favor of suites. > > Based on previous experience, I can see an argument right now for at > most 3 mandatory suites (esp sha1 alone, sha1 with 3des, sha1 with > aes) and less than 10 optional ones (the above with md5 instead of > sha1, basically). The "exponential" argument sounds like a red > herring. > > paul > From owner-ipsec@lists.tislabs.com Thu Aug 29 14:55: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 g7TLtY212830; Thu, 29 Aug 2002 14:55:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15449 Thu, 29 Aug 2002 17:08:56 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <200208291753.g7THrgve004220@marajade.sandelman.ottawa.on.ca> Subject: Re: Last ditch proposal for crypto suites To: Michael Richardson Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_08092002NP August 09, 2002 Message-ID: Date: Thu, 29 Aug 2002 17:21:09 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_08272002NP|August 27, 2002) at 08/29/2002 05:17:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Specifically, what if the initiator proposes an "a la carte" of > 3DES/MD5/LZS, which happens to be suite #5, and the responder has not > implemented a la carte negotiation. > The negotiation fails. > Do we mandate that the responder must understand this? I don't think so. > I agree. > Or do we mandate that the the initiator may not do that? That's complicated > code that for the initiator, but at least it is their choice to implement > the a-la-carte stuff. We mandate must implement suites, where must implement includes must include in proposals. If an initiator proposes no suites that the suite-only partner understands, the negotiation fails. It would be complicated for an initiator to take his a la carte list and automatically figure out what suites are included in there so they can be proposed separately. But that calculation is neither necessary nor (imho) useful. Configuration should enable suites explicitly and separately from a la carte stuff. --Charlie Opinions expressed may not even by mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Thu Aug 29 15: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 g7TMWO215975; Thu, 29 Aug 2002 15:32:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15643 Thu, 29 Aug 2002 17:46:25 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: Re: Last ditch proposal for crypto suites To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_08092002NP August 09, 2002 Message-ID: Date: Thu, 29 Aug 2002 17:58:36 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_08272002NP|August 27, 2002) at 08/29/2002 05:54:53 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The strong and nearly unanimous reaction to this question this time leads me to make a more radical proposal: I propose that we remove the text for a la carte negotiation from the IKEv2 spec, and escrow it in a bombproof vault somewhere in case future generations want it, and replace it with the proposal from my last message for specifying suites only. If we ever need a la carte, we have a backwards compatible way to add it in, but in the meantime we won't specify it. And if we're lucky, no one will ever miss it. --Charlie Opinions expressed may not even by mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Thu Aug 29 15:48: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 g7TMmp216847; Thu, 29 Aug 2002 15:48:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15712 Thu, 29 Aug 2002 18:03:38 -0400 (EDT) Message-Id: <200208292217.g7TMHPF7005865@marajade.sandelman.ottawa.on.ca> To: Charlie_Kaufman@notesdev.ibm.com cc: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites In-reply-to: Your message of "Thu, 29 Aug 2002 17:21:09 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 29 Aug 2002 18:17:24 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charlie" == Charlie Kaufman writes: Charlie> We mandate must implement suites, where must implement includes Charlie> must include in proposals. If an initiator proposes no suites Charlie> that the suite-only partner understands, the negotiation Charlie> fails. It would be complicated for an initiator to take his a la Charlie> carte list and automatically figure out what suites are included Charlie> in there so they can be proposed separately. But that Charlie> calculation is neither necessary nor (imho) Charlie> useful. Configuration should enable suites explicitly and Charlie> separately from a la carte stuff. So, you are saying that if the operator says he wants 3DES/MD5/LZS it will be negotiated a la carte. If he will also accept suite #5 (which happens to be 3DES/MD5/LZS), that is a seperate proposal, and probably a seperate click on the UI. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPW6dcYqHRg3pndX9AQGTiQP9GWKnyhQy8QF3v0foi4akFMze5mLPGqwA iolHCXk8AvFJgeF6/4QCOTLN1NqJdnCHKmzkEP7L9b5SsR3AtyAV1BHjz0m5g0zK gIEFLabFiG7xObIgo1MnUhKkDIynWG7+cGiyPG9XpivWnFrnTjyVHM7mVHRnBZtL rixz6EA6EYE= =II8E -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Aug 29 16:41: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 g7TNfi219679; Thu, 29 Aug 2002 16:41:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15868 Thu, 29 Aug 2002 18:56:21 -0400 (EDT) Message-Id: <200208292310.g7TNAi8u000914@mail2.trpz.com> To: Paul Hoffman / VPNC cc: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites In-Reply-To: Your message of "Thu, 29 Aug 2002 12:47:23 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1062.1030662527.1@tibernian.com> Date: Thu, 29 Aug 2002 16:08:47 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 29 Aug 2002 12:47:23 PDT you wrote > > Almost no one > in their right mind would really mean that Phase 1 be protected with > DES and Phase 2 be protected with TripleDES, but many UIs make that > easy to do. Why not? There is nothing particularly interesting in phase 1 anyway. This was especially true with IKEv1 where there were no TR payloads sent in phase 1. We're talking about two different proposals (whether it's suites or a la carte). One to protect the IKE traffic and another to protect the bulk data. Those two traffic flows are quite different and their security needs are different as well. Dan. From owner-ipsec@lists.tislabs.com Thu Aug 29 17:19: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 g7U0JW221170; Thu, 29 Aug 2002 17:19:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA15992 Thu, 29 Aug 2002 19:36:38 -0400 (EDT) Message-Id: <200208292346.g7TNks8S027794@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Charlie_Kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites In-reply-to: Your message of "Thu, 29 Aug 2002 17:58:36 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Aug 2002 19:46:54 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes! -Angelos (having exhausted his Advil supplies for the day) In message , Charlie_Kaufman@notesdev.ibm.com writes: > > > > >The strong and nearly unanimous reaction to this question this time leads >me to make a more radical proposal: > >I propose that we remove the text for a la carte negotiation from the IKEv2 >spec, and escrow it in a bombproof vault somewhere in case future >generations want it, and replace it with the proposal from my last message >for specifying suites only. If we ever need a la carte, we >have a backwards compatible way to add it in, but in the meantime we won't >specify it. And if we're lucky, no one will ever miss it. > > --Charlie > >Opinions expressed may not even by mine by the time you read them, and >certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Thu Aug 29 17:42: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 g7U0go223906; Thu, 29 Aug 2002 17:42:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16047 Thu, 29 Aug 2002 19:59:43 -0400 (EDT) Message-ID: <3D6EB89F.38EAF4AE@bstormnetworks.com> Date: Thu, 29 Aug 2002 17:13:19 -0700 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Charlie_Kaufman@notesdev.ibm.com CC: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2002 00:14:10.0696 (UTC) FILETIME=[2A002880:01C24FBA] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Unless someone can describe a real-life situation for which suites-only would not work, I think it is the best way to go. Vendors are always free to add proprietary extensions if they want to support unspecified algorithm combinations. If we mandate a minimal set of algorithms (and hence a minimal set of suites), this will suffice for the vast majority of deployments. If a la carte selection is important in a limited number of cases, this can be supported via private payloads, limiting the interop testing to interested parties. Scott Charlie_Kaufman@notesdev.ibm.com wrote: > > The strong and nearly unanimous reaction to this question this time leads > me to make a more radical proposal: > > I propose that we remove the text for a la carte negotiation from the IKEv2 > spec, and escrow it in a bombproof vault somewhere in case future > generations want it, and replace it with the proposal from my last message > for specifying suites only. If we ever need a la carte, we > have a backwards compatible way to add it in, but in the meantime we won't > specify it. And if we're lucky, no one will ever miss it. > > --Charlie > > Opinions expressed may not even by mine by the time you read them, and > certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Thu Aug 29 20:30: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 g7U3UJ203289; Thu, 29 Aug 2002 20:30:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA16607 Thu, 29 Aug 2002 22:44:04 -0400 (EDT) Message-ID: <3D6EDD80.7040903@nortelnetworks.com> Date: Thu, 29 Aug 2002 22:50:40 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie_Kaufman@notesdev.ibm.com CC: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In the IKEv2 spec., transforms may have attributes (Sec. 7.3.2 and Appendix A). I was wondering about how that would work with suites in a proposal. cheers, Lakshminath Charlie_Kaufman@notesdev.ibm.com wrote: > > > > The strong and nearly unanimous reaction to this question this time leads > me to make a more radical proposal: > > I propose that we remove the text for a la carte negotiation from the IKEv2 > spec, and escrow it in a bombproof vault somewhere in case future > generations want it, and replace it with the proposal from my last message > for specifying suites only. If we ever need a la carte, we > have a backwards compatible way to add it in, but in the meantime we won't > specify it. And if we're lucky, no one will ever miss it. > > --Charlie > > Opinions expressed may not even by mine by the time you read them, and > certainly don't reflect those of any other entity (legal or otherwise). > > From owner-ipsec@lists.tislabs.com Thu Aug 29 21:24: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 g7U4OD204782; Thu, 29 Aug 2002 21:24:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA16721 Thu, 29 Aug 2002 23:35:23 -0400 (EDT) Date: Thu, 29 Aug 2002 23:49:18 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Last ditch proposal for crypto suites 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, 29 Aug 2002 Charlie_Kaufman@notesdev.ibm.com wrote: > I propose that we remove the text for a la carte negotiation from the IKEv2 > spec, and escrow it in a bombproof vault somewhere in case future > generations want it, and replace it with the proposal from my last message > for specifying suites only. Sounds like a fine idea to me. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Aug 29 21:27: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 g7U4RK204819; Thu, 29 Aug 2002 21:27:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA16747 Thu, 29 Aug 2002 23:44:25 -0400 (EDT) Date: Thu, 29 Aug 2002 23:58:58 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Last ditch proposal for crypto suites In-Reply-To: <200208292310.g7TNAi8u000914@mail2.trpz.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 29 Aug 2002, Dan Harkins wrote: > > Almost no one > > in their right mind would really mean that Phase 1 be protected with > > DES and Phase 2 be protected with TripleDES... > > ...We're talking about two different proposals (whether it's suites or > a la carte). One to protect the IKE traffic and another to protect the > bulk data. Those two traffic flows are quite different and their > security needs are different as well. Yes, but under what circumstances would that particular combination make sense? If 3DES is fast enough to be used for bulk data, it is fast enough to be used for IKE traffic. Given that IKE traffic is such a tiny fraction of the normal traffic flow, there is just no sense in not using the best crypto algorithm you've got to protect it. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Aug 29 21:57: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 g7U4v1207163; Thu, 29 Aug 2002 21:57:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA16847 Fri, 30 Aug 2002 00:10:35 -0400 (EDT) Message-Id: <200208300424.g7U4OkL21725@sydney.East.Sun.COM> Date: Fri, 30 Aug 2002 00:24:44 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: Last ditch proposal for crypto suites To: Charlie_Kaufman@notesdev.ibm.com, ldondeti@nortelnetworks.com Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: cHYO81YRm0EVGdUZKqqlZA== 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 >> In the IKEv2 spec., transforms may have attributes (Sec. 7.3.2 and >> Appendix A). I was wondering about how that would work with suites in a >> proposal. >> cheers, >> Lakshminath All values of all attributes would be predefined in the definition of the suite. So for instance, the suite wouldn't be "AES" with an attribute of key size, but instead the suite would specity "AES with 128 bit keys". Radia From owner-ipsec@lists.tislabs.com Fri Aug 30 00: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 g7U73K227154; Fri, 30 Aug 2002 00:03:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA17186 Fri, 30 Aug 2002 02:21:12 -0400 (EDT) Message-Id: <3.0.3.32.20020829233313.013a6040@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Thu, 29 Aug 2002 23:33:13 -0700 To: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com From: Alex Alten Subject: Re: Last ditch proposal for crypto suites In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 05:58 PM 8/29/2002 -0400, Charlie_Kaufman@notesdev.ibm.com wrote: > >I propose that we remove the text for a la carte negotiation from the IKEv2 >spec, ... I'm amazed that after so many years the WG is still arguing over this issue (or maybe I'm not). As Steve B. pointed out interoperability and buggy code are very important considerations. We only need to spec two MUST have suites. RSA/3DES-CBC/SHA-1 and RSA/AES-CTR-128/SHA-2. Forget the rest, they are going into the dustbin of history. Details like PFS, HMAC should be the same across the suites. What I'll add, along with my vote to do suites, is that the receiver MUST accept whatever suite the sender chooses to use. This will make life a lot easier and will not be a "security" problem. The difference between 3DES and AES-128 is minor. What we are really after is to provide an upgrade path from 3DES to AES, to gain the huge performance improvement and yet not screw our existing customers. Choose the mandatory suites wisely and sparingly. Once the IKEv2 dust has settled there will be much more difficult fish to fry. Good luck Charlie & Co., - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Fri Aug 30 07:17: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 g7UEH2206578; Fri, 30 Aug 2002 07:17:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18185 Fri, 30 Aug 2002 09:29:02 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40DF2DCA2@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Alex Alten , Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites Date: Fri, 30 Aug 2002 06:45:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually following on from Radia's point I think we would have three suites: 1: RSA/3DES-CBC/SHA-1 2: RSA/AES-CTR-128/SHA-2 3: RSA/AES-CTR-256/SHA-2 The argument for suite 3 being that if something catastrophic does happen in the processing world there is a last ditch fallback. I would limit the SHOULD suites to the DSA variants of the above but excluding 3DES since the demand for DSA is likely to be restricted to people who want NIST acredited crypto and 3DES ain't acredited. 4: DSA/AES-CTR-128/SHA-2 5: DSA/AES-CTR-256/SHA-2 I don't want any other suites. I don't want EC variants, I don't want a different chaining mode for each day of the week. One thing that would be very useful for integration with specs in the Web Services space is if a unique URN was specified for each suite. EG urn:ietf:rfcxxx:cryptosuite-1 This would then allow the suite specification to be specified in negotiation at the Web services level. So that a UDDI directory or WSDL could contain a policy statement that says 'this service requires the use of IPSEC cryptosuite 2 or 4'. Note that we have fewer suites in total than we had symmetric algs for IKE1. Phill > -----Original Message----- > From: Alex Alten [mailto:Alten@attbi.com] > Sent: Friday, August 30, 2002 2:33 AM > To: Charlie_Kaufman@notesdev.ibm.com; ipsec@lists.tislabs.com > Subject: Re: Last ditch proposal for crypto suites > > > At 05:58 PM 8/29/2002 -0400, Charlie_Kaufman@notesdev.ibm.com wrote: > > > >I propose that we remove the text for a la carte negotiation > from the IKEv2 > >spec, > ... > > I'm amazed that after so many years the WG is still arguing > over this issue > (or maybe I'm not). As Steve B. pointed out interoperability > and buggy code > are very important considerations. > > We only need to spec two MUST have suites. RSA/3DES-CBC/SHA-1 and > RSA/AES-CTR-128/SHA-2. Forget the rest, they are going into > the dustbin > of history. Details like PFS, HMAC should be the same across > the suites. > > What I'll add, along with my vote to do suites, is that the > receiver MUST > accept whatever suite the sender chooses to use. This will > make life a lot > easier and will not be a "security" problem. The difference > between 3DES and > AES-128 is minor. What we are really after is to provide an > upgrade path from > 3DES to AES, to gain the huge performance improvement and yet > not screw our > existing customers. > > Choose the mandatory suites wisely and sparingly. Once the > IKEv2 dust has > settled there will be much more difficult fish to fry. > > Good luck Charlie & Co., > > - Alex > > -- > > Alex Alten > Alten@ATTBI.com > From owner-ipsec@lists.tislabs.com Fri Aug 30 07:40: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 g7UEeT207794; Fri, 30 Aug 2002 07:40:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18228 Fri, 30 Aug 2002 09:59:06 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15727.32170.696330.342358@pkoning.dev.equallogic.com> Date: Fri, 30 Aug 2002 10:14:02 -0400 From: Paul Koning To: Charlie_Kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites References: X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Charlie" == Charlie Kaufman writes: Charlie> The strong and nearly unanimous reaction to this question Charlie> this time leads me to make a more radical proposal: Charlie> I propose that we remove the text for a la carte negotiation Charlie> from the IKEv2 spec, and escrow it in a bombproof vault Charlie> somewhere in case future generations want it, and replace it Charlie> with the proposal from my last message for specifying suites Charlie> only. I support that. paul From owner-ipsec@lists.tislabs.com Fri Aug 30 07:50: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 g7UEoI209252; Fri, 30 Aug 2002 07:50:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18295 Fri, 30 Aug 2002 10:10:15 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15727.32791.951134.66593@pkoning.dev.equallogic.com> Date: Fri, 30 Aug 2002 10:24:23 -0400 From: Paul Koning To: henry@spsystems.net Cc: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites References: <200208292310.g7TNAi8u000914@mail2.trpz.com> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Henry" == Henry Spencer writes: Henry> On Thu, 29 Aug 2002, Dan Harkins wrote: >> > Almost no one > in their right mind would really mean that Phase >> 1 be protected with > DES and Phase 2 be protected with >> TripleDES... >> >> ...We're talking about two different proposals (whether it's >> suites or a la carte). One to protect the IKE traffic and another >> to protect the bulk data. Those two traffic flows are quite >> different and their security needs are different as well. Henry> Yes, but under what circumstances would that particular Henry> combination make sense? If 3DES is fast enough to be used for Henry> bulk data, it is fast enough to be used for IKE traffic. Henry> Given that IKE traffic is such a tiny fraction of the normal Henry> traffic flow, there is just no sense in not using the best Henry> crypto algorithm you've got to protect it. I agree. The ability to specify separately what transforms you want in phase 1 vs. phase 2 was always just a useless piece of extraneous complexity in IKE V1. When we implemented our IKE management (a few jobs ago) we didn't allow for this; the phase 1 transforms were the same as the phase 2 transforms. Henry's argument is a good one, and simplification of management is always valuable -- especially in security systems. paul From owner-ipsec@lists.tislabs.com Fri Aug 30 07:50: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 g7UEoI209253; Fri, 30 Aug 2002 07:50:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18296 Fri, 30 Aug 2002 10:10:15 -0400 (EDT) Message-Id: <3.0.3.32.20020830072212.014558e0@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 30 Aug 2002 07:22:12 -0700 To: "Hallam-Baker, Phillip" , Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com From: Alex Alten Subject: RE: Last ditch proposal for crypto suites In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40DF2DCA2@vhqpostal.verisig n.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This sounds reasonable. Shouldn't we also spec the RSA key lengths? And is 3DES-CBC doing EDE or EEE? (I assume EDE is preferable?) - Alex At 06:45 AM 8/30/2002 -0700, Hallam-Baker, Phillip wrote: >Actually following on from Radia's point I think we would have three suites: > >1: RSA/3DES-CBC/SHA-1 >2: RSA/AES-CTR-128/SHA-2 >3: RSA/AES-CTR-256/SHA-2 > >The argument for suite 3 being that if something catastrophic does happen in >the processing world there is a last ditch fallback. > >I would limit the SHOULD suites to the DSA variants of the above but >excluding 3DES since the demand for DSA is likely to be restricted to people >who want NIST acredited crypto and 3DES ain't acredited. > >4: DSA/AES-CTR-128/SHA-2 >5: DSA/AES-CTR-256/SHA-2 > >I don't want any other suites. I don't want EC variants, I don't want a >different chaining mode for each day of the week. > >One thing that would be very useful for integration with specs in the Web >Services space is if a unique URN was specified for each suite. EG >urn:ietf:rfcxxx:cryptosuite-1 > >This would then allow the suite specification to be specified in negotiation >at the Web services level. So that a UDDI directory or WSDL could contain a >policy statement that says 'this service requires the use of IPSEC >cryptosuite 2 or 4'. > >Note that we have fewer suites in total than we had symmetric algs for IKE1. > > > Phill > >> -----Original Message----- >> From: Alex Alten [mailto:Alten@attbi.com] >> Sent: Friday, August 30, 2002 2:33 AM >> To: Charlie_Kaufman@notesdev.ibm.com; ipsec@lists.tislabs.com >> Subject: Re: Last ditch proposal for crypto suites >> >> >> At 05:58 PM 8/29/2002 -0400, Charlie_Kaufman@notesdev.ibm.com wrote: >> > >> >I propose that we remove the text for a la carte negotiation >> from the IKEv2 >> >spec, >> ... >> >> I'm amazed that after so many years the WG is still arguing >> over this issue >> (or maybe I'm not). As Steve B. pointed out interoperability >> and buggy code >> are very important considerations. >> >> We only need to spec two MUST have suites. RSA/3DES-CBC/SHA-1 and >> RSA/AES-CTR-128/SHA-2. Forget the rest, they are going into >> the dustbin >> of history. Details like PFS, HMAC should be the same across >> the suites. >> >> What I'll add, along with my vote to do suites, is that the >> receiver MUST >> accept whatever suite the sender chooses to use. This will >> make life a lot >> easier and will not be a "security" problem. The difference >> between 3DES and >> AES-128 is minor. What we are really after is to provide an >> upgrade path from >> 3DES to AES, to gain the huge performance improvement and yet >> not screw our >> existing customers. >> >> Choose the mandatory suites wisely and sparingly. Once the >> IKEv2 dust has >> settled there will be much more difficult fish to fry. >> >> Good luck Charlie & Co., >> >> - Alex >> >> -- >> >> Alex Alten >> Alten@ATTBI.com >> > -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Fri Aug 30 07:54: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 g7UEst209613; Fri, 30 Aug 2002 07:54:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18338 Fri, 30 Aug 2002 10:15:15 -0400 (EDT) Message-Id: <200208301419.KAA13761@nwmail.wh.lucent.com> Content-Type: text/plain; charset="windows-1251" From: Uri Blumenthal Reply-To: uri@bell-labs.com Organization: Lucent Technologies / Bell Labs To: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites Date: Fri, 30 Aug 2002 10:14:59 -0400 X-Mailer: KMail [version 1.3.2] References: <200208300424.g7U4OkL21725@sydney.East.Sun.COM> In-Reply-To: <200208300424.g7U4OkL21725@sydney.East.Sun.COM> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA18242 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Friday 30 August 2002 00:24, Radia Perlman - Boston Center for Networking wrote: > >> In the IKEv2 spec., transforms may have attributes (Sec. 7.3.2 and > >> Appendix A). I was wondering about how that would work with > >> suites in a proposal. > > All values of all attributes would be predefined in the definition of > the suite. So for instance, the suite wouldn't be "AES" with an > attribute of key size, but instead the suite would specity "AES with > 128 bit keys". Can an explicitly specified attribute override what's predefined in the suite? Yes, no, it depends? In some cases (like key size) it might be desirable... Administration complexity - how high? -- Regards, Uri-David -=-=-<>-=-=- From owner-ipsec@lists.tislabs.com Fri Aug 30 07:56: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 g7UEuA209736; Fri, 30 Aug 2002 07:56:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18331 Fri, 30 Aug 2002 10:14:16 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15727.33046.544595.574674@pkoning.dev.equallogic.com> Date: Fri, 30 Aug 2002 10:28:38 -0400 From: Paul Koning To: Alten@attbi.com Cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites References: <3.0.3.32.20020829233313.013a6040@mail> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Alex" == Alex Alten writes: Alex> At 05:58 PM 8/29/2002 -0400, Charlie_Kaufman@notesdev.ibm.com Alex> wrote: >> I propose that we remove the text for a la carte negotiation from >> the IKEv2 spec, Alex> ... Alex> We only need to spec two MUST have suites. RSA/3DES-CBC/SHA-1 Alex> and RSA/AES-CTR-128/SHA-2. Forget the rest, they are going Alex> into the dustbin of history. Details like PFS, HMAC should be Alex> the same across the suites. I almost agree, except I'd make the second SHA-1 since SHA-2 is so new. If people insist on SHA-2, then add RSA/AES/SHA-1 instead, as a third suite. paul From owner-ipsec@lists.tislabs.com Fri Aug 30 08:31: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 g7UFUx211594; Fri, 30 Aug 2002 08:30:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18509 Fri, 30 Aug 2002 10:46:00 -0400 (EDT) Message-ID: From: "Walker, Jesse" To: "'Paul Koning'" , Alten@attbi.com Cc: ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites Date: Fri, 30 Aug 2002 08:00:10 -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 Hi Paul, I agree with you. SHA1 is the right choice. No one has presented a plausible argument why IPsec should migrate to SHA2 for data origin authenticity. There are other selections needed to complete the cipher suite: 1. PRF 2. Diffie-Hellman group 3. RSA key size SHA2 might be an appropriate choice to use in the PRF, given that was designed with the intent of supporting 128- and 256-bit key derivation. I am only raising a point for discussion, not making or defending a suggestion. -- Jesse > -----Original Message----- > From: Paul Koning [mailto:pkoning@equallogic.com] > Sent: Friday, August 30, 2002 7:29 AM > To: Alten@attbi.com > Cc: Charlie_Kaufman@notesdev.ibm.com; ipsec@lists.tislabs.com > Subject: Re: Last ditch proposal for crypto suites > > > >>>>> "Alex" == Alex Alten writes: > > Alex> At 05:58 PM 8/29/2002 -0400, Charlie_Kaufman@notesdev.ibm.com > Alex> wrote: > >> I propose that we remove the text for a la carte negotiation from > >> the IKEv2 spec, > Alex> ... > > Alex> We only need to spec two MUST have suites. RSA/3DES-CBC/SHA-1 > Alex> and RSA/AES-CTR-128/SHA-2. Forget the rest, they are going > Alex> into the dustbin of history. Details like PFS, HMAC should be > Alex> the same across the suites. > > I almost agree, except I'd make the second SHA-1 since SHA-2 is so > new. If people insist on SHA-2, then add RSA/AES/SHA-1 instead, as a > third suite. > > paul > From owner-ipsec@lists.tislabs.com Fri Aug 30 09:14: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 g7UGEe213319; Fri, 30 Aug 2002 09:14:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18824 Fri, 30 Aug 2002 11:31:44 -0400 (EDT) Date: Fri, 30 Aug 2002 09:44:46 -0600 Message-Id: <200208301544.g7UFikO17982@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think the original argument against suites came from observing how many SSL had. Hilarie From owner-ipsec@lists.tislabs.com Fri Aug 30 09:14: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 g7UGEs213338; Fri, 30 Aug 2002 09:14:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18841 Fri, 30 Aug 2002 11:33:49 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40DF2DD26@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites Date: Fri, 30 Aug 2002 08:49:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I support the proposal, only I would substitute the words 'highly flammable' for bombproof. Actually as a practical matter IETF should archive all drafts and all proposals in perpetuity, or at least for 30 years. The value of IDs as prior art is very significant. Phill > > The strong and nearly unanimous reaction to this question > this time leads > me to make a more radical proposal: > > I propose that we remove the text for a la carte negotiation > from the IKEv2 > spec, and escrow it in a bombproof vault somewhere in case future > generations want it, and replace it with the proposal from my > last message > for specifying suites only. If we ever need a la carte, we > have a backwards compatible way to add it in, but in the > meantime we won't > specify it. And if we're lucky, no one will ever miss it. > > --Charlie > > Opinions expressed may not even by mine by the time you read them, and > certainly don't reflect those of any other entity (legal or > otherwise). > From owner-ipsec@lists.tislabs.com Fri Aug 30 09:16: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 g7UGGs213377; Fri, 30 Aug 2002 09:16:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18842 Fri, 30 Aug 2002 11:33:49 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40DF2DD25@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Alex Alten , "Hallam-Baker, Phillip" , Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites Date: Fri, 30 Aug 2002 08:49:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't think we should spec the RSA keystrengths since this is not typically a negotiated parameter, the parties tend to have one key and the trustworthiness of that key is the issue. i.e. the endpoint may reject a key because it does not accept the certificate (or other validation). If an end point rejects 1024 bit keys as a matter of policy that will be incorporated into the certification policy. What we should do however is to require that the implementations accept key sizes up to at least 2048 bits and possibly 4096. As a practical matter requiring keys to be multiples of 32 bits is also a good idea (there is a 1000 bit key in use). Phill > -----Original Message----- > From: Alex Alten [mailto:Alten@attbi.com] > Sent: Friday, August 30, 2002 10:22 AM > To: Hallam-Baker, Phillip; Charlie_Kaufman@notesdev.ibm.com; > ipsec@lists.tislabs.com > Subject: RE: Last ditch proposal for crypto suites > > > This sounds reasonable. Shouldn't we also spec the RSA key lengths? > And is 3DES-CBC doing EDE or EEE? (I assume EDE is preferable?) > > - Alex > > > At 06:45 AM 8/30/2002 -0700, Hallam-Baker, Phillip wrote: > >Actually following on from Radia's point I think we would > have three suites: > > > >1: RSA/3DES-CBC/SHA-1 > >2: RSA/AES-CTR-128/SHA-2 > >3: RSA/AES-CTR-256/SHA-2 > > > >The argument for suite 3 being that if something > catastrophic does happen in > >the processing world there is a last ditch fallback. > > > >I would limit the SHOULD suites to the DSA variants of the above but > >excluding 3DES since the demand for DSA is likely to be > restricted to people > >who want NIST acredited crypto and 3DES ain't acredited. > > > >4: DSA/AES-CTR-128/SHA-2 > >5: DSA/AES-CTR-256/SHA-2 > > > >I don't want any other suites. I don't want EC variants, I > don't want a > >different chaining mode for each day of the week. > > > >One thing that would be very useful for integration with > specs in the Web > >Services space is if a unique URN was specified for each suite. EG > >urn:ietf:rfcxxx:cryptosuite-1 > > > >This would then allow the suite specification to be > specified in negotiation > >at the Web services level. So that a UDDI directory or WSDL > could contain a > >policy statement that says 'this service requires the use of IPSEC > >cryptosuite 2 or 4'. > > > >Note that we have fewer suites in total than we had > symmetric algs for IKE1. > > > > > > Phill > > > >> -----Original Message----- > >> From: Alex Alten [mailto:Alten@attbi.com] > >> Sent: Friday, August 30, 2002 2:33 AM > >> To: Charlie_Kaufman@notesdev.ibm.com; ipsec@lists.tislabs.com > >> Subject: Re: Last ditch proposal for crypto suites > >> > >> > >> At 05:58 PM 8/29/2002 -0400, > Charlie_Kaufman@notesdev.ibm.com wrote: > >> > > >> >I propose that we remove the text for a la carte negotiation > >> from the IKEv2 > >> >spec, > >> ... > >> > >> I'm amazed that after so many years the WG is still arguing > >> over this issue > >> (or maybe I'm not). As Steve B. pointed out interoperability > >> and buggy code > >> are very important considerations. > >> > >> We only need to spec two MUST have suites. RSA/3DES-CBC/SHA-1 and > >> RSA/AES-CTR-128/SHA-2. Forget the rest, they are going into > >> the dustbin > >> of history. Details like PFS, HMAC should be the same across > >> the suites. > >> > >> What I'll add, along with my vote to do suites, is that the > >> receiver MUST > >> accept whatever suite the sender chooses to use. This will > >> make life a lot > >> easier and will not be a "security" problem. The difference > >> between 3DES and > >> AES-128 is minor. What we are really after is to provide an > >> upgrade path from > >> 3DES to AES, to gain the huge performance improvement and yet > >> not screw our > >> existing customers. > >> > >> Choose the mandatory suites wisely and sparingly. Once the > >> IKEv2 dust has > >> settled there will be much more difficult fish to fry. > >> > >> Good luck Charlie & Co., > >> > >> - Alex > >> > >> -- > >> > >> Alex Alten > >> Alten@ATTBI.com > >> > > > -- > > Alex Alten > Alten@ATTBI.com > From owner-ipsec@lists.tislabs.com Fri Aug 30 09:46: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 g7UGkl213983; Fri, 30 Aug 2002 09:46:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19024 Fri, 30 Aug 2002 12:05:21 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15727.39708.303643.638692@pkoning.dev.equallogic.com> Date: Fri, 30 Aug 2002 12:19:40 -0400 From: Paul Koning To: uri@bell-labs.com Cc: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites References: <200208300424.g7U4OkL21725@sydney.East.Sun.COM> <200208301419.KAA13761@nwmail.wh.lucent.com> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Uri" == Uri Blumenthal writes: Uri> On Friday 30 August 2002 00:24, Radia Perlman - Boston Center Uri> for Networking wrote: >> >> In the IKEv2 spec., transforms may have attributes (Sec. 7.3.2 >> and >> Appendix A). I was wondering about how that would work >> with >> suites in a proposal. >> >> All values of all attributes would be predefined in the definition >> of the suite. So for instance, the suite wouldn't be "AES" with an >> attribute of key size, but instead the suite would specity "AES >> with 128 bit keys". Uri> Can an explicitly specified attribute override what's predefined Uri> in the suite? Yes, no, it depends? NO! It has to be no, otherwise you're back doing a la carte. paul From owner-ipsec@lists.tislabs.com Fri Aug 30 09:46: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 g7UGko213995; Fri, 30 Aug 2002 09:46:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19025 Fri, 30 Aug 2002 12:05:23 -0400 (EDT) From: "Ron Kiefer" To: "Alex Alten" , "Hallam-Baker, Phillip" , , Subject: Please remove me from your mailing lists. Date: Fri, 30 Aug 2002 12:20:00 -0400 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3.0.3.32.20020830072212.014558e0@mail> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sincerely, Ron Kiefer Cisco Security1, CCNP Southern Graphic Systems Office 502-635-8184 Cell 502-558-6531 rjkiefer@sgsintl.com -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Alex Alten Sent: Friday, August 30, 2002 10:22 AM To: Hallam-Baker, Phillip; Charlie_Kaufman@notesdev.ibm.com; ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites This sounds reasonable. Shouldn't we also spec the RSA key lengths? And is 3DES-CBC doing EDE or EEE? (I assume EDE is preferable?) - Alex At 06:45 AM 8/30/2002 -0700, Hallam-Baker, Phillip wrote: >Actually following on from Radia's point I think we would have three suites: > >1: RSA/3DES-CBC/SHA-1 >2: RSA/AES-CTR-128/SHA-2 >3: RSA/AES-CTR-256/SHA-2 > >The argument for suite 3 being that if something catastrophic does happen in >the processing world there is a last ditch fallback. > >I would limit the SHOULD suites to the DSA variants of the above but >excluding 3DES since the demand for DSA is likely to be restricted to people >who want NIST acredited crypto and 3DES ain't acredited. > >4: DSA/AES-CTR-128/SHA-2 >5: DSA/AES-CTR-256/SHA-2 > >I don't want any other suites. I don't want EC variants, I don't want a >different chaining mode for each day of the week. > >One thing that would be very useful for integration with specs in the Web >Services space is if a unique URN was specified for each suite. EG >urn:ietf:rfcxxx:cryptosuite-1 > >This would then allow the suite specification to be specified in negotiation >at the Web services level. So that a UDDI directory or WSDL could contain a >policy statement that says 'this service requires the use of IPSEC >cryptosuite 2 or 4'. > >Note that we have fewer suites in total than we had symmetric algs for IKE1. > > > Phill > >> -----Original Message----- >> From: Alex Alten [mailto:Alten@attbi.com] >> Sent: Friday, August 30, 2002 2:33 AM >> To: Charlie_Kaufman@notesdev.ibm.com; ipsec@lists.tislabs.com >> Subject: Re: Last ditch proposal for crypto suites >> >> >> At 05:58 PM 8/29/2002 -0400, Charlie_Kaufman@notesdev.ibm.com wrote: >> > >> >I propose that we remove the text for a la carte negotiation >> from the IKEv2 >> >spec, >> ... >> >> I'm amazed that after so many years the WG is still arguing >> over this issue >> (or maybe I'm not). As Steve B. pointed out interoperability >> and buggy code >> are very important considerations. >> >> We only need to spec two MUST have suites. RSA/3DES-CBC/SHA-1 and >> RSA/AES-CTR-128/SHA-2. Forget the rest, they are going into >> the dustbin >> of history. Details like PFS, HMAC should be the same across >> the suites. >> >> What I'll add, along with my vote to do suites, is that the >> receiver MUST >> accept whatever suite the sender chooses to use. This will >> make life a lot >> easier and will not be a "security" problem. The difference >> between 3DES and >> AES-128 is minor. What we are really after is to provide an >> upgrade path from >> 3DES to AES, to gain the huge performance improvement and yet >> not screw our >> existing customers. >> >> Choose the mandatory suites wisely and sparingly. Once the >> IKEv2 dust has >> settled there will be much more difficult fish to fry. >> >> Good luck Charlie & Co., >> >> - Alex >> >> -- >> >> Alex Alten >> Alten@ATTBI.com >> > -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Fri Aug 30 10:09: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 g7UH9X216056; Fri, 30 Aug 2002 10:09:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19168 Fri, 30 Aug 2002 12:28:41 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40DF2DD46@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "The Purple Streak, Hilarie Orman" , ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites Date: Fri, 30 Aug 2002 09:45:06 -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 think the original argument against suites came from observing how > many SSL had. I think that that was largely the result of TLS being specified at a time when RSA was still encumbered and bona-fide MAC functions had not been developed. We are talking about 3 MUST suites and 2 MAY suites maximum. IKE1 had 9 encryption ciphers alone. Phill From owner-ipsec@lists.tislabs.com Fri Aug 30 10: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 g7UHO2217384; Fri, 30 Aug 2002 10:24:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19286 Fri, 30 Aug 2002 12:44:07 -0400 (EDT) Message-Id: <3.0.3.32.20020830095652.014820c8@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 30 Aug 2002 09:56:52 -0700 To: "Walker, Jesse" , "'Paul Koning'" From: Alex Alten Subject: RE: Last ditch proposal for crypto suites Cc: ipsec@lists.tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I know SHA-2 is a bit new, but I think it is worth it for the following good reasons. 1. It's better to just have one hash in the suite for all uses. As a rule of thumb I always try to select a hash with twice the bits of the corresponding block cipher, mainly because of because of the square root attack (birthday attack). So AES-128 should use SHA2-256. 2. SHA-2 is scalable, with different hash lengths available (256, 384, 512), which compliment AES key lengths nicely. Assuming SHA-2 holds up then this will give us a simple implementation path to be forward compatible without issuing a new RFC for a new flavor-of-the-year hash. - Alex At 08:00 AM 8/30/2002 -0700, Walker, Jesse wrote: >Hi Paul, > >I agree with you. SHA1 is the right choice. No one has presented a plausible >argument why IPsec should migrate to SHA2 for data origin authenticity. > >There are other selections needed to complete the cipher suite: > >1. PRF >2. Diffie-Hellman group >3. RSA key size > >SHA2 might be an appropriate choice to use in the PRF, given that was >designed with the intent of supporting 128- and 256-bit key derivation. I am >only raising a point for discussion, not making or defending a suggestion. > >-- Jesse > -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Fri Aug 30 10:40: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 g7UHe8219208; Fri, 30 Aug 2002 10:40:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19343 Fri, 30 Aug 2002 12:54:19 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15727.42679.858233.625026@pkoning.dev.equallogic.com> Date: Fri, 30 Aug 2002 13:09:11 -0400 From: Paul Koning To: Alten@attbi.com Cc: jesse.walker@intel.com, ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites References: <3.0.3.32.20020830095652.014820c8@mail> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Alex" == Alex Alten writes: Alex> I know SHA-2 is a bit new, but I think it is worth it for the Alex> following good reasons. Alex> ... I don't think those are good reasons to throw cryptographic caution to the wind. paul From owner-ipsec@lists.tislabs.com Fri Aug 30 10:47: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 g7UHl7219367; Fri, 30 Aug 2002 10:47:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19401 Fri, 30 Aug 2002 13:01:26 -0400 (EDT) Message-Id: <200208301715.g7UHFe45009784@thunk.east.sun.com> From: Bill Sommerfeld To: "Hallam-Baker, Phillip" cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites In-Reply-To: Your message of "Fri, 30 Aug 2002 08:49:56 PDT." <2F3EC696EAEED311BB2D009027C3F4F40DF2DD25@vhqpostal.verisign.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 30 Aug 2002 13:15:40 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > As a practical matter requiring keys to be multiples of 32 bits is > also a good idea (there is a 1000 bit key in use). Could you expand on this? I don't see how this helps either interoperability or security. We've run into interoperability issues when moving private keys between different RSA implementations due to assumptions made about the precise modulus size or the precise size of the primes. I'd hate to see the same happen for public keys as well, and I'd prefer to avoid forcing customers to regenerate their long-term keys to migrate to IKEv2. - Bill From owner-ipsec@lists.tislabs.com Fri Aug 30 11:04: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 g7UI41219771; Fri, 30 Aug 2002 11:04:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19564 Fri, 30 Aug 2002 13:14:51 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869B87@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'sommerfeld@east.sun.com'" , "Hallam-Baker, Phillip" Cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites Date: Fri, 30 Aug 2002 10:30:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > As a practical matter requiring keys to be multiples of 32 bits is > > also a good idea (there is a 1000 bit key in use). > > Could you expand on this? I don't see how this helps either > interoperability or security. Long ago we generated a 1000 bit key and discovered all sorts of interesting bugs when other people tried to use the cert with their code. Basically it is a matter of testing the large integer math on the crypto toolkits and being sure it has been done. > We've run into interoperability issues when moving private keys > between different RSA implementations due to assumptions made about > the precise modulus size or the precise size of the primes. > > I'd hate to see the same happen for public keys as well, and I'd > prefer to avoid forcing customers to regenerate their long-term keys > to migrate to IKEv2. Are odd key sizes common? I would see this as very much an 'accept all/only generate' type situation. Clearly there is no value in forcing regenration of keys. However I am somewhat nervous about the support and interoperability for odd shaped key sizes. Again it is an issue of testing. I think it is reasonable to test a key pair of every size from 1024 bits thru 2048 at 32 bit intervals, at 1 bit intervals it would get very tedious indeed. Also we can even specify test vectors at those intervals. Phill From owner-ipsec@lists.tislabs.com Fri Aug 30 11:04: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 g7UI41219772; Fri, 30 Aug 2002 11:04:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19535 Fri, 30 Aug 2002 13:11:49 -0400 (EDT) To: "The Purple Streak, Hilarie Orman" Cc: ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites References: <200208301544.g7UFikO17982@localhost.localdomain> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 30 Aug 2002 10:28:36 -0700 In-Reply-To: "The Purple Streak, Hilarie Orman"'s message of "Fri, 30 Aug 2002 09:44:46 -0600" Message-ID: Lines: 16 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "The Purple Streak, Hilarie Orman" writes: > I think the original argument against suites came from observing how > many SSL had. Indeed. I've got nothing against cipher suites but I'd like to see something in the document describing the procedure for registering new cipher suites. Not having such a procedure has been a substantial point of contention with TLS. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Fri Aug 30 11: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 g7UI5w219848; Fri, 30 Aug 2002 11:05:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19634 Fri, 30 Aug 2002 13:22:57 -0400 (EDT) Message-Id: <200208301737.AGA46684@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 30 Aug 2002 10:22:09 -0700 To: "Hallam-Baker, Phillip" , Alex Alten , Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com From: Scott Fluhrer Subject: RE: Last ditch proposal for crypto suites In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40DF2DCA2@vhqpostal.verisig n.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 06:45 AM 8/30/02 , Hallam-Baker, Phillip wrote: >Actually following on from Radia's point I think we would have three suites: > >1: RSA/3DES-CBC/SHA-1 >2: RSA/AES-CTR-128/SHA-2 >3: RSA/AES-CTR-256/SHA-2 One problem with mandating AES counter mode is that there's been quite a bit of hardware development that assumed the AES CBC mode draft. Some of it can be changed to use counter mode without too much pain and effort, but some of it can't. If these are MUST suites, this means that those implementations cannot do IKEv2 efficiently, not because they cannot do the IKEv2 protocol itself, but because they cannot do the negotiated IPSec transforms. I would suggest that this is not in the IETF's best interest to impose such limitations. -- scott From owner-ipsec@lists.tislabs.com Fri Aug 30 11:07: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 g7UI76219893; Fri, 30 Aug 2002 11:07:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19605 Fri, 30 Aug 2002 13:18:55 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15727.44113.263383.84182@pkoning.dev.equallogic.com> Date: Fri, 30 Aug 2002 13:33:05 -0400 From: Paul Koning To: ho@alum.mit.edu Cc: ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites References: <200208301544.g7UFikO17982@localhost.localdomain> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Hilarie" == The Purple Streak writes: Hilarie> I think the original argument against suites came from Hilarie> observing how many SSL had. True, but in practice only about one was implemented... :-) At least 75% of that quantity comes from obsolete political considerations. If you delete all "*export*" and all DES and DES40 suites, the list is pretty small. paul From owner-ipsec@lists.tislabs.com Fri Aug 30 11:20: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 g7UIKF220224; Fri, 30 Aug 2002 11:20:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19697 Fri, 30 Aug 2002 13:32:13 -0400 (EDT) Message-Id: <200208301746.g7UHkl45011988@thunk.east.sun.com> From: Bill Sommerfeld To: "Hallam-Baker, Phillip" cc: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites In-Reply-To: Your message of "Fri, 30 Aug 2002 10:30:36 PDT." <2F3EC696EAEED311BB2D009027C3F4F405869B87@vhqpostal.verisign.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 30 Aug 2002 13:46:46 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Are odd key sizes common? I keep running into them so they can't be that rare. A long time ago, i asked pgp for a 1024 bit key and it generated a 1022 bit key instead. When I was migrating between different ssh implementations I noticed the newer one whining about 1023-bit keys generated by the older one. The more recent case (less directly analagous) involved a 1024-bit modulus which had factors of 513 and 512 bits; when we moved the private key to an alternate RSA implementation, it bumped into a misplaced test which assumed the factors of the modulus would be exactly half the size of the modulus. (had the test not been there, the code would have worked; the fix was to weaken the test). > Again it is an issue of testing. agreed. > I think it is reasonable to test a key pair of every size from 1024 > bits thru 2048 at 32 bit intervals, at 1 bit intervals it would get > very tedious indeed. yes, though based on the keys i've seen "in the wild", I'd suggest that testing 1-bit intervals clustered around "popular" moduli sizes would have more realistic coverage than every 32-bits. - Bill From owner-ipsec@lists.tislabs.com Fri Aug 30 11:30: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 g7UIUi220670; Fri, 30 Aug 2002 11:30:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19764 Fri, 30 Aug 2002 13:40:26 -0400 (EDT) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869B8C@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Scott Fluhrer'" , "Hallam-Baker, Phillip" , Alex Alten , Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: RE: Last ditch proposal for crypto suites Date: Fri, 30 Aug 2002 10:51:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK how about a different arrangement, each suite is specified as follows 1 RSA/3DES-CBC/SHA-1 Required Provide alternative to AES 2 RSA/AES-CTR-128/SHA-2 Required AES is prefered cryptography algorithm for IETF protocols (see SAAG discussion) CTR mode is preferred 3 RSA/AES-CTR-256/SHA-2 Required Support highest security version of AES 4 RSA/AES-CBC-128/SHA-2 Optional Compatibility mode for use with hardware that does not support CTR efficiently 5 DSA/AES-CTR-128/SHA-2 Optional Backup for use in case that RSA is compromised. Support applications that require DSA for certification reasons 6 DSA/AES-CTR-256/SHA-2 Optional Long key version of #5 Then at the end of the discussion we go through the list and decide which to cull. Phill > -----Original Message----- > From: Scott Fluhrer [mailto:sfluhrer@cisco.com] > Sent: Friday, August 30, 2002 1:22 PM > To: Hallam-Baker, Phillip; Alex Alten; > Charlie_Kaufman@notesdev.ibm.com; > ipsec@lists.tislabs.com > Subject: RE: Last ditch proposal for crypto suites > > > At 06:45 AM 8/30/02 , Hallam-Baker, Phillip wrote: > >Actually following on from Radia's point I think we would > have three suites: > > > >1: RSA/3DES-CBC/SHA-1 > >2: RSA/AES-CTR-128/SHA-2 > >3: RSA/AES-CTR-256/SHA-2 > > One problem with mandating AES counter mode is that there's > been quite a bit > of hardware development that assumed the AES CBC mode draft. > Some of it can > be changed to use counter mode without too much pain and > effort, but some of > it can't. If these are MUST suites, this means that those > implementations > cannot do IKEv2 efficiently, not because they cannot do the > IKEv2 protocol > itself, but because they cannot do the negotiated IPSec > transforms. I would > suggest that this is not in the IETF's best interest to impose such > limitations. > > > -- > scott > > From owner-ipsec@lists.tislabs.com Fri Aug 30 11:31: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 g7UIVJ220692; Fri, 30 Aug 2002 11:31:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19825 Fri, 30 Aug 2002 13:47:38 -0400 (EDT) Message-Id: <3.0.3.32.20020830105947.0145a6a8@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 30 Aug 2002 10:59:47 -0700 To: Scott Fluhrer , "Hallam-Baker, Phillip" , Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com From: Alex Alten Subject: RE: Last ditch proposal for crypto suites In-Reply-To: <200208301737.AGA46684@mira-sjcm-3.cisco.com> References: <2F3EC696EAEED311BB2D009027C3F4F40DF2DCA2@vhqpostal.verisig n.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:22 AM 8/30/2002 -0700, Scott Fluhrer wrote: >At 06:45 AM 8/30/02 , Hallam-Baker, Phillip wrote: >>Actually following on from Radia's point I think we would have three suites: >> >>1: RSA/3DES-CBC/SHA-1 >>2: RSA/AES-CTR-128/SHA-2 >>3: RSA/AES-CTR-256/SHA-2 > >One problem with mandating AES counter mode is that there's been quite a bit >of hardware development that assumed the AES CBC mode draft. Some of it can >be changed to use counter mode without too much pain and effort, but some of >it can't. If these are MUST suites, this means that those implementations >cannot do IKEv2 efficiently, not because they cannot do the IKEv2 protocol >itself, but because they cannot do the negotiated IPSec transforms. I would >suggest that this is not in the IETF's best interest to impose such >limitations. > You bring up an excellent point. It's not as if we will save much padding. The real issue is further out beyond the immediate pain of those who jumped the gun. What about the significant performance optimization that can be achieved with CTR v.s CBC? Doesn't this make CTR the best choice in the long run? Let's pick one or the other, but not both. - Alex -- Alex Alten Alten@ATTBI.com From owner-ipsec@lists.tislabs.com Fri Aug 30 11:41: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 g7UIf8220885; Fri, 30 Aug 2002 11:41:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19959 Fri, 30 Aug 2002 13:59:21 -0400 (EDT) Message-ID: <3D6FBE5A.EEF99159@univ-reims.fr> Date: Fri, 30 Aug 2002 20:50:03 +0200 From: =?iso-8859-1?Q?Hac=E8ne?= FOUCHAL X-Mailer: Mozilla 4.75 [fr] (Win98; U) X-Accept-Language: fr MIME-Version: 1.0 To: "Hacene.Fouchal@univ-reims.fr" , "alain.bui@univ-reims.fr" , "olivier.flauzac@univ-reims.fr" , "Michael.Krajecki" Subject: OPODIS DEADLINE EXTENSION to sept 15th Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mail.univ-reims.fr id g7UGbm719157 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA19332 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [please accept our sincere apologies if you receive this message more than once... But don't hesitate to distribute the first copy] Paper Submission Deadline: EXTENDED to SEPTEMBER 15th 6th International Conference On Principles Of DIstributed Systems OPODIS'02 December 11-13, 2002, Reims, France http://www.univ-reims.fr/opodis02 ************ Invited Speakers T. Bolognesi (CNR, Pisa, Italy) M. Cosnard (Inria Sophia Antipolis, France) L. Lamport (Microsoft, San Fransisco, USA) ************ Program co-Chairs A. Bui (Univ. Reims Champagne-Ardenne) H. Fouchal (Univ. Reims Champagne-Ardenne) ************ Aims and Scopes of the Conference The 6th International Conference On Principles Of Distributed Systems is an open forum for the exchange of state-of-the-art knowledge on Distributed Computing among researchers from around the world. This conference is the sixth in a series of annual conferences. The program committee is soliciting research contributions to the design, analysis theory and specification of Distributed Systems. ************ Topics of interest include, but are not limited to, Distributed Systems: concepts and design Distributed Algorithms Concurrency Control and Synchronization Self-stabilization, Reliability and Fault-Tolerance Performance Analysis and Distributed Complexity Networks Security, Routing and Communication Techniques Cooperative Distributed Information Systems Distributed computing issues in LANs, WANs and the Internet Mobile Computing Fundamental topics for distributed computing Formal Techniques GRID Computing ************ Program Committee J. Beauquier (Univ. of Paris 11, France) G. Bernard (INT, Evry, France) M. Bui (Univ. of Paris 8, France) O. Carvalho (Univ. Fed. Minas Geras, Brazil) J. Carlier (Univ. of Compiègne, France) R. Castanet (Univ. of Bordeaux, France) R. Gomez-Cardenas(CEM-ITESM, Mexico) S.K. Das (Univ. of Texas at Arlington, USA) A.K. Datta (Univ. of Nevada Las Vegas, USA) K. Drira (LAAS, Toulouse, France) T. Higashino (Osaka Univ., Japan) I. Lavallée (Univ. of Paris 8, France) R. Y. Lee (Central Michigan Univ., USA) T. Masuzawa (Osaka Univ., Japan) D. Mery (Univ. of Nancy, France) J.F. Myoupo (Univ. of Amiens, France) Y. Paker (Queen Mary Univ., UK) M. Papatriantafilou (Univ. of Göteborg, Sweden) I.D. Scherson (Univ. of California at Irvine, USA) A. Shvartsman (Univ. of Connecticut/MIT, USA) N. Santoro (Carleton Univ. , Canada) P. Tsigas (Univ. of Chalmers, Sweden) V. Villain (Univ. of Amiens, France) ************ Organizing Committee O. Flauzac (Univ. Reims Champagne-Ardenne) M. Krajecki (Univ. Reims Champagne-Ardenne) ************ Paper Submission Submitted papers must be written in English and should not exceed 12 pages using 11-point font and reasonable margins, including figures, tables and references. First page, must include the title of the paper, author(s) names and affiliation, postal address, fax number, email, address for correspondence, up to 5 keywords and an abstract of no more 250 words. Each paper will receive a minimum of two reviews from Program Committee members and some external reviewers. Authors should submit their paper electronically in printable postscript format or in PDF format at : opodis02@univ-reims.fr Accepted papers will be published in the Proceedings of the Conference. It is required that each accepted paper be presented at the conference by one of its authors. For any further information, please contact us at : opodis02@univ-reims.fr ************ Sponsors Université de Reims Champagne-Ardenne Ville de Reims CNRS (pending) Sun D-FI ASF (ACM SIGOPS French chapter) ************ Important Dates Paper Submission Deadline: Sep 1st, 2002 extended to Sep 15th Notification of Acceptance: Oct 15, 2002 extended to Oct 25th Early registration : October 30, 2002 Camera Ready Papers Due : November 15, 2002 Conference: December 11-13, 2002 From owner-ipsec@lists.tislabs.com Fri Aug 30 12:47: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 g7UJlw223627; Fri, 30 Aug 2002 12:47:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20317 Fri, 30 Aug 2002 15:04:19 -0400 (EDT) Message-Id: <200208301918.g7UJI6F8012380@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: suites - phase 1 vs 2 In-reply-to: Your message of "Fri, 30 Aug 2002 10:28:38 EDT." <15727.33046.544595.574674@pkoning.dev.equallogic.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 30 Aug 2002 15:18:02 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Charlie, I'm not clear if we are going to define common suites for *both* phase 1 and 2 use. If we are, then I think that we should seperate the phase 1 authentication algorithm from the phase 1 cipher/encryption routine. i.e. they should be negotiated seperately. There are two reasons: 1) proposing RSA/3DES-CBC/SHA-1 vs DSA/3DES-CBC/SHA-1 is meaningless for phase 2. They are the same thing. (at least, until something like HIP comes along) 2) if we are going to reuse the suites, then what does 3DES-CBC/SHA-1/LZS mean for phase 1? I'd say that it is meaningless and we forbid suites that specify compression from being proposed for phase 1. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPW/ExoqHRg3pndX9AQEVswQAubDYt9Wm68cHHTJQqsGlGi8u5Q/P9hWU LR0qBPrztUWO3R7IILOXFRkeAImM5rDGaQ8tABooFR1IHPwSakV2jw0sFpzbRW5J aJvH5a15WsyjF/elxcWIych7WMJo7Nez9Ievzmq/C1MWOb/yn/3PJTZuR16a+6ZE CEHhDLqENzU= =QBoU -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Aug 30 12:48: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 g7UJmA223645; Fri, 30 Aug 2002 12:48:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20329 Fri, 30 Aug 2002 15:05:20 -0400 (EDT) Date: Fri, 30 Aug 2002 12:19:40 -0700 (PDT) From: Jan Vilhuber To: "Hallam-Baker, Phillip" cc: "The Purple Streak, Hilarie Orman" , Subject: RE: Last ditch proposal for crypto suites In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40DF2DD46@vhqpostal.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Much as I'd like to specify RSA only suites, I don't think reality will let us get away with this. We'll need pre-shared key suites as well. Make the RSA suites MUST and the pre-shared key suites MAY. jan On Fri, 30 Aug 2002, Hallam-Baker, Phillip wrote: > > > I think the original argument against suites came from observing how > > many SSL had. > > I think that that was largely the result of TLS being specified at a time > when RSA was still encumbered and bona-fide MAC functions had not been > developed. > > We are talking about 3 MUST suites and 2 MAY suites maximum. IKE1 had 9 > encryption ciphers alone. > > > Phill > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Fri Aug 30 12:50: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 g7UJoA223714; Fri, 30 Aug 2002 12:50:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20365 Fri, 30 Aug 2002 15:08:28 -0400 (EDT) Message-ID: <3D6FC615.89384379@bstormnetworks.com> Date: Fri, 30 Aug 2002 12:23:01 -0700 From: "Scott G. Kelly" Organization: BlackStorm Networks X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-5custom i686) X-Accept-Language: en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: "The Purple Streak, Hilarie Orman" , ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites References: <2F3EC696EAEED311BB2D009027C3F4F40DF2DD46@vhqpostal.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2002 19:23:03.0210 (UTC) FILETIME=[A8FB10A0:01C2505A] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Hallam-Baker, Phillip" wrote: > > > I think the original argument against suites came from observing how > > many SSL had. > > I think that that was largely the result of TLS being specified at a time > when RSA was still encumbered and bona-fide MAC functions had not been > developed. > > We are talking about 3 MUST suites and 2 MAY suites maximum. IKE1 had 9 > encryption ciphers alone. I'm not sure how (or if) we actually arrived this conclusion, and I don't see how we can possibly make this work with just 3 suites. For example, I know the pk vendors would like to see nothing but RSA-based authentication mandated, but until the market fully embraces public key technology, we must have preshared key support. Whether we choose suites, a la carte, or both, there will be practical reasons for supporting multiple authentication, encryption, and integrity mechanisms. Choosing suites doesn't, in and of itself, automagically reduce the number of algorithmic combinations we will provide support for; it simply reduces the number of ways in which each combination can be expressed, and thereby significantly simplifies the protocol. I should make clear that I agree with the general notion that we should try to reasonably limit the number of suites which are IANA-defined. However, we must be realistic and pragmatic. Scott From owner-ipsec@lists.tislabs.com Fri Aug 30 13:17: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 g7UKHu225829; Fri, 30 Aug 2002 13:17:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20494 Fri, 30 Aug 2002 15:37:22 -0400 (EDT) Date: Fri, 30 Aug 2002 12:51:52 -0700 (PDT) From: Jan Vilhuber To: "Scott G. Kelly" cc: "Hallam-Baker, Phillip" , "The Purple Streak, Hilarie Orman" , Subject: Re: Last ditch proposal for crypto suites In-Reply-To: <3D6FC615.89384379@bstormnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm wondering whether a hybrid approach would be reasonable: 1) Define suites for ciphers+mac (i.e. 3des-sha1, aes-sha2 whatever). 1') Tie phase 1 and phase 2 suites together, i.e. a suite applies to both (drawback: You now can't negotiate des for phase 1 and 3des for phase 2; seems there are those that want this). 2) define a separate 'thing' for the phase 1 authentication. 3) Not sure where to put compression... So you would propose: suite A (3des-sha1) authentication pre-shared or suite A (3des-sha1) rsa This may prevent some of the combinatorial explosion of having 3des-sha-pre-share and 3des-sha-rsa and 3des-sha-dsa, and instead you only have pre-share and 3des-sha as separate entities. *donning flame proof bathrobe, which I'm sure arthur dent would have loved to have* jan P.S. I guess this really boils down to having three sets of parameters: 1) joint phase 1 and phase 2 cipher suite 2) phase 1 ONLY settings (authentication... anything else?) 3) phase 2 ONLY settings (above and beyind ciphers, i.e. compression? Anything else?) On Fri, 30 Aug 2002, Scott G. Kelly wrote: > "Hallam-Baker, Phillip" wrote: > > > > > I think the original argument against suites came from observing how > > > many SSL had. > > > > I think that that was largely the result of TLS being specified at a time > > when RSA was still encumbered and bona-fide MAC functions had not been > > developed. > > > > We are talking about 3 MUST suites and 2 MAY suites maximum. IKE1 had 9 > > encryption ciphers alone. > > I'm not sure how (or if) we actually arrived this conclusion, and I > don't see how we can possibly make this work with just 3 suites. For > example, I know the pk vendors would like to see nothing but RSA-based > authentication mandated, but until the market fully embraces public key > technology, we must have preshared key support. > > Whether we choose suites, a la carte, or both, there will be practical > reasons for supporting multiple authentication, encryption, and > integrity mechanisms. Choosing suites doesn't, in and of itself, > automagically reduce the number of algorithmic combinations we will > provide support for; it simply reduces the number of ways in which each > combination can be expressed, and thereby significantly simplifies the > protocol. > > I should make clear that I agree with the general notion that we should > try to reasonably limit the number of suites which are IANA-defined. > However, we must be realistic and pragmatic. > > Scott > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 http://www.eff.org/cafe From owner-ipsec@lists.tislabs.com Fri Aug 30 13:27: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 g7UKRX226064; Fri, 30 Aug 2002 13:27:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20537 Fri, 30 Aug 2002 15:42:39 -0400 (EDT) From: "Andrew Wenlang Zhu" To: Subject: IPSec v6 on linux Date: Fri, 30 Aug 2002 12:57:32 -0700 Message-ID: <000801c2505f$7b3bff80$6f690d0f@AZ735043> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <15727.44113.263383.84182@pkoning.dev.equallogic.com> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello: I am use Red hat Linux with kernel 2.4.18. Does anybody aware any IPsec can support IPV6 on this kernel? Thanks, Andrew From owner-ipsec@lists.tislabs.com Fri Aug 30 14:10: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 g7ULAj229799; Fri, 30 Aug 2002 14:10:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20810 Fri, 30 Aug 2002 16:25:26 -0400 (EDT) To: Paul Koning Cc: ho@alum.mit.edu, ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites References: <200208301544.g7UFikO17982@localhost.localdomain> <15727.44113.263383.84182@pkoning.dev.equallogic.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 30 Aug 2002 13:41:56 -0700 In-Reply-To: Paul Koning's message of "Fri, 30 Aug 2002 13:33:05 -0400" Message-ID: Lines: 38 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning writes: > >>>>> "Hilarie" == The Purple Streak writes: > > Hilarie> I think the original argument against suites came from > Hilarie> observing how many SSL had. > > True, but in practice only about one was implemented... :-) Pretty much all msjor implementations support: RSA*RC4*{MD5,SHA} RSA*{DES,3DES}*SHA And this will soon include AES. > At least 75% of that quantity comes from obsolete political > considerations. If you delete all "*export*" and all DES and DES40 > suites, the list is pretty small. I'm not sure what you mean by political considerations. The only political considerations I know of in the original SSLv3 documents were the export cipher suites. There were perfectly good reasons to have DES, 3DES, and RC4 (though the reasons for DES are diminished by AES). I suspect you may be referring to the DH/DSS cipher suites as well. I don't know for sure why those were there, but I don't believe that it was in fact political, since it was done before DH/DSS went royalty free and Netscape had an RSA license anyway. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Fri Aug 30 14:18: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 g7ULIX200906; Fri, 30 Aug 2002 14:18:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20860 Fri, 30 Aug 2002 16:35:30 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15727.55906.238840.215016@pkoning.dev.equallogic.com> Date: Fri, 30 Aug 2002 16:49:38 -0400 From: Paul Koning To: ekr@rtfm.com Cc: ho@alum.mit.edu, ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites References: <200208301544.g7UFikO17982@localhost.localdomain> <15727.44113.263383.84182@pkoning.dev.equallogic.com> X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Eric" == Eric Rescorla writes: Eric> Paul Koning writes: >> At least 75% of that quantity comes from obsolete political >> considerations. If you delete all "*export*" and all DES and DES40 >> suites, the list is pretty small. Eric> I'm not sure what you mean by political considerations. Eric> The only political considerations I know of in the original Eric> SSLv3 documents were the export cipher suites. There were Eric> perfectly good reasons to have DES, 3DES, and RC4 (though the Eric> reasons for DES are diminished by AES). I was mostly referring to the export control stuff, and you're right, that's only about a third of the total. Then again, while there may have been fairly good reasons back then to include DES, those clearly no longer apply. Eric> I suspect you may be referring to the DH/DSS cipher suites as Eric> well. I don't know for sure why those were there, but I don't Eric> believe that it was in fact political, since it was done before Eric> DH/DSS went royalty free and Netscape had an RSA license Eric> anyway. I wasn't, but that's another place where the situation has changed significantly. The summary point I would make is this: SSL has a long list of suites for a lot of reasons. A lot of these are no longer applicable, and some of the rest don't apply to IPsec. (For example, RC4 is a sensible cipher for SSL, but not applicable to IPsec.) Trying to argue against suites based on the length of the SSL suite list is misleading. paul From owner-ipsec@lists.tislabs.com Fri Aug 30 14:21: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 g7ULLV201309; Fri, 30 Aug 2002 14:21:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20892 Fri, 30 Aug 2002 16:39:38 -0400 (EDT) To: Paul Koning Cc: ho@alum.mit.edu, ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites References: <200208301544.g7UFikO17982@localhost.localdomain> <15727.44113.263383.84182@pkoning.dev.equallogic.com> <15727.55906.238840.215016@pkoning.dev.equallogic.com> Reply-to: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 30 Aug 2002 13:56:40 -0700 In-Reply-To: Paul Koning's message of "Fri, 30 Aug 2002 16:49:38 -0400" Message-ID: Lines: 39 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning writes: > I was mostly referring to the export control stuff, and you're right, > that's only about a third of the total. > > Then again, while there may have been fairly good reasons back then to > include DES, those clearly no longer apply. Yes, because we now have AES. > Eric> I suspect you may be referring to the DH/DSS cipher suites as > Eric> well. I don't know for sure why those were there, but I don't > Eric> believe that it was in fact political, since it was done before > Eric> DH/DSS went royalty free and Netscape had an RSA license > Eric> anyway. > > I wasn't, but that's another place where the situation has changed > significantly. Actually, it hasn't as much as you'd think. Aside from the brief period when DH was royalty free and RSA was not, the rationale for DH was PFS. In practice it turns out that noone really cares about PFS, at least for SSL. OTOH, it's possible that noone would care about PFS for IPsec if we weren't so set on giving it to them :( > Trying to > argue against suites based on the length of the SSL suite list is > misleading. The current problem with cipher suites is much more about vanity algorithms than it is about the length of the existing cipher suite list. Because suites are monolithic, a vanity algorithm means defining 5-8 new suites, not just one algorithm ID. That's why I'd like to see IPsec have rules for what it takes to add a new algorithm ID. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Fri Aug 30 15:06: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 g7UM6L202825; Fri, 30 Aug 2002 15:06:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA21122 Fri, 30 Aug 2002 17:23:54 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <200208301419.KAA13761@nwmail.wh.lucent.com> Subject: Re: Last ditch proposal for crypto suites To: uri@bell-labs.com Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_08092002NP August 09, 2002 Message-ID: Date: Fri, 30 Aug 2002 17:36:10 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_08272002NP|August 27, 2002) at 08/30/2002 05:32:33 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Can an explicitly specified attribute override what's predefined in the > suite? Yes, no, it depends? No means no. Suites have no attributes or parameters. That said, cryptographic algorithms that are not negotiated need not be part of suites. At least at the level of the specification, it is easier to let them be independent. What does this mean? Whether an endpoint authenticates by signing with a 1024 bit RSA key, a 2048 bit RSA key, a 1024 bit DSS key, or an HMAC based on a password is not negotiated. There is no place in the protocol where you tell the other end what sort of authentication you want because the presumption is that the other end has only one way to authenticate and you're going to take it or leave it. (If there were multiple ways to authenticate and you really wanted to hide preferences in the protocol, you could do so in the CERTREQ field saying what authorities you trust - different algorithms could - and probably in practice do - live under different authorities). So I maintain that suites should not say anything about authentication algorithms. We don't - but probably should - say something about must implement authentication algorithms & key sizes. But there is no obvious reason to tie these to the suites used to protect the data. (In IKEv1 there was, because different key types resulted in different protocol exchanges. In IKEv2, they only affect the AUTH payload, and it is explicitly allowed for one end to authenticate with an HMAC based on a password while the other end authenticates with a DSS key and certificates. I hope this doesn't open a can of worms, because if someone demanded it be otherwise I wouldn't know how to do it. --Charlie Opinions expressed may not even by mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Fri Aug 30 15:22: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 g7UMM9203378; Fri, 30 Aug 2002 15:22:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA21190 Fri, 30 Aug 2002 17:38:23 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <200208301918.g7UJI6F8012380@marajade.sandelman.ottawa.on.ca> Subject: Re: suites - phase 1 vs 2 To: Michael Richardson Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V60_08092002NP August 09, 2002 Message-ID: Date: Fri, 30 Aug 2002 17:48:20 -0400 X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_08272002NP|August 27, 2002) at 08/30/2002 05:47:09 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I'm not clear if we are going to define common suites for *both* phase 1 and > 2 use. If we are, then I think that we should seperate the phase 1 > authentication algorithm from the phase 1 cipher/encryption > routine. i.e. they should be negotiated seperately. > > There are two reasons: > 1) proposing RSA/3DES-CBC/SHA-1 vs DSA/3DES-CBC/SHA-1 is meaningless > for phase 2. They are the same thing. > (at least, until something like HIP comes along) > > 2) if we are going to reuse the suites, then what > does 3DES-CBC/SHA-1/LZS mean for phase 1? I'd say that > it is meaningless and we forbid suites that specify compression > from being proposed for phase 1. I'm trying not to use the terms phase 1 and phase 2 algorithms because phase 1 negotiates both an IKE-SA and a Child-SA (ESP and/or AH and/or IPcomp). I believe the definition of a suite should include the protocol it is securing. That means we need a minimum of two suites: one of IKE and one for ESP. People are likely to want additional suites for ESP+IPcomp, for AH, and for who knows what other combinations. If suites are independent of protocol, we will end up negotiating suite and protocol separately and face a different n*m explosion of possibilities. I'd like to shoot for a single MUST implement suite for each of IKE and ESP, and make all other algorithms and protocols optional. But I'm a wild-eyed dreamer. --Charlie Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From owner-ipsec@lists.tislabs.com Fri Aug 30 17:56: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 g7V0ug209962; Fri, 30 Aug 2002 17:56:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA21545 Fri, 30 Aug 2002 20:09:30 -0400 (EDT) Message-Id: <200208310023.g7V0Ne45017224@thunk.east.sun.com> From: Bill Sommerfeld To: Charlie_Kaufman@notesdev.ibm.com cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: suites - phase 1 vs 2 In-Reply-To: Your message of "Fri, 30 Aug 2002 17:48:20 EDT." Reply-to: sommerfeld@east.sun.com Date: Fri, 30 Aug 2002 20:23:40 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I believe the definition of a suite should include the protocol it > is securing. Agreed. > That means we need a minimum of two suites: one of IKE and one for > ESP. Yes, and we end up with (at least) two types of suites: one for IKE protecting itself, and one for each of the protocols that IKE manages (whether you look at this as a single "IPsec" protocol or as independant "AH", "ESP", and "IPcomp" is another question). - Bill From owner-ipsec@lists.tislabs.com Fri Aug 30 18:55: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 g7V1tS215068; Fri, 30 Aug 2002 18:55:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA21658 Fri, 30 Aug 2002 21:10:07 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: EKR Cc: "The Purple Streak, Hilarie Orman" , ipsec@lists.tislabs.com Subject: Re: Last ditch proposal for crypto suites Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Aug 2002 19:41:42 -0400 Message-Id: <20020830234142.A3D337B64@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Eric Rescorla writes: >"The Purple Streak, Hilarie Orman" writes: > >> I think the original argument against suites came from observing how >> many SSL had. > >Indeed. I've got nothing against cipher suites but I'd like >to see something in the document describing the procedure >for registering new cipher suites. Not having such a procedure >has been a substantial point of contention with TLS. > In fact, given that suites require IANA-administered code points, some statement in the document is mandatory -- see RFC 2434 for a description of how to write an "IANA Considerations" section. In particular, see the example policies at the end of Section 3. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book) From owner-ipsec@lists.tislabs.com Fri Aug 30 21:04: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 g7V44v219328; Fri, 30 Aug 2002 21:04:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA21910 Fri, 30 Aug 2002 23:11:38 -0400 (EDT) Date: Fri, 30 Aug 2002 23:26:08 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: RE: Last ditch proposal for crypto suites In-Reply-To: <3.0.3.32.20020830072212.014558e0@mail> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 30 Aug 2002, Alex Alten wrote: > And is 3DES-CBC doing EDE or EEE? (I assume EDE is preferable?) EDE is what all existing implementations (some of them in hardware) do. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Sat Aug 31 01:01: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 g7V81Q221177; Sat, 31 Aug 2002 01:01:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA22385 Sat, 31 Aug 2002 03:12:22 -0400 (EDT) From: Sabrina Minshall Message-Id: <200208310726.AAA28078@shell.accesscom.com> Subject: ICMP error generation To: ipsec@lists.tislabs.com Date: Sat, 31 Aug 2002 00:26:43 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DCC-Hypersurf-Metrics: mercury.hypersurf.com 1047; Body=1 Fuz1=1 Fuz2=1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, suppose a VPN gateway encrypts a packet and the next hop to the tunnel (endpoint) is unreachable. What should be done? Should the packet be dropped (without generating an ICMP host/net unreachable?). Any pointers? sabrina From owner-ipsec@lists.tislabs.com Sat Aug 31 02:33: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 g7V9X2229039; Sat, 31 Aug 2002 02:33:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA22551 Sat, 31 Aug 2002 04:42:37 -0400 (EDT) Date: 31 Aug 2002 04:40:16 -0400 Message-ID: <003201c250ca$09a9e420$a873e640@ca.alcatel.com> From: "Andrew Krywaniuk" Reply-To: andrew.krywaniuk@alcatel.com To: "'list'" Subject: RE: Last ditch proposal for crypto suites 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 > Indeed. I've got nothing against cipher suites but I'd like > to see something in the document describing the procedure > for registering new cipher suites. Not having such a procedure > has been a substantial point of contention with TLS. I think it was I who brought up the example of TLS at one of the IETFs. I don't normally attend TLS meetings, but I happened to go that one time (London?) when almost the entire session was devoted to ciphersuites. Someone was trying to add the Camilla cipher (apparently it is essential for penetration into the Japanese market), and at the same time there was a proposal for adding the PFS variants and RSA I think as well. Each of these entailed a full permutation of options. I can't deny that there now appears to be widespread support for ciphersuites, although perhaps for the wrong reasons(*). But I fear that we are still riding that initial wave of exuberance that comes with agreeing to agree, while the dirty work of actually agreeing lingers in the background. Phill somewhat naively suggested that we could get away with 3 suites: > >1: RSA/3DES-CBC/SHA-1 > >2: RSA/AES-CTR-128/SHA-2 > >3: RSA/AES-CTR-256/SHA-2 These choices display one particular view on the progression of suites, but the problem is that you could ask this question to 10 people and get 10 different replies. Most of this WG seems to be anti-SHA-2, and some of the 64-bit people are anti-SHA-1. Then there are those who think Rijndael is insecure and we should use 3DES (or one of the other finalists), and a lot of people who don't think AES-256 is necessary. Those of us who do remote access would argue that IPCOMP is necessary for all permutations. These examples also conspicuously omit pre-shared keys, NULL-encryption, AH, PFS, PRFs, MACs and DH in general. (*) Almost all of the arguments presented for suites dealt with the conceptual issue of suites vs. ala carte. In fact, no one ever denied that suites are a good idea. The issue was whether to do GUI suites or suites at the protocol layer. Very few of the comments on this list dealt with the issue of whether the cost of comparing a list of attributes was worth the benefit. Since DH is now negotiated via abort & retry, it is actually not absolutely necessary to specify the DH group in the wire protocol specification of the suite, but since the suite is actually two things (a GUI concept and an on-the-wire format), for the sake of interoperability it is desirable to specify the DH group within the suite. This is likely to be a huge bone of contention, especially considering the ECC vs. MODP issue. My argument for GUI suites rather than suites at a protocol level is entirely political and has nothing to do with technical merit. I find it doubtful that we will be able to agree on a small set of suites that everyone agrees on. The IANA considerations for adding new suites will no doubt require a standards track RFC. I have some reservations about this process, mainly motivated by the fact that it takes around 3 years for a draft to reach RFC status in this WG. That's why I was advocating a hierarchical textual namespace rather than an IANA assigned numberspace. 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 Eric Rescorla > Sent: Friday, August 30, 2002 1:29 PM > To: The Purple Streak, Hilarie Orman > Cc: ipsec@lists.tislabs.com > Subject: Re: Last ditch proposal for crypto suites > > > "The Purple Streak, Hilarie Orman" writes: > > > I think the original argument against suites came from observing how > > many SSL had. > > Indeed. I've got nothing against cipher suites but I'd like > to see something in the document describing the procedure > for registering new cipher suites. Not having such a procedure > has been a substantial point of contention with TLS. > > -Ekr > > > -- > [Eric Rescorla ekr@rtfm.com] > http://www.rtfm.com/ >