From owner-ipsec@lists.tislabs.com Sat Jul 1 18:10:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12485; Sat, 1 Jul 2000 18:10:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16478 Sat, 1 Jul 2000 19:23:50 -0400 (EDT) From: "Scott Fanning" To: "Vlado Zafirov" , Cc: "'Stephane Beaulieu'" , Subject: RE: Comments on: draft-vlado-ipsec-keep-alive-00.txt Date: Sat, 1 Jul 2000 16:33:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <395CF2C7.3EA350A8@radware.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well, I for one applaud the effort. Regardless of its technical merit, we should be encouraging different ideas in the WG. So lets argue the technical merits. BTW: I thought at the end of the WG in Australia, that we were not sure if this problem should be solved in the IPSec / IPSra space? Was there not a point about what the problem we are trying to solve may not be something for IPSec but for IP (Something like that). Scott > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Vlado Zafirov > Sent: Friday, June 30, 2000 12:20 PM > To: andrew.krywaniuk@alcatel.com > Cc: 'Stephane Beaulieu'; ipsec@lists.tislabs.com > Subject: Re: Comments on: draft-vlado-ipsec-keep-alive-00.txt > > > Andrew, > I am describing the use. If you think that it's a good idea > to show more > examples and ways to use it I will do it. > I read you draft. It's great. Don't get me like competitor > or enemy. I am > trying to do is give an idea. May be it is bad, may be not > Just go ahead with questions that you wanna see and let me > try answer them. > > Hey we're here to make the best possible standards available for > IPsec, right? > > Andrew Krywaniuk wrote: > > > My comment on complexity: > > > > There is syntactic complexity and there is operational > complexity. It is > > possible to trade off one for the other. > > > > My draft attempts to answer the question "How do you deal with > situation X?" > > for all scenerios that were expounded on this list. Therefore, > it is long > > but very precise. It's operation is simplified because there is no > > ambiguity. > > > > Vlado's draft is short (when you remove all the dead weight) and > > syntactically very simple because it only describes the > message format and > > not its use. It remains to be seen whether its operation will > still appear > > simple when multiple vendors' differing applications of the > protocol are > > permuted against our already very divergent implementations of IKE. > > > > Andrew > > -------------------------------------- > > Beauty with out truth is insubstantial. > > Truth without beauty is unbearable. > > > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Vlado > > > Sent: Thursday, June 29, 2000 3:17 PM > > > To: Scott G. Kelly > > > Cc: Stephane Beaulieu; ipsec@lists.tislabs.com > > > Subject: Re: Comments on: draft-vlado-ipsec-keep-alive-00.txt > > > > > > > > > Hi Scott, > > > I don't thnk so. I think this simpler alogirthm is doing > > > the same job with less > > > bandwith, faster processing AND EASY implementation. There is > > > some things to be added > > > > > > 1. Negotiation (this is only for backward compability) - This > > > can easy. The software > > > can have option - keep-alive on,off,auto. In auto mode > > > initiator sends keep-alive > > > packets, if he receives ISAKMP > > > Info message UNSUPPORTED-EXCHANGE-TYPE then he knows the > > > other end doesn't support > > > that exchange. > > > > > > 2. This can be further updated with rule: use keep-alive when > > > there is no traffic for > > > that SA for certain amount of time, default equal to the > > > keep-alive time. > > > > > > > > > "Scott G. Kelly" wrote: > > > > > > > Comments below - > > > > > > > > Vlado Zafirov wrote: > > > > > > > > > > Hi Stephane, > > > > > Well that's my first internet-draft I ever > > > published so please excuse me > > > > > for any mistakes I made. > > > > > > > > > > I meant to make very simple, low-bandwidth and easy to > > > implement exchange. > > > > > > > > > > I read very fast the proposal draft that you was so kind > > > to send me. It' very > > > > > very good. However I believe too complicated and needs a > > > lot of work > > > > > to be implemented and it's pretty bandwidth intesive. > > > > > > > > > > About comments: > > > > > 1. Yes, it's not a problem. I will make that change > > > and resubmit the draft. > > > > > However when Client dies it's just simple mater of > > > reconnecting. Usually > > > > > problem is when Secure Gateway loose connection > > > because it's should be > > > > > restarted or this connection dropped manually. > > > > > > > > > > 2. I didn't thought of that and I was not aware of > > > that practice. Thank you > > > > > so much for the feedback. This will be changed too. > > > > > > > > > > Stephane Beaulieu wrote: > > > > > > > > > > > Hi Vlado, > > > > > > > > > > > > I'm not sure if you were aware of it, but there is > > > another Internet-Draft > > > > > > whose goal it is to provide the same functionality. See > > > > > > http://www.vpnc.org/draft-ietf-ipsec-heartbeats > > > > > > > > > > > > It has received quite a bit of feedback, and I think > > > that most people are > > > > > > pretty satisfied with it. > > > > > > > > This is absolute nonsense. Take a straw poll right now. > > > > > > > > > > > > > > > > All in all, I think the rough consensus was that a much simpler > > > > mechanism would suffice. > > > > > > > > Scott > > > > > > > > > > > -- > Vlado Zafirov > RADWare, INC > Technical Support Engineer > Tel: (202) 625-1505 > Fax: (202) 625-1506 > > Confidentiality Note: This e-mail, and any attachment to it, > contains privileged > and confidential information intended only for the use of the > individual(s) or > entity > named in the e-mail. If the reader of this e-mail is not the > intended recipient, > or the employee or agent responsible for delivering it to the intended > recipient, you are > hereby notified that reading it is strictly prohibited. If you > have received > this e-mail in error, please immediately return it to the sender > and delete it > from your system. > Thank you. > > > > > From owner-ipsec@lists.tislabs.com Mon Jul 3 03:47:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA14011; Mon, 3 Jul 2000 03:47:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA20093 Mon, 3 Jul 2000 04:33:51 -0400 (EDT) Message-ID: <20000703084217.9803.qmail@web3502.mail.yahoo.com> Date: Mon, 3 Jul 2000 01:42:17 -0700 (PDT) From: Eva Jencusova To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Could someone help me to find some documents about prooving of correctness of ISAKMP or some documents about analysis of ISAKMP ? Thanks. Eva Jencusova __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ From owner-ipsec@lists.tislabs.com Mon Jul 3 12:15:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26241; Mon, 3 Jul 2000 12:15:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21988 Mon, 3 Jul 2000 13:50:12 -0400 (EDT) Message-ID: <3960D475.98AECB2B@storm.ca> Date: Mon, 03 Jul 2000 13:59:17 -0400 From: Sandy Harris Organization: Global Village Idiots X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Eva Jencusova CC: ipsec@lists.tislabs.com Subject: Re: analysis of ISAKMP References: <20000703084217.9803.qmail@web3502.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Eva Jencusova wrote: > > Could someone help me to find some documents about > prooving of correctness of ISAKMP or some documents > about analysis of ISAKMP ? > > Thanks. > Eva Jencusova >From the file links.ipsec.html in the FreeS/WAN documentation. This is from just-released version 1.5. Web site at: htpp://www.freeswan.org has not yet been updated, has 1.4 docs Analysis and critiques of IPSEC protocols Counterpane's evaluation of the protocols (on counterpane.com) Simpson's IKE Considered Dangerous paper. Note that this is a link to an archive of our mailing list. There are several replies in addition to the paper itself. http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/06/msg00319.html Bellovin's papers page including his: Security Problems in the TCP/IP Protocol Suite (1989) Problem Areas for the IP Security Protocols (1996) Probable Plaintext Cryptanalysis of the IP Security Protocols (1997) http://www.research.att.com/~smb/papers/index.html An errata list for the IPSEC RFCs. http://www.lounge.org/ike_doi_errata.html If anyone knows of additional links that should be on that list, please let me know. From owner-ipsec@lists.tislabs.com Mon Jul 3 15:09:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28223; Mon, 3 Jul 2000 15:09:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22581 Mon, 3 Jul 2000 16:59:55 -0400 (EDT) Message-Id: <3.0.5.32.20000703171332.007c9840@email.nist.gov> X-Sender: sfrankel@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 03 Jul 2000 17:13:32 -0400 To: Sandy Harris From: Sheila Frankel Subject: Re: analysis of ISAKMP Cc: ipsec@lists.tislabs.com, Eva Jencusova In-Reply-To: <3960D475.98AECB2B@storm.ca> References: <20000703084217.9803.qmail@web3502.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Catherine Meadows of NRL applied the NRL Protocol Analyzer to IKE. Her paper can be found at: http://chacs.nrl.navy.mil/publications/CHACS/1999/1999meadows-IEEE99.{ps,pdf} > >If anyone knows of additional links that should be on that list, please >let me know. > > From owner-ipsec@lists.tislabs.com Tue Jul 4 12:21:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26013; Tue, 4 Jul 2000 12:21:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25903 Tue, 4 Jul 2000 13:32:27 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Vlado Zafirov'" Cc: Subject: RE: Comments on: draft-vlado-ipsec-keep-alive-00.txt Date: Tue, 4 Jul 2000 13:36:04 -0400 Message-Id: <000a01bfe5de$5526f4a0$d23e788a@andrewk3.ca.newbridge.com> 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 V4.72.2106.4 Importance: Normal In-Reply-To: <395CF2C7.3EA350A8@radware.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Vlado, You could get an idea of the issues to which I am referring by browsing the archives of this list for December, February, and March. Some of the issues: - Is the protocol self-stabilizing? - How does the protocol deal with DoS (or even DDoS) attempts? (and how do we ensure that a poor implementation cannot help to effect a DoS attack on the peer?) - Can the processing of the messages be optimized by not using encyption? - How does the protocol deal with so-called "dangling" phase 2s? (ipsec sa's that persist after the isakmp sa has been deleted) - How do we deal with very low bandwidth peers (e.g. wireless)? - What do we do if the peer wants to drop the link layer connection without deleting the sa? - How should the protocol be used in conjunction with load sharing? - How can the protocol be revised later? - How SHOULD the protocol actually be used? Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Vlado Zafirov [mailto:vladoz@radware.com] > Sent: Friday, June 30, 2000 3:20 PM > To: andrew.krywaniuk@alcatel.com > Cc: 'Stephane Beaulieu'; ipsec@lists.tislabs.com > Subject: Re: Comments on: draft-vlado-ipsec-keep-alive-00.txt > > > Andrew, > I am describing the use. If you think that it's a good > idea to show more > examples and ways to use it I will do it. > I read you draft. It's great. Don't get me like > competitor or enemy. I am > trying to do is give an idea. May be it is bad, may be not > Just go ahead with questions that you wanna see and let > me try answer them. > > Hey we're here to make the best possible standards available > for IPsec, right? > > Andrew Krywaniuk wrote: > > > My comment on complexity: > > > > There is syntactic complexity and there is operational > complexity. It is > > possible to trade off one for the other. > > > > My draft attempts to answer the question "How do you deal > with situation X?" > > for all scenerios that were expounded on this list. > Therefore, it is long > > but very precise. It's operation is simplified because there is no > > ambiguity. > > > > Vlado's draft is short (when you remove all the dead weight) and > > syntactically very simple because it only describes the > message format and > > not its use. It remains to be seen whether its operation > will still appear > > simple when multiple vendors' differing applications of the > protocol are > > permuted against our already very divergent implementations of IKE. > > > > Andrew > > -------------------------------------- > > Beauty with out truth is insubstantial. > > Truth without beauty is unbearable. > > > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Vlado > > > Sent: Thursday, June 29, 2000 3:17 PM > > > To: Scott G. Kelly > > > Cc: Stephane Beaulieu; ipsec@lists.tislabs.com > > > Subject: Re: Comments on: draft-vlado-ipsec-keep-alive-00.txt > > > > > > > > > Hi Scott, > > > I don't thnk so. I think this simpler alogirthm is doing > > > the same job with less > > > bandwith, faster processing AND EASY implementation. There is > > > some things to be added > > > > > > 1. Negotiation (this is only for backward compability) - This > > > can easy. The software > > > can have option - keep-alive on,off,auto. In auto mode > > > initiator sends keep-alive > > > packets, if he receives ISAKMP > > > Info message UNSUPPORTED-EXCHANGE-TYPE then he knows the > > > other end doesn't support > > > that exchange. > > > > > > 2. This can be further updated with rule: use keep-alive when > > > there is no traffic for > > > that SA for certain amount of time, default equal to the > > > keep-alive time. > > > > > > > > > "Scott G. Kelly" wrote: > > > > > > > Comments below - > > > > > > > > Vlado Zafirov wrote: > > > > > > > > > > Hi Stephane, > > > > > Well that's my first internet-draft I ever > > > published so please excuse me > > > > > for any mistakes I made. > > > > > > > > > > I meant to make very simple, low-bandwidth and easy to > > > implement exchange. > > > > > > > > > > I read very fast the proposal draft that you was so kind > > > to send me. It' very > > > > > very good. However I believe too complicated and needs a > > > lot of work > > > > > to be implemented and it's pretty bandwidth intesive. > > > > > > > > > > About comments: > > > > > 1. Yes, it's not a problem. I will make that change > > > and resubmit the draft. > > > > > However when Client dies it's just simple mater of > > > reconnecting. Usually > > > > > problem is when Secure Gateway loose connection > > > because it's should be > > > > > restarted or this connection dropped manually. > > > > > > > > > > 2. I didn't thought of that and I was not aware of > > > that practice. Thank you > > > > > so much for the feedback. This will be changed too. > > > > > > > > > > Stephane Beaulieu wrote: > > > > > > > > > > > Hi Vlado, > > > > > > > > > > > > I'm not sure if you were aware of it, but there is > > > another Internet-Draft > > > > > > whose goal it is to provide the same functionality. See > > > > > > http://www.vpnc.org/draft-ietf-ipsec-heartbeats > > > > > > > > > > > > It has received quite a bit of feedback, and I think > > > that most people are > > > > > > pretty satisfied with it. > > > > > > > > This is absolute nonsense. Take a straw poll right now. > > > > > > > > > > > > > > > > All in all, I think the rough consensus was that a much simpler > > > > mechanism would suffice. > > > > > > > > Scott > > > > > > > > > > > -- > Vlado Zafirov > RADWare, INC > Technical Support Engineer > Tel: (202) 625-1505 > Fax: (202) 625-1506 > > Confidentiality Note: This e-mail, and any attachment to it, > contains privileged > and confidential information intended only for the use of the > individual(s) or > entity > named in the e-mail. If the reader of this e-mail is not the > intended recipient, > or the employee or agent responsible for delivering it to the intended > recipient, you are > hereby notified that reading it is strictly prohibited. If > you have received > this e-mail in error, please immediately return it to the > sender and delete it > from your system. > Thank you. > > > From owner-ipsec@lists.tislabs.com Thu Jul 6 16:06:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02491; Thu, 6 Jul 2000 16:06:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01335 Thu, 6 Jul 2000 16:58:44 -0400 (EDT) Date: Thu, 6 Jul 2000 17:10:08 -0400 Message-Id: <200007062110.RAA01323@trampoline.thunk.org> X-Authentication-Warning: trampoline.thunk.org: tytso set sender to tytso@trampoline.thunk.org using -f To: ipsec@lists.tislabs.com Subject: Call for agenda topics for Pittsburgh IETF From: tytso@mit.edu Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As I'm sure you all know, the Pittsburgh IETF is rapidly approaching. The cutoff for Internet-Draft submissions is Friday, July 14th. If you have an updated draft to submit, please make sure it gets submitted by then. If you have a topic you'd like to bring up for discussion at the IPSEC wg meeting, please let me know by sending me e-mail. Thanks!! - Ted From owner-ipsec@lists.tislabs.com Fri Jul 7 05:37:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA11742; Fri, 7 Jul 2000 05:37:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA03343 Fri, 7 Jul 2000 06:55:21 -0400 (EDT) Message-Id: <200007071104.HAA20174@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-notifymsg-03.txt Date: Fri, 07 Jul 2000 07:04:24 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Content Requirements for ISAKMP Notify Messages Author(s) : S. Kelly, T. Kivinen Filename : draft-ietf-ipsec-notifymsg-03.txt Pages : 26 Date : 06-Jul-00 The ISAKMP and DOI RFCs [RFC2408, RFC2407] specify error and status message types for use in ISAKMP NOTIFY messages, but in some cases do not specify that any additional clarifying data be carried in the messages. In these cases, it is difficult to determine which SA corresponds to the received NOTIFY message. While the DOI RFC specifies content and formats for additional data in the currently defined IPSEC status messages, no such requirements are currently specified for ISAKMP NOTIFY messages. This document provides content and format recommendations for those messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-notifymsg-03.txt 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-notifymsg-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-notifymsg-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000706151900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-notifymsg-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-notifymsg-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000706151900.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jul 7 06:47:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA13722; Fri, 7 Jul 2000 06:47:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03704 Fri, 7 Jul 2000 08:16:45 -0400 (EDT) Message-ID: From: Jong Hui Sian To: "'ieeetcpc@ccvm.sunysb.edu'" Subject: 8th IEEE International Conference on Networks 2000 Date: Fri, 7 Jul 2000 18:51:24 +0800 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 Dear Sir/Madam Kindly ignore this if you have already registered to participatee in ICON 2000. CALL FOR PARTICIPATION * 8th IEEE International Conference on Networks 2000 * 5 - 8 September 2000 Please visit : http:\\www.comp.nus.edu.sg\~icon We are pleased to invite you to attend the 8th IEEE International Conference On Networks 2000 (ICON 2000) which will be held from September 5- 8, 2000 in Singapore. It is organized by the IEEE Singapore Computer Chapter and the Professional Activities Center, Faculty of Engineering, National University of Singapore with co-operation from the Nanyang Technological University. Two days of tutorials and two days of technical presentations are planned for this conference. The conference will also include invited speakers, exhibitions and special panel discussion sessions. The aim of the conference is to provide an international forum for experts to promote, share and discuss various issues and developments in the broad field of computer and communication networks. * * * ICON' 2000 will provide a forum to discuss recent advances in computer networks and communications. Contributions describing original research, surveys and applications including, but not restricted to, the following areas are solicited * Active/intelligent networks * BISDN and ATM * Congestion/admission control * Data traffic engineering and management * High speed network protocols * Internet services/applications * Multicast/broadcast protocols * Multimedia protocols and networking * Multiple access technology * Network architecture and protocol performance * Network management and control * Network monitoring * Converged data and telecom networks * Network security and privacy * Network signaling and connection management * Optical communication networks * Personal communication services * Quality of service * Routing and routing protocols * Storage area networks * Testbeds and measurements * Voice over internet * Virtual private networks * Wireless/mobile/satellite networks and protocols * Pervasive networks * Distributed storage * * * More details of the conference including the Advance Program and registration form may be found at our web site http:\\www.comp.nus.edu.sg\~icon . Please do not hesitate to contact us should you need further information. Thank you and looking forward to your attendance to IEEE ICON 2000. Yours sincerely IEEE ICON 2000 Secretariat Tel : (65) 874 5113 Fax : (65) 874 5097 E-mail : engicon@nus.edu.sg From owner-ipsec@lists.tislabs.com Fri Jul 7 08:19:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16793; Fri, 7 Jul 2000 08:19:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04069 Fri, 7 Jul 2000 10:03:34 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A02E37641@eseis06nok> To: ipsec@lists.tislabs.com Subject: Subnet and range IDs in Phase II Date: Fri, 7 Jul 2000 16:27:44 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How are these updated in the SAD? Is it allowed to specify a proxy as a subnet (addr + mask) when updating the SAD? The person who implemented my IPSEC says no but I think it must be possible to use SUBNET IDs. And how do people do it for an ADDR RANGE? Here's an example for the SUBNET case: H* - SG1 =========== SG2 (end host is the gateway itself) The policies are: SG1: H* <-> SG2(through tunnel with SG2 itself) SG2: SG2 <-> H*(through tunnel with SG1) The Phase II IDs will be H* (IPV4 SUBNET ID) and SG2 (IPV4 ID) When updating the SAD in SG2 the parameter for the: inbound SA should be SRC = SG1 DST = SG2 PROXY = SG2 outbound SA should be SRC = SG2 DST = SG2 PROXY = H* Is that right? Can someone provide a case when the RANGE IDs are used? I have no idea how to do it. (Maybe it's because my IPSEC only allows the specification of subnets and no ranges so it's limited to SUBNET IDs) Any help would be greatly appreciated. Toni From owner-ipsec@lists.tislabs.com Fri Jul 7 21:22:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA22904; Fri, 7 Jul 2000 21:22:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA06618 Fri, 7 Jul 2000 22:50:00 -0400 (EDT) Date: Fri, 7 Jul 2000 23:01:48 -0400 From: "Theodore Ts'o" Message-Id: <200007080301.XAA08856@trampoline.thunk.org> X-Authentication-Warning: trampoline.thunk.org: tytso set sender to tytso@mit.edu using -f To: ipsec@lists.tislabs.com Subject: WG Last call: draft-jenkins-ipsec-rekeying-06.txt Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tim Jenkins has requested that draft-jenkins-ipsec-rekeying-06.txt be advanced forward as an Informational RFC. Since this document has been discussed extensively within the IPSEC working group, it seems to make sense to do a last call period within the working group, and then advance this forward as a working group informational RFC, if there is consensus to do so. (Since otherwise it'll almost certainly get bounced back to us for review.) This last call period will last one week, and close on July 14, 2000. If you have any comments about this document, please send them to the ipsec mailing list. - Ted From owner-ipsec@lists.tislabs.com Fri Jul 7 21:22:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA22916; Fri, 7 Jul 2000 21:22:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA06624 Fri, 7 Jul 2000 22:50:41 -0400 (EDT) Date: Fri, 7 Jul 2000 23:02:30 -0400 From: "Theodore Ts'o" Message-Id: <200007080302.XAA08860@trampoline.thunk.org> X-Authentication-Warning: trampoline.thunk.org: tytso set sender to tytso@mit.edu using -f To: ipsec@lists.tislabs.com Subject: Re: WG Last call: draft-jenkins-ipsec-rekeying-06.txt Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ With my wg chair hat off ] While I was reviewing this document for the last call, it struck me that while most if it is supposed reflect implementation discussions, the last section, "4.5 Commit bit replacement", probably should be moved into an appendix, and much more clearly labelled as a proposal for a future revision of the ipsec protocols. Right now, it could quite easily be confused as being something implementors should implement, although without any assigned numbers or bits'n'bytes details, most implementors wouldn't get very far. The danger is that some implementor may invent the implementational details and claim conformance to the informational RFC, and that could harm interoperability. So this text needs to be explicitly set off from the rest of the discussion somehow. - Ted From owner-ipsec@lists.tislabs.com Mon Jul 10 05:17:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA23301; Mon, 10 Jul 2000 05:17:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA13641 Mon, 10 Jul 2000 06:23:01 -0400 (EDT) Message-Id: <200007101031.GAA02002@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: smug@cs.umass.edu, ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-irtf-smug-data-transforms-00.txt Date: Mon, 10 Jul 2000 06:31:50 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multicast Data Security Transformations: Requirements, Considerations, and Proposed Design Author(s) : R. Canetti, P. Rohatgi, P. Cheng Filename : draft-irtf-smug-data-transforms-00.txt Pages : 13 Date : 07-Jul-00 In the framework document , the Secure Multicast Group (SMuG) has identified three functionalities that deal with security transformations for the multicasted data. These are data encryption, source authentication, and group authentication. This document expands on the issues to be taken into consideration when designing transforms that realize these functionalities. These issues include the order of applying the transforms, their placement in the communication layers, possible aggregation of several functionalities in a single transform, and the relationships with other protocols (such as reliable multicast protocols). Next a specific design is proposed, that attempts to meet the requirements of prominent application in a simple yet flexible way. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-smug-data-transforms-00.txt 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-irtf-smug-data-transforms-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-irtf-smug-data-transforms-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000707143517.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-irtf-smug-data-transforms-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-irtf-smug-data-transforms-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000707143517.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Jul 10 06:16:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA24604; Mon, 10 Jul 2000 06:16:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13883 Mon, 10 Jul 2000 08:00:07 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A02E37659@eseis06nok> To: ipsec@lists.tislabs.com Subject: Subnet and range IDs in Phase II (corrected) Date: Mon, 10 Jul 2000 15:07:11 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Correction in the example. -----Original Message----- From: EXT antonio.barrera@nokia.com [mailto:antonio.barrera@nokia.com] Sent: 07. July 2000 16:28 To: ipsec@lists.tislabs.com Subject: Subnet and range IDs in Phase II How are these updated in the SAD? Is it allowed to specify a proxy as a subnet (addr + mask) when updating the SAD? The person who implemented my IPSEC says no but I think it must be possible to use SUBNET IDs. And how do people do it for an ADDR RANGE? Here's an example for the SUBNET case: H* - SG1 =========== SG2 (end host is the gateway itself) The policies are: SG1: H* <-> SG2(through tunnel with SG2 itself) SG2: SG2 <-> H*(through tunnel with SG1) The Phase II IDs will be H* (IPV4 SUBNET ID) and SG2 (IPV4 ID) When updating the SAD in SG2 the parameter for the: inbound SA should be SRC = SG1 DST = SG2 PROXY = SG2 outbound SA should be SRC = SG2 DST = SG1 PROXY = H* Is that right? Can someone provide a case when the RANGE IDs are used? I have no idea how to do it. (Maybe it's because my IPSEC only allows the specification of subnets and no ranges so it's limited to SUBNET IDs) Any help would be greatly appreciated. Toni From owner-ipsec@lists.tislabs.com Mon Jul 10 12:56:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09885; Mon, 10 Jul 2000 12:56:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15482 Mon, 10 Jul 2000 14:07:29 -0400 (EDT) Message-ID: <310508EDF557D31188FA0050DA0A37526586EF@CAT01S2> From: Tim Jenkins To: "'Theodore Ts'o'" , ipsec@lists.tislabs.com Subject: RE: WG Last call: draft-jenkins-ipsec-rekeying-06.txt Date: Mon, 10 Jul 2000 08:54:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ted, Thanks for the comments; I'll update the document by putting section 4.5 in its own section with some words to state that the proposal is incomplete and needs magic numbers. I'll hold off on other changes for a bit. There is one potential issue with the references, in that the document refers to which I believe has expired and has not been replaced. Do I need to do something with that? Thanks, Tim > -----Original Message----- > From: Theodore Ts'o [mailto:tytso@mit.edu] > Sent: Friday, July 07, 2000 11:03 PM > To: ipsec@lists.tislabs.com > Subject: Re: WG Last call: draft-jenkins-ipsec-rekeying-06.txt > > > > [ With my wg chair hat off ] > > While I was reviewing this document for the last call, it > struck me that > while most if it is supposed reflect implementation discussions, the > last section, "4.5 Commit bit replacement", probably should be moved > into an appendix, and much more clearly labelled as a proposal for a > future revision of the ipsec protocols. > > Right now, it could quite easily be confused as being something > implementors should implement, although without any assigned > numbers or > bits'n'bytes details, most implementors wouldn't get very far. The > danger is that some implementor may invent the > implementational details > and claim conformance to the informational RFC, and that could harm > interoperability. So this text needs to be explicitly set > off from the > rest of the discussion somehow. > > - Ted > From owner-ipsec@lists.tislabs.com Tue Jul 11 15:37:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA00831; Tue, 11 Jul 2000 15:37:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21115 Tue, 11 Jul 2000 16:30:22 -0400 (EDT) Date: Tue, 11 Jul 2000 16:41:24 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: IPsec List Subject: minor editorial suggestions for draft-jenkins-ipsec-rekeying-06.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This document suggests minor editorial changes to draft-jenkins-ipsec-rekeying-06.txt. We currently intend to send two messages with more substantive comments on the draft before the last call expires. All notes are on lines starting with ">> ". These notes are embedded in chunks of the original document to give context. Appropriate subsection headings are included to give context to the context :-) Internet Engineering Task Force Tim Jenkins IP Security Working Group Catena Networks Internet Draft May 3, 2000 IPsec Re-keying Issues This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 1. Introduction This document discusses issues associated with the use of protocols developed in the IETF's IPsec working group, specifically, RFC 2409 [IKE] and RFC 2408 [ISAKMP]. It is expected that the reader is familiar with those documents. >> Also draft-ietf-ipsec-ike-01.txt. >> (Perhaps draft-ietf-ipsec-ike-hash-revised-00.txt?) >> In the sequel, these will be refered to as the "IPsec documents". The first objective is to illustrate problems and issues associated with re-keying within the confines of the current set of IPsec documents. For a number of reasons, re-keying in IPsec has become >> ^^^^^^^^^^is problematic, such that IPsec implementations can drop packets during re-keying. Worse, there exists the possibility that IPsec implementations from different vendors may not be interoperable because of the way they re-key. 2. Phase 2 SA Re-keying It also does not assume that the implementation has specific knowledge about the peer's behaviour. In other words, the peer's behaviour is assumed to be any of those that may be potentially allowed by the documents. >> ^ IPsec 2.1 Phase 2 Re-keying Issues The issues associated with phase 2 re-keying are listed below. Some of the points are expanded upon later. 1) There is no specification explicitly defining how the transfer of traffic from old to new SAs is to be done. 2) The existing drafts appear contradictory in their recommendations on the usage of multiple phase 2 SAs. 3) Some implementations have shipped with a method of re-keying >> ^^ ^s that will not perform reliably under real world network conditions. 4) The use of the DELETE notification is not required. >> Reword: >> 4) The DELETE notification is optional: an implentation need not >> send it and an implementation need not pay attention to it. >> Furthermore, a DELETE notification is not authenticated >> nor is it reliably delivered. 5) A variety of re-keying behaviours have been observed, some of which are incompatible. 6) The commit bit is not yet widely implemented, and its use as described is confusing. Further, while the documentation requires its support, its use is not required. >> The Commit Bit is not authenticated. 7) A race condition exists at SA set up, exacerbating re-keying issues. 2.1.1 Inconsistent SA Use Recommendation This interpretation of [ISAKMP] is in direct conflict with the usage implied by [IKE], resulting in potential problems. >> This isn't clearly a contradiction. >> SAs negotiated in one QM exchange are all the same age, there is no >> newer/older distinction among them. 2.1.2 Observed Behaviours All of these behaviours are permitted under the current documents. >> ^ IPsec 2.1.4 Commit Bit Interaction 3) Its use may make implementations susceptible to a denial of service attack by forcing initiators to wait for a CONNECTED notification that may never come. While this is only one of a number of possible denial of service attacks on IKE, this is not an excuse to leave the existing implementation as it is. >> Alternate wording: >> 3) The Commit bit is not authenticated, so a man-in-the-middle can >> modify it without detection. The result would be a serious denial >> of service. Point 3 happens because the commit bit is in the ISAKMP header, and the ISAKMP header is not authenticated, so the commit bit is susceptible to undetectable modification. >> This paragraph is now redundant. 2.2 Solution Examination This section details the operation of some possible behaviours, with the intent of arriving at a best possible phase 2 re-keying mechanism under the constraints of the existing documents. >> ^ IPsec 2.2.1.1 Normal Conditions 3) Responder sends second quick mode message. 4) Responder sets up new inbound SA. This is to handle the case where the initiator starts transmitting on the new SA immediately after sending the third quick mode message. >> I think it would appear safer if 3) and 4) were reversed. 2.2.2.1 Dropped Quick Mode 3 Message This implies that implementations must be able to respond to the re- >> ^^^^^^^^^^^^^^^Initiators transmission of the second quick mode message even after having sent the third quick mode message. 2.2.2.3 Compatibility With Observed Behaviours When responders use the proposed method and the initiator is an implementation that uses the new SA immediately, there is no difference in SA transfer performance compared to the responder also using the new SA immediately. This is because the proposed method tries to use the new SA immediately on inbound, so it will be ready >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> immediately enables input on the new SA to receive on the new SA just as fast as an implementation that starts using the new immediately under all conditions. However, since the initiator is also using the new SA immediately, there is a possibility that packets will arrive at the responder on the new SA before the responder has time to set up the new SA. 2.2.2.4 Compatibility with Commit Bit The recommended proposal does not allow built-in support of the >> ^^^^^^^^^^^^^^^^^^^^^^ >> What does this mean? commit bit. It does allow responders that use the commit bit to detect reception of the CONNECTED notification by the initiator due to the presence of traffic on its new inbound SA. However, this works only if there is traffic, so it cannot be considered a useful method to perform this function. 3.1 Phase 1 SA Re-keying Requirements Two reasons for re-keying a phase 1 SA are for freshness (time or other) of the phase 1 SA keying material (affecting its ability to protect phase 2 SA negotiations and to generate phase keying >> ^2 material) and for re-authentication (and therefore authorisation) of the encrypting devices. 3.3 A Note About Overlapping Phase 1 SAs A specific application for this model that provides distinct advantages is with the use of token cards. For example, if a userÆs >> ^' >> [That character shows up as an AE dipthong on my xterm.] phase 1 authentication and authorisation is bound by the presence of a token card in a reader, the removal of the card should result in all SAs being torn down. Since there exists a continuous channel, delete notifications (acknowledged or not) can be sent for all SAs when the token card is removed from the system. However, if the phase 1 SA was allowed to be deleted without being re-keyed, the local end can only unilaterally delete its SAs, leaving the two end points out of sync with each other. (It cannot send delete notifications since the absence of the card makes it unable to re- establish a phase 1 SA.) Finally, it must be aware of implementations that do not want or >> ^^ >> What does "it" refer to? "A system implementing the Continuous >> Channel Model"? need phase 1 SAs that are continuously available. 3.3.1 Identity Perfect Forward Secrecy Allowing the use of only a single phase 2 negotiation in a phase 1 SA is how identity PFS is done. This is controlled by the deletion >> ^^^^^^^^^^accomplished of the phase 1 SA after a phase 2 negotiation. >> Proposed replacement for first sentence: >> Identity PFS requires that only a single Quick Mode negotiation >> may be performed under the protection of a Phase 1 SA, and that >> the Phase 1 SA must be destroyed after the negotiation. In implementations that do not wish to delete all phase 1 SAs, this can be done by creating two phase 1 SAs before the first phase 2 negotiation is done. The first of these SAs is assigned the role of channel management, and thus performs SA deletion and notification transfer. The second SA is used to perform phase 2 negotiations, and is immediately deleted. Since Identity PFS is not negotiated, it may not be possible to >> ^^^^^^^^^^^^^^neither negotiated nor announced guarantee that the peer knows Identity PFS is being used. In this case, the initiator may be required to delete its channel management SA and create a new one if the peer uses that phase 1 SA to re-key a phase 2 SA. >> How does the peer find out about the deletion? 4.1 Re-transmission Rules In the modes with an odd number of packets, the request-response >> ^^^^^^^^^^^^^^^^^^^^^ >> For this to apply there must be more than one packet. pair must be applied across the odd number of packets. This means that at least one packet must be considered the response to the previous packet, and must also be considered the request of the next request-response pair. 4.2 Acknowledged SA Deletion Note that re-transmission rules apply to the request-acknowledge pair. That is, if the initiator of the delete mode does not get the >> ^^^^ informational exchange delete acknowledgement, the delete request should be re-transmitted. Similarly, if the responder of the delete request receives multiple copies, multiple copies of the delete acknowledgement should be sent. Note that there is a race condition for the delete request and delete acknowledgement packets if an implementation sends them immediately after sending a packet on one of the SAs to be deleted. The race occurs if the packet order gets changed in the network and the delete mode packets arrive before packets sent on the SAs to >> ^^^^informational exchange which the deletes refer. The use of the Acknowledged Informational does not eliminate the use for the existing DELETE notification. It could still be used if an >> ^^^^^^^^unacknowledged implementation determines it needs to immediately (and impolitely) delete an SA. Implementations must still recognise that it is sent over UDP and may be dropped. 4.5.2 ALLOW_USAGE Notify Payload The initiator of the exchange must start usage of the inbound SA of >> ^^^^^^^^^^^^^^enable the pair when sending the first packet of the exchange. Usage of the >> ^^^^before initiator's outbound SA must wait until reception of the acknowledgement packet of the exchange. The responder of the exchange must start usage of its inbound SA of >> ^^^^^^^^^^^^^^enable the pair before sending the acknowledgement, and may start usage of >> ^^^^^^^^using its outbound SA of the pair any time after receiving the first packet of the exchange. Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec@lists.tislabs.com Wed Jul 12 04:48:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA13639; Wed, 12 Jul 2000 04:48:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA23865 Wed, 12 Jul 2000 06:20:46 -0400 (EDT) Message-Id: <200007121029.GAA14780@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-pki-req-05.txt Date: Wed, 12 Jul 2000 06:29:57 -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 : A PKIX Profile for IKE Author(s) : R. Thayer, C. Kunzinger, P. Hoffman Filename : draft-ietf-ipsec-pki-req-05.txt Pages : 28 Date : 11-Jul-00 The IKE protocol allows the use of the PKIX profile of X.509v3 certificates for encryption and authentication. Common practice in the IPsec community differs in some ways from these specifications made in the PKIX format specification and other specifications that have come from the PKIX WG. In order to promote interoperability in the IPsec market, this document lays out a profile for using PKIX in IKE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-05.txt 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-pki-req-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-pki-req-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <20000711134405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-pki-req-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-pki-req-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000711134405.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Jul 12 15:35:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA05641; Wed, 12 Jul 2000 15:35:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26630 Wed, 12 Jul 2000 16:35:54 -0400 (EDT) Date: Wed, 12 Jul 2000 16:48:36 -0400 Message-Id: <200007122048.QAA17951@trampoline.thunk.org> X-Authentication-Warning: trampoline.thunk.org: tytso set sender to tytso@trampoline.thunk.org using -f To: TJenkins@Catena.com CC: ipsec@lists.tislabs.com In-reply-to: <310508EDF557D31188FA0050DA0A37526586EF@CAT01S2> (message from Tim Jenkins on Mon, 10 Jul 2000 08:54:43 -0400) Subject: Re: WG Last call: draft-jenkins-ipsec-rekeying-06.txt From: tytso@mit.edu Phone: (781) 391-3464 References: <310508EDF557D31188FA0050DA0A37526586EF@CAT01S2> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From: Tim Jenkins Date: Mon, 10 Jul 2000 08:54:43 -0400 There is one potential issue with the references, in that the document refers to which I believe has expired and has not been replaced. Do I need to do something with that? Yes, we can't have any references to expired I-D's. I assume the simpliest thing to do is replace it with the IKE RFC; or is there some specific reason why you referenced the ike-01.txt I-D? - Ted From owner-ipsec@lists.tislabs.com Wed Jul 12 16:10:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA06033; Wed, 12 Jul 2000 16:10:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26857 Wed, 12 Jul 2000 17:49:16 -0400 (EDT) Date: Wed, 12 Jul 2000 17:57:52 -0400 (EDT) From: Henry Spencer To: tytso@mit.edu cc: TJenkins@Catena.com, ipsec@lists.tislabs.com Subject: Re: WG Last call: draft-jenkins-ipsec-rekeying-06.txt In-Reply-To: <200007122048.QAA17951@trampoline.thunk.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 12 Jul 2000 tytso@mit.edu wrote: > Yes, we can't have any references to expired I-D's. I assume the > simpliest thing to do is replace it with the IKE RFC; or is there some > specific reason why you referenced the ike-01.txt I-D? I think the problem is that Tim wants to reference the Acknowledged Delete proposal, which exists only in the I-D. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Jul 12 16:16:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA06156; Wed, 12 Jul 2000 16:16:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26882 Wed, 12 Jul 2000 17:59:15 -0400 (EDT) Date: Wed, 12 Jul 2000 18:10:18 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: IPsec List cc: Hugh Daniel , John Gilmore Subject: problems with draft-jenkins-ipsec-rekeying-06.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This document describes a number of substantive problems we perceive with draft-jenkins-ipsec-rekeying-06.txt. We don't think this draft is ready to be an RFC, even an Informational one. We see significant problems in both the description and the intent. (We apologize for leaving this to the last minute, but much of this became clear to us only recently.) | 2.2.1.4 Responder Pre-Set-up Security Hole | | In the failed negotiation case, the need to delete the invalid | inbound SA raises the issue of a temporary hole, in that the | responder allows inbound packets while waiting for the third quick | mode message. However, if the inbound SA is not set up ahead of | time, initiators that immediately transmit on the new outbound SA | will cause packets to be dropped. We don't see why this is a security hole. The Responder has set up an inbound IPSEC SA because the Initiator has made a request to do so. The request is authenticated and the protection suite has been selected. This seems adequately secure. | It also illustrates why the proposal above made the usage of the | outbound SA by the initiator wait until there is an indication of | the use of the SA by the responder. This isn't required because the responder could set up the SA earlier. | Note that this security hole is exactly what would result from an | attacker replaying the first quick mode message of an exchange. A replay attack cannot succeed since the RFCs require that the Message ID be unique. The Message ID is protected by encryption and authenticated by being included in HASH(1). | 2.2.2 Recommended Re-keying Method | 2.2.2.2 Absence of Traffic | However, due to the number of implementations that delete old SAs 30 | seconds after negotiating a new one, the same behaviour has the best | chance of interoperability, and of not dropping packets when traffic | does restart. | | Therefore, it is recommended that implementations delete old SAs and | start using new SAs 30 seconds after negotiating new SAs in the | absence of traffic. Use of the DELETE notification is strongly | recommended in cases where the peer implementation is continuing to | use the old SA. It would surely aid interoperability to leave the the inbound SA for a longer time. This is true even if the DELETE notification is sent -- it can be lost or ignored. There are other reasons to delete the inbound SA, and they may point to a recommendation for deletion, but the reason given here does not apply. | 3.4.2 INITIAL-CONTACT Notification | | As stated above, the INITIAL-CONTACT notification should be used | only with the very first phase 1 SA that is negotiated between two | peers. We think that INITIAL-CONTACT is a useful mechanism, but there are flaws. - There are well-known problems with the integrity of Informational Payloads. Within a Main Mode exchange, they are not authenticated. The consequences of acting on a forged INITIAL-CONTACT are severe. - the meaning of INITIAL-CONTACT is not sufficiently nailed down in rfc2407.txt: "The INITIAL-CONTACT status message may be used when one side wishes to inform the other that this is the first SA being established with the remote system." + the meaning of "system" is not given. * Are systems identified with IP addresses? (in reality, a system might have several IP addresses) * Do/should Phase 1 IDs play any part in this? (It might be that the authority to blow away other SAs should be limited to SAs that have the same ID, the basis for authentication.) + Observations on one system may be ordered differently from observations on another. So the word "first", upon which the meaning of INITIAL-CONTACT crucially depends, is not defined in a way that both will always agree. This is exacerbated because INITIAL-CONTACT should be delayed until a Quick Mode negotiation, so it can be authenticated and hence trustworthy. (We actually think that a FINAL-CONTACT message would be useful, given a precise definition. Interestingly, we think that INITIAL-CONTACT might be usable for this purpose! After all, it would probably cause all but one SA to be deleted; it might prompt the recipient to renegotiate SAs, but the sender could refuse to negotiate.) | If used on subsequent negotiations, it means that all pre-existing | SAs (phase 1 and phase 2) held between the peers should be deleted. It is interesting to note that INITIAL-CONTACT is only defined in the IPSEC-DOI. This seems like an oversight to us. This could be a problem because a Main Mode SA proposal could specify a DOI of 0. This document should require that IPSEC-DOI be specified. | As an example, this is the mechanism used to detect when an SA end | point has crashed and is now alive again. | | The use of INITIAL-CONTACT may be restricted by the mode used to | negotiate phase 1 SAs. For these reasons, implementations may want | to avoid the use of aggressive mode when possible. When it is used, | it is recommended that the third aggressive mode message be | encrypted so that the INITIAL-CONTACT notification can be added to | it when needed. Note that the use of any notification by a responder | during aggressive mode is not allowed, and this document's | suggestion that the use of INITIAL-CONTACT is permitted by the | initiator if the third aggressive mode packet is encrypted is | possibly contrary to RFC2408. | | Alternatively, if notifications cannot be used within the phase 1 | modes at all, it is recommended that INITIAL-CONTACT be sent in a | notification packet (preferably acknowledged) immediately after the | phase 1 is complete. Reception of this notification (at any time) | should indicate to the receiver that all other SAs, phase 1 and | phase 2, with the sender must be deleted. (In other words, the SA | that was used to encrypt the notification is the only SA that is not | deleted.) The only safe places to put INITIAL-CONTACT that are RFC-compliant are in the first two messages of a Quick Mode Exchange. Elsewhere they are not authenticated, cannot be trusted, and *must be ignored*. | 3.4.1 Multiple SA Usage ^ISAKMP | | When there is more than one phase 1 SA between peers, What is the definition of "peers" being used here? Not all ISAKMP SAs are interchangeable. Some have different protection suites. Some have different Phase 1 ID authentication. | it is | recommended that the oldest SA be used for subsequent traffic | requiring phase 1 SAs. We have found that always using the newest ISAKMP SA avoids some problems when a system is restarted. INITIAL-CONTACT addresses some of the same problems, but it is optional, ill-defined, inconsistently used, and less timely. | This allows full use of the keying material | generated We don't understand this to be an issue. Surely if a new ISAKMP SA is negotiated, it was negotiated for some reason. If the reason is that it was time to rekey, then the keying material is close to expired -- discarding the old ISAKMP SA wastes little. If it was another reason, this rule may stymie the intent. | and reduces race conditions. Which race conditions? | It also means that no special | expiration conditions are required when the phase 1 SAs expire by | traffic or other usage dependent expirations only, as the old SA | will eventually expire on its own due to usage. We don't think that there is a negotiated way to expire Phase 1 SAs by traffic, is there? (Vague inference from some list traffic.) If not, this argument doesn't apply. | 3.4.4 Re-keying Timing | An example of this is that the end with the higher IP address re- | keys at 95% of the lifetime, while the end with lower IP address re- | keys at 85% of the lifetime. Although this is only an example, this document is quite influential. We think that there is a better way of breaking the symmetry, and we'd like it to be used as the example, or even become a recommendation. We suggest that the bias be towards rekeying by the Initiator over the Responder. These roles are already an asymmetry in the standards. The Initiator has already been able to initiate, so the chances of rekeying succeeding are probably higher if the Initiator re-initiates. We have actually observed this to make a significant difference. | Whatever rule is chosen, it is recommended that the rule be | deterministic in order to have predictable and consistent behaviour | between peers. If the rule had used the SPI as the determining | factor (as an example did in the first version of this document), | different peers would be doing the re-keying at different times. We have found great value in adding jitter to the rekeying threshold. True, this adds non-determinacy, but it also helps prevent and cure "convoy" behaviour. This convoy behaviour was a serious problem with a hub server. | 4. Next IPsec Version Recommendations We would add a few recommendations: - Make Identity PFS an announced (or negotiated) property so that both peers know that it is in effect. - Clarify the meaning of INITIAL-CONTACT. Perhaps make it an ISAKMP Notification. Perhaps add FINAL-CONTACT. - authenticate optional payloads in all exchanges. Authenticate the header (for example, the Commit Bit). - allow the responder to an Acknowledged Informational to include information about whether the message was understood or acted upon. For example, a response to a Delete ought to be able to indicate whether the deletion was understood. At least some of these responses should be standardized. | 4.1 Re-transmission Rules | | In systems that use exchanges that have an even number of packets, | the rules for re-transmission are relatively obvious. Simply put, a | packet is re-sent if the expected response to it is not received | within a certain period of time. | | However, IPsec has a number of modes that have an odd number of | packets. This can lead to confusion as to when the re-transmission | rules should be applied, depending how the re-transmission rules are | applied to the packets in the exchange. This in turn can lead to the | dropping of aggressive mode's and quick mode's third messages. It is | recommended that each of these modes have specific rules applied to | them to avoid re-transmission issues. This section distinguishes exchanges that use an even number of packets (messages) and those that use an odd number. We think that this is not the best distinction. We will propose another approach. There are two interesting properties of a message in an exchange: whether it has a preceding message, and whether it has a following message. Because peers alternate turns in an exchange, the preceding and following messages come from the other peer. If a message has no predecessor, the simple observation is that the system that sends the message must have decided to do so on its own. Not much more is worth saying. If a message has a successor, this successor (if the protocol is appropriately designed, as IKE seems to be) will serve as an acknowledgement of receipt. If there is no acknowledgement in a timely fashion, the message should be retransmitted. Local policy should determine the rate of retransmission and how persistent it should be. If a message has a predecessor, and after the message is sent, a predecessor is received, it could be ignored. After all, UDP can re-deliver a message. It might be worth checking to see that the new message is identical to the earlier one -- but if it is different, what action should be taken? In any case, this message could be taken as a sign that the peer hadn't received our most recent message. Should this trigger a retransmission? It could be that our last transmission "crossed paths" with the second copy of the preceding message. Our retransmission could then lead the other side to retransmit its next message (at least this isn't a loop). It might be better to just wait to see if we get the succeeding message in time, and if not *then* retransmit. This last approach does not work for the last message in an exchange, because we are not waiting for another message. In that case, the reception of a preceding message should definitely trigger a retransmission. This cannot stimulate spurious retransmission from the peer since this is the last message. This approach is not as robust as one would like in determining that the last message needs retransmission. In effect, it depends on a Negative Acknowledgement. On the other hand, if these Negative Acknowledgements are not getting through, future communication is unlikely to work anyway. This may suggest that retransmission should be more persistent for the second-last message in an exchange. The only case we haven't covered is that of an exchange with only one message. This is a case where the last message does not have a predecessor, so even the NACK isn't available. We think that this analysis eliminates the needs for sections 4.1.1, 4.1.2, and 4.1.3. | 4.2 Acknowledged SA Deletion | The Acknowledged Informational exchange consists of two packets. The | first packet is the transmission of a notify or delete payload. The | second is the acknowledgement of that packet. | | When used with a delete payload, it is interpreted to mean the | following: | | "I am not sending anymore traffic on this SA (or these SAs). Would | you please stop sending traffic on it (or them), and send me an | acknowledgement when you are done?" This discussion seems to reflect a fundamental misunderstanding of what Delete does. According to IKEbis, the semantics of Acknowledged SA Deletion and normal SA Deletion are identical. According to RFC 2408, a Delete is not a *request*, it is an *announcement*. Specifically, it announces that a particular *incoming* (at the sender) SA is no longer usable. It is not a warning of intent to do so, nor a query as to whether this would be acceptable. It does not say anything about what sorts of traffic the sender is sending or will send; it says nothing about the *outgoing* SAs that such traffic would be flowing on. It does not require any specific action on the part of the recipient. If the intent here is that associations should be made between incoming and outgoing IPSEC SAs, so that a Delete would *also* imply a request to delete any associated SAs in the opposite direction, this needs to be said much more explicitly. Consideration also needs to be given to whether a new payload should be defined to convey this new meaning, and to whether prior negotiation would be preferable to after-the-fact notification. The draft's discussion seems to want Acknowledged Delete to be a prior negotiation -- the two ends are agreeing to stop using certain SAs, with the implication that those SAs might then be deleted -- but that is *not* what Delete does, and hence is not what Acknowledged Delete does. Such a drastic change in semantics would be better accommodated in a new payload, rather than a redefinition of an old one. | The receiver of the delete request then switches his outbound | traffic to another SA, deletes both inbound and outbound SAs and | sends the delete acknowledgement. That is a worthwhile convention. And this is a good place to suggest it. But it isn't in the RFCs, at least not for IPSEC SAs. It would be nice to have a new Delete that would delete all the SAs in a suite at once (both directions, ESP, AH, and IPcomp, if present). It could be part of IPSEC DOI since this particular issue only arises with IPSEC SA deletion. Unfortunately, as far as we can tell, the response to an Acknowledged Informational message in no way indicates whether the responder understood or acted upon the message. How should one delete the ISAKMP SA used to carry the deletion message? This would be useful when shutting down a connection. | 4.5 Commit Bit Replacement The Commit Bit has serious problems. Does it fulfill a real need? The race condition outlined in 2.1.3 is eliminated if the Responder sets up the inbound SA earlier (we explained why we don't think that this is a security hole). If it does fulfill a need, its worst problems can be fixed by authenticating it (as proposed elsewhere). True, that is a change, but so are the additions proposed in this section. The proposed additions seem much more complicated. Hugh Redelmeier hugh@mimosa.com Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Jul 12 17:15:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA06924; Wed, 12 Jul 2000 17:15:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA27004 Wed, 12 Jul 2000 18:58:04 -0400 (EDT) Date: Wed, 12 Jul 2000 19:09:17 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: IPsec List cc: Hugh Daniel , John Gilmore Subject: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The "last call" on draft-jenkins-ipsec-rekeying-06.txt has galvanized us into writing up what we think is a better approach to certain parts of the rekeying problem. draft-jenkins-ipsec-rekeying-06.txt is a very important document. It has plainly laid out key problems with the implementation of IPsec. It has proposed useful approaches to surmounting them. We think that certain parts of the proposed solutions are overly complex. In software, complexity is the enemy. In security software, this is doubly true. Key advantages of our approach: - no extensions to RFCs are required - few optional features are required - simplicity and robustness For ease of reference, here is what Quick Mode looks like: Initiator Responder ----------- ----------- HDR*, HASH(1), SA, Ni [, KE ] [, IDi2, IDr2 ] --> <-- HDR*, HASH(2), SA, Nr [, KE ] [, IDi2, IDr2 ] HDR*, HASH(3) --> Broadly speaking, our major proposal is to use what draft-jenkins-ipsec-rekeying-06.txt calls "Responder Pre-Set-Up" in Quick Mode. The Responder will set up the SA(s) inbound to it before sending the reply to the first message from the Initiator. draft-jenkins-ipsec-rekeying-06.txt describes fairly well the advantages of RPSU. But it vetoes this approach because it claims that RPSU is vulnerable to a replay attack. A man in the middle could capture a Quick Mode first message from the Initiator and replay it to the Responder, provoking the Initiator to set up useless inbound SAs. Those useless SAs might even be no longer secure. In fact, the replay attack cannot work if the Responder implements the RFCs. The RFCs stipulate that the Message IDs of Phase 2 exchanges must be unique. A replayed message would not meet this requirement. Since the Message ID is authenticated, it cannot be forged by a man in the middle. The enforced uniqueness of Message IDs prevents replay attacks for certain other exchanges such as Informational. Enforcing Uniqueness of Message IDs =================================== We infer from some comments that some implementations do not enforce the requirement that Message IDs be unique. Although this isn't RFC compliant, the suggestion is that the RFCs be changed! The specific suggestion is that "probably unique" is good enough. We claim that the cost of enforcing uniqueness of Message IDs is well repaid by the advantages it affords: simple robust rekeying and defence against some replay attacks. Uniqueness of Message IDs over all messages seen by a system cannot sensibly be enforced. If a system communicates with two peers, each may choose the same Message ID for an exchange with our system. Forbidding this is silly. Since each Message ID appears under the protection of an ISAKMP SA, and only has meaning within that ISAKMP SA, uniqueness should only be required within the scope of a particular ISAKMP SA. (This needs to be made explicit in the RFCs.) One complaint about enforcing uniqueness of Message IDs is that it appears to require an unbounded amount of state in an ISAKMP SA to store all the used Message IDs. Although the state for each Message ID is small (4 octets), there might be a very large number of them. It turns out that there is a simple way to prune this state: negotiate a new ISAKMP SA and delete the old one. At this point, none of the state matters any more. It was only used to enforce uniqueness of future Message IDs for exchanges under the protection of the old ISAKMP SA, and there will be none. In practice, we have not noticed an inordinate build up of defunct Message IDs, and so think that replacing ISAKMP SAs for this reason will not normally be required. The advantages of Responder Pre-Set-Up ====================================== Many of the advantages are discussed in draft-jenkins-ipsec-rekeying-06.txt. If we can assume that all implementations use RPSU, no extra handshaking is required to prevent race conditions in setting up an IPSEC SA. There is no need for the Initiator to delay using its new outbound SA, because it is guaranteed to have been installed. There is no need for the Commit Bit (a flawed mechanism as it is). There is no need to wait for inbound traffic as a proxy for an ACK communicating that the outbound SA ready. The Responder knows that it may use its outbound SA as soon as it receives the last Quick Mode message. It all just works. No Informational messages are required. No observation of IPsec traffic is required. No timeouts are required (except those for retransmission of the Quick Mode messages). There is one flaw in this happy setup. If the peer is not using RPSU, but instead sets up its inbound SAs on reception of the last Quick Mode message, then there is a race condition. The race is between the last Quick Mode message and the first outbound IPsec packet from the Initiator. Two reactions to this problem seem reasonable to us: - consider the peer to be in error. After all, we are RFC compliant so it should handle this case. - consider the problem to be minor: IP protocols are supposed to recover from lost packets, so the occasional lost initial packet should not be a disaster. We think that it would be a mistake to try to "paper over" the problem by, for example, making the Initiator delay a fixed amount of time between sending the last Quick Mode message and the first IPsec message. This would complicate all future implementations and reduce their performance. In this, we diverge from RPSU as described by draft-jenkins-ipsec-rekeying-06.txt In 2.2.1, that document states: Implicit acknowledgement of the reception of the third quick mode message by the responder is provided by use of the new SA in the initiator's inbound direction. The initiator should not use its new outbound SA before that time. This implicit acknowledgement might well never come! After all, the conversation was initiated by the Initiator -- maybe it is the only one with something to say. Implementation Experience ========================= We have implemented this technique in FreeS/WAN (www.freeswan.org). The implementation as a whole is minimal: it leaves out large parts of IKE: - no Informational Payloads are understood or generated - the Commit Bit isn't implemented - the IKE implementation knows nothing about actual traffic on the IPsec SAs Even so, this implementation interoperates quite well with others. It rekeys successfully. The one problematic case of which we are aware is with an implementation which depends on Delete Payloads to switch between SAs. We consider this a bug in that implementation, since Delete messages are not acknowledged and hence their delivery is unreliable. Hugh Redelmeier hugh@mimosa.com Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Jul 12 18:03:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA08352; Wed, 12 Jul 2000 18:03:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA27166 Wed, 12 Jul 2000 19:52:55 -0400 (EDT) X-Authentication-Warning: janpc-home.cisco.com: vilhuber owned process doing -bs Date: Wed, 12 Jul 2000 17:01:00 -0700 (PDT) From: Jan Vilhuber To: "D. Hugh Redelmeier" cc: IPsec List , Hugh Daniel , John Gilmore Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 12 Jul 2000, D. Hugh Redelmeier wrote: > The "last call" on draft-jenkins-ipsec-rekeying-06.txt has galvanized > us into writing up what we think is a better approach to certain parts > of the rekeying problem. > > draft-jenkins-ipsec-rekeying-06.txt is a very important document. > It has plainly laid out key problems with the implementation of IPsec. > It has proposed useful approaches to surmounting them. > > We think that certain parts of the proposed solutions are overly > complex. In software, complexity is the enemy. In security software, > this is doubly true. > > Key advantages of our approach: > > - no extensions to RFCs are required > > - few optional features are required > > - simplicity and robustness > > > For ease of reference, here is what Quick Mode looks like: > > Initiator Responder > ----------- ----------- > HDR*, HASH(1), SA, Ni > [, KE ] [, IDi2, IDr2 ] --> > <-- HDR*, HASH(2), SA, Nr > [, KE ] [, IDi2, IDr2 ] > HDR*, HASH(3) --> > > Broadly speaking, our major proposal is to use what > draft-jenkins-ipsec-rekeying-06.txt calls "Responder Pre-Set-Up" in > Quick Mode. The Responder will set up the SA(s) inbound to it before > sending the reply to the first message from the Initiator. > > draft-jenkins-ipsec-rekeying-06.txt describes fairly well the > advantages of RPSU. But it vetoes this approach because it claims > that RPSU is vulnerable to a replay attack. A man in the middle could > capture a Quick Mode first message from the Initiator and replay it to > the Responder, provoking the Initiator to set up useless inbound SAs. > Those useless SAs might even be no longer secure. > > In fact, the replay attack cannot work if the Responder implements the > RFCs. The RFCs stipulate that the Message IDs of Phase 2 exchanges must > be unique. I don't remember for sure, but I thought message ID's were also supposed to be random. So unless a host saved a list of ALL messages ID's ever used or encountered, then you couldn't detect the replay! So you must either use a sequentially increasing message-id, which I was under the impression that this was a bad idea, or you need to add some sort of time-stamp to the packets so that they can be rejected in kerberos fashion... So I'm not quite as confident as you that this is simply a matter of 'implementing the rfc's' properly. I interpret 'unique' as meaning that they are unique in the sender's 'name-space'. It means that I can not send out two quick-modes with message-id == 5 AT THE SAME TIME. There's nothing from preventing me (or my bad random number generator) from sending out a quick mode with message-id 5 now, and then again 10 minutes from now, after I'm long done with the old quick mode that used 5 (and completely oblivious to it, too, unless I keep a list of all previously used message-ids). Can you elaborate on this some more? Bottom line is that I don't think the intent of the message-id was to prevent replay attacks. It's simply an identifier to match up requests and replies. The Nonces fulfill the replay requirement, but if you use "Responder Pre-Set-Up", then you're not waiting to get QM3 (that proves that the remote has the right key) before setting up your SA and accepting traffic on it. So I believe Tim is right in that there is a security hole here. jan > A replayed message would not meet this requirement. Since > the Message ID is authenticated, it cannot be forged by a man in the > middle. > > The enforced uniqueness of Message IDs prevents replay attacks for > certain other exchanges such as Informational. > > > Enforcing Uniqueness of Message IDs > =================================== > > We infer from some comments that some implementations do not enforce the > requirement that Message IDs be unique. Although this isn't RFC > compliant, the suggestion is that the RFCs be changed! The specific > suggestion is that "probably unique" is good enough. We claim that > the cost of enforcing uniqueness of Message IDs is well repaid by the > advantages it affords: simple robust rekeying and defence against some > replay attacks. > > Uniqueness of Message IDs over all messages seen by a system cannot > sensibly be enforced. If a system communicates with two peers, each > may choose the same Message ID for an exchange with our system. > Forbidding this is silly. > > Since each Message ID appears under the protection of an ISAKMP SA, > and only has meaning within that ISAKMP SA, uniqueness should only be > required within the scope of a particular ISAKMP SA. (This needs to be > made explicit in the RFCs.) > > One complaint about enforcing uniqueness of Message IDs is that it > appears to require an unbounded amount of state in an ISAKMP SA to > store all the used Message IDs. Although the state for each Message > ID is small (4 octets), there might be a very large number of them. > > It turns out that there is a simple way to prune this state: > negotiate a new ISAKMP SA and delete the old one. At this point, none > of the state matters any more. It was only used to enforce uniqueness > of future Message IDs for exchanges under the protection of the old > ISAKMP SA, and there will be none. > > In practice, we have not noticed an inordinate build up of defunct > Message IDs, and so think that replacing ISAKMP SAs for this reason > will not normally be required. > > > The advantages of Responder Pre-Set-Up > ====================================== > > Many of the advantages are discussed in > draft-jenkins-ipsec-rekeying-06.txt. > > If we can assume that all implementations use RPSU, no extra > handshaking is required to prevent race conditions in setting up an > IPSEC SA. > > There is no need for the Initiator to delay using its new outbound SA, > because it is guaranteed to have been installed. There is no need for the > Commit Bit (a flawed mechanism as it is). There is no need to wait > for inbound traffic as a proxy for an ACK communicating that the > outbound SA ready. > > The Responder knows that it may use its outbound SA as soon as it > receives the last Quick Mode message. > > It all just works. No Informational messages are required. No > observation of IPsec traffic is required. No timeouts are required > (except those for retransmission of the Quick Mode messages). > > There is one flaw in this happy setup. If the peer is not using RPSU, > but instead sets up its inbound SAs on reception of the last Quick > Mode message, then there is a race condition. The race is between the > last Quick Mode message and the first outbound IPsec packet from the > Initiator. > > Two reactions to this problem seem reasonable to us: > > - consider the peer to be in error. After all, we are RFC compliant > so it should handle this case. > > - consider the problem to be minor: IP protocols are supposed to > recover from lost packets, so the occasional lost initial packet should > not be a disaster. > > We think that it would be a mistake to try to "paper over" the problem > by, for example, making the Initiator delay a fixed amount of time > between sending the last Quick Mode message and the first IPsec > message. This would complicate all future implementations and reduce > their performance. > > In this, we diverge from RPSU as described by > draft-jenkins-ipsec-rekeying-06.txt In 2.2.1, that document states: > > Implicit acknowledgement of the reception of the third quick mode > message by the responder is provided by use of the new SA in the > initiator's inbound direction. The initiator should not use its new > outbound SA before that time. > > This implicit acknowledgement might well never come! After all, the > conversation was initiated by the Initiator -- maybe it is the only > one with something to say. > > > Implementation Experience > ========================= > > We have implemented this technique in FreeS/WAN (www.freeswan.org). > > The implementation as a whole is minimal: it leaves out large parts of IKE: > > - no Informational Payloads are understood or generated > > - the Commit Bit isn't implemented > > - the IKE implementation knows nothing about actual traffic on the > IPsec SAs > > Even so, this implementation interoperates quite well with others. It > rekeys successfully. > > The one problematic case of which we are aware is with an > implementation which depends on Delete Payloads to switch between SAs. > We consider this a bug in that implementation, since Delete messages > are not acknowledged and hence their delivery is unreliable. > > Hugh Redelmeier > hugh@mimosa.com > > Henry Spencer > henry@spsystems.net > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Jul 12 18:52:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA14854; Wed, 12 Jul 2000 18:52:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA27401 Wed, 12 Jul 2000 20:47:57 -0400 (EDT) Message-ID: From: Alex Deacon To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-pki-req-05.txt Date: Wed, 12 Jul 2000 17:56:08 -0700 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, Some comments on the latest pki-req draft.... 1) In section 5. Algorithm Requirements Based on the number of odd OIDS I've seen for sha-1WithRSAEncryption and id-dsa-with-sha1, I would suggest we either include the actual numeric oids in this document, or reference the sections in RFC2459 (or son of) where they are specified (7.2.1 for sha-1WithRSAEncryption and 7.2.2 for id-dsa-with-sha1) 2) In Section 6.1 paragraph 3 > In order to protect the identity in a Certificate payload, the IKE > device that wishes to deliver its own certificates to its peer MUST use > Main Mode MUST only include Certificate payloads in message 5 or 6. I *think* you wanted to say ".....its peer MUST use Main Mode *and* MUST only include...." 3) In Section 7.1 > 2. Create a PKCS #10 [RFC-2314] object that includes the public key > portion of the key pair. This object MUST NOT use any PKCS #10 > extensions. I just noticed the "MUST NOT use any PKCS #10 extensions" statement. Looks like this was also in the -03 and -04 versions. First of all I think the word "extensions" is not correct here. I believe we are referring to PKCS#10 attributes, specifically the use of the extensionReq attribute defined in PKCS#9, right? Anyway, based on workshop experience, there are quite a few implementations that use this attribute to request the subjectAltName value. What is, or what was, the reason to make it a "MUST NOT"? 4) Further down in Section 7.1 > message as the Base64 transformation of the PKCS #10 object. That > Base64 object SHOULD be preceded with either the line: > > -----BEGIN CERTIFICATE----- > > or the line: > > -----BEGIN CERTIFICATE REQUEST----- Why would a pkcs#10 certificate *request* be wrapped in a -----BEGIN CERTIFICATE----- line? Are we trying to document what implementations are currently doing? Or specifying what implementations *should* be doing. If its the latter, then we shouldn't specify that people use the -----BEGIN CERTIFICATE----- wrapper for certificate requests. If its the former, we should strongly recommend -----BEGIN CERTIFICATE REQUEST----- 5) > [[[ OK, folks, that really doesn't help on interoperability. Should > we pick one of those four as a SHOULD? ]]] I vote for the first one "- A PKCS #7 object holding the certificate" 6) In section 10. References Believe it or not, CMC is now officially RFC 2797. 7) In Appendix A. Change History > 7. (A.) Added "Note that P10POUB using PKCS7 responses is one mode of > CMC.".... I didn't see this in the main document. Did it get lost? Alex From owner-ipsec@lists.tislabs.com Wed Jul 12 18:54:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA15089; Wed, 12 Jul 2000 18:54:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA27373 Wed, 12 Jul 2000 20:43:16 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4408.0 content-class: urn:content-classes:message Subject: RE: Call for agenda topics for Pittsburgh IETF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEC64.564D0A7C" Date: Wed, 12 Jul 2000 17:50:27 -0700 Message-ID: <6A05D00595BE644E9F435BE5947423F2038CB3F6@fifi.platinum.corp.microsoft.com> Thread-Topic: Call for agenda topics for Pittsburgh IETF Thread-Index: Ab/nrks2m2u3PLanQ6OBryyACVv0pwEtboCw From: "William Dixon" To: , X-OriginalArrivalTime: 13 Jul 2000 00:51:22.0524 (UTC) FILETIME=[76E495C0:01BFEC64] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFEC64.564D0A7C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ted, I'd appreciate a slot for Bernard Aboba and myself to present his IPSec/NAT draft already submitted. http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-01.txt -----Original Message----- From: tytso@mit.edu [mailto:tytso@mit.edu] Sent: Thursday, July 06, 2000 2:10 PM To: ipsec@lists.tislabs.com Subject: Call for agenda topics for Pittsburgh IETF As I'm sure you all know, the Pittsburgh IETF is rapidly approaching. The cutoff for Internet-Draft submissions is Friday, July 14th. If you have an updated draft to submit, please make sure it gets submitted by then. If you have a topic you'd like to bring up for discussion at the IPSEC wg meeting, please let me know by sending me e-mail. Thanks!! - Ted ------_=_NextPart_001_01BFEC64.564D0A7C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Call for agenda topics for Pittsburgh IETF

Ted, I'd appreciate a slot for Bernard Aboba and = myself to present his IPSec/NAT draft already submitted.

http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-01.txt

-----Original Message-----
From: tytso@mit.edu [mailto:tytso@mit.edu]
Sent: Thursday, July 06, 2000 2:10 PM
To: ipsec@lists.tislabs.com
Subject: Call for agenda topics for Pittsburgh = IETF



As I'm sure you all know, the Pittsburgh IETF is = rapidly approaching.

The cutoff for Internet-Draft submissions is Friday, = July 14th.  If you
have an updated draft to submit, please make sure it = gets submitted by
then.

If you have a topic you'd like to bring up for = discussion at the IPSEC
wg meeting, please let me know by sending me = e-mail.  Thanks!!

        =         =         =         =         =         - Ted

------_=_NextPart_001_01BFEC64.564D0A7C-- From owner-ipsec@lists.tislabs.com Wed Jul 12 23:47:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA03999; Wed, 12 Jul 2000 23:47:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA28005 Thu, 13 Jul 2000 01:04:12 -0400 (EDT) X-Authentication-Warning: redshift.mimosa.com: hugh owned process doing -bs Date: Thu, 13 Jul 2000 01:14:55 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: Jan Vilhuber cc: IPsec List , Hugh Daniel , John Gilmore Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk | From: Jan Vilhuber | > In fact, the replay attack cannot work if the Responder implements the | > RFCs. The RFCs stipulate that the Message IDs of Phase 2 exchanges must | > be unique. | | I don't remember for sure, but I thought message ID's were also supposed to | be random. So unless a host saved a list of ALL messages ID's ever used or | encountered, then you couldn't detect the replay! As we explain slightly later in the same document, it is only necessary to save message IDs used/encountered *within the current ISAKMP SA*. When the ISAKMP SA expires (whether or not it is replaced by a fresh one), the message-ID memory can be freed. As also noted, we have implemented this and the memory consumption has not been a problem in practice. Half-measures are not necessary; doing it really right is not costly. It appears you didn't understand what we were trying to say. Could you explain what parts aren't clear? We'd like to make it clear. | I interpret 'unique' as meaning that they are unique in the sender's | 'name-space'. We suggested in the quoted section that "unique within an ISAKMP SA" would be sensible and sufficient. (At one time our implementation used a broader scope of uniqueness but the greater burden was still not a problem.) | It means that I can not send out two quick-modes with | message-id == 5 AT THE SAME TIME. Yes, it means that and more. | There's nothing from preventing me (or my | bad random number generator) from sending out a quick mode with message-id 5 | now, and then again 10 minutes from now, after I'm long done with the old | quick mode that used 5 (and completely oblivious to it, too, unless I keep a | list of all previously used message-ids). I see nothing in the RFC to bound the time the way you seem to. So yes, there is something preventing you: you are not following the RFC if the Message ID is not unique. And you won't interoperate with my implementation which is following the RFC. | Can you elaborate on this some more? | | Bottom line is that I don't think the intent of the message-id was to prevent | replay attacks. I'm not arguing about intent, only about following the specifications. The specs say "unique", and that gives a wonderful property. Are you suggesting we change the specs to remove this property? | It's simply an identifier to match up requests and replies. | The Nonces fulfill the replay requirement, but if you use "Responder | Pre-Set-Up", then you're not waiting to get QM3 (that proves that the remote | has the right key) before setting up your SA and accepting traffic on it. We are preventing replay. Given that, plus authentication, it does not appear to us that this proof is required at this point. Have we overlooked something? | So I believe Tim is right in that there is a security hole here. If we are preventing replay, do you think there is still a hole? Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec@lists.tislabs.com Thu Jul 13 05:18:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA21346; Thu, 13 Jul 2000 05:18:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA29017 Thu, 13 Jul 2000 06:37:02 -0400 (EDT) Date: Thu, 13 Jul 2000 13:45:18 +0300 (IDT) From: Hugo Krawczyk To: ipsec list Subject: Re: I-D ACTION:draft-ietf-ipsec-pki-req-05.txt In-Reply-To: <200007121029.GAA14780@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The draft has several incorrect statements about the ability of the encryption modes of IKE to protect the identity and certificate of the sender from discovery by eavesdroppers. Contrary to what is stated in the draft, the "Revised Mode of Public Key Encryption" allows for identity AND certificate protection in BOTH main mode AND aggressive mode. The first "Public Key Encryption mode" in IKE specifies how to encrypt the initiator's identity but not its certificate. The Revised mode specifies the latter too. In particular, the Revised mode is the only authentication mode of IKE that allows for certificate and identity protection in aggressive mode. I am including below the paragraphs in the current draft that need to be coorected. In particular, you have to distinguish between the "Public Key Encryption mode" and the "Revised" one for the sake of certificate protection. Hugo The incorrect paragraphs: > In order to protect the identity in a Certificate payload, the IKE > device that wishes to deliver its own certificates to its peer MUST use > Main Mode MUST only include Certificate payloads in message 5 or 6. The two MUST are incorrect: The first one is incorrect since there there is the possibility of using Revised PKE *aggressive* mode and still protect the certificate's identity. As for the second MUST, Revised PKE Main mode allows for certificate inclusion and encryption in the third message. [......] > > In Main Mode with encryption-based authentication, Certificate payloads > SHOULD only appear in messages 1, 2, and 3 because that is the only > place where they are useful for the exchange; note that the > certificates in these messages are not encrypted and will thus reveal > identity information. The last sentence (after ;) does not hold for Revised PKE mode. [......] > > IKE Main Mode attempts to preserve identity protection by only sending > ID payloads in messages 5 and 6, which are encrypted. Sending > certificates in unencrypted IKE Main Mode messages (1 through 4) will > reveal the identity of the sender. Note that sending certificates in > Main Mode for encryption-based authentication by its very nature will > expose the identity of the sender. Again, as explained, the above is incorrect. From owner-ipsec@lists.tislabs.com Thu Jul 13 08:20:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26715; Thu, 13 Jul 2000 08:20:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29688 Thu, 13 Jul 2000 09:56:21 -0400 (EDT) Message-ID: <310508EDF557D31188FA0050DA0A375265870B@CAT01S2> From: Tim Jenkins To: "'tytso@mit.edu'" Cc: ipsec@lists.tislabs.com Subject: RE: WG Last call: draft-jenkins-ipsec-rekeying-06.txt Date: Wed, 12 Jul 2000 16:48:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: tytso@mit.edu [mailto:tytso@mit.edu] > Sent: Wednesday, July 12, 2000 4:49 PM > To: TJenkins@Catena.com > Cc: ipsec@lists.tislabs.com > Subject: Re: WG Last call: draft-jenkins-ipsec-rekeying-06.txt > > > From: Tim Jenkins > Date: Mon, 10 Jul 2000 08:54:43 -0400 > > There is one potential issue with the references, in that > the document > refers to which I believe > has expired and has > not been replaced. Do I need to do something with that? > > Yes, we can't have any references to expired I-D's. I assume the > simpliest thing to do is replace it with the IKE RFC; or is there some > specific reason why you referenced the ike-01.txt I-D? Yes. The ike-01.txt document greatly clarified the usage of the commit bit. However, I'll look at taking out some of the words around that. I've got some other editing to do on it anyway, thanks to Hugh Redelmeier!! > > - Ted > From owner-ipsec@lists.tislabs.com Thu Jul 13 08:31:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27731; Thu, 13 Jul 2000 08:31:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29702 Thu, 13 Jul 2000 09:57:22 -0400 (EDT) Message-Id: <200007130135.SAA23452@potassium.network-alchemy.com> To: Jan Vilhuber cc: "D. Hugh Redelmeier" , IPsec List , Hugh Daniel , John Gilmore Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] In-reply-to: Your message of "Wed, 12 Jul 2000 17:01:00 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23449.963452134.1@network-alchemy.com> Date: Wed, 12 Jul 2000 18:35:34 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For all the complaints about poor definition of terms (e.g. "system") it seems surprising that a private definition of "unique" would guide an objection to advancement of this draft. The protection against a man-in-the-middle is that the nonces are random and _both_ are included in HASH(2) and HASH(3). Replay will not work as long as the hashes are checked and the responder does not allow the SAs to be used until HASH(3) has been received and processed (whether he mallocs space and does a "pre-set-up" is not a useful point to discuss). Replaying an old Responder-to-Initiator message (#2) back to the Initiator will result in a failure because the Initiator will assume it is message #1 in Quick Mode but the hash check will fail. Replaying an old Initiator-to-Responder message (#1) back to the Responder will result in the Responder sending an unexpected message #2 back to the Initiator which will fail the hash check (for the same reason). The response will time out naturally and since the Responder didn't actually create usable SAs all that's lost is some temporary space. Provided that there are not 2 simultaneous Quick Modes taking place with the same message ID your are not going to have problems. That, to me, is the requirement. Granted, the term "unique" is not defined but that does not mean that it is alright to use a private definition which imposes an onerous, and unnecessary, burden on implementations. And I still don't see the security hole. Dan. On Wed, 12 Jul 2000 17:01:00 PDT you wrote > On Wed, 12 Jul 2000, D. Hugh Redelmeier wrote: > > Initiator Responder > > ----------- ----------- > > HDR*, HASH(1), SA, Ni > > [, KE ] [, IDi2, IDr2 ] --> > > <-- HDR*, HASH(2), SA, Nr > > [, KE ] [, IDi2, IDr2 ] > > HDR*, HASH(3) --> > > > > Broadly speaking, our major proposal is to use what > > draft-jenkins-ipsec-rekeying-06.txt calls "Responder Pre-Set-Up" in > > Quick Mode. The Responder will set up the SA(s) inbound to it before > > sending the reply to the first message from the Initiator. > > > > draft-jenkins-ipsec-rekeying-06.txt describes fairly well the > > advantages of RPSU. But it vetoes this approach because it claims > > that RPSU is vulnerable to a replay attack. A man in the middle could > > capture a Quick Mode first message from the Initiator and replay it to > > the Responder, provoking the Initiator to set up useless inbound SAs. > > Those useless SAs might even be no longer secure. > > > > In fact, the replay attack cannot work if the Responder implements the > > RFCs. The RFCs stipulate that the Message IDs of Phase 2 exchanges must > > be unique. > > I don't remember for sure, but I thought message ID's were also supposed to > be random. So unless a host saved a list of ALL messages ID's ever used or > encountered, then you couldn't detect the replay! So you must either use a > sequentially increasing message-id, which I was under the impression that > this was a bad idea, or you need to add some sort of time-stamp to the > packets so that they can be rejected in kerberos fashion... > > So I'm not quite as confident as you that this is simply a matter of > 'implementing the rfc's' properly. > > I interpret 'unique' as meaning that they are unique in the sender's > 'name-space'. It means that I can not send out two quick-modes with > message-id == 5 AT THE SAME TIME. There's nothing from preventing me (or my > bad random number generator) from sending out a quick mode with message-id 5 > now, and then again 10 minutes from now, after I'm long done with the old > quick mode that used 5 (and completely oblivious to it, too, unless I keep a > list of all previously used message-ids). > > Can you elaborate on this some more? > > Bottom line is that I don't think the intent of the message-id was to prevent > replay attacks. It's simply an identifier to match up requests and replies. > The Nonces fulfill the replay requirement, but if you use "Responder > Pre-Set-Up", then you're not waiting to get QM3 (that proves that the remote > has the right key) before setting up your SA and accepting traffic on it. > > So I believe Tim is right in that there is a security hole here. > > jan > > > > A replayed message would not meet this requirement. Since > > the Message ID is authenticated, it cannot be forged by a man in the > > middle. > > > > The enforced uniqueness of Message IDs prevents replay attacks for > > certain other exchanges such as Informational. > > > > > > Enforcing Uniqueness of Message IDs > > =================================== > > > > We infer from some comments that some implementations do not enforce the > > requirement that Message IDs be unique. Although this isn't RFC > > compliant, the suggestion is that the RFCs be changed! The specific > > suggestion is that "probably unique" is good enough. We claim that > > the cost of enforcing uniqueness of Message IDs is well repaid by the > > advantages it affords: simple robust rekeying and defence against some > > replay attacks. > > > > Uniqueness of Message IDs over all messages seen by a system cannot > > sensibly be enforced. If a system communicates with two peers, each > > may choose the same Message ID for an exchange with our system. > > Forbidding this is silly. > > > > Since each Message ID appears under the protection of an ISAKMP SA, > > and only has meaning within that ISAKMP SA, uniqueness should only be > > required within the scope of a particular ISAKMP SA. (This needs to be > > made explicit in the RFCs.) > > > > One complaint about enforcing uniqueness of Message IDs is that it > > appears to require an unbounded amount of state in an ISAKMP SA to > > store all the used Message IDs. Although the state for each Message > > ID is small (4 octets), there might be a very large number of them. > > > > It turns out that there is a simple way to prune this state: > > negotiate a new ISAKMP SA and delete the old one. At this point, none > > of the state matters any more. It was only used to enforce uniqueness > > of future Message IDs for exchanges under the protection of the old > > ISAKMP SA, and there will be none. > > > > In practice, we have not noticed an inordinate build up of defunct > > Message IDs, and so think that replacing ISAKMP SAs for this reason > > will not normally be required. > > > > > > The advantages of Responder Pre-Set-Up > > ====================================== > > > > Many of the advantages are discussed in > > draft-jenkins-ipsec-rekeying-06.txt. > > > > If we can assume that all implementations use RPSU, no extra > > handshaking is required to prevent race conditions in setting up an > > IPSEC SA. > > > > There is no need for the Initiator to delay using its new outbound SA, > > because it is guaranteed to have been installed. There is no need for the > > Commit Bit (a flawed mechanism as it is). There is no need to wait > > for inbound traffic as a proxy for an ACK communicating that the > > outbound SA ready. > > > > The Responder knows that it may use its outbound SA as soon as it > > receives the last Quick Mode message. > > > > It all just works. No Informational messages are required. No > > observation of IPsec traffic is required. No timeouts are required > > (except those for retransmission of the Quick Mode messages). > > > > There is one flaw in this happy setup. If the peer is not using RPSU, > > but instead sets up its inbound SAs on reception of the last Quick > > Mode message, then there is a race condition. The race is between the > > last Quick Mode message and the first outbound IPsec packet from the > > Initiator. > > > > Two reactions to this problem seem reasonable to us: > > > > - consider the peer to be in error. After all, we are RFC compliant > > so it should handle this case. > > > > - consider the problem to be minor: IP protocols are supposed to > > recover from lost packets, so the occasional lost initial packet should > > not be a disaster. > > > > We think that it would be a mistake to try to "paper over" the problem > > by, for example, making the Initiator delay a fixed amount of time > > between sending the last Quick Mode message and the first IPsec > > message. This would complicate all future implementations and reduce > > their performance. > > > > In this, we diverge from RPSU as described by > > draft-jenkins-ipsec-rekeying-06.txt In 2.2.1, that document states: > > > > Implicit acknowledgement of the reception of the third quick mode > > message by the responder is provided by use of the new SA in the > > initiator's inbound direction. The initiator should not use its new > > outbound SA before that time. > > > > This implicit acknowledgement might well never come! After all, the > > conversation was initiated by the Initiator -- maybe it is the only > > one with something to say. > > > > > > Implementation Experience > > ========================= > > > > We have implemented this technique in FreeS/WAN (www.freeswan.org). > > > > The implementation as a whole is minimal: it leaves out large parts of IKE: > > > > - no Informational Payloads are understood or generated > > > > - the Commit Bit isn't implemented > > > > - the IKE implementation knows nothing about actual traffic on the > > IPsec SAs > > > > Even so, this implementation interoperates quite well with others. It > > rekeys successfully. > > > > The one problematic case of which we are aware is with an > > implementation which depends on Delete Payloads to switch between SAs. > > We consider this a bug in that implementation, since Delete messages > > are not acknowledged and hence their delivery is unreliable. > > > > Hugh Redelmeier > > hugh@mimosa.com > > > > Henry Spencer > > henry@spsystems.net > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > From owner-ipsec@lists.tislabs.com Thu Jul 13 09:18:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02854; Thu, 13 Jul 2000 09:18:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00021 Thu, 13 Jul 2000 10:37:23 -0400 (EDT) Message-ID: <310508EDF557D31188FA0050DA0A3752658712@CAT01S2> From: Tim Jenkins To: "'hugh@mimosa.com'" , IPsec List Cc: Hugh Daniel , John Gilmore Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt Date: Thu, 13 Jul 2000 10:30:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk All, Let me preface this response with a few comments. First, my understanding of an information RFC "... does not represent an Internet community consensus or recommendation" and that it is intended to provide a mechanism to allow the presentation of information related to IETF activities. (Quotes are from section 4.2.2 of RFC 2026 "Internet Standards Process".) Given that I believe and have been told by others that the information in this document is of value to IPsec implementors, I wanted to make the information available persistently. The only way that I know how to do that under the current circumstances is to make it an informational RFC. I believe the document provides ideas and thoughts for implementors dealing with the current standards-track RFCs, and provides potential ideas for future discussion on the standards-track RFCs. Additionally, I have neither the mandate nor the bandwidth to spend a lot of time on this document anymore. So, if it is not appropriate as an informational RFC with only relatively minor changes, then I will be forced to abandon it. What this means is that I need a definitive answer as to the suitability of the document as an informational RFC. (I understand I have to remove references to IKEbis in any case.) Now, I'll attempt to respond to the specifics. > -----Original Message----- > From: D. Hugh Redelmeier [mailto:hugh@mimosa.com] > Sent: Wednesday, July 12, 2000 6:10 PM > To: IPsec List > Cc: Hugh Daniel; John Gilmore > Subject: problems with draft-jenkins-ipsec-rekeying-06.txt > > > This document describes a number of substantive problems we > perceive with > draft-jenkins-ipsec-rekeying-06.txt. We don't think this > draft is ready > to be an RFC, even an Informational one. We see significant > problems in > both the description and the intent. (We apologize for > leaving this to > the last minute, but much of this became clear to us only recently.) > > | 2.2.1.4 Responder Pre-Set-up Security Hole > | > | In the failed negotiation case, the need to delete the invalid > | inbound SA raises the issue of a temporary hole, in that the > | responder allows inbound packets while waiting for the > third quick > | mode message. However, if the inbound SA is not set up ahead of > | time, initiators that immediately transmit on the new outbound SA > | will cause packets to be dropped. > > We don't see why this is a security hole. The Responder has set up an > inbound IPSEC SA because the Initiator has made a request to do so. > The request is authenticated and the protection suite has been > selected. This seems adequately secure. I think later you recognize this is due to potential replay, and you solve this by recording previously used message IDs within the phase 1 SA from that peer. Your justification is that message IDs are required by the RFCs to be unique. I am unable to find such a requirement. RFC 2408 section 3.1 only says "This value is randomly generated by the initiator of the Phase 2 negotiation." In practise, this may mean that it is unique, but it's not a requirement. So, my conclusion is that based on the RFCs as they stand, there is a potential hole. > > | It also illustrates why the proposal above made the usage of the > | outbound SA by the initiator wait until there is an indication of > | the use of the SA by the responder. > > This isn't required because the responder could set up the SA earlier. > > | Note that this security hole is exactly what would result from an > | attacker replaying the first quick mode message of an exchange. > > A replay attack cannot succeed since the RFCs require that the Message > ID be unique. The Message ID is protected by encryption and > authenticated by being included in HASH(1). See above about the uniqueness requirement. > > > | 2.2.2 Recommended Re-keying Method > > | 2.2.2.2 Absence of Traffic > > | However, due to the number of implementations that > delete old SAs 30 > | seconds after negotiating a new one, the same behaviour > has the best > | chance of interoperability, and of not dropping packets > when traffic > | does restart. > | > | Therefore, it is recommended that implementations delete > old SAs and > | start using new SAs 30 seconds after negotiating new SAs in the > | absence of traffic. Use of the DELETE notification is strongly > | recommended in cases where the peer implementation is > continuing to > | use the old SA. > > It would surely aid interoperability to leave the the inbound SA for a > longer time. This is true even if the DELETE notification is sent -- > it can be lost or ignored. > > There are other reasons to delete the inbound SA, and they may point > to a recommendation for deletion, but the reason given here does not > apply. I don't understand what you're objecting to here. Yes, it's obvious that leaving an old SA up longer (when permitted) aids interoperability, but how long provides real value? The 30 second suggestion is based on implementation experience, as stated in the first paragraph of that section. > > > | 3.4.2 INITIAL-CONTACT Notification > | > | As stated above, the INITIAL-CONTACT notification should be used > | only with the very first phase 1 SA that is negotiated > between two > | peers. > > We think that INITIAL-CONTACT is a useful mechanism, but there are > flaws. > > - There are well-known problems with the integrity of Informational > Payloads. Within a Main Mode exchange, they are not authenticated. > The consequences of acting on a forged INITIAL-CONTACT are severe. > > - the meaning of INITIAL-CONTACT is not sufficiently nailed down in > rfc2407.txt: > > "The INITIAL-CONTACT status message may be used when one > side wishes > to inform the other that this is the first SA being > established with > the remote system." > > + the meaning of "system" is not given. > > * Are systems identified with IP addresses? > (in reality, a system might have several IP addresses) > > * Do/should Phase 1 IDs play any part in this? > (It might be that the authority to blow away other SAs > should be limited to SAs that have the same ID, the basis > for authentication.) > > + Observations on one system may be ordered differently from > observations on another. So the word "first", upon which the > meaning of INITIAL-CONTACT crucially depends, is not defined in a > way that both will always agree. This is exacerbated because > INITIAL-CONTACT should be delayed until a Quick Mode negotiation, > so it can be authenticated and hence trustworthy. > > (We actually think that a FINAL-CONTACT message would be > useful, given a > precise definition. Interestingly, we think that > INITIAL-CONTACT might be > usable for this purpose! After all, it would probably cause > all but one > SA to be deleted; it might prompt the recipient to > renegotiate SAs, but > the sender could refuse to negotiate.) Your comments on INITIAL-CONTACT are applicable to the RFCs and not to this document. Further, I disagree that the use of INITIAL-CONTACT is not allowed in main mode by the RFCs. If the INITIAL-CONTACT is passed in one of the encrypted main mode exchanges, and not acted upon until main mode is complete, what is the problem? > > | If used on subsequent negotiations, it means that all > pre-existing > | SAs (phase 1 and phase 2) held between the peers should > be deleted. > > It is interesting to note that INITIAL-CONTACT is only defined in the > IPSEC-DOI. This seems like an oversight to us. This could be a > problem because a Main Mode SA proposal could specify a DOI of 0. > This document should require that IPSEC-DOI be specified. Which document? Again, I think your comments apply to the RFCs, not this document. > > | As an example, this is the mechanism used to detect when > an SA end > | point has crashed and is now alive again. > | > | The use of INITIAL-CONTACT may be restricted by the mode used to > | negotiate phase 1 SAs. For these reasons, > implementations may want > | to avoid the use of aggressive mode when possible. When > it is used, > | it is recommended that the third aggressive mode message be > | encrypted so that the INITIAL-CONTACT notification can > be added to > | it when needed. Note that the use of any notification by > a responder > | during aggressive mode is not allowed, and this document's > | suggestion that the use of INITIAL-CONTACT is permitted by the > | initiator if the third aggressive mode packet is encrypted is > | possibly contrary to RFC2408. > | > | Alternatively, if notifications cannot be used within the phase 1 > | modes at all, it is recommended that INITIAL-CONTACT be sent in a > | notification packet (preferably acknowledged) > immediately after the > | phase 1 is complete. Reception of this notification (at any time) > | should indicate to the receiver that all other SAs, phase 1 and > | phase 2, with the sender must be deleted. (In other words, the SA > | that was used to encrypt the notification is the only SA > that is not > | deleted.) > > The only safe places to put INITIAL-CONTACT that are > RFC-compliant are in > the first two messages of a Quick Mode Exchange. Elsewhere > they are not > authenticated, cannot be trusted, and *must be ignored*. See above; I disagree with this. > > > | 3.4.1 Multiple SA Usage > ^ISAKMP > | > | When there is more than one phase 1 SA between peers, > > What is the definition of "peers" being used here? Not all ISAKMP SAs > are interchangeable. Some have different protection suites. Some > have different Phase 1 ID authentication. I think the intent of the section is clear: what do you do when there is more than phase 1 SA that can be used? Do I really need to define peer more explicitly here? This section is not about how to decide if you have two phase 1 SAs with the same peer. It might be a worthwhile discussion, but it's out of scope of this document. (If asked to define what multiple ISAKMP SAs with same peer means, I would say that the the phase 1 IDs matching is the requirement.) > > | it is > | recommended that the oldest SA be used for subsequent traffic > | requiring phase 1 SAs. > > We have found that always using the newest ISAKMP SA avoids some > problems when a system is restarted. INITIAL-CONTACT addresses some > of the same problems, but it is optional, ill-defined, inconsistently > used, and less timely. Again, this document is intended to be information only, to attempt to help make implementors aware of issues and options. Does the existence of alternatives make this document invalid as informational? > > | This allows full use of the keying material > | generated > > We don't understand this to be an issue. Surely if a new ISAKMP SA is > negotiated, it was negotiated for some reason. If the reason is that > it was time to rekey, then the keying material is close to expired -- > discarding the old ISAKMP SA wastes little. If it was another reason, > this rule may stymie the intent. Are you saying that since the waste is little there's no value in stating this as a reason? > > | and reduces race conditions. > > Which race conditions? > > | It also means that no special > | expiration conditions are required when the phase 1 SAs expire by > | traffic or other usage dependent expirations only, as the old SA > | will eventually expire on its own due to usage. > > We don't think that there is a negotiated way to expire Phase 1 SAs by > traffic, is there? (Vague inference from some list traffic.) If not, > this argument doesn't apply. Well, IKEbis might deprecate phase 1 SA lifetime negotiation by traffic, but it's still in the RFCs as being usable. There was also talk of adding a "number of keys generated" parameter that could be negotiated for phase 1. That would be similar to a traffic value. > > > | 3.4.4 Re-keying Timing > > | An example of this is that the end with the higher IP address re- > | keys at 95% of the lifetime, while the end with lower IP > address re- > | keys at 85% of the lifetime. > > Although this is only an example, this document is quite influential. > We think that there is a better way of breaking the symmetry, and we'd > like it to be used as the example, or even become a recommendation. > > We suggest that the bias be towards rekeying by the Initiator over the > Responder. These roles are already an asymmetry in the standards. > > The Initiator has already been able to initiate, so the chances of > rekeying succeeding are probably higher if the Initiator re-initiates. > We have actually observed this to make a significant difference. I'll look into substituting your suggestion as the example. > > | Whatever rule is chosen, it is recommended that the rule be > | deterministic in order to have predictable and > consistent behaviour > | between peers. If the rule had used the SPI as the determining > | factor (as an example did in the first version of this document), > | different peers would be doing the re-keying at different times. > > We have found great value in adding jitter to the rekeying threshold. > True, this adds non-determinacy, but it also helps prevent and cure > "convoy" behaviour. This convoy behaviour was a serious problem with > a hub server. I can add some comments about jitter as well. > > > | 4. Next IPsec Version Recommendations > > We would add a few recommendations: > > - Make Identity PFS an announced (or negotiated) property so that both > peers know that it is in effect. > > - Clarify the meaning of INITIAL-CONTACT. Perhaps make it an ISAKMP > Notification. Perhaps add FINAL-CONTACT. > > - authenticate optional payloads in all exchanges. Authenticate the > header (for example, the Commit Bit). > > - allow the responder to an Acknowledged Informational to include > information about whether the message was understood or acted upon. > For example, a response to a Delete ought to be able to indicate > whether the deletion was understood. At least some of these > responses should be standardized. > All of these suggestions are beyond the scope of this document, and they're also not mine. This document is not intended to be IKEbis. I would recommend you pursue them separately, since they are things that should be in IKEbis. > > | 4.1 Re-transmission Rules > | > | In systems that use exchanges that have an even number > of packets, > | the rules for re-transmission are relatively obvious. > Simply put, a > | packet is re-sent if the expected response to it is not received > | within a certain period of time. > | > | However, IPsec has a number of modes that have an odd number of > | packets. This can lead to confusion as to when the > re-transmission > | rules should be applied, depending how the > re-transmission rules are > | applied to the packets in the exchange. This in turn can > lead to the > | dropping of aggressive mode's and quick mode's third > messages. It is > | recommended that each of these modes have specific rules > applied to > | them to avoid re-transmission issues. > > This section distinguishes exchanges that use an even number of > packets (messages) and those that use an odd number. We think that > this is not the best distinction. We will propose another approach. > > There are two interesting properties of a message in an exchange: > whether it has a preceding message, and whether it has a following > message. Because peers alternate turns in an exchange, the preceding > and following messages come from the other peer. > > If a message has no predecessor, the simple observation is that the > system that sends the message must have decided to do so on its own. > Not much more is worth saying. > > If a message has a successor, this successor (if the protocol is > appropriately designed, as IKE seems to be) will serve as an > acknowledgement of receipt. If there is no acknowledgement in a > timely fashion, the message should be retransmitted. Local policy > should determine the rate of retransmission and how persistent it > should be. > > If a message has a predecessor, and after the message is sent, a > predecessor is received, it could be ignored. After all, UDP can > re-deliver a message. It might be worth checking to see that the new > message is identical to the earlier one -- but if it is different, > what action should be taken? In any case, this message could be taken > as a sign that the peer hadn't received our most recent message. > Should this trigger a retransmission? > > It could be that our last transmission "crossed paths" with the second > copy of the preceding message. Our retransmission could then lead the > other side to retransmit its next message (at least this isn't a > loop). It might be better to just wait to see if we get the > succeeding message in time, and if not *then* retransmit. > > This last approach does not work for the last message in an exchange, > because we are not waiting for another message. In that case, the > reception of a preceding message should definitely trigger a > retransmission. This cannot stimulate spurious retransmission from > the peer since this is the last message. > > This approach is not as robust as one would like in determining that > the last message needs retransmission. In effect, it depends on a > Negative Acknowledgement. On the other hand, if these Negative > Acknowledgements are not getting through, future communication is > unlikely to work anyway. This may suggest that retransmission should > be more persistent for the second-last message in an exchange. > > The only case we haven't covered is that of an exchange with only one > message. This is a case where the last message does not have a > predecessor, so even the NACK isn't available. > > We think that this analysis eliminates the needs for sections 4.1.1, > 4.1.2, and 4.1.3. Again, this document is informational, and makes suggestions. Its contents could be used as a basis for future discussions of the standards. The publication of this document does nothing to prevent the standards from adopting your proposal. My points here are: 1) I don't wish to debate which method is better. I expect both will work. 2) I don't believe that the existence of another proposal should keep this document from being made informational, as I understand the intent of informational. > > > | 4.2 Acknowledged SA Deletion > > | The Acknowledged Informational exchange consists of two > packets. The > | first packet is the transmission of a notify or delete > payload. The > | second is the acknowledgement of that packet. > | > | When used with a delete payload, it is interpreted to mean the > | following: > | > | "I am not sending anymore traffic on this SA (or these > SAs). Would > | you please stop sending traffic on it (or them), and send me an > | acknowledgement when you are done?" > > This discussion seems to reflect a fundamental > misunderstanding of what > Delete does. According to IKEbis, the semantics of Acknowledged SA > Deletion and normal SA Deletion are identical. According to > RFC 2408, a > Delete is not a *request*, it is an *announcement*. Specifically, it > announces that a particular *incoming* (at the sender) SA is no longer > usable. It is not a warning of intent to do so, nor a query > as to whether > this would be acceptable. It does not say anything about > what sorts of > traffic the sender is sending or will send; it says nothing about the > *outgoing* SAs that such traffic would be flowing on. It > does not require > any specific action on the part of the recipient. > > If the intent here is that associations should be made between > incoming and outgoing IPSEC SAs, so that a Delete would *also* imply a > request to delete any associated SAs in the opposite direction, this > needs to be said much more explicitly. >From an operational point of view, meaning, intending to drop as few of the user's packets as possible, yes this is the intent. RFC 2408's meaning is not lost. My suggestions can still be considered an announcement, they just provide an opportunity for the peer to react so that it reduces the probability of lost packets. > > Consideration also needs to be given to whether a new payload > should be > defined to convey this new meaning, and to whether prior > negotiation would > be preferable to after-the-fact notification. The draft's discussion > seems to want Acknowledged Delete to be a prior negotiation -- the two > ends are agreeing to stop using certain SAs, with the implication that > those SAs might then be deleted -- but that is *not* what > Delete does, and > hence is not what Acknowledged Delete does. Such a drastic change in > semantics would be better accommodated in a new payload, rather than a > redefinition of an old one. I feel you are over-stating the differences. Perhaps it's not clear in the draft that if no response is received to the delete notification, the SAs will be deleted anyway. Again, the only difference is instead of saying "This is an announcement that my inbound SA is deleted", it's saying "This is an announcement that my inbound SA is going to be deleted soon; please tell me that you heard me say this". The wording I used in the draft was intended to convey some operational stuff at the same time. > > > | The receiver of the delete request then switches his outbound > | traffic to another SA, deletes both inbound and outbound SAs and > | sends the delete acknowledgement. > > That is a worthwhile convention. And this is a good place to suggest > it. But it isn't in the RFCs, at least not for IPSEC SAs. > > It would be nice to have a new Delete that would delete all the SAs in > a suite at once (both directions, ESP, AH, and IPcomp, if present). > It could be part of IPSEC DOI since this particular issue only arises > with IPSEC SA deletion. > > Unfortunately, as far as we can tell, the response to an Acknowledged > Informational message in no way indicates whether the responder > understood or acted upon the message. > These comments are valid for discussion about IKEbis, but I don't understand what you're looking for with respect to the rekeying document. > > How should one delete the ISAKMP SA used to carry the deletion > message? This would be useful when shutting down a connection. This is a valid question, but the fact that this document doesn't answer that shouldn't stop its acceptable as informational, right? That question should be answered in ISAKMPbis/IKEbis/whatever. > > > | 4.5 Commit Bit Replacement > > The Commit Bit has serious problems. Does it fulfill a real need? > The race condition outlined in 2.1.3 is eliminated if the Responder > sets up the inbound SA earlier (we explained why we don't think that > this is a security hole). > > If it does fulfill a need, its worst problems can be fixed by > authenticating it (as proposed elsewhere). True, that is a change, > but so are the additions proposed in this section. The proposed > additions seem much more complicated. Again, they are proposals only, in what intended as informational. They are intended to provide ideas moving forward. Also again, I don't believe the race condition is eliminated. > > Hugh Redelmeier > hugh@mimosa.com > > Henry Spencer > henry@spsystems.net > Tim From owner-ipsec@lists.tislabs.com Thu Jul 13 10:31:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04911; Thu, 13 Jul 2000 10:31:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00371 Thu, 13 Jul 2000 12:04:47 -0400 (EDT) Date: Thu, 13 Jul 2000 12:12:45 -0400 (EDT) From: Henry Spencer To: Tim Jenkins cc: Hugh Redelmeier , IPsec List , Hugh Daniel , John Gilmore Subject: procedural RE: problems with draft-jenkins-ipsec-rekeying-06.txt In-Reply-To: <310508EDF557D31188FA0050DA0A3752658712@CAT01S2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 13 Jul 2000, Tim Jenkins wrote: > First, my understanding of an information RFC "... does not represent an > Internet community consensus or recommendation" ... > Given that I believe and have been told by others that the information in > this document is of value to IPsec implementors, I wanted to make the > information available persistently. The only way that I know how to do that > under the current circumstances is to make it an informational RFC. Unfortunately, when an Informational RFC is the sole document discussing how to solve vexing interoperability problems, it tends to become a de-facto standard even if it explicitly disclaims that status. RFC 1036 was "the standard" for Usenet article formatting for a decade, even though it is (in modern terminology) an Informational RFC. There is a crying need for a standards-track effort in this area, but currently none is being made. We see a very real possibility of approaches which we consider inferior becoming accepted practice, hampering interoperability with better approaches, simply because they are the ones described by the only easily-accessible document on the subject. Pasting a disclaimer on the document will not prevent this, not when the document fills a persistent and painful vacuum. Hence our objections. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Jul 13 10:40:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05030; Thu, 13 Jul 2000 10:40:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00416 Thu, 13 Jul 2000 12:30:00 -0400 (EDT) Message-ID: <396DF034.D0320D33@redcreek.com> Date: Thu, 13 Jul 2000 09:37:08 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: William Dixon CC: tytso@mit.edu, ipsec@lists.tislabs.com Subject: Re: Call for agenda topics for Pittsburgh IETF References: <6A05D00595BE644E9F435BE5947423F2038CB3F6@fifi.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk William Dixon wrote: > > Ted, I'd appreciate a slot for Bernard Aboba and myself to present his > IPSec/NAT draft already submitted. > > http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-01.txt > This link is broken. Actually, the draft is currently version 02, not 01. Scott From owner-ipsec@lists.tislabs.com Thu Jul 13 10:45:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05106; Thu, 13 Jul 2000 10:45:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00410 Thu, 13 Jul 2000 12:28:45 -0400 (EDT) X-Authentication-Warning: redshift.mimosa.com: hugh owned process doing -bs Date: Thu, 13 Jul 2000 12:38:56 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: Tim Jenkins cc: IPsec List , Hugh Daniel , John Gilmore , Henry Spencer Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt In-Reply-To: <310508EDF557D31188FA0050DA0A3752658712@CAT01S2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk | From: Tim Jenkins In this message, I'll deal only with one key point Tim makes: | Your justification is that message IDs are required by the RFCs | to be unique. | | I am unable to find such a requirement. RFC 2408 section 3.1 only says "This | value is randomly generated by the initiator of the Phase 2 negotiation." In | practise, this may mean that it is unique, but it's not a requirement. On 2000 June 20, I sent a message to the list with the subject "uniqueness of Message IDs and related issues". It dealt this topic in detail. I'll cut and paste a few bits of it here. For more complete coverage, have a look at the original message. RFC2408 "ISAKMP" 3.1 "ISAKMP Header Format" (near end) states that the Message ID must be unique: o Message ID (4 octets) - Unique Message Identifier used to identify protocol state during Phase 2 negotiations. This value is randomly generated by the initiator of the Phase 2 negotiation. In the event of simultaneous SA establishments (i.e. collisions), the value of this field will likely be different because they are independently generated and, thus, two security associations will progress toward establishment. However, it is unlikely there will be absolute simultaneous establishments. During Phase 1 negotiations, the value MUST be set to 0. ... from RFC2409 "IKE", section 5.5 "Phase 2 - Quick Mode": The message ID in the ISAKMP header identifies a Quick Mode in progress for a particular ISAKMP SA which itself is identified by the cookies in the ISAKMP header. But another part, 5.7 "ISAKMP Informational Exchanges" says: As noted the message ID in the ISAKMP header-- and used in the prf computation-- is unique to this exchange and MUST NOT be the same as the message ID of another phase 2 exchange which generated this informational exchange. This does not qualify "unique" in any way. It does clearly use the admonition "MUST NOT". Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec@lists.tislabs.com Thu Jul 13 10:55:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05341; Thu, 13 Jul 2000 10:55:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00442 Thu, 13 Jul 2000 12:36:56 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Thu, 13 Jul 2000 09:44:54 -0700 (PDT) From: Jan Vilhuber To: "D. Hugh Redelmeier" cc: IPsec List , Hugh Daniel , John Gilmore Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] 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, 13 Jul 2000, D. Hugh Redelmeier wrote: > | From: Jan Vilhuber > > | > In fact, the replay attack cannot work if the Responder implements the > | > RFCs. The RFCs stipulate that the Message IDs of Phase 2 exchanges must > | > be unique. > | > | I don't remember for sure, but I thought message ID's were also supposed to > | be random. So unless a host saved a list of ALL messages ID's ever used or > | encountered, then you couldn't detect the replay! > > As we explain slightly later in the same document, it is only > necessary to save message IDs used/encountered *within the current > ISAKMP SA*. When the ISAKMP SA expires (whether or not it is replaced > by a fresh one), the message-ID memory can be freed. As also noted, > we have implemented this and the memory consumption has not been a > problem in practice. Half-measures are not necessary; doing it really > right is not costly. > I disagree. This adds even more memory to internal state that must be kept. In machines with limited memory, this is an issue. jan > It appears you didn't understand what we were trying to say. Could > you explain what parts aren't clear? We'd like to make it clear. > > | I interpret 'unique' as meaning that they are unique in the sender's > | 'name-space'. > > We suggested in the quoted section that "unique within an ISAKMP > SA" would be sensible and sufficient. > > (At one time our implementation used a broader scope of uniqueness > but the greater burden was still not a problem.) > > | It means that I can not send out two quick-modes with > | message-id == 5 AT THE SAME TIME. > > Yes, it means that and more. > > | There's nothing from preventing me (or my > | bad random number generator) from sending out a quick mode with message-id 5 > | now, and then again 10 minutes from now, after I'm long done with the old > | quick mode that used 5 (and completely oblivious to it, too, unless I keep a > | list of all previously used message-ids). > > I see nothing in the RFC to bound the time the way you seem to. So > yes, there is something preventing you: you are not following the RFC > if the Message ID is not unique. And you won't interoperate with my > implementation which is following the RFC. > > | Can you elaborate on this some more? > | > | Bottom line is that I don't think the intent of the message-id was to prevent > | replay attacks. > > I'm not arguing about intent, only about following the specifications. > The specs say "unique", and that gives a wonderful property. Are you > suggesting we change the specs to remove this property? > > | It's simply an identifier to match up requests and replies. > | The Nonces fulfill the replay requirement, but if you use "Responder > | Pre-Set-Up", then you're not waiting to get QM3 (that proves that the remote > | has the right key) before setting up your SA and accepting traffic on it. > > We are preventing replay. Given that, plus authentication, it does > not appear to us that this proof is required at this point. Have we > overlooked something? > > | So I believe Tim is right in that there is a security hole here. > > If we are preventing replay, do you think there is still a hole? > > Hugh Redelmeier > hugh@mimosa.com voice: +1 416 482-8253 > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Jul 13 11:09:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05748; Thu, 13 Jul 2000 11:09:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00492 Thu, 13 Jul 2000 12:54:47 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4408.0 content-class: urn:content-classes:message Subject: RE: Call for agenda topics for Pittsburgh IETF MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFECEC.18B060B4" Date: Thu, 13 Jul 2000 10:02:16 -0700 Message-ID: <6A05D00595BE644E9F435BE5947423F2038CB403@fifi.platinum.corp.microsoft.com> Thread-Topic: Call for agenda topics for Pittsburgh IETF Thread-Index: Ab/s6LxvLKvam3ksSjui4YtODqNx9QAA1cEw From: "William Dixon" To: "Scott G. Kelly" Cc: , , "Bernard Aboba" X-OriginalArrivalTime: 13 Jul 2000 17:03:12.0585 (UTC) FILETIME=[3A65CB90:01BFECEC] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFECEC.18B060B4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Scott, it worked yesterday... here is the latest draft not yet indexed by draft search, but posted: http://www.ietf.org/internet-drafts/draft-aboba-nat-ipsec-02.txt -----Original Message----- From: Scott G. Kelly [mailto:skelly@redcreek.com] Sent: Thursday, July 13, 2000 9:37 AM To: William Dixon Cc: tytso@mit.edu; ipsec@lists.tislabs.com Subject: Re: Call for agenda topics for Pittsburgh IETF William Dixon wrote: >=20 > Ted, I'd appreciate a slot for Bernard Aboba and myself to present his > IPSec/NAT draft already submitted. >=20 > http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-01.txt >=20 This link is broken. Actually, the draft is currently version 02, not 01. Scott ------_=_NextPart_001_01BFECEC.18B060B4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Call for agenda topics for Pittsburgh IETF

Thanks Scott, it worked yesterday...  here is the = latest draft not yet indexed by draft search, but posted:

http://www.ietf.org/internet-drafts/draft-aboba-nat-ipsec-02.txt


-----Original Message-----
From: Scott G. Kelly [mailto:skelly@redcreek.com]
Sent: Thursday, July 13, 2000 9:37 AM
To: William Dixon
Cc: tytso@mit.edu; ipsec@lists.tislabs.com
Subject: Re: Call for agenda topics for Pittsburgh = IETF


William Dixon wrote:
>
> Ted, I'd appreciate a slot for Bernard Aboba and = myself to present his
> IPSec/NAT draft already submitted.
>
> http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-01.txt
>

This link is broken. Actually, the draft is currently = version 02, not
01.

Scott

------_=_NextPart_001_01BFECEC.18B060B4-- From owner-ipsec@lists.tislabs.com Thu Jul 13 11:12:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05971; Thu, 13 Jul 2000 11:12:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00509 Thu, 13 Jul 2000 12:58:28 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14701.63299.957321.849848@xedia.com> Date: Thu, 13 Jul 2000 13:07:15 -0400 (EDT) To: henry@spsystems.net Cc: TJenkins@Catena.com, hugh@mimosa.com, ipsec@lists.tislabs.com, hugh@toad.com, gnu@toad.com Subject: Re: procedural RE: problems with draft-jenkins-ipsec-rekeying-06.txt References: <310508EDF557D31188FA0050DA0A3752658712@CAT01S2> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Henry" == Henry Spencer writes: Henry> On Thu, 13 Jul 2000, Tim Jenkins wrote: >> First, my understanding of an information RFC "... does not >> represent an Internet community consensus or recommendation" ... >> Given that I believe and have been told by others that the >> information in this document is of value to IPsec implementors, I >> wanted to make the information available persistently. The only >> way that I know how to do that under the current circumstances is >> to make it an informational RFC. Henry> Unfortunately, when an Informational RFC is the sole document Henry> discussing how to solve vexing interoperability problems, it Henry> tends to become a de-facto standard even if it explicitly Henry> disclaims that status. RFC 1036 was "the standard" for Usenet Henry> article formatting for a decade, even though it is (in modern Henry> terminology) an Informational RFC. Henry> There is a crying need for a standards-track effort in this Henry> area, but currently none is being made. Henry> We see a very real possibility of approaches which we consider Henry> inferior becoming accepted practice, hampering Henry> interoperability with better approaches, simply because they Henry> are the ones described by the only easily-accessible document Henry> on the subject. ... Henry, That may be true (I need to do more reading before I'd comment more strongly) but I have to side with Tim on this. Let's not throw the baby out with the bathwater. Yes, there's a need for more standards-track work. Standards track RFCs should all have the property that conformance implies interoperability -- all too often that isn't true these days. But meanwhile I feel the situation is improved by making the knowledge in Tim's document widely available. If any of what it says is technically incorrect (i.e., if you do what it says in section X you're worse of than if you didn't) that needs to be fixed. Is there anything like that? From what I can tell from the discussion, no. If anything it says is less than the full answer (i.e., if you do what it says in section Y you're better off than if you didn't, but if you do something different you will also get good results, perhaps even better ones), that's not a valid argument against progress on this document. It isn't, even if this document is "the sole document discussing how to solve vexing interoperability problems". That doesn't prevent anyone from distributing additional information. It doesn't prevent the creation of standards track documents that extend or enhance what's been documented earlier. If you have other ideas on how to make rekeying work better, please document them. That can give rise to additional informational RFCs, new standards track documents, sections in already-planned documents, or whatever is appropriate. If no one steps forward to add to the work that Tim did, his RFC will remain "the sole document discussing how to solve vexing interoperability problems". If that's how things work out, so be it. I would take that as evidence that no one else cares strongly enough to add to the work Tim has done -- but not as an argument against Tim's work. paul From owner-ipsec@lists.tislabs.com Thu Jul 13 13:14:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08256; Thu, 13 Jul 2000 13:14:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01107 Thu, 13 Jul 2000 14:39:11 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Dan Harkins'" , "'Jan Vilhuber'" Cc: "'D. Hugh Redelmeier'" , "'IPsec List'" , "'Hugh Daniel'" , "'John Gilmore'" Subject: RE: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] Date: Thu, 13 Jul 2000 14:42:55 -0400 Message-Id: <003901bfecfa$28ec57e0$d23e788a@andrewk3.ca.newbridge.com> 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 V4.72.2106.4 Importance: Normal In-Reply-To: <200007130135.SAA23452@potassium.network-alchemy.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am in qualified agreement with several of the points that have been brought up here. Hugh: > draft-jenkins-ipsec-rekeying-06.txt is a very important document. > It has plainly laid out key problems with the implementation of IPsec. > It has proposed useful approaches to surmounting them. Yes. This is an area where various interpretations of the RFCs have clearly diverged. There is a lot of "common knowledge" in this area that has come from bakeoffs and such, and it needs to be written down. A BCP-type document is definitely needed in this area. Dan: > Provided that there are not 2 simultaneous Quick Modes taking place > with the same message ID your are not going to have problems. That, to > me, is the requirement. Granted, the term "unique" is not defined but > that does not mean that it is alright to use a private definition > which imposes an onerous, and unnecessary, burden on implementations. In a case where there is a discrepancy between the obvious intent of a clause and an overly literal interpretation of that clause, we should favour the former (and perhaps add clarifying text to the RFC). Dan: > Replay will not > work as long as the hashes are checked and the responder does not > allow the SAs to be used until HASH(3) has been received and processed > (whether he mallocs space and does a "pre-set-up" is not a > useful point > to discuss). > [...] > The response will time out naturally and since the Responder > didn't actually create usable SAs all that's lost is some temporary > space. True, as long as you are not using PFS. If you are using PFS then the responder definitely does not want to pre-calculate the DH shared secret. My suggestion is to not use PFS if you are concerned about temporary packet loss. Hugh: > One complaint about enforcing uniqueness of Message IDs is that it > appears to require an unbounded amount of state in an ISAKMP SA to > store all the used Message IDs. Although the state for each Message > ID is small (4 octets), there might be a very large number of them. > > It turns out that there is a simple way to prune this state: > negotiate a new ISAKMP SA and delete the old one. At this point, none > of the state matters any more. It was only used to enforce uniqueness > of future Message IDs for exchanges under the protection of the old > ISAKMP SA, and there will be none. IMHO, we have already passed up one opportunity to have a technically clever, fully stateless protocol and we should not do it again. Requiring the peer to keep track of an array of unsolicited data that you generate breaks the general rule of thumb that a host should be able to control the bound on the amount of data he stores. Forcing a rekey to remedy this situation is not acceptable IMO. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Dan Harkins > Sent: Wednesday, July 12, 2000 9:36 PM > To: Jan Vilhuber > Cc: D. Hugh Redelmeier; IPsec List; Hugh Daniel; John Gilmore > Subject: Re: simplifying rekeying > [draft-jenkins-ipsec-rekeying-06.txt] > > > For all the complaints about poor definition of terms (e.g. > "system") > it seems surprising that a private definition of "unique" would guide > an objection to advancement of this draft. > > The protection against a man-in-the-middle is that the nonces are > random and _both_ are included in HASH(2) and HASH(3). Replay will not > work as long as the hashes are checked and the responder does not > allow the SAs to be used until HASH(3) has been received and processed > (whether he mallocs space and does a "pre-set-up" is not a > useful point > to discuss). Replaying an old Responder-to-Initiator message (#2) back > to the Initiator will result in a failure because the Initiator will > assume it is message #1 in Quick Mode but the hash check will fail. > Replaying an old Initiator-to-Responder message (#1) back to the > Responder will result in the Responder sending an unexpected > message #2 > back to the Initiator which will fail the hash check (for the same > reason). The response will time out naturally and since the Responder > didn't actually create usable SAs all that's lost is some temporary > space. > > Provided that there are not 2 simultaneous Quick Modes taking place > with the same message ID your are not going to have problems. That, to > me, is the requirement. Granted, the term "unique" is not defined but > that does not mean that it is alright to use a private definition > which imposes an onerous, and unnecessary, burden on implementations. > > And I still don't see the security hole. > > Dan. > > On Wed, 12 Jul 2000 17:01:00 PDT you wrote > > On Wed, 12 Jul 2000, D. Hugh Redelmeier wrote: > > > Initiator Responder > > > ----------- ----------- > > > HDR*, HASH(1), SA, Ni > > > [, KE ] [, IDi2, IDr2 ] --> > > > <-- HDR*, HASH(2), SA, Nr > > > [, KE ] [, > IDi2, IDr2 ] > > > HDR*, HASH(3) --> > > > > > > Broadly speaking, our major proposal is to use what > > > draft-jenkins-ipsec-rekeying-06.txt calls "Responder > Pre-Set-Up" in > > > Quick Mode. The Responder will set up the SA(s) inbound > to it before > > > sending the reply to the first message from the Initiator. > > > > > > draft-jenkins-ipsec-rekeying-06.txt describes fairly well the > > > advantages of RPSU. But it vetoes this approach because it claims > > > that RPSU is vulnerable to a replay attack. A man in the > middle could > > > capture a Quick Mode first message from the Initiator and > replay it to > > > the Responder, provoking the Initiator to set up useless > inbound SAs. > > > Those useless SAs might even be no longer secure. > > > > > > In fact, the replay attack cannot work if the Responder > implements the > > > RFCs. The RFCs stipulate that the Message IDs of Phase 2 > exchanges must > > > be unique. > > > > I don't remember for sure, but I thought message ID's were > also supposed to > > be random. So unless a host saved a list of ALL messages > ID's ever used or > > encountered, then you couldn't detect the replay! So you > must either use a > > sequentially increasing message-id, which I was under the > impression that > > this was a bad idea, or you need to add some sort of > time-stamp to the > > packets so that they can be rejected in kerberos fashion... > > > > So I'm not quite as confident as you that this is simply a matter of > > 'implementing the rfc's' properly. > > > > I interpret 'unique' as meaning that they are unique in the sender's > > 'name-space'. It means that I can not send out two quick-modes with > > message-id == 5 AT THE SAME TIME. There's nothing from > preventing me (or my > > bad random number generator) from sending out a quick mode > with message-id 5 > > now, and then again 10 minutes from now, after I'm long > done with the old > > quick mode that used 5 (and completely oblivious to it, > too, unless I keep a > > list of all previously used message-ids). > > > > Can you elaborate on this some more? > > > > Bottom line is that I don't think the intent of the > message-id was to prevent > > replay attacks. It's simply an identifier to match up > requests and replies. > > The Nonces fulfill the replay requirement, but if you use "Responder > > Pre-Set-Up", then you're not waiting to get QM3 (that > proves that the remote > > has the right key) before setting up your SA and accepting > traffic on it. > > > > So I believe Tim is right in that there is a security hole here. > > > > jan > > > > > > > A replayed message would not meet this requirement. Since > > > the Message ID is authenticated, it cannot be forged by a > man in the > > > middle. > > > > > > The enforced uniqueness of Message IDs prevents replay attacks for > > > certain other exchanges such as Informational. > > > > > > > > > Enforcing Uniqueness of Message IDs > > > =================================== > > > > > > We infer from some comments that some implementations do > not enforce the > > > requirement that Message IDs be unique. Although this isn't RFC > > > compliant, the suggestion is that the RFCs be changed! > The specific > > > suggestion is that "probably unique" is good enough. We > claim that > > > the cost of enforcing uniqueness of Message IDs is well > repaid by the > > > advantages it affords: simple robust rekeying and > defence against some > > > replay attacks. > > > > > > Uniqueness of Message IDs over all messages seen by a > system cannot > > > sensibly be enforced. If a system communicates with two > peers, each > > > may choose the same Message ID for an exchange with our system. > > > Forbidding this is silly. > > > > > > Since each Message ID appears under the protection of an > ISAKMP SA, > > > and only has meaning within that ISAKMP SA, uniqueness > should only be > > > required within the scope of a particular ISAKMP SA. > (This needs to be > > > made explicit in the RFCs.) > > > > > > One complaint about enforcing uniqueness of Message IDs is that it > > > appears to require an unbounded amount of state in an ISAKMP SA to > > > store all the used Message IDs. Although the state for > each Message > > > ID is small (4 octets), there might be a very large > number of them. > > > > > > It turns out that there is a simple way to prune this state: > > > negotiate a new ISAKMP SA and delete the old one. At > this point, none > > > of the state matters any more. It was only used to > enforce uniqueness > > > of future Message IDs for exchanges under the protection > of the old > > > ISAKMP SA, and there will be none. > > > > > > In practice, we have not noticed an inordinate build up of defunct > > > Message IDs, and so think that replacing ISAKMP SAs for > this reason > > > will not normally be required. > > > > > > > > > The advantages of Responder Pre-Set-Up > > > ====================================== > > > > > > Many of the advantages are discussed in > > > draft-jenkins-ipsec-rekeying-06.txt. > > > > > > If we can assume that all implementations use RPSU, no extra > > > handshaking is required to prevent race conditions in > setting up an > > > IPSEC SA. > > > > > > There is no need for the Initiator to delay using its new > outbound SA, > > > because it is guaranteed to have been installed. There > is no need for the > > > Commit Bit (a flawed mechanism as it is). There is no > need to wait > > > for inbound traffic as a proxy for an ACK communicating that the > > > outbound SA ready. > > > > > > The Responder knows that it may use its outbound SA as soon as it > > > receives the last Quick Mode message. > > > > > > It all just works. No Informational messages are required. No > > > observation of IPsec traffic is required. No timeouts > are required > > > (except those for retransmission of the Quick Mode messages). > > > > > > There is one flaw in this happy setup. If the peer is > not using RPSU, > > > but instead sets up its inbound SAs on reception of the last Quick > > > Mode message, then there is a race condition. The race > is between the > > > last Quick Mode message and the first outbound IPsec > packet from the > > > Initiator. > > > > > > Two reactions to this problem seem reasonable to us: > > > > > > - consider the peer to be in error. After all, we are > RFC compliant > > > so it should handle this case. > > > > > > - consider the problem to be minor: IP protocols are supposed to > > > recover from lost packets, so the occasional lost > initial packet should > > > not be a disaster. > > > > > > We think that it would be a mistake to try to "paper > over" the problem > > > by, for example, making the Initiator delay a fixed amount of time > > > between sending the last Quick Mode message and the first IPsec > > > message. This would complicate all future > implementations and reduce > > > their performance. > > > > > > In this, we diverge from RPSU as described by > > > draft-jenkins-ipsec-rekeying-06.txt In 2.2.1, that > document states: > > > > > > Implicit acknowledgement of the reception of the third > quick mode > > > message by the responder is provided by use of the new > SA in the > > > initiator's inbound direction. The initiator should > not use its new > > > outbound SA before that time. > > > > > > This implicit acknowledgement might well never come! > After all, the > > > conversation was initiated by the Initiator -- maybe it > is the only > > > one with something to say. > > > > > > > > > Implementation Experience > > > ========================= > > > > > > We have implemented this technique in FreeS/WAN > (www.freeswan.org). > > > > > > The implementation as a whole is minimal: it leaves out > large parts of IKE: > > > > > > - no Informational Payloads are understood or generated > > > > > > - the Commit Bit isn't implemented > > > > > > - the IKE implementation knows nothing about actual traffic on the > > > IPsec SAs > > > > > > Even so, this implementation interoperates quite well > with others. It > > > rekeys successfully. > > > > > > The one problematic case of which we are aware is with an > > > implementation which depends on Delete Payloads to switch > between SAs. > > > We consider this a bug in that implementation, since > Delete messages > > > are not acknowledged and hence their delivery is unreliable. > > > > > > Hugh Redelmeier > > > hugh@mimosa.com > > > > > > Henry Spencer > > > henry@spsystems.net > > > > > > > > > > -- > > Jan Vilhuber > vilhuber@cisco.com > > Cisco Systems, San Jose > (408) 527-0847 > > > From owner-ipsec@lists.tislabs.com Thu Jul 13 13:14:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08267; Thu, 13 Jul 2000 13:14:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01288 Thu, 13 Jul 2000 15:07:35 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B78910D@md-exchange1.nai.com> From: "Mason, David" To: IPsec List Subject: Unique MIDs Date: Thu, 13 Jul 2000 12:14:42 -0700 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 > Replaying an old Initiator-to-Responder message (#1) back to the > Responder will result in the Responder sending an unexpected message #2 > back to the Initiator which will fail the hash check If the responder allows the initiator to use non-unique message IDs then this opens up a DoS avenue especially if PFS was used. The RFCs make several references to unique IVs for the phase 2 exchanges (i.e., unique MID). These references seemed to indicate unique IVs were important for more reasons than just the case of having two simultaneous Quick Modes taking place with the same message ID. The RFCs don't make any statement about the temporal nature of the uniqueness. I assumed the uniqueness of the MID/IV was constrained to the cookie. Even if there were no cryptographic significance to mandating unique IVs there is still the issue of DoS mentioned above. -dave From owner-ipsec@lists.tislabs.com Thu Jul 13 13:14:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08288; Thu, 13 Jul 2000 13:14:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01301 Thu, 13 Jul 2000 15:07:58 -0400 (EDT) Message-ID: <20000713161104.23463.qmail@web5501.mail.yahoo.com> Date: Thu, 13 Jul 2000 09:11:04 -0700 (PDT) From: IPsec Interested Subject: question on IKE To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have the implementation of manual keying. Can someone direct me to IKE from here ?? thanks, David __________________________________________________ Do You Yahoo!? Get Yahoo! Mail ñ Free email you can access from anywhere! http://mail.yahoo.com/ From owner-ipsec@lists.tislabs.com Thu Jul 13 13:18:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08359; Thu, 13 Jul 2000 13:18:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01281 Thu, 13 Jul 2000 15:06:56 -0400 (EDT) Message-ID: <20000713152745.11810.qmail@web5501.mail.yahoo.com> Date: Thu, 13 Jul 2000 08:27:44 -0700 (PDT) From: IPsec Interested Subject: questions on IKE To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have the manual keying implementation based on PF_KEY . I would like to extend my applications to IKE ? Can anybody give me directions to write an IKE daemon ?? Or is it available for ready ?? What should I do if I don't know which machine I am talking to ( Let's assume IKE is running on other machine) thanks, David. __________________________________________________ Do You Yahoo!? Get Yahoo! Mail ñ Free email you can access from anywhere! http://mail.yahoo.com/ From owner-ipsec@lists.tislabs.com Thu Jul 13 13:19:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08384; Thu, 13 Jul 2000 13:19:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01273 Thu, 13 Jul 2000 15:04:56 -0400 (EDT) Message-ID: <310508EDF557D31188FA0050DA0A3752658716@CAT01S2> From: Tim Jenkins To: "'Henry Spencer'" Cc: Hugh Redelmeier , IPsec List , Hugh Daniel , John Gilmore Subject: RE: procedural RE: problems with draft-jenkins-ipsec-rekeying-06. txt Date: Thu, 13 Jul 2000 12:53:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Henry Spencer [mailto:henry@spsystems.net] > Sent: Thursday, July 13, 2000 12:13 PM > To: Tim Jenkins > Cc: Hugh Redelmeier; IPsec List; Hugh Daniel; John Gilmore > Subject: procedural RE: problems with > draft-jenkins-ipsec-rekeying-06.txt > > > On Thu, 13 Jul 2000, Tim Jenkins wrote: > > First, my understanding of an information RFC "... does not > represent an > > Internet community consensus or recommendation" ... > > Given that I believe and have been told by others that the > information in > > this document is of value to IPsec implementors, I wanted > to make the > > information available persistently. The only way that I > know how to do that > > under the current circumstances is to make it an informational RFC. > > Unfortunately, when an Informational RFC is the sole document > discussing > how to solve vexing interoperability problems, it tends to become a > de-facto standard even if it explicitly disclaims that > status. RFC 1036 > was "the standard" for Usenet article formatting for a > decade, even though > it is (in modern terminology) an Informational RFC. This sounds like a problem with the RFC process, not the document. > > There is a crying need for a standards-track effort in this area, but > currently none is being made. Then make the effort. The publication of this document could serve as a catalyst. > > We see a very real possibility of approaches which we > consider inferior > becoming accepted practice, hampering interoperability with better > approaches, simply because they are the ones described by the only > easily-accessible document on the subject. Pasting a > disclaimer on the > document will not prevent this, not when the document fills a > persistent > and painful vacuum. Hence our objections. The alternative is that this document is lost. Is that worse or better than a examination of the issues and an offered solution that works? > > > Henry Spencer > > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Thu Jul 13 13:27:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08501; Thu, 13 Jul 2000 13:27:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01396 Thu, 13 Jul 2000 15:17:52 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: , "'Tim Jenkins'" Cc: "'IPsec List'" , "'Hugh Daniel'" , "'John Gilmore'" , "'Henry Spencer'" Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt Date: Thu, 13 Jul 2000 15:21:40 -0400 Message-Id: <003b01bfecff$92b58b10$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 V4.72.2106.4 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugh: > As noted the message ID in the ISAKMP header-- and used in the prf > computation-- is unique to this exchange and MUST NOT be > the same as > the message ID of another phase 2 exchange which generated this > informational exchange. > > This does not qualify "unique" in any way. It does clearly use the > admonition "MUST NOT". As I mentioned several weeks ago, your statement here is misleading. The "MUST NOT" clause only applies to the statement that the informational exchange shoudn't use the same message id AS THE QM WHICH (PRESUMABLY) CAUSED IT TO BE GENERATED. As for your clear misinterpretation of the word "unique", let's go straight to the source. Take a look at the passage I have blocked off and you will see how the words "unique to" are commonly interpreted. According to Webster: Main Entry: unique Pronunciation: yu-'nEk Function: adjective Etymology: French, from Latin unicus, from unus one -- more at ONE Date: 1602 1 : being the only one : SOLE 2 a : being without a like or equal : UNEQUALED _______________________________________________________ b : distinctively characteristic : PECULIAR 1 _______________________________________________________ 3 : UNUSUAL synonym see STRANGE - unique·ly adverb - unique·ness noun usage Many commentators have objected to the comparison or modification (as by somewhat or very) of unique; the statement that a thing is either unique or it is not has often been repeated by them. Objections are based chiefly on the assumption that unique has but a single absolute sense, an assumption contradicted by information readily available in a dictionary. Unique dates back to the 17th century but was little used until the end of the 18th when, according to the Oxford English Dictionary, it was reacquired from French. H. J. Todd entered it as a foreign word in his edition (1818) of Johnson's Dictionary, characterizing it as "affected and useless." Around the middle of the 19th century it ceased to be considered foreign and came into considerable popular use. With popular use came a broadening of application beyond the original two meanings (here numbered 1 and 2a). In modern use both comparison and modification are widespread and standard but are confined to the extended senses 2b and 3. When sense 1 or sense 2a is intended, unique is used without qualifying modifiers. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of D. Hugh Redelmeier > Sent: Thursday, July 13, 2000 12:39 PM > To: Tim Jenkins > Cc: IPsec List; Hugh Daniel; John Gilmore; Henry Spencer > Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt > > > | From: Tim Jenkins > > In this message, I'll deal only with one key point Tim makes: > > | Your justification is that message IDs are required by the RFCs > | to be unique. > | > | I am unable to find such a requirement. RFC 2408 section > 3.1 only says "This > | value is randomly generated by the initiator of the Phase 2 > negotiation." In > | practise, this may mean that it is unique, but it's not a > requirement. > > On 2000 June 20, I sent a message to the list with the subject > "uniqueness of Message IDs and related issues". It dealt this topic > in detail. I'll cut and paste a few bits of it here. For more > complete coverage, have a look at the original message. > > RFC2408 "ISAKMP" 3.1 "ISAKMP Header Format" (near end) states that > the Message ID must be unique: > > o Message ID (4 octets) - Unique Message Identifier used to > identify protocol state during Phase 2 negotiations. > This value > is randomly generated by the initiator of the Phase 2 > negotiation. In the event of simultaneous SA establishments > (i.e. collisions), the value of this field will likely be > different because they are independently generated > and, thus, two > security associations will progress toward establishment. > However, it is unlikely there will be absolute simultaneous > establishments. During Phase 1 negotiations, the value MUST be > set to 0. > > > ... from RFC2409 "IKE", section 5.5 > "Phase 2 - Quick Mode": > > The message ID in the ISAKMP header identifies a Quick Mode in > progress for a particular ISAKMP SA which itself is > identified by the > cookies in the ISAKMP header. > > But another part, 5.7 "ISAKMP Informational Exchanges" says: > > As noted the message ID in the ISAKMP header-- and used in the prf > computation-- is unique to this exchange and MUST NOT be > the same as > the message ID of another phase 2 exchange which generated this > informational exchange. > > This does not qualify "unique" in any way. It does clearly use the > admonition "MUST NOT". > > Hugh Redelmeier > hugh@mimosa.com voice: +1 416 482-8253 > From owner-ipsec@lists.tislabs.com Thu Jul 13 14:18:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09452; Thu, 13 Jul 2000 14:18:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01685 Thu, 13 Jul 2000 16:00:24 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B78910E@md-exchange1.nai.com> From: "Mason, David" To: IPsec List Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt Date: Thu, 13 Jul 2000 13:07:32 -0700 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 Of course this is way late, but it would have been nice if the draft had given some discussion on the alternative loss-less rekey implementation method suggested in RFC 2408 (the NOTE: in section 3.1). The implementation note is extremely sketchy and it would have been nice if this draft could have provided some additional details on this method. This is how I interpreted the suggestion: Incoming IPsec packets with unrecognized SPIs are treated in a similar fashion to packet fragment collection (e.g., queued up with a time limit and memory consumption limit - the time limit is much smaller than one would use in fragment collection). The IKE daemon is informed of the reception of the unknown SPI (with less frequency than some specified minimum so as not to flood the daemon). If the SPI/protocol/addresses match that of a phase 2 exchange that's waiting for a third QM (or notify connected) message then the system "sets up" the SA (inbound and outbound) as if it had received the message it was waiting for and the queued unrecognized SPI packets are then processed. Otherwise it's a bogus SPI and the packets are thrown away and the event logged (if an IKE SA exists with the source of the packet a delete notify can optionally be sent). This method doesn't require pre-setup or a splitting of the inbound and outbound SAs and seems to handle the dropped 3rd QM, dropped connected notify, and out-of-order QM3/IPsec problems nicely. This method also helps for the case where a delete notify was dropped (if the peer continues to use that SPI it will get another delete notify). -dave From owner-ipsec@lists.tislabs.com Thu Jul 13 14:37:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09898; Thu, 13 Jul 2000 14:37:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01786 Thu, 13 Jul 2000 16:21:46 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B78910F@md-exchange1.nai.com> From: "Mason, David" To: IPsec List Subject: RE: Unique MIDs Date: Thu, 13 Jul 2000 13:28:55 -0700 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 In memory constrained systems the implementer may likely decide that the potential DoS hit is worth risking. If a memory constrained system is negotiating with a peer that doesn't allow duplicate MIDs the randomness of the MID will likely prevent duplicate MIDs anyways. In the rare case that a duplicate MID is used, the non-constrained system should reply with a INVALID-MESSAGE-ID notify (at an interval that won't flood the constrained system when there is a replay attack underway). -dave -----Original Message----- From: Mason, David [mailto:David_Mason@nai.com] Sent: Thursday, July 13, 2000 3:15 PM To: IPsec List Subject: Unique MIDs > Replaying an old Initiator-to-Responder message (#1) back to the > Responder will result in the Responder sending an unexpected message #2 > back to the Initiator which will fail the hash check If the responder allows the initiator to use non-unique message IDs then this opens up a DoS avenue especially if PFS was used. The RFCs make several references to unique IVs for the phase 2 exchanges (i.e., unique MID). These references seemed to indicate unique IVs were important for more reasons than just the case of having two simultaneous Quick Modes taking place with the same message ID. The RFCs don't make any statement about the temporal nature of the uniqueness. I assumed the uniqueness of the MID/IV was constrained to the cookie. Even if there were no cryptographic significance to mandating unique IVs there is still the issue of DoS mentioned above. -dave From owner-ipsec@lists.tislabs.com Thu Jul 13 15:34:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10683; Thu, 13 Jul 2000 15:34:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02030 Thu, 13 Jul 2000 17:26:20 -0400 (EDT) Date: Thu, 13 Jul 2000 17:33:33 -0400 (EDT) From: Henry Spencer To: Dan Harkins cc: "D. Hugh Redelmeier" , IPsec List , Hugh Daniel , John Gilmore Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] In-Reply-To: <200007130135.SAA23452@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 12 Jul 2000, Dan Harkins wrote: > For all the complaints about poor definition of terms (e.g. "system") > it seems surprising that a private definition of "unique" would guide > an objection to advancement of this draft. "Unique" is a word readily found in dictionaries; our definition is the standard one. Although there is a vague implication in the RFC that the uniqueness is intended to be only within the space of simultaneous negotiations, neither this nor any other restriction on the scope of uniqueness is actually stated. We do not feel it is unreasonable to interpret this as meaning that message IDs are supposed to be *unique*, in the strict dictionary sense of the word (within the obvious sanity constraint that different hosts cannot plausibly be prevented from choosing the same message ID). Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Jul 14 05:06:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA17600; Fri, 14 Jul 2000 05:06:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04078 Fri, 14 Jul 2000 06:41:19 -0400 (EDT) Message-Id: <200007141050.GAA08778@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-hybrid-auth-04.txt Date: Fri, 14 Jul 2000 06:50:23 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : A Hybrid Authentication Mode for IKE Author(s) : M. Litvin, R. Shamir, T. Zegman Filename : draft-ietf-ipsec-isakmp-hybrid-auth-04.txt Pages : 10 Date : 13-Jul-00 This document describes a set of new authentication methods to be used within Phase 1 of the Internet Key Exchange (IKE). The proposed methods assume an asymmetry between the authenticating entities. One entity, typically an Edge Device (e.g. firewall), authenticates using standard public key techniques (in signature mode), while the other entity, typically a remote User, authenticates using challenge response techniques. These authentication methods are used to establish, at the end of Phase 1, an IKE SA which is unidirectionally authenticated. To make this IKE bi-directionally authenticated, this Phase 1 is immediately followed by an X-Auth Exchange [XAUTH]. The X-Auth Exchange is used to authenticate the remote User. The use of these authentication methods is referred to as Hybrid Authentication mode. This proposal is designed to provide a solution for environments where a legacy authentication system exists, yet a full public key infrastructure is not deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-04.txt 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-isakmp-hybrid-auth-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000713145109.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-hybrid-auth-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713145109.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jul 14 05:06:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA17625; Fri, 14 Jul 2000 05:06:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04073 Fri, 14 Jul 2000 06:41:14 -0400 (EDT) Message-Id: <200007141050.GAA08803@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-monitor-mib-01.txt Date: Fri, 14 Jul 2000 06:50:28 -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 : IKE Monitoring MIB Author(s) : T. Jenkins, J. Shriver Filename : draft-ietf-ipsec-ike-monitor-mib-01.txt Pages : 73 Date : 13-Jul-00 This document defines monitoring and status MIBs for use when the (Internet Key Exchange) IKE protocol [IKE] is used to create IPsec security associations (SAs). As such, the MIBs provide the linkage between IKE (phase 1) SAs and the IPsec (phase 2) SAs created by those SAs. It does not define MIBs that may be used for configuring IPsec implementations or for providing low-level diagnostic or debugging information. It assumes no specific use of IPsec SAs, except that they were created using IKE. Further, it does not provide policy information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-monitor-mib-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ike-monitor-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-monitor-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000713145121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-monitor-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-monitor-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713145121.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jul 14 05:06:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA17601; Fri, 14 Jul 2000 05:06:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04084 Fri, 14 Jul 2000 06:41:23 -0400 (EDT) Message-Id: <200007141050.GAA08877@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-di-mon-mib-02.txt Date: Fri, 14 Jul 2000 06:50:38 -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 : ISAKMP DOI-Independent Monitoring MIB Author(s) : T. Jenkins, J. Shriver Filename : draft-ietf-ipsec-isakmp-di-mon-mib-02.txt Pages : 26 Date : 13-Jul-00 This document defines a DOI (domain of interpretation) independent monitoring MIB for ISAKMP. The purpose of this MIB is to be used as the basis for protocol specific MIBs that use ISAKMP as the basis for key exchanges or security association negotiation. As such, it has no DOI-dependent objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-di-mon-mib-02.txt 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-isakmp-di-mon-mib-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-isakmp-di-mon-mib-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: <20000713145145.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-di-mon-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-di-mon-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713145145.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jul 14 05:08:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA17731; Fri, 14 Jul 2000 05:08:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04077 Fri, 14 Jul 2000 06:41:16 -0400 (EDT) Message-Id: <200007141050.GAA08835@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-monitor-mib-03.txt Date: Fri, 14 Jul 2000 06:50: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 Monitoring MIB Author(s) : T. Jenkins, J. Shriver Filename : draft-ietf-ipsec-monitor-mib-03.txt Pages : 75 Date : 13-Jul-00 This document defines low level monitoring and status MIBs for IPsec security associations (SAs). It does not define MIBs that may be used for configuring IPsec implementations or for providing low-level diagnostic or debugging information. It assumes no specific use of IPsec. Further, it does not provide policy information. The purpose of the MIBs is to allow system administrators to determine operating conditions and perform system operational level monitoring of the IPsec portion of their network. Statistics are provided as well. Additionally, it may be used as the basis for application specific MIBs for specific uses of IPsec SAs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-monitor-mib-03.txt 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-monitor-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-monitor-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000713145133.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-monitor-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-monitor-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713145133.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jul 14 06:55:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA21042; Fri, 14 Jul 2000 06:55:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04601 Fri, 14 Jul 2000 08:49:32 -0400 (EDT) Message-Id: <200007140125.SAA26031@potassium.network-alchemy.com> To: Henry Spencer cc: "D. Hugh Redelmeier" , IPsec List , Hugh Daniel , John Gilmore Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] In-reply-to: Your message of "Thu, 13 Jul 2000 17:33:33 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26028.963537923.1@network-alchemy.com> Date: Thu, 13 Jul 2000 18:25:23 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We? Are you a doctor? You can infer any meaning you want and have it impact your implementation but then don't say that if I don't agree with your implementation that I am somehow non-compliant: On Wed, 12 Jul 2000 19:09:17 "D. Hugh Redelmeier" wrote: "We infer from some comments that some implementations do not enforce the requirement that Message IDs be unique. Although this isn't RFC compliant, the suggestion is that the RFCs be changed!" Your (plural) inference is correct but that does not mean that I'm not RFC compliant! What is the security hole? How can a replayed Quick Mode packet induce either party to accept forged packets? Dan. On Thu, 13 Jul 2000 17:33:33 EDT you wrote > On Wed, 12 Jul 2000, Dan Harkins wrote: > > For all the complaints about poor definition of terms (e.g. "system") > > it seems surprising that a private definition of "unique" would guide > > an objection to advancement of this draft. > > "Unique" is a word readily found in dictionaries; our definition is the > standard one. Although there is a vague implication in the RFC that the > uniqueness is intended to be only within the space of simultaneous > negotiations, neither this nor any other restriction on the scope of > uniqueness is actually stated. We do not feel it is unreasonable to > interpret this as meaning that message IDs are supposed to be *unique*, > in the strict dictionary sense of the word (within the obvious sanity > constraint that different hosts cannot plausibly be prevented from > choosing the same message ID). > > Henry Spencer > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Fri Jul 14 06:55:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA21059; Fri, 14 Jul 2000 06:55:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04563 Fri, 14 Jul 2000 08:48:34 -0400 (EDT) Message-Id: <200007140110.SAA25898@potassium.network-alchemy.com> To: "Mason, David" cc: IPsec List Subject: Re: Unique MIDs In-reply-to: Your message of "Thu, 13 Jul 2000 12:14:42 PDT." <447A3F40A07FD211BA2700A0C99D759B78910D@md-exchange1.nai.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25895.963537018.1@network-alchemy.com> Date: Thu, 13 Jul 2000 18:10:18 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 13 Jul 2000 12:14:42 PDT you wrote > > Replaying an old Initiator-to-Responder message (#1) back to the > > Responder will result in the Responder sending an unexpected message #2 > > back to the Initiator which will fail the hash check > > If the responder allows the initiator to use non-unique message IDs then > this opens up a DoS avenue especially if PFS was used. So then don't generate the KEYMAT until you receive message #3. Where is this security hole? Dan. From owner-ipsec@lists.tislabs.com Fri Jul 14 06:57:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA21244; Fri, 14 Jul 2000 06:57:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04562 Fri, 14 Jul 2000 08:48:33 -0400 (EDT) Message-Id: <200007140104.SAA25773@potassium.network-alchemy.com> To: hugh@mimosa.com cc: Tim Jenkins , IPsec List , Hugh Daniel , John Gilmore , Henry Spencer Subject: Re: problems with draft-jenkins-ipsec-rekeying-06.txt In-reply-to: Your message of "Thu, 13 Jul 2000 12:38:56 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25770.963536669.1@network-alchemy.com> Date: Thu, 13 Jul 2000 18:04:29 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 13 Jul 2000 12:38:56 EDT you wrote > > But another part, 5.7 "ISAKMP Informational Exchanges" says: > > As noted the message ID in the ISAKMP header-- and used in the prf > computation-- is unique to this exchange and MUST NOT be the same as > the message ID of another phase 2 exchange which generated this > informational exchange. > > This does not qualify "unique" in any way. It does clearly use the > admonition "MUST NOT". It also says "...which generated this informational exchange" which is really poor wording. 1000 pardons. But the message ID of the phase 2 exchange is not the same as the message ID of the Informational Exchange. You MUST NOT use a message ID of a currently active phase 2 exchange (e.g. Quick Mode) and send an Informational Exchange on it. But it doesn't say you have to keep track of every single message ID used by a single IKE SA. Dan. From owner-ipsec@lists.tislabs.com Fri Jul 14 07:03:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21406; Fri, 14 Jul 2000 07:03:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04611 Fri, 14 Jul 2000 08:50:33 -0400 (EDT) Message-Id: <200007140600.XAA26578@potassium.network-alchemy.com> To: "'IPsec List'" Subject: Re: problems with draft-jenkins-ipsec-rekeying-06.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26575.963554441.1@network-alchemy.com> Date: Thu, 13 Jul 2000 23:00:41 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I do not believe that a "Responder Pre-Set-up Security Hole" exists in IKE as is defined in RFC2409 and suggest that the text referring to such be deleted from rekeying draft prior to advancement to Informational RFC status. The draft says: "2.2.1.4 Responder Pre-Set-up Security Hole In the failed negotiation case, the need to delete the invalid inbound SA raises the issue of a temporary hole, in that the responder allows inbound packets while waiting for the third quick mode message. However, if the inbound SA is not set up ahead of time, initiators that immediately transmit on the new outbound SA will cause packets to be dropped. It also illustrates why the proposal above made the usage of the outbound SA by the initiator wait until there is an indication of the use of the SA by the responder. Note that this security hole is exactly what would result from an attacker replaying the first quick mode message of an exchange." There would be no security hole from an attacker replaying a Quick Mode message because upon receipt of this replayed packet the Responder would choose a random nonce and, if it chose to "pre set up" its SAs, derive keying material for the IPSec SAs which are based, in part, on that nonce. In addition the SPI the Responder would choose is part of his responce which, again, the attacker would be unable to read and therefore would not know which SPI upon which to send his packets! Basically, even if the attacker could guess which random SPI the Responder chose as a result of this replayed packet he would still not be able to construct a packet which the Responder would verify and decrypt. Only the authenticated peer has the SKEYID state necessary to construct the right KEYMAT. The only issue is that there is a possible attack if this replayed packet contained PFS (which the attacker would not know) because the Responder is doing "pre-set-up" and would most likely finish exponentiation. But this seems to be a manufactured problem. Don't do "pre-set-up"! Use the commit bit if you don't want to receive IPSec packets from the Initiator prior to receipt of the message #3. Dan. From owner-ipsec@lists.tislabs.com Fri Jul 14 12:03:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08350; Fri, 14 Jul 2000 12:03:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05867 Fri, 14 Jul 2000 13:28:35 -0400 (EDT) Message-Id: <200007141734.KAA28035@potassium.network-alchemy.com> To: Tim Jenkins cc: "'IPsec List'" Subject: Re: Responder Pre-set-up hole (was RE: problems with draft-jenkins-ip sec-rekeying-06.txt) In-reply-to: Your message of "Fri, 14 Jul 2000 12:48:19 EDT." <310508EDF557D31188FA0050DA0A3752658724@CAT01S2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28032.963596046.1@network-alchemy.com> Date: Fri, 14 Jul 2000 10:34:07 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tim, But that SA will not and cannot be used in the case of a replay attack. I'm not sure about whether you're being over-cautious or not but saying that there is a Security Hole seems being not only over critical but wrong. If the issue is a DoS attack in which the Responder can be induced into doing exponentiations as a result of replayed packets then that should be explicitly stated. I received 2 private emails over the last couple of days saying that the Security Hole was that the Responder would accept traffic (also replayed) on that SA. Statistics 101 tells me that there are probably even more people who received that impression by reading the draft. Dan. On Fri, 14 Jul 2000 12:48:19 EDT you wrote > Dan, > > The hole I was referring to was the existence for a brief period of time an > inbound SA that was created with less randomness then the one set up with by > the original quick mode exchange since it would use the same value for Ni_b > and protocol in the KEYMAT generation. > > I was not willing to state that this was as secure and was not somehow > exploitable, so I took the cautious route and decided that it was not > acceptable to do this. > > Is this being over-cautious? > > Tim > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@cips.nokia.com] > > Sent: Friday, July 14, 2000 2:01 AM > > To: 'IPsec List' > > Subject: Re: problems with draft-jenkins-ipsec-rekeying-06.txt > > > > > > I do not believe that a "Responder Pre-Set-up Security Hole" > > exists in IKE as is defined in RFC2409 and suggest that the > > text referring to such be deleted from rekeying draft prior > > to advancement to Informational RFC status. > > > > The draft says: > > > > "2.2.1.4 Responder Pre-Set-up Security Hole > > > > In the failed negotiation case, the need to delete the invalid > > inbound SA raises the issue of a temporary hole, in that the > > responder allows inbound packets while waiting for the third quick > > mode message. However, if the inbound SA is not set up ahead of > > time, initiators that immediately transmit on the new outbound SA > > will cause packets to be dropped. > > > > It also illustrates why the proposal above made the usage of the > > outbound SA by the initiator wait until there is an indication of > > the use of the SA by the responder. > > > > Note that this security hole is exactly what would result from an > > attacker replaying the first quick mode message of an exchange." > > > > There would be no security hole from an attacker replaying a Quick > > Mode message because upon receipt of this replayed packet the > > Responder would choose a random nonce and, if it chose to "pre set > > up" its SAs, derive keying material for the IPSec SAs which are > > based, in part, on that nonce. In addition the SPI the Responder > > would choose is part of his responce which, again, the attacker > > would be unable to read and therefore would not know which SPI > > upon which to send his packets! > > > > Basically, even if the attacker could guess which random SPI > > the Responder chose as a result of this replayed packet he would > > still not be able to construct a packet which the Responder would > > verify and decrypt. Only the authenticated peer has the SKEYID > > state necessary to construct the right KEYMAT. > > > > The only issue is that there is a possible attack if this > > replayed packet contained PFS (which the attacker would not know) > > because the Responder is doing "pre-set-up" and would most likely > > finish exponentiation. But this seems to be a manufactured > > problem. Don't do "pre-set-up"! Use the commit bit if you don't > > want to receive IPSec packets from the Initiator prior to > > receipt of the message #3. > > > > Dan. > > From owner-ipsec@lists.tislabs.com Fri Jul 14 12:03:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08371; Fri, 14 Jul 2000 12:03:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05905 Fri, 14 Jul 2000 13:45:55 -0400 (EDT) Message-Id: <200007141751.KAA28090@potassium.network-alchemy.com> To: Tim Jenkins cc: "'IPsec List'" Subject: Re: Responder Pre-set-up hole (was RE: problems with draft-jenkin s-ip sec-rekeying-06.txt) In-reply-to: Your message of "Fri, 14 Jul 2000 13:42:53 EDT." <310508EDF557D31188FA0050DA0A3752658725@CAT01S2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28087.963597087.1@network-alchemy.com> Date: Fri, 14 Jul 2000 10:51:27 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk But what's the point if that SA can not be used? If there is some issue aside from the potential for a DoS attack then what is it? If it's just a potential DoS attack then just say so. If it's just a DoS attack it seems appropriate to mention that the attack is bounded by the number of Quick Modes already performed on each active SA. Replaying old Quick Modes for SAs which have expired will do nothing. "Unsafe at any speed" killed a very fine, and quite safe, car; "Security Hole" seems hyperbolic. Dan. On Fri, 14 Jul 2000 13:42:53 EDT you wrote > Okay, I'll be more explicit. You alluded to it already, but it seems to me > that this new SA has less entropy in the key material generation, and > therefore might have some greater susceptibility in being cracked. > > If I explicitly state that the new SA in this particular case has less > entropy because it re-uses the initiator nonce from the original quick mode > message one that is replayed, and therefore might possibly be weakened, > would that satisfy you rather than having the statement removed? > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@cips.nokia.com] > > Sent: Friday, July 14, 2000 1:34 PM > > To: Tim Jenkins > > Cc: 'IPsec List' > > Subject: Re: Responder Pre-set-up hole (was RE: problems with > > draft-jenkins-ip sec-rekeying-06.txt) > > > > > > Tim, > > > > But that SA will not and cannot be used in the case of a > > replay attack. > > > > I'm not sure about whether you're being over-cautious or > > not but saying > > that there is a Security Hole seems being not only over > > critical but wrong. > > If the issue is a DoS attack in which the Responder can be > > induced into > > doing exponentiations as a result of replayed packets then > > that should be > > explicitly stated. > > > > I received 2 private emails over the last couple of days > > saying that the > > Security Hole was that the Responder would accept traffic > > (also replayed) > > on that SA. Statistics 101 tells me that there are probably even more > > people who received that impression by reading the draft. > > > > Dan. > > > > On Fri, 14 Jul 2000 12:48:19 EDT you wrote > > > Dan, > > > > > > The hole I was referring to was the existence for a brief > > period of time an > > > inbound SA that was created with less randomness then the > > one set up with by > > > the original quick mode exchange since it would use the > > same value for Ni_b > > > and protocol in the KEYMAT generation. > > > > > > I was not willing to state that this was as secure and was > > not somehow > > > exploitable, so I took the cautious route and decided that > > it was not > > > acceptable to do this. > > > > > > Is this being over-cautious? > > > > > > Tim > > > > > > > -----Original Message----- > > > > From: Dan Harkins [mailto:dharkins@cips.nokia.com] > > > > Sent: Friday, July 14, 2000 2:01 AM > > > > To: 'IPsec List' > > > > Subject: Re: problems with draft-jenkins-ipsec-rekeying-06.txt > > > > > > > > > > > > I do not believe that a "Responder Pre-Set-up Security Hole" > > > > exists in IKE as is defined in RFC2409 and suggest that the > > > > text referring to such be deleted from rekeying draft prior > > > > to advancement to Informational RFC status. > > > > > > > > The draft says: > > > > > > > > "2.2.1.4 Responder Pre-Set-up Security Hole > > > > > > > > In the failed negotiation case, the need to delete the invalid > > > > inbound SA raises the issue of a temporary hole, in that the > > > > responder allows inbound packets while waiting for the > > third quick > > > > mode message. However, if the inbound SA is not set up ahead of > > > > time, initiators that immediately transmit on the new > > outbound SA > > > > will cause packets to be dropped. > > > > > > > > It also illustrates why the proposal above made the > > usage of the > > > > outbound SA by the initiator wait until there is an > > indication of > > > > the use of the SA by the responder. > > > > > > > > Note that this security hole is exactly what would > > result from an > > > > attacker replaying the first quick mode message of an > > exchange." > > > > > > > > There would be no security hole from an attacker replaying a Quick > > > > Mode message because upon receipt of this replayed packet the > > > > Responder would choose a random nonce and, if it chose to "pre set > > > > up" its SAs, derive keying material for the IPSec SAs which are > > > > based, in part, on that nonce. In addition the SPI the Responder > > > > would choose is part of his responce which, again, the attacker > > > > would be unable to read and therefore would not know which SPI > > > > upon which to send his packets! > > > > > > > > Basically, even if the attacker could guess which random SPI > > > > the Responder chose as a result of this replayed packet he would > > > > still not be able to construct a packet which the Responder would > > > > verify and decrypt. Only the authenticated peer has the SKEYID > > > > state necessary to construct the right KEYMAT. > > > > > > > > The only issue is that there is a possible attack if this > > > > replayed packet contained PFS (which the attacker would not know) > > > > because the Responder is doing "pre-set-up" and would most likely > > > > finish exponentiation. But this seems to be a manufactured > > > > problem. Don't do "pre-set-up"! Use the commit bit if you don't > > > > want to receive IPSec packets from the Initiator prior to > > > > receipt of the message #3. > > > > > > > > Dan. > > > > > > From owner-ipsec@lists.tislabs.com Fri Jul 14 13:10:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12452; Fri, 14 Jul 2000 13:10:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06066 Fri, 14 Jul 2000 14:54:41 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B789111@md-exchange1.nai.com> From: "Mason, David" To: "'Dan Harkins'" , "Mason, David" Cc: IPsec List Subject: RE: Unique MIDs Date: Fri, 14 Jul 2000 06:41:41 -0700 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 Yes you should delay generating g^xy until it is actually needed but as a responder you need to generate g^xr for QM2. This involves big number exponentiation and modulo arithemetic which definitely isn't cheap. There is also the overhead of decrypting QM1 and encrypting QM2 and retransmitting QM2 until the retry counter expires but these operations are probably not all that significant. As I stated in a subsequent mailing, memory constrained systems may feel that the cost of this operation is cheaper than consuming memory to store MIDs to avoid this operation. -dave -----Original Message----- From: Dan Harkins [mailto:dharkins@cips.nokia.com] Sent: Thursday, July 13, 2000 9:10 PM To: Mason, David Cc: IPsec List Subject: Re: Unique MIDs On Thu, 13 Jul 2000 12:14:42 PDT you wrote > > Replaying an old Initiator-to-Responder message (#1) back to the > > Responder will result in the Responder sending an unexpected message #2 > > back to the Initiator which will fail the hash check > > If the responder allows the initiator to use non-unique message IDs then > this opens up a DoS avenue especially if PFS was used. So then don't generate the KEYMAT until you receive message #3. Where is this security hole? Dan. From owner-ipsec@lists.tislabs.com Fri Jul 14 14:33:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16211; Fri, 14 Jul 2000 14:33:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06389 Fri, 14 Jul 2000 16:14:35 -0400 (EDT) Message-Id: <200007142020.NAA07571@potassium.network-alchemy.com> To: Tim Jenkins cc: "'IPsec List'" Subject: Re: Responder Pre-set-up hole (was RE: problems with draft-jenkin s-ip sec-rekeying-06.txt) In-reply-to: Your message of "Fri, 14 Jul 2000 15:47:16 EDT." <310508EDF557D31188FA0050DA0A3752658726@CAT01S2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7568.963606008.1@network-alchemy.com> Date: Fri, 14 Jul 2000 13:20:08 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are no guarantees in anything but I would say that it is statistically impossible. What sort of analysis of a previous SA can be done resulting in what sort of attack? And on what SPI would the attacker send packets if he was able to somehow divine the key? The SA will, presumably, die a quick death due to the fact that the true Initiator did not send the original message prompting the creation of this SA. If the Initiator sent anything back to the Responder upon receipt of this response to the attack it would probably be an Informational saying that the message was garbled (he'd think it was message #1 and be unable to authenticated it). If he sent nothing the Responder would retransmit a few times and delete the SA. The only harm is the exponentiation which should be noted. And, this whole thing is an issue only because of the proposal to actually create a usable SA upon receipt of a single message in the first place! Don't do "responder pre-set up". If a Responder is sensitive about receiving a few IPSec packets prior to creation of a valid, usable SA then it should use the commit bit. That's what it's there for. Even so, if the Responder did "pre set-up" it still isn't any sort of Security Hole. Dan. On Fri, 14 Jul 2000 15:47:16 EDT you wrote > Dan, > > I assume you mean "... if it that SA not be used" by the attacker. > > Are you going to guarantee that the SA cannot be used given that it has less > entropy in its keying material? Is there no attack that can be launched > based on analysis of the previous SA and knowing that some of the keying > material input is the same? > > As I said before, I won't guarantee that. > > I won't call it a security hole. I would categorize it as a potential risk. > How about I change the section name to "2.2.1.4 Responder Pre-Set-up Issues" > and I'll add your comments about DoS? > > Would that make you happy? > > Tim > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@cips.nokia.com] > > Sent: Friday, July 14, 2000 1:51 PM > > To: Tim Jenkins > > Cc: 'IPsec List' > > Subject: Re: Responder Pre-set-up hole (was RE: problems with > > draft-jenkin s-ip sec-rekeying-06.txt) > > > > > > But what's the point if that SA can not be used? If there is some > > issue aside from the potential for a DoS attack then what is it? If > > it's just a potential DoS attack then just say so. If it's just a DoS > > attack it seems appropriate to mention that the attack is bounded by > > the number of Quick Modes already performed on each active > > SA. Replaying > > old Quick Modes for SAs which have expired will do nothing. > > > > "Unsafe at any speed" killed a very fine, and quite safe, > > car; "Security > > Hole" seems hyperbolic. > > > > Dan. > > > > On Fri, 14 Jul 2000 13:42:53 EDT you wrote > > > Okay, I'll be more explicit. You alluded to it already, but > > it seems to me > > > that this new SA has less entropy in the key material > > generation, and > > > therefore might have some greater susceptibility in being cracked. > > > > > > If I explicitly state that the new SA in this particular > > case has less > > > entropy because it re-uses the initiator nonce from the > > original quick mode > > > message one that is replayed, and therefore might possibly > > be weakened, > > > would that satisfy you rather than having the statement removed? > > > > > > > -----Original Message----- > > > > From: Dan Harkins [mailto:dharkins@cips.nokia.com] > > > > Sent: Friday, July 14, 2000 1:34 PM > > > > To: Tim Jenkins > > > > Cc: 'IPsec List' > > > > Subject: Re: Responder Pre-set-up hole (was RE: problems with > > > > draft-jenkins-ip sec-rekeying-06.txt) > > > > > > > > > > > > Tim, > > > > > > > > But that SA will not and cannot be used in the case of a > > > > replay attack. > > > > > > > > I'm not sure about whether you're being over-cautious or > > > > not but saying > > > > that there is a Security Hole seems being not only over > > > > critical but wrong. > > > > If the issue is a DoS attack in which the Responder can be > > > > induced into > > > > doing exponentiations as a result of replayed packets then > > > > that should be > > > > explicitly stated. > > > > > > > > I received 2 private emails over the last couple of days > > > > saying that the > > > > Security Hole was that the Responder would accept traffic > > > > (also replayed) > > > > on that SA. Statistics 101 tells me that there are > > probably even more > > > > people who received that impression by reading the draft. > > > > > > > > Dan. > > > > > > > > On Fri, 14 Jul 2000 12:48:19 EDT you wrote > > > > > Dan, > > > > > > > > > > The hole I was referring to was the existence for a brief > > > > period of time an > > > > > inbound SA that was created with less randomness then the > > > > one set up with by > > > > > the original quick mode exchange since it would use the > > > > same value for Ni_b > > > > > and protocol in the KEYMAT generation. > > > > > > > > > > I was not willing to state that this was as secure and was > > > > not somehow > > > > > exploitable, so I took the cautious route and decided that > > > > it was not > > > > > acceptable to do this. > > > > > > > > > > Is this being over-cautious? > > > > > > > > > > Tim > > > > > > > > > > > -----Original Message----- > > > > > > From: Dan Harkins [mailto:dharkins@cips.nokia.com] > > > > > > Sent: Friday, July 14, 2000 2:01 AM > > > > > > To: 'IPsec List' > > > > > > Subject: Re: problems with > > draft-jenkins-ipsec-rekeying-06.txt > > > > > > > > > > > > > > > > > > I do not believe that a "Responder Pre-Set-up Security Hole" > > > > > > exists in IKE as is defined in RFC2409 and suggest that the > > > > > > text referring to such be deleted from rekeying draft prior > > > > > > to advancement to Informational RFC status. > > > > > > > > > > > > The draft says: > > > > > > > > > > > > "2.2.1.4 Responder Pre-Set-up Security Hole > > > > > > > > > > > > In the failed negotiation case, the need to delete > > the invalid > > > > > > inbound SA raises the issue of a temporary hole, > > in that the > > > > > > responder allows inbound packets while waiting for the > > > > third quick > > > > > > mode message. However, if the inbound SA is not > > set up ahead of > > > > > > time, initiators that immediately transmit on the new > > > > outbound SA > > > > > > will cause packets to be dropped. > > > > > > > > > > > > It also illustrates why the proposal above made the > > > > usage of the > > > > > > outbound SA by the initiator wait until there is an > > > > indication of > > > > > > the use of the SA by the responder. > > > > > > > > > > > > Note that this security hole is exactly what would > > > > result from an > > > > > > attacker replaying the first quick mode message of an > > > > exchange." > > > > > > > > > > > > There would be no security hole from an attacker > > replaying a Quick > > > > > > Mode message because upon receipt of this replayed packet the > > > > > > Responder would choose a random nonce and, if it > > chose to "pre set > > > > > > up" its SAs, derive keying material for the IPSec SAs > > which are > > > > > > based, in part, on that nonce. In addition the SPI > > the Responder > > > > > > would choose is part of his responce which, again, > > the attacker > > > > > > would be unable to read and therefore would not know which SPI > > > > > > upon which to send his packets! > > > > > > > > > > > > Basically, even if the attacker could guess which random SPI > > > > > > the Responder chose as a result of this replayed > > packet he would > > > > > > still not be able to construct a packet which the > > Responder would > > > > > > verify and decrypt. Only the authenticated peer has the SKEYID > > > > > > state necessary to construct the right KEYMAT. > > > > > > > > > > > > The only issue is that there is a possible attack if this > > > > > > replayed packet contained PFS (which the attacker > > would not know) > > > > > > because the Responder is doing "pre-set-up" and would > > most likely > > > > > > finish exponentiation. But this seems to be a manufactured > > > > > > problem. Don't do "pre-set-up"! Use the commit bit if > > you don't > > > > > > want to receive IPSec packets from the Initiator prior to > > > > > > receipt of the message #3. > > > > > > > > > > > > Dan. > > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Fri Jul 14 14:57:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17687; Fri, 14 Jul 2000 14:57:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06472 Fri, 14 Jul 2000 16:46:49 -0400 (EDT) Message-ID: <003001bfedd5$f6e03910$cbd62ca1@cisco.com> From: "Stephane Beaulieu" To: "ipsec-list" Subject: Generating 3DES keys from SKEYID_e Date: Fri, 14 Jul 2000 16:56:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, In RFC 2409, Appendix B, there's some text on how to generate keying material for a cipher that requires a key larger than SKEYID_e. Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long enough to supply all the necessary keying material an algorithm requires, the key is derived from feeding the results of a pseudo- random function into itself, concatenating the results, and taking the highest necessary bits. For example, if (fictitious) algorithm AKULA requires 320-bits of key (and has no weak key check) and the prf used to generate SKEYID_e only generates 120 bits of material, the key for AKULA, would be the first 320-bits of Ka, where: Ka = K1 | K2 | K3 and K1 = prf(SKEYID_e, 0) K2 = prf(SKEYID_e, K1) K3 = prf(SKEYID_e, K2) where prf is the negotiated prf or the HMAC version of the negotiated hash function (if no prf was negotiated) and 0 is represented by a single octet. Each result of the prf provides 120 bits of material for a total of 360 bits. AKULA would use the first 320 bits of that 360 bit string. This probably comes from the same idea presented in RFC 2412, section 2.6, which uses similar formulas: Don't these methods limit the effective keyspace for 3DES? Someone wanting to guess the 3DES key, could start by simply guessing SKEYID_e. SKEYID_e is only 128 bits long (assuming md5 is used for the hmac). The attacker then runs every one of those 2^128 SKEYID_e through the algorithm above (requiring 3*2^128 md5 computations), and ends up with 2^128 possible 3des keys. So, effectively, the strength of the cipher could only ever be as strong as the size of the output of the hash algorithm. Is this correct? If this is correct, then it could be fixed by including g^xy in K1, K2 and K3 K1 = prf(SKEYID_e, g^xy, 0) K2 = prf(SKEYID_e, g^xy, K1) K3 = prf(SKEYID_e, g^xy, K2) I searched through the archives, and haven't seen this discussed. Stephane. ------ Stephane Beaulieu S/W Engineer VSEC Business Unit, Enterprise Line of Business Cisco Systems. email: stephane@cisco.com phone: (613) 271-3678 From owner-ipsec@lists.tislabs.com Fri Jul 14 15:08:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA18312; Fri, 14 Jul 2000 15:08:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06535 Fri, 14 Jul 2000 17:05:01 -0400 (EDT) Message-ID: From: "Glawitsch, Gregor" To: "'Stephane Beaulieu'" , ipsec-list Subject: RE: Generating 3DES keys from SKEYID_e Date: Fri, 14 Jul 2000 14:11:34 -0700 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 Stephane, do you realize how large 2^128 is? Greg Glawitsch Network Associate, Inc. -----Original Message----- From: Stephane Beaulieu [mailto:stephane@cisco.com] Sent: Friday, July 14, 2000 1:56 PM To: ipsec-list Subject: Generating 3DES keys from SKEYID_e Hi All, In RFC 2409, Appendix B, there's some text on how to generate keying material for a cipher that requires a key larger than SKEYID_e. Encryption keys used to protect the ISAKMP SA are derived from SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long enough to supply all the necessary keying material an algorithm requires, the key is derived from feeding the results of a pseudo- random function into itself, concatenating the results, and taking the highest necessary bits. For example, if (fictitious) algorithm AKULA requires 320-bits of key (and has no weak key check) and the prf used to generate SKEYID_e only generates 120 bits of material, the key for AKULA, would be the first 320-bits of Ka, where: Ka = K1 | K2 | K3 and K1 = prf(SKEYID_e, 0) K2 = prf(SKEYID_e, K1) K3 = prf(SKEYID_e, K2) where prf is the negotiated prf or the HMAC version of the negotiated hash function (if no prf was negotiated) and 0 is represented by a single octet. Each result of the prf provides 120 bits of material for a total of 360 bits. AKULA would use the first 320 bits of that 360 bit string. This probably comes from the same idea presented in RFC 2412, section 2.6, which uses similar formulas: Don't these methods limit the effective keyspace for 3DES? Someone wanting to guess the 3DES key, could start by simply guessing SKEYID_e. SKEYID_e is only 128 bits long (assuming md5 is used for the hmac). The attacker then runs every one of those 2^128 SKEYID_e through the algorithm above (requiring 3*2^128 md5 computations), and ends up with 2^128 possible 3des keys. So, effectively, the strength of the cipher could only ever be as strong as the size of the output of the hash algorithm. Is this correct? If this is correct, then it could be fixed by including g^xy in K1, K2 and K3 K1 = prf(SKEYID_e, g^xy, 0) K2 = prf(SKEYID_e, g^xy, K1) K3 = prf(SKEYID_e, g^xy, K2) I searched through the archives, and haven't seen this discussed. Stephane. ------ Stephane Beaulieu S/W Engineer VSEC Business Unit, Enterprise Line of Business Cisco Systems. email: stephane@cisco.com phone: (613) 271-3678 From owner-ipsec@lists.tislabs.com Fri Jul 14 16:30:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA21369; Fri, 14 Jul 2000 16:30:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06650 Fri, 14 Jul 2000 18:00:00 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14703.36745.942949.456705@xedia.com> Date: Fri, 14 Jul 2000 18:09:13 -0400 (EDT) To: Gregor_Glawitsch@nai.com Cc: stephane@cisco.com, ipsec@lists.tislabs.com Subject: RE: Generating 3DES keys from SKEYID_e References: X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Glawitsch," == Glawitsch, Gregor writes: Glawitsch,> Stephane, do you realize how large 2^128 is? While it doesn't matter for 3DES (since the effective key strength is less than 2^128) this issue will matter for AES. Yes, 2^128 is a big number. But if you want to claim support for ciphers with long keys, by his argument you need a PRF of corresponding size. There's something to be said for that. The alternative, of course, is not to support keys larger than 128 bits. That's in practice not a bad idea. paul From owner-ipsec@lists.tislabs.com Fri Jul 14 18:13:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA04759; Fri, 14 Jul 2000 18:13:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06858 Fri, 14 Jul 2000 19:53:14 -0400 (EDT) Message-ID: <001c01bfedf0$01c89600$d2d02ca1@cisco.com> From: "Stephane Beaulieu" To: "Glawitsch, Gregor" , "ipsec-list" References: Subject: Re: Generating 3DES keys from SKEYID_e Date: Fri, 14 Jul 2000 20:02:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's higher than I can count, I know that. :) ----- Original Message ----- From: "Glawitsch, Gregor" To: "'Stephane Beaulieu'" ; "ipsec-list" Sent: Friday, July 14, 2000 5:11 PM Subject: RE: Generating 3DES keys from SKEYID_e > Stephane, > > do you realize how large 2^128 is? > > Greg Glawitsch > Network Associate, Inc. > > -----Original Message----- > From: Stephane Beaulieu [mailto:stephane@cisco.com] > Sent: Friday, July 14, 2000 1:56 PM > To: ipsec-list > Subject: Generating 3DES keys from SKEYID_e > > > Hi All, > > In RFC 2409, Appendix B, there's some text on how to generate keying > material for a cipher that requires a key larger than SKEYID_e. > > > Encryption keys used to protect the ISAKMP SA are derived from > SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long > enough to supply all the necessary keying material an algorithm > requires, the key is derived from feeding the results of a pseudo- > random function into itself, concatenating the results, and taking > the highest necessary bits. > > For example, if (fictitious) algorithm AKULA requires 320-bits of key > (and has no weak key check) and the prf used to generate SKEYID_e > only generates 120 bits of material, the key for AKULA, would be the > first 320-bits of Ka, where: > > Ka = K1 | K2 | K3 > and > K1 = prf(SKEYID_e, 0) > K2 = prf(SKEYID_e, K1) > K3 = prf(SKEYID_e, K2) > > where prf is the negotiated prf or the HMAC version of the negotiated > hash function (if no prf was negotiated) and 0 is represented by a > single octet. Each result of the prf provides 120 bits of material > for a total of 360 bits. AKULA would use the first 320 bits of that > 360 bit string. > > > This probably comes from the same idea presented in RFC 2412, section 2.6, > which uses similar formulas: > > Don't these methods limit the effective keyspace for 3DES? > > Someone wanting to guess the 3DES key, could start by simply guessing > SKEYID_e. SKEYID_e is only 128 bits long (assuming md5 is used for the > hmac). > > The attacker then runs every one of those 2^128 SKEYID_e through the > algorithm above (requiring 3*2^128 md5 computations), and ends up with 2^128 > possible 3des keys. > > So, effectively, the strength of the cipher could only ever be as strong as > the size of the output of the hash algorithm. Is this correct? > > If this is correct, then it could be fixed by including g^xy in K1, K2 and > K3 > > K1 = prf(SKEYID_e, g^xy, 0) > K2 = prf(SKEYID_e, g^xy, K1) > K3 = prf(SKEYID_e, g^xy, K2) > > > I searched through the archives, and haven't seen this discussed. > > Stephane. > > ------ > Stephane Beaulieu > S/W Engineer > VSEC Business Unit, Enterprise Line of Business > Cisco Systems. > email: stephane@cisco.com > phone: (613) 271-3678 > > > > From owner-ipsec@lists.tislabs.com Fri Jul 14 18:43:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA09078; Fri, 14 Jul 2000 18:43:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07038 Fri, 14 Jul 2000 20:38:05 -0400 (EDT) Message-ID: From: "Glawitsch, Gregor" To: ipsec-list Subject: RE: Generating 3DES keys from SKEYID_e Date: Fri, 14 Jul 2000 17:44:37 -0700 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 >>> The attacker then runs every one of those 2^128 SKEYID_e through the >>> algorithm above (requiring 3*2^128 md5 computations), and ends up with >>> 2^128 possible 3des keys. >> Stephane, >> >> do you realize how large 2^128 is? >It's higher than I can count, I know that. :) 2^128 = 2^32 * 2^32 * 2^32 * 2^32 where 2^32 = (roughly) 4 billion Assume an ASIC implements twelve MD5 circuits, and each of these circuits runs at 1 GHz in pipelined mode and completes one MD5 result per nanosecond, it just takes a second to run through 2^32 combinations. 2^96 to go. Assume you run this computation for 136 years, this takes care of another 2^32. 2^64 to go. Assume you distribute one of these ASICs to every man, woman and child (let's exclude toddlers) on this planet, this takes care of another 2^32. 2^32 to go. Assume our galaxy has 2^32 planets that have intelligent life on them, and assume each of these planets has a few billion intelligent beings on it on the average, then, yes, an entire galaxy working together can conduct an exhaustive search in 136 earth years. Greg Glawitsch Network Associates, Inc. From owner-ipsec@lists.tislabs.com Fri Jul 14 20:08:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA17186; Fri, 14 Jul 2000 20:08:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07118 Fri, 14 Jul 2000 21:53:54 -0400 (EDT) Message-ID: <396FC665.6890C2C2@storm.ca> Date: Fri, 14 Jul 2000 22:03:17 -0400 From: Sandy Harris Organization: Global Village Idiots X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Generating 3DES keys from SKEYID_e References: <14703.36745.942949.456705@xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: > > >>>>> "Glawitsch," == Glawitsch, Gregor writes: > > Glawitsch,> Stephane, do you realize how large 2^128 is? > > While it doesn't matter for 3DES (since the effective key strength is > less than 2^128) this issue will matter for AES. > > Yes, 2^128 is a big number. But if you want to claim support for > ciphers with long keys, by his argument you need a PRF of > corresponding size. There's something to be said for that. > > The alternative, of course, is not to support keys larger than 128 > bits. That's in practice not a bad idea. > > paul Another alternative would be to use Tiger as the hash. That is a SHOULD in RFC 2409 and gives a 192-bit hash. http://www.cs.technion.ac.il/~biham/Reports/Tiger/ From owner-ipsec@lists.tislabs.com Sat Jul 15 12:19:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02545; Sat, 15 Jul 2000 12:19:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09177 Sat, 15 Jul 2000 13:43:41 -0400 (EDT) Message-ID: <002701bfee85$9fe99650$d9d02ca1@cisco.com> From: "Stephane Beaulieu" To: "Sandy Harris" , References: <14703.36745.942949.456705@xedia.com> <396FC665.6890C2C2@storm.ca> Subject: Re: Generating 3DES keys from SKEYID_e Date: Sat, 15 Jul 2000 13:53:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Another alternative would be to use Tiger as the hash. That is a > SHOULD in RFC 2409 and gives a 192-bit hash. > http://www.cs.technion.ac.il/~biham/Reports/Tiger/ > > That's a good work-around solution for the short term, and requires no modifications to IKE. If IKE ever gets rev'ed however, I'd like to see g^xy (or some other large secret value) be included in the prf feedback mechanism used to expand SKEYID_e. Stephane. From owner-ipsec@lists.tislabs.com Sun Jul 16 06:18:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06635; Sun, 16 Jul 2000 06:18:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA10909 Sun, 16 Jul 2000 06:56:18 -0400 (EDT) Date: Sun, 16 Jul 2000 14:04:10 +0300 (IDT) From: Hugo Krawczyk To: Stephane Beaulieu cc: ipsec-list Subject: Re: Generating 3DES keys from SKEYID_e In-Reply-To: <003001bfedd5$f6e03910$cbd62ca1@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This form of derivation of long keys is a conscious design decision in IKE. Nothing in IKE is stronger than the strength of the prf as this prf is used to derive the basic SKEYID and authenticate the exchanges. If you want a stronger prf than, say, HMAC-SHA1 just use it. This is why prf needs to be a negotiable parameter and not a fixed one. Note that you can use any block cipher (including 3DES and AES) as your negotiated prf. Besides, 128 bits of security is more than necessary. If I had an algorithm with *PROVEN* 90 bits of security I would prefer it to 3DES or the best of AES candidates. The reason we go for longer keys is because we need SAFETY MARGINS due to our very limited undersanding of cryptanalysis. The best I can wish any IKE implementation is to have a 128-bit secure prf as its weakest link... Hugo On Fri, 14 Jul 2000, Stephane Beaulieu wrote: > Hi All, > > In RFC 2409, Appendix B, there's some text on how to generate keying > material for a cipher that requires a key larger than SKEYID_e. > > > Encryption keys used to protect the ISAKMP SA are derived from > SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long > enough to supply all the necessary keying material an algorithm > requires, the key is derived from feeding the results of a pseudo- > random function into itself, concatenating the results, and taking > the highest necessary bits. > > For example, if (fictitious) algorithm AKULA requires 320-bits of key > (and has no weak key check) and the prf used to generate SKEYID_e > only generates 120 bits of material, the key for AKULA, would be the > first 320-bits of Ka, where: > > Ka = K1 | K2 | K3 > and > K1 = prf(SKEYID_e, 0) > K2 = prf(SKEYID_e, K1) > K3 = prf(SKEYID_e, K2) > > where prf is the negotiated prf or the HMAC version of the negotiated > hash function (if no prf was negotiated) and 0 is represented by a > single octet. Each result of the prf provides 120 bits of material > for a total of 360 bits. AKULA would use the first 320 bits of that > 360 bit string. > > > This probably comes from the same idea presented in RFC 2412, section 2.6, > which uses similar formulas: > > Don't these methods limit the effective keyspace for 3DES? > > Someone wanting to guess the 3DES key, could start by simply guessing > SKEYID_e. SKEYID_e is only 128 bits long (assuming md5 is used for the > hmac). > > The attacker then runs every one of those 2^128 SKEYID_e through the > algorithm above (requiring 3*2^128 md5 computations), and ends up with 2^128 > possible 3des keys. > > So, effectively, the strength of the cipher could only ever be as strong as > the size of the output of the hash algorithm. Is this correct? > > If this is correct, then it could be fixed by including g^xy in K1, K2 and > K3 > > K1 = prf(SKEYID_e, g^xy, 0) > K2 = prf(SKEYID_e, g^xy, K1) > K3 = prf(SKEYID_e, g^xy, K2) > > > I searched through the archives, and haven't seen this discussed. > > Stephane. > > ------ > Stephane Beaulieu > S/W Engineer > VSEC Business Unit, Enterprise Line of Business > Cisco Systems. > email: stephane@cisco.com > phone: (613) 271-3678 > > > > From owner-ipsec@lists.tislabs.com Sun Jul 16 13:07:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15959; Sun, 16 Jul 2000 13:07:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11413 Sun, 16 Jul 2000 14:24:56 -0400 (EDT) X-Authentication-Warning: redshift.mimosa.com: hugh owned process doing -bs Date: Sun, 16 Jul 2000 14:35:30 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: Dan Harkins cc: Henry Spencer , IPsec List , Hugh Daniel , John Gilmore Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] In-Reply-To: <200007140125.SAA26031@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk | From: Dan Harkins | We? There are two authors on the comments to which you were replying. If you read to the bottom, you'd have noticed. | Are you a doctor? Yes. So what? | You can infer any meaning you want and have it impact your implementation | but then don't say that if I don't agree with your implementation that | I am somehow non-compliant: | | On Wed, 12 Jul 2000 19:09:17 "D. Hugh Redelmeier" wrote: | | "We infer from some comments that some implementations do not enforce the | requirement that Message IDs be unique. Although this isn't RFC | compliant, the suggestion is that the RFCs be changed!" | | Your (plural) inference is correct but that does not mean that I'm not | RFC compliant! We read the word "unique" as having its standard meaning and hence reach the stated conclusion. You seem to read it as having some other unspecified meaning ("kind of rare"?) and hence essentially meaningless. If you can read any word that vaguely, there is no standard. | What is the security hole? How can a replayed Quick Mode packet induce | either party to accept forged packets? Please read what we wrote; at no time did we claim that a security hole resulted. Interoperability problems are less serious than security holes, but are far from negligible -- people will not use a security system that doesn't work. Subsequent discussion on the list has made some of these issues clearer. It does look as if enforcing Message ID uniqueness could reduce the cost to the victim of a replay-QM1 DOS attack. Your other postings have been constructive. Thanks, Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 On Thu, 13 Jul 2000, Dan Harkins wrote: | Date: Thu, 13 Jul 2000 18:25:23 -0700 | From: Dan Harkins | To: Henry Spencer | Cc: D. Hugh Redelmeier , | IPsec List , Hugh Daniel , | John Gilmore | Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] | | We? Are you a doctor? | | You can infer any meaning you want and have it impact your implementation | but then don't say that if I don't agree with your implementation that | I am somehow non-compliant: | | On Wed, 12 Jul 2000 19:09:17 "D. Hugh Redelmeier" wrote: | | "We infer from some comments that some implementations do not enforce the | requirement that Message IDs be unique. Although this isn't RFC | compliant, the suggestion is that the RFCs be changed!" | | Your (plural) inference is correct but that does not mean that I'm not | RFC compliant! | | What is the security hole? How can a replayed Quick Mode packet induce | either party to accept forged packets? | | Dan. | | On Thu, 13 Jul 2000 17:33:33 EDT you wrote | > On Wed, 12 Jul 2000, Dan Harkins wrote: | > > For all the complaints about poor definition of terms (e.g. "system") | > > it seems surprising that a private definition of "unique" would guide | > > an objection to advancement of this draft. | > | > "Unique" is a word readily found in dictionaries; our definition is the | > standard one. Although there is a vague implication in the RFC that the | > uniqueness is intended to be only within the space of simultaneous | > negotiations, neither this nor any other restriction on the scope of | > uniqueness is actually stated. We do not feel it is unreasonable to | > interpret this as meaning that message IDs are supposed to be *unique*, | > in the strict dictionary sense of the word (within the obvious sanity | > constraint that different hosts cannot plausibly be prevented from | > choosing the same message ID). | > | > Henry Spencer | > henry@spsystems.net | > | From owner-ipsec@lists.tislabs.com Sun Jul 16 18:40:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA24264; Sun, 16 Jul 2000 18:40:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA12150 Sun, 16 Jul 2000 20:10:34 -0400 (EDT) Message-Id: <200007170018.e6H0IVJ113187@thunk.east.sun.com> From: Bill Sommerfeld To: hugh@mimosa.com cc: Dan Harkins , Henry Spencer , IPsec List , Hugh Daniel , John Gilmore Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] In-reply-to: Your message of "Sun, 16 Jul 2000 14:35:30 EDT." Reply-to: sommerfeld@East.Sun.COM Date: Sun, 16 Jul 2000 20:18:30 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Having just spent some time beating my head against a related issue (quick mode state management) in interoperability testing, it's clear that the whole phase-2 "message-id" (really "transaction id") and the implicit initialization vector chaining approach is just extremely fragile from a protocol point of view, leading to all sorts of finger-pointing when debugging. one commonly sees the following if a quick mode exchange which runs "slow" (particularly when you have logging, etc., cranked up all the way), leading one party to retransmit: - both packets are received; the first one is handled properly, advancing the IV and similar state in the phase 2 transaction. - the second packet is decrypted using the new (wrong) IV state, resulting in a decrypted packet in which the first block of the plaintext is garbled. - the garbled packet is fed to the isakmp parser, where any of a number of things could happen before the parser decides the packet is too broken to live. almost certainly, it's not going to be able to find the HASH payload at all so it can't even verify the integrity of the rest of the message.. - the receiver typically then sends a (spurious) NOTIFY message informing the sender that a message, broken in one of many possible ways, has been received. An alternative case occurs when the initiator doesn't like the responder's reply, and just drops the phase 2 exchange state. the retransmitted message from the responder is then treated as a "new" QM transaction, which, as above, is garbled on decryption. No, this isn't a "security flaw" in the protocol. It's simply non-robust protocol design.. it's exactly when retransmissions are occuring that you *don't* want to burden the network with additional spurious traffic. - Bill From owner-ipsec@lists.tislabs.com Sun Jul 16 21:35:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA01877; Sun, 16 Jul 2000 21:35:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA12448 Sun, 16 Jul 2000 23:25:11 -0400 (EDT) Message-Id: <200007170330.UAA24108@potassium.network-alchemy.com> To: hugh@mimosa.com cc: Dan Harkins , Henry Spencer , IPsec List , Hugh Daniel , John Gilmore Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] In-reply-to: Your message of "Sun, 16 Jul 2000 14:35:30 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24105.963804601.1@network-alchemy.com> Date: Sun, 16 Jul 2000 20:30:01 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 16 Jul 2000 14:35:30 EDT you wrote > We read the word "unique" as having its standard meaning and hence > reach the stated conclusion. You seem to read it as having some other > unspecified meaning ("kind of rare"?) and hence essentially > meaningless. If you can read any word that vaguely, there is no > standard. Sigh. I'll appeal to authority then. Websters's Encyclopedic Unabridged Dictionary of the English Language (the big fat one) says that unique is "1. existing as the only one or as the sole example: single; solitary in type or characeristics 2. unequaled; unparalleled; incomparable 3. impossible to duplicate within a stated or implied scope as a geographical area or range of experience; unlikely to be matched; extremely rare 4. limited in occurance to a given class, situation, or area 5. limited to a simple outcome or result" are all given as definitions for unique. "existing as the sole example" seems appropriate. When the Quick Mode terminates it does not exist any more. Therefore it seems perfectly within the _standard definition_ of the word "unique" to re-use message IDs as long as they are not used simultaneously. "limited in occurance to a given class [or] situation" seems even better. The class or situation is a Quick Mode. The uniqueness of message IDs states that they are limited in their occurance to a single Quick Mode. So we too adhere to the standard definition and we therefore come to the stated conclusion. Dan. From owner-ipsec@lists.tislabs.com Sun Jul 16 22:27:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA02583; Sun, 16 Jul 2000 22:27:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA12538 Mon, 17 Jul 2000 00:13:06 -0400 (EDT) Message-ID: <000d01bfefa6$ba8744e0$a7253ac3@elvis.ru> From: "Valery Smyslov" To: , Cc: "Dan Harkins" , "Henry Spencer" , "IPsec List" , "Hugh Daniel" , "John Gilmore" References: <200007170018.e6H0IVJ113187@thunk.east.sun.com> Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] Date: Mon, 17 Jul 2000 08:23:13 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill, ----- Original Message ----- From: Bill Sommerfeld To: Cc: Dan Harkins ; Henry Spencer ; IPsec List ; Hugh Daniel ; John Gilmore Sent: Monday, July 17, 2000 4:18 AM Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] > Having just spent some time beating my head against a related issue > (quick mode state management) in interoperability testing, it's clear > that the whole phase-2 "message-id" (really "transaction id") and the > implicit initialization vector chaining approach is just extremely > fragile from a protocol point of view, leading to all sorts of > finger-pointing when debugging. > > one commonly sees the following if a quick mode exchange which runs > "slow" (particularly when you have logging, etc., cranked up all the > way), leading one party to retransmit: > > - both packets are received; the first one is handled > properly, advancing the IV and similar state in the phase 2 > transaction. > - the second packet is decrypted using the new (wrong) IV > state, resulting in a decrypted packet in which the first block of the > plaintext is garbled. > - the garbled packet is fed to the isakmp parser, where any of > a number of things could happen before the parser decides the packet > is too broken to live. almost certainly, it's not going to be able to find > the HASH payload at all so it can't even verify the integrity of > the rest of the message.. > - the receiver typically then sends a (spurious) NOTIFY > message informing the sender that a message, broken in one of many > possible ways, has been received. The problem you have described is not a protocol problem, it is an implementation problem. Nothing prevents implementation from keeping last received packet (or hash of it) in SA state and discarding any incoming packet if it is identical to the packet kept. At least our implementation behaves this way and we have never encountered your problem. > An alternative case occurs when the initiator doesn't like the > responder's reply, and just drops the phase 2 exchange state. the > retransmitted message from the responder is then treated as a "new" QM > transaction, which, as above, is garbled on decryption. Again, it is possible for initiator to keep the state for a while (as TCP does), although in this case it is less desireable and can lead to potential DoS attacks. > No, this isn't a "security flaw" in the protocol. It's simply > non-robust protocol design.. it's exactly when retransmissions are > occuring that you *don't* want to burden the network with additional > spurious traffic. I agree that protocol could have been designed a bit better in this area (for example, it could have been possible to introduce some field in ISAKMP header, say Message-Number-In-This-Exchange; it must be authenticated, but not encrypted; this would have helped to quickly detect retransmissions), but I don't think that current design is "non-robust", it just require an implementation to be a bit more wise. > - Bill Regards, Valera. From owner-ipsec@lists.tislabs.com Mon Jul 17 03:54:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11516; Mon, 17 Jul 2000 03:54:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA13390 Mon, 17 Jul 2000 05:27:51 -0400 (EDT) Message-Id: <200007170936.e6H9a2J113489@thunk.east.sun.com> From: Bill Sommerfeld To: "Valery Smyslov" cc: sommerfeld@East.Sun.COM, hugh@mimosa.com, "Dan Harkins" , "Henry Spencer" , "IPsec List" , "Hugh Daniel" , "John Gilmore" Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] In-reply-to: Your message of "Mon, 17 Jul 2000 08:23:13 +0400." <000d01bfefa6$ba8744e0$a7253ac3@elvis.ru> Reply-to: sommerfeld@East.Sun.COM Date: Mon, 17 Jul 2000 05:36:02 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Nothing prevents implementation from keeping last received packet > (or hash of it) in SA state and discarding any incoming packet if it > is identical to the packet kept. At least our implementation behaves > this way and we have never encountered your problem. You'll still get wind up with garbled decryptions of a retransmission if the network reorders packets on you.. i.e., if you recieve packet 1, then packet 2, then a duplicate/retransmission of packet 1. (maybe you've not played with flakeways and other similarly "abusive" test environments..) - Bill From owner-ipsec@lists.tislabs.com Mon Jul 17 06:14:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA13835; Mon, 17 Jul 2000 06:14:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA14078 Mon, 17 Jul 2000 07:54:52 -0400 (EDT) Message-ID: <310508EDF557D31188FA0050DA0A3752658724@CAT01S2> From: Tim Jenkins To: "'Dan Harkins'" , "'IPsec List'" Subject: Responder Pre-set-up hole (was RE: problems with draft-jenkins-ip sec-rekeying-06.txt) Date: Fri, 14 Jul 2000 12:48:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, The hole I was referring to was the existence for a brief period of time an inbound SA that was created with less randomness then the one set up with by the original quick mode exchange since it would use the same value for Ni_b and protocol in the KEYMAT generation. I was not willing to state that this was as secure and was not somehow exploitable, so I took the cautious route and decided that it was not acceptable to do this. Is this being over-cautious? Tim > -----Original Message----- > From: Dan Harkins [mailto:dharkins@cips.nokia.com] > Sent: Friday, July 14, 2000 2:01 AM > To: 'IPsec List' > Subject: Re: problems with draft-jenkins-ipsec-rekeying-06.txt > > > I do not believe that a "Responder Pre-Set-up Security Hole" > exists in IKE as is defined in RFC2409 and suggest that the > text referring to such be deleted from rekeying draft prior > to advancement to Informational RFC status. > > The draft says: > > "2.2.1.4 Responder Pre-Set-up Security Hole > > In the failed negotiation case, the need to delete the invalid > inbound SA raises the issue of a temporary hole, in that the > responder allows inbound packets while waiting for the third quick > mode message. However, if the inbound SA is not set up ahead of > time, initiators that immediately transmit on the new outbound SA > will cause packets to be dropped. > > It also illustrates why the proposal above made the usage of the > outbound SA by the initiator wait until there is an indication of > the use of the SA by the responder. > > Note that this security hole is exactly what would result from an > attacker replaying the first quick mode message of an exchange." > > There would be no security hole from an attacker replaying a Quick > Mode message because upon receipt of this replayed packet the > Responder would choose a random nonce and, if it chose to "pre set > up" its SAs, derive keying material for the IPSec SAs which are > based, in part, on that nonce. In addition the SPI the Responder > would choose is part of his responce which, again, the attacker > would be unable to read and therefore would not know which SPI > upon which to send his packets! > > Basically, even if the attacker could guess which random SPI > the Responder chose as a result of this replayed packet he would > still not be able to construct a packet which the Responder would > verify and decrypt. Only the authenticated peer has the SKEYID > state necessary to construct the right KEYMAT. > > The only issue is that there is a possible attack if this > replayed packet contained PFS (which the attacker would not know) > because the Responder is doing "pre-set-up" and would most likely > finish exponentiation. But this seems to be a manufactured > problem. Don't do "pre-set-up"! Use the commit bit if you don't > want to receive IPSec packets from the Initiator prior to > receipt of the message #3. > > Dan. > From owner-ipsec@lists.tislabs.com Mon Jul 17 06:16:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA13875; Mon, 17 Jul 2000 06:16:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA14106 Mon, 17 Jul 2000 07:57:52 -0400 (EDT) Message-ID: <310508EDF557D31188FA0050DA0A3752658725@CAT01S2> From: Tim Jenkins To: "'Dan Harkins'" , Tim Jenkins Cc: "'IPsec List'" Subject: RE: Responder Pre-set-up hole (was RE: problems with draft-jenkin s-ip sec-rekeying-06.txt) Date: Fri, 14 Jul 2000 13:42:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Okay, I'll be more explicit. You alluded to it already, but it seems to me that this new SA has less entropy in the key material generation, and therefore might have some greater susceptibility in being cracked. If I explicitly state that the new SA in this particular case has less entropy because it re-uses the initiator nonce from the original quick mode message one that is replayed, and therefore might possibly be weakened, would that satisfy you rather than having the statement removed? > -----Original Message----- > From: Dan Harkins [mailto:dharkins@cips.nokia.com] > Sent: Friday, July 14, 2000 1:34 PM > To: Tim Jenkins > Cc: 'IPsec List' > Subject: Re: Responder Pre-set-up hole (was RE: problems with > draft-jenkins-ip sec-rekeying-06.txt) > > > Tim, > > But that SA will not and cannot be used in the case of a > replay attack. > > I'm not sure about whether you're being over-cautious or > not but saying > that there is a Security Hole seems being not only over > critical but wrong. > If the issue is a DoS attack in which the Responder can be > induced into > doing exponentiations as a result of replayed packets then > that should be > explicitly stated. > > I received 2 private emails over the last couple of days > saying that the > Security Hole was that the Responder would accept traffic > (also replayed) > on that SA. Statistics 101 tells me that there are probably even more > people who received that impression by reading the draft. > > Dan. > > On Fri, 14 Jul 2000 12:48:19 EDT you wrote > > Dan, > > > > The hole I was referring to was the existence for a brief > period of time an > > inbound SA that was created with less randomness then the > one set up with by > > the original quick mode exchange since it would use the > same value for Ni_b > > and protocol in the KEYMAT generation. > > > > I was not willing to state that this was as secure and was > not somehow > > exploitable, so I took the cautious route and decided that > it was not > > acceptable to do this. > > > > Is this being over-cautious? > > > > Tim > > > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@cips.nokia.com] > > > Sent: Friday, July 14, 2000 2:01 AM > > > To: 'IPsec List' > > > Subject: Re: problems with draft-jenkins-ipsec-rekeying-06.txt > > > > > > > > > I do not believe that a "Responder Pre-Set-up Security Hole" > > > exists in IKE as is defined in RFC2409 and suggest that the > > > text referring to such be deleted from rekeying draft prior > > > to advancement to Informational RFC status. > > > > > > The draft says: > > > > > > "2.2.1.4 Responder Pre-Set-up Security Hole > > > > > > In the failed negotiation case, the need to delete the invalid > > > inbound SA raises the issue of a temporary hole, in that the > > > responder allows inbound packets while waiting for the > third quick > > > mode message. However, if the inbound SA is not set up ahead of > > > time, initiators that immediately transmit on the new > outbound SA > > > will cause packets to be dropped. > > > > > > It also illustrates why the proposal above made the > usage of the > > > outbound SA by the initiator wait until there is an > indication of > > > the use of the SA by the responder. > > > > > > Note that this security hole is exactly what would > result from an > > > attacker replaying the first quick mode message of an > exchange." > > > > > > There would be no security hole from an attacker replaying a Quick > > > Mode message because upon receipt of this replayed packet the > > > Responder would choose a random nonce and, if it chose to "pre set > > > up" its SAs, derive keying material for the IPSec SAs which are > > > based, in part, on that nonce. In addition the SPI the Responder > > > would choose is part of his responce which, again, the attacker > > > would be unable to read and therefore would not know which SPI > > > upon which to send his packets! > > > > > > Basically, even if the attacker could guess which random SPI > > > the Responder chose as a result of this replayed packet he would > > > still not be able to construct a packet which the Responder would > > > verify and decrypt. Only the authenticated peer has the SKEYID > > > state necessary to construct the right KEYMAT. > > > > > > The only issue is that there is a possible attack if this > > > replayed packet contained PFS (which the attacker would not know) > > > because the Responder is doing "pre-set-up" and would most likely > > > finish exponentiation. But this seems to be a manufactured > > > problem. Don't do "pre-set-up"! Use the commit bit if you don't > > > want to receive IPSec packets from the Initiator prior to > > > receipt of the message #3. > > > > > > Dan. > > > > From owner-ipsec@lists.tislabs.com Mon Jul 17 06:33:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14085; Mon, 17 Jul 2000 06:33:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA14153 Mon, 17 Jul 2000 08:16:51 -0400 (EDT) Message-ID: <310508EDF557D31188FA0050DA0A3752658726@CAT01S2> From: Tim Jenkins To: "'Dan Harkins'" Cc: "'IPsec List'" Subject: RE: Responder Pre-set-up hole (was RE: problems with draft-jenkin s-ip sec-rekeying-06.txt) Date: Fri, 14 Jul 2000 15:47:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, I assume you mean "... if it that SA not be used" by the attacker. Are you going to guarantee that the SA cannot be used given that it has less entropy in its keying material? Is there no attack that can be launched based on analysis of the previous SA and knowing that some of the keying material input is the same? As I said before, I won't guarantee that. I won't call it a security hole. I would categorize it as a potential risk. How about I change the section name to "2.2.1.4 Responder Pre-Set-up Issues" and I'll add your comments about DoS? Would that make you happy? Tim > -----Original Message----- > From: Dan Harkins [mailto:dharkins@cips.nokia.com] > Sent: Friday, July 14, 2000 1:51 PM > To: Tim Jenkins > Cc: 'IPsec List' > Subject: Re: Responder Pre-set-up hole (was RE: problems with > draft-jenkin s-ip sec-rekeying-06.txt) > > > But what's the point if that SA can not be used? If there is some > issue aside from the potential for a DoS attack then what is it? If > it's just a potential DoS attack then just say so. If it's just a DoS > attack it seems appropriate to mention that the attack is bounded by > the number of Quick Modes already performed on each active > SA. Replaying > old Quick Modes for SAs which have expired will do nothing. > > "Unsafe at any speed" killed a very fine, and quite safe, > car; "Security > Hole" seems hyperbolic. > > Dan. > > On Fri, 14 Jul 2000 13:42:53 EDT you wrote > > Okay, I'll be more explicit. You alluded to it already, but > it seems to me > > that this new SA has less entropy in the key material > generation, and > > therefore might have some greater susceptibility in being cracked. > > > > If I explicitly state that the new SA in this particular > case has less > > entropy because it re-uses the initiator nonce from the > original quick mode > > message one that is replayed, and therefore might possibly > be weakened, > > would that satisfy you rather than having the statement removed? > > > > > -----Original Message----- > > > From: Dan Harkins [mailto:dharkins@cips.nokia.com] > > > Sent: Friday, July 14, 2000 1:34 PM > > > To: Tim Jenkins > > > Cc: 'IPsec List' > > > Subject: Re: Responder Pre-set-up hole (was RE: problems with > > > draft-jenkins-ip sec-rekeying-06.txt) > > > > > > > > > Tim, > > > > > > But that SA will not and cannot be used in the case of a > > > replay attack. > > > > > > I'm not sure about whether you're being over-cautious or > > > not but saying > > > that there is a Security Hole seems being not only over > > > critical but wrong. > > > If the issue is a DoS attack in which the Responder can be > > > induced into > > > doing exponentiations as a result of replayed packets then > > > that should be > > > explicitly stated. > > > > > > I received 2 private emails over the last couple of days > > > saying that the > > > Security Hole was that the Responder would accept traffic > > > (also replayed) > > > on that SA. Statistics 101 tells me that there are > probably even more > > > people who received that impression by reading the draft. > > > > > > Dan. > > > > > > On Fri, 14 Jul 2000 12:48:19 EDT you wrote > > > > Dan, > > > > > > > > The hole I was referring to was the existence for a brief > > > period of time an > > > > inbound SA that was created with less randomness then the > > > one set up with by > > > > the original quick mode exchange since it would use the > > > same value for Ni_b > > > > and protocol in the KEYMAT generation. > > > > > > > > I was not willing to state that this was as secure and was > > > not somehow > > > > exploitable, so I took the cautious route and decided that > > > it was not > > > > acceptable to do this. > > > > > > > > Is this being over-cautious? > > > > > > > > Tim > > > > > > > > > -----Original Message----- > > > > > From: Dan Harkins [mailto:dharkins@cips.nokia.com] > > > > > Sent: Friday, July 14, 2000 2:01 AM > > > > > To: 'IPsec List' > > > > > Subject: Re: problems with > draft-jenkins-ipsec-rekeying-06.txt > > > > > > > > > > > > > > > I do not believe that a "Responder Pre-Set-up Security Hole" > > > > > exists in IKE as is defined in RFC2409 and suggest that the > > > > > text referring to such be deleted from rekeying draft prior > > > > > to advancement to Informational RFC status. > > > > > > > > > > The draft says: > > > > > > > > > > "2.2.1.4 Responder Pre-Set-up Security Hole > > > > > > > > > > In the failed negotiation case, the need to delete > the invalid > > > > > inbound SA raises the issue of a temporary hole, > in that the > > > > > responder allows inbound packets while waiting for the > > > third quick > > > > > mode message. However, if the inbound SA is not > set up ahead of > > > > > time, initiators that immediately transmit on the new > > > outbound SA > > > > > will cause packets to be dropped. > > > > > > > > > > It also illustrates why the proposal above made the > > > usage of the > > > > > outbound SA by the initiator wait until there is an > > > indication of > > > > > the use of the SA by the responder. > > > > > > > > > > Note that this security hole is exactly what would > > > result from an > > > > > attacker replaying the first quick mode message of an > > > exchange." > > > > > > > > > > There would be no security hole from an attacker > replaying a Quick > > > > > Mode message because upon receipt of this replayed packet the > > > > > Responder would choose a random nonce and, if it > chose to "pre set > > > > > up" its SAs, derive keying material for the IPSec SAs > which are > > > > > based, in part, on that nonce. In addition the SPI > the Responder > > > > > would choose is part of his responce which, again, > the attacker > > > > > would be unable to read and therefore would not know which SPI > > > > > upon which to send his packets! > > > > > > > > > > Basically, even if the attacker could guess which random SPI > > > > > the Responder chose as a result of this replayed > packet he would > > > > > still not be able to construct a packet which the > Responder would > > > > > verify and decrypt. Only the authenticated peer has the SKEYID > > > > > state necessary to construct the right KEYMAT. > > > > > > > > > > The only issue is that there is a possible attack if this > > > > > replayed packet contained PFS (which the attacker > would not know) > > > > > because the Responder is doing "pre-set-up" and would > most likely > > > > > finish exponentiation. But this seems to be a manufactured > > > > > problem. Don't do "pre-set-up"! Use the commit bit if > you don't > > > > > want to receive IPSec packets from the Initiator prior to > > > > > receipt of the message #3. > > > > > > > > > > Dan. > > > > > > > > > From owner-ipsec@lists.tislabs.com Mon Jul 17 08:27:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16914; Mon, 17 Jul 2000 08:27:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14625 Mon, 17 Jul 2000 09:40:06 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14707.3806.575040.769888@xedia.com> Date: Mon, 17 Jul 2000 09:49:18 -0400 (EDT) To: dharkins@cips.nokia.com Cc: hugh@mimosa.com, henry@spsystems.net, ipsec@lists.tislabs.com, hugh@toad.com, gnu@toad.com Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] References: <200007170330.UAA24108@potassium.network-alchemy.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan Harkins writes: Dan> On Sun, 16 Jul 2000 14:35:30 EDT you wrote >> We read the word "unique" as having its standard meaning and hence >> reach the stated conclusion. You seem to read it as having some >> other unspecified meaning ("kind of rare"?) and hence essentially >> meaningless. If you can read any word that vaguely, there is no >> standard. Dan> Sigh. I'll appeal to authority then. Websters's Encyclopedic Dan> Unabridged Dictionary ... All this is of great academic interest to those of us who are language buffs, but it in no way contributes to a useful technical discussion on the merits of various key management algorithms. >From what I can tell, the wording of the current spec on the requirements for message IDs is ambiguous (witness this discussion). So the conclusion is that the spec needs repair. Can we please agree on what the *technical* requirement is and proceed from there? Once that is known it should be possible to craft an English phrase that clearly expresses the desired requirement. paul From owner-ipsec@lists.tislabs.com Mon Jul 17 09:04:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17693; Mon, 17 Jul 2000 09:04:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15007 Mon, 17 Jul 2000 10:57:00 -0400 (EDT) X-Authentication-Warning: redshift.mimosa.com: hugh owned process doing -bs Date: Mon, 17 Jul 2000 11:06:54 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: Andrew Krywaniuk cc: "'Tim Jenkins'" , "'IPsec List'" , "'Hugh Daniel'" , "'John Gilmore'" , "'Henry Spencer'" Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt In-Reply-To: <003b01bfecff$92b58b10$d23e788a@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk | From: Andrew Krywaniuk | Date: Thu, 13 Jul 2000 15:21:40 -0400 | Hugh: | | > As noted the message ID in the ISAKMP header-- and used in the prf | > computation-- is unique to this exchange and MUST NOT be the same as | > the message ID of another phase 2 exchange which generated this | > informational exchange. | > | > This does not qualify "unique" in any way. It does clearly use the | > admonition "MUST NOT". | | As I mentioned several weeks ago, your statement here is misleading. The | "MUST NOT" clause only applies to the statement that the informational | exchange shoudn't use the same message id AS THE QM WHICH (PRESUMABLY) | CAUSED IT TO BE GENERATED. What I said about this quote from RFC2409 did not clearly communicate what I meant. Sorry. Let me try again. The sentence is best understood as two separate assertions. | > As noted the message ID in the ISAKMP header-- and used in the prf | > computation-- is unique to this exchange The Message ID of the exchange is unique. | > and MUST NOT be the same as | > the message ID of another phase 2 exchange which generated this | > informational exchange. The MUST NOT is reinforcing an implication of the first part: that the Message ID on an Informational Exchange won't be the same as the Message ID of another Phase 2 exchange which generated the Informational Exchange. This needs to be reinforced because sharing a Message ID in this case would help connect the Informational Exchange to the Phase 2 exchange that generated it. So this use of MUST NOT does not enforce uniqueness in general, only in this particular case. But it contradicts any interpretation that "unique" means nothing. There is still the use of "unique" that I pointed out in RFC2408. RFC2408 "ISAKMP" 3.1 "ISAKMP Header Format" (near end) states that the Message ID must be unique, without further qualification: o Message ID (4 octets) - Unique Message Identifier used to identify protocol state during Phase 2 negotiations. This value is randomly generated by the initiator of the Phase 2 negotiation. In the event of simultaneous SA establishments (i.e. collisions), the value of this field will likely be different because they are independently generated and, thus, two security associations will progress toward establishment. However, it is unlikely there will be absolute simultaneous establishments. During Phase 1 negotiations, the value MUST be set to 0. | As for your clear misinterpretation of the word "unique", let's go straight | to the source. Take a look at the passage I have blocked off and you will | see how the words "unique to" are commonly interpreted. | | According to Webster: | _______________________________________________________ | | b : distinctively characteristic : PECULIAR 1 | _______________________________________________________ I'm having trouble applying this interpretation to the quote from RGC2409. Are you claiming that the quote means that only Informational Exchanges have Message IDs? That is easy to refute :-) Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec@lists.tislabs.com Mon Jul 17 09:06:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17718; Mon, 17 Jul 2000 09:06:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14983 Mon, 17 Jul 2000 10:50:23 -0400 (EDT) X-Authentication-Warning: redshift.mimosa.com: hugh owned process doing -bs Date: Mon, 17 Jul 2000 11:01:03 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: Andrew Krywaniuk cc: Henry Spencer , "'Dan Harkins'" , "'Jan Vilhuber'" , "'IPsec List'" , "'Hugh Daniel'" , "'John Gilmore'" Subject: RE: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] In-Reply-To: <003901bfecfa$28ec57e0$d23e788a@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk | From: Andrew Krywaniuk | Date: Thu, 13 Jul 2000 14:42:55 -0400 | Hugh: | | > One complaint about enforcing uniqueness of Message IDs is that it | > appears to require an unbounded amount of state in an ISAKMP SA to | > store all the used Message IDs. Although the state for each Message | > ID is small (4 octets), there might be a very large number of them. | > | > It turns out that there is a simple way to prune this state: | > negotiate a new ISAKMP SA and delete the old one. At this point, none | > of the state matters any more. It was only used to enforce uniqueness | > of future Message IDs for exchanges under the protection of the old | > ISAKMP SA, and there will be none. | | IMHO, we have already passed up one opportunity to have a technically | clever, fully stateless protocol and we should not do it again. | | Requiring the peer to keep track of an array of unsolicited data that you | generate breaks the general rule of thumb that a host should be able to | control the bound on the amount of data he stores. Forcing a rekey to remedy | this situation is not acceptable IMO. As I understand it, the point of statelessness in Photuris was so that a Bad Guy could not put a heavy burden on the keying agent. This is a much less severe problem in IKE Phase 2: the peer has already authenticated itself. So a random Bad Guy would not be able to trigger this buildup of state. Have I missed the point of statelessness? Of course, the protocol isn't stateless in any interesting way. We've got several IPsec SAs as the product of each Quick Mode, and each of them has state that is significantly larger than the 4 octets of a Message ID. Presumably a peer that can establish an ISAKMP SA will probably be able to create as many IPsec SAs as it wishes (perhaps duplicates). If a Bad Guy can build an ISAKMP SA, he can crush us with way more than a surfeit of Message IDs. It is true that (most) Informational exchanges and New Group modes consume a Message ID. But they are optional. An implementation could exploit this if space is at a premium -- ignore them and ignore their Message IDs. I just don't see that the 4 octets add up to a dominant requirement for memory. If replaying of Informational exchanges and New Group Modes is of no concern, uniqueness could be dropped as a requirement for them. Thus only Quick Mode Message IDs need be saved. I'm not sure I like this, but I point it out. If replaying of Informational exchanges and New Group Modes is of concern, is there any other mechanism to prevent a replay attack using them? Replaying an INITIAL_CONTACT, for example, is quite nasty; that is one reason why we recommend that it not be part of an Informational Exchange (Unacknowledged or Acknowledged). Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec@lists.tislabs.com Mon Jul 17 12:40:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22330; Mon, 17 Jul 2000 12:40:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15612 Mon, 17 Jul 2000 13:57:30 -0400 (EDT) Message-ID: <002a01bff019$e7d04d20$53323ac3@elvis.ru> From: "Valery Smyslov" To: Cc: "IPsec List" References: <200007170936.e6H9a2J113489@thunk.east.sun.com> Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] Date: Mon, 17 Jul 2000 22:07:42 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: Bill Sommerfeld To: Valery Smyslov Cc: ; ; Dan Harkins ; Henry Spencer ; IPsec List ; Hugh Daniel ; John Gilmore Sent: Monday, July 17, 2000 1:36 PM Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] > > Nothing prevents implementation from keeping last received packet > > (or hash of it) in SA state and discarding any incoming packet if it > > is identical to the packet kept. At least our implementation behaves > > this way and we have never encountered your problem. > > You'll still get wind up with garbled decryptions of a retransmission > if the network reorders packets on you.. i.e., if you recieve packet > 1, then packet 2, then a duplicate/retransmission of packet 1. OK, then keep all of them (or better hashes). I guess there will be not too many of them, at most 3 :-) > (maybe you've not played with flakeways and other similarly "abusive" > test environments..) We did. However test environments differ, so maybe we played other scenarious then you. > - Bill Regards, Valera. From owner-ipsec@lists.tislabs.com Mon Jul 17 12:41:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22350; Mon, 17 Jul 2000 12:41:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15703 Mon, 17 Jul 2000 14:16:35 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Glawitsch, Gregor'" , "'Stephane Beaulieu'" , "'ipsec-list'" Subject: RE: Generating 3DES keys from SKEYID_e Date: Mon, 17 Jul 2000 14:20:08 -0400 Message-Id: <000c01bff01b$a433baa0$d23e788a@andrewk3.ca.newbridge.com> 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 V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Good catch, Stephane. Yet again, we see a suboptimal result from a parameter derivation where the derivation formula appears to have been arbitrary chosen (and the justification for the formula is omitted). Yes, we all know that 2^128 is a large number, but 2^256 is a much biger number. We deal with large numbers all the time. As cryptography implementers, we have to set aside the "billions and billions" mumbo jumbo and deal with quanitifiable safety margins. (For example, 2^128 is only 2^64 against meet in the middle.) As Stephane pointed out, fixing this weakness would have been trivial, had it been caught sooner. Fine, so in this case the weakness was not fatal... But what assurance do we have that some other parameter derivation is not casually discarding entropy? IMHO, it just goes to show that pseudo-arbitrary parameter derivations do not lead to a strong protocol. BTW, although Stephane only mentioned the phase 1 SKEYID_e derivation, I want to point out that this weakness also applies to phase 2 (although it's fixed if pfs is used). Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Glawitsch, Gregor > Sent: Friday, July 14, 2000 5:12 PM > To: 'Stephane Beaulieu'; ipsec-list > Subject: RE: Generating 3DES keys from SKEYID_e > > > Stephane, > > do you realize how large 2^128 is? > > Greg Glawitsch > Network Associate, Inc. > > -----Original Message----- > From: Stephane Beaulieu [mailto:stephane@cisco.com] > Sent: Friday, July 14, 2000 1:56 PM > To: ipsec-list > Subject: Generating 3DES keys from SKEYID_e > > > Hi All, > > In RFC 2409, Appendix B, there's some text on how to generate keying > material for a cipher that requires a key larger than SKEYID_e. > > > Encryption keys used to protect the ISAKMP SA are derived from > SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long > enough to supply all the necessary keying material an algorithm > requires, the key is derived from feeding the results of a pseudo- > random function into itself, concatenating the results, and taking > the highest necessary bits. > > For example, if (fictitious) algorithm AKULA requires > 320-bits of key > (and has no weak key check) and the prf used to generate SKEYID_e > only generates 120 bits of material, the key for AKULA, > would be the > first 320-bits of Ka, where: > > Ka = K1 | K2 | K3 > and > K1 = prf(SKEYID_e, 0) > K2 = prf(SKEYID_e, K1) > K3 = prf(SKEYID_e, K2) > > where prf is the negotiated prf or the HMAC version of the > negotiated > hash function (if no prf was negotiated) and 0 is represented by a > single octet. Each result of the prf provides 120 bits of material > for a total of 360 bits. AKULA would use the first 320 bits of that > 360 bit string. > > > This probably comes from the same idea presented in RFC 2412, > section 2.6, > which uses similar formulas: > > Don't these methods limit the effective keyspace for 3DES? > > Someone wanting to guess the 3DES key, could start by simply guessing > SKEYID_e. SKEYID_e is only 128 bits long (assuming md5 is > used for the > hmac). > > The attacker then runs every one of those 2^128 SKEYID_e through the > algorithm above (requiring 3*2^128 md5 computations), and > ends up with 2^128 > possible 3des keys. > > So, effectively, the strength of the cipher could only ever > be as strong as > the size of the output of the hash algorithm. Is this correct? > > If this is correct, then it could be fixed by including g^xy > in K1, K2 and > K3 > > K1 = prf(SKEYID_e, g^xy, 0) > K2 = prf(SKEYID_e, g^xy, K1) > K3 = prf(SKEYID_e, g^xy, K2) > > > I searched through the archives, and haven't seen this discussed. > > Stephane. > > ------ > Stephane Beaulieu > S/W Engineer > VSEC Business Unit, Enterprise Line of Business > Cisco Systems. > email: stephane@cisco.com > phone: (613) 271-3678 > > > From owner-ipsec@lists.tislabs.com Mon Jul 17 12:42:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22372; Mon, 17 Jul 2000 12:42:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15770 Mon, 17 Jul 2000 14:25:39 -0400 (EDT) Message-ID: <009d01bff01d$c9c3bf70$0101a8c0@mv.lucent.com> From: "David W. Faucher" To: "Paul Koning" , Cc: , , , , References: <200007170330.UAA24108@potassium.network-alchemy.com> <14707.3806.575040.769888@xedia.com> Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] Date: Mon, 17 Jul 2000 13:34:01 -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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Regardless of how "unique" is interpreted, it does appear that an implementation may be open to replay attacks if it does not keep track of the MIDs that have been used on a given ISKAMP SA. My question is whether an MID needs to be random. Could it be replaced by something like a counter? This would be similar to the anti-replay concept used by IPSEC. To prevent collisions, a post phase1 exchange initiated by the ISAKMP SA initiator would use odd numbers while exchanges initiated by the ISAKMP SA responder would be even. [snip...] > > From what I can tell, the wording of the current spec on the > requirements for message IDs is ambiguous (witness this discussion). > So the conclusion is that the spec needs repair. Can we please agree > on what the *technical* requirement is and proceed from there? Once > that is known it should be possible to craft an English phrase that > clearly expresses the desired requirement. > > paul > From owner-ipsec@lists.tislabs.com Mon Jul 17 13:34:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23301; Mon, 17 Jul 2000 13:34:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15948 Mon, 17 Jul 2000 15:19:03 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: , "'Andrew Krywaniuk'" Cc: "'Tim Jenkins'" , "'IPsec List'" , "'Hugh Daniel'" , "'John Gilmore'" , "'Henry Spencer'" Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt Date: Mon, 17 Jul 2000 15:22:33 -0400 Message-Id: <001101bff024$5cba37e0$d23e788a@andrewk3.ca.newbridge.com> 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 V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugh, I don't agree with your interpretation and I think you are missing the point. The MUST NOT clause is not saying what you think it is saying, "unique to" means "characteristic of", and, in the context of "randomly generated", "unique" means "statistically unique" (i.e. collision resistant). However, I agree with Paul in this matter. Obviously, the RFC is amphibologous enough to have confused you, so it should be amended to be more clear. Internet drafts are written in a mix of English and jargon; sometimes the two languages overlap and it confuses people. Obviously, Dan knows what the intent of the wording in the IKE RFC is; I don't see how you can argue with that. Most of the rest of us figured it out as well. BTW, imagine if we had to qualify "unique" as "statistically unique" everywhere... "Alice is probably the only one who can decrypt the message because only she (or someone who randomly generated the same public key as she did) has the private key." "The hash proves that the message hasn't been tampered with (or at the very least, that the original message was one of the very few 256 byte messages that would have produced the same hash)." "The responder must store all nonces that he ever generates. If he ever happened to randomly generate a nonce that was used before then he could fall victim to a replay attack." Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: D. Hugh Redelmeier [mailto:hugh@mimosa.com] > Sent: Monday, July 17, 2000 11:07 AM > To: Andrew Krywaniuk > Cc: 'Tim Jenkins'; 'IPsec List'; 'Hugh Daniel'; 'John Gilmore'; 'Henry > Spencer' > Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt > > > | From: Andrew Krywaniuk > | Date: Thu, 13 Jul 2000 15:21:40 -0400 > > | Hugh: > | > | > As noted the message ID in the ISAKMP header-- and > used in the prf > | > computation-- is unique to this exchange and MUST NOT > be the same as > | > the message ID of another phase 2 exchange which generated this > | > informational exchange. > | > > | > This does not qualify "unique" in any way. It does > clearly use the > | > admonition "MUST NOT". > | > | As I mentioned several weeks ago, your statement here is > misleading. The > | "MUST NOT" clause only applies to the statement that the > informational > | exchange shoudn't use the same message id AS THE QM WHICH > (PRESUMABLY) > | CAUSED IT TO BE GENERATED. > > What I said about this quote from RFC2409 did not clearly communicate > what I meant. Sorry. Let me try again. > > The sentence is best understood as two separate assertions. > > | > As noted the message ID in the ISAKMP header-- and > used in the prf > | > computation-- is unique to this exchange > > The Message ID of the exchange is unique. > > | > and MUST NOT > be the same as > | > the message ID of another phase 2 exchange which generated this > | > informational exchange. > > The MUST NOT is reinforcing an implication of the first part: that the > Message ID on an Informational Exchange won't be the same as the > Message ID of another Phase 2 exchange which generated the > Informational Exchange. This needs to be reinforced because sharing > a Message ID in this case would help connect the Informational > Exchange to the Phase 2 exchange that generated it. > > So this use of MUST NOT does not enforce uniqueness in general, only > in this particular case. But it contradicts any interpretation > that "unique" means nothing. > > There is still the use of "unique" that I pointed out in > RFC2408. RFC2408 > "ISAKMP" 3.1 "ISAKMP Header Format" (near end) states that > the Message ID > must be unique, without further qualification: > > o Message ID (4 octets) - Unique Message Identifier used to > identify protocol state during Phase 2 negotiations. > This value > is randomly generated by the initiator of the Phase 2 > negotiation. In the event of simultaneous SA establishments > (i.e. collisions), the value of this field will likely be > different because they are independently generated > and, thus, two > security associations will progress toward establishment. > However, it is unlikely there will be absolute simultaneous > establishments. During Phase 1 negotiations, the value MUST be > set to 0. > > | As for your clear misinterpretation of the word "unique", > let's go straight > | to the source. Take a look at the passage I have blocked > off and you will > | see how the words "unique to" are commonly interpreted. > | > | According to Webster: > > | _______________________________________________________ > | > | b : distinctively characteristic : PECULIAR 1 a condition > | unique to California -- Ronald Reagan> > | _______________________________________________________ > > I'm having trouble applying this interpretation to the quote from > RGC2409. Are you claiming that the quote means that only > Informational Exchanges have Message IDs? That is easy to refute :-) > > Hugh Redelmeier > hugh@mimosa.com voice: +1 416 482-8253 > > From owner-ipsec@lists.tislabs.com Mon Jul 17 13:36:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23346; Mon, 17 Jul 2000 13:36:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15982 Mon, 17 Jul 2000 15:29:29 -0400 (EDT) Message-Id: <200007171934.MAA26154@potassium.network-alchemy.com> To: "David W. Faucher" cc: "Paul Koning" , hugh@mimosa.com, henry@spsystems.net, ipsec@lists.tislabs.com, hugh@toad.com, gnu@toad.com Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] In-reply-to: Your message of "Mon, 17 Jul 2000 13:34:01 CDT." <009d01bff01d$c9c3bf70$0101a8c0@mv.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26151.963862466.1@network-alchemy.com> Date: Mon, 17 Jul 2000 12:34:26 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk An implementation may be open to a DoS attack if it does not keep track of the MIDs of Quick Modes in which PFS was used for all active IKE SAs. This attack is not effective if PFS is not used. There is no "security hole" associated with small amounts of entropy nor is there any generic replay attack which can induce an implementation into processing old IPSec packets. Dan. On Mon, 17 Jul 2000 13:34:01 CDT you wrote > Regardless of how "unique" is interpreted, it does appear that > an implementation may be open to replay attacks if it does > not keep track of the MIDs that have been used on a given > ISKAMP SA. From owner-ipsec@lists.tislabs.com Mon Jul 17 13:53:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23529; Mon, 17 Jul 2000 13:53:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16025 Mon, 17 Jul 2000 15:37:52 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Tim Jenkins'" , "'Dan Harkins'" Cc: "'IPsec List'" Subject: RE: Responder Pre-set-up hole (was RE: problems with draft-jenkins-ip sec-rekeying-06.txt) Date: Mon, 17 Jul 2000 15:41:12 -0400 Message-Id: <001201bff026$f75cc9a0$d23e788a@andrewk3.ca.newbridge.com> 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: <310508EDF557D31188FA0050DA0A3752658725@CAT01S2> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tim, I don't think the key has less entropy because the peer's nonce has been replayed. The point of the nonce is to protect you from replay (or from a bad random number generator on the peer), so as long as you trust your own random number generator, you have provided sufficient entropy. Of course, this raises an interesting point. If you do use "responder pre-setup" then an attacker can cause you to consume your random number generator's entropy quite fast (perhaps faster than he could by generating spurious main modes?) Do most implementations monitor their random number generators and refuse to proceed if they detect insufficient entropy? Probably not. Could an attacker use up the entropy faster than it is generated and use this weakness to reduce the key space for a brute force search? Sounds unlikely, but maybe. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Tim Jenkins > Sent: Friday, July 14, 2000 1:43 PM > To: 'Dan Harkins'; Tim Jenkins > Cc: 'IPsec List' > Subject: RE: Responder Pre-set-up hole (was RE: problems with > draft-jenkins-ip sec-rekeying-06.txt) > > > Okay, I'll be more explicit. You alluded to it already, but > it seems to me > that this new SA has less entropy in the key material generation, and > therefore might have some greater susceptibility in being cracked. > > If I explicitly state that the new SA in this particular case has less > entropy because it re-uses the initiator nonce from the > original quick mode > message one that is replayed, and therefore might possibly be > weakened, > would that satisfy you rather than having the statement removed? > > > -----Original Message----- > > From: Dan Harkins [mailto:dharkins@cips.nokia.com] > > Sent: Friday, July 14, 2000 1:34 PM > > To: Tim Jenkins > > Cc: 'IPsec List' > > Subject: Re: Responder Pre-set-up hole (was RE: problems with > > draft-jenkins-ip sec-rekeying-06.txt) > > > > > > Tim, > > > > But that SA will not and cannot be used in the case of a > > replay attack. > > > > I'm not sure about whether you're being over-cautious or > > not but saying > > that there is a Security Hole seems being not only over > > critical but wrong. > > If the issue is a DoS attack in which the Responder can be > > induced into > > doing exponentiations as a result of replayed packets then > > that should be > > explicitly stated. > > > > I received 2 private emails over the last couple of days > > saying that the > > Security Hole was that the Responder would accept traffic > > (also replayed) > > on that SA. Statistics 101 tells me that there are > probably even more > > people who received that impression by reading the draft. > > > > Dan. > > > > On Fri, 14 Jul 2000 12:48:19 EDT you wrote > > > Dan, > > > > > > The hole I was referring to was the existence for a brief > > period of time an > > > inbound SA that was created with less randomness then the > > one set up with by > > > the original quick mode exchange since it would use the > > same value for Ni_b > > > and protocol in the KEYMAT generation. > > > > > > I was not willing to state that this was as secure and was > > not somehow > > > exploitable, so I took the cautious route and decided that > > it was not > > > acceptable to do this. > > > > > > Is this being over-cautious? > > > > > > Tim > > > > > > > -----Original Message----- > > > > From: Dan Harkins [mailto:dharkins@cips.nokia.com] > > > > Sent: Friday, July 14, 2000 2:01 AM > > > > To: 'IPsec List' > > > > Subject: Re: problems with draft-jenkins-ipsec-rekeying-06.txt > > > > > > > > > > > > I do not believe that a "Responder Pre-Set-up Security Hole" > > > > exists in IKE as is defined in RFC2409 and suggest that the > > > > text referring to such be deleted from rekeying draft prior > > > > to advancement to Informational RFC status. > > > > > > > > The draft says: > > > > > > > > "2.2.1.4 Responder Pre-Set-up Security Hole > > > > > > > > In the failed negotiation case, the need to delete > the invalid > > > > inbound SA raises the issue of a temporary hole, in that the > > > > responder allows inbound packets while waiting for the > > third quick > > > > mode message. However, if the inbound SA is not set > up ahead of > > > > time, initiators that immediately transmit on the new > > outbound SA > > > > will cause packets to be dropped. > > > > > > > > It also illustrates why the proposal above made the > > usage of the > > > > outbound SA by the initiator wait until there is an > > indication of > > > > the use of the SA by the responder. > > > > > > > > Note that this security hole is exactly what would > > result from an > > > > attacker replaying the first quick mode message of an > > exchange." > > > > > > > > There would be no security hole from an attacker > replaying a Quick > > > > Mode message because upon receipt of this replayed packet the > > > > Responder would choose a random nonce and, if it chose > to "pre set > > > > up" its SAs, derive keying material for the IPSec SAs which are > > > > based, in part, on that nonce. In addition the SPI the > Responder > > > > would choose is part of his responce which, again, the attacker > > > > would be unable to read and therefore would not know which SPI > > > > upon which to send his packets! > > > > > > > > Basically, even if the attacker could guess which random SPI > > > > the Responder chose as a result of this replayed > packet he would > > > > still not be able to construct a packet which the > Responder would > > > > verify and decrypt. Only the authenticated peer has the SKEYID > > > > state necessary to construct the right KEYMAT. > > > > > > > > The only issue is that there is a possible attack if this > > > > replayed packet contained PFS (which the attacker > would not know) > > > > because the Responder is doing "pre-set-up" and would > most likely > > > > finish exponentiation. But this seems to be a manufactured > > > > problem. Don't do "pre-set-up"! Use the commit bit if you don't > > > > want to receive IPSec packets from the Initiator prior to > > > > receipt of the message #3. > > > > > > > > Dan. > > > > > > > > From owner-ipsec@lists.tislabs.com Mon Jul 17 17:07:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27084; Mon, 17 Jul 2000 17:07:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16480 Mon, 17 Jul 2000 18:27:58 -0400 (EDT) Date: Mon, 17 Jul 2000 18:36:03 -0400 (EDT) From: Henry Spencer To: Andrew Krywaniuk cc: hugh@mimosa.com, "'Tim Jenkins'" , "'IPsec List'" , "'Hugh Daniel'" , "'John Gilmore'" Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt In-Reply-To: <001101bff024$5cba37e0$d23e788a@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 17 Jul 2000, Andrew Krywaniuk wrote: > Internet drafts are written in a mix of English and jargon; sometimes the > two languages overlap and it confuses people. I don't actually think that's an issue here... > Obviously, Dan knows what the > intent of the wording in the IKE RFC is; I don't see how you can argue with > that. Most of the rest of us figured it out as well. The problem with standards which rely on "well, everybody knows that where it says WX_Z it really means WXQZ" is precisely that not everybody *does* know. Dan surely knows what the RFC was supposed to say, but that's not what it actually says. Moreover, I think this has slightly missed our point. We are not just arguing that there is a different interpretation possible here, or that it is the preferred interpretation in the absence of supplementary folklore (although we do make both those claims). We contend that our interpretation is *superior*. It improves the protocol's robustness, and permits solving certain vexing problems in a much simpler way than Tim Jenkins proposes, and does this (as verified by both analysis and practical experience) without introducing significant implementation difficulties or interoperability problems. The primary criterion for choice when resolving ambiguities should be technical merit, not closeness to the original intent. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jul 17 17:57:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA28489; Mon, 17 Jul 2000 17:57:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16630 Mon, 17 Jul 2000 19:32:42 -0400 (EDT) X-Authentication-Warning: redshift.mimosa.com: hugh owned process doing -bs Date: Mon, 17 Jul 2000 19:43:19 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: Dan Harkins cc: "David W. Faucher" , Paul Koning , henry@spsystems.net, ipsec@lists.tislabs.com, hugh@toad.com, gnu@toad.com Subject: Re: simplifying rekeying [draft-jenkins-ipsec-rekeying-06.txt] In-Reply-To: <200007171934.MAA26154@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk | From: Dan Harkins | To: David W. Faucher | An implementation may be open to a DoS attack if it does not keep | track of the MIDs of Quick Modes in which PFS was used for all active | IKE SAs. This attack is not effective if PFS is not used. It seems to me that if "unique" is read in some weaker sense ("probably unique" or "unique amongst live exchanges"), then a Responder probably isn't justified in rejecting a packet just because the Message ID is a duplicate of one from the past. Of course, an implementation can do what it wishes, but the rejecting Responder would not be conforming to (this reading of) the RFCs. I would very much like to be wrong about this. If I am wrong, then whether an implementation decides to enforce uniqueness is a purely local decision. Since it has (rare) interoperability consequences, I think that this ought to be a standardized feature. If it isn't, we have the worst of both worlds: implementations should not generate duplicate Message IDs for fear that their peers would reject them, but should not reject duplicate Message IDs because their peers might generate them. | There is no "security hole" associated with small amounts of entropy I imagine that this is correct. Have we a convincing argument? My intuition is that each side should put in the entropy it requires. Thus there is enough entropy in the keying material for its purposes. Besides, no sample encrypted packets are provided, so there isn't much to crack. But I made this up out of whole cloth. | nor is there any generic replay attack which can induce an implementation | into processing old IPSec packets. But IKE packets are another story. Any Phase 2 exchange with fewer than 3 messages must be vulnerable to replay unless Message ID uniqueness is enforced. Any other exchange with fewer than 3 messages must be vulnerable (Message IDs can't save this case). Some such exchanges probably have no important effect when replayed. Deleting an already deleted SA isn't dangerous. Even so, care ought to be taken to avoid an opening for DoS -- logging or excess notification or excess computation in response to a replayed packet. Even for exchanges with 3 or more messages, enforcing uniqueness will defeat a replay attack earlier, perhaps avoiding DoS consequences. Why was the Acknowledged Notification Exchange designed with only 2 messages? This seems like a mistake if uniqueness isn't to be enforced. | On Mon, 17 Jul 2000 13:34:01 CDT you [David W. Faucher ] wrote | > Regardless of how "unique" is interpreted, it does appear that | > an implementation may be open to replay attacks if it does | > not keep track of the MIDs that have been used on a given | > ISKAMP SA. Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec@lists.tislabs.com Mon Jul 17 18:26:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA02181; Mon, 17 Jul 2000 18:26:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA16754 Mon, 17 Jul 2000 20:14:38 -0400 (EDT) Message-Id: <200007180019.RAA23028@potassium.network-alchemy.com> To: Henry Spencer cc: Andrew Krywaniuk , hugh@mimosa.com, "'Tim Jenkins'" , "'IPsec List'" , "'Hugh Daniel'" , "'John Gilmore'" Subject: Re: problems with draft-jenkins-ipsec-rekeying-06.txt In-reply-to: Your message of "Mon, 17 Jul 2000 18:36:03 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23025.963879579.1@network-alchemy.com> Date: Mon, 17 Jul 2000 17:19:39 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, technical merit should guide resolution but it helps to have the problem laid out first. This whole thing started with your proposal that was a "better approach to certain parts of the rekeying problem" that draft-jenkins-ipsec-rekeying-06.txt addressed. That draft addresses _lots_ of issues. What certain parts are you resolving? The responder pre-set-up problem, which is what you seem to be focusing on, is solved by using a CONNECTED notify. There is no "security hole" associated with this. There is only potential for a DoS attack. Nowhere in your proposal does it even discuss a DoS attack. So what is it you're solving? If the problem space has moved then let's take a step back and redefine what it is we're discussing. Maybe an even more *superior* solution would be what David Faucher proposed: just make the MID a monotonically increasing counter and don't accept anything <= the currently authenticated MID. But this requires agreeing on what the problem is that the solution proposes to solve. Dan. On Mon, 17 Jul 2000 18:36:03 EDT you wrote > > Moreover, I think this has slightly missed our point. We are not just > arguing that there is a different interpretation possible here, or that it > is the preferred interpretation in the absence of supplementary folklore > (although we do make both those claims). > > We contend that our interpretation is *superior*. It improves the > protocol's robustness, and permits solving certain vexing problems in a > much simpler way than Tim Jenkins proposes, and does this (as verified by > both analysis and practical experience) without introducing significant > implementation difficulties or interoperability problems. > > The primary criterion for choice when resolving ambiguities should be > technical merit, not closeness to the original intent. > > Henry Spencer > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Mon Jul 17 21:30:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA17097; Mon, 17 Jul 2000 21:30:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA17171 Mon, 17 Jul 2000 22:45:32 -0400 (EDT) From: andrew.krywaniuk@alcatel.com Reply-To: To: "'Henry Spencer'" , "Andrew Krywaniuk" Cc: , "'Tim Jenkins'" , "'IPsec List'" , "'Hugh Daniel'" , "'John Gilmore'" Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt Date: Mon, 17 Jul 2000 22:49:11 -0400 Message-Id: <002101bff062$c1335010$d23e788a@andrewk3.ca.newbridge.com> 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 V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Internet drafts are written in a mix of English and jargon; > sometimes the > > two languages overlap and it confuses people. > > I don't actually think that's an issue here... I think it is. There is a mathematical/logical definition of "unique" which goes something like: a is unique in Z if for all b in (Z exclude a) a is not equal to b. And then there is the dictionary entry I posted earlier which shows that the English word "unique" has more than one meaning. > The problem with standards which rely on "well, everybody > knows that where > it says WX_Z it really means WXQZ" is precisely that not > everybody *does* > know. I only said that most of us knew. > The primary criterion for choice when resolving ambiguities should be > technical merit, not closeness to the original intent. I disagree here. The time to weigh technical merit is BEFORE the protocol is standardized and everyone has implemented it. Ambiguities should be resolved according to the intent of the clause and the way most people interpreted it. If it turns out that the protocol is actually lacking in technical merit, then it is time to change the protocol. But that should be done in a backwards compatible way that does not break all existing implementations. > We contend that our interpretation is *superior*. It improves the > protocol's robustness, and permits solving certain vexing > problems in a > much simpler way than Tim Jenkins proposes, and does this (as > verified by > both analysis and practical experience) without introducing > significant > implementation difficulties or interoperability problems. I'm not sure that's true. I can think of a few problems off the top of my head: I've often you heard you say (or maybe it was Hugh) that an implementation should be allowed to ignore notify and delete messages since there is no guarantee of delivery. Is the implementation required to keep track of of the message ids from packets it may never receive? I also claim that the storage/processing requirements are worse than you claim. Do you store the message ids in an array/list (in which case search time is slow) or a hash table (in which case memory consumption is high) or a tree (bit of both). I also believe that this violates the design principle which mandates that Alice should not be able to force unbounded state creation on Bob's machine. (Can you give an example of elsewhere in IPsec where this is true?) Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Henry Spencer [mailto:henry@spsystems.net] > Sent: Monday, July 17, 2000 6:36 PM > To: Andrew Krywaniuk > Cc: hugh@mimosa.com; 'Tim Jenkins'; 'IPsec List'; 'Hugh Daniel'; 'John > Gilmore' > Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt > > > On Mon, 17 Jul 2000, Andrew Krywaniuk wrote: > > Internet drafts are written in a mix of English and jargon; > sometimes the > > two languages overlap and it confuses people. > > I don't actually think that's an issue here... > > > Obviously, Dan knows what the > > intent of the wording in the IKE RFC is; I don't see how > you can argue with > > that. Most of the rest of us figured it out as well. > > The problem with standards which rely on "well, everybody > knows that where > it says WX_Z it really means WXQZ" is precisely that not > everybody *does* > know. Dan surely knows what the RFC was supposed to say, but > that's not > what it actually says. > > Moreover, I think this has slightly missed our point. We are not just > arguing that there is a different interpretation possible > here, or that it > is the preferred interpretation in the absence of > supplementary folklore > (although we do make both those claims). > > We contend that our interpretation is *superior*. It improves the > protocol's robustness, and permits solving certain vexing > problems in a > much simpler way than Tim Jenkins proposes, and does this (as > verified by > both analysis and practical experience) without introducing > significant > implementation difficulties or interoperability problems. > > The primary criterion for choice when resolving ambiguities should be > technical merit, not closeness to the original intent. > > > Henry Spencer > > henry@spsystems.net > > From owner-ipsec@lists.tislabs.com Mon Jul 17 21:30:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA17110; Mon, 17 Jul 2000 21:30:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17268 Mon, 17 Jul 2000 23:17:56 -0400 (EDT) Date: Mon, 17 Jul 2000 23:26:03 -0400 (EDT) From: Henry Spencer To: andrew.krywaniuk@alcatel.com cc: hugh@mimosa.com, "'Tim Jenkins'" , "'IPsec List'" , "'Hugh Daniel'" , "'John Gilmore'" Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt In-Reply-To: <002101bff062$c1335010$d23e788a@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 17 Jul 2000 andrew.krywaniuk@alcatel.com wrote: > And then there is the dictionary entry I posted earlier which shows that the > English word "unique" has more than one meaning. Only one of those seemed applicable... unless you "know what it means" and thus aren't really looking at the dictionary at all. > > The primary criterion for choice when resolving ambiguities should be > > technical merit, not closeness to the original intent. > > I disagree here. The time to weigh technical merit is BEFORE the protocol is > standardized and everyone has implemented it. IKE is only a Proposed Standard at this time. To quote RFC 2026: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. That is, we're still at the stage where technical considerations found by experience can legitimately result in changes. "Internet Standard" is two steps farther along the process. Implementors are supposed to be aware of this. > If it turns out that the protocol is actually lacking in technical merit, > then it is time to change the protocol. But that should be done in a > backwards compatible way that does not break all existing implementations. As we have pointed out -- repeatedly -- our interpretation has demonstrated interoperability with a wide variety of existing implementations. This is not theory, but established fact. > I've often you heard you say (or maybe it was Hugh) that an implementation > should be allowed to ignore notify and delete messages since there is no > guarantee of delivery. Is the implementation required to keep track of of > the message ids from packets it may never receive? It keeps track of the ones it receives, and not the ones it doesn't receive. Can we try to keep this discussion serious? > I also claim that the storage/processing requirements are worse than you > claim. Do you store the message ids in an array/list (in which case search > time is slow) or a hash table (in which case memory consumption is high) or > a tree (bit of both). Given the length of the lists involved -- tiny -- either approach will be totally dominated by fixed overhead anyway, unless you're doing something very strange. Remember that those message IDs come attached to messages, which typically involve the creation of much larger structures and the expenditure of much greater amounts of processing time. As we have pointed out -- repeatedly -- this has been a non-issue in practice in all experience to date. > I also believe that this violates the design principle which mandates that > Alice should not be able to force unbounded state creation on Bob's machine. Your belief is incorrect. As we have pointed out -- repeatedly -- if too much state accumulates, Bob rekeys (that is, replaces) the ISAKMP SA, at which point all saved state related to the old one can be discarded. > (Can you give an example of elsewhere in IPsec where this is true?) If Bob makes no attempt to control resource consumption -- the assumption required for the above belief to be true -- then the creation of ISAKMP and IPsec SAs is far more state-intensive. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Jul 18 09:48:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01867; Tue, 18 Jul 2000 09:48:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19291 Tue, 18 Jul 2000 10:47:44 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14708.28716.793630.882538@xedia.com> Date: Tue, 18 Jul 2000 10:56:44 -0400 (EDT) To: andrew.krywaniuk@alcatel.com Cc: henry@spsystems.net, hugh@mimosa.com, TJenkins@Catena.com, ipsec@lists.tislabs.com, hugh@toad.com, gnu@toad.com Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt References: <002101bff062$c1335010$d23e788a@andrewk3.ca.newbridge.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "andrew" == andrew krywaniuk writes: >> > Internet drafts are written in a mix of English and jargon; >> sometimes the > two languages overlap and it confuses people. >> >> I don't actually think that's an issue here... andrew> I think it is. There is a mathematical/logical definition of andrew> "unique" which goes something like: andrew> a is unique in Z if for all b in (Z exclude a) a is not equal andrew> to b. Indeed. And the real issue actually is that Z has not been defined. We need to find Z. Or, more precisely, the smallest sufficient Z. >> The primary criterion for choice when resolving ambiguities should >> be technical merit, not closeness to the original intent. andrew> I disagree here. The time to weigh technical merit is BEFORE andrew> the protocol is standardized and everyone has implemented andrew> it. Ambiguities should be resolved according to the intent of andrew> the clause and the way most people interpreted it. andrew> If it turns out that the protocol is actually lacking in andrew> technical merit, then it is time to change the protocol. But andrew> that should be done in a backwards compatible way that does andrew> not break all existing implementations. Mostly agreed. Given that we have an existing protocol with existing implementations, we should: a. Choose the meaning that "most" have used, if we can find it *and* if it is technically correct (i.e., secure), b. Failing that, choose a technically correct interpretation that's backwards compatible with most of the existing implementations, if there is one, c. Failing that, choose a technically correct interpretation (that's not backwards compatible). You left out (c) which is the last fallback, but you must have that one. (You can't choose backwards compatibility at the expense of security.) paul From owner-ipsec@lists.tislabs.com Tue Jul 18 15:11:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA09519; Tue, 18 Jul 2000 15:11:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21087 Tue, 18 Jul 2000 16:28:08 -0400 (EDT) Message-ID: <3974BFC7.3784298F@redcreek.com> Date: Tue, 18 Jul 2000 13:36:23 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com CC: anfreema@cisco.com Subject: [Fwd: Application available for Sept 2000 VPN InteroperabilityWorkshop] Content-Type: multipart/mixed; boundary="------------4318AFDD531D7AFBEB1103F1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------4318AFDD531D7AFBEB1103F1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Forwarded to ipsec list for Anita... --------------4318AFDD531D7AFBEB1103F1 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from mailman.cisco.com ([171.68.225.9]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3XGBRX5Z; Tue, 18 Jul 2000 13:34:10 -0700 Received: from anfreema-pc (dhcp-l21-163.cisco.com [171.68.210.163]) by mailman.cisco.com (8.9.3/8.9.1) with SMTP id NAA19835 for ; Tue, 18 Jul 2000 13:34:21 -0700 (PDT) Message-Id: <200007182034.NAA19835@mailman.cisco.com> X-Sender: anfreema@sj-email X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 18 Jul 2000 13:32:01 -0700 To: skelly@redcreek.com From: Anita Freeman Subject: Application available for Sept 2000 VPN Interoperability Workshop Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_8245725==_.ALT" X-Mozilla-Status2: 00000000 --=====================_8245725==_.ALT Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Jul 2000 13:27:54 -0700 To: l2tp@ipsec.org, ietf-ppp@merit.edu, ipsec@lists.tislabs.com From: Anita Freeman Subject: Application available for Sept 2000 VPN Interoperability Workshop Bcc: anfreema@cisco.com, cbazinet@cisco.com The application for the September 2000 VPN Interoperability Workshop is now available at: http://www.calbug.org:8080/vpnworkshop/ The deadline for the VPN workshop application and hotel reservations is August 15, 2000. The VPN Interoperability Workshop will be held September 18-22, 2000, at the Paradise Point Resort in San Diego, California. The VPN Workshop is being sponsored by VeriSign, SSH, Hi/fn, WindRiver, Entrust, Nokia, Alcatel, RedBack, Microsoft, Cisco, and UUNET, a Worldcom Company. The protocols being tested at this workshop are: IPsec IKE IPComp L2TP over Transport-Mode IPsec PPTP PPPoE PPPoATM L2TPoATM Hotel reservations may be made by calling Paradise Point Resort at 800-344-2626. Please register under the VPN Workshop room block for the discounted rate of $159 per night (plus tax). If you cannot access the web site above, please send an email to me and I will forward a text version of the application. Thanks, Anita Freeman --=====================_8245725==_.ALT Content-Type: text/html; charset="us-ascii"
Date: Mon, 17 Jul 2000 13:27:54 -0700
To: l2tp@ipsec.org, ietf-ppp@merit.edu, ipsec@lists.tislabs.com
From: Anita Freeman
Subject: Application available for Sept 2000 VPN Interoperability Workshop
Bcc: anfreema@cisco.com, cbazinet@cisco.com

The application for the September 2000 VPN Interoperability Workshop is now
available at:

http://www.calbug.org:8080/vpnworkshop/

The deadline for the VPN workshop application and hotel reservations is
August 15, 2000.

The VPN Interoperability Workshop will be held September 18-22, 2000, at the
Paradise Point Resort in San Diego, California.

The VPN Workshop is being sponsored by VeriSign, SSH, Hi/fn, WindRiver, Entrust, Nokia, Alcatel, RedBack, Microsoft, Cisco, and UUNET, a Worldcom Company.

The protocols being tested at this workshop are:

IPsec
IKE
IPComp
L2TP over Transport-Mode IPsec
PPTP
PPPoE
PPPoATM
L2TPoATM

Hotel reservations may be made by calling Paradise Point Resort at
800-344-2626.  Please register under the VPN Workshop room block for
the discounted rate of $159 per night (plus tax).

If you cannot access the web site above, please send an email to me and I will forward a text version of the application.

Thanks, Anita Freeman

--=====================_8245725==_.ALT-- --------------4318AFDD531D7AFBEB1103F1-- From owner-ipsec@lists.tislabs.com Wed Jul 19 12:39:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21224; Wed, 19 Jul 2000 12:39:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25504 Wed, 19 Jul 2000 13:58:36 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Paul Koning'" Cc: , , , , , Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt Date: Wed, 19 Jul 2000 14:02:02 -0400 Message-Id: <003a01bff1ab$71d1a6d0$d23e788a@andrewk3.ca.newbridge.com> 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: <14708.28716.793630.882538@xedia.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Mostly agreed. > > Given that we have an existing protocol with existing implementations, > we should: > > a. Choose the meaning that "most" have used, if we can find it *and* > if it is technically correct (i.e., secure), > > b. Failing that, choose a technically correct interpretation that's > backwards compatible with most of the existing implementations, if > there is one, > > c. Failing that, choose a technically correct interpretation (that's > not backwards compatible). > > You left out (c) which is the last fallback, but you must have that > one. (You can't choose backwards compatibility at the expense of > security.) Paul, I left out (c) for a reason. Fixing a bug in the protocol is not the same as resolving an ambiguity. If this was truly a bug then I would advocate changing the RFC to solve the problem, then advancing the IKE version number and deprecating the old version. Still, the fact remains that the purpose of message ids is to solve the demultiplexing problem, not to prevent replay attacks. In fact, IKE does not claim to offer a comprehensive solution to replay attacks. The fact that a feature is missing from IKE does not give you latitude to invent it yourself and claim it is part of the standard. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Jul 19 12:40:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21244; Wed, 19 Jul 2000 12:40:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25541 Wed, 19 Jul 2000 14:02:29 -0400 (EDT) From: andrew.krywaniuk@alcatel.com Reply-To: To: "'Henry Spencer'" , "Andrew Krywaniuk" Cc: , "'Tim Jenkins'" , "'IPsec List'" , "'Hugh Daniel'" , "'John Gilmore'" Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt Date: Wed, 19 Jul 2000 14:05:57 -0400 Message-Id: <003b01bff1ab$fe147b40$d23e788a@andrewk3.ca.newbridge.com> 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 V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > I disagree here. The time to weigh technical merit is > BEFORE the protocol is > > standardized and everyone has implemented it. > > IKE is only a Proposed Standard at this time. I think we're confusing English and Jargon again. RFC 2026 defines the terms "Proposed Standard" and "Internet Standard," not the word "standardized." You are free to write a draft proposing this behaviour for IKEv2 (or IKEv1.1), but this is not the correct way to modify IKEv1. > > I also believe that this violates the design principle > which mandates that > > Alice should not be able to force unbounded state creation > on Bob's machine. > > Your belief is incorrect. As we have pointed out -- > repeatedly -- if too > much state accumulates, Bob rekeys (that is, replaces) the > ISAKMP SA, at > which point all saved state related to the old one can be discarded. Replacing unbounded state creation with unbounded rekeying frequency is no solution. Fine, so this problem is kind of academic, but you are endagering the ability of a host to be fully self-stablizing (and that is of academic interest to me). > As we have pointed out -- repeatedly -- our interpretation has > demonstrated interoperability with a wide variety of existing > implementations. This is not theory, but established fact. You don't interoperate with people in this regard; you just think you do because this situation (a collision in 2^32) rarely happens. That's like saying your implemetation of DES40 is interoperable: no one ever proposes it and you never accept it. > Given the length of the lists involved -- tiny -- either > approach will be > totally dominated by fixed overhead anyway, unless you're > doing something > very strange. I reserve the right to do something strange. > > I've often you heard you say (or maybe it was Hugh) that an > implementation > > should be allowed to ignore notify and delete messages > since there is no > > guarantee of delivery. Is the implementation required to > keep track of of > > the message ids from packets it may never receive? > > It keeps track of the ones it receives, and not the ones it > doesn't receive. > Can we try to keep this discussion serious? If an exchange times out or a packet is dropped then the peers may not agree as to which message ids have been used. Now there is potential for one of the peers to detect a spurious replay attack (and reject legitimate packets). You already conceded that maybe this technique would have to only apply to QMs, since notifies carry no guarantee of delivery. (So already your convention is of limited usefulness.) But it is also possible for a QM negotiation to fail prematurely. What do you do then? A better solution than the one you propose, the use of a counter (a well-known anti-replay mechanism), has already been discussed on this list. If we do decide to add such a feature to IKEv2, I don't see why we would go with your suboptimal technique. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Jul 19 12:57:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21511; Wed, 19 Jul 2000 12:57:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25867 Wed, 19 Jul 2000 14:46:56 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14709.63954.655560.534909@xedia.com> Date: Wed, 19 Jul 2000 14:56:18 -0400 (EDT) To: andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt References: <003b01bff1ab$fe147b40$d23e788a@andrewk3.ca.newbridge.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "andrew" == andrew krywaniuk writes: andrew> ...Replacing unbounded state creation with unbounded rekeying andrew> frequency is no solution. Fine, so this problem is kind of andrew> academic, but you are endagering the ability of a host to be andrew> fully self-stablizing (and that is of academic interest to andrew> me). Self-stabilization is of far *more* than "academic" interest to me. I know that it is a property that is critically important in reliable networks. I look for it in real world protocols to make them safe for use in real world situations. paul From owner-ipsec@lists.tislabs.com Fri Jul 21 08:14:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01750; Fri, 21 Jul 2000 08:14:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02936 Fri, 21 Jul 2000 09:39:07 -0400 (EDT) To: tytso@mit.edu, ipsec@lists.tislabs.com Subject: re: Call for agenda topics for Pittsburgh IETF From: Markus Stenberg Date: 21 Jul 2000 12:54:32 +0900 Message-ID: <87itu06suf.fsf@porsas.jp.ssh.com> Lines: 34 User-Agent: Gnus/5.0806 (Gnus v5.8.6) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We submitted a draft last Friday that details our approach for IPsec NAT-traversal, in hope of getting a standard for this some day. NATs are here to stay, regrettably, and many vendors, each of them making their own version of NAT-traversal, is suboptimal solution to getting IPsec to work with NATs. Ted hadn't reacted to my previous mail, but this is a FYI to WG about my desire to get a chance to give a presentation regarding it (in the IETF Pittsburgh meeting) to the IPsec WG. In short, the draft details UDP encapsulation of IPsec SAs and how to probe for need of encapsulation in the IKE P1. (and then cut-n-pasted parts of I-D Announce) ------------------------------------------------------------------------------ Title : IPsec NAT-Traversal Author(s) : M. Stenberg, S. Paavolainen, T. Ylonen, T. Kivinen Filename : draft-stenberg-ipsec-nat-traversal-00.txt Pages : 16 Date : 18-Jul-00 This draft details the changes needed in order to make both initial IKE negotiation and subsequent authenticated/encrypted communications across IPsec AH/ESP SAs work despite the changes in the headers, and possible protocol transformations. The draft is at ------------------------------------------------------------------------------ -- Markus Stenberg SSH Communications Security Corp (http://www.ssh.com) From owner-ipsec@lists.tislabs.com Sun Jul 23 14:12:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02921; Sun, 23 Jul 2000 14:12:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10139 Sun, 23 Jul 2000 15:24:01 -0400 (EDT) X-Authentication-Warning: redshift.mimosa.com: hugh owned process doing -bs Date: Sun, 23 Jul 2000 15:34:24 -0400 (EDT) From: "D. Hugh Redelmeier" Reply-To: hugh@mimosa.com To: andrew.krywaniuk@alcatel.com cc: "'Henry Spencer'" , Andrew Krywaniuk , "'Tim Jenkins'" , "'IPsec List'" , "'Hugh Daniel'" , "'John Gilmore'" Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt In-Reply-To: <003b01bff1ab$fe147b40$d23e788a@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk | From: andrew.krywaniuk@alcatel.com | Replacing unbounded state creation with unbounded rekeying frequency is no | solution. Fine, so this problem is kind of academic, but you are endagering | the ability of a host to be fully self-stablizing (and that is of academic | interest to me). Can you expand on this? Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec@lists.tislabs.com Sun Jul 23 23:56:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA23746; Sun, 23 Jul 2000 23:56:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA11333 Mon, 24 Jul 2000 01:19:35 -0400 (EDT) Message-ID: <397BD422.A2CC6447@cyphers.net> Date: Sun, 23 Jul 2000 22:29:06 -0700 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: RIPEMD-160? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The working group website lists an RFC 2857 for using RIPEMD-160 in the context of ESP and AH. The link is broken and the document does not exist. Eventually, I did find the document elsewhere. I noted that for all its longevity, it didn't include any ID numbers to use for negotiating the use of it! Since these ID numbers do not appear in the DOI document either, it is somewhat of a mystery to me how this document could have advanced to RFC without any existing way to interoperate with it. As well, I don't see anything about an ID for using RIPEMD-160 in the context of Phase 1. Surely I am missing something? -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. From owner-ipsec@lists.tislabs.com Mon Jul 24 04:45:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA03282; Mon, 24 Jul 2000 04:45:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA12091 Mon, 24 Jul 2000 06:25:42 -0400 (EDT) Message-Id: <200007241035.GAA07849@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-dhcp-06.txt Date: Mon, 24 Jul 2000 06:35:01 -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 : DHCP Configuration of IPSEC Tunnel Mode Author(s) : B. Patel, B. Aboba, S. Kelly, V. Gupta Filename : draft-ietf-ipsec-dhcp-06.txt Pages : 12 Date : 21-Jul-00 In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a 'virtual' address from the corporate network, and then tunneling traffic via Ipsec from the host's ISP-assigned address to the corporate security gateway. The Dynamic Host Configuration Protocol (DHCP) provides for such remote host configuration. This draft explores the requirements for host configuration in IPSEC tunnel mode, and describes how the DHCP protocol may be leveraged for configuration in this case. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-06.txt 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-dhcp-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-dhcp-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <20000721171630.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dhcp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721171630.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Jul 24 04:45:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA03284; Mon, 24 Jul 2000 04:45:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA12090 Mon, 24 Jul 2000 06:25:36 -0400 (EDT) Message-Id: <200007241035.GAA07875@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-heartbeats-01.txt Date: Mon, 24 Jul 2000 06:35:05 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Using Isakmp Heartbeats for Dead Peer Detection Author(s) : A. Krywaniuk, T. Kivinen Filename : draft-ietf-ipsec-heartbeats-01.txt Pages : 31 Date : 21-Jul-00 This document describes a method for sending heartbeat packets (sometimes called keep-alives) across an ISAKMP SA in order to detect when a peer has crashed or has become otherwise unreachable. A method for negotiating the heartbeat parameters is also provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-heartbeats-01.txt 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-heartbeats-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-heartbeats-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000721171646.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-heartbeats-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-heartbeats-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721171646.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Jul 24 06:32:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05905; Mon, 24 Jul 2000 06:32:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13163 Mon, 24 Jul 2000 08:25:37 -0400 (EDT) Message-ID: <20000724123436.77450.qmail@hotmail.com> X-Originating-IP: [195.101.37.190] From: "beldi olivier" To: ipsec@lists.tislabs.com Subject: about ipsec Date: Mon, 24 Jul 2000 14:34:36 CEST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not sure my question is exactly on the topic of this list but i'm supposed to study and understand IPSec,in order to integrate them as a solution for my company network security. but even if i've read a lots of books and some RFC i still don't understand IKE. could anyone give me some help. i also have some problem with testing them with WIndows 2000. And looking for some free implementation on linux. hope i'm not really off topic. By the way i would be interested in research about IPsec does anyone knows where i could find some information? Beldi Olivier Syseca 06-62-14-17-01 ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-ipsec@lists.tislabs.com Mon Jul 24 09:28:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15925; Mon, 24 Jul 2000 09:28:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14077 Mon, 24 Jul 2000 10:54:11 -0400 (EDT) Message-ID: <397C5ACC.95403F1D@radware.com> Date: Mon, 24 Jul 2000 11:03:40 -0400 From: Vlado Zafirov X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: New draft-vlado-keep-alive-02 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, This is my new version of the draft. I hope I addressed most of the issues of the previous one. -- Vlado Zafirov RADWare, INC Technical Support Engineer Tel: (202) 625-1505 Fax: (202) 625-1506 Confidentiality Note: This e-mail, and any attachment to it, contains privileged and confidential information intended only for the use of the individual(s) or entity named in the e-mail. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that reading it is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you. From owner-ipsec@lists.tislabs.com Mon Jul 24 09:30:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15993; Mon, 24 Jul 2000 09:30:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14191 Mon, 24 Jul 2000 11:19:42 -0400 (EDT) Message-ID: <397C60C8.BE62C76B@storm.ca> Date: Mon, 24 Jul 2000 11:29:12 -0400 From: Sandy Harris Organization: Global Village Idiots X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: beldi olivier CC: ipsec@lists.tislabs.com Subject: Re: about ipsec References: <20000724123436.77450.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk beldi olivier wrote: > > I'm not sure my question is exactly on the topic of this list but i'm > supposed to study and understand IPSec,in order to integrate them as a > solution for my company network security. > but even if i've read a lots of books and some RFC i still don't understand > IKE. > could anyone give me some help. Two good starting points: VPN Consortium www.vpnc.org VPN mailing list http://kubarb.phsx.ukans.edu/~tbird/vpn.html > i also have some problem with testing them with WIndows 2000. > And looking for some free implementation on linux. http://www.freeswan.org All the documentation for that implementation is on the web site. It includes an overview.html file that is supposed to explain IKE among other things. I'm the author, and I'm not yet happy about that text. Comment and crticism would be appreciated. It should, however, go to the linux-ipsec@clinet.fi list rather than here. From owner-ipsec@lists.tislabs.com Mon Jul 24 11:17:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA18225; Mon, 24 Jul 2000 11:17:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14499 Mon, 24 Jul 2000 12:50:51 -0400 (EDT) Message-ID: <397C75D8.A032E743@redcreek.com> Date: Mon, 24 Jul 2000 09:59:04 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Internet-Drafts@ietf.org CC: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-heartbeats-01.txt References: <200007241035.GAA07875@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 3. Changes Since Last Revision > > The document has been reorganized based on comments since the initial > revision. Protocol specifications have been moved closer to the > beginning of the document; background information and implementation > hints have been moved closer to the end. The details of the protocol > have not been significantly altered, due to a lack of agreement among > WG members as to what, if any, changes are required. These are merely cosmetic changes. This is a waste of everyone's time. It was quite clear after the presentation in Adelaide that this document does not clearly specify the problem it attempts to solve, and that many of the assumptions upon which it is based are clearly incorrect. Ignoring these facts will not advance this document. Scott From owner-ipsec@lists.tislabs.com Mon Jul 24 14:19:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23401; Mon, 24 Jul 2000 14:19:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15161 Mon, 24 Jul 2000 15:49:53 -0400 (EDT) From: Chien-chung Shen Date: Mon, 24 Jul 2000 15:10:25 -0400 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@lists.tislabs.com Subject: IKE source code... Message-ID: <200007241510.aa02571@cis.udel.edu> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I'd apologize in advance if the question had been asked before. Is there IKE source code publically available for research purposes? Thanks alot. Chien-Chung Shen From owner-ipsec@lists.tislabs.com Mon Jul 24 16:53:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26062; Mon, 24 Jul 2000 16:53:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA15530 Mon, 24 Jul 2000 18:48:23 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: Cc: "'Henry Spencer'" , "'Andrew Krywaniuk'" , "'Tim Jenkins'" , "'IPsec List'" , "'Hugh Daniel'" , "'John Gilmore'" Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt Date: Mon, 24 Jul 2000 18:51:49 -0400 Message-Id: <005e01bff5c1$c1317380$d23e788a@andrewk3.ca.newbridge.com> 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 V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > | Replacing unbounded state creation with unbounded rekeying > frequency is no > | solution. Fine, so this problem is kind of academic, but > you are endagering > | the ability of a host to be fully self-stablizing (and that > is of academic > | interest to me). > > Can you expand on this? Sure, I guess (although I suspect many people are getting bored of this topic). As I said, this is of mainly academic interest to me. I believe that a networking protocol should allow compliant implementations to be robust. If you want to be fully self-stabilizing then you need to be able to predict and control your behaviour, even while under heavy load or attack. Relying on dynamic memory allocation under low memory conditions can make a system very unpredictable. The proof of self-stabilization is akin to mathematical induction. Instead of merely stating that abnormal situation S_t shouldn't happen, you assume S_(t-1) is stable and show that S_t = S(t, S_(t-1)) is also stable. [Note than I am distinguishing between "abnormal" and "unstable" states here. (An abnormal situation should not cause unstable behaviour in a robust implementation.)] One important key to ensuring the predictability of your behaviour is that YOU (rather than the peer) get to decide how to bound your CPU consumption and memory usage. That's why it's best to avoid statements like "the host MUST store each X" or "the host MUST reply to (unsolicited) messages of type X". As I'm sure you're aware, the danger of an unstable system under heavy load is that after it corrects its behaviour (usually by crashing and rebooting), the situation which created the heavy load still exists (and is often worsened by the increased demand which is generated by the temporary outage). This may cause the instability to re-manifest itself. Witness the famous AT&T crash of 1990 or the recent DDoS attacks on websites or the Bill Clinton chatroom bug. Or consider the well-known logging bug where an application has a log message for "log is full" but they forget to reserve space in the log for this abnormal condition. A similar bug often manifiests itself on Windows systems when a careless implementer stores the "Out of Memory" message in the stringtable resource. It's easy for a system to be stable if it has very limited functionality. The danger here is that most of us want to make the most of the resources we have. Right now, we can't determine ahead of time exactly how much memory will be required to negotiate and store an SA of either type (although the SA footprints have much less size variance than the dynamic memory required during negotiation). However, once an SA has been created, it's size never needs to change. That's the beauty of bounded connection state. Even if you run out of dynamic memory, your existing SAs are not affected. You are also able to ignore unsolicted messages from the peer. If the peer sends a QM and you don't have the memory or the CPU power to handle the message, you can simply ignore it with no bad consequences. Now let's consider what happens if you need to process a QM under heavy load conditions: 1) A QM comes in and you don't have the CPU resources to parse it. You drop the message but the peer assumes you have received it, so the message id lists for the Isakmp SA get out of synch. or 2) A QM comes in and you don't have enough memory to store the message id. Therefore, you delete the Isakmp SA and renegotiate. However, the negotiation fails because you don't have enough memory to complete it. Now you have lost an SA that used to work + the peer will probably continue to retry the negotiation and it will continue to fail, thus wasting additional CPU resources. or 3) As above, except that the renegotiation of the Isakmp SA succeeds. Then the peer resends the QM and you don't have enough memory to store the message id, so you delete the Isakmp SA, attempt to renegotiate, and end up thrashing endlessly (this is particularly bad if it happens to multiple SAs simultaneously). And, of course, if you are susceptible to this problem under heavy load, then this behaviour can also be exploited by a malicious intermediate router (particularly if you store the message ids of info modes in addition to QMs). On the other hand, a counter (which was also proposed as a solution to the replay attack) does not require any additional memory allocation, nor does it require you to process every packet from the peer. Therefore, there is no potential for the counter to create unstable behaviour. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Mon Jul 24 18:15:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA29037; Mon, 24 Jul 2000 18:15:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA15682 Mon, 24 Jul 2000 19:51:43 -0400 (EDT) Message-Id: <200007250000.e6P00cq04886@adk.gr> X-Mailer: exmh version 2.0.2 2/24/98 To: wprice@cyphers.net Cc: ipsec@lists.tislabs.com Subject: Re: RIPEMD-160? In-reply-to: Your message of "Sun, 23 Jul 2000 22:29:06 PDT." <397BD422.A2CC6447@cyphers.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Jul 2000 20:00:38 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <397BD422.A2CC6447@cyphers.net>, Will Price writes: >The working group website lists an RFC 2857 for using RIPEMD-160 in the >context of ESP and AH. The link is broken and the document does not exist. Link seems to work (for me, now). >Eventually, I did find the document elsewhere. I noted that for all its >longevity, it didn't include any ID numbers to use for negotiating the use >of it! Since these ID numbers do not appear in the DOI document either, it >is somewhat of a mystery to me how this document could have advanced to >RFC without any existing way to interoperate with it. That document is not supposed to have any ID numbers of any sort in it; it just describes the use of RIPEMD-160 in ESP and AH -- neither of which has any notion of ID number. As for IKE, I've repeatedly asked IANA to assign a number but the request seems to be falling between the cracks. At some point they "verbally" told me it would be "4" in the hash algorithms table, but it still hasn't appeared. >As well, I don't see >anything about an ID for using RIPEMD-160 in the context of Phase 1. Now you have me at a loss; why would you need an ID to tell you how to use rmd160 in Phase 1? -Angelos From owner-ipsec@lists.tislabs.com Mon Jul 24 20:04:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA08530; Mon, 24 Jul 2000 20:04:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA16036 Mon, 24 Jul 2000 21:50:05 -0400 (EDT) Message-ID: <397CF47C.72FD4F88@storm.ca> Date: Mon, 24 Jul 2000 21:59:24 -0400 From: Sandy Harris Organization: Global Village Idiots X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Chien-chung Shen CC: ipsec@lists.tislabs.com Subject: Re: IKE source code... References: <200007241510.aa02571@cis.udel.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chien-chung Shen wrote: > I'd apologize in advance if the question had been asked before. > Is there IKE source code publically available for research purposes? > Thanks alot. One is Linux FreeS/WAN: http://www.freeswan.org/ The online docs for it have a list of others: http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/links.ipsec.html#opensource From owner-ipsec@lists.tislabs.com Tue Jul 25 04:56:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA15515; Tue, 25 Jul 2000 04:56:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA17260 Tue, 25 Jul 2000 06:23:39 -0400 (EDT) Message-Id: <200007251033.GAA22386@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-06.txt Date: Tue, 25 Jul 2000 06:33:11 -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 : A GSS-API Authentication Method for IKE Author(s) : D. Piper, B. Swander Filename : draft-ietf-ipsec-isakmp-gss-auth-06.txt Pages : 12 Date : 24-Jul-00 This document describes an alternate authentication method for IKE which makes use of GSS-API to authenticate the Diffie-Hellman exchange. The mechanism described here extends the authentication methods defined in RFC-2409 without introducing any modifications to the IKE key exchange protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-06.txt 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-isakmp-gss-auth-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <20000724141745.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-gss-auth-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000724141745.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Jul 25 06:11:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA20710; Tue, 25 Jul 2000 06:11:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA17576 Tue, 25 Jul 2000 07:51:45 -0400 (EDT) Message-Id: <200007251033.GAA22386@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-gss-auth-06.txt Date: Tue, 25 Jul 2000 06:33:11 -0400 X-scanner: scanned by Inflex 0.1.5-E - (http://www.inflex.co.za/) 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 : A GSS-API Authentication Method for IKE Author(s) : D. Piper, B. Swander Filename : draft-ietf-ipsec-isakmp-gss-auth-06.txt Pages : 12 Date : 24-Jul-00 This document describes an alternate authentication method for IKE which makes use of GSS-API to authenticate the Diffie-Hellman exchange. The mechanism described here extends the authentication methods defined in RFC-2409 without introducing any modifications to the IKE key exchange protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-06.txt 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-isakmp-gss-auth-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <20000724141745.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-gss-auth-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000724141745.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Jul 25 06:40:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA22273; Tue, 25 Jul 2000 06:40:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17852 Tue, 25 Jul 2000 08:31:50 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: The result of IKE bake-off at Yokohama in Japan. X-Mailer: Cue version 0.6 (000609-1000/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20000725214302F.sakane@ydc.co.jp> Date: Tue, 25 Jul 2000 21:43:02 +0900 From: "Shoichi 'Ne' Sakane" X-Dispatcher: imput version 990905(IM130) Lines: 9 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We held a small interoperability test for IKE at Yokohama in Japan, 4 days from 14th July. There were 11 implementation. 4 of them could talk IKE by IPv6. Here is the result. http://www.tanu.org/~sakane/doc/public/report-ike-interop0007.html Thank you. /Shoichi `NE' Sakane @ KAME project/ From owner-ipsec@lists.tislabs.com Tue Jul 25 09:04:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA08256; Tue, 25 Jul 2000 09:04:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18391 Tue, 25 Jul 2000 10:31:26 -0400 (EDT) Message-Id: <200007250947.LAA26117@ritz.appli.se> To: Chien-chung Shen cc: ipsec@lists.tislabs.com Subject: Re: IKE source code... In-reply-to: Your message of "Mon, 24 Jul 2000 15:10:25 EDT." <200007241510.aa02571@cis.udel.edu> Date: Tue, 25 Jul 2000 11:47:29 +0200 From: Niklas Hallqvist Sender: owner-ipsec@lists.tislabs.com Precedence: bulk isakmpd Available from either OpenBSD's source tree in sbin/isakmpd (lacks other OS support in this instantiation, but is rather up-to-date), ftp.gsnig.org:/pub/isakmpd (have multi-platform support, but is aged) or apply for CVS access to the GSNIG isakmpd source tree (always up-to-date, have the multi-platform support, but requires an account and preferrably some sort of agenda wrt isakmpd development). The implementation of isakmpd was presented in a paper last Usenix' technical conference. BSD-licensed. Niklas From owner-ipsec@lists.tislabs.com Tue Jul 25 11:30:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11507; Tue, 25 Jul 2000 11:30:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19156 Tue, 25 Jul 2000 13:17:23 -0400 (EDT) Message-ID: <000701bff65d$54b36e60$8ae5e18f@grid.unina.it> From: "Fabio Zamparelli" To: Subject: Anyone using 3com ipsecNICs with WIN2K? Date: Tue, 25 Jul 2000 19:25:25 +0200 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.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have some problems using the international (DES) version of 3Com SecurNICs, setting up a Win2k Testbed for my university-master thesis. Is someone using them? Thanks, Fabio Zamparelli From owner-ipsec@lists.tislabs.com Tue Jul 25 14:31:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14316; Tue, 25 Jul 2000 14:31:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19795 Tue, 25 Jul 2000 16:00:53 -0400 (EDT) Date: Tue, 25 Jul 2000 22:05:07 +0200 (METDST) From: "Hans v. Sommerfeld" Message-Id: <200007252005.WAA01609@charly.peanuts.local> To: ipsec@lists.tislabs.com Subject: EICAR 2001: Call for Papers Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-MD5: Y8L98b67cp0fyOyp9eTm6Q== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id QAA19792 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk EICAR 2001: 10th Annual EICAR Conference - 2nd European Anti-Malware Conference Saturday March 3th - Tuesday March 6th 2001, Bilbao, Spain Hosted by the European Software Institute (ESI) This is a final reminder about the EICAR 2001 Call for Papers. SUBMISSION DEADLINE for PAPERS: AUGUST 1, 2000. There's still time to submit your paper. Check out to see where to submit to. The Editorial Team at EICAR-ConferenceNews: See EICAR at HvS :-) From owner-ipsec@lists.tislabs.com Wed Jul 26 07:25:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06199; Wed, 26 Jul 2000 07:25:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22479 Wed, 26 Jul 2000 08:53:56 -0400 (EDT) Message-ID: <397EE19F.5AE38323@F-Secure.com> Date: Wed, 26 Jul 2000 16:03:27 +0300 From: Ari Huttunen Organization: F-Secure Oyj X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-list Subject: Comments regarding IPsec NAT traversal / new proposal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This mail applies partly to both of these drafts: draft-aboba-nat-ipsec-02.txt draft-stenberg-ipsec-nat-traversal-00.txt We believe that using UDP encapsulation is the correct way to traverse NATs, at least in the short term. We also intend to produce an internet draft about this, however it didn't materialize before the Pittsburgh meeting. The current proposals are unnecessarily complex, and I'd like some discussion about these issues, to judge if this is indeed the case. ASSUMPTION: There is no *need* to enable AH traffic to traverse through a NAT. ESP is sufficient to provide encryption and/or authentication. By accepting this assumption, the solution can be made less complex. It has been argued that in some rare cases AH is necessary to protect the IP header. If this is so, I argue that there is no need to make this pass through a NAT as well. Thus, we can use the following encapsulation that is less complex and has less overhead than either of the referred drafts has, i.e. 8 octets. Transport mode: --------------------------------------------------------- IPv4 |orig IP hdr | UDP | ESP | | ESP | ESP| |(any options)| Hdr | Hdr | Payload Data | Trailer |Auth| --------------------------------------------------------- ASSUMPTION: We do *not* wish to use the same UDP port for both IKE and IPsec traffic encapsulated in UDP. This is because we'd loose the possibility to filter these traffic types separately in a firewall. For this purpose we've reserved the port 2797 from IANA. As draft-stenberg-ipsec-nat-traversal-00.txt mentions, there is a potential need for a keepalive to ensure NAT tables remain up-to-date. Because our proposal uses a different port than IKE, there is a need for a keepalive that sends packets along the ESPoverUDP path. This can be achieved for instance by sending empty UDP packets (i.e. without ESP contents). (Assuming the general IPsec keepalive is along the IKE SA and can't be used.) In particular, the method of negotiating and setting up UDP encapsulation as defined in draft-stenberg-ipsec-nat-traversal-00.txt is too complex. We propose the following mechanism for discussion: 1) IKE phase 1 is not modified. 2) IKE phase 2 adds a new protocol ID, Protocol ID Value ----------- ----- RESERVED 0 PROTO_ISAKMP 1 PROTO_IPSEC_AH 2 PROTO_IPSEC_ESP 3 PROTO_IPCOMP 4 PROTO_IPSEC_ESP_OVER_UDP X This is used to send proposals for plain IPsec as well as ESPoverUDP during the QM. As usual, the responder may use any proposal it wishes. The proposal shall contain parameters that say which src/dst port/addresses were used by the initiator when sending the IKE packet. If these differ from those observed by the responder, there is a NAT acting between them, and the responder SHOULD choose the ESP over UDP proposal. Unlike draft-stenberg-ipsec-nat-traversal-00.txt, this method does not leak information regarding the internal structure of the network, because QM messages are encrypted. We don't have patent applications regarding this, but I have no way of knowing whether SSH has tried to patent some it. -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Wed Jul 26 07:46:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07232; Wed, 26 Jul 2000 07:46:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22641 Wed, 26 Jul 2000 09:38:48 -0400 (EDT) Message-ID: <9F2ABADBBA07D311BA2D0008C70718BB029A4892@DENNTEX003.qwest.net> From: "Simmons, Aaron J" To: "'Fabio Zamparelli'" , ipsec@lists.tislabs.com Subject: RE: Anyone using 3com ipsecNICs with WIN2K? Date: Wed, 26 Jul 2000 07:47:29 -0600 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 Yes, I have test them and there was a problem, they didn't work! I've since switched to the Intel Pro/100 S Server Adapter.... Aaron Simmons -----Original Message----- From: Fabio Zamparelli [mailto:zamparelli@mclink.it] Sent: Tuesday, July 25, 2000 11:25 To: ipsec@lists.tislabs.com Subject: Anyone using 3com ipsecNICs with WIN2K? I have some problems using the international (DES) version of 3Com SecurNICs, setting up a Win2k Testbed for my university-master thesis. Is someone using them? Thanks, Fabio Zamparelli From owner-ipsec@lists.tislabs.com Thu Jul 27 10:21:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06647; Thu, 27 Jul 2000 10:21:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03680 Thu, 27 Jul 2000 11:37:19 -0400 (EDT) Date: Thu, 27 Jul 2000 11:46:59 -0400 From: "Theodore Ts'o" Message-Id: <200007271546.LAA16004@trampoline.thunk.org> To: mstenber@ssh.com CC: ipsec@lists.tislabs.com In-reply-to: <87itu06suf.fsf@porsas.jp.ssh.com> (message from Markus Stenberg on 21 Jul 2000 12:54:32 +0900) Subject: Re: Call for agenda topics for Pittsburgh IETF Phone: (781) 391-3464 References: <87itu06suf.fsf@porsas.jp.ssh.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm very sorry for the delay in getting this proposed agenda out. I've been on the road this past week, and my e-mail latency has been more than a little bit variable. Attached please find the list of those people who have requested time for the IPSEC meeting. I've I've missed anything or anybody, please let me know. - Ted DRAFT agenda for IPSEC WG Notify messages draft ===================== "Scott G. Kelly" I submitted the latest rev of the notify messages draft last Friday, so I assume we should be seeing an announcement on the ipsec list soon. I think we've resolved all remaining issues, and would like to see if we have consensus so that we can move it into last call. I can present the latest round of modifications in Pittsburg. Heartbeat proposals ==================== "Andrew Krywaniuk" draft-krywaniuk-ipsec-attribute-exchange-00.txt draft-krywaniuk-ipsec-heartbeats-00.txt Vlado Zafirov draft-vlado-ipsec-keep-alive-01.txt NAT proposals ============= Wlliam Dixon and Bernard Aboba draft-aboba-nat-ipsec-01.txt IPSEC/NAT Jose Carlos Brustoloni Title: VPN Masquerade Assist (VMA): An End-to-End Mechanism for Robust NAT Interoperation with IPsec's IKE and ESP Tunnel Mode From: Markus Stenberg We submitted a draft on Friday regarding our approach about how to implement NAT-traversal in IPsec. Although no I-D announce has yet showed up (are they usually delayed much?), I'd like to get a chance to give a presentation regarding it in the IETF Pittsburgh meeting. (providing it gets to I-D announce stage, obviously) From: Claudio Lordello I would like to request some time to discuss an issue that we have with IKE on how to identify a particular virtual router (or, a distinct IP address realm) during phase 2 SA negotiations. Stream Cipher ESP proposal =========================== "David A. McGrew" I've just sent in an individual submission Internet Draft, "The Stream Cipher ESP". I would like to pursue standards track. I thought it would be good to let you know. draft-mcgrew-ipsec-scesp-01.txt From owner-ipsec@lists.tislabs.com Thu Jul 27 23:46:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA19488; Thu, 27 Jul 2000 23:46:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA05627 Fri, 28 Jul 2000 01:19:20 -0400 (EDT) Message-Id: <01BFE0EF.EA17D820.sridharj@future.futsoft.com> From: Sridhar J Reply-To: "sridharj@future.futsoft.com" To: "'Sandy Harris'" Cc: "ipsec@lists.tislabs.com" , "'linux-ipsec@clinet.fi'" Date: Wed, 28 Jun 2000 10:59:19 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Is there any source code available for IKE which implements RSA authentication algorithm. sridhara. j future software pvt ltd. chennai india email : sridharj@future.futsoft.com From owner-ipsec@lists.tislabs.com Fri Jul 28 12:13:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA15663; Fri, 28 Jul 2000 12:13:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07390 Fri, 28 Jul 2000 13:26:08 -0400 (EDT) Message-Id: <200007280627.IAA03324@ritz.appli.se> To: "sridharj@future.futsoft.com" cc: "'Sandy Harris'" , "ipsec@lists.tislabs.com" , "'linux-ipsec@clinet.fi'" In-reply-to: Your message of "Wed, 28 Jun 2000 10:59:19 +0530." <01BFE0EF.EA17D820.sridharj@future.futsoft.com> Date: Fri, 28 Jul 2000 08:27:03 +0200 From: Niklas Hallqvist Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Sridhar J > Date: Wed, 28 Jun 2000 10:59:19 +0530 > Is there any source code available for IKE which implements RSA > authentication algorithm. Once again, isakmpd. The message below, sent two days ago, shows availability information. For the actual RSA algorithmic stuff, we use OpenSSL. Niklas > Date: Tue, 25 Jul 2000 11:47:29 +0200 > From: Niklas Hallqvist > > isakmpd > > Available from either OpenBSD's source tree in sbin/isakmpd (lacks > other OS support in this instantiation, but is rather up-to-date), > ftp.gsnig.org:/pub/isakmpd (have multi-platform support, but is aged) > or apply for CVS access to the GSNIG isakmpd source tree (always > up-to-date, have the multi-platform support, but requires an account > and preferrably some sort of agenda wrt isakmpd development). > > The implementation of isakmpd was presented in a paper last Usenix' > technical conference. > > BSD-licensed. > > Niklas From owner-ipsec@lists.tislabs.com Fri Jul 28 14:03:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA18833; Fri, 28 Jul 2000 14:03:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07888 Fri, 28 Jul 2000 15:55:57 -0400 (EDT) X-Authentication-Warning: malabar.mitre.org: guttman set sender to guttman@mitre.org using -f To: ipsec@lists.tislabs.com Cc: guttman@mitre.org (Joshua D. Guttman), "Grant M. Wagner" , fnc@mitre.org (Chase, Frederick N.), althomas@mitre.org (Herzog, Amy L.), bede@mitre.org (McCall, Bede B.) Subject: Cisco "dynamic-map"s Reply-To: guttman@mitre.org (Joshua D. Guttman) From: guttman@mitre.org (Joshua D. Guttman) Date: 28 Jul 2000 16:05:03 -0400 Message-ID: Lines: 49 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA07885 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd be grateful for information about a particular aspect of Cisco's implementation. A Cisco configuration file can use the key word dynamic-map, as in crypto dynamic-map mydynamicmap 10  match address 103  set transform-set my_t_set1 my_t_set2 my_t_set3 (quoted from http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_r/srprt4/srdipsec.htm) What this means is that a peer will be allowed to initiate an IPsec tunnel for certain packets. *Which* packets is determined by the "match address 103" line; it means the set of packets accepted by access list number 103, which would be defined elsewhere in the file. Then those packets will be subjected to the one of the named my_t_set_i sets of transforms. My question is this: Is there any way to constrain which *peers* can initiate tunnels for these packets? For instance, if all the packets accepted by access list 103 have source address in a particular class C network, then I might want to stipulate that the peer should have an address in that network too (any address in that network would be OK). I might not want a peer in one class C network "authenticating" packets that purportedly come from a different class C network. Even if I have a reliable public key for the peer. In fact, if it's not possible to prevent this, it would seem to me an unsafe mechanism. I hope that this is not too implementation-specific a question for this list. I have sent the question here because it's really about how to use IPsec mechanisms to achieve reasonable packet-level access control. Thanks. Joshua -- Joshua D. Guttman MITRE, Mail Stop A150 202 Burlington Rd. Tel: +1 781 271 2654 Bedford, MA 01730-1420 USA Fax: +1 781 271 3816 From owner-ipsec@lists.tislabs.com Sat Jul 29 12:47:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28298; Sat, 29 Jul 2000 12:47:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10407 Sat, 29 Jul 2000 14:21:33 -0400 (EDT) From: "=?iso-8859-1?Q?Svenning_S=F8rensen?=" To: , Subject: Order of IPCOMP encapsulation Date: Sat, 29 Jul 2000 20:33:37 +0200 Message-ID: <000001bff98b$83702b40$1400a8c0@ssscpq.sss.dk> 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 V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello there. I have had a shot at implementing IPCOMP (Deflate) into FreeS/WAN, and it has been working flawlessly for a couple of months between 2 FreeS/WAN gateways. However, I ran into a problem when trying to communicate with PGPNet. Transport mode between PGPNet and FS works fine, but tunnel mode does not, because I have used a different ordering of the IPCOMP encapsulation than PGPNet has. PGPNet does ESP(IPCOMP(IPIP(payload))), while I have done ESP(IPIP(IPCOMP(payload))). My implementation has no problem decoding packets from PGPNet, but PGPNet rejects my packets. I wondered what would be the most correct order of doing the IPCOMP processing. RFC2393 states that IPCOMP must be done before any IPSec processing. While IPIP tunnelling isn't strictly an IPSec protocol, it nevertheless is a part of FreeS/Wan, and other IPSec implementations, I suspect, so that statement seems a bit ambiguos to me. Also, RFC2393 proposes to use ISAKMP to negotiate an IPCA (which I also do) together with an IPSec SA. Since IPIP encapsulation is negotiated as an attribute (ENCAPSULATION_MODE_TUNNEL) of the ESP transform, it would suggest to me, that ESP and IPIP should be closely tied together. Thus, putting IPCOMP in between seems incorrect to me. OTOH, doing the compression after the IPIP encapsulation may gain a few more bytes of compression. I wondered if anybody on the lists has any comments about this? How do other implementations do it? Cheers, Svenning From owner-ipsec@lists.tislabs.com Sun Jul 30 09:56:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05788; Sun, 30 Jul 2000 09:56:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11981 Sun, 30 Jul 2000 11:09:12 -0400 (EDT) Message-ID: From: "Kavsan, Bronislav" To: ipsec@lists.tislabs.com Subject: VPN Bakeoff question Date: Sun, 30 Jul 2000 11:18:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is anyone interested in testing XAUTH, Hybrid Auth or CRACK using SecurID tokens at the September bakeoff? If there is enough interest - RSA Security will set up integrated ACE/RADIUS server there and configure/distribute SecurID tokens to the participants of the bakeoff. Thank you, Slava Kavsan RSA Security Inc. From owner-ipsec@lists.tislabs.com Sun Jul 30 23:09:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA26673; Sun, 30 Jul 2000 23:09:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA13394 Mon, 31 Jul 2000 00:10:45 -0400 (EDT) Message-Id: <01BFE341.DB5F52A0.sridharj@future.futsoft.com> From: Sridhar J Reply-To: "sridharj@future.futsoft.com" To: "'Chien-chung Shen'" , "Ipsec (E-mail)" Subject: RE: IKE source code... Date: Sat, 1 Jul 2000 09:50:54 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----Original Message----- From: Chien-chung Shen [SMTP:cshen@mail.eecis.udel.edu] Sent: Tuesday, July 25, 2000 12:40 AM To: ipsec@lists.tislabs.com Subject: IKE source code... Hi, I'd apologize in advance if the question had been asked before. Is there IKE source code publically available for research purposes? Thanks alot. Chien-Chung Shen ej, From: Sridhar J > Date: Wed, 28 Jun 2000 10:59:19 +0530 > Is there any source code available for IKE which implements RSA > authentication algorithm. Once again, isakmpd. The message below, sent two days ago, shows availability information. For the actual RSA algorithmic stuff, we use OpenSSL. Niklas > Date: Tue, 25 Jul 2000 11:47:29 +0200 > From: Niklas Hallqvist > > isakmpd > > Available from either OpenBSD's source tree in sbin/isakmpd (lacks > other OS support in this instantiation, but is rather up-to-date), > ftp.gsnig.org:/pub/isakmpd (have multi-platform support, but is aged) > or apply for CVS access to the GSNIG isakmpd source tree (always > up-to-date, have the multi-platform support, but requires an account > and preferrably some sort of agenda wrt isakmpd development). > > The implementation of isakmpd was presented in a paper last Usenix' > technical conference. > > BSD-licensed. > > Niklas From owner-ipsec@lists.tislabs.com Mon Jul 31 10:25:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17334; Mon, 31 Jul 2000 10:25:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15778 Mon, 31 Jul 2000 11:56:49 -0400 (EDT) Message-ID: <3985A3F9.63D7A47E@F-Secure.com> Date: Mon, 31 Jul 2000 19:06:17 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.71 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Kavsan, Bronislav" CC: ipsec@lists.tislabs.com Subject: Re: VPN Bakeoff question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We'd be interested in testing as a client to XAUTH + SecurID. Ari Huttunen, F-Secure Corporation "Kavsan, Bronislav" wrote: > > Is anyone interested in testing XAUTH, Hybrid Auth or CRACK using SecurID > tokens at the September bakeoff? > > If there is enough interest - RSA Security will set up integrated ACE/RADIUS > server there and configure/distribute SecurID tokens to the participants of > the bakeoff. > > Thank you, > > Slava Kavsan > RSA Security Inc. From owner-ipsec@lists.tislabs.com Mon Jul 31 12:22:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA19880; Mon, 31 Jul 2000 12:22:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16337 Mon, 31 Jul 2000 14:08:58 -0400 (EDT) Message-Id: <200007311814.LAA00992@potassium.network-alchemy.com> To: "Kavsan, Bronislav" cc: ipsec@lists.tislabs.com Subject: Re: VPN Bakeoff question In-reply-to: Your message of "Sun, 30 Jul 2000 11:18:44 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <989.965067290.1@network-alchemy.com> Date: Mon, 31 Jul 2000 11:14:50 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We'd be interested in testing CRACK w/SecurID, client side and gateway side. Dan. On Sun, 30 Jul 2000 11:18:44 EDT you wrote > Is anyone interested in testing XAUTH, Hybrid Auth or CRACK using SecurID > tokens at the September bakeoff? > > If there is enough interest - RSA Security will set up integrated ACE/RADIUS > server there and configure/distribute SecurID tokens to the participants of > the bakeoff. > > Thank you, > > Slava Kavsan > RSA Security Inc. From owner-ipsec@lists.tislabs.com Mon Jul 31 13:18:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20871; Mon, 31 Jul 2000 13:18:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16577 Mon, 31 Jul 2000 15:07:53 -0400 (EDT) Date: Mon, 31 Jul 2000 15:11:10 -0400 From: Jim Tiller X-Mailer: The Bat! (v1.44) Reply-To: "Jim Tiller, CISSP" Organization: Belenos, Inc. X-Priority: 3 (Normal) Message-ID: <61050760.20000731151110@belenosinc.com> To: guttman@mitre.org ((Joshua D. Guttman)) CC: ipsec@lists.tislabs.com, "Grant M. Wagner" , fnc@mitre.org ((Chase, Frederick N.)), (\(Herzog, Amy L.), (\(McCall, Bede B.) Subject: Re: Cisco "dynamic-map"s In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Joshua, This is a bit implementation specific. The dynamic map is geared for remote access where the source IP is unknown - hence the reason for assigning last - "If you don't know the peer by not matching set static maps allow them to communicate using a dynamic map". If you want to limit it, add the accepted IP addresses to the ACL 103. In other words, you know that all your remote users are on cable modems - enter permit 24.0.0.0 0.255.255.255 - or something along those lines. If you want to limit access to known the IP address you could just use expanded static maps. my $0.02 -jim Friday, July 28, 2000, 4:05:03 PM, you wrote: JDG> I'd be grateful for information about a particular aspect of Cisco's JDG> implementation. JDG> A Cisco configuration file can use the key word dynamic-map, as in JDG> crypto dynamic-map mydynamicmap 10 JDG> match address 103 JDG> set transform-set my_t_set1 my_t_set2 my_t_set3 JDG> (quoted from JDG> http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_r/srprt4/srdipsec.htm) JDG> What this means is that a peer will be allowed to initiate an IPsec JDG> tunnel for certain packets. *Which* packets is determined by the JDG> "match address 103" line; it means the set of packets accepted by JDG> access list number 103, which would be defined elsewhere in the file. JDG> Then those packets will be subjected to the one of the named JDG> my_t_set_i sets of transforms. JDG> My question is this: Is there any way to constrain which *peers* can JDG> initiate tunnels for these packets? JDG> For instance, if all the packets accepted by access list 103 have JDG> source address in a particular class C network, then I might want to JDG> stipulate that the peer should have an address in that network too JDG> (any address in that network would be OK). JDG> I might not want a peer in one class C network "authenticating" JDG> packets that purportedly come from a different class C network. Even JDG> if I have a reliable public key for the peer. JDG> In fact, if it's not possible to prevent this, it would seem to me an JDG> unsafe mechanism. JDG> I hope that this is not too implementation-specific a question for JDG> this list. I have sent the question here because it's really about JDG> how to use IPsec mechanisms to achieve reasonable packet-level access JDG> control. JDG> Thanks. JDG> Joshua From owner-ipsec@lists.tislabs.com Mon Jul 31 15:06:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA23031; Mon, 31 Jul 2000 15:06:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16948 Mon, 31 Jul 2000 16:52:51 -0400 (EDT) Message-ID: From: Bill Becker To: "'Kavsan, Bronislav'" , ipsec@lists.tislabs.com Subject: RE: VPN Bakeoff question Date: Mon, 31 Jul 2000 17:00:19 -0400 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 Slava, We'd like to test our SafeNet client with gateways that support XAUTH + SecureID. Bill Becker IRE -----Original Message----- From: Kavsan, Bronislav [mailto:bkavsan@rsasecurity.com] Sent: Sunday, July 30, 2000 11:19 AM To: ipsec@lists.tislabs.com Subject: VPN Bakeoff question Is anyone interested in testing XAUTH, Hybrid Auth or CRACK using SecurID tokens at the September bakeoff? If there is enough interest - RSA Security will set up integrated ACE/RADIUS server there and configure/distribute SecurID tokens to the participants of the bakeoff. Thank you, Slava Kavsan RSA Security Inc. From owner-ipsec@lists.tislabs.com Mon Jul 31 15:58:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA23678; Mon, 31 Jul 2000 15:58:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17073 Mon, 31 Jul 2000 17:54:56 -0400 (EDT) Date: Mon, 31 Jul 2000 18:03:45 -0400 (EDT) From: Henry Spencer To: =?iso-8859-1?Q?Svenning_S=F8rensen?= cc: ipsec@lists.tislabs.com, linux-ipsec@clinet.fi Subject: Re: Order of IPCOMP encapsulation In-Reply-To: <000001bff98b$83702b40$1400a8c0@ssscpq.sss.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 29 Jul 2000, =?iso-8859-1?Q?Svenning_S=F8rensen?= wrote: > PGPNet does ESP(IPCOMP(IPIP(payload))), while I have done > ESP(IPIP(IPCOMP(payload)))... > I wondered what would be the most correct order of doing the IPCOMP > processing. There was some discussion of this on the IPsec list in the distant past, as I recall. My notes say consensus favored ESP(IPCOMP(IPIP(payload))), so compression covers the inner header as well as the data, but they don't say why... although one obvious reason is compressing the IP header. > RFC2393 states that IPCOMP must be done before any IPSec processing. While > IPIP tunnelling isn't strictly an IPSec protocol, it nevertheless is a part > of FreeS/Wan, and other IPSec implementations... Moreover, it is very much part of IPsec *processing* -- RFC 2401 spends considerable verbiage discussing how to construct the outer header for the encapsulation, for example. So a strict reading of the specs would seem to put IPcomp inside IPIP. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jul 31 16:24:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA24341; Mon, 31 Jul 2000 16:24:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17119 Mon, 31 Jul 2000 18:20:04 -0400 (EDT) Message-ID: From: "Jones, Michael ( Marketing)" To: Ari Huttunen , "Kavsan, Bronislav" Cc: ipsec@lists.tislabs.com Subject: RE: VPN Bakeoff question Date: Mon, 31 Jul 2000 15:29:42 -0700 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 Yes, please set one up. I think there will be lots of folks who will want to test this. Can you also bring some tokens that we can test with? Thanks, Mike Michael K. Jones PGP Business Line Manager PGP Security, Inc. - Your e-Business Defender mjones@nai.com PGP Fingerprint: D4D0 E06D 7DF9 736F 49B3 0B63 C081 3AC0 4D6D 2E7E http://www.pgp.com/ -----Original Message----- From: Ari Huttunen [mailto:Ari.Huttunen@F-Secure.com] Sent: Monday, July 31, 2000 9:06 AM To: Kavsan, Bronislav Cc: ipsec@lists.tislabs.com Subject: Re: VPN Bakeoff question We'd be interested in testing as a client to XAUTH + SecurID. Ari Huttunen, F-Secure Corporation "Kavsan, Bronislav" wrote: > > Is anyone interested in testing XAUTH, Hybrid Auth or CRACK using SecurID > tokens at the September bakeoff? > > If there is enough interest - RSA Security will set up integrated ACE/RADIUS > server there and configure/distribute SecurID tokens to the participants of > the bakeoff. > > Thank you, > > Slava Kavsan > RSA Security Inc.